[Bug c++/89244] __builtin_is_constant_evaluated not documented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89244 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- Why should it? We don't want people to use it directly, they should use std::is_constant_evaluated () which is documented. We don't document most the C++ magic builtins either (__is_*, __has_*, __builtin_launder), people shouldn't use those directly, they are private APIs between libstdc++ and the compiler.
[Bug tree-optimization/88217] [8 Regression] Compile time and memory hog w/ -O2 -fstrict-enums -fno-tree-forwprop -fno-tree-fre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88217 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||8.2.1 Resolution|--- |FIXED --- Comment #7 from Richard Biener --- Fixed.
[Bug tree-optimization/88217] [8 Regression] Compile time and memory hog w/ -O2 -fstrict-enums -fno-tree-forwprop -fno-tree-fre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88217 --- Comment #6 from Richard Biener --- Author: rguenth Date: Fri Feb 8 07:40:31 2019 New Revision: 268665 URL: https://gcc.gnu.org/viewcvs?rev=268665=gcc=rev Log: 2019-02-08 Richard Biener Backport from mainline 2018-12-10 Richard Biener PR tree-optimization/88427 * vr-values.c (vr_values::extract_range_from_phi_node): Handle symbolic ranges conservatively when trying to drop to Inf +- 1. * gcc.dg/pr88427.c: New testcase. 2018-11-28 Richard Biener PR tree-optimization/88217 * vr-values.c (vr_values::extract_range_from_phi_node): Make sure to handle results > +INF and < -INF correctly when trying to drop down to +INF - 1 or -INF + 1. * g++.dg/pr88217.C: New testcase. 2018-11-23 Richard Biener PR tree-optimization/88149 * tree-vect-slp.c (vect_slp_analyze_node_operations): Detect the case where there are two different def types for the same operand at different operand position in the same stmt. * g++.dg/torture/pr88149.C: New testcase. Added: branches/gcc-8-branch/gcc/testsuite/g++.dg/pr88217.C branches/gcc-8-branch/gcc/testsuite/g++.dg/torture/pr88149.C branches/gcc-8-branch/gcc/testsuite/gcc.dg/pr88427.c Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/testsuite/ChangeLog branches/gcc-8-branch/gcc/tree-vect-slp.c branches/gcc-8-branch/gcc/vr-values.c
[Bug tree-optimization/88149] [7/8 Regression] ICE in vect_transform_stmt since r265959
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88149 --- Comment #15 from Richard Biener --- Author: rguenth Date: Fri Feb 8 07:40:31 2019 New Revision: 268665 URL: https://gcc.gnu.org/viewcvs?rev=268665=gcc=rev Log: 2019-02-08 Richard Biener Backport from mainline 2018-12-10 Richard Biener PR tree-optimization/88427 * vr-values.c (vr_values::extract_range_from_phi_node): Handle symbolic ranges conservatively when trying to drop to Inf +- 1. * gcc.dg/pr88427.c: New testcase. 2018-11-28 Richard Biener PR tree-optimization/88217 * vr-values.c (vr_values::extract_range_from_phi_node): Make sure to handle results > +INF and < -INF correctly when trying to drop down to +INF - 1 or -INF + 1. * g++.dg/pr88217.C: New testcase. 2018-11-23 Richard Biener PR tree-optimization/88149 * tree-vect-slp.c (vect_slp_analyze_node_operations): Detect the case where there are two different def types for the same operand at different operand position in the same stmt. * g++.dg/torture/pr88149.C: New testcase. Added: branches/gcc-8-branch/gcc/testsuite/g++.dg/pr88217.C branches/gcc-8-branch/gcc/testsuite/g++.dg/torture/pr88149.C branches/gcc-8-branch/gcc/testsuite/gcc.dg/pr88427.c Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/testsuite/ChangeLog branches/gcc-8-branch/gcc/tree-vect-slp.c branches/gcc-8-branch/gcc/vr-values.c
[Bug tree-optimization/88427] [9 Regression] ICE: tree check: expected integer_cst, have plus_expr in get_len, at tree.h:5617
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88427 --- Comment #6 from Richard Biener --- Author: rguenth Date: Fri Feb 8 07:40:31 2019 New Revision: 268665 URL: https://gcc.gnu.org/viewcvs?rev=268665=gcc=rev Log: 2019-02-08 Richard Biener Backport from mainline 2018-12-10 Richard Biener PR tree-optimization/88427 * vr-values.c (vr_values::extract_range_from_phi_node): Handle symbolic ranges conservatively when trying to drop to Inf +- 1. * gcc.dg/pr88427.c: New testcase. 2018-11-28 Richard Biener PR tree-optimization/88217 * vr-values.c (vr_values::extract_range_from_phi_node): Make sure to handle results > +INF and < -INF correctly when trying to drop down to +INF - 1 or -INF + 1. * g++.dg/pr88217.C: New testcase. 2018-11-23 Richard Biener PR tree-optimization/88149 * tree-vect-slp.c (vect_slp_analyze_node_operations): Detect the case where there are two different def types for the same operand at different operand position in the same stmt. * g++.dg/torture/pr88149.C: New testcase. Added: branches/gcc-8-branch/gcc/testsuite/g++.dg/pr88217.C branches/gcc-8-branch/gcc/testsuite/g++.dg/torture/pr88149.C branches/gcc-8-branch/gcc/testsuite/gcc.dg/pr88427.c Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/testsuite/ChangeLog branches/gcc-8-branch/gcc/tree-vect-slp.c branches/gcc-8-branch/gcc/vr-values.c
[Bug target/84762] GCC for PowerPC32 violates the SysV ABI spec for small struct returns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84762 Lokesh Janghel changed: What|Removed |Added CC||lokeshjanghel91 at gmail dot com --- Comment #15 from Lokesh Janghel --- Created attachment 45639 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45639=edit Patch with new option for LSB & MSB
[Bug libbacktrace/78063] libbacktrace fails to handle cross CU DW_AT_abstract_origin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78063 --- Comment #7 from Tom de Vries --- Author: vries Date: Fri Feb 8 05:55:44 2019 New Revision: 268663 URL: https://gcc.gnu.org/viewcvs?rev=268663=gcc=rev Log: [libbacktrace] Handle DW_FORM_ref_addr Add handling of the DW_FORM_ref_addr encoding to libbacktrace. 2019-02-08 Tom de Vries PR libbacktrace/78063 * dwarf.c (build_address_map): Keep all parsed units. (read_referenced_name_from_attr): Handle DW_FORM_ref_addr. Modified: trunk/libbacktrace/ChangeLog trunk/libbacktrace/dwarf.c
[Bug lto/89246] New: LTO produces references to cloned symbols which the compiler failed to clone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89246
Bug ID: 89246
Summary: LTO produces references to cloned symbols which the
compiler failed to clone
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: link-failure, lto
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
CC: marxin at gcc dot gnu.org
Target Milestone: ---
Target: x86_64-pc-linux-gnu
I suspect this PR is just a user error in the first place, as ones ignores a
compiler warning here and also bars the compiler from performing proper
analysis of the program.
The symptom is that during LTO, under certain circumstances gcc still emits
references to functions that should have been cloned but turned out to be
impossible to clone:
int
u0 (int z5)
{
return z5;
}
#pragma omp declare simd
int
d6 (__int128 tn __attribute__ ((unused)))
{
return u0 (0) + u0 (0) + u0 (0);
}
#pragma omp declare simd
int
k4 (void)
{
return u0 (0) + u0 (0) + d6 (0);
}
int
main (void)
{
return d6 (0) + d6 (0) + k4 () + k4 ();
}
% x86_64-pc-linux-gnu-gcc-9.0.0-alpha20190203 -O1 -flto -fopenmp-simd
-fno-ipa-pure-const --param lto-min-partition=7 ui2rn7yh.c
ui2rn7yh.c:9:1: warning: unsupported argument type '__int128' for simd
9 | d6 (__int128 tn)
| ^
/tmp/ccU4vevn.ltrans1.ltrans.o::function _ZGVbN4_k4: error:
undefined reference to '_ZGVbN4v_d6'
/tmp/ccU4vevn.ltrans1.ltrans.o::function _ZGVcN4_k4: error:
undefined reference to '_ZGVcN4v_d6'
/tmp/ccU4vevn.ltrans1.ltrans.o::function _ZGVdN8_k4: error:
undefined reference to '_ZGVdN8v_d6'
/tmp/ccU4vevn.ltrans1.ltrans.o::function _ZGVeN16_k4: error:
undefined reference to '_ZGVeN16v_d6'
collect2: error: ld returned 1 exit status
Removing "#pragma omp declare simd" annotation from d6() definition, or
omitting -flto or -fno-ipa-pure-const from the command line, or increasing
--param lto-min-partition value, obviously, resolves the link failure.
[Bug c++/52830] ICE: "canonical types differ for identical types ..." when attempting SFINAE with member type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52830 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #6 from Marek Polacek --- ICEs with current trunk still.
[Bug c++/89217] [9 Regression] ICE tree check: expected constructor, have error_mark in split_nonconstant_init_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89217 Marek Polacek changed: What|Removed |Added Keywords||patch --- Comment #6 from Marek Polacek --- https://gcc.gnu.org/ml/gcc-patches/2019-02/msg00412.html
[Bug c/89051] -Wno-error= does not work for warning groups
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89051 --- Comment #2 from m101010a at gmail dot com --- (In reply to Martin Sebor from comment #1) > I don't think GCC has an internal representation of warning groups It has to have some representation, because it can tell which warning group is more specific (the documentation specifically mentions this, and it works in practice). That representation might be able to be re-used to mark which groups are also errors.
[Bug target/89245] New: [MIPS] v1 is assigned in jalr delay slot for later use at -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89245 Bug ID: 89245 Summary: [MIPS] v1 is assigned in jalr delay slot for later use at -Os Product: gcc Version: 8.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: i...@mobile-stream.com Target Milestone: --- Created attachment 45638 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45638=edit preprocessed LuaJIT-2.1.0-beta3/src/lj_asm.c command line: gcc -mips32r2 -mhard-float -fPIC -Os lj_asm.i generated assembly (asm_href): lw $2,40($sp) andi$6,$2,0x1f $L942: jalr$25 li $3,-1944125440 # 0x8c1f lw $4,256($16) addiu $3,$3,12 where $25 is loaded earlier with the address of emit_tsi.isra.2 (which mangles $3). the problem goes away with "-Os -fschedule-insns" (i.e. like at -O2) or "-Os -fno-schedule-insns2". "-fno-ipa-sra" changes nothing. also happens with gcc-6 (codescape-2018.09-03 or debian stretch mipsel) and gcc-7 (codescape-2018.11-01).
[Bug fortran/81552] -finit-integer=n is restricted to 32-bit INTEGER.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81552 Dominique d'Humieres changed: What|Removed |Added Status|NEW |WAITING --- Comment #2 from Dominique d'Humieres --- IMO this PR should be closed as WONTFIX.
[Bug fortran/68940] -Wno-error=compare-reals not working
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68940 Dominique d'Humieres changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Dominique d'Humieres --- AFAICT this has been fixed for GCC7 up to trunk (9.0), closing.
[Bug c++/88977] __builtin_is_constant_evaluated() as function template argument causes substitution failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88977
--- Comment #2 from Martin Sebor ---
I had missed the example is missing a semicolon after the definition of X (the
error could use improvement). With the semicolon added, the example is
accepted (it's even in the test suite).
The equivalent that isn't accepted but I believe should be is the following:
$ cat pr88977.C && gcc -S -Wall pr88977.C
template constexpr bool f() { return B; }
static_assert (f<__builtin_is_constant_evaluated()>());
pr88977.C:2:53: error: no matching function for call to
‘f<__builtin_is_constant_evaluated()>()’
2 | static_assert (f<__builtin_is_constant_evaluated()>());
| ^
pr88977.C:1:34: note: candidate: ‘template constexpr bool f()’
1 | template constexpr bool f() { return B; }
| ^
pr88977.C:1:34: note: template argument deduction/substitution failed:
[Bug target/87532] bad results from vec_extract(unsigned char, foo) dependent upon function inline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87532
--- Comment #11 from Bill Schmidt ---
Let me take back what I said earlier. We've had full support for vec_extract
with a variable second argument for quite a long time. So let me try again
responding to comment #4.
We have special-case code for ALTIVEC_BUILTIN_VEC_EXTRACT in rs6000-c.c when
handling overloaded built-ins. There is short-circuit code there for cases
where the second argument is a constant and in-range, as well for cases where
the second argument is variable and we have a direct-move instruction
available. In all other cases, we are supposed to expand this code into
address arithmetic:
/* Build *(((arg1_inner_type*)&(vector type){arg1})+arg2). */
But the fact that you are seeing the error message about the selector being out
of range indicates that we are expanding the vector built-in via rs6000.c:
altivec_expand_builtin, which in turn means that rs6000_overloaded_builtin_p
failed to expand the call.
We need to understand why the code in altivec_resolve_overloaded_builtin is not
being expanded as expected. So please set a breakpoint there and look at the
fndecl to see what's going on.
[Bug tree-optimization/89235] [9 Regression] ICE: tree check: expected block, have in inlining_chain_to_json, at optinfo-emit-json.cc:285
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89235 David Malcolm changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from David Malcolm --- Should be fixed by r268659.
[Bug tree-optimization/86637] [9 Regression] ICE: tree check: expected block, have in inlining_chain_to_json, at optinfo-emit-json.cc:293
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86637 --- Comment #13 from David Malcolm --- Author: dmalcolm Date: Thu Feb 7 23:00:18 2019 New Revision: 268659 URL: https://gcc.gnu.org/viewcvs?rev=268659=gcc=rev Log: Fix more ICEs in -fsave-optimization-record (PR tree-optimization/89235) PR tree-optimization/89235 reports an ICE inside -fsave-optimization-record whilst reporting the inlining chain of of the location_t in the vect_location global. This is very similar to PR tree-optimization/86637, fixed in r266821. The issue is that the inlining chains are read from the location_t's ad-hoc data, referencing GC-managed tree blocks, but the former are not GC roots; it's simply assumed that old locations referencing dead blocks never get used again. The fix is to reset the "vect_location" global in more places. Given that is a somewhat subtle detail, the patch adds a sentinel class to reset vect_location at the end of a scope. Doing it as a class simplifies the task of ensuring that the global is reset on every exit path from a function, and also gives a good place to signpost the above subtlety (in the documentation for the class). The patch also adds test cases for both of the PRs mentioned above. gcc/testsuite/ChangeLog: PR tree-optimization/86637 PR tree-optimization/89235 * gcc.c-torture/compile/pr86637-1.c: New test. * gcc.c-torture/compile/pr86637-2.c: New test. * gcc.c-torture/compile/pr86637-3.c: New test. * gcc.c-torture/compile/pr89235.c: New test. gcc/ChangeLog: PR tree-optimization/86637 PR tree-optimization/89235 * tree-vect-loop.c (optimize_mask_stores): Add an auto_purge_vect_location sentinel to ensure that vect_location is purged on exit. * tree-vectorizer.c (auto_purge_vect_location::~auto_purge_vect_location): New dtor. (try_vectorize_loop_1): Add an auto_purge_vect_location sentinel to ensure that vect_location is purged on exit. (pass_slp_vectorize::execute): Likewise, replacing the manual reset. * tree-vectorizer.h (class auto_purge_vect_location): New class. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr86637-1.c trunk/gcc/testsuite/gcc.c-torture/compile/pr86637-2.c trunk/gcc/testsuite/gcc.c-torture/compile/pr86637-3.c trunk/gcc/testsuite/gcc.c-torture/compile/pr89235.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-loop.c trunk/gcc/tree-vectorizer.c trunk/gcc/tree-vectorizer.h
[Bug c++/88977] __builtin_is_constant_evaluated() as function template argument causes substitution failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88977
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2019-02-07
CC||msebor at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Martin Sebor ---
The first example in the Wording Changes in P0595R1:
template struct X {}
X x; // type X
makes it clear that the intent is for the function to evaluate to true in the
context of a non-type template argument, but GCC rejects it as well:
$ cat pr88977.C && gcc -S -Wall -std=c++2a pr88977.C
template struct X {}
X<__builtin_is_constant_evaluated()> x; // type X
pr88977.C:2:1: error: a class template declaration must not declare anything
else
2 | X<__builtin_is_constant_evaluated()> x; // type X
| ^
[Bug tree-optimization/89235] [9 Regression] ICE: tree check: expected block, have in inlining_chain_to_json, at optinfo-emit-json.cc:285
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89235 --- Comment #4 from David Malcolm --- Author: dmalcolm Date: Thu Feb 7 23:00:18 2019 New Revision: 268659 URL: https://gcc.gnu.org/viewcvs?rev=268659=gcc=rev Log: Fix more ICEs in -fsave-optimization-record (PR tree-optimization/89235) PR tree-optimization/89235 reports an ICE inside -fsave-optimization-record whilst reporting the inlining chain of of the location_t in the vect_location global. This is very similar to PR tree-optimization/86637, fixed in r266821. The issue is that the inlining chains are read from the location_t's ad-hoc data, referencing GC-managed tree blocks, but the former are not GC roots; it's simply assumed that old locations referencing dead blocks never get used again. The fix is to reset the "vect_location" global in more places. Given that is a somewhat subtle detail, the patch adds a sentinel class to reset vect_location at the end of a scope. Doing it as a class simplifies the task of ensuring that the global is reset on every exit path from a function, and also gives a good place to signpost the above subtlety (in the documentation for the class). The patch also adds test cases for both of the PRs mentioned above. gcc/testsuite/ChangeLog: PR tree-optimization/86637 PR tree-optimization/89235 * gcc.c-torture/compile/pr86637-1.c: New test. * gcc.c-torture/compile/pr86637-2.c: New test. * gcc.c-torture/compile/pr86637-3.c: New test. * gcc.c-torture/compile/pr89235.c: New test. gcc/ChangeLog: PR tree-optimization/86637 PR tree-optimization/89235 * tree-vect-loop.c (optimize_mask_stores): Add an auto_purge_vect_location sentinel to ensure that vect_location is purged on exit. * tree-vectorizer.c (auto_purge_vect_location::~auto_purge_vect_location): New dtor. (try_vectorize_loop_1): Add an auto_purge_vect_location sentinel to ensure that vect_location is purged on exit. (pass_slp_vectorize::execute): Likewise, replacing the manual reset. * tree-vectorizer.h (class auto_purge_vect_location): New class. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr86637-1.c trunk/gcc/testsuite/gcc.c-torture/compile/pr86637-2.c trunk/gcc/testsuite/gcc.c-torture/compile/pr86637-3.c trunk/gcc/testsuite/gcc.c-torture/compile/pr89235.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-loop.c trunk/gcc/tree-vectorizer.c trunk/gcc/tree-vectorizer.h
[Bug c++/89244] New: __builtin_is_constant_evaluated not documented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89244 Bug ID: 89244 Summary: __builtin_is_constant_evaluated not documented Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: msebor at gcc dot gnu.org Target Milestone: --- __builtin_is_constant_evaluated added in r263392 to support std::is_constant_evaluated() does not appear to be documented.
[Bug target/87532] bad results from vec_extract(unsigned char, foo) dependent upon function inline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87532 --- Comment #10 from Bill Schmidt --- Hm. Hang on while I look at some history.
[Bug target/69061] Huge (~7GB of them) Static arrays are not fully usable on Darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69061 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-02-07 CC||iains at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #4 from Dominique d'Humieres --- Still present on x86_64-apple-darwin18.2, Xcode 10.1.
[Bug sanitizer/88997] Implicit constructors created with line numbers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88997 Martin Sebor changed: What|Removed |Added CC||dodji at gcc dot gnu.org, ||dvyukov at gcc dot gnu.org, ||jakub at gcc dot gnu.org, ||kcc at gcc dot gnu.org, ||marxin at gcc dot gnu.org, ||msebor at gcc dot gnu.org Component|c++ |sanitizer Severity|normal |enhancement --- Comment #1 from Martin Sebor --- This sounds like a sanitizer enhancement. No idea how feasible it is.
[Bug c++/89011] member function pointer template argument with initialization by constant generates ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89011 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2019-02-07 CC||msebor at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Martin Sebor --- I can't reproduce the ICE with a native GCC (any version) and a cross-GCC for x86_64-w64-mingw32 fails build for me. Can you try again with a recent version of GCC and/or confirm that this is target-specific?
[Bug c++/89050] GCC sometimes requires this to be captured when doing overload resolution but selecting a static member function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89050 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-02-07 CC||msebor at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Sebor --- Confirmed. Clang and ICC like the code but Visual C++ has this to say: x.cpp(6): warning C4573: the usage of 'A::f' requires the compiler to capture 'this' but the current default capture mode does not allow it x.cpp(5): note: while compiling class template member function 'void A::foo(void)' x.cpp(11): note: see reference to function template instantiation 'void A::foo(void)' being compiled x.cpp(11): note: see reference to class template instantiation 'A' being compiled
[Bug c/89051] -Wno-error= does not work for warning groups
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89051 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-02-07 CC||msebor at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Sebor --- It works as expected in Clang so I'd say it would make sense to try to make it work the same in GCC. I don't think GCC has an internal representation of warning groups (-Wimplicit is just an option that turns on -Wimplicit-int and -Wimplicit-function-declaration), so implementing it in a clean way without hardcoding these relationships in the code would mean adding such a representation.
[Bug c++/89074] valid pointer equality constexpr comparison rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89074 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-02-07 CC||msebor at gcc dot gnu.org Ever confirmed|0 |1 Known to fail||6.4.0, 7.3.0, 8.2.0, 9.0 --- Comment #1 from Martin Sebor --- Confirmed. Not a regression.
[Bug c++/82877] negative array index accepted in a pointer difference expression in constexpr context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82877
--- Comment #2 from Martin Sebor ---
Clang issues the expected errors, as does ICC:
$ clang -S pr82877.C
pr82877.C:1:15: error: constexpr function never produces a constant expression
[-Winvalid-constexpr]
constexpr int f ()
^
pr82877.C:6:21: note: cannot refer to element -1 of array of 1 element in a
constant expression
return [0] - [-1]; // undefined, should be rejected
^
pr82877.C:6:21: warning: array index -1 is before the beginning of the array
[-Warray-bounds]
return [0] - [-1]; // undefined, should be rejected
^ ~~
pr82877.C:3:14: note: array 'a' declared here
struct S { int a[1]; };
^
pr82877.C:9:15: error: constexpr variable 'i' must be initialized by a constant
expression
constexpr int i = f ();
^
pr82877.C:6:21: note: cannot refer to element -1 of array of 1 element in a
constant expression
return [0] - [-1]; // undefined, should be rejected
^
pr82877.C:9:19: note: in call to 'f()'
constexpr int i = f ();
^
1 warning and 2 errors generated.
[Bug c++/82877] negative array index accepted in a pointer difference expression in constexpr context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82877 Martin Sebor changed: What|Removed |Added Known to fail||7.3.0, 8.2.0, 9.0 --- Comment #1 from Martin Sebor --- No change in GCC 9.0.
[Bug c++/89149] Out of bounds array access not detected as ill-formed in a constant expression context in some cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89149
Martin Sebor changed:
What|Removed |Added
Keywords||diagnostic
Status|UNCONFIRMED |NEW
Last reconfirmed||2019-02-07
CC||msebor at gcc dot gnu.org
Blocks||56456, 55004
Ever confirmed|0 |1
--- Comment #5 from Martin Sebor ---
Confirmed. The missing diagnostic isn't specific to C++ but also affects C.
The problem is worse in C++ because it requires an error in the constexpr
context.
$ cat pr89149.c && gcc -O2 -S -Wall -Warray-bounds=2
-fdump-tree-optimized=/dev/stdout pr89149.c
int f (void)
{
char a = (&(&(&"abc"[3])[-1])[-2])[5];
return a;
}
int g (void)
{
char a = (&(&(&"abc"[2])[-1])[-3])[4];
return a;
}
pr89149.c: In function ‘f’:
pr89149.c:3:37: warning: array subscript 5 is outside array bounds of ‘char[4]’
[-Warray-bounds]
3 | char a = (&(&(&"abc"[3])[-1])[-2])[5];
|~^~~
;; Function f (f, funcdef_no=0, decl_uid=1906, cgraph_uid=1, symbol_order=0)
f ()
{
char a;
int _3;
[local count: 1073741824]:
a_2 = MEM[(char *)"abc" + 5B];
_3 = (int) a_2;
return _3;
}
;; Function g (g, funcdef_no=1, decl_uid=1910, cgraph_uid=2, symbol_order=1)
g ()
{
[local count: 1073741824]:
return 99;
}
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004
[Bug 55004] [meta-bug] constexpr issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456
[Bug 56456] [meta-bug] bogus/missing -Warray-bounds
[Bug c++/89151] SFINAE-disabled member hides another
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89151 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||msebor at gcc dot gnu.org Resolution|--- |WORKSFORME --- Comment #3 from Martin Sebor --- With the translation unit in attachment 45585 I'm unable to reproduce the errors with either GCC 8 or with trunk. After removing -Werror I get the following output with the command line options in comment #0 and the top of GCC 8 branch: $ gcc -S -Wno-class-memaccess -pipe -fsanitize=address -fno-omit-frame-pointer -ftrapv -std=c++11 -fPIC -g -Wall -pedantic -Wextra -Wformat=2 -Wshadow -Wmissing-include-dirs -Wuninitialized -Wfloat-equal -Wcast-align -Wcast-qual -Wwrite-strings -Wlogical-op -O1 -Wno-error=pragmas -O0 -fstrict-aliasing pr89151.C pr89151.C:1:3: warning: style of line directive is a GCC extension # 1 "bilsett.cc" ^ bilsett.cc:1:3: warning: style of line directive is a GCC extension /home/csabaraduly/wk/hotblack/__build-g++-8.2.0//:1:3: warning: style of line directive is a GCC extension : warning: style of line directive is a GCC extension :1:3: warning: style of line directive is a GCC extension :1:3: warning: style of line directive is a GCC extension bilsett.cc:1:3: warning: style of line directive is a GCC extension bilsett.cc:9:3: warning: style of line directive is a GCC extension
[Bug other/89243] New: ICE in new test case g++.dg/opt/pr89188.C from r268647
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89243 Bug ID: 89243 Summary: ICE in new test case g++.dg/opt/pr89188.C from r268647 Product: gcc Version: 8.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- r268647 | jakub | 2019-02-07 08:55:50 -0600 (Thu, 07 Feb 2019) | 11 lines Backported from mainline 2019-02-05 Jakub Jelinek PR target/89188 * dce.c (delete_unmarked_insns): Don't remove no-op moves if they can throw, non-call exceptions are enabled and we can't delete dead exceptions or alter cfg. Set must_clean if delete_insn_and_edges returns true, don't set it blindly for calls. * g++.dg/opt/pr89188.C: New test. This works on trunk but gives me ICEs with gcc 8. spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-8/gcc/testsuite/g++/../../xg++ -B/home/seurer/gcc/build/gcc-8/gcc/testsuite/g++/../../ /home/seurer/gcc/gcc-8/gcc/testsuite/g++.dg/opt/pr89188.C -fno-diagnostics-show-caret -fdiagnostics-color=never -nostdinc++ -I/home/seurer/gcc/build/gcc-8/powerpc64-unknown-linux-gnu/libstdc++-v3/include/powerpc64-unknown-linux-gnu -I/home/seurer/gcc/build/gcc-8/powerpc64-unknown-linux-gnu/libstdc++-v3/include -I/home/seurer/gcc/gcc-8/libstdc++-v3/libsupc++ -I/home/seurer/gcc/gcc-8/libstdc++-v3/include/backward -I/home/seurer/gcc/gcc-8/libstdc++-v3/testsuite/util -fmessage-length=0 -std=gnu++11 -Og -flive-range-shrinkage -fnon-call-exceptions -S -o pr89188.s during RTL pass: lr_shrinkage /home/seurer/gcc/gcc-8/gcc/testsuite/g++.dg/opt/pr89188.C: In function 'int main()': /home/seurer/gcc/gcc-8/gcc/testsuite/g++.dg/opt/pr89188.C:13:1: internal compiler error: in pre_and_rev_post_order_compute, at cfganal.c:1055 0x1041dc13 pre_and_rev_post_order_compute(int*, int*, bool) /home/seurer/gcc/gcc-8/gcc/cfganal.c:1054 0x103e4b0f init_alias_analysis() /home/seurer/gcc/gcc-8/gcc/alias.c:3325 0x1115843b sched_init() /home/seurer/gcc/gcc-8/gcc/haifa-sched.c:7289 0x1115a3cf haifa_sched_init() /home/seurer/gcc/gcc-8/gcc/haifa-sched.c:7326 0x1088e293 schedule_insns() /home/seurer/gcc/gcc-8/gcc/sched-rgn.c:3507 0x1088eaaf schedule_insns() /home/seurer/gcc/gcc-8/gcc/sched-rgn.c:3501 0x1088eaaf rest_of_handle_live_range_shrinkage /home/seurer/gcc/gcc-8/gcc/sched-rgn.c:3704 0x1088eaaf execute /home/seurer/gcc/gcc-8/gcc/sched-rgn.c:3791
[Bug c/89153] internal compiler error: in assign_stack_local_1, at function.c:409
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89153 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2019-02-07 CC||msebor at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #3 from Martin Sebor --- If you reproduce this error with a supported release please provide an updated test case/translation unit and command line option used to trigger it.
[Bug c++/89231] Bogus "ambiguous template instantiation" error for variadic nested class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89231 Martin Sebor changed: What|Removed |Added Keywords||rejects-valid Status|UNCONFIRMED |NEW Last reconfirmed||2019-02-07 CC||msebor at gcc dot gnu.org Ever confirmed|0 |1 Known to fail||6.4.0, 7.3.0, 8.2.0, 9.0 --- Comment #1 from Martin Sebor --- Confirmed. Fails as far back as GCC 6. Doesn't appear to be a regression. The error seems to be triggered by struct A being a variadic template (it disappears when it's an ordinary template).
[Bug c++/89237] Partial specialization incorrectly marked as ambiguous
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89237
Martin Sebor changed:
What|Removed |Added
Keywords||rejects-valid
Status|UNCONFIRMED |NEW
Last reconfirmed||2019-02-07
CC||msebor at gcc dot gnu.org
Ever confirmed|0 |1
Known to fail||6.4.0, 7.3.0, 8.2.0, 9.0
--- Comment #1 from Martin Sebor ---
Confirmed with the test case below (please be sure to include the compiler
output). Not a regression.
Clang rejects it with the same error in C++ 98 mode so I wonder if the GCC
error is because of some yet-to-be implemented language change.
$ cat pr89237.C && /build/gcc-svn/gcc/xgcc -B /build/gcc-svn/gcc -S -Wall
pr89237.C
template struct enable_if {};
template struct enable_if { typedef T type; };
template struct S;
template struct S::type> {};
template struct S {};
int main() { S s; }
pr89237.C: In function ‘int main()’:
pr89237.C:8:23: error: ambiguous template instantiation for ‘struct S’
8 | int main() { S s; }
| ^
pr89237.C:5:30: note: candidates are: ‘template struct S::type> [with T = int*]’
5 | template struct S::type>
{};
| ^
pr89237.C:6:30: note: ‘template struct S [with T =
int]’
6 | template struct S {};
| ^~
pr89237.C:8:23: error: aggregate ‘S s’ has incomplete type and cannot be
defined
8 | int main() { S s; }
| ^
[Bug tree-optimization/83581] [8 Regression] ICE in expand_LOOP_VECTORIZED, at internal-fn.c:2397
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83581 --- Comment #7 from Arseny Solokha --- (In reply to Shubham Narlawar from comment #5) > Is this the same bug as above filed? Please don't hijack random PRs resolved w/ proper fixes long ago. There's one open PR filed for an ICE in expand_LOOP_VECTORIZED as for now, which you can amend if you're absolutely sure that your testcase exposes the same problem as the one reported there. Otherwise, just file a new PR. A report resolved as duplicate by developers is always better than a report which clutters another unrelated PR. BTW, your testcase doesn't fail for me on the current trunk, which probably means it has been fixed or made latent on the trunk already and that fix has to be identified first.
[Bug tree-optimization/89235] [9 Regression] ICE: tree check: expected block, have in inlining_chain_to_json, at optinfo-emit-json.cc:285
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89235 --- Comment #3 from David Malcolm --- Candidate patch: https://gcc.gnu.org/ml/gcc-patches/2019-02/msg00402.html
[Bug tree-optimization/83581] [8 Regression] ICE in expand_LOOP_VECTORIZED, at internal-fn.c:2397
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83581 --- Comment #6 from Shubham Narlawar --- Created attachment 45637 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45637=edit Preprocessed code of file named "work23_crash1.c" internal compiler error: in expand_LOOP_VECTORIZED, at internal-fn.c:2409 --COMPILE OPTIONS gcc -w work23_crash1.c.orig -O3 Target: x86_64-pc-linux-gnu Configured with: ../gcc-8.2.0/configure --enable-languages=c,c++ --enable-lto --disable-bootstrap Thread model: posix gcc version 8.2.0 (GCC)
[Bug tree-optimization/83581] [8 Regression] ICE in expand_LOOP_VECTORIZED, at internal-fn.c:2397
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83581
Shubham Narlawar changed:
What|Removed |Added
CC||gsocshubham at gmail dot com
--- Comment #5 from Shubham Narlawar ---
I got an ICE as below on gcc-8.2 at optimization -O3 as below-
internal compiler error: in expand_LOOP_VECTORIZED, at internal-fn.c:2409
--REDUCED CODE
a;
b() {
void *c = &
for (;;)
d:
if (a)
;
else
a = ({ 0 < b; });
}
Is this the same bug as above filed? If it is fixed on gcc-8.0, what causes ICE
on gcc-8.2?
[Bug fortran/89236] Intrinsic documentation changes for intrinsics affected by GNU extension
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89236 Dominique d'Humieres changed: What|Removed |Added Priority|P3 |P5 Status|WAITING |NEW Blocks||89078 Severity|normal |enhancement Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89078 [Bug 89078] [meta-bug] Improve the gfortran manual
[Bug target/89229] [7/8/9 Regression] Unnecessary ZMM in movoi_internal_avx/movti_internal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89229 --- Comment #3 from hjl at gcc dot gnu.org --- Author: hjl Date: Thu Feb 7 17:58:19 2019 New Revision: 268657 URL: https://gcc.gnu.org/viewcvs?rev=268657=gcc=rev Log: i386: Fix typo in *movoi_internal_avx/movti_internal PR target/89229 * config/i386/i386.md (*movoi_internal_avx): Set mode to OI for TARGET_AVX512VL. (*movti_internal): Set mode to TI for TARGET_AVX512VL. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.md
[Bug tree-optimization/54855] Unnecessary duplication when performing scalar operation on vector element
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54855 H.J. Lu changed: What|Removed |Added CC|kirill.yukhin at intel dot com |hjl.tools at gmail dot com, ||ubizjak at gmail dot com --- Comment #9 from H.J. Lu --- A patch is posted at: https://gcc.gnu.org/ml/gcc-patches/2019-02/msg00398.html
[Bug rtl-optimization/89242] New: [7/8/9 Regression] ICE in verify_dominators, at dominance.c:1184 (error: dominator of 7 should be 5, not 2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89242 Bug ID: 89242 Summary: [7/8/9 Regression] ICE in verify_dominators, at dominance.c:1184 (error: dominator of 7 should be 5, not 2) Product: gcc Version: 9.0 Status: UNCONFIRMED Keywords: EH, ice-checking, ice-on-valid-code Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: asolokha at gmx dot com Target Milestone: --- g++-9.0.0-alpha20190203 snapshot (r268503) ICEs when compiling gcc/testsuite/g++.dg/opt/pr47280.C w/ -O2 (-O3, -Ofast, -Os) -fdelete-dead-exceptions -fnon-call-exceptions -ftrapv -fno-rerun-cse-after-loop -fno-forward-propagate -fno-tree-loop-optimize: % g++-9.0.0-alpha20190203 -O2 -fdelete-dead-exceptions -fnon-call-exceptions -ftrapv -fno-rerun-cse-after-loop -fno-forward-propagate -fno-tree-loop-optimize -c gcc/testsuite/g++.dg/opt/pr47280.C gcc/testsuite/g++.dg/opt/pr47280.C: In function 'void bar(int, char*)': gcc/testsuite/g++.dg/opt/pr47280.C:14:1: error: dominator of 7 should be 5, not 2 14 | } | ^ during RTL pass: ce2 gcc/testsuite/g++.dg/opt/pr47280.C:14:1: internal compiler error: in verify_dominators, at dominance.c:1184 0x6b99b0 verify_dominators(cdi_direction) /var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190203/work/gcc-9-20190203/gcc/dominance.c:1184 0xbbdcbe checking_verify_dominators /var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190203/work/gcc-9-20190203/gcc/dominance.h:76 0xbbdcbe calculate_dominance_info(cdi_direction) /var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190203/work/gcc-9-20190203/gcc/dominance.c:717 0xb52de2 flow_loops_find(loops*) /var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190203/work/gcc-9-20190203/gcc/cfgloop.c:431 0xe0221e loop_optimizer_init(unsigned int) /var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190203/work/gcc-9-20190203/gcc/loop-init.c:93 0x1820753 if_convert /var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190203/work/gcc-9-20190203/gcc/ifcvt.c:5374 0x182315d execute /var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190203/work/gcc-9-20190203/gcc/ifcvt.c:5553
[Bug fortran/52789] gfortran sets -Wunused-parameter in the C sense as well as the Fortran sense
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52789 Dominique d'Humieres changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #9 from Dominique d'Humieres --- > Commit a test case and close? Done as revision r268656.
[Bug libfortran/78314] [aarch64] ieee_support_halting does not report unsupported fpu traps correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78314 Steve Ellcey changed: What|Removed |Added CC||sje at gcc dot gnu.org --- Comment #22 from Steve Ellcey --- It looks like the recent checkins are causing gfortran.dg/ieee/ieee_6.f90 to fail on aarch64. Reading through the comments it looks like this isn't a new problem but the failure showing up in the GCC testsuite run is new.
[Bug fortran/52789] gfortran sets -Wunused-parameter in the C sense as well as the Fortran sense
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52789 --- Comment #8 from dominiq at gcc dot gnu.org --- Author: dominiq Date: Thu Feb 7 17:40:29 2019 New Revision: 268656 URL: https://gcc.gnu.org/viewcvs?rev=268656=gcc=rev Log: 2019-02-07 Dominique d'Humieres PR fortran/52789 * gfortran.dg/wunused-parameter_2.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/wunused-parameter_2.f90 Modified: trunk/gcc/testsuite/ChangeLog
[Bug fortran/89240] Discrepancy in the return kind of MAX and MIN between all literal input parameters and input parameters that are variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89240 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-02-07 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Confirmed.
[Bug middle-end/89230] Bogus uninited usage warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89230
Martin Sebor changed:
What|Removed |Added
Keywords||alias
CC||msebor at gcc dot gnu.org
Depends on||81776
--- Comment #4 from Martin Sebor ---
Making GCC aware that printf doesn't modify memory (at least not without %n in
the format string, or without addresses in its argument list) is the subject of
pr81776.
It's hard to tell for sure without more context but a similar (if not the same)
problem can be reproduced in the following test case. Uncommenting the
attribute makes the warning go away because it tells GCC that the pointer
returned from f() and assigned to q does not alias any object in memory, so
printf cannot clobber what it points to. With the test case below, I could
confirm this bug as a dependency of pr81776. But if your case is different
then as Andrew requests, please try to reduce it to a small reproducible test
case to show us what's going on there.
$ cat z.c && gcc -O2 -S -Wall z.c
struct S { int i, j; };
/* attribute__ ((malloc)) */ struct S* f (void);
int g (void)
{
struct S *p = f (), *q;
if (p->i || !(q = f ()) || p->j != q->i)
{
__builtin_printf ("%i", p->i);
if (p->i)
return 1;
if (!q)
return 2;
}
return 0;
}
z.c: In function ‘g’:
z.c:16:9: warning: ‘q’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
16 | if (!q)
| ^
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81776
[Bug 81776] missing sprintf optimization due to pointer escape analysis
[Bug target/87532] bad results from vec_extract(unsigned char, foo) dependent upon function inline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87532
--- Comment #9 from kelvin at gcc dot gnu.org ---
The new tests proposed by as part of this PR represent illegal code and are
properly rejected by the compiler.
However, the compiler is not currently rejecting the following test program
even though the test depends on undefined behavior. This test is defined in
vec-extract.h, which is included by 14 expansions of vec-extract-v*.c.
/* Tests for vec_extract where the vector comes from memory (the compiler can
optimize this by doing a scalar load without having to load the whole
vector). */
RTYPE
get_pointer_n (vector TYPE *p, ssize_t n)
{
return (RTYPE) vec_extract (*p, n);
}
...
void
do_pointer (vector TYPE *p)
{
size_t i;
for (i = 0; i < sizeof (get_pointer_const) / sizeof (get_pointer_const[0]);
i\
++)
{
TRACE ("pointer", i);
check (get_pointer_n (p, i), (get_pointer_const[i]) (p));
}
}
This is the code from which the newly proposed tests were derived.
I am inclined to remove this code from the test suite under the principle that
optimizers should not change the legality of code. If the code is illegal
without optimization, it should still be illegal with optimization. In that
spirit, I would think we do not ever want to allow non-constant values as the
selector argument to vec_extract.
I haven't yet confirmed whether the compiler considers this "legal" only
because it fully unrolls the loop and in-lines get_pointer_n or if it is
considered legal because, given a pointer to a vector, the expansion uses a
different implementation technique than it would use in the case of direct move
for an in-register vector.
If we do consider it legal to use vec_extract with a variable selector on
in-memory vectors, then I would want to make sure the semantics is the same
with regards to modular truncation of the selector expression...
I couldn't resist glancing at the implementation of vec_extract in rs6000-c.c.
I haven't experimented but the following comment around line 6024 causes some
concern:
/* If the second argument is variable, we can optimize it if we are
generating 64-bit code on a machine with direct move. */
Am looking for advice on next steps here.
Am happy to simply close this problem report if that's the right thing to do.
[Bug middle-end/89230] Bogus uninited usage warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89230
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed||2019-02-07
Ever confirmed|0 |1
--- Comment #3 from Andrew Pinski ---
(In reply to lavr from comment #2)
> Okay, but "d" points to a clearly separate storage on stack within a local
> frame. None of the pointers passed to (s)printf() relate to that area
> (either they are also clearly separate within the current stack frame,
> automatic ("name", "type", "temp"); or the argument values, that function
> was called with ("pfx")), so how "d->D_fid[2]" can be changed, in GCC's
> point of view? I mean, within the semantics of the language, that's
> impossible; and the warning should only be issued for that kind of a
> (mis)use.
It is not obvious from your small code snippet that d does not point to a local
struct or if that local struct does not escape.
Without a full testcase (preprocessed source), it is hard to debug this any
further.
[Bug tree-optimization/89223] [7/8/9 Regression] internal compiler error: in int_cst_value, at tree.c:11226
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89223 --- Comment #10 from Jakub Jelinek --- The #c9 patch looks good, but I don't view #c5 as papering over issues, but rather as an optimization and desirable change. The expansion of ARRAY_REFs is done through calling get_inner_reference and expanding the base and offset. And, get_inner_reference does with the index: offset = size_binop (PLUS_EXPR, offset, size_binop (MULT_EXPR, fold_convert (sizetype, index), unit_size)); so, all upper bits beyond TYPE_PRECISION (sizetype) are thrown away. While it is probably desirable for optimization purposes to keep ARRAY_REF indexes with smaller or equal precision than sizetype in whatever type they were originally, I don't see any advantages of pretending we care about the extra bits we ignore in the end, by folding it during gimplification we might generate better code by computing stuff only in narrower types etc. Given above, I'm no longer worried about what it would cause for targets with weird pointer sizes. BTW, e.g. get_addr_base_and_unit_offset_1 doesn't seem to be prepared to handle ARRAY_REF indexes larger than sizetype: poly_offset_int woffset = wi::sext (wi::to_poly_offset (index) - wi::to_poly_offset (low_bound), TYPE_PRECISION (TREE_TYPE (index))); While offset_int is actually 128-bit for efficiency, if we use the full sometimes signed, sometimes unsigned __int128 indexes there, we don't have the always signed bit anyway. Guess the above could be easily changed to MIN (TYPE_PRECISION (TREE_TYPE (index)), TYPE_PRECISION (sizetype)) or similar, but with the gimplifier change it wouldn't be needed (we could later on add verifier that ARRAY*REF indexes aren't wider than sizetype's precision).
[Bug c++/89241] [9 Regression] ICE in enclosing_instantiation_of, at cp/pt.c:13380
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89241 --- Comment #2 from Marek Polacek --- Started with that fix, actually: r268424.
[Bug c++/89241] [9 Regression] ICE in enclosing_instantiation_of, at cp/pt.c:13380
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89241 Marek Polacek changed: What|Removed |Added Target Milestone|--- |9.0 Summary|ICE in |[9 Regression] ICE in |enclosing_instantiation_of, |enclosing_instantiation_of, |at cp/pt.c:13380|at cp/pt.c:13380
[Bug c++/89241] ICE in enclosing_instantiation_of, at cp/pt.c:13380
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89241 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-02-07 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- I thought this was a dup of the PR Jason fixed recently, but it's a new one.
[Bug debug/86964] Too many debug symbols included, especially for extern globals
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86964 --- Comment #6 from Johan.karlsson at enea dot com --- Created attachment 45636 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45636=edit Patch to enable skip unused extern variables. I'm attaching a patch that I've been working on. It loops over the variable pool that contains the used global variables. It grabs the declaration and lookup the DIE of the variable and mark it as used. I've also tweaked the function that loops over all dies so that instead of marking every DW_TAG_variable it only marks the ones that are not extern. With this patch we where able to get similar debug information size to GCC 4.9.2. Right now the functionality is only enabled by adding -feliminate-unused-debug-symbols, it could probably always be enable since I don't think any debug information is lost. -fno-eliminate-unused-debug-types should not be set, because if it is the the functionality is disabled. A bit strange but using that in the first place will generate a bunch of extra debug information anyway.
[Bug c++/89241] New: ICE in enclosing_instantiation_of, at cp/pt.c:13380
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89241
Bug ID: 89241
Summary: ICE in enclosing_instantiation_of, at cp/pt.c:13380
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: larsbj at gullik dot net
Target Milestone: ---
Created attachment 45635
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45635=edit
Reduced sources showing ICE
With the attached reduced from code using Boost.Asio I get this ICE:
g++ -v
Using built-in specs.
COLLECT_GCC=/opt/gcc/gcc-9/bin/g++
COLLECT_LTO_WRAPPER=/opt/gcc/gcc-9/libexec/gcc/x86_64-pc-linux-gnu/9.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --prefix=/opt/gcc/gcc-9
--enable-checking=release --enable-languages=c,c++
Thread model: posix
gcc version 9.0.1 20190207 (experimental) (GCC)
/opt/gcc/gcc-9/bin/g++ -c bug3.cpp
bug3.cpp: In instantiation of ‘o< >::m_fn3() [with
= int]:: [with auto:1 = int;
auto:2 = int]’:
bug3.cpp:4:27: required by substitution of ‘template decltype (g(1,
2)) ag(e) [with e = o< >::m_fn3() [with
= int]::]’
bug3.cpp:8:7: required from ‘void l< >::m(al) [with
al = o< >::m_fn3() [with =
int]::; = int]’
bug3.cpp:30:5: required from ‘void o< >::m_fn3()
[with = int]’
bug3.cpp:33:16: required from here
bug3.cpp:30:39: internal compiler error: in enclosing_instantiation_of, at
cp/pt.c:13380
30 | av[0]->m_fn2().m([](auto, auto) { __PRETTY_FUNCTION__; });
| ^~~
0x5ccba9 enclosing_instantiation_of
../../gcc/gcc/cp/pt.c:13380
0x702ff9 tsubst_copy
../../gcc/gcc/cp/pt.c:15543
0x703a08 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:19345
0x7038f6 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:19475
0x6ff724 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:17805
0x6ff23a tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16925
0x6ff07c tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:17212
0x6fef08 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16911
0x6ff07c tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:17212
0x6ff07c tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:17212
0x6fde6d tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16896
0x6fde6d instantiate_decl(tree_node*, bool, bool)
../../gcc/gcc/cp/pt.c:24584
0x677823 maybe_instantiate_decl
../../gcc/gcc/cp/decl2.c:5281
0x677823 maybe_instantiate_decl
../../gcc/gcc/cp/decl2.c:5265
0x678e08 mark_used(tree_node*, int)
../../gcc/gcc/cp/decl2.c:5437
0x61afde build_over_call
../../gcc/gcc/cp/call.c:8543
0x61de1e build_op_call_1
../../gcc/gcc/cp/call.c:4671
0x61de1e build_op_call(tree_node*, vec**, int)
../../gcc/gcc/cp/call.c:4700
0x72f16f finish_call_expr(tree_node*, vec**, bool,
bool, int)
../../gcc/gcc/cp/semantics.c:2585
0x705cb7 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:18970
[Bug bootstrap/88714] [9 regression] bootstrap comparison failure on armv7l since r265398
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88714 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #43 from Jakub Jelinek --- Fixed.
[Bug rtl-optimization/89225] [9 Regression] LRA hang on ppc64le compiling glibc starting with r268404
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89225 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Jakub Jelinek --- Fixed, thanks.
[Bug tree-optimization/88919] New test case gcc.dg/vect/pr88903-1.c in r268076 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88919 --- Comment #18 from Tamar Christina --- Ah no worries, I was just wondering if there was some explicit action that was wanted from me :)
[Bug go/89019] LTO and gccgo cause ICE during free_lang_data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89019 Nikhil Benesch changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from Nikhil Benesch --- This is fixed for me now.
[Bug tree-optimization/89235] [9 Regression] ICE: tree check: expected block, have in inlining_chain_to_json, at optinfo-emit-json.cc:285
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89235 David Malcolm changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |dmalcolm at gcc dot gnu.org --- Comment #2 from David Malcolm --- I needed "-g" in addition to the options in comment #0 to trigger it. Am investigating.
[Bug fortran/89236] Intrinsic documentation changes for intrinsics affected by GNU extension
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89236 --- Comment #11 from MarkEggleston --- Created attachment 45634 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45634=edit Updated change log for gcc/fortran for patch Change no longer affects MAX and MIN.
[Bug bootstrap/84402] [meta] GCC build system: parallelism bottleneck
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84402 --- Comment #29 from Giuliano Belinassi --- > No, the proper fix would be to split the generated files and compile them in > parallel. Similarly for all the insn-*.c generated files. That would the > proper fix. Indeed. However, I am working on parallelizing the compilation with threads. This may lead to a solution, but may not be the best for this scenario. > Anyway, I like the graph you made :) Thank you. > But what version of GCC is this graph, with what exact configuration? * This is the gcc that I used to build: * Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/8/lto-wrapper OFFLOAD_TARGET_NAMES=nvptx-none OFFLOAD_TARGET_DEFAULT=1 Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 8.2.0-14' --with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr --with-gcc-major-version-only --program-suffix=-8 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie --with-system-zlib --with-target-system-zlib --enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 8.2.0 (Debian 8.2.0-14) * The gcc that I built: * Using built-in specs. COLLECT_GCC=./xgcc Target: x86_64-pc-linux-gnu Configured with: /home/giulianob/gcc_svn/trunk//configure --disable-checking --disable-bootstrap Thread model: posix gcc version 9.0.1 20190205 (experimental) (GCC)
[Bug fortran/89236] Intrinsic documentation changes for intrinsics affected by GNU extension
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89236 MarkEggleston changed: What|Removed |Added Attachment #45629|0 |1 is obsolete|| --- Comment #10 from MarkEggleston --- Created attachment 45633 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45633=edit Reworded and changes for MAX and MIN removed. The changes for MAX and MIN will need to be done when PR fortran/89240 is fixed.
[Bug rtl-optimization/89234] [7/8/9 Regression] ICE in get_eh_region_and_lp_from_rtx at gcc/except.c:1824
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89234 --- Comment #5 from Jakub Jelinek --- Created attachment 45632 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45632=edit gcc9-pr89234.patch Full untested patch.
[Bug tree-optimization/88919] New test case gcc.dg/vect/pr88903-1.c in r268076 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88919 --- Comment #17 from Bill Seurer --- On 02/07/19 09:47, tnfchris at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88919 > > Tamar Christina changed: > > What|Removed |Added > > CC|tamar.christina at arm dot com | > > --- Comment #15 from Tamar Christina --- > You did :) You added my Arm email address, I was already on CC based on my > gcc.gnu email. > > Removing it since I'm getting the mails twice :) > I looked back through my browser history and found this: Bugzilla cannot make a conclusive match for one or more of the names and/or email addresses you entered on the previous page. Please examine the lists of potential matches below and select the ones you want, or go back to the previous page to revise the names you entered. CC: tamar matched: ...list of email addrs including your arm one... I'd never seen this before and just let bugzilla choose. I have no idea why that happened as it was my reply that showed the test cases now succeeding and I did not add to nor change the CC list there. It wasn't my intent to add that email address and I apologize.
[Bug rtl-optimization/89234] [7/8/9 Regression] ICE in get_eh_region_and_lp_from_rtx at gcc/except.c:1824
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89234 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Component|target |rtl-optimization Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Target Milestone|--- |7.5 Summary|ICE in |[7/8/9 Regression] ICE in |get_eh_region_and_lp_from_r |get_eh_region_and_lp_from_r |tx at gcc/except.c:1824 |tx at gcc/except.c:1824 --- Comment #4 from Jakub Jelinek --- Started between r242338 (still works) and r243455 (ICEs already).
[Bug ipa/88755] [9 Regression] ICE in compute_fn_summary, at ipa-fnsummary.c:2513 since r267601
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88755 --- Comment #3 from Jan Hubicka --- tp_sum is function that should be inlined. The problem is that its estimated size after inlining a function call within tp_sum is 75. We used to estimate that the speedup for inlining function is large and thus we bumped limit from 30 to 400 (inline-insns-sinle to -auto). This is no longer the case after fix to the time acocunting, because tp_sum has loop which we now account as iterating 16 times (it is correct) and previously we accounted 1 times (that is bug I fixed). Now the speedup for inlining estimated by inliner is just about 2% which falls bellow to the estimate of 15%. I do not see how to reasonably tel inliner that this is good idea to inline here. So shall we just xfail the testcase? Honza
[Bug tree-optimization/88919] New test case gcc.dg/vect/pr88903-1.c in r268076 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88919 Bill Schmidt changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #16 from Bill Schmidt --- Terrific. Closing as fixed. Thanks, all.
[Bug fortran/89236] Intrinsic documentation changes for intrinsics affected by GNU extension
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89236 --- Comment #9 from MarkEggleston --- (In reply to Thomas Koenig from comment #5) > (In reply to MarkEggleston from comment #3) > > Looks like I missed MIN with literals. > > > > integer(2) :: a2 > > integer(4) :: a4 > > write(*,*) kind(max(7, 9_1)) > > write(*,*) kind(max(7_2, 9)) > > write(*,*) kind(max(a2, a4)) > > write(*,*) kind(min(7_2, 9)) > > write(*,*) kind(min(a2, a4)) > > end > > > > gives > > > >4 > >2 > >4 > >2 > >4 > > > > So there is discrepancy between literal parameters and variables for MAX and > > MIN. > > That is a bug, IMHO. > > In general, I disagree with the statement that a bug can be turned into > a feature by documenting it :-) Submitted as PR fortran/89240
[Bug fortran/89240] New: Discrepancy in the return kind of MAX and MIN between all literal input parameters and input parameters that are variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89240 Bug ID: 89240 Summary: Discrepancy in the return kind of MAX and MIN between all literal input parameters and input parameters that are variables Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: mark.eggleston at codethink dot com Target Milestone: --- Return kind differs when actual arguments are all literals and when they have at least one variable. integer(2) :: a2 integer(4) :: a4 write(*,*) kind(max(7, 9_1)) write(*,*) kind(max(7_2, 9)) write(*,*) kind(max(a2, a4)) write(*,*) kind(min(7_2, 9)) write(*,*) kind(min(a2, a4)) end gives 4 2 4 2 4 So there is discrepancy between literal arguments and variables for MAX and MIN.
[Bug fortran/89236] Intrinsic documentation changes for intrinsics affected by GNU extension
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89236 --- Comment #8 from MarkEggleston --- (In reply to kargl from comment #7) > (In reply to MarkEggleston from comment #0) > > Created attachment 45626 [details] > > Add GNU extension notes to DIM, MOD, MODULO, MAX and MIN > > > > Missing notes regarding GNU extension. > > > > The second parameters of DIM, MOD and MODULO require the addition of: > > > > (As a GNU extension, arguments of different kinds are permitted.) > > > > The kind of the return types of these intrinsics and MAX and MIN, are > > dependent on the larger of the kinds of the input parameters hence the > > addition of: > > > > (As a GNU extension, kind is the largest kind of the input parameters.) > > > > Patch is attached. > > > > For trunk and currently supported compilers. > > A minor nit. Fortran subprograms do not have input parameters > in the sense of C. Instead of "input parameters", it would > be better to use "actual arguments". I'll change the wording.
[Bug fortran/89236] Intrinsic documentation changes for intrinsics affected by GNU extension
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89236 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #7 from kargl at gcc dot gnu.org --- (In reply to MarkEggleston from comment #0) > Created attachment 45626 [details] > Add GNU extension notes to DIM, MOD, MODULO, MAX and MIN > > Missing notes regarding GNU extension. > > The second parameters of DIM, MOD and MODULO require the addition of: > > (As a GNU extension, arguments of different kinds are permitted.) > > The kind of the return types of these intrinsics and MAX and MIN, are > dependent on the larger of the kinds of the input parameters hence the > addition of: > > (As a GNU extension, kind is the largest kind of the input parameters.) > > Patch is attached. > > For trunk and currently supported compilers. A minor nit. Fortran subprograms do not have input parameters in the sense of C. Instead of "input parameters", it would be better to use "actual arguments".
[Bug c++/89239] gcc claims that this expression is not constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89239 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org, ||mpolacek at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- Already 4.6 rejects this, so likely not a regression (4.4 rejected it for other reasons, insufficient C++11 support). Using integer indexes rather than enumeration ones fixes it too.
[Bug middle-end/89230] Bogus uninited usage warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89230
--- Comment #2 from lavr at ncbi dot nlm.nih.gov ---
Okay, but "d" points to a clearly separate storage on stack within a local
frame. None of the pointers passed to (s)printf() relate to that area (either
they are also clearly separate within the current stack frame, automatic
("name", "type", "temp"); or the argument values, that function was called with
("pfx")), so how "d->D_fid[2]" can be changed, in GCC's point of view? I mean,
within the semantics of the language, that's impossible; and the warning should
only be issued for that kind of a (mis)use.
[Bug tree-optimization/88919] New test case gcc.dg/vect/pr88903-1.c in r268076 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88919 Tamar Christina changed: What|Removed |Added CC|tamar.christina at arm dot com | --- Comment #15 from Tamar Christina --- You did :) You added my Arm email address, I was already on CC based on my gcc.gnu email. Removing it since I'm getting the mails twice :)
[Bug target/89229] [7/8/9 Regression] Unnecessary ZMM in movoi_internal_avx/movti_internal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89229 --- Comment #2 from H.J. Lu --- Another problem: (cond [(ior (match_operand 0 "ext_sse_reg_operand") (match_operand 1 "ext_sse_reg_operand")) (const_string "XI") We shouldn't use XI for TARGET_AVX512VL. OI/TI is OK for upper 16 vector registers with TARGET_AVX512VL.
[Bug fortran/89236] Intrinsic documentation changes for intrinsics affected by GNU extension
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89236 --- Comment #6 from MarkEggleston --- (In reply to Thomas Koenig from comment #5) > (In reply to MarkEggleston from comment #3) > > Looks like I missed MIN with literals. > > > > integer(2) :: a2 > > integer(4) :: a4 > > write(*,*) kind(max(7, 9_1)) > > write(*,*) kind(max(7_2, 9)) > > write(*,*) kind(max(a2, a4)) > > write(*,*) kind(min(7_2, 9)) > > write(*,*) kind(min(a2, a4)) > > end > > > > gives > > > >4 > >2 > >4 > >2 > >4 > > > > So there is discrepancy between literal parameters and variables for MAX and > > MIN. > > That is a bug, IMHO. > > In general, I disagree with the statement that a bug can be turned into > a feature by documenting it :-) I agree. I intended to create a PR for it and change the documentation accordingly. I can revert to the earlier wording or remove the extra wording for MIN and MAX. The documentation for MIN and MAX can be updated when the bug is fixed.
[Bug tree-optimization/89238] cc1 hangs after
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89238 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #1 from Jakub Jelinek --- Can't reproduce on current 8 branch, on the trunk this stopped hanging with r262573. *** This bug has been marked as a duplicate of bug 87645 ***
[Bug tree-optimization/87645] [7 Regression] gcc hangs up on vr_values::vrp_visit_assignment_or_call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87645 --- Comment #8 from Jakub Jelinek --- *** Bug 89238 has been marked as a duplicate of this bug. ***
[Bug fortran/89236] Intrinsic documentation changes for intrinsics affected by GNU extension
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89236 Thomas Koenig changed: What|Removed |Added CC||tkoenig at gcc dot gnu.org --- Comment #5 from Thomas Koenig --- (In reply to MarkEggleston from comment #3) > Looks like I missed MIN with literals. > > integer(2) :: a2 > integer(4) :: a4 > write(*,*) kind(max(7, 9_1)) > write(*,*) kind(max(7_2, 9)) > write(*,*) kind(max(a2, a4)) > write(*,*) kind(min(7_2, 9)) > write(*,*) kind(min(a2, a4)) > end > > gives > >4 >2 >4 >2 >4 > > So there is discrepancy between literal parameters and variables for MAX and > MIN. That is a bug, IMHO. In general, I disagree with the statement that a bug can be turned into a feature by documenting it :-)
[Bug tree-optimization/88919] New test case gcc.dg/vect/pr88903-1.c in r268076 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88919 --- Comment #14 from seurer at gcc dot gnu.org --- I did not add you to the CC list.
[Bug tree-optimization/88919] New test case gcc.dg/vect/pr88903-1.c in r268076 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88919 --- Comment #13 from Tamar Christina --- Hmm? I don't understand Bill Seurer, was there something you wanted me to do here?
[Bug rtl-optimization/89195] [7 regression] Corrupted stack offset after combine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89195 Jakub Jelinek changed: What|Removed |Added Summary|[7/8 regression] Corrupted |[7 regression] Corrupted |stack offset after combine |stack offset after combine --- Comment #15 from Jakub Jelinek --- Fixed for 8.3+ too.
[Bug c/89211] [8 Regression] ICE in int_mode_for_mode, at stor-layout.c:403
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89211 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Jakub Jelinek --- Fixed for 8.3+ too.
[Bug c++/89187] [7 Regression] ICE in initialize_argument_information, at calls.c:2023
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89187 Jakub Jelinek changed: What|Removed |Added Summary|[7/8 Regression] ICE in |[7 Regression] ICE in |initialize_argument_informa |initialize_argument_informa |tion, at calls.c:2023 |tion, at calls.c:2023 --- Comment #10 from Jakub Jelinek --- Fixed for 8.3+ too.
[Bug middle-end/89002] [7 Regression] ICE in scan_omp_1_op, at omp-low.c:3166
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89002 Jakub Jelinek changed: What|Removed |Added Summary|[7/8 Regression] ICE in |[7 Regression] ICE in |scan_omp_1_op, at |scan_omp_1_op, at |omp-low.c:3166 |omp-low.c:3166 --- Comment #7 from Jakub Jelinek --- Fixed for 8.3+ too.
[Bug target/88965] powerpc64le vector builtin hits ICE in verify_gimple
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88965 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |8.3 --- Comment #10 from Jakub Jelinek --- Fixed for 8.3+ too.
[Bug c++/88988] [8 Regression] ICE: Segmentation fault (in lookup_name_real_1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88988 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Jakub Jelinek --- Fixed for 8.3+ too.
[Bug middle-end/88968] [8 Regression] Stack overflow in gimplify_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88968 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Jakub Jelinek --- Fixed for 8.3+ too.
[Bug tree-optimization/88964] [8 Regression] ICE in wide_int_to_tree_1, at tree.c:1561
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88964 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #14 from Jakub Jelinek --- Fixed for 8.3+ too.
[Bug c++/88976] [7 Regression] ICE in fold_convert_loc, at fold-const.c:2552
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88976 Jakub Jelinek changed: What|Removed |Added Summary|[7/8 Regression] ICE in |[7 Regression] ICE in |fold_convert_loc, at|fold_convert_loc, at |fold-const.c:2552 |fold-const.c:2552 --- Comment #5 from Jakub Jelinek --- Fixed for 8.3+ too.
[Bug bootstrap/84402] [meta] GCC build system: parallelism bottleneck
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84402 --- Comment #28 from Segher Boessenkool --- But what version of GCC is this graph, with what exact configuration?
[Bug c++/88949] ICE in expand_expr_real_1, at expr.c:10001 with -fopenmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88949 --- Comment #5 from Jakub Jelinek --- Fixed for 8.3+ too.
[Bug target/88906] wrong code with -march=k6 -minline-all-stringops -minline-stringops-dynamically -mmemcpy-strategy=libcall:-1:align and vector argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88906 --- Comment #11 from Jakub Jelinek --- Fixed for 8.3+ too.
[Bug target/88905] [8 Regression] ICE: in decompose, at rtl.h:2253 with -mabm and __builtin_popcountll
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88905 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Jakub Jelinek --- Fixed for 8.3+ too.
[Bug sanitizer/88901] ICE when using -fsanitize=pointer-compare
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88901 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Jakub Jelinek --- Fixed for 8.3+ too.
[Bug target/88734] [8 Regression] AArch64's ACLE intrinsics give an ICE instead of compile error when option mismatch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88734 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #13 from Jakub Jelinek --- Fixed for 8.3+ too.
[Bug fortran/88902] ICE: Segmentation fault (in DFS::DFS_write_tree_body)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88902 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #10 from Jakub Jelinek --- Fixed for 8.3+ too.
