[Bug ipa/96394] internal compiler error: in add_new_edges_to_heap, at ipa-inline.c:1746 (-O3 PGO)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96394 --- Comment #6 from Martin Liška --- I reproduced that locally..
[Bug tree-optimization/96369] [8/9/10/11 Regression] Wrong evaluation order of || operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96369 Richard Biener changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #3 from Richard Biener --- I have a patch.
[Bug ipa/96394] internal compiler error: in add_new_edges_to_heap, at ipa-inline.c:1746 (-O3 PGO)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96394 Martin Liška changed: What|Removed |Added Status|NEW |WAITING --- Comment #5 from Martin Liška --- > I can't craft short example from this as is. Is there a way to reduce with > cvise/creduce both .c and .gcda files at the same time? This is a problematic reduction as .gcda file contains checksums of the source file and one needs to run an instrumented binary.
[Bug ipa/96394] internal compiler error: in add_new_edges_to_heap, at ipa-inline.c:1746 (-O3 PGO)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96394 Martin Liška changed: What|Removed |Added Last reconfirmed||2020-07-31 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #4 from Martin Liška --- Can you please provide steps how to build entire package with PGO? I'll try to bisect that then.
[Bug preprocessor/96391] [10/11 Regression] internal compiler error: in linemap_compare_locations, at libcpp/line-map.c:1359
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96391 --- Comment #3 from Martin Liška --- All right, so please provide pre-processed source file (-E option). I can then try to reproduce it..
[Bug preprocessor/96391] [10/11 Regression] internal compiler error: in linemap_compare_locations, at libcpp/line-map.c:1359
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96391 Richard Biener changed: What|Removed |Added Target Milestone|--- |10.3 Known to fail||10.1.0, 10.2.0 Keywords||ice-on-valid-code Summary|internal compiler error: in |[10/11 Regression] internal |linemap_compare_locations, |compiler error: in |at libcpp/line-map.c:1359 |linemap_compare_locations, ||at libcpp/line-map.c:1359 Target||i686-w64-mingw32 Known to work||9.2.1 Component|c++ |preprocessor --- Comment #2 from Richard Biener --- A backtrace would be helpful, I suspect a stale location somewhere.
[Bug middle-end/96397] New: GCC Fails to exploit ranges from overflow tests
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96397
Bug ID: 96397
Summary: GCC Fails to exploit ranges from overflow tests
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: law at redhat dot com
Target Milestone: ---
Compile with -O2. We should be able to eliminate the x > p1 test if we were
smart about back propagating equivalences to generate a range from the
__builtin_add_overflow.
This was derived from a bogus warning in tpm2-pkcs11's testsuite.
#include
#include
extern void frob (void);
void
foo(size_t p1)
{
size_t x = p1 - 4;
size_t y;
if (__builtin_add_overflow (x, 8, &y))
{
frob ();
}
else
{
if (x > p1)
abort ();
}
}
[Bug d/96393] [11 regression] All 32-bit execution tests FAIL: internal error printing module cycle
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96393 Rainer Orth changed: What|Removed |Added Target|i386-pc-solaris2.11,|i386-pc-solaris2.11, |sparc-sun-solaris2.11 |sparc-sun-solaris2.11, ||x86_64-pc-linux-gnu --- Comment #1 from Rainer Orth --- Same on Linux/x86_64: 64-bit is fine, all 32-bit tests FAIL.
[Bug c++/96396] New: initializer_list in `-fconcepts -std=c++11` reports internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96396
Bug ID: 96396
Summary: initializer_list in `-fconcepts -std=c++11` reports
internal compiler error
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc at mailinator dot com
Target Milestone: ---
Program:
```
#include
int main(){
for(auto it:{1, 2}){
}
}
```
Compiler flag: `-fconcepts -std=c++11`
Godbolt link: https://cpp.godbolt.org/z/K7e5rh (version: x84-64 gcc 10.2 or
trunk)
Compiler output:
```
: In function 'int main()':
:4:26: internal compiler error: in type_unification_real, at
cp/pt.c:21786
4 | for(auto it:{1, 2}){
| ^
Please submit a full bug report,
with preprocessed source if appropriate.
See
[Bug c++/96197] Excess memory consumption, positive correlation with the size of a constexpr array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96197 --- Comment #7 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:8c00059ce058ea2aec2933319e270f5443b8b909 commit r11-2445-g8c00059ce058ea2aec2933319e270f5443b8b909 Author: Patrick Palka Date: Thu Jul 30 22:21:41 2020 -0400 c++: decl_constant_value and unsharing [PR96197] In the testcase from the PR we're seeing excessive memory use (> 5GB) during constexpr evaluation, almost all of which is due to the call to decl_constant_value in the VAR_DECL/CONST_DECL branch of cxx_eval_constant_expression. We reach here every time we evaluate an ARRAY_REF of a constexpr VAR_DECL, and from there decl_constant_value makes an unshared copy of the VAR_DECL's initializer. But unsharing here is unnecessary because callers of cxx_eval_constant_expression already unshare its result when necessary. To fix this excessive unsharing, this patch adds a new defaulted parameter unshare_p to decl_really_constant_value and decl_constant_value so that callers can control whether to unshare. As a simplification, we can also move the call to unshare_expr in constant_value_1 outside of the loop, since doing unshare_expr on a DECL_P is a no-op. Now that we no longer unshare the result of decl_constant_value and decl_really_constant_value from cxx_eval_constant_expression, memory use during constexpr evaluation for the testcase from the PR falls from ~5GB to 15MB according to -ftime-report. gcc/cp/ChangeLog: PR c++/96197 * constexpr.c (cxx_eval_constant_expression) : Pass false to decl_constant_value and decl_really_constant_value so that they don't unshare their result. * cp-tree.h (decl_constant_value): New declaration with an added bool parameter. (decl_really_constant_value): Add bool parameter defaulting to true to existing declaration. * init.c (constant_value_1): Add bool parameter which controls whether to unshare the initializer before returning. Call unshare_expr at most once. (scalar_constant_value): Pass true to constant_value_1's new bool parameter. (decl_really_constant_value): Add bool parameter and forward it to constant_value_1. (decl_constant_value): Likewise, but instead define a new overload with an added bool parameter. gcc/testsuite/ChangeLog: PR c++/96197 * g++.dg/cpp1y/constexpr-array8.C: New test.
[Bug analyzer/96395] New: gcc.dg/analyzer/explode-2.c fails when compiled as C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96395 Bug ID: 96395 Summary: gcc.dg/analyzer/explode-2.c fails when compiled as C++ Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: analyzer Assignee: dmalcolm at gcc dot gnu.org Reporter: sandra at gcc dot gnu.org Target Milestone: --- gcc.dg/analyzer/explode-2.c triggers a -Wanalyzer-too-complex diagnostic when compiled as C++, but not as C: $ x86_64-linux-gnu-g++ /path/to/gcc/testsuite/gcc.dg/analyzer/explode-2.c -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -fdiagnostics-urls=never -fanalyzer -fdiagnostics-path-format=separate-events -Wanalyzer-too-complex -fanalyzer-call-summaries --param analyzer-max-enodes-per-program-point=200 --param analyzer-bb-explosion-factor=50 -S cc1plus: warning: analysis bailed out early (701 'after-snode' enodes; 2762 enodes) [-Wanalyzer-too-complex] ... Increasing both of the params specified in the test case by a factor of 5 didn't seem to help. I ran into this problem in connection with my patches to unify loop representations in the C and C++ front ends https://gcc.gnu.org/pipermail/gcc-patches/2020-March/541954.html but it can be reproduced separately without those patches just by compiling with g++ instead of gcc.
[Bug c++/85282] CWG 727 (full specialization in non-namespace scope)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85282 S. Davis Herring changed: What|Removed |Added CC||herring at lanl dot gov --- Comment #9 from S. Davis Herring --- > But it's not a DR, so it only applies to C++17 and not C++14 or older > standards. Isn't it? Its motion does say "accept as Defect Reports".
[Bug tree-optimization/96369] [8/9/10/11 Regression] Wrong evaluation order of || operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96369 Joseph S. Myers changed: What|Removed |Added Component|c |tree-optimization Summary|Wrong evaluation order of |[8/9/10/11 Regression] ||| operator |Wrong evaluation order of |||| operator --- Comment #2 from Joseph S. Myers --- Actually it appears the wrong code is being introduced somewhere in fold_range_test (I didn't trace it further than that); the only front-end involvement is that the front end does folding as part of conversions at various points. Testing with old compilers suggests this appeared between 4.8.1 and 4.8.3 (quite possibly through some backported change perturbing the exact sequence of calls to folding functions rather than the actual underlying cause being introduced in whatever backport).
[Bug target/94826] [8/9 regression] ICE in gcc.dg/pr94780.c after r10-7999
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94826 Peter Bergner changed: What|Removed |Added CC||bergner at gcc dot gnu.org --- Comment #5 from Peter Bergner --- Is this something we want in GCC 8 & 9? If so, is it just a lack of time to proper regtesting? If so, I can find someone on our team to do the backport and testing. Or is the backport not so straightforward?
[Bug ipa/96394] internal compiler error: in add_new_edges_to_heap, at ipa-inline.c:1746 (-O3 PGO)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96394 --- Comment #3 from Sergei Trofimovich --- Created attachment 48967 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48967&action=edit gcc-tauthon-734006-PR96394.tar.gz gcc-tauthon-734006-PR96394.tar.gz is seemingly self-contained example. It contains preprocessed file, .gcda file and a gcc command (with absolute path to gcc). GCC is built as: $ :/home/slyfox/dev/git/gcc-10-build/gcc/xgcc -B/home/slyfox/dev/git/gcc-10-build/gcc -v Reading specs from /home/slyfox/dev/git/gcc-10-build/gcc/specs COLLECT_GCC=/home/slyfox/dev/git/gcc-10-build/gcc/xgcc COLLECT_LTO_WRAPPER=/home/slyfox/dev/git/gcc-10-build/gcc/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../gcc-10/configure --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --enable-languages=c,c++ --disable-bootstrap --with-multilib-list=m64 --prefix=/home/slyfox/dev/git/gcc-10-build/../gcc-native-quick-installed --disable-nls --without-isl --disable-libsanitizer --disable-libvtv --disable-libgomp --disable-libstdcxx-pch --disable-libunwind-exceptions CFLAGS='-O0 -ggdb3 ' CXXFLAGS='-O0 -ggdb3 ' --with-sysroot=/usr/x86_64-HEAD-linux-gnu Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 10.2.1 20200729 (GCC)
[Bug ipa/96394] internal compiler error: in add_new_edges_to_heap, at ipa-inline.c:1746 (-O3 PGO)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96394
--- Comment #2 from Sergei Trofimovich ---
My guess is it's somehow related to the fact that inliner did 'termvalid'
inline (twice probably?):
"""
static int
validate_chain_two_ops(node *tree, int (*termvalid)(node *), int op1, int op2)
{
int pos = 1;
int nch = ((tree)->n_nchildren);
int res = nch) & 1) == 1)
&& (*termvalid)((&(tree)->n_child[0])));
for ( ; res && (pos < nch); pos += 2) {
if &(tree)->n_child[pos]))->n_type) != op1)
res = validate_ntype((&(tree)->n_child[pos]), op2);
if (res)
res = (*termvalid)((&(tree)->n_child[pos + 1]));
}
return (res);
}
static int
validate_shift_expr(node *tree)
{
return (validate_ntype(tree, 321)
&& validate_chain_two_ops(tree, validate_arith_expr,
34, 35));
}
static int
validate_arith_expr(node *tree)
{
return (validate_ntype(tree, 322)
&& validate_chain_two_ops(tree, validate_term, 14, 15));
}
"""
I can't craft short example from this as is. Is there a way to reduce with
cvise/creduce both .c and .gcda files at the same time?
[Bug ipa/96394] internal compiler error: in add_new_edges_to_heap, at ipa-inline.c:1746 (-O3 PGO)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96394 --- Comment #1 from Sergei Trofimovich --- Created attachment 48966 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48966&action=edit all.tar.gz all.tar.gz is a preprocessed file, corresponding .gcda file and a few ipa dumps.
[Bug ipa/96394] New: internal compiler error: in add_new_edges_to_heap, at ipa-inline.c:1746 (-O3 PGO)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96394
Bug ID: 96394
Summary: internal compiler error: in add_new_edges_to_heap, at
ipa-inline.c:1746 (-O3 PGO)
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: slyfox at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
Target Milestone: ---
It's a forward of https://bugs.gentoo.org/734006 where Ștefan Talpalaru found
an ICE when gcc tries to build PGO-optimised variant of python tauthon-2.8.2.
I can consistently reproduce the crash on gcc-10.2.0 and was able to extract
the backtrace from -O0 ggdb3 gcc:
$ ${HOME}/dev/git/gcc-10-build/gcc/xgcc -B${HOME}/dev/git/gcc-10-build/gcc
-pthread -fPIC -fno-strict-aliasing -O3 -frecord-gcc-switches -fwrapv -DNDEBUG
-fprofile-use -fprofile-correction -I.
-I/tmp/portage/dev-lang/tauthon-2.8.2/work/tauthon-2.8.2/Include
-I/tmp/portage/dev-lang/tauthon-2.8.2/work/x86_64-pc-linux-gnu -c
/tmp/portage/dev-lang/tauthon-2.8.2/work/tauthon-2.8.2/Modules/parsermodule.c
-o
build/temp.linux-x86_64-2.8/tmp/portage/dev-lang/tauthon-2.8.2/work/tauthon-2.8.2/Modules/parsermodule.o
-v -fdump-ipa-all-slim
Breakpoint 2, internal_error (gmsgid=0x297d49f "in %s, at %s:%d") at
../../gcc-10/gcc/diagnostic.c:1706
1706{
(gdb) bt
#0 internal_error (gmsgid=0x297d49f "in %s, at %s:%d") at
../../gcc-10/gcc/diagnostic.c:1706
#1 0x02063d64 in fancy_abort (file=0x2912678
"../../gcc-10/gcc/ipa-inline.c", line=1746, function=0x2912cd4
"add_new_edges_to_heap") at ../../gcc-10/gcc/diagnostic.c:1778
#2 0x01f3fb12 in add_new_edges_to_heap (heap=0x7fffce90,
new_edges=...) at ../../gcc-10/gcc/ipa-inline.c:1746
#3 0x01f412e0 in inline_small_functions () at
../../gcc-10/gcc/ipa-inline.c:2210
#4 0x01f43074 in ipa_inline () at ../../gcc-10/gcc/ipa-inline.c:2689
#5 0x01f43eb1 in (anonymous namespace)::pass_ipa_inline::execute
(this=0x2f03ce0) at ../../gcc-10/gcc/ipa-inline.c:3091
#6 0x00fd326c in execute_one_pass (pass=0x2f03ce0) at
../../gcc-10/gcc/passes.c:2502
#7 0x00fd41c9 in execute_ipa_pass_list (pass=0x2f03ce0) at
../../gcc-10/gcc/passes.c:2929
#8 0x00adbb78 in ipa_passes () at ../../gcc-10/gcc/cgraphunit.c:2678
#9 0x00adbd95 in symbol_table::compile (this=0x77865100) at
../../gcc-10/gcc/cgraphunit.c:2755
#10 0x00adc33d in symbol_table::finalize_compilation_unit
(this=0x77865100) at ../../gcc-10/gcc/cgraphunit.c:3002
#11 0x011332a9 in compile_file () at ../../gcc-10/gcc/toplev.c:483
#12 0x011364aa in do_compile () at ../../gcc-10/gcc/toplev.c:2298
#13 0x011367b6 in toplev::main (this=0x7fffd266, argc=37,
argv=0x7fffd378) at ../../gcc-10/gcc/toplev.c:2437
#14 0x02035d42 in main (argc=37, argv=0x7fffd378) at
../../gcc-10/gcc/main.c:39
(gdb) fr 2
#2 0x01f3fb12 in add_new_edges_to_heap (heap=0x7fffce90,
new_edges=...) at ../../gcc-10/gcc/ipa-inline.c:1746
1746 gcc_assert (!edge->aux);
(gdb) list
1741{
1742 while (new_edges.length () > 0)
1743{
1744 struct cgraph_edge *edge = new_edges.pop ();
1745
1746 gcc_assert (!edge->aux);
1747 gcc_assert (edge->callee);
1748 if (edge->inline_failed
1749 && can_inline_edge_p (edge, true)
1750 && want_inline_small_function_p (edge, true)
Dumping the edge: validate_chain_two_ops/133 -> validate_arith_expr/135
(gdb) call edge->caller->dump(stdout)
validate_chain_two_ops/133 (validate_chain_two_ops) @0x76efc708
Type: function definition analyzed
Visibility: prevailing_def_ironly
previous sharing asm name: 430
References: parser_error/46 (read)
Referring:
Function validate_chain_two_ops/133 is inline copy in validate_shift_expr/134
Availability: local
Profile id: 607042219
Function flags: count:395 (estimated locally, globally 0) first_run:27 body
local unlikely_executed
Called by: validate_shift_expr/134 (inlined) (395 (estimated locally,
globally 0),1.00 per call)
Calls: validate_arith_expr/135 (indirect_inlining) (9 (estimated locally,
globally 0 adjusted),0.02 per call) validate_arith_expr/135 (indirect_inlining)
(394 (estimated locally, globally 0 adjusted),1.00 per call) PyErr_Format/202
(0 (precise),0.00 per call)
(gdb) call edge->callee->dump(stdout)
validate_arith_expr/135 (validate_arith_expr) @0x76efc9d8
Type: function definition analyzed
Visibility: prevailing_def_ironly
previous sharing asm name: 435
Address is taken.
References: parser_error/46 (read)
Referring:
Availability: available
Profile id: 829576279
Function flags: count:1 (adjusted) first_run:28 body hot
Called by: validate_chain_two_ops/133 (indirect_inlining) (9 (estimated
locally, globally 0 adjusted),0.02 per call) valida
[Bug d/96393] [11 regression] All 32-bit execution tests FAIL: internal error printing module cycle
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96393 Rainer Orth changed: What|Removed |Added Target Milestone|--- |11.0
[Bug d/96393] New: [11 regression] All 32-bit execution tests FAIL: internal error printing module cycle
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96393 Bug ID: 96393 Summary: [11 regression] All 32-bit execution tests FAIL: internal error printing module cycle Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: d Assignee: ibuclaw at gdcproject dot org Reporter: ro at gcc dot gnu.org Target Milestone: --- Target: i386-pc-solaris2.11, sparc-sun-solaris2.11 Between 20200729 (f6fe3bbf9f6c0b7249933e19b94560b6b26bf269) and 20200730 (561a19c3011f7bde3a41f2a27ea979118e3a2dff), all 32-bit D execution tests began to FAIL on (at least) Solaris/SPARC and Solaris/x86, all with the same error: object.Error@(0): internal error printing module cycle The 64-bit tests seem to be unchanged.
[Bug d/96152] d: associative array literals don't have alignment holes filled.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96152 --- Comment #1 from CVS Commits --- The master branch has been updated by Iain Buclaw : https://gcc.gnu.org/g:7508a7e958ea06eb311a4a106312634eaf6d40c3 commit r11-2443-g7508a7e958ea06eb311a4a106312634eaf6d40c3 Author: Iain Buclaw Date: Sat Jul 18 17:14:54 2020 +0200 d: Fix associative array literals that don't have alignment holes filled Associative array literal keys with alignment holes are now filled using memset() prior to usage, with LTR evaluation of side-effects enforced. gcc/d/ChangeLog: PR d/96152 * d-codegen.cc (build_array_from_exprs): New function. * d-tree.h (build_array_from_exprs): Declare. * expr.cc (ExprVisitor::visit (AssocArrayLiteralExp *)): Use build_array_from_exprs to generate key and value arrays. gcc/testsuite/ChangeLog: PR d/96152 * gdc.dg/pr96152.d: New test.
[Bug d/96154] d: Add -Wvarargs warning flag to compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96154 --- Comment #1 from CVS Commits --- The master branch has been updated by Iain Buclaw : https://gcc.gnu.org/g:873b45d39c14fee6b68032b83ea6bfbc023e3379 commit r11-2442-g873b45d39c14fee6b68032b83ea6bfbc023e3379 Author: Iain Buclaw Date: Thu Jul 16 18:56:18 2020 +0200 d: Add -Wvarargs warning flag to the D front-end The D front-end has C-style variadic functions and va_start/va_arg, so it is right to also have warnings for inproper use. gcc/d/ChangeLog: PR d/96154 * gdc.texi (Warnings): Document -Wvarargs. * lang.opt: Add -Wvarargs gcc/testsuite/ChangeLog: PR d/96154 * gdc.dg/pr96154a.d: New test. * gdc.dg/pr96154b.d: New test.
[Bug d/96140] internal compiler error: in expand_intrinsic_vaarg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96140 --- Comment #2 from CVS Commits --- The master branch has been updated by Iain Buclaw : https://gcc.gnu.org/g:dfc420f8d4492dbf5f45df4fecf93cb9645c0d7b commit r11-2441-gdfc420f8d4492dbf5f45df4fecf93cb9645c0d7b Author: Iain Buclaw Date: Thu Jul 16 18:34:18 2020 +0200 d: Fix ICE in expand_intrinsic_vaarg Both intrinsics did not handle the case where the va_list object comes from a ref parameter. gcc/d/ChangeLog: PR d/96140 * intrinsics.cc (expand_intrinsic_vaarg): Handle ref parameters as arguments to va_arg(). (expand_intrinsic_vastart): Handle ref parameters as arguments to va_start(). gcc/testsuite/ChangeLog: PR d/96140 * gdc.dg/pr96140.d: New test.
[Bug tree-optimization/96392] Optimize x+0.0 if x is an integer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96392 Marc Glisse changed: What|Removed |Added Last reconfirmed||2020-07-30 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Severity|normal |enhancement
[Bug target/90234] 503.bwaves_r is 6% slower on Zen1/Zen2 CPUs at -Ofast with native march/mtune than with generic ones
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90234 Martin Jambor changed: What|Removed |Added Summary|503.bwaves_r is 6% slower |503.bwaves_r is 6% slower |on Zen1 CPUs at -Ofast with |on Zen1/Zen2 CPUs at -Ofast |native march/mtune than |with native march/mtune |with generic ones |than with generic ones --- Comment #2 from Martin Jambor --- I spoke too soon, I can see this in May gcc 10.1 data on zen1 machine and also in current master (6e1e0decc9e) on a zen-2 machine, still about 6% in both cases. (Gcc9 does not have this problem on zen2 but does on zen1 so it looks a bit fragile).
[Bug libstdc++/94051] #include & is not enough for operator<
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94051 Jonathan Wakely changed: What|Removed |Added Target Milestone|--- |10.0 Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Jonathan Wakely --- This was fixed for GCC 10.1, I don't plan to backport it.
[Bug libstdc++/81967] No overload std::basic_string::erase(__const_iterator, __const_iterator) for old ABI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81967 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-07-30 Ever confirmed|0 |1 --- Comment #2 from Jonathan Wakely --- The allocator support is more complete now, although allocator propagation still isn't supported. I'll confirm the bug, but I have no plans to fix it. The old string is old, and is not going to be maintained to track the current C++ standard.
[Bug target/96377] [10/11 Regression] GCC 10.2/11 doesn't build Linux kernel anymore
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96377 --- Comment #10 from joseph at codesourcery dot com --- On Thu, 30 Jul 2020, rsandifo at gcc dot gnu.org wrote: > IMO process_init_element shouldn't recurse into vector types > if the initialisation value is also a vector type. We should > treat the vector value as initialising the whole type and report > an error if they're not compatible. Yes, that seems correct.
[Bug target/84490] [8/9/10/11 regression] 436.cactusADM regressed by 6-8% percent with -Ofast on Zen and Haswell, compared to gcc 7.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84490 --- Comment #15 from Martin Jambor --- The problem sometimes is still there, sometimes it isn't: https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=37.100.0&plot.1=27.100.0&; I wonder whether we should keep this bug opened, the benchmark seems too erratic.
[Bug target/84481] [8/9/10/11 Regression] 429.mcf with -O2 regresses by ~6% and ~4%, depending on tuning, on Zen compared to GCC 7.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84481 --- Comment #12 from Martin Jambor --- I can once again confirm the slowdown on a zen1-based machine (commit 6e1e0decc9e vs gcc 7.5) but it is not present on a zen2-based one. I wonder whether the bug should me marked as WONTFIX.
[Bug target/96327] Inefficient increment through pointer to volatile on x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96327 --- Comment #6 from Paul McKenney --- (In reply to Marc Glisse from comment #5) > I don't think bug 3506 has been fixed (its status seems wrong to me). But > don't worry, there are several other duplicates that still have status NEW > (bug 50677 for instance). > This is a sensible enhancement request, I think some gcc backends already do > a similar optimization, it simply isn't a priority, because volatile almost > means "don't optimize this". > At least the difference between the gcc and clang codes matches those other > PRs. Not sure why you are talking of address computations. Probably because I was confused by the addressing mode and by wishful thinking, and yes, you are quite correct. Anyway, if you look at https://godbolt.org/z/fGze8E, you can see that Clang/LLVM is using a to-memory addl rather than loading, adding, and storing.
[Bug tree-optimization/96392] New: Optimize x+0.0 if x is an integer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96392
Bug ID: 96392
Summary: Optimize x+0.0 if x is an integer
Product: gcc
Version: 10.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: hugo_musso_gualandi at hotmail dot com
Target Milestone: ---
One way to convert an integer to a floating point number in C is to multiply it
by 1.0. In this case, gcc is clever enough to optimize away the multiplication.
Another way is to add 0.0. However, in this case, GCC does not optimize away
the addition.
Example C code:
double times1(int x)
{
return x * 1.0;
}
double plus0(int x)
{
return x + 0.0;
}
Output of objdump -d after compiling with gcc -O2 -c:
:
0: 66 0f ef c0 pxor %xmm0,%xmm0
4: f2 0f 2a c7 cvtsi2sd %edi,%xmm0
8: c3 retq
9: 0f 1f 80 00 00 00 00nopl 0x0(%rax)
0010 :
10: 66 0f ef c0 pxor %xmm0,%xmm0
14: f2 0f 2a c7 cvtsi2sd %edi,%xmm0
18: f2 0f 58 05 00 00 00addsd 0x0(%rip),%xmm0
1f: 00
20: c3 retq
I believe that the reason that GCC does not optimize x+0.0 is that it is
worried that x could be negative zero. However, promoting an integer to
floating point can never yield negative zero so it should be possible to
optimize in this particular case. (For the matter, Clang does optimize it.)
[Bug target/96327] Inefficient increment through pointer to volatile on x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96327 --- Comment #5 from Marc Glisse --- I don't think bug 3506 has been fixed (its status seems wrong to me). But don't worry, there are several other duplicates that still have status NEW (bug 50677 for instance). This is a sensible enhancement request, I think some gcc backends already do a similar optimization, it simply isn't a priority, because volatile almost means "don't optimize this". At least the difference between the gcc and clang codes matches those other PRs. Not sure why you are talking of address computations.
[Bug fortran/87625] [OOP] (re)allocate on assignment fails for polymorphic array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87625 --- Comment #9 from paul.richard.thomas at gmail dot com --- Bonsoir Dominique, Je t'en remercie! A petits pas je recommence. Comme Steve Kargl je trouve le git complètement incompréhensible mais je retrouve des recettes avec l'aide de Thomas. J'espère que tu as guéri de votre maladie? Amicalement Paul On Thu, 30 Jul 2020 at 16:28, dominiq at lps dot ens.fr < gcc-bugzi...@gcc.gnu.org> wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87625 > > Dominique d'Humieres changed: > >What|Removed |Added > > > Status|WAITING |RESOLVED > Resolution|--- |FIXED > > --- Comment #8 from Dominique d'Humieres --- > Fixed. > > -- > You are receiving this mail because: > You are on the CC list for the bug.
[Bug fortran/92191] internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92191 --- Comment #12 from John Watts --- Thank you - compiles clean now. Regards, John Watts john_wa...@isoparix.com Skype: JS.Watts Tel:+44 (0)20 8549 6501 Mob:+44 (0)774 694 9715 Everything that is Proveable is True. But not everything that is True is Proveable - and we can prove that. On 08/12/2019 14:49, tkoenig at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92191 > > Thomas Koenig changed: > >What|Removed |Added > > Status|NEW |WAITING > > --- Comment #10 from Thomas Koenig --- > I cannot reproduce the error any more with cygwin's current 8.3.0 > (testing), so it seems to be fixed in the meantime. > > Could you confirm that? If so, we could mark this as FIXED. >
[Bug libfortran/95670] Fatal Error: File 'mod_intkinds.mod' opened at (1) is not a GNU Fortran module file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95670 Dominique d'Humieres changed: What|Removed |Added Resolution|--- |INVALID Status|WAITING |RESOLVED --- Comment #2 from Dominique d'Humieres --- Closing.
[Bug target/96377] [10/11 Regression] GCC 10.2/11 doesn't build Linux kernel anymore
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96377 --- Comment #9 from rsandifo at gcc dot gnu.org --- Created attachment 48964 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48964&action=edit Patch for the initialisation problem I'm testing this patch to fix the initialisation side of the problem.
[Bug fortran/92191] internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92191 Dominique d'Humieres changed: What|Removed |Added Resolution|--- |FIXED Status|WAITING |RESOLVED --- Comment #11 from Dominique d'Humieres --- > I cannot reproduce the error any more with cygwin's current 8.3.0 > (testing), so it seems to be fixed in the meantime. > > Could you confirm that? If so, we could mark this as FIXED. No feedback, closing.
[Bug fortran/85575] Acceptance of invalid code: ordering of declaration statements with implicit typing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85575 Dominique d'Humieres changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |WONTFIX --- Comment #11 from Dominique d'Humieres --- No feedback for over two years. Closing.
[Bug target/96377] [10/11 Regression] GCC 10.2/11 doesn't build Linux kernel anymore
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96377
--- Comment #8 from rsandifo at gcc dot gnu.org
---
(In reply to Jakub Jelinek from comment #7)
> I guess that is reasonable thing to do, if the two vector types aren't
> really compatible one will get an error.
> But then, for trunk, won't the stripping of the attributes from vector types
> still mean that comp_type_attributes will return false when comparing the
> destination vector type (the uint8x16_t one) with the one from the binary
> expression (the same with stripped attribute, i.e. essentially a generic
> vector) and thus the initialization will be considered erroneous?
The initialization itself seems to work, since for vectors
compatibility depends on vector_types_compatible_p.
But the stripping of the attributes does still affect:
#include
uint8x16_t
foo (int c, uint8x16_t x, uint8x16_t y)
{
return c ? x + 1 : y;
}
which is wrongly rejected for C, but not C++. So I guess for trunk
we need both fixes.
[Bug c++/96391] internal compiler error: in linemap_compare_locations, at libcpp/line-map.c:1359
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96391 --- Comment #1 from Michael Cronenworth --- Created attachment 48963 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48963&action=edit g++ command and output of error
[Bug c++/96391] New: internal compiler error: in linemap_compare_locations, at libcpp/line-map.c:1359
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96391 Bug ID: 96391 Summary: internal compiler error: in linemap_compare_locations, at libcpp/line-map.c:1359 Product: gcc Version: 10.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: mike at cchtml dot com Target Milestone: --- Compiling the Wine Gecko project on Fedora for a Windows target produces an internal compiler error. GCC 10.1 and 10.2 are affected. Last known working with GCC 9.2.1. When I compile it with the default arguments I get the error. When I compile it with '-save-temps' to get the preprocessed file no error occurs. No error occurs if I compile the preprocessed file either. I'm not sure what to provide to reproduce this besides the SRPM file to compile it. https://kojipkgs.fedoraproject.org//packages/mingw-wine-gecko/2.47.1/2.fc32/src/mingw-wine-gecko-2.47.1-2.fc32.src.rpm
[Bug rtl-optimization/94440] [8/9/10/11 Regression] ICE in check_bool_attrs, at recog.c:2168 since r7-5324-gb8cab8a5492e9639
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94440
David Binderman changed:
What|Removed |Added
CC||dcb314 at hotmail dot com
--- Comment #7 from David Binderman ---
Another test case.
This C code:
double a;
b;
long double c;
e() { float d = (double)(long double)b; }
__attribute__((optimize(""))) f() { a = c; }
when compiled by recent gcc trunk and compiler flag -ffast-math,
does this:
uring RTL pass: reload
bug634.c: In function ‘f’:
bug634.c:5:44: internal compiler error: in check_bool_attrs, at recog.c:2169
5 | __attribute__((optimize(""))) f() { a = c; }
|^
0xc42e4c check_bool_attrs(rtx_insn*)
../../trunk.git/gcc/recog.c:2168
0xafb3fc lra_update_insn_recog_data(rtx_insn*)
../../trunk.git/gcc/lra.c:1260
0xb18199 eliminate_regs_in_insn(rtx_insn*, bool, bool, poly_int<1u, long>)
../../trunk.git/gcc/lra-eliminations.c:0
0xb18b87 process_insn_for_elimination(rtx_insn*, bool, bool)
../../trunk.git/gcc/lra-eliminations.c:1304
This has been going wrong since sometime before date 20200630.
[Bug target/96377] [10/11 Regression] GCC 10.2/11 doesn't build Linux kernel anymore
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96377 --- Comment #7 from Jakub Jelinek --- I guess that is reasonable thing to do, if the two vector types aren't really compatible one will get an error. But then, for trunk, won't the stripping of the attributes from vector types still mean that comp_type_attributes will return false when comparing the destination vector type (the uint8x16_t one) with the one from the binary expression (the same with stripped attribute, i.e. essentially a generic vector) and thus the initialization will be considered erroneous?
[Bug fortran/53940] Optionally warn about multiple explicit USE-association of the same symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53940 Dominique d'Humieres changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |WONTFIX --- Comment #7 from Dominique d'Humieres --- Closing.
[Bug fortran/87625] [OOP] (re)allocate on assignment fails for polymorphic array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87625 Dominique d'Humieres changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #8 from Dominique d'Humieres --- Fixed.
[Bug fortran/94925] Undesired runtime warning message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94925 Dominique d'Humieres changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #5 from Dominique d'Humieres --- You should not get the warning if you don't ask for. Without reproducer there is nothing that ca be done. Closing.
[Bug fortran/51591] Strange output from STOP statement in OpenMP region
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51591 --- Comment #9 from Jakub Jelinek --- OpenMP just says that a structured block "may contain STOP or ERROR STOP statements." and nothing else, what the particular behavior for STOP is is covered in the base language or is up to the implementation.
[Bug fortran/51591] Strange output from STOP statement in OpenMP region
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51591 Dominique d'Humieres changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |WORKSFORME --- Comment #8 from Dominique d'Humieres --- > Jakub, do you know what the OMP standard has to say on this? > Is "STOP 1" in an OMP region defined behavior? No answer after more than one year. Closing. Open a new PR if the problem is still there.
[Bug c++/96379] [10/11 Regression] GCC accepts totally invalid template declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96379 Marek Polacek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug c++/96380] [10/11 Regression] ICE in tree check: expected integer_cst, have view_convert_expr in get_len, at tree.h:5954
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96380 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org
[Bug fortran/91902] "Where has __float128 gone" error during "making" gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91902 Dominique d'Humieres changed: What|Removed |Added Resolution|--- |INVALID Status|WAITING |RESOLVED --- Comment #7 from Dominique d'Humieres --- No feedback, closing.
[Bug fortran/90237] Bogus warning from -Wdo-subscript
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90237 Dominique d'Humieres changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #9 from Dominique d'Humieres --- > Looks like this has just been addressed in my original report > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90563 So closing.
[Bug fortran/60144] Misleading error message when missing "then" after "if" and "else if"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60144 Dominique d'Humieres changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #8 from Dominique d'Humieres --- This is fixed since at least GCC7.
[Bug c/89180] [meta-bug] bogus/missing -Wunused warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89180 Bug 89180 depends on bug 92358, which changed state. Bug 92358 Summary: libgfortran/io/async.c:548:37: warning: unused parameter 'cmp' https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92358 What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID
[Bug fortran/92358] libgfortran/io/async.c:548:37: warning: unused parameter 'cmp'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92358 Dominique d'Humieres changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #3 from Dominique d'Humieres --- I also don't see the issue. Closing.
[Bug c++/96387] gnu gmp c source edit g++ internal compiler error appear
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96387
cents2823 at yahoo dot co.jp changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID |---
--- Comment #2 from cents2823 at yahoo dot co.jp ---
I was recompiling all of the gmp-6.2.0 software to use the new struct by
configure, make, make check,and make install.
I want to calculate π 40 billion digits or more by gmp.
The high-speed π parallel calculation program I created requires a large amount
of memory and cannot be used on the current PC, but will be calculated on the
next new PC.
Even on the current PC, I changed the gmp API and was able to calculate route 2
with 77 billion digits. The calculation result was calculated by y-cruncer and
collated.
Therefore, the changed gmp API can be used.
However, it is necessary to partially change the gmp program with another
struct (__mpf_struct).
So I would like to know why changing gmp struct causes g++ to make an error.
Thanking you in advance.
Frome:Tsukamoto
#1 Sources unrelated to gmp:
float y = 0.1;
printf("\ny= %5.2f",y);
g++ error message:
printf float %f become this error mesege but %d etc is OK
during GIMPLE pass: printf-return-value
test_g++.c: In function ‘int main()’:
test_g++.c:4:5: internal compiler error: Segmentation fault
4 | int main(void) {
| ^~~~
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
If I comment out "printf("\ny= %5.2f",y);", the above g++ error message
will disappear.
[Bug c++/96003] [11 Regression] spurious -Wnonnull calling a member on the result of static_cast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96003 --- Comment #15 from Martin Sebor --- The patch I posted two weeks ago is only now being reviewed.
[Bug c++/95949] mame build succeeds with -O3 but fails with -O2 and all -O3 flags added manually
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95949 W E Brown changed: What|Removed |Added CC||webrown.cpp at gmail dot com Julian Sikorski changed: What|Removed |Added Version|10.1.0 |10.2.0 --- Comment #10 from Julian Sikorski --- 10.2.0 is still affected.
[Bug target/96377] [10/11 Regression] GCC 10.2/11 doesn't build Linux kernel anymore
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96377 rsandifo at gcc dot gnu.org changed: What|Removed |Added CC||jsm28 at gcc dot gnu.org, ||mpolacek at gcc dot gnu.org --- Comment #6 from rsandifo at gcc dot gnu.org --- Joseph, Marek, any thoughts on comment #5?
[Bug target/96377] [10/11 Regression] GCC 10.2/11 doesn't build Linux kernel anymore
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96377
--- Comment #5 from rsandifo at gcc dot gnu.org
---
I think this is bound up with the question whether:
typedef int v4si __attribute__((vector_size(16)));
typedef short v8hi __attribute__((vector_size(16)));
struct s {
v8hi x;
v4si y;
};
void
foo (v4si i, v8hi h)
{
struct s x1 = { i, i };
struct s x2 = { h, h };
struct s x3 = { i, h };
struct s x4 = { h, i };
}
should be valid with -flax-vector-conversions. g++ and clang
think it should be, but gcc doesn't accept it.
IMO process_init_element shouldn't recurse into vector types
if the initialisation value is also a vector type. We should
treat the vector value as initialising the whole type and report
an error if they're not compatible.
[Bug c++/79078] Warnings from deprecated attribute are too noisy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79078
--- Comment #17 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #16)
> struct string
> {
> #if __cplusplus == 201703L
> [[deprecated("use shrink_to_fit() instead")]]
> #elif __cplusplus > 201703L
> private:
> #endif
> void reserve()
> { }
> public:
The solution here is to just disable the warning around this use:
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wdeprecated-declarations"
> void shrink_to_fit() { reserve(); }
#pragma GCC diagnostic pop
> };
So I don't need a compiler change after all.
[Bug rtl-optimization/96388] scheduling takes forever with -fPIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96388 --- Comment #9 from Martin Liška --- Created attachment 48962 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48962&action=edit Partially reduced test-case The reduction is quite stuck at this point.
[Bug debug/96383] [8/9/10/11 Regression] Full ABI information missing from GCC compiled C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96383 Richard Biener changed: What|Removed |Added CC||ebotcazou at gcc dot gnu.org --- Comment #11 from Richard Biener --- So with the attached 'updated patch' I see === gnat tests === Running target unix/ FAIL: gnat.dg/debug11_pkg.adb scan-assembler-not foreign_imported_func FAIL: gnat.dg/debug9.adb scan-assembler-times (DIE (0x[a-f0-9]*) DW_ TAG_type_unit) 0 where the first FAIL seems obvious from the name of 'foreign_imported_func' and the changed outcome is expected and OK? For the second FAIL I see type units for system__secondary_stack_* types and the extra subroutines are likely the invoked system__secondary_stack_* functions like <1><77>: Abbrev Number: 38 (DW_TAG_subprogram) <78> DW_AT_external: 1 <78> DW_AT_name: (indirect string, offset: 0x47): system__secondar y_stack__ss_release <7c> DW_AT_decl_file : 2 <7d> DW_AT_decl_line : 95 <7e> DW_AT_decl_column : 14 <7f> DW_AT_sibling : <0x8e> <2><83>: Abbrev Number: 39 (DW_TAG_formal_parameter) <84> DW_AT_name: m <86> DW_AT_decl_file : 2 <87> DW_AT_decl_line : 95 <88> DW_AT_decl_column : 26 <89> DW_AT_type: <0x8e> <2><8d>: Abbrev Number: 0 note they are not DECL_ARTIFICIAL and also not DECL_IGNORED. Now the testcase tries to test sth else than no type units at all as its comment explains.
[Bug c++/79078] Warnings from deprecated attribute are too noisy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79078
--- Comment #16 from Jonathan Wakely ---
(In reply to Marek Polacek from comment #8)
> One thing we should do is to
>
> --- a/gcc/cp/decl.c
> +++ b/gcc/cp/decl.c
> @@ -12643,7 +12643,7 @@ grokparms (tree parmlist, tree *parms)
> if (deprecated_state != DEPRECATED_SUPPRESS)
> {
> tree deptype = type_is_deprecated (type);
> - if (deptype)
> + if (deptype && !TYPE_BEING_DEFINED (deptype))
> warn_deprecated_use (deptype, NULL_TREE);
> }
>
>
> i.e. don't warn if the deprecated type is being defined.
That looks sensible, but only helps for uses of the type. It doesn't help this
case where a function is deprecated (this is based on a real change I want to
make to libstdc++):
struct string
{
#if __cplusplus == 201703L
[[deprecated("use shrink_to_fit() instead")]]
#elif __cplusplus > 201703L
private:
#endif
void reserve()
{ }
public:
void shrink_to_fit() { reserve(); }
};
int main()
{
string s;
s.shrink_to_fit();
}
When compiled as C++17 this issues a deprecated warning for the call from
shrink_to_fit(). The user of the class never calls the deprecated function
though. Calling it from another member of the class should not warn.
Marek, do you have a suggestion for how to suppress this one?
It would be very helpful to get a quick fix for this part, even if Martin's
more ambitious plan in comment 14 isn't going to be ready in the short term.
[Bug middle-end/96390] [OpenMP] Link errors on the offload side for C++ code with templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96390 --- Comment #1 from Tobias Burnus --- Created attachment 48961 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48961&action=edit Test case from https://bugs.llvm.org/show_bug.cgi?id=43771 (basis for sollve_vv test case, by Jonas Hahnfeld)
[Bug target/96366] [AArch64] ICE due to lack of support for VNx2SI sub instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96366
--- Comment #2 from Bu Le ---
(In reply to rsand...@gcc.gnu.org from comment #1)
> (In reply to Bu Le from comment #0)
> Hmm. In general, the lack of a vector pattern shouldn't case ICEs,
> but I suppose the add/sub pairing is somewhat special because of
> the canonicalisation rules. It would be worth looking at exactly
> why we generate the subtract though, just to confirm that this is
> an “expected” ICE rather than a symptom of a deeper problem.
Sure. The logic is that the subtraction will be expanded in expr.c:8989, before
which I believe it still works fine. The gimple to be expand is
vect__5.16_77 = { 4294967273, 4294967154, 4294967294, 4294967265 } -
vect__1.14_73
When the logic goes on, it went into the binop routine at expr:9948 because op1
(vect__1.14_73) is not a const op and missed the oppotunity to turn into an add
negative pair. Then,the routine will call expand_binop to finalize the
subtraction. The expand_binop function also has an oppotunity to turn this
subtraction to add a negative number, but also missed because op1 is not a
constant.
It occurs to me that we can brought the check for the availbility of this
pattern to the decision condition for whether turning the subtraction to a
addition of negative equivalent. This can be an insurance measurement for the
similar case that the pattern is missed, preventing the ICE. So I tried
following change, which turns out could also solve the problem by turning the
subtraction into addition as expected.
diff -Nurp gcc-20200728-org/gcc/optabs.c gcc-20200728/gcc/optabs.c
--- gcc-20200728-org/gcc/optabs.c 2020-07-29 15:53:52.76000 +0800
+++ gcc-20200728/gcc/optabs.c 2020-07-30 11:00:00.96400 +0800
@@ -1171,10 +1171,12 @@ expand_binop (machine_mode mode, optab b
mclass = GET_MODE_CLASS (mode);
- /* If subtracting an integer constant, convert this into an addition of
- the negated constant. */
+ /* If subtracting an integer constant, or if no subtraction pattern
available
+ for this mode, convert this into an addition of the negated constant. */
- if (binoptab == sub_optab && CONST_INT_P (op1))
+ if (binoptab == sub_optab
+ && (CONST_INT_P (op1)
+ || optab_handler (binoptab, mode) == CODE_FOR_nothing))
{
op1 = negate_rtx (mode, op1);
binoptab = add_optab;
> The idea was for that patch to add the bare minimum needed
> to support the “unpacked vector” infrastructure. Then, once the
> infrastructure was in place, we could add support for other
> unpacked vector operations too.
>
> However, the infrastructure went in late during the GCC 10
> cycle, so the idea was to postpone any new unpacked vector
> support to GCC 11. So far the only additional operations
> has been Joe Ramsay's patches for logical operations
> (g:bb3ab62a8b4a108f01ea2eddfe31e9f733bd9cb6 and
> g:6802b5ba8234427598abfd9f0163eb5e7c0d6aa8).
>
> The reason for not changing many operations at once is that,
> in each case, a decision needs to be made whether the
> operation should use the container mode (as for INDEX),
> the element mode (as for right shifts, once they're
> implemented) or whether it doesn't matter (as for addition).
> Each operation also needs tests. So from that point of view,
> it's more convenient to have a separate patch for each
> operation (or at least closely-related groups of operations).
Oh, I see. From the performance's point of view, I beleive that add the
subtraction pattern is necessary eventually. I compiled and ran the test case
attached with the subtraction pattern sulotion, which works fine. Logically,
the subtraction should be the same as the addition, which is not sensetive to
the operation mode.
My idea of solving this problem is that we upstream the patch for mode
extension independently, after which upstream the sub-to-add patch for
insurance that other cases might step into the same routine.
Any suggestions?
[Bug bootstrap/96202] --enable-cet complains about missing assembler support with GCC 7 host compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96202 H.J. Lu changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from H.J. Lu --- Fixed.
[Bug bootstrap/96202] --enable-cet complains about missing assembler support with GCC 7 host compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96202 --- Comment #3 from CVS Commits --- The master branch has been updated by H.J. Lu : https://gcc.gnu.org/g:4712bde3cabed644884a52386404765fca3b0ac2 commit r11-2430-g4712bde3cabed644884a52386404765fca3b0ac2 Author: H.J. Lu Date: Wed Jul 15 06:16:01 2020 -0700 Require CET support only for the final GCC build With --enable-cet, require CET support only for the final GCC build. Don't enable CET without CET support for non-bootstrap build, in stage1 nor for build support. config/ PR bootstrap/96202 * cet.m4 (GCC_CET_HOST_FLAGS): Don't enable CET without CET support in stage1 nor for build support. gcc/ PR bootstrap/96202 * configure: Regenerated. libbacktrace/ PR bootstrap/96202 * configure: Regenerated. libcc1/ PR bootstrap/96202 * configure: Regenerated. libcpp/ PR bootstrap/96202 * configure: Regenerated. libdecnumber/ PR bootstrap/96202 * configure: Regenerated. libiberty/ PR bootstrap/96202 * configure: Regenerated. lto-plugin/ PR bootstrap/96202 * configure: Regenerated.
[Bug middle-end/96390] New: [OpenMP] Link errors on the offload side for C++ code with templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96390 Bug ID: 96390 Summary: [OpenMP] Link errors on the offload side for C++ code with templates Product: gcc Version: 10.0 Status: UNCONFIRMED Keywords: openmp Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org CC: jakub at gcc dot gnu.org Target Milestone: --- sollve_vv's tests/4.5/application_kernels/gemv_target_reduction.cpp fails to link when compiling with -O0. Note: with -O1 and higher, it becomes a host-only code, which works. Testcase: https://github.com/SOLLVE/sollve_vv/blob/master/tests/4.5/application_kernels/alpaka_complex_template.cpp g++ -fopenmp alpaka_complex_template.cpp -O0 Namely, with GCN: ld: error: undefined symbol: S<0>::S() >>> referenced by /tmp/ccGooH3g.o:(main._omp_fn.2) >>> referenced by /tmp/ccGooH3g.o:(main._omp_fn.2) ld: error: undefined symbol: V<1>::V(unsigned long&&) >>> referenced by /tmp/ccGooH3g.o:(main._omp_fn.2) >>> referenced by /tmp/ccGooH3g.o:(main._omp_fn.2) And likewise with nvptx: libgomp: Link error log ptxas application ptx input, line 262; error : Label expected for argument 0 of instruction 'call' ptxas application ptx input, line 262; error : Function '_ZN1SILi0EEC1Ev' not declared in this scope ptxas application ptx input, line 262; error : Call target not recognized ptxas application ptx input, line 276; error : Label expected for argument 0 of instruction 'call' ptxas application ptx input, line 276; error : Function '_ZN1VILi1EEC1ImvEEOT_' not declared in this scope which demangles to the same symbols.
[Bug debug/96383] [8/9/10/11 Regression] Full ABI information missing from GCC compiled C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96383 --- Comment #10 from Richard Biener --- Created attachment 48960 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48960&action=edit updated patch Avoid aliases and thunks, avoid not declared builtins w/o body. Updates stats for cc1 to FILE SIZEVM SIZE -- -- +1.0% +1.21Mi [ = ] 0.debug_info +4.4% +92.0Ki [ = ] 0.debug_abbrev +0.1% +6.76Ki [ = ] 0.debug_str +0.0% +5.80Ki [ = ] 0.debug_line +0.0%+426 [ = ] 0.debug_loc +0.0%+144 [ = ] 0.debug_ranges +0.0% +80 +0.0% +80.text +0.0% +52 [ = ] 0.strtab +0.0% +32 +0.0% +32.rodata +0.0% +24 [ = ] 0.symtab +0.0% +16 +0.0% +16.eh_frame +0.0% +8 +0.0% +8.eh_frame_hdr -1.9%-138 [ = ] 0[Unmapped] +0.4% +1.31Mi +0.0%+136TOTAL and after applying DWZ to both: FILE SIZEVM SIZE -- -- +1.0% +751Ki [ = ] 0.debug_info +4.8% +87.8Ki [ = ] 0.debug_abbrev +0.1% +6.76Ki [ = ] 0.debug_str +0.0% +5.80Ki [ = ] 0.debug_line +0.0%+426 [ = ] 0.debug_loc +0.0%+144 [ = ] 0.debug_ranges +0.0% +80 +0.0% +80.text +0.0% +52 [ = ] 0.strtab +0.0% +32 +0.0% +32.rodata +0.0% +24 [ = ] 0.symtab +0.0% +16 +0.0% +16.eh_frame +0.0% +8 +0.0% +8.eh_frame_hdr -1.9%-137 [ = ] 0[Unmapped] +0.3% +852Ki +0.0%+136TOTAL
[Bug lto/96385] GCC generates separate debug info with undefined symbols without relocations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96385 --- Comment #5 from H.J. Lu --- Please get users/hjl/pr26314/test branch at https://gitlab.com/x86-binutils/binutils-gdb/-/tree/users/hjl/pr26314/test and build binutils with GCC 10: CC="/usr/gcc-10.1.1-x32/bin/gcc -flto -ffat-lto-objects -Wl,--as-needed -fcf-protection" CXX="/usr/gcc-10.1.1-x32/bin/g++ -flto -ffat-lto-objects -Wl,--as-needed -fcf-protection" /export/gnu/import/git/gitlab/x86-binutils/configure \ --enable-shared \ \ --enable-plugins --disable-gdb --disable-gdbserver --disable-libdecnumber --disable-readline --disable-sim --with-sysroot=/ --with-system-zlib \ --prefix=/usr/local \ --with-local-prefix=/usr/local I got [hjl@gnu-cfl-2 build-x86_64-linux]$ nm -D binutils/.libs/ar | grep lrealpath A lrealpath [hjl@gnu-cfl-2 build-x86_64-linux]$
[Bug tree-optimization/96376] [11 regression] vect/vect-alias-check.c and vect/vect-live-5.c fail on armeb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96376 --- Comment #1 from Christophe Lyon --- Bisect identified commit g30fdaead5b7880c4e9f140618e26ad1c545642d5
[Bug lto/96385] GCC generates separate debug info with undefined symbols without relocations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96385 --- Comment #4 from rguenther at suse dot de --- On Thu, 30 Jul 2020, rguenther at suse dot de wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96385 > > --- Comment #3 from rguenther at suse dot de --- > On Thu, 30 Jul 2020, hjl.tools at gmail dot com wrote: > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96385 > > > > H.J. Lu changed: > > > >What|Removed |Added > > > > Status|WAITING |NEW > > > > --- Comment #2 from H.J. Lu --- > > A testcase is on pr96385 branch at: > > > > https://gitlab.com/x86-gcc/gcc-bugs > > I'd like to have the _source_ to whichever of the .o files > has the bogus relocation in the .gnulto.debug_info section. > > The bug happens at the compile stage. More specifically, .rela.gnu.debuglto_.debug_info may only contain relocations to other .gnu.debuglto_.* sections and definitely _not_ relocations to UNDEF symbols.
[Bug lto/96385] GCC generates separate debug info with undefined symbols without relocations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96385 --- Comment #3 from rguenther at suse dot de --- On Thu, 30 Jul 2020, hjl.tools at gmail dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96385 > > H.J. Lu changed: > >What|Removed |Added > > Status|WAITING |NEW > > --- Comment #2 from H.J. Lu --- > A testcase is on pr96385 branch at: > > https://gitlab.com/x86-gcc/gcc-bugs I'd like to have the _source_ to whichever of the .o files has the bogus relocation in the .gnulto.debug_info section. The bug happens at the compile stage.
[Bug lto/96385] GCC generates separate debug info with undefined symbols without relocations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96385 H.J. Lu changed: What|Removed |Added Status|WAITING |NEW --- Comment #2 from H.J. Lu --- A testcase is on pr96385 branch at: https://gitlab.com/x86-gcc/gcc-bugs
[Bug lto/96389] Compiling MinGW-w64 GCC with LTO results in error: symbol wrong type (4 vs 3)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96389 --- Comment #2 from Brecht Sanders --- Am I in uncharted territory? Or is it worth it exploring LTO versions of libgcc_s.a and libstdc++.a? What about the error message "symbol wrong type (4 vs 3)"? What does it mean exactly and how dos the LTO build trigger this error?
[Bug lto/96389] Compiling MinGW-w64 GCC with LTO results in error: symbol wrong type (4 vs 3)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96389 --- Comment #1 from Richard Biener --- You also want -O2 and maybe -g in your CXXFLAGS_FOR_TARGET, I'm not sure if LTO IL in libgcc_s.a or libstdc++.a "works" for consumers or if there's unintended side-effects of LTOing those system pieces. I think altering CXXFLAGS_FOR_TARGET (plus CFLAGS_FOR_TARGET) is correct though. Not sure about LTO and MinGW-w64 in general. If the linker plugin is not supported then it would be still second class. It definitely is second class with respect to debug info support because it's not using ELF.
[Bug tree-optimization/96370] [8/9/10 Regression] ICE with -ffast-math since r7-950-g8a85cee26eabf5cf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96370 Richard Biener changed: What|Removed |Added Summary|ICE with -ffast-math since |[8/9/10 Regression] ICE |r7-950-g8a85cee26eabf5cf|with -ffast-math since ||r7-950-g8a85cee26eabf5cf Priority|P3 |P2 Known to work||11.0 Target Milestone|--- |8.5 --- Comment #7 from Richard Biener --- Fixed on trunk sofar.
[Bug target/90928] [9/10/11 Regression] [nvptx] internal compiler error: in instantiate_virtual_regs_in_insn, at function.c:1737
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90928 --- Comment #4 from Tom de Vries --- Patch submitted: https://gcc.gnu.org/pipermail/gcc-patches/2020-July/550140.html
[Bug tree-optimization/96370] ICE with -ffast-math since r7-950-g8a85cee26eabf5cf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96370 --- Comment #6 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:2c558d2655cb22f472c83e8296b5cd2a92365cd3 commit r11-2424-g2c558d2655cb22f472c83e8296b5cd2a92365cd3 Author: Richard Biener Date: Thu Jul 30 10:24:42 2020 +0200 tree-optimization/96370 - make reassoc expr rewrite more robust In the face of the more complex tricks in reassoc with respect to negate processing it can happen that the expression rewrite is fooled to recurse on a leaf and pick up a bogus expression code. The following patch makes the expression rewrite more robust in providing the expression code to it directly since it is the same for all operations in a chain. 2020-07-30 Richard Biener PR tree-optimization/96370 * tree-ssa-reassoc.c (rewrite_expr_tree): Add operation code parameter and use it instead of picking it up from the stmt that is being rewritten. (reassociate_bb): Pass down the operation code. * gcc.dg/pr96370.c: New testcase.
[Bug debug/96383] [8/9/10/11 Regression] Full ABI information missing missing from GCC compiled C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96383 --- Comment #9 from Richard Biener --- cc1 debug info increases like the following VM SIZE FILE SIZE ++ GROWING ++ [ = ] 0 .debug_info +1.63Mi +1.3% [ = ] 0 .debug_str +263Ki +3.4% [ = ] 0 .debug_abbrev +101Ki +4.9% [ = ] 0 .debug_line +5.71Ki +0.0% +44% +16 [Unmapped]+48 +1.2% -- SHRINKING -- [ = ] 0 .debug_loc -213 -0.0% -0.0% -48 .text -48 -0.0% [ = ] 0 .debug_ranges -16 -0.0% -0.0% -32 TOTAL +1.99Mi +0.6% Throwing dzw on both makes the difference VM SIZE FILE SIZE ++ GROWING ++ [ = ] 0 .debug_info +1023Ki +1.3% [ = ] 0 .debug_str +263Ki +3.4% [ = ] 0 .debug_abbrev +84.9Ki +4.6% [ = ] 0 .debug_line +5.71Ki +0.0% +44% +16 [Unmapped]+50 +1.2% -- SHRINKING -- [ = ] 0 .debug_loc -213 -0.0% -0.0% -48 .text -48 -0.0% [ = ] 0 .debug_ranges -16 -0.0% -0.0% -32 TOTAL +1.35Mi +0.5% I'm with Jakub here, having the information is useful, esp. at -O0 where we never had any of it.
[Bug fortran/53298] ICE in gfc_conv_scalarized_array_ref for ARRAY + substring
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53298 --- Comment #12 from markeggleston at gcc dot gnu.org --- Fixed the ICE in comment 5. I completely missed the "a different ICE"... More investigation required.
[Bug debug/96383] [8/9/10/11 Regression] Full ABI information missing missing from GCC compiled C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96383 --- Comment #8 from Jakub Jelinek --- Agreed, and we do want the prototypes of used functions even when it costs some increase in debug info size, because without that one say can't easily call in a debugger those functions unless debug info for the library they are defined in is available. Well, one can always do p ((int (*)(int, int)) foo) (2, 3) instead of just p foo (2, 3) which gdb disallows because it doesn't have the prototype, but it is ugly.
[Bug lto/96389] New: Compiling MinGW-w64 GCC with LTO results in error: symbol wrong type (4 vs 3)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96389 Bug ID: 96389 Summary: Compiling MinGW-w64 GCC with LTO results in error: symbol wrong type (4 vs 3) Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: brechtsanders at users dot sourceforge.net CC: marxin at gcc dot gnu.org Target Milestone: --- Created attachment 48959 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48959&action=edit Build output I would like to compile my MinGW-w64 build of GCC for Windows (targetting win32 and win64) with the (static) standard libraries containing LTO information. I added these flag to the configure command: CXXFLAGS_FOR_TARGET="-flto -ffat-lto-objects" but then I get errors like this when it tries to build libstdc++-v3: symbol wrong type (4 vs 3) After looking on the internet I also tried with this as possible workaround: LDFLAGS="-fno-use-linker-plugin" but I got the same errors. I have attached the complete compiler output. Are there still known issues with LTO on Windows? Is it supported to have LTO information in libraries like libgcc_s.a and libstdc++.a? If so, what is the correct way to build them?
[Bug debug/96383] [8/9/10/11 Regression] Full ABI information missing missing from GCC compiled C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96383 --- Comment #7 from rguenther at suse dot de --- On Thu, 30 Jul 2020, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96383 > > Jakub Jelinek changed: > >What|Removed |Added > > CC||jakub at gcc dot gnu.org > > --- Comment #6 from Jakub Jelinek --- > I think at least compared to 4.8 this regressed with the PR65549 change > r224029. Yeah, so that means we've created those DIEs late and only when doing DW_TAG_GNU_call_site processing which we appearantly not do at -O0 and thus get no DIE then. For LTO we need them early anyway so it makes more sense to create them for all neede calls.
[Bug debug/96383] [8/9/10/11 Regression] Full ABI information missing missing from GCC compiled C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96383
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #6 from Jakub Jelinek ---
I think at least compared to 4.8 this regressed with the PR65549 change
r224029.
At least for simple:
extern int foo (int, int);
void
bar (void)
{
foo (1, 2);
}
[Bug target/95435] bad builtin memcpy performance with znver1/znver2 and 32bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95435 Martin Liška changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #13 from Martin Liška --- Fixed on master and gcc-10 release branch, closing now.
[Bug target/95435] bad builtin memcpy performance with znver1/znver2 and 32bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95435 --- Comment #11 from CVS Commits --- The master branch has been updated by Martin Liska : https://gcc.gnu.org/g:dc65aba7a4725d1b464c8c64a5f739ee910e8943 commit r11-2422-gdc65aba7a4725d1b464c8c64a5f739ee910e8943 Author: Martin Liska Date: Mon Jun 1 13:21:40 2020 +0200 Tune memcpy and memset for Zen cores. Based on the collected numbers in PR95435, I suggest the following tuning changes: gcc/ChangeLog: PR target/95435 * config/i386/x86-tune-costs.h: Use libcall for large sizes for -m32. Start using libcall from 128+ bytes.
[Bug target/95435] bad builtin memcpy performance with znver1/znver2 and 32bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95435 --- Comment #12 from CVS Commits --- The releases/gcc-10 branch has been updated by Martin Liska : https://gcc.gnu.org/g:809b4d226c7f5ded392a88ffafe8d652f911b473 commit r10-8554-g809b4d226c7f5ded392a88ffafe8d652f911b473 Author: Martin Liska Date: Mon Jun 1 13:21:40 2020 +0200 Tune memcpy and memset for Zen cores. Based on the collected numbers in PR95435, I suggest the following tuning changes: gcc/ChangeLog: PR target/95435 * config/i386/x86-tune-costs.h: Use libcall for large sizes for -m32. Start using libcall from 128+ bytes. (cherry picked from commit dc65aba7a4725d1b464c8c64a5f739ee910e8943)
[Bug rtl-optimization/96388] scheduling takes forever with -fPIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96388
--- Comment #8 from Richard Biener ---
> /usr/bin/time ./cc1 -quiet t.c 2>&1 | head -1 | awk '{ print $6 * 1 }'
35975
is the max RSS in kB. Guess subtracting the value for an empty compile
makes sense as well.
[Bug rtl-optimization/96388] scheduling takes forever with -fPIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96388 --- Comment #7 from Martin Liška --- (In reply to Richard Biener from comment #6) > (In reply to Martin Liška from comment #5) > > Started with r9-2469-gc6067437d314f803. > > Hmm, it probably makes a latent scheduler issue appear. Guess for better > analysis we have to trim down the source. Not sure how - maybe > automatically with one good and one bad rev. looking for a hundred-fold > increase in memory use? Look at the good compile with /usr/bin/time > and using the RSS to compute a ulimit -v limit or so. I'm reducing that in the ulimit fence ;) Let see where it leads..
[Bug lto/96385] GCC generates separate debug info with undefined symbols without relocations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96385 Richard Biener changed: What|Removed |Added Last reconfirmed||2020-07-30 Status|UNCONFIRMED |WAITING Ever confirmed|0 |1
[Bug rtl-optimization/96388] scheduling takes forever with -fPIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96388 --- Comment #6 from Richard Biener --- (In reply to Martin Liška from comment #5) > Started with r9-2469-gc6067437d314f803. Hmm, it probably makes a latent scheduler issue appear. Guess for better analysis we have to trim down the source. Not sure how - maybe automatically with one good and one bad rev. looking for a hundred-fold increase in memory use? Look at the good compile with /usr/bin/time and using the RSS to compute a ulimit -v limit or so.
[Bug debug/96383] [8/9/10/11 Regression] Full ABI information missing missing from GCC compiled C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96383
--- Comment #5 from Richard Biener ---
Note one reason to omit the info might be that it should be available in the
debug information of the callee. The following simple patch makes the
desired debug information appear at both -O0 -g and -O -g for foo but
not for bar (which is unused):
extern void foo (int);
extern void bar (int);
int main()
{
foo (1);
}
diff --git a/gcc/cgraphunit.c b/gcc/cgraphunit.c
index ea9a34bda6f..3e97c1f4b4e 100644
--- a/gcc/cgraphunit.c
+++ b/gcc/cgraphunit.c
@@ -2989,7 +2989,7 @@ symbol_table::finalize_compilation_unit (void)
/* Emit early debug for reachable functions, and by consequence,
locally scoped symbols. */
struct cgraph_node *cnode;
- FOR_EACH_FUNCTION_WITH_GIMPLE_BODY (cnode)
+ FOR_EACH_FUNCTION/*_WITH_GIMPLE_BODY*/ (cnode)
(*debug_hooks->early_global_decl) (cnode->decl);
/* Clean up anything that needs cleaning up after initial debug
The effect on debug info size would need to be evaluated (I'll check
GCC itself for this).
[Bug rtl-optimization/96388] scheduling takes forever with -fPIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96388 Martin Liška changed: What|Removed |Added CC||uros at gcc dot gnu.org --- Comment #5 from Martin Liška --- Started with r9-2469-gc6067437d314f803.
[Bug tree-optimization/96370] ICE with -ffast-math since r7-950-g8a85cee26eabf5cf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96370
--- Comment #5 from Richard Biener ---
OK, so rewrite_expr_tree isn't prepared to see ops with a three component
"leaf" as try_special_add_to_ops produces which turns { -b, b } into
{ b, b, -1 }. Instead it recurses into the apperant non-leaf _1 which
is the negate.
/* Recurse on the LHS of the binary operator, which is guaranteed to
be the non-leaf side. */
tree new_rhs1
= rewrite_expr_tree (SSA_NAME_DEF_STMT (rhs1), opindex + 1, ops,
changed || oe->op != rhs2 || next_changed,
false);
But I have a simple fix.
[Bug tree-optimization/96370] ICE with -ffast-math since r7-950-g8a85cee26eabf5cf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96370
--- Comment #4 from Richard Biener ---
More "complete" testcase:
void c(_Decimal128);
void a(_Decimal128 b)
{
c(-b * b);
}
[Bug rtl-optimization/96388] scheduling takes forever with -fPIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96388 Martin Liška changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2020-07-30 CC||marxin at gcc dot gnu.org Status|UNCONFIRMED |NEW --- Comment #4 from Martin Liška --- Bisecting that..
[Bug fortran/96386] Internal compiler error in ASSOCIATE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96386 Martin Liška changed: What|Removed |Added Last reconfirmed||2020-07-30 Ever confirmed|0 |1 CC||marxin at gcc dot gnu.org, ||pault at gcc dot gnu.org Status|UNCONFIRMED |NEW --- Comment #1 from Martin Liška --- Confirmed, started with r8-3365-gb89a63b916340ef2.
