[Bug c/91031] wrong code generated when using compound literal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91031 Andrew Pinski changed: What|Removed |Added CC||makhaloff at gmail dot com --- Comment #4 from Andrew Pinski --- *** Bug 94979 has been marked as a duplicate of this bug. ***
[Bug c/94979] gcc-9 generates incorrect code causing segfault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94979
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRMED |RESOLVED
--- Comment #1 from Andrew Pinski ---
>if (!j)
j = (char *[]){"a", "test"};
The scope of the unnamed variable is just in that statement.
So you are using the unnamed variable outside of the scope.
See https://gcc.gnu.org/gcc-9/porting_to.html#complit
See PR 91031 also which is this is a dup of.
*** This bug has been marked as a duplicate of bug 91031 ***
[Bug c/94979] New: gcc-9 generates incorrect code causing segfault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94979
Bug ID: 94979
Summary: gcc-9 generates incorrect code causing segfault
Product: gcc
Version: 9.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: makhaloff at gmail dot com
Target Milestone: ---
I found this issue while compiling systemd-239 with gcc-9.3.0
The problem is in local data initialization on the stack such as array of
pointers to global data.
-O0 is fine, but -01,02,03 eliminates such data causing app to segfault.
Confirmed gcc-9 branch (up to commit 25c60fcadc397c42a0ec778e5b123f2c94d3)
still has this bug.
Test program is attached below.
Additional info and steps to reproduce:
~/gcc$ ./host-x86_64-pc-linux-gnu/gcc/xgcc -v
Using built-in specs.
COLLECT_GCC=./host-x86_64-pc-linux-gnu/gcc/xgcc
Target: x86_64-pc-linux-gnu
Configured with: ./configure --enable-shared --enable-threads=posix
--enable-__cxa_atexit --enable-clocale=gnu --enable-languages=c
--disable-multilib --disable-bootstrap --disable-libstdcxx-pch
--enable-linker-build-id --enable-plugin --with-system-zlib
Thread model: posix
gcc version 9.3.1 20200507 (GCC)
~/gcc$ ./host-x86_64-pc-linux-gnu/gcc/xgcc -B./host-x86_64-pc-linux-gnu/gcc/
test.c
~/gcc$ ./a.out
~/gcc$ echo $?
0
~/gcc$ ./host-x86_64-pc-linux-gnu/gcc/xgcc -B./host-x86_64-pc-linux-gnu/gcc/
-O1 test.c
~/gcc$ ./a.out
Segmentation fault (core dumped)
= test.c ==
#include
int chararray(char **j) {
if (!j)
j = (char *[]){"a", "test"};
return (strlen(j[0]) == 1) & (strlen(j[1]) == 4);
}
int main(void) {
return chararray(0) == 0;
}
===
[Bug fortran/94978] [8/9/10/11 Regression] Bogus warning "Array reference at (1) out of bounds in loop beginning at (2)"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94978 --- Comment #1 from Fritz Reese --- The regression is caused by r253156, which introduces the warning in the first place. The relevant code is in frontend-passes.c (do_subscript). Apparently, the FE is aware that when there is a conditional it cannot correctly simplify the subscript bounds. However, in the testcase there is an inner DO-loop which, when the bounds are reduced to the empty set, prevents the code from becoming invalid. Therefore no warning should be issued. The warning can be bypassed by guarding the inner DO-loop with any conditional, including a vacuously true one: $ diff -auw pascal.f03 pascal2.f03 --- pascal.f03 2020-05-06 19:14:50.966646632 -0400 +++ pascal2.f03 2020-05-06 19:23:48.209569659 -0400 @@ -9,9 +9,11 @@ do i = 0, 8 pascal(i,0) = 1 + if (.true.) then do j = 1, i-1 pascal(i,j) = pascal(i-1,j) + pascal(i-1,j-1) enddo + endif do j = i, 8 pascal(i,j) = 0 enddo $ gfortran pascal2.f03 Normally the warning can be suppressed with -Wno-do-subscript, but the code in do_subscript() determines that this is "definitely" an issue and therefore moves the warning to category 0. (An interesting note: moving the code in the testcase into a subroutine, rather than the main program, suppresses the warning for GCC 8, but not GCC 9, 10, or 11.)
[Bug fortran/94978] New: [8/9/10/11 Regression] Bogus warning "Array reference at (1) out of bounds in loop beginning at (2)"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94978 Bug ID: 94978 Summary: [8/9/10/11 Regression] Bogus warning "Array reference at (1) out of bounds in loop beginning at (2)" Product: gcc Version: 8.4.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: foreese at gcc dot gnu.org Target Milestone: --- Created attachment 48472 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48472=edit Testcase which exhibits the regression The following issues a bogus warning which cannot be disabled except with -w. The warning is not present in 7.x or earlier. Tried with 8.4.1, 9.3.1, 10 and 11.x (current trunk). Attached is a simple test case, which builds Pascal's triangle of order 8 and exhibits the regression. $ gfortran pascal.f03 pascal.f03:13:25: 10 | do i = 0, 8 | 2 .. 13 | pascal(i,j) = pascal(i-1,j) + pascal(i-1,j-1) | 1 Warning: Array reference at (1) out of bounds (-1 < 0) in loop beginning at (2) pascal.f03:13:41: 10 | do i = 0, 8 | 2 .. 13 | pascal(i,j) = pascal(i-1,j) + pascal(i-1,j-1) | 1 Warning: Array reference at (1) out of bounds (-1 < 0) in loop beginning at (2)
[Bug c++/94938] [10 Regression] internal compiler error: in value_dependent_expression_p, at cp/pt.c:26522
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94938 Marek Polacek changed: What|Removed |Added Summary|[10/11 Regression] internal |[10 Regression] internal |compiler error: in |compiler error: in |value_dependent_expression_ |value_dependent_expression_ |p, at cp/pt.c:26522 |p, at cp/pt.c:26522 --- Comment #5 from Marek Polacek --- Fixed on trunk so far.
[Bug c++/94938] [10/11 Regression] internal compiler error: in value_dependent_expression_p, at cp/pt.c:26522
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94938 --- Comment #4 from CVS Commits --- The master branch has been updated by Marek Polacek : https://gcc.gnu.org/g:1e89178889741c9c4d6a61e5a01c40a8a182fa68 commit r11-155-g1e89178889741c9c4d6a61e5a01c40a8a182fa68 Author: Marek Polacek Date: Mon May 4 18:34:38 2020 -0400 c++: ICE in value_dependent_expression_p in C++98 mode [PR94938] Here we ICE with -std=c++98 since the newly added call to uses_template_parms (r10-6357): we hit 26530 gcc_assert (cxx_dialect >= cxx11 26531 || INTEGRAL_OR_ENUMERATION_TYPE_P (type)); and TYPE is a record type. The problem is that the argument to value_dependent_expression_p does not satisfy potential_constant_expression which it must, as the comment explains. I thought about fixing this in uses_template_parms -- only call v_d_e_p if p_c_e is true, but in this case we want to also suppress the warnings if we don't have a constant expression. I couldn't simply check TREE_CONSTANT as in compute_array_index_type_loc, because then we'd stop warning in the new Wtype-limits3.C test. Fixed by using type_dependent_expression_p_push instead. This means that we won't suppress the warnings for value-dependent expressions that aren't type-dependent, e.g. sizeof (T). This only seems to make a difference for -Wdiv-by-zero, now tested in Wdiv-by-zero-3.C, where I think it's reasonable to warn. It could make -Wtautological-compare warn more, but that warning doesn't trigger when it gets constant arguments. Wtype-limits4.C is a test reduced from poly-int.h and it tests a scenario that was missing in our testsuite. This patch also moves the warning_sentinels after the RECURs -- we mean to use them for build_x_binary_op purposes only. PR c++/94938 * pt.c (tsubst_copy_and_build): Call type_dependent_expression_p_push instead of uses_template_parms. Move the warning_sentinels after the RECURs. * g++.dg/warn/Wdiv-by-zero-3.C: New test. * g++.dg/warn/Wtype-limits4.C: New test. * g++.dg/warn/template-2.C: New test. * g++.old-deja/g++.pt/crash10.C: Add dg-warning.
[Bug d/94970] d: internal compiler error: in verify_gimple_stmt, at tree-cfg.c:4959
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94970 --- Comment #5 from CVS Commits --- The master branch has been updated by Iain Buclaw : https://gcc.gnu.org/g:0af711e1914ab6d88538f1fcf0146757b5608b1d commit r11-154-g0af711e1914ab6d88538f1fcf0146757b5608b1d Author: Iain Buclaw Date: Wed May 6 23:34:11 2020 +0200 d: Fix ICE in verify_gimple_stmt, at tree-cfg.c:4959 Both array concat and array new expressions wrapped any temporaries created into a BIND_EXPR. This does not work if an expression used to construct the result requires scope destruction, which is represented by a TARGET_EXPR with a clean-up, and a CLEANUP_POINT_EXPR at the location where the temporaries logically go out of scope. The reason for this not working is because the lowering of cleanup point expressions does not traverse inside BIND_EXPRs to expand any gimple cleanup expressions within. The use of creating BIND_EXPR has been removed at both locations, and replaced with a normal temporary variable that has initialization delayed until its address is taken. gcc/d/ChangeLog: PR d/94970 * d-codegen.cc (force_target_expr): Move create_temporary_var implementation inline here. (create_temporary_var): Remove. (maybe_temporary_var): Remove. (bind_expr): Remove. * d-convert.cc (d_array_convert): Use build_local_temp to generate temporaries, and generate its assignment. * d-tree.h (create_temporary_var): Remove. (maybe_temporary_var): Remove. (d_array_convert): Remove vars argument. * expr.cc (ExprVisitor::visit (CatExp *)): Use build_local_temp to generate temporaries, don't wrap them in a BIND_EXPR. (ExprVisitor::visit (NewExp *)): Likewise. gcc/testsuite/ChangeLog: PR d/94970 * gdc.dg/pr94970.d: New test.
[Bug target/94950] [8/9/10 regression] ICE in gcc.dg/pr94780.c on riscv64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94950 --- Comment #6 from Jakub Jelinek --- (In reply to Jim Wilson from comment #5) > I tested it with an rv64gc-linux cross compiler. The patch fixes these Thanks. > I think it should be backported to the gcc-10 release branch. Sure, but at this point I'd prefer after 10.1.0 is released tomorrow. This isn't a recent regression and so shouldn't block the release.
[Bug target/94950] [8/9/10 regression] ICE in gcc.dg/pr94780.c on riscv64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94950 --- Comment #5 from Jim Wilson --- I tested it with an rv64gc-linux cross compiler. The patch fixes these failures: FAIL: gcc.dg/pr94780.c (internal compiler error) FAIL: gcc.dg/pr94780.c (test for excess errors) FAIL: gcc.dg/pr94842.c (internal compiler error) FAIL: gcc.dg/pr94842.c (test for excess errors) There are no regressions. I think it should be backported to the gcc-10 release branch.
[Bug c++/94951] [8/9/10/11 Regression] dereferencing type-punned pointer will break strict-aliasing rules when using super class for a template type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94951 --- Comment #6 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:46fcef99f49cc2d9f28d98f8ecdbf8263e9e0a87 commit r11-153-g46fcef99f49cc2d9f28d98f8ecdbf8263e9e0a87 Author: Jakub Jelinek Date: Wed May 6 23:38:13 2020 +0200 c++: Avoid strict_aliasing_warning on dependent types or expressions [PR94951] The following testcase gets a bogus warning during build_base_path, when cp_build_indirect_ref* calls strict_aliasing_warning with a dependent expression. IMHO calling get_alias_set etc. on dependent types feels wrong to me, we should just defer the warnings in those cases until instantiation and only handle the cases where neither type nor expr are dependent. 2020-05-06 Jakub Jelinek PR c++/94951 * typeck.c (cp_strict_aliasing_warning): New function. (cp_build_indirect_ref_1, build_reinterpret_cast_1): Use it instead of strict_aliasing_warning. * g++.dg/warn/Wstrict-aliasing-bogus-tmpl.C: New test.
[Bug c++/94907] [10/11 Regression] ICE: Segmentation fault (in check_return_expr) since r10-8016-gbce54ed494fd0e61
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94907 --- Comment #4 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:25ee2155ead87a5ea1c152a29341ee1e3275d706 commit r11-152-g25ee2155ead87a5ea1c152a29341ee1e3275d706 Author: Jakub Jelinek Date: Wed May 6 23:36:31 2020 +0200 c++: Don't synthesize sfk_comparison method multiple times [PR94907] On the following testcase we ICE, because synthesize_method is called twice on the same sfk_comparison method fndecl, the first time it works fine because start_preparsed_function in that case sets both current_function_decl and cfun, but second time it is called it only sets the former and keeps cfun NULL, so we ICE when trying to store current_function_returns_value. I think it is just wrong to call synthesize_method multiple times, and most synthesize_method callers avoid that by not calling it if DECL_INITIAL is already set, so this patch does that too. 2020-05-06 Jakub Jelinek PR c++/94907 * method.c (defaulted_late_check): Don't call synthesize_method on constexpr sfk_comparison if it has been called on it already. * g++.dg/cpp2a/spaceship-synth8.C: New test.
[Bug target/94630] General bug for changes needed to switch the powerpc64le-linux long double default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94630 --- Comment #8 from Paul E. Murphy --- The new libm/libc ABI for ieee128 long double on ppc64le is now committed to glibc which will be available for the 2.32 release (commit 051be01f6b41a1466b07ae4bd7f5894a8ec5fe67). TS-18661 does not specify any changes to the printf/scanf family of functions as related to _FloatN types. It won't always be a drop in replacement.
[Bug target/94977] New: Some X86 inline assembly modifiers are not documented in the web documentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94977 Bug ID: 94977 Summary: Some X86 inline assembly modifiers are not documented in the web documentation Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: craig.topper at gmail dot com Target Milestone: --- gcc supports some modifiers for inline assembly on X86 that are not documented in the table at 6.47.2.8 x86 Operand Modifiers here https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html For example gcc supports %x0 in inline assembly to indicate to always print a register as its xmm name. Similar there is also %t0 and %g0 for ymm and zmm respectively.
[Bug c++/94946] [9/10/11 Regression] error: ‘template JSC::FunctionPtr::FunctionPtr(returnType (*)())’ cannot be overloaded since r10-7998-g5f1cd1da1a805c3d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94946 Nathan Sidwell changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Nathan Sidwell --- Patch pushed to 9, 10 & master
[Bug c++/94955] [10/11 Regression] ICE in to_wide
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94955 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org
[Bug middle-end/4210] should not warn in dead code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=4210 --- Comment #41 from Niels Möller --- (In reply to Manuel López-Ibáñez from comment #39) > You can easily find which pass does something by dumping (-ftree-dump-*) > all of them and comparing them. It's -ftree-dump-all, and also -fdump-passes was useful. Thanks! I'm now compiling without optimization to (i) reduce number of passes, and (ii) because it would be nice to get it right also in absence of optimization options. It looks like the dead code is eliminated by the "cfg" (control flow graph) pass, in gcc/tree-cfg.c. In the .cfg dumpfile it says "Removing basic block 3", and the invalid shift disappears in that dump. That's nice. Immediately after this pass comes *warn_function_return, implemented in the same file. It would make sense to me to add a pass to warn about shift operations with invalid constant operands at about the same place. Is it easy to traverse a gimple function, and check all expressions? The "*warn_unused_result" pass seems to do a similar traversal (but examining statements rather than expressions, and done *before* the cfg pass).
[Bug c/94230] provide an option to change the size limitation for -Wmisleading-indent
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94230 qinzhao at gcc dot gnu.org changed: What|Removed |Added Version|10.0|11.0 Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #10 from qinzhao at gcc dot gnu.org --- the patch has been committed to gcc11 today. closed as fixed.
[Bug c++/94946] [9/10/11 Regression] error: ‘template JSC::FunctionPtr::FunctionPtr(returnType (*)())’ cannot be overloaded since r10-7998-g5f1cd1da1a805c3d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94946 Jakub Jelinek changed: What|Removed |Added Target Milestone|10.0|9.4
[Bug c++/94946] [9/10/11 Regression] error: ‘template JSC::FunctionPtr::FunctionPtr(returnType (*)())’ cannot be overloaded since r10-7998-g5f1cd1da1a805c3d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94946 Marek Polacek changed: What|Removed |Added Summary|[10/11 Regression] error: |[9/10/11 Regression] error: |‘template |‘template |JSC::FunctionPtr::FunctionP |JSC::FunctionPtr::FunctionP |tr(returnType (*)())’ |tr(returnType (*)())’ |cannot be overloaded since |cannot be overloaded since |r10-7998-g5f1cd1da1a805c3d |r10-7998-g5f1cd1da1a805c3d --- Comment #4 from Marek Polacek --- (In reply to Jakub Jelinek from comment #3) > Isn't 9 branch affected too? The r10-7998 change has been backported. It is.
[Bug c++/94946] [10/11 Regression] error: ‘template JSC::FunctionPtr::FunctionPtr(returnType (*)())’ cannot be overloaded since r10-7998-g5f1cd1da1a805c3d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94946 --- Comment #3 from Jakub Jelinek --- Isn't 9 branch affected too? The r10-7998 change has been backported.
[Bug target/93069] Assembler messages: Error: unsupported masking for `vextracti32x8'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93069 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #10 from Jakub Jelinek --- Fixed now.
[Bug target/93069] Assembler messages: Error: unsupported masking for `vextracti32x8'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93069
--- Comment #9 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:319eafce3e54c8cb10e3fddce6823a6a558fca8b
commit r11-147-g319eafce3e54c8cb10e3fddce6823a6a558fca8b
Author: Jakub Jelinek
Date: Wed May 6 20:05:02 2020 +0200
x86: Fix vextract* masked patterns [PR93069]
The AVX512F documentation clearly states that in instructions where the
destination is a memory only merging-masking is possible, not zero-masking,
and the assembler enforces that.
The testcase in this patch fails to assemble because of
Error: unsupported masking for `vextracti32x8'
on
vextracti32x8 $0x0, %zmm1, -64(%rsp){%k1}{z}
For the vector extraction patterns, we apparently have 7 *_maskm patterns
that only accept memory destinations and rtx_equal_p merge-masking source
for it, 7 * corresponding patterns that allow memory destination
only for the non-masked cases (through ), then 2
* patterns (lo ssehalf V16FI and lo ssehalf VI8F_256 ones) which
do allow memory destination even for masked cases and are the cause of the
testsuite failure, because we must not allow C constraint if the
destination
is m, and finally one pair of patterns (separate * and *_mask, hi ssehalf
VI4F_256), which has another issue (for which I don't have a testcase
though), where if it would match zero-masking with register destination,
it wouldn't emit the needed {z} into assembly.
The attached patch fixes those 3 issues only, perhaps more suitable for
backporting.
But, even with that fixed, we are missing 3 further *_maskm patterns and
more importantly, I find the split into 3 separate patterns after subst,
*_maskm for masking with memory destination, *_mask for masking with
register destination and * for non-masking unnecessarily complex and harder
for reload, so the included patch below (non-attached) instead kills all
*_maskm patterns and splits the * patterns into * and *_mask
by hand instead of subst, where the *_mask ones make sure that with v
destination they use 0C, while with m destination they use 0 and as
condition enforce that either destination is not MEM, or rtx_equal_p
between
the destination and corresponding merging-masking operand source.
If we had those 3 missing *_maskm patterns, this patch would actually
result
in both shorter sse.md and shorter machine description after subst (e.g.
length of tmp-mddump.md), as we don't have them, the patch is actually 16
lines longer sse.md, but still shorter tmp-mddump.md.
2020-05-06 Jakub Jelinek
PR target/93069
* config/i386/subst.md (store_mask_constraint,
store_mask_predicate):
Remove.
(avx512dq_vextract64x2_1_maskm,
avx512f_vextract32x4_1_maskm,
vec_extract_lo__maskm, vec_extract_hi__maskm): Remove.
(avx512dq_vextract64x2_1):
Split
into ...
(*avx512dq_vextract64x2_1,
avx512dq_vextract64x2_1_mask): ... these new
define_insns. Even in the masked variant allow memory output but
in
that case use 0 rather than 0C constraint on the source of
masked-out
elts.
(avx512f_vextract32x4_1):
Split
into ...
(*avx512f_vextract32x4_1,
avx512f_vextract32x4_1_mask): ... these new
define_insns.
Even in the masked variant allow memory output but in that case use
0 rather than 0C constraint on the source of masked-out elts.
(vec_extract_lo_): Split into ...
(vec_extract_lo_, vec_extract_lo__mask): ... these new
define_insns. Even in the masked variant allow memory output but
in
that case use 0 rather than 0C constraint on the source of
masked-out
elts.
(vec_extract_hi_): Split into ...
(vec_extract_hi_, vec_extract_hi__mask): ... these new
define_insns. Even in the masked variant allow memory output but
in
that case use 0 rather than 0C constraint on the source of
masked-out
elts.
[Bug c/94230] provide an option to change the size limitation for -Wmisleading-indent
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94230 --- Comment #9 from CVS Commits --- The master branch has been updated by Qing Zhao : https://gcc.gnu.org/g:530b44094354758d0dea5374188caa6863647114 commit r11-146-g530b44094354758d0dea5374188caa6863647114 Author: qing zhao Date: Wed May 6 10:46:09 2020 -0700 add a new option -flarge-source-files. gcc/ChangeLog: PR c/94230 * common.opt: Add -flarge-source-files. * doc/invoke.texi: Document it. * toplev.c (process_options): set line_table->default_range_bits to 0 when flag_large_source_files is true. gcc/c-family/ChangeLog: PR c/94230 * c-indentation.c (get_visual_column): Add a hint to use the new -flarge-source-files option. gcc/testsuite/ChangeLog: PR c/94230 * gcc.dg/plugin/location-overflow-test-1.c (fn_1): New message to provide hint to use the new -flarge-source-files option.
[Bug c++/94973] compile error when trying to use pointer-to-member function as invokable projection to ranges::find()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94973 --- Comment #17 from Jonathan Wakely --- They're on by default for mingw, for compatibility with the MS compiler (but in this case it seems the relevant extension is ancient history).
[Bug c++/94973] compile error when trying to use pointer-to-member function as invokable projection to ranges::find()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94973 --- Comment #16 from DB --- > -fno-ms-extensions will allow you to compile it, as long as you aren't > relying on any of the other MSVC compatibility quirks. That indeed fixes the problem, as well as squashing lots of other spurious warnings (some of which default to errors!) from libsigc++ in the same project that were Windows-specific. Thanks!
[Bug c++/94973] compile error when trying to use pointer-to-member function as invokable projection to ranges::find()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94973 --- Comment #15 from DB --- Aha, many thanks for the findings. IMO the MS extensions should really be off by default, esp if compiling in a Standard mode, until the user actually says they want them... right? They seem liable to lead to issues. And might explain lots of other weird warning spam I got earlier... (All I do special is pass -mwindows, just to avoid a spurious terminal)
[Bug c++/94973] compile error when trying to use pointer-to-member function as invokable projection to ranges::find()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94973 --- Comment #14 from Jonathan Wakely --- No (see PR 94771 comment 4)
[Bug c++/94973] compile error when trying to use pointer-to-member function as invokable projection to ranges::find()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94973 --- Comment #13 from Richard Biener --- Does MSVC still accept that [without diagnostic]? Maybe it's time to remove it completely...
[Bug c++/94973] compile error when trying to use pointer-to-member function as invokable projection to ranges::find()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94973 --- Comment #12 from Jonathan Wakely --- -fno-ms-extensions will allow you to compile it, as long as you aren't relying on any of the other MSVC compatibility quirks.
[Bug c++/94973] compile error when trying to use pointer-to-member function as invokable projection to ranges::find()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94973 Jonathan Wakely changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #11 from Jonathan Wakely --- Oops, CCing Jason this time.
[Bug c++/94973] compile error when trying to use pointer-to-member function as invokable projection to ranges::find()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94973 Jonathan Wakely changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=94771 --- Comment #10 from Jonathan Wakely --- Aha, the same problem happens on linux if I compile with -fms-extensions This is the old MS extension that causes x.*f to be accepted when f is a pointer to member function, which should only be valid when used as (x.*f)(). That causes ranges::invoke to think that the projection is a pointer to data member, when actually it's a pointer to member function. See also PR 94771 comment 4. Jason, do we want to disable that extension in SFINAE contexts?
[Bug middle-end/4210] should not warn in dead code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=4210 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #40 from Eric Gallager --- (In reply to Manuel López-Ibáñez from comment #39) > I think these questions are more appropriate for the mailing list, since > few people are subscribed to this bug. There were more previously, but a lot of people got dropped from cc lists all throughout bugzilla in the process of transferring servers... I was on this one previously, for example, but now I'm having to re-subscribe... > > You can easily find which pass does something by dumping (-ftree-dump-*) > all of them and comparing them. > > On Wed, 6 May 2020, 09:11 nisse at lysator dot liu.se, < > gcc-bugzi...@gcc.gnu.org> wrote: > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=4210 > > > > --- Comment #38 from Niels Möller --- > > Just a brief update. > > > > 1. Tried adding fprintf warnings to c_gimplify_expr (btw, what's the right > > way > > to display a pretty warning with line numbers etc in later passes?). But it > > seems that's too early, I still get warnings for dead code. > > > > 2. The pass_remove_useless_stmts, mentioned in the docs, was deleted in > > 2009 > > (see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41573), and I take it > > it was > > obsoleted earlier, since there's no mention of a replacement. So what pass > > should I look at that is related to basic control flow analysis, and > > discarding > > unreachable statements? > > > > -- > > You are receiving this mail because: > > You are on the CC list for the bug.
[Bug c++/94973] compile error when trying to use pointer-to-member function as invokable projection to ranges::find()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94973 --- Comment #9 from Jonathan Wakely --- If it used std::invoke it would compile: static_assert( std::is_same_v, int> );// OK static_assert( std::is_same_v, int> ); // ERROR
[Bug c++/94973] compile error when trying to use pointer-to-member function as invokable projection to ranges::find()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94973 --- Comment #8 from DB --- > I can reproduce it using x86_64-w64-mingw32-g++ 9.2.1 Thanks again for testing! > I'm not yet convinced this isn't a ranges-v3 bug. I will of course defer to your expertise! It could well be caused by something buried somewhere in range-v3's many layers of supporting code. If it can't be a g++ bug, of course just say the word, and I will just forward this all to them. > As it says on that page, "the first three of which can be obtained from the > output of gcc -v" D'oh. Here we are: $ g++ -v Using built-in specs. COLLECT_GCC=C:\msys64\mingw64\bin\g++.exe COLLECT_LTO_WRAPPER=C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.3.0/lto-wrapper.exe Target: x86_64-w64-mingw32 Configured with: ../gcc-9.3.0/configure --prefix=/mingw64 --with-local-prefix=/mingw64/local --build=x86_64-w64-mingw32 --host=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 --with-native-system-header-dir=/mingw64/x86_64-w64-mingw32/include --libexecdir=/mingw64/lib --enable-bootstrap --with-arch=x86-64 --with-tune=generic --enable-languages=c,lto,c++,fortran,ada,objc,obj-c++ --enable-shared --enable-static --enable-libatomic --enable-threads=posix --enable-graphite --enable-fully-dynamic-string --enable-libstdcxx-filesystem-ts=yes --enable-libstdcxx-time=yes --disable-libstdcxx-pch --disable-libstdcxx-debug --disable-isl-version-check --enable-lto --enable-libgomp --disable-multilib --enable-checking=release --disable-rpath --disable-win32-registry --disable-nls --disable-werror --disable-symvers --enable-plugin --with-libiconv --with-system-zlib --with-gmp=/mingw64 --with-mpfr=/mingw64 --with-mpc=/mingw64 --with-isl=/mingw64 --with-pkgversion='Rev2, Built by MSYS2 project' --with-bugurl=https://sourceforge.net/projects/msys2 --with-gnu-as --with-gnu-ld Thread model: posix gcc version 9.3.0 (Rev2, Built by MSYS2 project)
[Bug c++/94973] compile error when trying to use pointer-to-member function as invokable projection to ranges::find()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94973
--- Comment #7 from Jonathan Wakely ---
Further reduced:
#include
struct X { };
using F = int (X::*)() const;
using I = X*;
using R1 = ranges::invoke_result_t;
static_assert( std::is_same_v );
This fails because R1 is int (X::)() const which is nonsense.
(In reply to DB from comment #3)
> I chose libstdc++ because I figured it was more likely that some corner case
> of std::invoke() was ultimately being hit, rather than the core compiler
> being at fault. I guess not.
std::invoke is not even used, ranges-v3 provides its own invoke.
[Bug analyzer/94976] New: Oddities with -fanalyzer and -flto (SSA names leaking through)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94976
Bug ID: 94976
Summary: Oddities with -fanalyzer and -flto (SSA names leaking
through)
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: mark at gcc dot gnu.org
Target Milestone: ---
$ gcc --version
gcc (GCC) 10.0.1 20200430 (Red Hat 10.0.1-0.13)
This is the build of elfutils libelf with both -flto and -fanalyzer.
The report is correct. __elf64_getshdr_rdlock () can return NULL and we are
directly dereferencing the result without a NULL check.
The report could be a bit better though:
In function ‘elf_strptr’:
elf_strptr.c:148:11: warning: dereference of NULL ‘_67’ [CWE-690]
[-Wanalyzer-null-dereference]
148 | if (unlikely (shdr->sh_type != SHT_STRTAB))
| ^
‘elf_strptr’: events 1-14
|
| 73 | elf_strptr (Elf *elf, size_t idx, size_t offset)
| | ^
| | |
| | (1) entry to ‘elf_strptr’
| 74 | {
| 75 | if (elf == NULL)
| | ~
| | |
| | (2) following ‘false’ branch (when ‘elf_77(D)’ is
non-NULL)...
|..
| 78 | if (elf->kind != ELF_K_ELF)
| | ~ ~
| | | |
| | | (4) following ‘false’ branch...
| | (3) ...to here
|..
| 84 | rwlock_rdlock (elf->lock);
| | ~
| | |
| | (5) ...to here
|..
| 96 | if (idx < runp->max)
| | ~
| | |
| | (6) following ‘true’ branch...
| 97 | {
| 98 |if (idx < runp->cnt)
| |~ ~
| || |
| || (8) following ‘true’ branch...
| |(7) ...to here
| 99 | strscn = >data[idx];
| | ~
| | |
| | (9) ...to here
|..
| 119 | if (elf->class == ELFCLASS32)
| | ~
| | |
| | (10) following ‘false’ branch...
|..
| 147 | Elf64_Shdr *shdr = strscn->shdr.e64 ?:
__elf64_getshdr_rdlock (strscn);
| | ~~ ~
| | || |
| | || (13) ...to here
| | || (14) calling
‘__elf64_getshdr_rdlock’ from ‘elf_strptr’
| | (11) ...to here (12) following ‘false’
branch...
|
+--> ‘__elf64_getshdr_rdlock’: events 15-16
|
|elf32_getshdr.c:250:1:
| 250 | __elfw2(LIBELFBITS,getshdr_rdlock) (Elf_Scn *scn)
| | ^
| | |
| | (15) entry to ‘__elf64_getshdr_rdlock’
|..
| 254 | if (!scn_valid (scn))
| |~
| ||
| |(16) calling ‘scn_valid’ from
‘__elf64_getshdr_rdlock’
|
+--> ‘scn_valid’: events 17-22
|
| 228 | scn_valid (Elf_Scn *scn)
| | ^
| | |
| | (17) entry to ‘scn_valid’
| 229 | {
| 230 | if (scn == NULL)
| | ~
| | |
| | (18) following ‘false’ branch (when ‘scn_12(D)’
is non-NULL)...
|..
| 233 | if (unlikely (scn->elf->state.elf.ehdr == NULL))
| | ~ ~
| | | |
| | | (20) following ‘true’ branch...
| | (19) ...to here
| 234 | {
| 235 | __libelf_seterrno (ELF_E_WRONG_ORDER_EHDR);
| | ~
| | |
| | (21) ...to here
| | (22) calling ‘__libelf_seterrno’ from
‘scn_valid’
|
+--> ‘__libelf_seterrno’: events 23-25
|
|elf_error.c:334:1:
| 334 | __libelf_seterrno (int value)
| | ^
| | |
| | (23) entry to ‘__libelf_seterrno’
| 335 | {
| 336 | global_error = value >= 0 && value <
nmsgidx ? value : ELF_E_UNKNOWN_ERROR;
| |~
~
| ||
|
| |(25) ...to here
[Bug c++/94973] compile error when trying to use pointer-to-member function as invokable projection to ranges::find()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94973 --- Comment #6 from Jonathan Wakely --- (In reply to DB from comment #3) > I didn't build it. Is there a switch that can get this for you? As it says on that page, "the first three of which can be obtained from the output of gcc -v" But I can reproduce it now anyway.
[Bug c++/94973] compile error when trying to use pointer-to-member function as invokable projection to ranges::find()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94973
Jonathan Wakely changed:
What|Removed |Added
Component|libstdc++ |c++
Status|WAITING |NEW
Target||*-*-mingw*
Keywords||rejects-valid
--- Comment #5 from Jonathan Wakely ---
I can reproduce it using x86_64-w64-mingw32-g++ 9.2.1
Reduced:
#include
struct X {
int get_i() const { return 0; }
};
static_assert( ranges::indirectly_regular_unary_invocable );
Th static assert fails with mingw but not with a native compiler on linux.
I'm not yet convinced this isn't a ranges-v3 bug.
[Bug middle-end/94783] Abs-equivalent pattern is not recognized as abs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94783 Jakub Jelinek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #3 from Jakub Jelinek --- Created attachment 48471 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48471=edit gcc11-pr94783.patch Untested fix.
[Bug tree-optimization/94877] Failure to simplify ~(x + 1) to -2 - x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94877 --- Comment #4 from Uroš Bizjak --- (In reply to Jakub Jelinek from comment #3) > I'm not sure why this is considered a simplification, two insns vs. two, and > on the subtraction it isn't specific to just one target, but I think for > most the constant will need to be forced into register, the immediates the > instructions have is mostly for the second operand. Two ALU operations are merged into one, assuming that move is "free".
[Bug libstdc++/94973] compile error when trying to use pointer-to-member function as invokable projection to ranges::find()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94973 --- Comment #4 from DB --- Created attachment 48470 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48470=edit test.ii from --save-temps
[Bug libstdc++/94973] compile error when trying to use pointer-to-member function as invokable projection to ranges::find()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94973 --- Comment #3 from DB --- > Please read https://gcc.gnu.org/bugs and provide the missing information. Fair point. Let me know if I missed anything still. the exact version of GCC; g++.exe (Rev2, Built by MSYS2 project) 9.3.0 the system type; Windows, g++ provided by MSYS2/MinGW64 projects the options given when GCC was configured/built; I didn't build it. Is there a switch that can get this for you? the complete command line that triggers the bug; g++ -I /home/ME/.local/include/range-v3 -std=c++17 -Wall -Wextra -Wpedantic test.cpp the compiler output (error messages, warnings, etc.); already included. the preprocessed file (*.i*) that triggers the bug, generated by adding -save-temps to the complete compilation command I will attach this next. > Why is this marked as a libstdc++ bug? I chose libstdc++ because I figured it was more likely that some corner case of std::invoke() was ultimately being hit, rather than the core compiler being at fault. I guess not. > I can't reproduce this using range-v3 0.10.0 and GCC 9.3.0 on GNU/Linux, the > example compiles fine. Curioser and curioser. It's fine on clang++ on Windows too. Seems a corner case.
[Bug tree-optimization/94974] [11 regression] Many ICEs on power 7 after r11-59
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94974 Bill Seurer changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #1 from Bill Seurer --- Hmm, looks like this was already fixed.
[Bug libstdc++/94973] compile error when trying to use pointer-to-member function as invokable projection to ranges::find()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94973 --- Comment #2 from Jonathan Wakely --- I can't reproduce this using range-v3 0.10.0 and GCC 9.3.0 on GNU/Linux, the example compiles fine.
[Bug middle-end/4210] should not warn in dead code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=4210 --- Comment #39 from Manuel López-Ibáñez --- I think these questions are more appropriate for the mailing list, since few people are subscribed to this bug. You can easily find which pass does something by dumping (-ftree-dump-*) all of them and comparing them. On Wed, 6 May 2020, 09:11 nisse at lysator dot liu.se, < gcc-bugzi...@gcc.gnu.org> wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=4210 > > --- Comment #38 from Niels Möller --- > Just a brief update. > > 1. Tried adding fprintf warnings to c_gimplify_expr (btw, what's the right > way > to display a pretty warning with line numbers etc in later passes?). But it > seems that's too early, I still get warnings for dead code. > > 2. The pass_remove_useless_stmts, mentioned in the docs, was deleted in > 2009 > (see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41573), and I take it > it was > obsoleted earlier, since there's no mention of a replacement. So what pass > should I look at that is related to basic control flow analysis, and > discarding > unreachable statements? > > -- > You are receiving this mail because: > You are on the CC list for the bug.
[Bug tree-optimization/94913] Failure to optimize not+cmp into overflow check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94913 --- Comment #5 from CVS Commits --- The master branch has been updated by Uros Bizjak : https://gcc.gnu.org/g:7c2879301d3b027a1ba427a5d5c7557decb8a7ab commit r11-145-g7c2879301d3b027a1ba427a5d5c7557decb8a7ab Author: Uros Bizjak Date: Wed May 6 17:33:51 2020 +0200 i386: Use ADD to implement compares with negated operand [PR94913] Use carry flag from addition to implement GEU/LTU compares with negated operand, so e.g. ~x < y compiles to: addq%rsi, %rdi setc%al instead of: notq%rdi cmpq%rsi, %rdi setb%al PR target/94913 * config/i386/predicates.md (add_comparison_operator): New predicate. * config/i386/i386.md (compare->add splitter): New splitters. testsuite/ChangeLog: PR target/94913 * gcc.target/i386/pr94913-1.c: New test. * gcc.target/i386/pr94913-2.c: Ditto.
[Bug c/92472] enhancement: 5 * constify some parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92472 --- Comment #12 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #11) > (In reply to David Binderman from comment #10) > > I am still not sure if the new code is ok or not, > > Wasn't "This is 400% wrong" clear? Here's the error it caused: /home/jwakely/build/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/parallel/multiway_merge.h:273: error: no match for 'operator<' in '__seq2 < __seq0' (operand types are '__gnu_parallel::_GuardedIterator<__gnu_cxx::__normal_iterator >, std::less >' and '__gnu_parallel::_GuardedIterator<__gnu_cxx::__normal_iterator >, std::less >') /home/jwakely/build/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/parallel/multiway_merge.h:120: note: candidate: 'bool __gnu_parallel::operator<(__gnu_parallel::_GuardedIterator<__gnu_cxx::__normal_iterator >, std::less >&, __gnu_parallel::_GuardedIterator<__gnu_cxx::__normal_iterator >, const std::less >&)' /home/jwakely/build/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/parallel/multiway_merge.h:121: note: no known conversion for argument 2 from '__gnu_parallel::_GuardedIterator<__gnu_cxx::__normal_iterator >, std::less >' to '__gnu_parallel::_GuardedIterator<__gnu_cxx::__normal_iterator >, const std::less >&' And the reason it's wrong is that const Foo& and Foo& are completely different things. Your patch made *one* of the parameters Foo& (which is wrong because it's never called with anything matching that type) and left the other parameter unchanged (which is even more wrong, because now the operator can't be used to compare two objects of the same type). ( https://gcc.gnu.org/pipermail/gcc-patches/2020-May/545214.html
[Bug fortran/94975] Address sanitizations show heap-buffer-overflow with class(*) allocated to character on assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94975 --- Comment #1 from Vladimir Fuka --- It is probably discussed here https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83118 but that was not possible to find it by the search as the title is not directly related.
[Bug libstdc++/94973] compile error when trying to use pointer-to-member function as invokable projection to ranges::find()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94973 Jonathan Wakely changed: What|Removed |Added Last reconfirmed||2020-05-06 Ever confirmed|0 |1 Status|UNCONFIRMED |WAITING --- Comment #1 from Jonathan Wakely --- Please read https://gcc.gnu.org/bugs and provide the missing information. Why is this marked as a libstdc++ bug?
[Bug tree-optimization/94779] Bad optimization of simple switch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94779 --- Comment #11 from Jakub Jelinek --- Related PR is PR89059 though, while we can have a useful range info already in the early opts from evrp, in many cases we can get much better info after inlining. So, if we during the first switchconv pass could just perform analysis and stick on the gswitch info that e.g. the inlining cost computations could use and only perform lowering later, or if we could perform the conversion right away but in some way note for the second switchconv pass that this and this came from switch conversion and that if the range info is narrowed second switchconv pass should attempt to adjust it, it would be really appreciated.
[Bug c/92472] enhancement: 5 * constify some parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92472 --- Comment #11 from Jonathan Wakely --- (In reply to David Binderman from comment #10) > > It certainly has an effect on which member functions you can call on the > > parameter. > > Agreed, but does it matter ? These are a bunch of comparison > functions, they AFAIK shouldn't be changing the objects they are comparing. You're confused. It's irrelevant whether the comparison function changes anything, and that's not what cppcheck was complaining about anyway. It was talking about the parameters to operator< and you didn't change that in your patch. My comment was saying that *if* you had change what cppcheck was complaining about, it would have been wrong for a different reason (that you can't call operator* if the parameters are const). > I am still not sure if the new code is ok or not, Wasn't "This is 400% wrong" clear? > Suggest play safe and assume that JW is correct, so the proposed change to > file > multiway_merge.h should be removed. It already has been. > If this code is to die, should it be marked as unmaintained ? What does that mean?
[Bug gcov-profile/94928] Doc comments in gcov-io.h do not show cwd and unexec blocks in the Notes file format
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94928 --- Comment #12 from Myron Walker --- What would be helpful then is if gcno, gcda and source files could all have separate root file system prefixes.
[Bug fortran/94975] New: Address sanitizations show heap-buffer-overflow with class(*) allocated to character on assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94975 Bug ID: 94975 Summary: Address sanitizations show heap-buffer-overflow with class(*) allocated to character on assignment Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: vladimir.fuka at gmail dot com Target Milestone: --- With GCC 7-10 (bit libasan from 10) class(*), allocatable :: p p = "abc" select type(p) type is (character(*)) print *, p end select end causes > gfortran-10 star_character.f90 -fsanitize=address > ./a.out = ==12833==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60200071 at pc 0x7fa43e30e9b9 bp 0x7fffe526aa50 sp 0x7fffe526a200 WRITE of size 3 at 0x60200071 thread T0 #0 0x7fa43e30e9b8 in __interceptor_memmove (/usr/lib64/libasan.so.6+0x3b9b8) #1 0x400ddc in __copy_character_1.0 (/home/lada/f/testy/bugs/a.out+0x400ddc) #2 0x401078 in MAIN__ (/home/lada/f/testy/bugs/a.out+0x401078) #3 0x401305 in main (/home/lada/f/testy/bugs/a.out+0x401305) #4 0x7fa43d2f0349 in __libc_start_main (/lib64/libc.so.6+0x24349) #5 0x400c99 in _start (/home/lada/f/testy/bugs/a.out+0x400c99) 0x60200071 is located 0 bytes to the right of 1-byte region [0x60200070,0x60200071) allocated by thread T0 here: #0 0x7fa43e37f3df in malloc (/usr/lib64/libasan.so.6+0xac3df) #1 0x400fca in MAIN__ (/home/lada/f/testy/bugs/a.out+0x400fca) #2 0x401305 in main (/home/lada/f/testy/bugs/a.out+0x401305) #3 0x7fa43d2f0349 in __libc_start_main (/lib64/libc.so.6+0x24349) SUMMARY: AddressSanitizer: heap-buffer-overflow (/usr/lib64/libasan.so.6+0x3b9b8) in __interceptor_memmove Shadow bytes around the buggy address: 0x0c047fff7fb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c047fff7fc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c047fff7fd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c047fff7fe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c047fff7ff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 =>0x0c047fff8000: fa fa 06 fa fa fa 07 fa fa fa 07 fa fa fa[01]fa 0x0c047fff8010: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c047fff8020: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c047fff8030: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c047fff8040: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c047fff8050: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user:f7 Container overflow: fc Array cookie:ac Intra object redzone:bb ASan internal: fe Left alloca redzone: ca Right alloca redzone:cb Shadow gap: cc ==12833==ABORTING while class(*), allocatable :: p allocate(p, source = "abc") select type(p) type is (character(*)) print *, p end select end is clean and prints "abc". That is also written with the former without address sanitizations. Tested on OpenSuSE Leap 15.1.
[Bug tree-optimization/94974] New: [11 regression] Many ICEs on power 7 after r11-59
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94974 Bug ID: 94974 Summary: [11 regression] Many ICEs on power 7 after r11-59 Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: seurer at linux dot vnet.ibm.com Target Milestone: --- This only happens on power 7 BE. Didn't see it on power 8 BE. this run: g:308bc496884706af4b3077171cbac684c7a6f7c6, r11-59: 127 failures FAIL: gcc.c-torture/execute/pr65369.c -O3 -g (internal compiler error) FAIL: gcc.c-torture/execute/pr65369.c -O3 -g (test for excess errors) FAIL: gcc.dg/torture/pr93428.c -O1 (internal compiler error) FAIL: gcc.dg/torture/pr93428.c -O1 (test for excess errors) FAIL: gcc.dg/torture/pr93428.c -O2 (internal compiler error) FAIL: gcc.dg/torture/pr93428.c -O2 (test for excess errors) FAIL: gcc.dg/torture/pr93428.c -O2 -flto -fno-use-linker-plugin -flto-partition=none (internal compiler error) FAIL: gcc.dg/torture/pr93428.c -O2 -flto -fno-use-linker-plugin -flto-partition=none (test for excess errors) FAIL: gcc.dg/torture/pr93428.c -O3 -g (internal compiler error) FAIL: gcc.dg/torture/pr93428.c -O3 -g (test for excess errors) FAIL: gcc.dg/torture/pr93428.c -Os (internal compiler error) FAIL: gcc.dg/torture/pr93428.c -Os (test for excess errors) FAIL: gcc.dg/vect/bb-slp-29.c -flto -ffat-lto-objects (internal compiler error) FAIL: gcc.dg/vect/bb-slp-29.c -flto -ffat-lto-objects (test for excess errors) FAIL: gcc.dg/vect/bb-slp-9.c (internal compiler error) FAIL: gcc.dg/vect/bb-slp-9.c (test for excess errors) FAIL: gcc.dg/vect/bb-slp-9.c -flto -ffat-lto-objects scan-tree-dump-times slp2 "basic block vectorized" 1 FAIL: gcc.dg/vect/bb-slp-9.c -flto -ffat-lto-objects (internal compiler error) FAIL: gcc.dg/vect/bb-slp-9.c -flto -ffat-lto-objects (test for excess errors) FAIL: gcc.dg/vect/bb-slp-9.c scan-tree-dump-times slp2 "basic block vectorized" 1 FAIL: gcc.dg/vect/costmodel/ppc/costmodel-bb-slp-9a.c (internal compiler error) FAIL: gcc.dg/vect/costmodel/ppc/costmodel-bb-slp-9a.c (test for excess errors) FAIL: gcc.dg/vect/costmodel/ppc/costmodel-bb-slp-9a.c scan-tree-dump-times slp2 "basic block vectorized" 1 FAIL: gcc.dg/vect/slp-43.c (internal compiler error) FAIL: gcc.dg/vect/slp-43.c (test for excess errors) FAIL: gcc.dg/vect/slp-43.c -flto -ffat-lto-objects (internal compiler error) FAIL: gcc.dg/vect/slp-43.c -flto -ffat-lto-objects (test for excess errors) FAIL: gfortran.dg/aliasing_dummy_4.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions (internal compiler error) FAIL: gfortran.dg/aliasing_dummy_4.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions (test for excess errors) FAIL: gfortran.dg/aliasing_dummy_4.f90 -O3 -g (internal compiler error) FAIL: gfortran.dg/aliasing_dummy_4.f90 -O3 -g (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_2.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions (internal compiler error) FAIL: gfortran.dg/alloc_comp_assign_2.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_2.f90 -O3 -g (internal compiler error) FAIL: gfortran.dg/alloc_comp_assign_2.f90 -O3 -g (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_4.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions (internal compiler error) FAIL: gfortran.dg/alloc_comp_assign_4.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions (test for excess errors) FAIL: gfortran.dg/alloc_comp_assign_4.f90 -O3 -g (internal compiler error) FAIL: gfortran.dg/alloc_comp_assign_4.f90 -O3 -g (test for excess errors) FAIL: gfortran.dg/inline_transpose_1.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions (internal compiler error) FAIL: gfortran.dg/inline_transpose_1.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions (test for excess errors) FAIL: gfortran.dg/inline_transpose_1.f90 -O3 -g (internal compiler error) FAIL: gfortran.dg/inline_transpose_1.f90 -O3 -g (test for excess errors) FAIL: gfortran.dg/pr55086_aliasing_dummy_4_tfat.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions (internal compiler error) FAIL: gfortran.dg/pr55086_aliasing_dummy_4_tfat.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions (test for excess errors) FAIL: gfortran.dg/pr55086_aliasing_dummy_4_tfat.f90 -O3 -g (internal compiler error) FAIL: gfortran.dg/pr55086_aliasing_dummy_4_tfat.f90 -O3 -g (test for excess errors) FAIL: gfortran.dg/transfer_array_intrinsic_2.f90 -O3
[Bug tree-optimization/94779] Bad optimization of simple switch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94779 Martin Liška changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #10 from Martin Liška --- (In reply to Jakub Jelinek from comment #9) > Martin, I think switchconv pass should use get_range_info and completely > ignore labels with values outside of the range of the switch SSA_NAME range > (including the default label if all values in the SSA_NAME range have > explicit case labels). > That wouldn't change everything in this report, e.g. the #c0 one I think > doesn't even make switchconv as it is lowered earlier. Good point, I'll work on that!
[Bug c/92472] enhancement: 5 * constify some parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92472 --- Comment #10 from David Binderman --- (In reply to Jonathan Wakely from comment #9) > Or in other words, of course whether a parameter can be const is separate > from whether a member function can be const. Agreed. > But that doesn't mean that changing a parameter from non-const to const > can't have any effect. Double negative, but I think I know what you mean. > It certainly has an effect on which member functions you can call on the > parameter. Agreed, but does it matter ? These are a bunch of comparison functions, they AFAIK shouldn't be changing the objects they are comparing. I am still not sure if the new code is ok or not, and by now, TBH not bothered either way. I gave up on C++ because of its ever growing complexity. This is another example. Suggest play safe and assume that JW is correct, so the proposed change to file multiway_merge.h should be removed. If this code is to die, should it be marked as unmaintained ?
[Bug tree-optimization/94779] Bad optimization of simple switch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94779 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #9 from Jakub Jelinek --- Martin, I think switchconv pass should use get_range_info and completely ignore labels with values outside of the range of the switch SSA_NAME range (including the default label if all values in the SSA_NAME range have explicit case labels). That wouldn't change everything in this report, e.g. the #c0 one I think doesn't even make switchconv as it is lowered earlier.
[Bug libstdc++/94973] New: compile error when trying to use pointer-to-member function as invokable projection to ranges::find()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94973
Bug ID: 94973
Summary: compile error when trying to use pointer-to-member
function as invokable projection to ranges::find()
Product: gcc
Version: 9.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: db0451 at gmail dot com
Target Milestone: ---
`range-v3` has the concept of "invocable projections", i.e. simple
transformations that can be applied as predicates to its algorithms.
Pointer-to-member-functions should be included and mean 'get the result of
calling that on the current element'. However, it seems that invoking a
pointer-to-member-function in g++ (but NOT clang++) causes the build to fail.
Given the code, compiled with `g++ -std=c++17` against `ericniebler/range-v3`
release `range-v3-0.10.0`, using `g++.exe (Rev2, Built by MSYS2 project)
9.3.0`:
```cpp
#include
#include
auto
main() -> int
{
struct S {
int i{};
auto get_i() const { return i; }
};
auto const ss = std::vector(10);
ranges::find(ss, 1, ::get_i);
return 0;
}
```
I get a spew of errors:
```none
test.cpp: In function 'int main()':
test.cpp:14:31: error: no match for call to '(const ranges::find_fn) (const
std::vector&, int, int (main()::S::*)() const)'
14 | ranges::find(ss, 1, ::get_i);
| ^
In file included from FOO/include/range-v3/range/v3/range_fwd.hpp:24,
from FOO/include/range-v3/range/v3/algorithm/find.hpp:18,
from test.cpp:1:
FOO/include/range-v3/range/v3/detail/config.hpp:618:27: note: candidate:
'template constexpr concepts::return_t && sentinel_for) &&
indirect_relation::apply, const V*>) &&
concepts::detail::CPP_true(concepts::detail::Nil{})), void>::type>
ranges::find_fn::operator()(I, S, const V&, P) const'
618 | #define RANGES_FUNC(NAME) operator() RANGES_FUNC_CONST_ /**/
| ^~~~
FOO/include/range-v3/range/v3/algorithm/find.hpp:47:24: note: in expansion of
macro 'RANGES_FUNC'
47 | constexpr auto RANGES_FUNC(find)(I first, S last, V const &
val, P proj = P{})
|^~~
FOO/include/range-v3/range/v3/detail/config.hpp:618:27: note: template
argument deduction/substitution failed:
618 | #define RANGES_FUNC(NAME) operator() RANGES_FUNC_CONST_ /**/
| ^~~~
FOO/include/range-v3/range/v3/algorithm/find.hpp:47:24: note: in expansion of
macro 'RANGES_FUNC'
47 | constexpr auto RANGES_FUNC(find)(I first, S last, V const &
val, P proj = P{})
|^~~
In file included from FOO/include/range-v3/range/v3/iterator/access.hpp:22,
from FOO/include/range-v3/range/v3/iterator/concepts.hpp:30,
from FOO/include/range-v3/range/v3/algorithm/find.hpp:22,
from test.cpp:1:
FOO/include/range-v3/std/detail/associated_types.hpp: In substitution of
'template using enable_if_t = typename
ranges::detail::enable_if::apply [with bool B =
ranges::readable >; T = std::vector]':
FOO/include/range-v3/range/v3/iterator/concepts.hpp:561:19: required by
substitution of 'template using apply =
ranges::detail::enable_if_t<(bool)(readable), I> [with I =
std::vector]'
FOO/include/range-v3/range/v3/algorithm/find.hpp:48:15: required by
substitution of 'template constexpr
concepts::return_t &&
sentinel_for) && indirect_relation::apply, const V*>) &&
concepts::detail::CPP_true(concepts::detail::Nil{})), void>::type>
ranges::find_fn::operator()(I, S, const V&, P) const [with I =
std::vector; S = int; V = int (main()::S::*)() const; P =
ranges::identity]'
test.cpp:14:31: required from here
FOO/include/range-v3/std/detail/associated_types.hpp:73:15: error: no class
template named 'apply' in 'struct ranges::detail::enable_if'
73 | using enable_if_t = typename enable_if::template apply;
| ^~~
In file included from FOO/include/range-v3/range/v3/range_fwd.hpp:24,
from FOO/include/range-v3/range/v3/algorithm/find.hpp:18,
from test.cpp:1:
FOO/include/range-v3/range/v3/detail/config.hpp:618:27: note: candidate:
'template constexpr concepts::return_t >::apply())), ranges::dangling>, typename
std::enable_if<((input_range && indirect_relation::apply()))>, const V*>) &&
concepts::detail::CPP_true(concepts::detail::Nil{})), void>::type>
ranges::find_fn::operator()(Rng&&, const V&, P) const'
618 | #define RANGES_FUNC(NAME) operator() RANGES_FUNC_CONST_ /**/
| ^~~~
FOO/include/range-v3/range/v3/algorithm/find.hpp:60:24: note: in expansion of
macro 'RANGES_FUNC'
60 | constexpr auto RANGES_FUNC(find)(Rng && rng, V const & val, P
proj = P{})
|
[Bug gcov-profile/94928] Doc comments in gcov-io.h do not show cwd and unexec blocks in the Notes file format
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94928 --- Comment #11 from Myron Walker --- Ok. I'll look into it On Wed, May 6, 2020, 7:25 AM marxin at gcc dot gnu.org < gcc-bugzi...@gcc.gnu.org> wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94928 > > --- Comment #10 from Martin Liška --- > (In reply to Myron Walker from comment #9) > > How you I process data files from multiple sources and multiple runs with > > gcov. > > $ man gcov-tool > > $ gcov-tool merge [merge-options] directory1 directory2 > > So you basically take 2 folders of 2 runs and merge them into a destination > one. > The folders are traversed for .gcda files and corresponding files are > merged. > Having N runs, you need to run log2(N) merge operations. > > -- > You are receiving this mail because: > You reported the bug.
[Bug tree-optimization/94877] Failure to simplify ~(x + 1) to -2 - x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94877 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- I'm not sure why this is considered a simplification, two insns vs. two, and on the subtraction it isn't specific to just one target, but I think for most the constant will need to be forced into register, the immediates the instructions have is mostly for the second operand.
[Bug target/94934] Failure to inline addv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94934 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Yeah, -ftrapv should just be reimplemented using the ubsan/__builtin_*_overflow internal functions or perhaps killed altogether, one can use -fsanitize=signed-integer-overflow -fsanitize-undefined-trap-on-error instead.
[Bug target/94972] Function multi-versioning binary may crash dynamic linker
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94972 Martin Liška changed: What|Removed |Added Last reconfirmed||2020-05-06 Status|UNCONFIRMED |WAITING CC||jakub at gcc dot gnu.org, ||jwakely.gcc at gmail dot com, ||marxin at gcc dot gnu.org, ||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Can't reproduce that on openSUSE Tumbleweed with: marxin@marxinbox:~/Programming/testcases> g++ -v Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/usr/lib64/gcc/x86_64-suse-linux/9/lto-wrapper OFFLOAD_TARGET_NAMES=hsa:nvptx-none 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 --enable-offload-targets=hsa,nvptx-none=/usr/nvptx-none, --without-cuda-driver --disable-werror --with-gxx-include-dir=/usr/include/c++/9 --enable-ssp --disable-libssp --disable-libvtv --disable-cet --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=-9 --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 gcc version 9.3.1 20200406 [revision 6db837a5288ee3ca5ec504fbd5a765817e556ac2] (SUSE Linux) marxin@marxinbox:~/Programming/testcases> ldd --version ldd (GNU libc) 2.31 Copyright (C) 2020 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Written by Roland McGrath and Ulrich Drepper. I'm adding RedHat guys to CC.
[Bug c++/94953] A lot of false maybe-uninitialized warnings with O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94953 --- Comment #2 from Olaf Krzikalla --- Created attachment 48469 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48469=edit Test case code triggering the warning
[Bug c++/94967] std::get<0>(tuple const &&) returns wrong type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94967 --- Comment #2 from Rene Rahn --- Oh, thanks for clarifying this. Best regards
[Bug fortran/92736] [9/10/11 Regression] Error when using a variable from a module in a submodule and its parent module.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92736 markeggleston at gcc dot gnu.org changed: What|Removed |Added CC||markeggleston at gcc dot gnu.org --- Comment #8 from markeggleston at gcc dot gnu.org --- This was fixed by Tobias: https://gcc.gnu.org/g:36c3edb1e39c74e2705efac738a389b5597d9d88 As PR fortran/92736 was not used in the body of the commit message (or ChangeLog files) this PR was not automatically updated with the commit info. I'm not precisely sure of the mechanism used to automatically add the commit info to a PR but preceding change log entries with PR / (both in the commit message and the ChangeLog files) has worked for me. When I've omitted PR / it has not worked. Just needs backporting to gcc-9.
[Bug gcov-profile/94928] Doc comments in gcov-io.h do not show cwd and unexec blocks in the Notes file format
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94928 --- Comment #10 from Martin Liška --- (In reply to Myron Walker from comment #9) > How you I process data files from multiple sources and multiple runs with > gcov. $ man gcov-tool $ gcov-tool merge [merge-options] directory1 directory2 So you basically take 2 folders of 2 runs and merge them into a destination one. The folders are traversed for .gcda files and corresponding files are merged. Having N runs, you need to run log2(N) merge operations.
[Bug gcov-profile/94928] Doc comments in gcov-io.h do not show cwd and unexec blocks in the Notes file format
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94928 --- Comment #9 from Myron Walker --- How you I process data files from multiple sources and multiple runs with gcov.
[Bug c/92472] enhancement: 5 * constify some parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92472 --- Comment #9 from Jonathan Wakely --- Or in other words, of course whether a parameter can be const is separate from whether a member function can be const. But that doesn't mean that changing a parameter from non-const to const can't have any effect. It certainly has an effect on which member functions you can call on the parameter.
[Bug gcov-profile/94928] Doc comments in gcov-io.h do not show cwd and unexec blocks in the Notes file format
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94928 --- Comment #8 from Martin Liška --- Or even better: you can merge various .gcda files with: gcov-tool merge ... https://gcc.gnu.org/onlinedocs/gcc/Gcov-tool-Intro.html
[Bug c/92472] enhancement: 5 * constify some parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92472
--- Comment #8 from Jonathan Wakely ---
(In reply to David Binderman from comment #7)
> (In reply to Jonathan Wakely from comment #6)
> > Those parameter can NOT be const, because *__b1 and *__b2 will not
> > compile if they're const, because operator* is not const.
>
> My understanding of C++, frayed somewhat since 1988, is that operator *
> being const is a different language feature to parameters being const.
The function looks like this:
friend bool
operator<(const _UnguardedIterator<_RAIter, _Compare>& __bi1,
const _UnguardedIterator<_RAIter, _Compare>& __bi2)
{
// Normal compare.
return (__bi1.__comp)(*__bi1, *__bi2);
}
i.e. it uses *__b1 which uses _UnguardedIterator::operator*
If you change __b1 to be const, you can't call non-const member functions on
that object, including _UnguardedIterator::operator*
> Any guidance on fixing this problem, if it is a problem at all,
> would be most welcome.
It's not a problem. The code should be left alone to die in peace.
[Bug gcov-profile/94928] Doc comments in gcov-io.h do not show cwd and unexec blocks in the Notes file format
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94928 --- Comment #7 from Martin Liška --- (In reply to Myron Walker from comment #6) > I use the gcno file to build a the graph, pull counters from the gcda files > and then solve the graph for the missing counts. That's what gcov does itself. > I am merging the data from > multiple gcda sources. Multiple nodes running the same software. I would recommend writing a simple merging tool on top of the JSON files. That will save you a lot of time.
[Bug gcov-profile/94928] Doc comments in gcov-io.h do not show cwd and unexec blocks in the Notes file format
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94928 --- Comment #6 from Myron Walker --- I use the gcno file to build a the graph, pull counters from the gcda files and then solve the graph for the missing counts. I am merging the data from multiple gcda sources. Multiple nodes running the same software.
[Bug lto/48200] Implement function attribute for symbol versioning (.symver)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48200 --- Comment #44 from Jan Hubicka --- Thanks, I am happy we now have real-world use of symver attribute. I have WIP patch for better control over the symbol visibility, but I have run into problems with gas limitations which was fixed by HJ about two weeks ago. I will try to update the patch and aim for backporting to gcc 10.2.
[Bug gcov-profile/94928] Doc comments in gcov-io.h do not show cwd and unexec blocks in the Notes file format
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94928 --- Comment #5 from Martin Liška --- (In reply to Myron Walker from comment #4) > A python tool that can do distributed code coverage analysis. Gcda files > from cluster nodes from a web interface, gcno from a web interface or file > share in a build archive, and source directly from github. Can you please use gcov --json-format: https://gcc.gnu.org/onlinedocs/gcc/Invoking-Gcov.html#Invoking-Gcov ? What kind of information do you need to get from these files? Is it about finding a corresponding files?
[Bug target/94972] New: Function multi-versioning binary may crash dynamic linker
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94972 Bug ID: 94972 Summary: Function multi-versioning binary may crash dynamic linker Product: gcc Version: 9.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: d at ilvokhin dot com Target Milestone: --- Created attachment 48468 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48468=edit Simplified version of function multi-versioning example I compiled simple binary (a simplified version of function multi-versioning example from gcc.gnu.org) and do ldd -u -r on result. This leads to ldd segfault in __cpu_indicator_init from libgcc_s.so. Behaviour is observed at least for GCC 9.1.1 and 7.3.1 (both from Red Hat devtoolset). $ g++ --version g++ (GCC) 9.1.1 20190605 (Red Hat 9.1.1-2) Copyright (C) 2019 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ g++ tt.cpp -o cpp $ ldd -u -r ./cpp /usr/bin/ldd: line 116: 6148 Segmentation fault (core dumped) LD_TRACE_LOADED_OBJECTS=1 LD_WARN=yes LD_BIND_NOW=yes LD_LIBRARY_VERSION=$verify_out LD_VERBOSE= LD_DEBUG="unused" "$@ Backtrace is looks like that: (gdb) bt #0 0x7efccf094c87 in __cpu_indicator_init () from /lib64/libgcc_s.so.1 #1 0x00401178 in ?? () #2 0x7fff5f97e220 in ?? () #3 0x7efccf8bce5f in _dl_relocate_object () from /lib64/ld-linux-x86-64.so.2 (gdb) disass Dump of assembler code for function __cpu_indicator_init: 0x7efccf094c70 <+0>: push %r15 0x7efccf094c72 <+2>: push %r14 0x7efccf094c74 <+4>: push %r13 0x7efccf094c76 <+6>: push %r12 0x7efccf094c78 <+8>: push %rbp 0x7efccf094c79 <+9>: xor%ebp,%ebp 0x7efccf094c7b <+11>:push %rbx 0x7efccf094c7c <+12>:sub$0x18,%rsp 0x7efccf094c80 <+16>:mov0x212351(%rip),%rax# 0x7efccf2a6fd8 => 0x7efccf094c87 <+23>:mov(%rax),%eax 0x7efccf094c89 <+25>:test %eax,%eax
[Bug gcov-profile/94928] Doc comments in gcov-io.h do not show cwd and unexec blocks in the Notes file format
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94928 --- Comment #4 from Myron Walker --- A python tool that can do distributed code coverage analysis. Gcda files from cluster nodes from a web interface, gcno from a web interface or file share in a build archive, and source directly from github.
[Bug tree-optimization/94913] Failure to optimize not+cmp into overflow check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94913 --- Comment #4 from Jakub Jelinek --- Created attachment 48467 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48467=edit gcc11-pr94913.patch Untested fix for that part.
[Bug gcov-profile/94928] Doc comments in gcov-io.h do not show cwd and unexec blocks in the Notes file format
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94928 --- Comment #3 from Martin Liška --- (In reply to Myron Walker from comment #2) > I am parsinv both gcno and gcda files. These files are not intended to be parsed :/ Can you please describe your use-case?
[Bug d/94970] d: internal compiler error: in verify_gimple_stmt, at tree-cfg.c:4959
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94970
--- Comment #4 from Iain Buclaw ---
(In reply to Iain Buclaw from comment #3)
> Somewhat simplified reduction of test that doesn't depend on operator
> overloading.
>
> struct RegexMatch
> {
> string index() { return null; }
> ~this() { }
> }
> auto m() { return RegexMatch(); }
>
> void initCommands()
> {
> auto a = m.index() ~ ' ';
> }
There are two places that create a BIND_EXPR in the D front end, first in
CatExp, the other in NewExp.
The ICE would also happen there as well, and indeed, it does if the
initialization is replaced with.
auto a = new int[](m.index);
[Bug fortran/91726] [8/9 Regression] ICE in gfc_conv_array_ref, at fortran/trans-array.c:3612
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91726 José Rui Faustino de Sousa changed: What|Removed |Added CC||jrfsousa at gmail dot com --- Comment #7 from José Rui Faustino de Sousa --- Hi all! Still ICEs with 9/10/11 using -ftrapv -fcheck=bounds Best regards, José Rui
[Bug gcov-profile/94928] Doc comments in gcov-io.h do not show cwd and unexec blocks in the Notes file format
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94928 --- Comment #2 from Myron Walker --- I am parsinv both gcno and gcda files.
[Bug fortran/93833] [8/9/10/11 Regression] ICE in trans_array_constructor, at fortran/trans-array.c:2566
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93833 markeggleston at gcc dot gnu.org changed: What|Removed |Added CC||markeggleston at gcc dot gnu.org --- Comment #8 from markeggleston at gcc dot gnu.org --- As noted by Tobias: Patch was submitted at https://gcc.gnu.org/pipermail/fortran/2020-March/054072.html but the new mailing had stripped off the 'text/x-patch' MIME type back then. Is the patch going to be resubmitted?
[Bug d/94970] d: internal compiler error: in verify_gimple_stmt, at tree-cfg.c:4959
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94970
--- Comment #3 from Iain Buclaw ---
Somewhat simplified reduction of test that doesn't depend on operator
overloading.
struct RegexMatch
{
string index() { return null; }
~this() { }
}
auto m() { return RegexMatch(); }
void initCommands()
{
auto a = m.index() ~ ' ';
}
[Bug c++/94960] extern template prevents inlining of standard library objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94960 --- Comment #6 from Erich Keane --- (In reply to Jonathan Wakely from comment #5) > (In reply to Erich Keane from comment #3) > > As you know, "extern template" is a hint to the compiler that we don't need > > to emit the template as a way to save on compile time. > > > > Both GCC and clang will NOT instantiate these templates in O0 mode. > > However, in O1+ modes, both will actually still instantiate the templates in > > the frontend, BUT only for 'inline' functions. Basically, we're using > > 'inline' as a heuristic that there is benefit in sending these functions to > > the optimizer (basically, sacrificing the compile time gained by 'extern > > template' in exchange for a better inlining experience). > > Hmm, I've seen different behaviours for clang and g++ in this respect, with > clang inlining a lot more of std::string's members. So I'm surprised they > use the same heuristic. > > Do they both instantiate the function templates marked 'inline' even at -O1? > Presumably not at -O0. My understanding of Clang is based on a brief debugging session. My understanding of GCC's behavior here is a brief amount of time messing around on godbolt. I could very well be incorrect. > > > In the submitter's case, the std::string constructor calls "_M_construct". > > The constructor is inlined, but _M_construct is not, since it never gets to > > the optimizer. > > > > libc++ uses an __init function to do the same thing as _M_construct, however > > IT is marked inline, and thus doesn't have the problem. > > > > I believe the submitter wants to have you mark more of the functions in > > extern-templated classes 'inline' so that it matches the heuristic better. > > And that's what I don't want to do. I think it's wrong for the human to say > "inline this!" because humans are stupid (well, I am anyway). And I don't > want to have to examine the GIMPLE/asm again for every new GCC release to > decide whether 'inline' is still in the right places (and whether the answer > should be different for every different version of Clang or ICC!) > > And when I say "I don't want to" I mean "I am never ever going to". > > > I don't think that there is a good way to change the compiler itself without > > making 'extern template' absolutely meaningless. > > I absolutely disagree. > > It would still give a reduction in object file size for cases where the > compiler decides not to inline, and still make compilation much faster for > -O0 and -O1. That is fair, I guess it would slightly reduce 'link' time because of that. I doubt people would be willing to put up with the STL compiling that much slower though (which seems to be the major user of this feature in my experience). > One property of -O2 and -O3 is that we try to optimize aggressively even if > that takes a long time to compile. So we could instantiate things that have > an explicit instantiation declaration (thus doing "redundant" work) to see > if inlining them would be beneficial. That would take longer to compile, but > might produce faster code. If the heuristics decide the instantiation ends > up too big to inline, it could just discard it (because we know there's a > definition elsewhere). That is essentially what the frontends DO, except only with the 'inline' functions. If the inliner chooses to not inline it, it gets thrown out (since we've marked it 'available externally'). > If the only way to get that is to mark every function as 'inline' (and then > "trick" the compiler into doing all that extra work even at -O1?) then we > might as well add 'inline' to every single function template in and > , , etc. so they're all potential candiates > for inlining. > > And if we have to mark every single function as 'inline' then maybe the > compiler shouldn't be using it as a hint. I don't think the idea is to mark EVERY function 'inline', simply ones that are pretty tiny and really good candidates for inlining.
[Bug d/94970] d: internal compiler error: in verify_gimple_stmt, at tree-cfg.c:4959
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94970
--- Comment #2 from Iain Buclaw ---
Because RegexMatch needs destruction, a temporary is created that requires
scope destruction. The temporary is wrapped in a TARGET_EXPR, and dtor call
set in TARGET_EXPR_CLEANUP.
TARGET_EXPR
A clean-up point is then created around the initialization of 'a'.
<>
The problem is that for the array concat expression on the RHS, a BIND_EXPR is
set-up for a temporary created for the character literal (its address needs to
be taken).
The routine gimplify_cleanup_point_expr does not look any lower than the first
level of sequences in the body, so it completely misses the
GIMPLE_WITH_CLEANUP_EXPRs in the following:
{
const char D.4043;
try
{
D.4043 = 32;
D.4110.length = 1;
D.4110.ptr =
__tmpfordtor57 = m (); [return slot optimization]
<<< Unknown GIMPLE statement: gimple_with_cleanup_expr >>>
<<< Unknown GIMPLE statement: gimple_with_cleanup_expr >>>
D.4111 = index (&__tmpfordtor57);
D.4112 = _d_arraycatT (&_D12TypeInfo_Aya6__initZ, D.4111, D.4110);
retval.0 = VIEW_CONVERT_EXPR(D.4112);
}
finally
{
D.4043 = {CLOBBER};
}
}
retval.1 = retval.0;
a = retval.1;
There is a note above gimplify_cleanup_point_expr:
FIXME should we complexify the prequeue handling instead? Or use flags
for all the cleanups and let the optimizer tighten them up? The current
code seems pretty fragile; it will break on a cleanup within any
non-conditional nesting. But any such nesting would be broken, anyway;
we can't write a TRY_FINALLY_EXPR that starts inside a nesting construct
and continues out of it. We can do that at the RTL level, though, so
having an optimizer to tighten up try/finally regions would be a Good
Thing.
[Bug target/94865] Failure to combine unpckhpd+unpcklpd into blendps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94865
--- Comment #2 from Richard Biener ---
Missing match.pd patterns also include a no-op comb of insertion of an
extracted element at the same position
(simplify
(bit_insert @0 (BIT_FIELD_REF @0 @size @pos) @pos)
(if (size matches)
@0)
in addition to the requested
(simplify
(bit_insert @0 (BIT_FIELD_REF @1 @rsize @rpos) @ipos)
(if (@0 and @1 are vectors compatible for a vec_perm)
(vec_perm @0 @1 { shuffle-mask }))
[Bug rtl-optimization/94873] [8/9/10 Regression] wrong code with -O -fno-merge-constants -fno-split-wide-types -fno-tree-fre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94873 Jakub Jelinek changed: What|Removed |Added Summary|[8/9/10/11 Regression] |[8/9/10 Regression] wrong |wrong code with -O |code with -O |-fno-merge-constants|-fno-merge-constants |-fno-split-wide-types |-fno-split-wide-types |-fno-tree-fre |-fno-tree-fre --- Comment #21 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug target/94950] [8/9/10 regression] ICE in gcc.dg/pr94780.c on riscv64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94950 Jakub Jelinek changed: What|Removed |Added Summary|[8/9/10/11 regression] ICE |[8/9/10 regression] ICE in |in gcc.dg/pr94780.c on |gcc.dg/pr94780.c on riscv64 |riscv64 | --- Comment #4 from Jakub Jelinek --- Should be fixed on the trunk so far.
[Bug tree-optimization/94964] [8/9/10 Regression] ICE in add_phi_arg, at tree-phinodes.c:359 since r8-2993-ga7976089dba5e227
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94964 Richard Biener changed: What|Removed |Added Known to fail|11.0|10.0 Summary|[8/9/10/11 Regression] ICE |[8/9/10 Regression] ICE in |in add_phi_arg, at |add_phi_arg, at |tree-phinodes.c:359 since |tree-phinodes.c:359 since |r8-2993-ga7976089dba5e227 |r8-2993-ga7976089dba5e227 Known to work||11.0 Priority|P3 |P2 --- Comment #3 from Richard Biener --- Fixed on trunk sofar.
[Bug tree-optimization/94964] [8/9/10/11 Regression] ICE in add_phi_arg, at tree-phinodes.c:359 since r8-2993-ga7976089dba5e227
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94964 --- Comment #2 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:6fc00b41e764219e2c88d8892d7c701c0d292a17 commit r11-139-g6fc00b41e764219e2c88d8892d7c701c0d292a17 Author: Richard Biener Date: Wed May 6 10:23:15 2020 +0200 middle-end/94964 - avoid EH loop entry with CP_SIMPLE_PREHEADERS Loop optimizers expect to be able to insert on the preheader edge w/o splitting it thus avoid ending up with a preheader that enters the loop via an EH edge (or an abnormal edge). 2020-05-06 Richard Biener PR middle-end/94964 * cfgloopmanip.c (create_preheader): Require non-complex preheader edge for CP_SIMPLE_PREHEADERS.
[Bug bootstrap/94961] [11 Regression] ICE in df_refs_verify, at df-scan.c:4002 since r11-87-gd44f14ccef831d90feb57fab56bc3389d543ffdd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94961 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- Created attachment 48466 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48466=edit gcc11-pr94961.patch Untested fix.
[Bug bootstrap/94961] [11 Regression] ICE in df_refs_verify, at df-scan.c:4002 since r11-87-gd44f14ccef831d90feb57fab56bc3389d543ffdd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94961 --- Comment #3 from Martin Liška --- Created attachment 48465 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48465=edit Partially reduced test-case Cannot reduce much..
[Bug other/89394] libiberty :stack overflow in nm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89394 --- Comment #10 from Nick Clifton --- (In reply to Trupti Pardeshi from comment #9) > May I know, in which version of binutils this fix is available? 2.35. Which should be available in August, all being well. Cheers Nick PS. The fix is already in the mainline development code, so you can always clone the repository and build your own toolchain.
[Bug d/94970] d: internal compiler error: in verify_gimple_stmt, at tree-cfg.c:4959
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94970 --- Comment #1 from Iain Buclaw --- The statement it is balking on is GIMPLE_WITH_CLEANUP_EXPR.
[Bug c/92472] enhancement: 5 * constify some parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92472 --- Comment #7 from David Binderman --- (In reply to Jonathan Wakely from comment #6) > This is 400% wrong. It doesn't even address what cppcheck is complaining > about, and cppcheck is drunk anyway. Thanks for your explanation. I am a bit confused by it, so further explanation sought, please. > Those parameter can NOT be const, because *__b1 and *__b2 will not > compile if they're const, because operator* is not const. My understanding of C++, frayed somewhat since 1988, is that operator * being const is a different language feature to parameters being const. Unless you know different. > But what about testing them? Any guidance on fixing this problem, if it is a problem at all, would be most welcome.
[Bug c/94968] [10/11 Regression] internal compiler error: tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in useless_type_conversion_p, at gimple-expr.c:87
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94968 --- Comment #1 from Jakub Jelinek --- Created attachment 48464 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48464=edit gcc11-pr94968.patch Untested fix.
[Bug tree-optimization/94963] [11 Regression] Spurious uninitialized warning for static variable building glibc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94963 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Richard Biener --- Should be fixed.
[Bug tree-optimization/94963] [11 Regression] Spurious uninitialized warning for static variable building glibc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94963 --- Comment #3 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:371905d12259c180efb9b1f1b5716e969feb60f9 commit r11-138-g371905d12259c180efb9b1f1b5716e969feb60f9 Author: Richard Biener Date: Wed May 6 09:39:45 2020 +0200 tree-optimization/94963 - avoid bogus uninit warning with store-motion Eliding the load for store-motion causes an uninitialized variable flowing into the loop, conditionally initialized and used. The uninit warning cannot relate the flag used to guard the initialization and use with the actual initialization so the following robustifies the previous approach of marking the conditional store as not to be warned on by instead initializing the variable on loop entry from an uninitialized variable we mark as not to be warned for. 2020-05-06 Richard Biener PR tree-optimization/94963 * tree-ssa-loop-im.c (execute_sm_if_changed): Remove no-warning marking of the conditional store. (execute_sm): Instead mark the uninitialized state on loop entry to be not warned about. * gcc.dg/pr94963.c: New testcase.
[Bug libstdc++/94971] [10/11 Regression] Parallel Mode cannot be used in C++20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94971 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2020-05-06 Target Milestone|--- |10.2 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- I'm not going to fix this for 10.1, I doubt anybody is using our non-standard parallel mode with C++20 (they should be using the standard parallel algos added in C++17 instead).
