[Bug tree-optimization/43432] Missed vectorization: "complicated access pattern" for increasing and decreasing data indexing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43432 Eric Gallager changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #6 from Eric Gallager --- (In reply to Eric Gallager from comment #5) > (In reply to Eric Gallager from comment #4) > > (In reply to Michael Matz from comment #3) > > > Subject: Bug 43432 > > > > > > Author: matz > > > Date: Fri Sep 17 13:26:43 2010 > > > New Revision: 164367 > > > > > > URL: http://gcc.gnu.org/viewcvs?root=gcc=rev=164367 > > > Log: > > > PR tree-optimization/43432 > > > * tree-vect-data-refs.c (vect_analyze_data_ref_access): > > > Accept backwards consecutive accesses. > > > (vect_create_data_ref_ptr): If step is negative generate > > > decreasing IVs. > > > * tree-vect-stmts.c (vectorizable_store): Reject negative steps. > > > (perm_mask_for_reverse, reverse_vec_elements): New functions. > > > (vectorizable_load): Handle loads with negative steps when easily > > > possible. > > > > > > testsuite/ > > > PR tree-optimization/43432 > > > * lib/target-supports.exp (check_effective_target_vect_perm_byte, > > > check_effective_target_vect_perm_short): New predicates. > > > (check_effective_target_vect_perm): Include x86_64. > > > * gcc.dg/vect/pr43432.c: New test. > > > * gcc.dg/vect/vect-114.c: Adjust. > > > * gcc.dg/vect/vect-15.c: Ditto. > > > * gcc.dg/vect/slp-perm-8.c: Use new predicate. > > > * gcc.dg/vect/slp-perm-9.c: Ditto. > > > > > > Added: > > > trunk/gcc/testsuite/gcc.dg/vect/pr43432.c > > > Modified: > > > trunk/gcc/ChangeLog > > > trunk/gcc/testsuite/ChangeLog > > > trunk/gcc/testsuite/gcc.dg/vect/slp-perm-8.c > > > trunk/gcc/testsuite/gcc.dg/vect/slp-perm-9.c > > > trunk/gcc/testsuite/gcc.dg/vect/vect-114.c > > > trunk/gcc/testsuite/gcc.dg/vect/vect-15.c > > > trunk/gcc/testsuite/lib/target-supports.exp > > > trunk/gcc/tree-vect-data-refs.c > > > trunk/gcc/tree-vect-stmts.c > > > > Did this fix it? > > Putting in WAITING on a reply No reply so I'm going to assume that that fixed it.
[Bug middle-end/45720] [4.6 regression] Revision 164367 miscompiled SPEC CPU 2K
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45720 Bug 45720 depends on bug 43432, which changed state. Bug 43432 Summary: Missed vectorization: "complicated access pattern" for increasing and decreasing data indexing https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43432 What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/45764] [4.6 Regression] wrong code -O2 vs -O3 (problem in vectorizer???)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45764 Bug 45764 depends on bug 43432, which changed state. Bug 43432 Summary: Missed vectorization: "complicated access pattern" for increasing and decreasing data indexing https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43432 What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED
[Bug other/46828] gengtype is not installed, but become a user [plugins with GTY-s] program
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46828 Eric Gallager changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Eric Gallager --- (In reply to Eric Gallager from comment #1) > Pretty sure gengtype is installed now in newer versions Yeah I just rechecked and it's installed; I'm going to close this as FIXED.
[Bug middle-end/87276] New: Buggy code with -O2 in trunk revision 264170: MPFR test tstrtofr fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87276
Bug ID: 87276
Summary: Buggy code with -O2 in trunk revision 264170: MPFR
test tstrtofr fails
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: vincent-gcc at vinc17 dot net
Target Milestone: ---
On Debian x86_64, I get the following failure with
gcc (Debian 20180908-1) 9.0.0 20180908 (experimental) [trunk revision 264170]
This is a regression, as there are no issues with either GCC 8 or with
gcc (Debian 20180822-1) 9.0.0 20180822 (experimental) [trunk revision 263760]
When building the MPFR trunk revision 13165 with
./configure --enable-assert=full CC=gcc-snapshot CFLAGS="-O2"
(no issues with -O or with -O2 -fsanitize=undefined -fno-sanitize-recover), I
get a failure in tstrtofr:
Check overflow failed (2) with:
s=''
x=0
I've modified MPFR's strtofr.c to the following (i.e. adding printf's):
[...]
long read_exp = strtol (str + 1, , 10);
if (endptr != str+1)
str = endptr;
sum =
read_exp < MPFR_EXP_MIN ? (str = endptr, MPFR_EXP_MIN) :
read_exp > MPFR_EXP_MAX ? (str = endptr, MPFR_EXP_MAX) :
(mpfr_exp_t) read_exp;
printf ("%ld %d\n", sum, res);
printf ("%ld\n", pstr->exp_base);
MPFR_SADD_OVERFLOW (sum, sum, pstr->exp_base,
mpfr_exp_t, mpfr_uexp_t,
MPFR_EXP_MIN, MPFR_EXP_MAX,
res = 2, res = 3);
// printf ("%ld %d\n", sum, res);
[...]
and reduced tstrtofr.c to:
#include "mpfr-test.h"
static void
check_overflow (void)
{
mpfr_t x;
char *s;
mpfr_init (x);
mpfr_strtofr (x, "123456789E9223372036854775807", , 0, MPFR_RNDN);
if (s[0] != 0 || !MPFR_IS_INF (x) || !MPFR_IS_POS (x) )
{
printf ("Check overflow failed (2) with:\n s='%s'\n x=", s);
mpfr_dump (x);
exit (1);
}
mpfr_clear (x);
}
int
main (int argc, char *argv[])
{
tests_start_mpfr ();
check_overflow ();
tests_end_mpfr ();
return 0;
}
I get the following failure:
9223372036854775807 1
9
Check overflow failed (2) with:
s=''
x=0
Then, if I uncomment the last printf line, the failure disappears, and I get:
9223372036854775807 1
9
9223372036854775807 2
[Bug c++/87275] unsequenced writes not diagnosed in constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87275
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
--- Comment #1 from Manuel López-Ibáñez ---
The following doesn't warn either:
int f2(bool b) {
int x = 0;
int& r = x;
return (x++) + (r++);
}
It seems the warning cannot see through references.
[Bug fortran/85395] [F03] private clause contained in derived type acquires spurious scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85395 --- Comment #9 from janus at gcc dot gnu.org --- Author: janus Date: Mon Sep 10 21:25:33 2018 New Revision: 264196 URL: https://gcc.gnu.org/viewcvs?rev=264196=gcc=rev Log: fix PR 85395 2018-09-10 Janus Weil PR fortran/85395 * decl.c (match_binding_attributes): Use correct default accessibility for procedure pointer components. 2018-09-10 Janus Weil PR fortran/85395 * gfortran.dg/proc_ptr_comp_52.f90: New test case. Added: trunk/gcc/testsuite/gfortran.dg/proc_ptr_comp_52.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/testsuite/ChangeLog
[Bug middle-end/85872] False positive for -Wmaybe-unitialized (compile-time limit)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85872 Manuel López-Ibáñez changed: What|Removed |Added Last reconfirmed|2018-05-22 00:00:00 |2018-9-10 Summary|False positive for |False positive for |-Wmaybe-unitialized |-Wmaybe-unitialized ||(compile-time limit) --- Comment #3 from Manuel López-Ibáñez --- Possibly worth playing with: #define MAX_NUM_CHAINS 8 #define MAX_CHAIN_LEN 5 #define MAX_POSTDOM_CHECK 8 #define MAX_SWITCH_CASES 40 in gcc/tree-ssa-uninit.c
[Bug tree-optimization/18501] [6/7/8/9 Regression] Missing 'used uninitialized' warning (CCP)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18501 Manuel López-Ibáñez changed: What|Removed |Added CC||lvenkatakumarchakka at gmail dot c ||om --- Comment #85 from Manuel López-Ibáñez --- *** Bug 69578 has been marked as a duplicate of this bug. ***
[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639 Bug 24639 depends on bug 69578, which changed state. Bug 69578 Summary: -Wuninitialized not issuing warning. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69578 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE
[Bug middle-end/69578] -Wuninitialized not issuing warning.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69578 Manuel López-Ibáñez changed: What|Removed |Added Status|NEW |RESOLVED CC||manu at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #5 from Manuel López-Ibáñez --- Original report is PR18501. Comment #4 is PR54554. *** This bug has been marked as a duplicate of bug 18501 ***
[Bug c++/87275] New: unsequenced writes not diagnosed in constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87275
Bug ID: 87275
Summary: unsequenced writes not diagnosed in constant
expression
Product: gcc
Version: 8.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: bbi5291 at gmail dot com
Target Milestone: ---
An expression fails to be a constant expression if it contains UB. The code
below contains a function whose evaluation results in UB when called with the
argument `true` because of unsequenced writes to `x`. However, the code
compiles without a diagnostic when said function is called in a context that
requires a constant expression.
$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-pc-linux-gnu/8.1.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ./configure --prefix=/usr/local --disable-multilib
--without-mpc --without-mpfr --without-gmp --without-cloog --without-isl
--enable-languages=c,c++
Thread model: posix
gcc version 8.1.0 (GCC)
$ g++ -std=c++17 -Wall -pedantic main.cpp
$ cat main.cpp
constexpr int f(bool b) {
int x = 0, y = 0;
int& r = b ? x : y;
return (x++) + (r++);
}
template struct S {};
int main() {
S();
S();
}
[Bug rtl-optimization/85458] FAIL: gcc.dg/pr83480.c (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85458 --- Comment #6 from John David Anglin --- The patch was approved by Jeff Law. The ICE indicates that there was a negative priority generated in testcase on ia64. Negative priorities present a problem for targets that define TARGET_SCHED_ADJUST_PRIORITY. For example, the ">>" operator can't be used to reduce the priority if the current priority is negative.
[Bug bootstrap/87030] GCC fails to build with Xcode 10, attempting an impossible multilib build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87030 --- Comment #9 from joseph at codesourcery dot com --- On Sat, 8 Sep 2018, iains at gcc dot gnu.org wrote: > 2. Actually, you get the same failure on GNU-Linux if you try to configure > defaults on (for example) an x86_64 system without 32bit libs installed (one > has to add --disable-multilib there, or install 32b libs), so automation is > not > the default on Linux. The toplevel configure.ac code # Special user-friendly check for native x86_64-linux build, if # multilib is not explicitly enabled. case "$target:$have_compiler:$host:$target:$enable_multilib" in x86_64-*linux*:yes:$build:$build:) # Make sure we have a development environment that handles 32-bit [...] is meant to give a more helpful error in that case: AC_MSG_ERROR([I suspect your system does not have 32-bit development libraries (libc and headers). If you have them, rerun configure with --enable-multilib. If you do not have them, and want to build a 64-bit-only compiler, rerun configure with --disable-multilib.])
[Bug c++/87274] New: -std=c++11 breaks quadmath macros
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87274
Bug ID: 87274
Summary: -std=c++11 breaks quadmath macros
Product: gcc
Version: 8.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: lopresti at gmail dot com
Target Milestone: ---
Test case:
#include
__float128 doit()
{
return FLT128_MAX;
}
Compile with "g++ -std=c++11" to get the error:
/tmp/quadmath.cc: In function \u2018__float128 doit()\u2019:
/tmp/quadmath.cc:5:10: error: unable to find numeric literal operator
\u2018operator""Q\u2019
return FLT128_MAX;
^~
/tmp/quadmath.cc:5:10: note: use -fext-numeric-literals to enable more built-in
suffixes
Note that my code does not use any quad-precision literals; just the documented
`FLT128_MAX` macro.
I realize quadmath is more a C thing than a C++ thing... But it would still be
nice if this worked, IMO.
On a possibly related note, writing "__extension__" before a quad-precision
literal does not silence this error. Perhaps it should (?)
[Bug bootstrap/87030] GCC fails to build with Xcode 10, attempting an impossible multilib build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87030 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org, ||jeremyhu at macports dot org --- Comment #8 from Eric Gallager --- (In reply to Jack Howarth from comment #7) > (In reply to Iain Sandoe from comment #6) > > We are not dependent on the Xcode supplied tools for some time now, since > > upstream dsymutil is functional. So, if that were to happen - we would > > simply (as the Linux folks do) build a complete toolchain rather than just > > the compiler (i have a 'cctools' look-alike driver for the LLVM backend - > > and an actual cctools assembler with the known bugs fixed). > > > > While using the assembler from llvm should be straight forward enough, > assuming Apple didn't push its obsoleting of i386 changes upstream, the > linker would be a tricker issue since the llvm lld code hasn't been kept up > on the Darwin side for quite some time. > > > To assist this, it would be helpful if fink, macports etc. could file radars > > noting that the open source releases are very out of date for these > > components (currently 8.2.1 compared with the released Xcode of 10.x) > > I pinged Jeremy to see if he can nudge that along. cc-ing him on this bug, too
[Bug rtl-optimization/87273] New: [8/9 Regression] ICE in merge_fences, at sel-sched-ir.c:708
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87273
Bug ID: 87273
Summary: [8/9 Regression] ICE in merge_fences, at
sel-sched-ir.c:708
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: 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: ---
Target: x86_64-pc-linux-gnu
gcc-9.0.0-alpha20180902 snapshot (r264045) ICEs when compiling the following
snippet w/ -march=core2 -Os -fschedule-insns -fsel-sched-pipelining
-fselective-scheduling -fno-ssa-phiopt -fno-tree-loop-im:
int sd;
void
w5 (int n4)
{
long int *vq = (long int *)
while (n4 < 1)
{
int ks;
ks = !!(n4 + 1) ? ((++sd) == *vq) : 0;
if (ks == 1 / *vq)
*vq *= sd;
}
}
% gcc-9.0.0-alpha20180902 -march=core2 -Os -fschedule-insns
-fsel-sched-pipelining -fselective-scheduling -fno-ssa-phiopt -fno-tree-loop-im
-c mdrdoij6.c
during RTL pass: sched1
mdrdoij6.c: In function 'w5':
mdrdoij6.c:16:1: internal compiler error: in merge_fences, at
sel-sched-ir.c:708
16 | }
| ^
0x64a6f4 merge_fences
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180902/work/gcc-9-20180909/gcc/sel-sched-ir.c:708
0xc71d8a move_fence_to_fences(_list_node*, flist_tail_def*)
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180902/work/gcc-9-20180909/gcc/sel-sched-ir.c:841
0xc8082b calculate_new_fences
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180902/work/gcc-9-20180909/gcc/sel-sched.c:7425
0xc8082b sel_sched_region_2
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180902/work/gcc-9-20180909/gcc/sel-sched.c:7505
0xc81386 sel_sched_region_1
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180902/work/gcc-9-20180909/gcc/sel-sched.c:7546
0xc82b66 sel_sched_region(int)
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180902/work/gcc-9-20180909/gcc/sel-sched.c:7647
0xc83a81 run_selective_scheduling()
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180902/work/gcc-9-20180909/gcc/sel-sched.c:7733
0xc6379d rest_of_handle_sched
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180902/work/gcc-9-20180909/gcc/sched-rgn.c:3718
0xc6379d execute
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180902/work/gcc-9-20180909/gcc/sched-rgn.c:3828
[Bug gcov-profile/85871] g++.dg/gcov/gcov-8.C random failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85871 Martin Liška changed: What|Removed |Added Status|WAITING |ASSIGNED Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org --- Comment #7 from Martin Liška --- Looks it will be fixed in: https://gcc.gnu.org/ml/gcc-patches/2018-09/msg00303.html
[Bug c++/87269] [9 Regression] ICE in tsubst_copy, at cp/pt.c:15475 starting from r261802
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87269
--- Comment #1 from Martin Liška ---
Reduced test-case:
$ cat ice2.ii
namespace {
void operator"" a(const char *, unsigned long);
}
inline namespace b {
void operator"" a(unsigned long long );
}
namespace c {
struct d {
using e = bool ;
e f;
};
struct g {
d h;
};
template < class > class i {
static const g k;
static bool f();
};
template < class j > bool i< j >::f() {
""a;
} template <> const g i< int >::k {
f};
}
[Bug tree-optimization/87271] [9 Regression] ICE in rpo_elim::~rpo_elim (this=0xbfbfe15c, __in_chrg=) at ../../gcc/tree-ssa-sccvn.c:5709 on FreeBSD 10.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87271 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-09-10 CC||gerald at pfeifer dot com Target Milestone|--- |9.0 Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- One another back-trace for another reduced test-case: $ (gdb) bt #0 0x08519136 in memory_block_pool::allocate () at ../../gcc/memory-block.h:59 #1 0x08519663 in base_pool_allocator::allocate (this=0xa3facc0 ) at ../../gcc/alloc-pool.h:373 #2 0x08659e58 in object_allocator::allocate (this=0xa3facc0 ) at ../../gcc/alloc-pool.h:502 #3 0x08652bb9 in new_elt_loc_list (val=0x2addd00c, loc=0x2b2293c0) at ../../gcc/cselib.c:365 #4 0x08656052 in cselib_lookup_1 (x=0x2b2293c0, mode=E_SImode, create=1, memmode=E_VOIDmode) at ../../gcc/cselib.c:2035 #5 0x08656489 in cselib_lookup (x=0x2b2293c0, mode=E_SImode, create=1, memmode=E_VOIDmode) at ../../gcc/cselib.c:2141 #6 0x086573ab in cselib_record_sets (insn=0x2b1db8dc) at ../../gcc/cselib.c:2593 #7 0x08657db2 in cselib_process_insn (insn=0x2b1db8dc) at ../../gcc/cselib.c:2790 #8 0x09801c85 in local_cprop_pass () at ../../gcc/cprop.c:1293 #9 0x09802a48 in one_cprop_pass () at ../../gcc/cprop.c:1778 #10 0x09802f3e in execute_rtl_cprop () at ../../gcc/cprop.c:1932 #11 0x09803013 in (anonymous namespace)::pass_rtl_cprop::execute (this=0x2ac5edc0) at ../../gcc/cprop.c:1970 #12 0x08ad607b in execute_one_pass (pass=0x2ac5edc0) at ../../gcc/passes.c:2446 #13 0x08ad63b4 in execute_pass_list_1 (pass=0x2ac5edc0) at ../../gcc/passes.c:2535 #14 0x08ad63e4 in execute_pass_list_1 (pass=0x2ac5ebc0) at ../../gcc/passes.c:2536 #15 0x08ad6430 in execute_pass_list (fn=0x2b10fc98, pass=0x2ac5b480) at ../../gcc/passes.c:2546 #16 0x08637115 in cgraph_node::expand (this=0x2b0ae898) at ../../gcc/cgraphunit.c:2121 #17 0x086376f0 in expand_all_functions () at ../../gcc/cgraphunit.c:2259 #18 0x08638189 in symbol_table::compile (this=0x2b0070c8) at ../../gcc/cgraphunit.c:2610 #19 0x0863858e in symbol_table::finalize_compilation_unit (this=0x2b0070c8) at ../../gcc/cgraphunit.c:2788 #20 0x08c33ea9 in compile_file () at ../../gcc/toplev.c:480 #21 0x08c36679 in do_compile () at ../../gcc/toplev.c:2170 #22 0x08c3694c in toplev::main (this=0xbfbfea1e, argc=13, argv=0xbfbfea84) at ../../gcc/toplev.c:2305 #23 0x099dabda in main (argc=13, argv=0xbfbfea84) at ../../gcc/main.c:39 $ (gdb) p instance.m_blocks $1 = (memory_block_pool::block_list *) 0x1 It looks some memory corruption is hapenning. Gerald, would it be possible to build recebt GCC with -fsanitize=address on the system?
[Bug bootstrap/87272] New: Infinite loop for incorrect hardware clock
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87272 Bug ID: 87272 Summary: Infinite loop for incorrect hardware clock Product: gcc Version: 7.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: jdphysik at gmail dot com Target Milestone: --- If the hardware clock is set incorrectly (e.g. to 1970), make will go into an infinite loop because of the --recheck option in the Makefile.
[Bug fortran/87270] "FINAL" subroutine is called when compiled with "gfortran -O1", but not "gfortran -O0"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87270 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2018-09-10 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- This seems to have been fixed by revision r264008 on trunk and r264027 on the gcc8 branch (pr86328 and pr86760).
[Bug tree-optimization/87271] New: [9 Regression] ICE in rpo_elim::~rpo_elim (this=0xbfbfe15c, __in_chrg=) at ../../gcc/tree-ssa-sccvn.c:5709 on FreeBSD 10.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87271 Bug ID: 87271 Summary: [9 Regression] ICE in rpo_elim::~rpo_elim (this=0xbfbfe15c, __in_chrg=) at ../../gcc/tree-ssa-sccvn.c:5709 on FreeBSD 10.4 Product: gcc Version: 9.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org CC: rguenth at gcc dot gnu.org Target Milestone: --- Host: i586-freebsd That's follow-up of: https://gcc.gnu.org/ml/gcc-patches/2018-09/msg00501.html I see following back-trace: $ Starting program: /tmp/gcc3/objdir/gcc/cc1 -quiet -I . -I ../../../libbacktrace -I ../../../libbacktrace/../include -I ../../../libbacktrace/../libgcc -I ../libgcc -iprefix /tmp/gcc3/objdir/gcc/../lib/gcc/i586-unknown-freebsd10.4/9.0.0/ -isystem /tmp/gcc3/objdir/./gcc/include -isystem /tmp/gcc3/objdir/./gcc/include-fixed -D HAVE_CONFIG_H -D PIC -isystem /usr/local/i586-unknown-freebsd10.4/include -isystem /usr/local/i586-unknown-freebsd10.4/sys-include ../../../libbacktrace/elf.c -quiet -dumpbase elf.c -mtune=pentium -march=pentium -auxbase-strip .libs/elf.o -g -O2 -Wextra -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wsuggest-attribute=format -Wcast-qual -Werror -funwind-tables -frandom-seed=elf.lo -fPIC -o /tmp//ccR4tmV8.s Program received signal SIGSEGV, Segmentation fault. 0x2a59ebe8 in ?? () from /lib/libc.so.7 (gdb) bt #0 0x2a59ebe8 in ?? () from /lib/libc.so.7 #1 0x2a59efb7 in ?? () from /lib/libc.so.7 #2 0x2a5aa90c in free () from /lib/libc.so.7 #3 0x085ced17 in va_heap::release > (v=@0x2b42801c: 0x2aefbf80) at ../../gcc/vec.h:307 #4 0x085ce59f in vec, va_heap, vl_ptr>::release (this=0x2b42801c) at ../../gcc/vec.h:1675 #5 0x08ea9523 in rpo_elim::~rpo_elim (this=0xbfbfe15c, __in_chrg=) at ../../gcc/tree-ssa-sccvn.c:5709 #6 0x08eac4a9 in do_rpo_vn (fn=0x2b1df340, entry=0x2b273b20, exit_bbs=0x0, iterate=true, eliminate=false) at ../../gcc/tree-ssa-sccvn.c:6303 #7 0x08ea8dab in run_rpo_vn (kind=VN_WALK) at ../../gcc/tree-ssa-sccvn.c:5560 #8 0x08e722e1 in (anonymous namespace)::pass_pre::execute (this=0x2ac5d0c0, fun=0x2b1df340) at ../../gcc/tree-ssa-pre.c:4199 #9 0x08ad607b in execute_one_pass (pass=0x2ac5d0c0) at ../../gcc/passes.c:2446 #10 0x08ad63b4 in execute_pass_list_1 (pass=0x2ac5d0c0) at ../../gcc/passes.c:2535 #11 0x08ad63e4 in execute_pass_list_1 (pass=0x2ac5b5c0) at ../../gcc/passes.c:2536 #12 0x08ad6430 in execute_pass_list (fn=0x2b1df340, pass=0x2ac5b480) at ../../gcc/passes.c:2546 #13 0x08637115 in cgraph_node::expand (this=0x2b20c320) at ../../gcc/cgraphunit.c:2121 #14 0x086376f0 in expand_all_functions () at ../../gcc/cgraphunit.c:2259 #15 0x08638189 in symbol_table::compile (this=0x2b0070c8) at ../../gcc/cgraphunit.c:2610 #16 0x0863858e in symbol_table::finalize_compilation_unit (this=0x2b0070c8) at ../../gcc/cgraphunit.c:2788 #17 0x08c33ea9 in compile_file () at ../../gcc/toplev.c:480 #18 0x08c36679 in do_compile () at ../../gcc/toplev.c:2170 #19 0x08c3694c in toplev::main (this=0xbfbfe4fe, argc=50, argv=0xbfbfe558) at ../../gcc/toplev.c:2305 #20 0x099dabda in main (argc=50, argv=0xbfbfe558) at ../../gcc/main.c:39
[Bug target/84201] 549.fotonik3d_r from SPEC2017 fails verification with recent Intel and AMD CPUs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84201 --- Comment #4 from Martin Liška --- I see it failing with 4 years old revision r216027 on the Haswell machine. Looking at portability issues: https://www.spec.org/cpu2017/Docs/benchmarks/549.fotonik3d_r.html ``` It is perhaps worth mentioning that some calculations generate 'subnormal' numbers (wikipedia) which may cause slower operation than normal numbers on some hardware platforms. On such platforms, performance may be improved if "flush to zero on underflow" (FTZ) is enabled. During SPEC's testing of Fotonik3d, the output validated correctly whether or not FTZ was enabled. ``` Maybe that's causing the -Ofast issues?
[Bug target/84201] 549.fotonik3d_r from SPEC2017 fails verification with -mprefer-vector-width=256 or 512 on Zen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84201 --- Comment #3 from Martin Liška --- If I'm correct it's also problematic on Haswell with -march=native. Particularly the only affected file is power.fppized.o. I also tried -mno-fma4 and -mno-fma and it does not help. From the assembly diff, there is additional vectorization happening.
[Bug fortran/87270] New: "FINAL" subroutine is called when compiled with "gfortran -O1", but not "gfortran -O0"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87270 Bug ID: 87270 Summary: "FINAL" subroutine is called when compiled with "gfortran -O1", but not "gfortran -O0" Product: gcc Version: 8.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: andrew at fluidgravity dot co.uk Target Milestone: --- Created attachment 44676 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44676=edit code.f90 Compile and the attached code with gfortran 8.1.0: > gfortran -O1 code.f90 && ./a.out main: check 1 create: check 1 create: check 2 main: check 2 cleanup: check 1 Program received signal SIGSEGV: Segmentation fault - invalid memory reference. Backtrace for this error: #0 0x10e293f3c #1 0x10e2932e3 #2 0x7fff670f4f59 #3 0x10e28bbe2 #4 0x10e28bddf #5 0x10e28c6f1 #6 0x10e28c7ad Segmentation fault: 11 The error does not occur if compiled without "-O1" or with "-O0". It also works with gfortran 7.3.1 Using "-O0", I get this: > gfortran -O0 test01.f90 && ./a.out main: check 1 create: check 1 create: check 2 main: check 2 create: check 1 create: check 2 main: check 3 So, the 'cleanup' function is called with one option, but not the other.
[Bug bootstrap/84554] make check: FAIL: tversion: ERROR! The versions of gmp.h (5.0.5) and libgmp (4.3.1) do not match.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84554 --- Comment #5 from Jonathan Wakely --- That does look like a problem. But why are the mpfr tests running as part of bootstrap? I don't think they do for me. I only see tversion built as part of "make check"
[Bug rtl-optimization/85458] FAIL: gcc.dg/pr83480.c (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85458 Andreas Schwab changed: What|Removed |Added Status|RESOLVED|REOPENED Last reconfirmed||2018-09-10 Resolution|FIXED |--- Ever confirmed|0 |1 --- Comment #5 from Andreas Schwab --- Who has approved that commit? Please revert! during RTL pass: mach /usr/local/gcc/test/gcc/testsuite/gcc.c-torture/compile/20010102-1.c: In function ‘_obstack_newchunk’: /usr/local/gcc/test/gcc/testsuite/gcc.c-torture/compile/20010102-1.c:101:1: internal compiler error: in sel_target_adjust_priority, at sel-sched.c: 0x410bb68f sel_target_adjust_priority ../../gcc/sel-sched.c: 0x410bb68f fill_vec_av_set ../../gcc/sel-sched.c:3727 0x410bd45f fill_ready_list ../../gcc/sel-sched.c:4028 0x410bd45f find_best_expr ../../gcc/sel-sched.c:4388 0x410bd45f fill_insns ../../gcc/sel-sched.c:5549 0x410c29cf schedule_on_fences ../../gcc/sel-sched.c:7366 0x410c29cf sel_sched_region_2 ../../gcc/sel-sched.c:7504 0x410c510f sel_sched_region_1 ../../gcc/sel-sched.c:7546 0x410c700f sel_sched_region(int) ../../gcc/sel-sched.c:7647 0x410c9def run_selective_scheduling() ../../gcc/sel-sched.c:7733 0x419e473f ia64_reorg ../../gcc/config/ia64/ia64.c:9857 0x410314cf execute ../../gcc/reorg.c:3984
[Bug c++/87269] [9 Regression] ICE in tsubst_copy, at cp/pt.c:15475 starting from r261802
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87269 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-09-10 CC||nathan at gcc dot gnu.org Known to work||8.2.0 Target Milestone|--- |9.0 Ever confirmed|0 |1 Known to fail||9.0
[Bug c++/87150] [8 Regression] move ctor wrongly chosen in return stmt (derived vs. base)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87150
--- Comment #15 from Stephan Bergmann ---
I see that with the fix from comment 13 included, the slightly changed source
#include
struct S1 { S1(S1 &&); };
struct S2: S1 {};
S1 f(S2 s) { return std::move(s); }
causes -Wredundant-move (when that warning is explicitly requested).
[Bug c++/87269] New: [9 Regression] ICE in tsubst_copy, at cp/pt.c:15475 starting from r261802
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87269 Bug ID: 87269 Summary: [9 Regression] ICE in tsubst_copy, at cp/pt.c:15475 starting from r261802 Product: gcc Version: 9.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org Target Milestone: --- Created attachment 44675 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44675=edit unreduced test-case Starting from the revision I see: $ g++ ice.ii -c In file included from /home/abuild/rpmbuild/BUILD/webkitgtk-2.22.0/Source/JavaScriptCore/API/JSCallbackObject.h:244, from /home/abuild/rpmbuild/BUILD/webkitgtk-2.22.0/Source/JavaScriptCore/API/glib/JSAPIWrapperGlobalObject.cpp:30: /home/abuild/rpmbuild/BUILD/webkitgtk-2.22.0/Source/JavaScriptCore/API/JSCallbackObjectFunctions.h: In instantiation of ‘static JSC::EncodedJSValue JSC::JSCallbackObject::callbackGetter(JSC::ExecState*, JSC::EncodedJSValue, JSC::PropertyName) [with Parent = JSC::JSAPIWrapperGlobalObject; JSC::EncodedJSValue = long int]’: /home/abuild/rpmbuild/BUILD/webkitgtk-2.22.0/Source/JavaScriptCore/API/JSCallbackObjectFunctions.h:162:21: required from ‘static bool JSC::JSCallbackObject::getOwnPropertySlot(JSC::JSObject*, JSC::ExecState*, JSC::PropertyName, JSC::PropertySlot&) [with Parent = JSC::JSAPIWrapperGlobalObject]’ /home/abuild/rpmbuild/BUILD/webkitgtk-2.22.0/Source/JavaScriptCore/API/glib/JSAPIWrapperGlobalObject.cpp:57:429: required from here /home/abuild/rpmbuild/BUILD/webkitgtk-2.22.0/Source/JavaScriptCore/API/JSCallbackObjectFunctions.h:700:83: internal compiler error: in tsubst_copy, at cp/pt.c:15513 0x645c85 tsubst_copy /home/marxin/Programming/gcc/gcc/cp/pt.c:15513 0x9f046f tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool, bool) /home/marxin/Programming/gcc/gcc/cp/pt.c:19039 0x9ef398 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool, bool) /home/marxin/Programming/gcc/gcc/cp/pt.c:18309 0x9ef4ac tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool, bool) /home/marxin/Programming/gcc/gcc/cp/pt.c:18325 0x9ef4ac tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool, bool) /home/marxin/Programming/gcc/gcc/cp/pt.c:18325 0x9ef4ac tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool, bool) /home/marxin/Programming/gcc/gcc/cp/pt.c:18325 0x9d6fdb tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool) /home/marxin/Programming/gcc/gcc/cp/pt.c:17455 0x9d4099 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool) /home/marxin/Programming/gcc/gcc/cp/pt.c:16646 0x9d4b54 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool) /home/marxin/Programming/gcc/gcc/cp/pt.c:16636 0x9d3fd9 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool) /home/marxin/Programming/gcc/gcc/cp/pt.c:16939 0xa054ae instantiate_decl(tree_node*, bool, bool) /home/marxin/Programming/gcc/gcc/cp/pt.c:24099 0xa094fb instantiate_pending_templates(int) /home/marxin/Programming/gcc/gcc/cp/pt.c:24215 0x920408 c_parse_final_cleanups() /home/marxin/Programming/gcc/gcc/cp/decl2.c:4709 I'm going to reduce the test-case.
[Bug bootstrap/87030] GCC fails to build with Xcode 10, attempting an impossible multilib build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87030 --- Comment #7 from Jack Howarth --- (In reply to Iain Sandoe from comment #6) > We are not dependent on the Xcode supplied tools for some time now, since > upstream dsymutil is functional. So, if that were to happen - we would > simply (as the Linux folks do) build a complete toolchain rather than just > the compiler (i have a 'cctools' look-alike driver for the LLVM backend - > and an actual cctools assembler with the known bugs fixed). > While using the assembler from llvm should be straight forward enough, assuming Apple didn't push its obsoleting of i386 changes upstream, the linker would be a tricker issue since the llvm lld code hasn't been kept up on the Darwin side for quite some time. > To assist this, it would be helpful if fink, macports etc. could file radars > noting that the open source releases are very out of date for these > components (currently 8.2.1 compared with the released Xcode of 10.x) I pinged Jeremy to see if he can nudge that along.
[Bug bootstrap/84402] [meta] GCC build system: parallelism bottleneck
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84402 Martin Liška changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org --- Comment #25 from Martin Liška --- Let me assign it.
[Bug c++/83428] Static initialization and struct with constexpr ctor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83428 --- Comment #5 from Wolfgang Roehrl --- Hello, I just came back from holidays and I read your comments on my bug report. For two reasons I still think that the compiler should not use dynamic initialization for objX - at least not without any warning: a) According to my understanding the Standard requests static initialization for a class-type variable whose constexpr constructor is invoked with constant expressions (cf. C++17 Standard, 6.6.2/2;); and it is additionally required that all sub-objects of the variable can also be initialized statically. But I don't see that the Standard requests that the ctor definition has to precede the variable definition in order to get static initialization. b) The behaviour of the compiler ist not user-friendly: A program may rely on the static initialization of an object - especially if the object contains atomic variables. Now somebody may modify the programm and move the constructor definition unintentionally behind the definiton of the object. The program still compiles but the program behaviour has changed silently and to fix this kind of bugs can be very time-consuming. With kind regards, W. Roehrl
[Bug c++/87262] Static Code Analysis Findings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87262 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Jonathan Wakely --- I looked at a few of these and they're complete nonsense. This is not a redundant initialization in std::swap: _Tp __tmp = _GLIBCXX_MOVE(__a); __a = _GLIBCXX_MOVE(__b); __b = _GLIBCXX_MOVE(__tmp); And the memory leaks are not leaks.
[Bug bootstrap/87030] GCC fails to build with Xcode 10, attempting an impossible multilib build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87030 --- Comment #6 from Iain Sandoe --- (In reply to Jack Howarth from comment #5) > (In reply to Iain Sandoe from comment #3) > > > > > 3. I don't see why GCC should be subject to the vendor's support policy. As > > far as I am concerned, with the right SDK / sysroot available, there's no > > reason why a compiler *hosted* on x86-64-Darwin18 shouldn't be able to build > > code for i686-darwin10 *target*. > > That makes the assumption that the cctools in some future macOS release > won't obsolete out the code for support i386 assembly and linkage. I > wouldn't be surprised if that actually happened should Apple start making > arm64-apple-darwin a thing. We are not dependent on the Xcode supplied tools for some time now, since upstream dsymutil is functional. So, if that were to happen - we would simply (as the Linux folks do) build a complete toolchain rather than just the compiler (i have a 'cctools' look-alike driver for the LLVM backend - and an actual cctools assembler with the known bugs fixed). To assist this, it would be helpful if fink, macports etc. could file radars noting that the open source releases are very out of date for these components (currently 8.2.1 compared with the released Xcode of 10.x)
[Bug tree-optimization/87263] [9 Regression] ICE on valid code at -O1: verify_ssa failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87263 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-09-10 CC||jakub at gcc dot gnu.org Target Milestone|--- |9.0 Summary|ICE on valid code at -O1: |[9 Regression] ICE on valid |verify_ssa failed |code at -O1: verify_ssa ||failed Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Started with r263980.
[Bug bootstrap/84554] make check: FAIL: tversion: ERROR! The versions of gmp.h (5.0.5) and libgmp (4.3.1) do not match.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84554 --- Comment #4 from matthew.hambley at metoffice dot gov.uk --- I have further information. From the build log: (long paths reduced with ellipses) .../gcc-8.2.0-build/./prev-gcc/xgcc -B.../gcc/8.2.0/x86_64-pc-linux-gnu/sys-include-DTIME_WITH_SYS_TIME=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_LOCALE_H=1 -DHAVE_WCHAR_H=1 -DHAVE_STDARG=1 -DHAVE_SYS_TIME_H=1 -DHAVE_STRUCT_LCONV_DECIMAL_POINT=1 -DHAVE_STRUCT_LCONV_THOUSANDS_SEP=1 -DHAVE_ALLOCA_H=1 -DHAVE_STDINT_H=1 -DHAVE_VA_COPY=1 -DHAVE_SETLOCALE=1 -DHAVE_GETTIMEOFDAY=1 -DHAVE_LONG_LONG=1 -DHAVE_INTMAX_T=1 -DMPFR_HAVE_INTMAX_MAX=1 -DMPFR_HAVE_FESETROUND=1 -DHAVE_DENORMS=1 -DHAVE_SIGNEDZ=1 -DHAVE_ROUND=1 -DHAVE_TRUNC=1 -DHAVE_FLOOR=1 -DHAVE_CEIL=1 -DHAVE_NEARBYINT=1 -DHAVE_LDOUBLE_IEEE_EXT_LITTLE=1 -DMPFR_USE_THREAD_SAFE=1 -DMPFR_USE_C11_THREAD_SAFE=1 -DHAVE_CLOCK_GETTIME=1 -DLT_OBJDIR=\".libs/\" -DHAVE_ATTRIBUTE_MODE=1 -DHAVE___GMPN_ROOTREM=1 -DHAVE___GMPN_SBPI1_DIVAPPR_Q=1 -I. -I../../../gcc-8.2.0/mpfr/tests -DSRCDIR='"../../../gcc-8.2.0/mpfr/tests"' -I../../../gcc-8.2.0/mpfr/src -I../src -I.../gcc-8.2.0-build/./gmp -DNO_ASM -g -O2 -MT tversion.o -MD -MP -MF .deps/tversion.Tpo -c -o tversion.o ../../../gcc-8.2.0/mpfr/tests/tversion.c mv -f .deps/tversion.Tpo .deps/tversion.Po /bin/sh ../libtool --tag=CC --mode=link .../gcc-8.2.0-build/./prev-gcc/xgcc -B.../gcc-8.2.0-build/./prev-gcc/ -B.../gcc/8.2.0/x86_64-pc-linux-gnu/bin/ -B.../gcc/8.2.0/x86_64-pc-linux-gnu/bin/ -B.../gcc/8.2.0/x86_64-pc-linux-gnu/lib/ -isystem .../gcc/8.2.0/x86_64-pc-linux-gnu/include -isystem .../gcc/8.2.0/x86_64-pc-linux-gnu/sys-include-DNO_ASM -g -O2 -no-install -L../src/.libs -static-libstdc++ -static-libgcc -o tversion tversion.o libfrtests.la -lm ../src/libmpfr.la -lgmp Notice that when tversion is compiled the argument "-I.../gcc-8.2.0-build/./gmp" is specified which explains why it uses the correct headers. Further notice that when it is linked there is no corresponding "big Ell" argument meaning that the "little Ell" reference to "gmp" will be satisfied elsewhere. Am I missing something when I configure the build?
[Bug tree-optimization/87266] [9 Regression] ICE: Segmentation fault (in useless_type_conversion_p, tree_nop_conversion_p, or is_gimple_reg_type)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87266 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-09-10 CC||jakub at gcc dot gnu.org Target Milestone|--- |9.0 Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Started with r263875.
[Bug tree-optimization/87267] [9 Regression] ICE: Segmentation fault (in gimple_truth_valued_p)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87267 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-09-10 CC||jakub at gcc dot gnu.org Target Milestone|--- |9.0 Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Started with r263875.
[Bug middle-end/87268] Missed optimization for a tailcall
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87268 --- Comment #3 from ead --- Sorry, I only saw that clang gives me what I expect... and overlooked the warning. call_doit should return void and not int.
[Bug middle-end/87268] Missed optimization for a tailcall
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87268 --- Comment #2 from Andrew Pinski --- So you might have undefined code in c if the return value is used there. In c++ it is undefined even without using it. Also noreturn is never sibcalled.
[Bug c/87268] New: Missed optimization for a tailcall
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87268
Bug ID: 87268
Summary: Missed optimization for a tailcall
Product: gcc
Version: 8.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: no...@turm-lahnstein.de
Target Milestone: ---
For a simple code like this:
extern int shared;
void doit(int *);
int call_doit(){
doit();
}
when compiled with -O3 the resulting assembler is without tailcall
optimization:
call_doit:
subq$8, %rsp
movl$shared, %edi
calldoit
addq$8, %rsp
ret
There are two thing that are probably not needed:
1. The whole "subq$8, %rsp / addq$8, %rsp" is not really necessary,
isn't it?
2. call instead of simple jmp, which would be possible due to tailcall
optimization. Possibly it was not performed, because subq/addq are still
hanging around.
If I'm not mistaken, something like:
call_doit:
movl$global, %edi
jmp doit
should be possible as output.
