[Bug fortran/71723] [7/8/9 Regression] [F08] ICE on invalid pointer initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71723 Thomas Koenig changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |tkoenig at gcc dot gnu.org --- Comment #12 from Thomas Koenig --- I have a patch, let's see if it survives regression testing.
[Bug target/89213] Optimize V2DI shifts by a constant on power8 & above systems.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89213 --- Comment #3 from Michael Meissner --- The vector shift sequence does not appear in Spec 2006 CPU compiled for power9. The vector shift sequence does appear 4 times in the 602_gcc_s benchmark, and once in the 683_imagick_s benchmark.
[Bug c/89211] [8/9 Regression] ICE in int_mode_for_mode, at stor-layout.c:403
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89211 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug c++/89212] [8/9 Regression] ICE in fold_convert_loc at fold-const.c:2552
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89212 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug c++/89214] [7/8/9 Regression] ICE in digest_init_r, at cp/typeck2.c:1211 with -std=c++17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89214 Richard Biener changed: What|Removed |Added Keywords||ice-checking Priority|P3 |P2
[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 Richard Biener changed: What|Removed |Added Keywords||error-recovery, ||rejects-valid Priority|P3 |P1 Summary|ICE tree check: expected|[9 Regression] ICE tree |constructor, have |check: expected |error_mark in |constructor, have |split_nonconstant_init_1|error_mark in ||split_nonconstant_init_1 --- Comment #3 from Richard Biener --- So it's also rejects-valid and the ICE is error-recovery...
[Bug libstdc++/58142] _pthread_tsd_cleanup called before destructors are called
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58142 --- Comment #10 from Ev Drikos --- (In reply to Jonathan Wakely from comment #9) > ... I'm not sure either. But I've confirmed in macOS (10.13) the following simple hack. If the routine that initialises the Emulated TLS created two keys and then deleted the first, immediately after, the former key would be reassigned to the one used in function "__cxa_thread_atexit". The destructors would run in the desired order. Ideally, this routine would like to know, if the following two symbols are defined: _GLIBCXX_HAVE___CXA_THREAD_ATEXIT, and _GLIBCXX_HAVE___CXA_THREAD_ATEXIT_IMPL To avoid the hack then, one would need to know which "__cxa_thread_atexit" is used. Ev. Drikos
[Bug fortran/89219] New: [gfortran 7.3] compiler throws internal compiler error: segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89219 Bug ID: 89219 Summary: [gfortran 7.3] compiler throws internal compiler error: segmentation fault Product: gcc Version: 7.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: cih_dmc at yahoo dot com.mx Target Milestone: --- Created attachment 45615 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45615&action=edit simplied version This internal compiler error seems to occur when a fuction returns a class pointer of a derived type directly in a user defined i/o procedure $gfortran main.f90 compiler output: main.f90:88:0: print*, l%get() internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. here a simplified version of the code module Test implicit none type :: Parent contains procedure :: toString procedure :: wio generic :: write(formatted) => wio end type type, extends(Parent) :: Child1 real :: x = 0 contains procedure :: toString => toString1 end type type, extends(Parent) :: Child2 class(Parent), pointer :: p => null() contains procedure :: set procedure :: get procedure :: toString => toString2 end type contains subroutine set(this, o) class(Child2), intent(inout) :: this class(*), intent(in), target :: o select type(o) type is (real) allocate(this%p, source=Child1(o)) class is (Parent) this%p => o class default stop "unknown type" end select end subroutine function get(this) result(p) class(Child2), intent(in) :: this class(Parent), pointer :: p p => this%p end function function toString1(this) result(str) class(Child1), intent(in) :: this character(50) :: str write(str, *) this%x end function function toString2(this) result(str) class(Child2), intent(in) :: this character(50) :: str str = "child2" end function function toString(this) result(str) class(Parent), intent(in) :: this character(50) :: str write(str, *) loc(this) end function subroutine wio(this, unit, iotype, v_list, iostat, iomsg) class(Parent), intent(in) :: this integer, intent(in) :: unit character(*), intent(in) :: iotype integer, intent(in) :: v_list(:) integer, intent(out) :: iostat character(*), intent(inout) :: iomsg write(unit, fmt=*, iostat=iostat, iomsg=iomsg) this%toString() end subroutine end module program main use Test implicit none type(Child2) :: l class(Parent), pointer :: pch1 => null() call l%set(234434.) !print*, l%get() ! in this way doesn't work, throws internal compile error pch1 => l%get() print*, pch1! in this way compiles ! end program
[Bug middle-end/89210] [9 Regression] ICE tree check: expected integer_cst, have real_cst in to_wide, at tree.h:5600
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89210 --- Comment #2 from Jakub Jelinek --- Author: jakub Date: Wed Feb 6 09:16:19 2019 New Revision: 268573 URL: https://gcc.gnu.org/viewcvs?rev=268573&root=gcc&view=rev Log: PR middle-end/89210 * fold-const-call.c (fold_const_vec_convert): Pass true as last operand to new_unary_operation only if both element types are integral and it isn't a widening conversion. Return NULL_TREE if new_unary_operation failed. * c-c++-common/builtin-convertvector-2.c: New test. Added: trunk/gcc/testsuite/c-c++-common/builtin-convertvector-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/fold-const-call.c trunk/gcc/testsuite/ChangeLog
[Bug c/89211] [8/9 Regression] ICE in int_mode_for_mode, at stor-layout.c:403
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89211 --- Comment #4 from Jakub Jelinek --- Author: jakub Date: Wed Feb 6 09:17:55 2019 New Revision: 268574 URL: https://gcc.gnu.org/viewcvs?rev=268574&root=gcc&view=rev Log: PR c/89211 * c-parser.c (c_parser_declaration_or_fndef): Don't update DECL_ARGUMENTS of d if it has been defined already. Use a single if instead of 3 nested ifs. * gcc.dg/pr89211.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr89211.c Modified: trunk/gcc/c/ChangeLog trunk/gcc/c/c-parser.c trunk/gcc/testsuite/ChangeLog
[Bug middle-end/89210] [9 Regression] ICE tree check: expected integer_cst, have real_cst in to_wide, at tree.h:5600
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89210 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Jakub Jelinek --- Fixed.
[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 Summary|[8/9 Regression] ICE in |[8 Regression] ICE in |int_mode_for_mode, at |int_mode_for_mode, at |stor-layout.c:403 |stor-layout.c:403 --- Comment #5 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug fortran/89219] [gfortran 7.3] compiler throws internal compiler error: segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89219 --- Comment #1 from Richard Biener --- Works for me with FSF 7.3.0 on x86_64-linux.
[Bug c++/89220] New: Inconsistent behaviour of class template type deduction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89220
Bug ID: 89220
Summary: Inconsistent behaviour of class template type
deduction
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: matt at ookypooky dot com
Target Milestone: ---
Demonstrated by the following code:
template
struct Foo
{
Foo (T) {}
auto operator () (int) { return 0; }
};
// this compiles
auto x = Foo(123)(0);
// this doesn't
auto y = (Foo(123))(0);
When compiled with "g++ -std=c++17". See here https://godbolt.org/z/Xrmf_8
Interestingly with "-std=c++1y" both x and y fail to compile, which is at least
consistent (even if I'm not sure it's correct...)
[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 #6 from Richard Biener ---
If Martins bisection to power.fppized.o is correct you can bisect the loop
via the vect_loop or vect_slp debug counters (or first try with just
-fno-tree-{loop,slp}-vectorize to narrow down to loop vs. BB vectorization).
[Bug tree-optimization/88074] [7/8/9 Regression] g++ hangs on math expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88074 Richard Biener changed: What|Removed |Added Status|ASSIGNED|NEW CC||rguenth at gcc dot gnu.org Assignee|rguenth at gcc dot gnu.org |unassigned at gcc dot gnu.org --- Comment #27 from Richard Biener --- Not working on this.
[Bug c++/89220] Inconsistent behaviour of class template type deduction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89220 --- Comment #1 from Matt A --- // ... but this compiles again auto z = ((Foo(123)))(0);
[Bug fortran/89219] ICE with derived type I/O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89219 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-02-06 CC||jvdelisle at gcc dot gnu.org Summary|[gfortran 7.3] compiler |ICE with derived type I/O |throws internal compiler| |error: segmentation fault | Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres --- > Works for me with FSF 7.3.0 on x86_64-linux. Did you uncomment the line !print*, l%get() ! in this way doesn't work, throws internal compile error ? If I do so, I get with 7.3.0 up to trunk (9.0) * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x37) frame #0: 0x0001001395a8 f951`::transfer_expr(se=0x7ffeefbfe810, ts=0x000143e16c08, addr_expr=0x000143c0bce8, code=0x000143e16cd0, vptr=) at trans-io.c:2438 2435&& !(ts->u.derived->attr.sequence 2436 || ts->u.derived->attr.is_bind_c)) 2437 || (ts->type == BT_CLASS -> 2438 && !GFC_CLASS_TYPE_P (TREE_TYPE (decl 2439 gfc_conv_derived_to_class (se, code->expr1, 2440dtio_sub->formal->sym->ts, 2441vptr, false, false); Target 0: (f951) stopped. (lldb) bt * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x37) * frame #0: 0x0001001395a8 f951`::transfer_expr(se=0x7ffeefbfe810, ts=0x000143e16c08, addr_expr=0x000143c0bce8, code=0x000143e16cd0, vptr=) at trans-io.c:2438 frame #1: 0x00010013c8a1 f951`gfc_trans_transfer(code=) at trans-io.c:2663 frame #2: 0x0001000dffec f951`::trans_code(code=0x000143e16cd0, cond=0x000143df12f8) at trans.c:2038 frame #3: 0x00010013a2d8 f951`::build_dt(function=0x000143dcb600, code=0x000143e16f40) at trans-io.c:2026 frame #4: 0x0001000e000c f951`::trans_code(code=0x000143e16f40, cond=0x) at trans.c:2010 frame #5: 0x000100107b41 f951`gfc_generate_function_code(ns=) at trans-decl.c:6527 frame #6: 0x000100094f24 f951`gfc_parse_file() [inlined] translate_all_program_units(gfc_global_ns_list=) at parse.c:6134 frame #7: 0x000100094e3a f951`gfc_parse_file() frame #8: 0x0001000dd157 f951`::gfc_be_parse_file() at f95-lang.c:204 frame #9: 0x000100b51b2a f951`::compile_file() at toplev.c:456 frame #10: 0x000100f64014 f951`toplev::main(int, char**) at toplev.c:2176 frame #11: 0x000100f63ee0 f951`toplev::main(this=0x7ffeefbff0fe, argc=, argv=) frame #12: 0x000100f66881 f951`main(argc=2, argv=0x7ffeefbff130) at main.c:39 frame #13: 0x7fff63ab6ed9 libdyld.dylib`start + 1
[Bug c++/89220] Inconsistent behaviour of class template type deduction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89220 --- Comment #2 from Jonathan Wakely --- (In reply to Matt A from comment #0) > Interestingly with "-std=c++1y" both x and y fail to compile, which is at > least consistent (even if I'm not sure it's correct...) It's correct. -std=c++1y is a synonym for -std=c++14 which doesn't support class template argument deduction.
[Bug c++/87709] c++17 class template argument deduction not working in a very specific case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87709 Jonathan Wakely changed: What|Removed |Added CC||matt at ookypooky dot com --- Comment #7 from Jonathan Wakely --- *** Bug 89220 has been marked as a duplicate of this bug. ***
[Bug c++/89220] Inconsistent behaviour of class template type deduction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89220 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Jonathan Wakely --- I think this is another dup of PR 87709 *** This bug has been marked as a duplicate of bug 87709 ***
[Bug tree-optimization/88415] [7/8 Regression] ICE: verify_gimple failed (error: dead STMT in EH table)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88415 --- Comment #5 from Richard Biener --- For backport depends on some earlier change.
[Bug tree-optimization/88415] [7/8 Regression] ICE: verify_gimple failed (error: dead STMT in EH table)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88415 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug target/89221] New: --enable-frame-pointer does not work as intended
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89221
Bug ID: 89221
Summary: --enable-frame-pointer does not work as intended
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: ebotcazou at gcc dot gnu.org
Target Milestone: ---
Target: i?86-*-*, x86_64-*-*
The first issue is that the code in configure.ac line 1882 reads:
AC_ARG_ENABLE(frame-pointer,
[AS_HELP_STRING([--enable-frame-pointer],
[enable -fno-omit-frame-pointer by default for 32bit x86])],
[],
[
case $target_os in
linux* | darwin[[8912]]*)
# Enable -fomit-frame-pointer by default for Linux and Darwin with
# DWARF2.
enable_frame_pointer=no
;;
*)
enable_frame_pointer=yes
;;
esac
])
so it's clear that the idea is to default to enable_frame_pointer on Linux and
Darwin and neither on Solaris nor Windows for example.
But the second part doesn't work because the associated code in config.gcc:
i[34567]86-*-*)
if test "x$enable_frame_pointer" = xyes; then
tm_defines="${tm_defines} USE_IX86_FRAME_POINTER=1"
fi
is executed *before* (line 1488 of configure.ac) so enable_frame_pointer is
empty at this point. That's why config/i386/sol2.h forcibly defines it.
On the plus side, explicitly passing --enable-frame-pointer works.
The second issue is that the x86-64 code in config.gcc reads:
x86_64-*-*)
if test "x$enable_frame_pointer" = xyes; then
tm_defines="${tm_defines} USE_IX86_FRAME_POINTER=1"
fi
but the macro is i386.c is different:
#ifndef USE_X86_64_FRAME_POINTER
#define USE_X86_64_FRAME_POINTER 0
#endif
so --enable-frame-pointer doesn't work at all for x86-64.
[Bug tree-optimization/89182] [8/9 Regression] [graphite] ICE in extract_affine, at graphite-sese-to-poly.c:280
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89182 --- Comment #3 from Richard Biener --- Author: rguenth Date: Wed Feb 6 11:18:33 2019 New Revision: 268575 URL: https://gcc.gnu.org/viewcvs?rev=268575&root=gcc&view=rev Log: 2019-02-06 Richard Biener PR tree-optimization/89182 * graphite.h (cached_scalar_evolution_in_region): Declare. * graphite.c (struct seir_cache_key): New. (struct sese_scev_hash): Likewise. (seir_cache): New global. (cached_scalar_evolution_in_region): New function. (graphite_transform_loops): Allocate and release seir_cache. * graphite-isl-ast-to-gimple.c (get_rename_from_scev): Use cached_scalar_evolution_in_region. * graphite-scop-detection.c (scop_detection::can_represent_loop): Simplify. (scop_detection::graphite_can_represent_expr: Use cached_scalar_evolution_in_region. (scop_detection::stmt_simple_for_scop_p): Likewise. (find_params_in_bb): Likewise. (gather_bbs::before_dom_children): Likewise. * graphite-sese-to-poly.c (create_pw_aff_from_tree): Likewise. (add_loop_constraints): Likewise. * gfortran.dg/graphite/pr89182.f90: New testcase. Added: trunk/gcc/testsuite/gfortran.dg/graphite/pr89182.f90 Modified: trunk/gcc/ChangeLog trunk/gcc/graphite-isl-ast-to-gimple.c trunk/gcc/graphite-scop-detection.c trunk/gcc/graphite-sese-to-poly.c trunk/gcc/graphite.c trunk/gcc/graphite.h trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/89182] [8 Regression] [graphite] ICE in extract_affine, at graphite-sese-to-poly.c:280
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89182 Richard Biener changed: What|Removed |Added Known to work||9.0 Summary|[8/9 Regression] [graphite] |[8 Regression] [graphite] |ICE in extract_affine, at |ICE in extract_affine, at |graphite-sese-to-poly.c:280 |graphite-sese-to-poly.c:280 --- Comment #4 from Richard Biener --- Fixed on trunk sofar.
[Bug rtl-optimization/89154] 5% degradation of CPU2006 473.astar starting with r266305
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89154 --- Comment #4 from Segher Boessenkool --- The r1 adjustment is establishing the stack frame. It needs to precede all stack accesses (not just those by the prologue saves!) We could separately wrap it, if that would help? You can then get multiple copies of it, that will be the only real benefit.
[Bug other/89222] New: [7.x regression] ARM thumb-2 misoptimisation of func ptr call with -O2 or -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89222 Bug ID: 89222 Summary: [7.x regression] ARM thumb-2 misoptimisation of func ptr call with -O2 or -Os Product: gcc Version: 7.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: jifl-bugzilla at jifvik dot org Target Milestone: --- Created attachment 45616 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45616&action=edit C file to demonstrate problem [ I have set the Component as "Other" as I don't know which part of GCC's optimization is at fault] On GCC 7.3.0 I am experiencing a problem where GCC is misoptimizing code built with either -O2 or -Os. The effect of the misoptimization is that it calls a function pointer without the LS bit set, even though the function is a Thumb function (it's Cortex-M, so ARM mode isn't even allowed). The attached pared-down code demonstrates this, although I couldn't manage to divorce it from my embedded run-time, so unfortunately you will have to inspect the asm :-/ The key part is that if a certain magic constant is 1, then it fails. This constant is used to compare against function pointers (it is the value of SIG_DFL from signal.h and this sort of comparison is standard practise, e.g. in glibc etc.). Values of SIG_DFL other than 1 work - it is the fact it is 1 that confuses GCC. In the asm (I used -Os as it made more tractable output), right at the start of main(), r5 is loaded with e.g. 0x23a7. Then this value plus one is put into $r6. For most of the rest of the function r6 is left as-is, and is saved and restored around the call to the hal_setjmp function. Shortly after, there is a "blx r6" and that's when the processor gets the exception. The C file shows this when built with: arm-eabi-gcc -c -mcpu=cortex-m3 -mthumb -Os signal1.c Or -O2 equally.
[Bug other/89222] [7.x regression] ARM thumb-2 misoptimisation of func ptr call with -O2 or -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89222 --- Comment #1 from Jonathan Larmour --- Created attachment 45617 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45617&action=edit Assembler file generated by GCC when compiled with -Os
[Bug target/89213] Optimize V2DI shifts by a constant on power8 & above systems.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89213 --- Comment #4 from Segher Boessenkool --- You could just do xxspltib xx,sh vsrad 2,2,xx (only the low 6 bits of the shift count are looked at, for 64-bit shifts, in all vector insns).
[Bug c++/84075] Template parameter not resolved: invalid application of ‘sizeof’ to incomplete type ‘boost::serialization::U’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84075
Marc Schmitt changed:
What|Removed |Added
CC||schmitt.marc at gmail dot com
--- Comment #5 from Marc Schmitt ---
Hi,
we encountered a the same bug.
See:
https://stackoverflow.com/questions/54534047/eigen-matrix-boostserialization-c17
The bug is reproducible with G++8.
The bug seems to be related with the (new?) template argument deduction
mechanism in G++7/8 with --std=c++17 (or --std=gnu++17).
A simplified test case (thx @Marc Giese/SO), reproducing the problem just
including Eigen without the boost dependency is attached (see below).
//
// G++ 7
//
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
7.3.0-27ubuntu1~18.04' --with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-7
--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 --with-sysroot=/ --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 7.3.0 (Ubuntu 7.3.0-27ubuntu1~18.04)
//
// G++ 8
//
$ g++-8 -v
Using built-in specs.
COLLECT_GCC=g++-8
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='Ubuntu
8.2.0-1ubuntu2~18.04' --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 --with-sysroot=/ --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 (Ubuntu 8.2.0-1ubuntu2~18.04)
//
// testcase (see: https://stackoverflow.com/a/54536756/1267320)
//
#include
templateclass SPT>void f(SPT&);
template
void f(Eigen::Matrix<_Scalar, _Rows, _Cols, _Options, _MaxRows, _MaxCols> &
arMatrix){};
int main()
{
Eigen::Matrix2d m;
f(m);
}
//
compile with: (G++7 or G++8)
g++ -std=c++17 main.cpp
//
Error output:
$ g++ -std=c++17 main.cpp
In file included from /usr/local/include/Eigen/Core:365:0,
from main.cpp:1:
/usr/local/include/Eigen/src/Core/util/ForwardDeclarations.h: In instantiation
of ‘struct Eigen::internal::accessors_level’:
main.cpp:9:8: recursively required by substitution of
‘template class SPT> void f(SPT&) [with SPT = ]’
main.cpp:9:8: required from here
/usr/local/include/Eigen/src/Core/util/ForwardDeclarations.h:32:54: error:
incomplete type ‘Eigen::internal::traits’ used in nested name specifier
enum { has_direct_access = (traits::Flags & DirectAccessBit) ? 1 :
0,
^~
/usr/local/include/Eigen/src/Core/util/ForwardDeclarations.h:33:53: error:
incomplete type ‘Eigen::internal::traits’ used in nested name specifier
has_write_access = (traits::Flags & LvalueBit) ? 1 : 0,
[Bug c++/84075] Template parameter not resolved: invalid application of ‘sizeof’ to incomplete type ‘boost::serialization::U’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84075 --- Comment #6 from Marc Schmitt --- Created attachment 45618 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45618&action=edit Reduced test case with eigen-only dependency
[Bug c++/84075] Template parameter not resolved: invalid application of ‘sizeof’ to incomplete type ‘boost::serialization::U’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84075 --- Comment #7 from Marc Schmitt --- Created attachment 45619 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45619&action=edit Preprocessed test case with eigen-only dependency
[Bug tree-optimization/89223] New: internal compiler error: in int_cst_value, at tree.c:11226
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89223
Bug ID: 89223
Summary: internal compiler error: in int_cst_value, at
tree.c:11226
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: gsocsameeran at gmail dot com
Target Milestone: ---
Host: x86_64-linux-gnu
Target: x86_64-linux-gnu
Build: x86_64-linux-gnu
Created attachment 45620
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45620&action=edit
Preprocessed code of file named "crash1.c"
--BACKTRACK-
during GIMPLE pass: pcom
crash1.c: In function ‘func_13.constprop’:
crash1.c:701:24: internal compiler error: in int_cst_value, at tree.c:11730
701 | static const int32_t * func_13(int32_t * p_14)
|^~~
0x1fa2edc int_cst_value(tree_node const*)
../../gcc/tree.c:11730
0x31bd717 initialize_matrix_A
../../gcc/tree-data-ref.c:3194
0x31bf66d analyze_subscript_affine_affine
../../gcc/tree-data-ref.c:3614
0x31c15ff analyze_siv_subscript
../../gcc/tree-data-ref.c:3925
0x31c2b16 analyze_overlapping_iterations
../../gcc/tree-data-ref.c:4171
0x31c4e49 subscript_dependence_tester_1
../../gcc/tree-data-ref.c:4713
0x31c5074 subscript_dependence_tester
../../gcc/tree-data-ref.c:4760
0x31c54c9 compute_affine_dependence(data_dependence_relation*, loop*)
../../gcc/tree-data-ref.c:4819
0x31c5a3f compute_all_dependences(vec, vec*, vec, bool)
../../gcc/tree-data-ref.c:4886
0x31c7daf compute_data_dependences_for_loop(loop*, bool, vec*, vec*,
vec*)
../../gcc/tree-data-ref.c:5360
0x1a465ac tree_predictive_commoning_loop
../../gcc/tree-predcom.c:3191
0x1a47190 tree_predictive_commoning()
../../gcc/tree-predcom.c:3313
0x1a472eb run_tree_predictive_commoning
../../gcc/tree-predcom.c:3338
0x1a473b7 execute
../../gcc/tree-predcom.c:3367
---COMMMAND LINE
~/again_build/bin/current-gcc -O3 -fgnu-tm crash1.c -I../../runtime/ -w
GCC VERSION--
current-gcc (GCC) 9.0.0 20190108 (experimental)
--PREVIOUS REPORTING---
https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=SUSPENDED&bug_status=WAITING&bug_status=REOPENED&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&cf_known_to_fail_type=allwords&cf_known_to_work_type=allwords&list_id=228813&query_format=advanced&short_desc=internal%20compiler%20error%3A%20in%20int_cst_value&short_desc_type=allwordssubstr
---REDUCED TEST CASE
a[5];
unsigned __int128 b;
c() {
b = 4;
for (;; b--)
a[b] = ({ a[b + b]; });
}
Previous reporting were on older version and reduced test case were different.
So I filed a new bug because it fails on the trunk.
[Bug target/89224] New: subscript of NEON intrinsic discards const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89224
Bug ID: 89224
Summary: subscript of NEON intrinsic discards const
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: kretz at kde dot org
Target Milestone: ---
Test case (cf. https://godbolt.org/z/RFrftn):
#include
template
void g(T &&x) {
x = 1;
}
auto f(const __Int8x8_t &x) {
g(x[0]);
//x[0] = 1; // ill-formed
}
decltype(x[0]) is `signed char&`, which can't be right if decltype(x) is
const-ref.
[Bug tree-optimization/89135] [7 Regression] internal compiler error: in gimple_split_edge, at tree-cfg.c:2747
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89135 --- Comment #6 from Richard Biener --- Author: rguenth Date: Wed Feb 6 12:56:02 2019 New Revision: 268578 URL: https://gcc.gnu.org/viewcvs?rev=268578&root=gcc&view=rev Log: 2019-02-06 Richard Biener Backport from mainline 2019-01-31 Richard Biener PR tree-optimization/89135 * tree-ssa-phiprop.c (pass_phiprop::execute): Skip blocks with abnormal preds. * gcc.dg/torture/pr89135.c: New testcase. 2019-01-18 Richard Biener PR tree-optimization/88903 * tree-vect-stmts.c (vectorizable_shift): Verify we see all scalar stmts a SLP shift amount is composed of when detecting shifts by scalars. * gcc.dg/vect/pr88903-1.c: New testcase. * gcc.dg/vect/pr88903-2.c: Likewise. Added: branches/gcc-8-branch/gcc/testsuite/gcc.dg/torture/pr89135.c branches/gcc-8-branch/gcc/testsuite/gcc.dg/vect/pr88903-1.c branches/gcc-8-branch/gcc/testsuite/gcc.dg/vect/pr88903-2.c Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/testsuite/ChangeLog branches/gcc-8-branch/gcc/tree-ssa-phiprop.c branches/gcc-8-branch/gcc/tree-vect-stmts.c
[Bug tree-optimization/88903] [7 Regression] wrong-code with SLP vectorized shift
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88903 --- Comment #8 from Richard Biener --- Author: rguenth Date: Wed Feb 6 12:56:02 2019 New Revision: 268578 URL: https://gcc.gnu.org/viewcvs?rev=268578&root=gcc&view=rev Log: 2019-02-06 Richard Biener Backport from mainline 2019-01-31 Richard Biener PR tree-optimization/89135 * tree-ssa-phiprop.c (pass_phiprop::execute): Skip blocks with abnormal preds. * gcc.dg/torture/pr89135.c: New testcase. 2019-01-18 Richard Biener PR tree-optimization/88903 * tree-vect-stmts.c (vectorizable_shift): Verify we see all scalar stmts a SLP shift amount is composed of when detecting shifts by scalars. * gcc.dg/vect/pr88903-1.c: New testcase. * gcc.dg/vect/pr88903-2.c: Likewise. Added: branches/gcc-8-branch/gcc/testsuite/gcc.dg/torture/pr89135.c branches/gcc-8-branch/gcc/testsuite/gcc.dg/vect/pr88903-1.c branches/gcc-8-branch/gcc/testsuite/gcc.dg/vect/pr88903-2.c Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/testsuite/ChangeLog branches/gcc-8-branch/gcc/tree-ssa-phiprop.c branches/gcc-8-branch/gcc/tree-vect-stmts.c
[Bug target/89213] Optimize V2DI shifts by a constant on power8 & above systems.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89213 --- Comment #5 from Michael Meissner --- Sure I could use XXSPLTIB all of the time if I limit the optimization to ISA 3.0 (power9). I was trying to add optimization for shift counts for 1..15 on ISA 2.07 (power8) as well, hence using VSPLTISW for the constants that fit in that range. Looking at the code for ISA 2.07, I think we need to extend the code for loading duplicated constants to consider using vspltisw/vupklsw on ISA 2.07 instead of xxspltib/vecb2d that we can use on ISA 3.0. I think I missed that the last time I was updating the code.
[Bug sanitizer/89215] UBSAN leaks memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89215
--- Comment #1 from Jakub Jelinek ---
Seems to be upstream bug, also in asan etc., Demangle(name) in there doesn't
really differentiate between cases where it allocated the memory or just
returned the passed in string or did something else.
E.g.
const char *MaybeDemangleGlobalName(const char *name) {
// We can spoil names of globals with C linkage, so use an heuristic
// approach to check if the name should be demangled.
bool should_demangle = false;
if (name[0] == '_' && name[1] == 'Z')
should_demangle = true;
else if (SANITIZER_WINDOWS && name[0] == '\01' && name[1] == '?')
should_demangle = true;
return should_demangle ? Symbolizer::GetOrInit()->Demangle(name) : name;
}
Not really sure if changing say:
Buffer->append("'%s'", Symbolizer::GetOrInit()->Demangle(A.String));
to:
char *str = Symbolizer::GetOrInit()->Demangle(A.String);
Buffer->append("'%s'", str);
if (str != A.String) InternalFree(str);
would be safe, after all, some demangling could be done with the internal
allocator, other with some other allocator, and libsanitizer supports many
different demangling styles.
[Bug c++/84075] Template parameter not resolved: invalid application of ‘sizeof’ to incomplete type ‘boost::serialization::U’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84075 Christoph Hertzberg changed: What|Removed |Added CC||chtz at informatik dot uni-bremen. ||de --- Comment #8 from Christoph Hertzberg --- Another case where someone hit this problem: https://stackoverflow.com/questions/54534047/eigen-matrix-boostserialization-c17/ Corresponding Bug at the Eigen-library: http://eigen.tuxfamily.org/bz/show_bug.cgi?id=1676
[Bug c++/71302] [9 Regression] -Wzero-as-null-pointer-constant: misleading caret location for pointer in function call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71302 David Malcolm changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |dmalcolm at gcc dot gnu.org Target Milestone|--- |9.0 Summary|-Wzero-as-null-pointer-cons |[9 Regression] |tant: misleading caret |-Wzero-as-null-pointer-cons |location for pointer in |tant: misleading caret |function call |location for pointer in ||function call --- Comment #3 from David Malcolm --- (In reply to Eric Gallager from comment #2) > (In reply to Manuel López-Ibáñez from comment #1) > > I don't think this can be fixed without having locations for constants (or > > at least for the arguments of function calls, thus fixing PR43486.) > > Even though bug 43486 isn't quite fixed yet, David Malcolm still made some > major progress on it for GCC 9. In GCC 8, actually. Unfortunately, it seems to have regressed on trunk. g++ 7.4 has false positives for NULL, and uses the closing parenthesis of the call as the location: : In function 'int main()': :16:14: warning: zero as null pointer constant [-Wzero-as-null-pointer-constant] Function1(0); ^ :17:17: warning: zero as null pointer constant [-Wzero-as-null-pointer-constant] Function1(NULL); ^ :18:17: warning: zero as null pointer constant [-Wzero-as-null-pointer-constant] Function2(0, 0); ^ :19:20: warning: zero as null pointer constant [-Wzero-as-null-pointer-constant] Function2(NULL, 0); ^ g++ 8.2 gets it right: : In function 'int main()': :16:13: warning: zero as null pointer constant [-Wzero-as-null-pointer-constant] Function1(0); ^ :18:13: warning: zero as null pointer constant [-Wzero-as-null-pointer-constant] Function2(0, 0); ^ g++ trunk seems to have regressed: it uses the closing parenthesis of the call as the location (but doesn't have the false positives from above): : In function 'int main()': :16:14: warning: zero as null pointer constant [-Wzero-as-null-pointer-constant] 16 | Function1(0); | ^ :18:17: warning: zero as null pointer constant [-Wzero-as-null-pointer-constant] 18 | Function2(0, 0); | ^ I'm investigating the regression.
[Bug libstdc++/88749] [9 Regression] Failure while building libstdc++-v3/src/filesystem/ops.cc on trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88749 Xi Ruoyao changed: What|Removed |Added CC||xry111 at mengyan1223 dot wang --- Comment #17 from Xi Ruoyao --- (In reply to Romain Geissler from comment #15) > Thanks for these remarks. > > FYI, what I am following are the Linux From Scratch guidelines, which build > the initial gcc like this (with both c and C++ support, disabling libstdc++ > build): > http://www.linuxfromscratch.org/lfs/view/development/chapter05/gcc-pass1.html > Then after building the glibc, they do build the libstdc++ alone like this: > http://www.linuxfromscratch.org/lfs/view/development/chapter05/gcc-libstdc++. > html > > With this PR I just found out that either my understanding of LFS is wrong, > either LFS itself is. Indeed I don't like much that when configured using my > bootstrap scripts libstdc++ doesn't use the C compiler but the C++ one to > find C headers. I will have a look to sort this out. LFS is not wrong but it's only tested with GCC-8.2, not GCC trunk. Its FAQ explicitly said "you can't gather all latest packages from ftp.gnu.org and expect them to work" :).
[Bug rtl-optimization/89225] New: [9 Regression] LRA hang on ppc64le compiling glibc starting with r268404
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89225
Bug ID: 89225
Summary: [9 Regression] LRA hang on ppc64le compiling glibc
starting with r268404
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
The following testcase hangs in LRA with -O2 -fstack-protector-strong
-mlong-double-128 on powerpc64le-linux.
extern long double foo (long double);
extern double bar (double);
typedef long long int64_t;
typedef unsigned long long uint64_t;
typedef union { int64_t i[2]; long double x; double d[2]; } mynumber;
static const double t512 = 0x1p512, tm256 = 0x1p-256, two54 = 0x1p54, twom54 =
0x1p-54;
long double
foo (long double x)
{
static const long double big = 134217728.0, big1 = 134217729.0;
long double t, s, i;
mynumber a, c;
uint64_t k, l;
int64_t m, n;
double d;
a.x = x;
k = a.i[0] & 0x7fffL;
if (k > 0x000fL && k < 0x7ff0L)
{
if (x < 0)
return (big1 - big1) / (big - big);
l = (k & 0x001fL) | 0x3fe0L;
if ((a.i[1] & 0x7fffL) != 0)
{
n = (int64_t) ((l - k) * 2) >> 53;
m = (a.i[1] >> 52) & 0x7ff;
if (m == 0)
{
a.d[1] *= two54;
m = ((a.i[1] >> 52) & 0x7ff) - 54;
}
m += n;
if (m > 0)
a.i[1] = (a.i[1] & 0x800fL) | (m << 52);
else if (m <= -54)
{
a.i[1] &= 0x8000L;
}
else
{
m += 54;
a.i[1] = (a.i[1] & 0x800fL) | (m << 52);
a.d[1] *= twom54;
}
}
a.i[0] = l;
s = a.x;
d = bar (a.d[0]);
c.i[0] = 0x2000L + ((k & 0x7fe0L) >> 1);
c.i[1] = 0;
i = d;
t = 0.5L * (i + s / i);
i = 0.5L * (t + s / t);
return c.x * i;
}
else
{
if (k >= 0x7ff0L)
return x * x + x;
if (x == 0)
return x;
if (x < 0)
return (big1 - big1) / (big - big);
return tm256 * foo (x * t512);
}
}
[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 Priority|P3 |P1 Status|UNCONFIRMED |NEW Last reconfirmed||2019-02-06 CC||vmakarov at gcc dot gnu.org Target Milestone|--- |9.0 Ever confirmed|0 |1
[Bug tree-optimization/89223] internal compiler error: in int_cst_value, at tree.c:11226
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89223 David Malcolm changed: What|Removed |Added Keywords||ice-on-valid-code Status|UNCONFIRMED |NEW Last reconfirmed||2019-02-06 CC||dmalcolm at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from David Malcolm --- Confirmed via godbolt; this crashes GCC 5 onwards, including trunk. It's failing this assertion here: 11731 /* Make sure the sign-extended value will fit in a HOST_WIDE_INT. */ 11732 gcc_assert (cst_and_fits_in_hwi (x)); where: (gdb) call debug_tree (x) constant 0xfffe>
[Bug sanitizer/89215] UBSAN leaks memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89215
--- Comment #2 from Jakub Jelinek ---
E.g. the LLVM demangler even documents that leak:
const char *DemangleCXXABI(const char *name) {
// FIXME: __cxa_demangle aggressively insists on allocating memory.
// There's not much we can do about that, short of providing our
// own demangler (libc++abi's implementation could be adapted so that
// it does not allocate). For now, we just call it anyway, and we leak
// the returned value.
if (&__cxxabiv1::__cxa_demangle)
if (const char *demangled_name =
__cxxabiv1::__cxa_demangle(name, 0, 0, 0))
return demangled_name;
return name;
}
on the other side, e.g.
const char *WinSymbolizerTool::Demangle(const char *name) {
CHECK(is_dbghelp_initialized);
static char demangle_buffer[1000];
if (name[0] == '\01' &&
UnDecorateSymbolName(name + 1, demangle_buffer, sizeof(demangle_buffer),
UNDNAME_NAME_ONLY))
return demangle_buffer;
else
return name;
}
will not allocate anything and so trying to free wouldn't work.
[Bug c++/89158] [8 Regression] by-value capture of ICE variable isn't an lvalue?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89158 --- Comment #8 from Marek Polacek --- Author: mpolacek Date: Wed Feb 6 15:26:24 2019 New Revision: 268580 URL: https://gcc.gnu.org/viewcvs?rev=268580&root=gcc&view=rev Log: PR c++/89158 - by-value capture of constexpr variable broken. * call.c (convert_like_real) : Call mark_exp_read instead of mark_rvalue_use. Added: branches/gcc-8-branch/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-89158.C Modified: branches/gcc-8-branch/gcc/cp/ChangeLog branches/gcc-8-branch/gcc/cp/call.c
[Bug c++/89158] [8 Regression] by-value capture of ICE variable isn't an lvalue?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89158 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Marek Polacek --- Fixed.
[Bug go/89199] libgo intermittent testcase failures on ppc64le power9 after r268458
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89199
boger at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P2
Severity|normal |major
--- Comment #1 from boger at gcc dot gnu.org ---
I have raised this priority because this looks like a bug in the Go code due to
the use of __atomic_compare_exchange_n builtin and how it is implementing the
CompareAndSwapUintptr.
In atomic.c:
_Bool
CompareAndSwapUintptr (uintptr_t *val, uintptr_t old, uintptr_t new)
{
return __atomic_compare_exchange_n (val, &old, new, true, __ATOMIC_SEQ_CST,
__ATOMIC_RELAXED);
}
The true argument is indicating 'weak' which results in the following code.
Note that there is no guarantee in this code that the CompareAndSwap will do
the store and return true, if it can't get the reservation it will return false
and the store won't happen.
010cc280 :
10cc280: ac 04 00 7c hwsync
10cc284: a8 18 20 7d ldarx r9,0,r3
10cc288: 00 20 29 7c cmpdr9,r4
10cc28c: 0c 00 82 40 bne 10cc298
10cc290: ad 19 a0 7c stdcx. r5,0,r3
10cc294: 2c 01 00 4c isync
10cc298: 26 00 78 7c mfocrf r3,128
10cc29c: fe 1f 63 54 rlwinm r3,r3,3,31,31
10cc2a0: 20 00 80 4e blr
If I look in sync/cond.go check() function:
func (c *copyChecker) check() {
if uintptr(*c) != uintptr(unsafe.Pointer(c)) &&
!atomic.CompareAndSwapUintptr((*uintptr)(c), 0,
uintptr(unsafe.Pointer(c))) &&
uintptr(*c) != uintptr(unsafe.Pointer(c)) {
panic("sync.Cond is copied")
}
}
This if check assumes that the CompareAndSwapUinptr will do the store if needed
which is not true with the latest implementation of CompareAndSwapUintptr. It
seems that the CompareAndSwapUinptr should be passing the argument to indicate
'strong' and not 'weak'. I made that change and that fixes this problem. I have
not checked the other CompareAndSwaps.
[Bug c++/88983] [7/8 Regression] ICE in label_matches, at cp/constexpr.c:4035
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88983 --- Comment #7 from Marek Polacek --- Author: mpolacek Date: Wed Feb 6 15:29:14 2019 New Revision: 268581 URL: https://gcc.gnu.org/viewcvs?rev=268581&root=gcc&view=rev Log: PR c++/88983 - ICE with switch in constexpr function. * constexpr.c (cxx_eval_switch_expr): Use SWITCH_COND and SWITCH_BODY. (cxx_eval_constant_expression) : Don't look for the label in the else branch if we found it in the then branch. Added: branches/gcc-8-branch/gcc/testsuite/g++.dg/cpp1y/constexpr-88983.C Modified: branches/gcc-8-branch/gcc/cp/ChangeLog branches/gcc-8-branch/gcc/cp/constexpr.c
[Bug c++/88983] [7 Regression] ICE in label_matches, at cp/constexpr.c:4035
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88983 Marek Polacek changed: What|Removed |Added Summary|[7/8 Regression] ICE in |[7 Regression] ICE in |label_matches, at |label_matches, at |cp/constexpr.c:4035 |cp/constexpr.c:4035 --- Comment #8 from Marek Polacek --- Fixed for 8 too.
[Bug c++/89119] [7/8 Regression] internal compiler error: in tsubst_copy with RANGE_EXPR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89119 --- Comment #9 from Marek Polacek --- Author: mpolacek Date: Wed Feb 6 15:33:18 2019 New Revision: 268582 URL: https://gcc.gnu.org/viewcvs?rev=268582&root=gcc&view=rev Log: PR c++/89119 - ICE with value-initialization in template. * pt.c (tsubst_copy_and_build): Handle RANGE_EXPR. Added: branches/gcc-8-branch/gcc/testsuite/g++.dg/cpp0x/initlist-value3.C Modified: branches/gcc-8-branch/gcc/cp/ChangeLog branches/gcc-8-branch/gcc/cp/pt.c
[Bug tree-optimization/89223] internal compiler error: in int_cst_value, at tree.c:11226
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89223
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek ---
Updated testcase that doesn't have UB at runtime if it was ever called:
int a[9];
unsigned __int128 b;
void
foo (void)
{
for (b = 4; b != 0; b--)
a[b] = a[b + b];
}
[Bug c++/89119] [7 Regression] internal compiler error: in tsubst_copy with RANGE_EXPR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89119 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Summary|[7/8 Regression] internal |[7 Regression] internal |compiler error: in |compiler error: in |tsubst_copy with RANGE_EXPR |tsubst_copy with RANGE_EXPR --- Comment #10 from Marek Polacek --- Fixed for 8 too.
[Bug c++/89024] [7/8 Regression] ICE testing convertibility of incomplete enumeration types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89024 --- Comment #9 from Marek Polacek --- Author: mpolacek Date: Wed Feb 6 15:36:20 2019 New Revision: 268583 URL: https://gcc.gnu.org/viewcvs?rev=268583&root=gcc&view=rev Log: PR c++/89024 - ICE with incomplete enum type. * call.c (standard_conversion): When converting an ARITHMETIC_TYPE_P to an incomplete type, return NULL. Added: branches/gcc-8-branch/gcc/testsuite/g++.dg/cpp0x/enum37.C Modified: branches/gcc-8-branch/gcc/cp/ChangeLog branches/gcc-8-branch/gcc/cp/call.c
[Bug c++/89024] [7 Regression] ICE testing convertibility of incomplete enumeration types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89024 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Summary|[7/8 Regression] ICE|[7 Regression] ICE testing |testing convertibility of |convertibility of |incomplete enumeration |incomplete enumeration |types |types --- Comment #10 from Marek Polacek --- Fixed for 8 too.
[Bug c++/88983] [7 Regression] ICE in label_matches, at cp/constexpr.c:4035
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88983 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Marek Polacek --- .
[Bug target/84251] [8/9 Regression] Performance regression in gcc 8/9 when comparing floating point numbers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84251 Jeffrey A. Law changed: What|Removed |Added CC||law at redhat dot com --- Comment #10 from Jeffrey A. Law --- Couldn't this be tackled in DOM? For A UNORDERED_EXPR B, on the true arm we record A != B must be true. A ORDERED_EXPR B, on the false arm we record A != B must be true. We might also be able to record something about the NaN status of A and B on the other arms as well.
[Bug tree-optimization/89223] internal compiler error: in int_cst_value, at tree.c:11226
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89223
--- Comment #3 from Jakub Jelinek ---
Started with r210113.
int_cst_value changed there:
/* Make sure the sign-extended value will fit in a HOST_WIDE_INT. */
- gcc_assert (TREE_INT_CST_HIGH (x) == 0
- || TREE_INT_CST_HIGH (x) == -1);
+ gcc_assert (cst_and_fits_in_hwi (x));
which is not equivalent, as previously it wasn't testing whether it has signed
or unsigned type, now it is.
With a small modification:
int a[9];
unsigned __int128 b;
void
foo (void)
{
for (b = (((unsigned __int128) 4) << 64) + 4; b != 0; b -= unsigned
__int128) 1) << 64) + 1))
a[b] = a[b + b];
}
(where it relies on sizetype/pointers being at most 64-bit), it started to ICE
with r159879 when __int128 support has been introduced.
[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 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P2 Target Milestone|--- |7.5 Summary|internal compiler error: in |[7/8/9 Regression] internal |int_cst_value, at |compiler error: in |tree.c:11226|int_cst_value, at ||tree.c:11226
[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 --- Comment #1 from Vladimir Makarov --- It seems my latest patch for PR87246 caused this: https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=268404
[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 #4 from Jakub Jelinek --- I guess either we should lower ARRAY_REF indexes with precisions higher than pointer precision to that smaller precision early (during gimplification e.g.?), though not really sure what effect would that have on weirdo targets with 20/24-bit etc. pointers and sizetype say even smaller than pointers, or we should just punt somewhere in the data dependence handling for anything that involves integers with > HOST_BITS_PER_WIDE_INT precisions.
[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
Jakub Jelinek changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comment #5 from Jakub Jelinek ---
The gimplifier change would be something like:
--- gimplify.c.jj 2019-01-28 23:30:53.199762928 +0100
+++ gimplify.c 2019-02-06 17:15:35.368976785 +0100
@@ -2977,6 +2977,10 @@ gimplify_compound_lval (tree *expr_p, gi
if (TREE_CODE (t) == ARRAY_REF || TREE_CODE (t) == ARRAY_RANGE_REF)
{
+ if (!error_operand_p (TREE_OPERAND (t, 1))
+ && (TYPE_PRECISION (TREE_TYPE (TREE_OPERAND (t, 1)))
+ > TYPE_PRECISION (sizetype)))
+ TREE_OPERAND (t, 1) = fold_convert (sizetype, TREE_OPERAND (t, 1));
/* Gimplify the dimension. */
if (!is_gimple_min_invariant (TREE_OPERAND (t, 1)))
{
and besides the fears about weirdo targets I think it is the right thing even
on 32-bit targets when they use long long indexes into arrays. After all, if
we gimplify it into pointer arithmetics, we'd cast to sizetype anyway.
Richard, thoughts on this?
Or if we fear too much, we could do that only if pointers have the same
precision as sizetype or something similar, I think weirdo targets will not
have support for > 64-bit integral types anyway.
[Bug target/88856] [8/9 Regression] gfortran producing wrong code with -funroll-loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88856 --- Comment #22 from Jakub Jelinek --- What we could do there is remove the first of those two splitters, remove the && !dead_or_set_p (insn, operands[1]) test from the second, and add peephole2 that would transform (set (access part 1) (subreg:SI (match_dup 1) low)) (set (match_dup 1) (rotate:DI (match_dup 1) (const_int 32))) (set (access part 2) (subreg:SI (match_dup 1) low)) with a lshiftrt instead of rotate if reg 1 is dead after the third insn (assuming rotate is more expensive as right shift, if it is the same expensive/same size, then having the two splitters makes no sense). The last rotate should have been removed by DCE already if it was truly dead (though, of course, if it for some reason isn't yet, you could have another peephole2 for that too).
[Bug target/88856] [8/9 Regression] gfortran producing wrong code with -funroll-loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88856 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #23 from Jakub Jelinek --- That said, the regression is fixed now.
[Bug go/89123] Too many go test failures on s390x-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89123 --- Comment #10 from rdapp at linux dot ibm.com --- Created attachment 45621 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45621&action=edit Tentative patch for libgo on s390x I didn't manage to make much progress with analyzing the remaining FAILs but I guess this can wait until after this bug. Is there an easy/preferred way to build and debug a single test case without having to manually add a plethora of dependency arguments? Attached is a tentative patch that works for me on s390x and reduces the number of FAILs significantly. Does it look reasonable?
[Bug target/89213] Optimize V2DI shifts by a constant on power8 & above systems.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89213 --- Comment #6 from Segher Boessenkool --- For 32-bit or smaller shifts you can use vspltisb always, or vspltis[hw] if you prefer. If generating code for ISA 2.07 (Power8) you don't have xxspltib but you do have vsld/vsrd/vsrad/vrld, hrm. You still can always generate the constant with just two insns of course (vspltis* and either a vsl* or a vrl* by 1, depending if you need the low bit 0 or 1, for example). But you cannot in general do it in one (non-load ;-) ) insn I think.
[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 #7 from Steve Ellcey ---
(In reply to Richard Biener from comment #6)
> If Martins bisection to power.fppized.o is correct you can bisect the loop
> via the vect_loop or vect_slp debug counters (or first try with just
> -fno-tree-{loop,slp}-vectorize to narrow down to loop vs. BB vectorization).
I will let one of the x86 experts try that. I was just surprised to find that
one of the most popular benchmarks fails on one of the most popular targets
and that it has been that way for about a year.
[Bug rtl-optimization/89195] [7/8 regression] Corrupted stack offset after combine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89195 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Summary|[7/8/9 regression] |[7/8 regression] Corrupted |Corrupted stack offset |stack offset after combine |after combine | --- Comment #13 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug rtl-optimization/87871] [9 Regression] testcases fail after r265398 on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
Wilco changed:
What|Removed |Added
CC||wilco at gcc dot gnu.org
--- Comment #8 from Wilco ---
(In reply to Segher Boessenkool from comment #5)
> The first one just needs an xfail. I don't know if it should be *-*-* there
> or only arm*-*-* should be added.
>
> The other two need some debugging by someone who knows the target and/or
> these tests.
The previous code for Arm was:
cbz r0, .L5
push{r4, lr}
mov r4, r0
bl foo
movwr2, #:lower16:.LANCHOR0
movtr2, #:upper16:.LANCHOR0
add r4, r4, r0
str r4, [r2]
pop {r4, pc}
.L5:
movsr0, #1
bx lr
Now it fails to shrinkwrap:
push{r4, lr}
mov r4, r0
cmp r4, #0
moveq r0, #1
beq .L3
bl foo
ldr r2, .L7
add r3, r4, r0
str r3, [r2]
.L3:
pop {r4, lr}
bx lr
It seems shrinkwrapping is more random, sometimes it's done as expected,
sometimes it is not. It was more consistent on older GCC's.
[Bug libstdc++/89102] 'common_type' of single abominable function should not have a nested typename
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89102 --- Comment #3 from Jonathan Wakely --- Author: redi Date: Wed Feb 6 17:25:26 2019 New Revision: 268586 URL: https://gcc.gnu.org/viewcvs?rev=268586&root=gcc&view=rev Log: PR libstdc++/89102 fix common_type<> and common_type specializations This is a partial implementation of the revised std::common_type rules from P0435R1. PR libstdc++/89102 (partial) * include/std/type_traits (common_type<>): Define. (common_type): Derive from common_type. * testsuite/20_util/common_type/requirements/explicit_instantiation.cc: Test zero-length template argument list. * testsuite/20_util/common_type/requirements/sfinae_friendly_1.cc: Test additional single argument cases. * testsuite/20_util/common_type/requirements/sfinae_friendly_2.cc: Adjust expected error. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/std/type_traits trunk/libstdc++-v3/testsuite/20_util/common_type/requirements/explicit_instantiation.cc trunk/libstdc++-v3/testsuite/20_util/common_type/requirements/sfinae_friendly_1.cc trunk/libstdc++-v3/testsuite/20_util/common_type/requirements/sfinae_friendly_2.cc
[Bug rtl-optimization/88596] [9 Regression] ICE: Maximum number of LRA assignment passes is achieved (30)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88596
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2019-02-06
Ever confirmed|0 |1
--- Comment #7 from Jakub Jelinek ---
The above testcase reproduced, reduced to following, started with r266385.
Note, this testcase ICEd in gcc 7.x and earlier too, got fixed with r258504
(started with r225484). So, this testcase is effectively [7/9 Regression].
/* { dg-do compile } */
/* { dg-options "-O1 -fschedule-insns -fselective-scheduling -fno-tree-ter" }
*/
/* { dg-additional-options "-maccumulate-outgoing-args" { target i?86-*-*
x86_64-*-* } } */
void bar ();
void baz ();
void qux ();
_Complex char a, b, c, d, e, f, g, h, i, j, k, l, m, n, o;
void
foo ()
{
bar (b, c, d, e, 5);
baz (4, a, b, c, d);
baz (5, a, b, c, d, e);
baz (b, c, d, e, f);
baz (b, c, d, e, f, g);
baz (b, c, d, e, f, g, h);
baz (b, c, d, e, f, g, h, i);
baz (j);
baz (i, j, h, i, j, k, l, m, n, o);
qux (e, g, i, k, m, o);
}
The ICE in 6.x/7.x used to be like:
pr88596.c: In function ‘foo’:
pr88596.c:19:1: error: unable to find a register to spill
}
^
pr88596.c:19:1: error: this is the insn:
(insn 23 381 380 2 (set (zero_extract:SI (reg:SI 226 [orig:195 D.1795+1 ]
[195])
(const_int 8 [0x8])
(const_int 8 [0x8]))
(reg:SI 227)) pr88596.c:9 115 {insvsi_1}
(expr_list:REG_DEAD (reg:SI 227)
(nil)))
pr88596.c:19:1: internal compiler error: in assign_by_spills, at
lra-assigns.c:1417
[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
--- Comment #4 from Marek Polacek ---
Some sort of modification happens twice for the RANGE_FOR_EXPR. Originally we
have
{*((struct S *) this)->r}
which should be turned to
TARGET_EXPR r}>
but we now reprocess this again and get bogus
TARGET_EXPR r}>
[Bug target/89222] [7.x regression] ARM thumb-2 misoptimisation of func ptr call with -O2 or -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89222 --- Comment #2 from Jakub Jelinek --- Not confirming since it is unclear even on what OS you are using this and what to look for (I don't see r5 set close to start of main etc.). That said, if hal_setjmp works similarly to setjmp, but you don't actually tell the compiler it has that behavior through __attribute__((__returns_twice__)) and it doesn't have one of the standard setjmp names, like setjmp, sigsetjmp, savectx, vfork or getcontext (with optional _ or __ prefixes), then it surprises me if it works at all.
[Bug c++/88049] [7/8/9 Regression] ICE in lto_symtab_prevailing_virtual_decl at gcc/lto/lto-symtab.c:1075 since r231671
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88049 --- Comment #4 from Jason Merrill --- (In reply to Jan Hubicka from comment #3) > > > We ICE on the fact that _ZTV1aIN12_GLOBAL__N_11fEE which is vtable for > > > anonymous namespace type but it has EXTERNAL flag set. > > > > > > Jason, why this happens? I am changing type to C++: if there is indeed > > > legal > > > reason to have exported vtables for anonymous types, then we can simply > > > drop > > > the sanity check. > > > > It isn't exported; it has DECL_EXTERNAL set because it isn't defined, and it > > isn't defined because nothing uses it, so it isn't needed. Note that it > > isn't > > TREE_PUBLIC. > > Hmm, so perhaps just adjusting sanity check to also check || > !TREE_PUBLIC? I'd suggest changing the behavior on type_in_anonymous_namespace_p to just "return decl".
[Bug target/84251] [8/9 Regression] Performance regression in gcc 8/9 when comparing floating point numbers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84251 --- Comment #11 from Jeffrey A. Law --- Oh, DOM is too early, it's expansion that exposes the redundancies. Seems like CSE ought to be able to pick this up though.
[Bug target/89222] [7.x regression] ARM thumb-2 misoptimisation of func ptr call with -O2 or -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89222 --- Comment #3 from Jonathan Larmour --- Thanks for the quick reply. (In reply to Jakub Jelinek from comment #2) > Not confirming since it is unclear even on what OS you are using this It's an embedded OS, so from your point of view, it's essentially bare metal. There are no included headers in the testcase so I'm not expecting the OS to make a difference in terms of generated asm. I would have expected any arm-none-eabi toolchain based on 7.3 would do the same thing as the one I built at least. > and > what to look for (I don't see r5 set close to start of main etc.). I attached the generated assembly file I get with --save-temps and the compile command line I provided (using -Os). You can see r5 being set on line 50 of that file. > That > said, if hal_setjmp works similarly to setjmp, but you don't actually tell > the compiler it has that behavior through __attribute__((__returns_twice__)) > and it doesn't have one of the standard setjmp names, like setjmp, > sigsetjmp, savectx, vfork or getcontext (with optional _ or __ prefixes), > then it surprises me if it works at all. Fortunately the semantics of hal_setjmp aren't relevant for the purposes of this bug - it's just a function call. Since the processor exception occurs when attempting to call myhandler2(), the longjmp() is never reached. In fact myhandler2() can be empty... perhaps I should have done that to emphasise that point, sorry. Thanks, Jifl
[Bug debug/87451] FAIL: gcc.dg/debug/dwarf2/inline5.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87451 --- Comment #14 from Rainer Orth --- Author: ro Date: Wed Feb 6 18:54:16 2019 New Revision: 268588 URL: https://gcc.gnu.org/viewcvs?rev=268588&root=gcc&view=rev Log: Fix gcc.dg/debug/dwarf2/inline5.c with Solaris as (PR debug/87451) PR debug/87451 * gcc.dg/debug/dwarf2/inline5.c: Allow for non-comment before "(DIE (0x[0-9a-f]*) DW_TAG_variable". xfail scan-assembler-not with Solaris as. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/debug/dwarf2/inline5.c
[Bug target/89222] [7.x regression] ARM thumb-2 misoptimisation of func ptr call with -O2 or -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89222 Andrew Pinski changed: What|Removed |Added Keywords||wrong-code --- Comment #4 from Andrew Pinski --- I think the bug is in the assembler or the linker: .L22: .word myhandler2-1 Basically what is happening is: (__handler != ((__sighandler_t) 2)) && (__handler != ((__sighandler_t) SIG_DFL)) is converted to: (((size_t)__handler)-1) <= 1 And then GCC emits myhandler2-1 in the constant pool which is correct but the assembler/linker decides to put 0x23a7 in that location (See the .L22 above) and then GCC adds +1 to it to try to make it myhandler2 (again). This is why using SIG_DFL of 5 works, it is just by accident because GCC decides not to do the transformation or put myhandler2-1 in the constant pool. Again I think this is an assembler/linker issue of putting the wrong value for .L22: .word myhandler2-1
[Bug c++/89226] New: codegen for copying a 512-bit object fails to use avx instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89226
Bug ID: 89226
Summary: codegen for copying a 512-bit object fails to use avx
instructions
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: barry.revzin at gmail dot com
Target Milestone: ---
Consider the following example:
#include
// DUMB PAIR
struct dumb_pair {
alignas(2*sizeof(__m256i)) __m256i x[2];
};
void copy1(const dumb_pair& from, dumb_pair& to) {
to = from;
}
// SMART PAIR
struct foo512 {
__m256i a;
__m256i b;
auto& operator=(const foo512& f) {
a = f.a;
b = f.b;
return *this;
}
};
struct smart_pair {
union {
foo512 y;
__m256i x[2];
};
smart_pair(const smart_pair& sp) {
y = sp.y;
}
smart_pair& operator=(const smart_pair& sp) {
y = sp.y;
return *this;
}
};
void copy2(const smart_pair& from, smart_pair& to) {
to = from;
}
when compiled with:
g++ -mavx -O3 -march=corei7-avx -mtune=corei7-avx
on latest gcc (either trunk or 8.2 or 7.4) emits
(https://godbolt.org/z/mZj4VU):
copy1(dumb_pair const&, dumb_pair&):
vmovdqa xmm0, XMMWORD PTR [rdi]
vmovaps XMMWORD PTR [rsi], xmm0
vmovdqa xmm1, XMMWORD PTR [rdi+16]
vmovaps XMMWORD PTR [rsi+16], xmm1
vmovdqa xmm2, XMMWORD PTR [rdi+32]
vmovaps XMMWORD PTR [rsi+32], xmm2
vmovdqa xmm3, XMMWORD PTR [rdi+48]
vmovaps XMMWORD PTR [rsi+48], xmm3
ret
copy2(smart_pair const&, smart_pair&):
vmovdqa ymm0, YMMWORD PTR [rdi]
vmovdqa ymm1, YMMWORD PTR [rdi+32]
vmovdqa YMMWORD PTR [rsi], ymm0
vmovdqa YMMWORD PTR [rsi+32], ymm1
vzeroupper
ret
copy2() is better than copy1(). If we remove the user-provided copy assignment
operator from foo512 (even though the user-provided implementation is the same
as the default), the smart_pair code becomes the same as dumb_pair code.
clang++ emits the same code in both cases: the same code as copy2() in this
example.
[Bug libstdc++/89102] 'common_type' of single abominable function should not have a nested typename
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89102 --- Comment #4 from Jonathan Wakely --- Minimal fix committed to trunk, with a complete fix posted to https://gcc.gnu.org/ml/gcc-patches/2019-02/msg00346.html for stage 1.
[Bug libstdc++/89102] 'common_type' of single abominable function should not have a nested typename
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89102 Jonathan Wakely changed: What|Removed |Added Target Milestone|9.0 |8.3
[Bug c++/71302] [9 Regression] -Wzero-as-null-pointer-constant: misleading caret location for pointer in function call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71302 --- Comment #4 from David Malcolm --- Author: dmalcolm Date: Wed Feb 6 19:44:52 2019 New Revision: 268589 URL: https://gcc.gnu.org/viewcvs?rev=268589&root=gcc&view=rev Log: Fix locations in conversion_null_warnings (PR c++/71302) PR c++/71302 reports that g++ shows poor locations for -Wzero-as-null-pointer-constant for pointers in function calls, using the close parenthesis of the call, rather than showing the pertinent argument. This particular case was fixed in GCC 8, but regressed on trunk in r260973. This patch fixes the regression, and adds column numbers to the test cases (where they're correct) to avoid regressing them in the future. There are still various places where the locations aren't correct, but fixing them isn't stage 4 material. gcc/cp/ChangeLog: PR c++/71302 * call.c (get_location_for_expr_unwinding_for_system_header): New function. (conversion_null_warnings): Use it when getting locations for EXPR, effectively adding a call to get_location_for_expr_unwinding_for_system_header for -Wconversion-null and making use of EXPR_LOCATION for -Wzero-as-null-pointer-constant. gcc/testsuite/ChangeLog: PR c++/71302 * g++.dg/cpp0x/Wzero-as-null-pointer-constant-1.C: Add expected column numbers to dg-warning directives where they are correct. * g++.dg/warn/Wzero-as-null-pointer-constant-5.C: Likewise. * g++.dg/warn/Wzero-as-null-pointer-constant-7.C: Likewise. * g++.dg/warn/Wzero-as-null-pointer-constant-8.C: New test. Added: trunk/gcc/testsuite/g++.dg/warn/Wzero-as-null-pointer-constant-8.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/cpp0x/Wzero-as-null-pointer-constant-1.C trunk/gcc/testsuite/g++.dg/warn/Wzero-as-null-pointer-constant-1.C trunk/gcc/testsuite/g++.dg/warn/Wzero-as-null-pointer-constant-5.C trunk/gcc/testsuite/g++.dg/warn/Wzero-as-null-pointer-constant-7.C
[Bug c++/71302] [9 Regression] -Wzero-as-null-pointer-constant: misleading caret location for pointer in function call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71302 David Malcolm changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from David Malcolm --- Locations for -Wzero-as-null-pointer-constant for function-call arguments should be fixed by r268589; marking this as "FIXED". There are still some places in the existing testcases where the location's aren't quite right, but they don't relate to function calls.
[Bug go/89227] New: gotools test cmd/go fails with link error "call lacks nop, can't restore toc; recompile with -fPIC"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89227 Bug ID: 89227 Summary: gotools test cmd/go fails with link error "call lacks nop, can't restore toc; recompile with -fPIC" Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go Assignee: ian at airs dot com Reporter: boger at gcc dot gnu.org CC: cmang at google dot com, wschmidt at gcc dot gnu.org Target Milestone: --- Target: ppc64le I'm not sure when this testcase started failing. I can get it to fail consistently if I configure my gccgo build with lto (--enable-languages=c,c++,go,lto). However after searching the gcc-testresults output, it only fails intermittently on those runs, and they don't configure with lto. gotools.log shows this: Running cmd/go cd check-go-dir/src/cmd/go && PATH=/home/boger/gccgo.work/trunk/bld/gotools:/home/boger/golang/base/go/bin:/home/boger/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin GCCGO='/home/boger/gccgo.work/trunk/bld/gotools/check-gccgo' CC='/home/boger/gccgo.work/trunk/bld/gotools/check-gcc' GCCGOTOOLDIR='/home/boger/gccgo.work/trunk/bld/gotools' GO_TESTING_GOTOOLS=yes LD_LIBRARY_PATH=/home/boger/gccgo.work/trunk/bld/powerpc64le-linux/libgo/.libs GOROOT=/home/boger/gccgo.work/trunk/bld/powerpc64le-linux/libgo GOCACHE=/home/boger/gccgo.work/trunk/bld/gotools/gocache-test GOPATH=/home/boger/gccgo.work/trunk/bld/gotools/check-go-dir /home/boger/gccgo.work/trunk/bld/gotools/go test -test.short -test.timeout=600s -test.v # cmd/go.test /home/boger/gccgo.work/trunk/bld/gotools/check-go-dir/src/cmd/go/script_test.go:283: error: call lacks nop, can't restore toc; recompile with -fPIC collect2: error: ld returned 1 exit status FAILcmd/go [build failed] Here are the steps I use to get down to a compile command to test with: >cd bld/gotools >make check-go-tool This will generate the directories needed for the above command. In order to see everything, you might need to remove directory gocache_test. Submit the above command, adding -x -work before -test.short and direct that into a file like this: cd check-go-dir/src/cmd/go && PATH=/home/boger/gccgo.work/trunk/bld/gotools:/home/boger/golang/base/go/bin:/home/boger/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin GCCGO='/home/boger/gccgo.work/trunk/bld/gotools/check-gccgo' CC='/home/boger/gccgo.work/trunk/bld/gotools/check-gcc' GCCGOTOOLDIR='/home/boger/gccgo.work/trunk/bld/gotools' GO_TESTING_GOTOOLS=yes LD_LIBRARY_PATH=/home/boger/gccgo.work/trunk/bld/powerpc64le-linux/libgo/.libs GOROOT=/home/boger/gccgo.work/trunk/bld/powerpc64le-linux/libgo GOCACHE=/home/boger/gccgo.work/trunk/bld/gotools/gocache-test GOPATH=/home/boger/gccgo.work/trunk/bld/gotools/check-go-dir /home/boger/gccgo.work/trunk/bld/gotools/go test -x -work -test.short -test.timeout=600s -test.v 2> link.out The error message happens because the call to testenv.HasLink does not have a nop following its 'bl' instruction. This call occurs in script_test.go. In the link.out find the value for $WORK and then the compile command that includes script_test.go. I was able to minimize the go files to these, and put the output file into the current directory instead of under $WORK. ../../../../check-gccgo -c -g -fdebug-prefix-map=$WORK=/tmp/go-build -gno-record-gcc-switches -fgo-pkgpath=cmd/go_test -O0 -o _go_.o -I $WORK/b104/_importcfgroot_ ./go_test.go ./proxy_test.go ./script_test.go -v Using the -v output I use this command: /home/boger/gccgo.work/trunk/bld/./gcc/go1 ./go_test.go ./proxy_test.go ./script_test.go -quiet -dumpbase go_test.go -auxbase-strip _go_.o -g -gno-record-gcc-switches -O0 -version -fdebug-prefix-map=/tmp/go-build260802146=/tmp/go-build -fgo-pkgpath=cmd/go_test -I /tmp/go-build260802146/b104/_importcfgroot_ -I /home/boger/gccgo.work/trunk/bld/powerpc64le-linux/libgo -L/home/boger/gccgo.work/trunk/bld/powerpc64le-linux/libgo -L/home/boger/gccgo.work/trunk/bld/powerpc64le-linux/libgo/.libs -L/home/boger/gccgo.work/trunk/bld/./gcc -L/home/boger/gccgo.work/trunk/bld/powerpc64le-linux/libgo/../libstdc++-v3/src/.libs -L/home/boger/gccgo.work/trunk/bld/powerpc64le-linux/libgo/../libstdc++-v3/libsupc++/.libs -L/lib/powerpc64le-linux-gnu -L/lib/../lib64 -L/usr/lib/powerpc64le-linux-gnu -fdump-rtl-expand -o /tmp/ccqwFgbq.s I can see in the asm output file, that there is no nop following the call to HasLink: .LBB2080: .loc 5 283 18 bl internal..z2ftestenv.HasLink .LEHE4985: mr 9,3 But there is one after all other calls in the file including others from testenv. I did an rtl dump too although not sure what this is telling me. The call to HasLink looks like this: (call_insn 1086 1085 1973 191 (parallel [ (set (reg:DI 3 3) (call (mem:SI (symbol
[Bug target/89226] codegen for copying a 512-bit object fails to use avx instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89226 --- Comment #1 from Marc Glisse --- The optimized dump for copy1 looks like *to_2(D) = *from_3(D); so we get essentially memcpy, while copy2 has _4 = MEM[(const struct foo512 &)from_3(D)].a; MEM[(struct foo512 *)to_2(D)].a = _4; _5 = MEM[(const struct foo512 &)from_3(D)].b; MEM[(struct foo512 *)to_2(D)].b = _5; which we expand literally. I agree that we should generate the same code for both (ideally we would reach expand with essentially the same GIMPLE representation, although I am not sure how). A question is whether the memcpy expansion is optimal for that target. It could be that as long as you are only copying a rather small object, it isn't worth switching to larger registers which cause a drop in the processor frequency. However the code generated is not impacted if I use other AVX instructions nearby. -Os can make us generate 'rep movsl' for copy1.
[Bug go/89227] gotools test cmd/go fails with link error "call lacks nop, can't restore toc; recompile with -fPIC"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89227
--- Comment #1 from Ian Lance Taylor ---
Same as https://golang.org/issue/29046?
I would bet that this has something to do with the fact that testenv.HasLink is
inlinable. Something is wrong with the way that the frontend is passing the
inlinable function to the backend. The specific code in gcc/go/go-gcc.cc is in
Gcc_backend::function:
if ((flags & function_only_inline) != 0)
{
DECL_EXTERNAL(decl) = 1;
DECL_DECLARED_INLINE_P(decl) = 1;
}
This is intended to tell the backend to treat the function the way it treats a
C gnu89 extern inline function. This seems to work fine on x86 but perhaps I
am missing something on ppc64le.
[Bug target/89226] codegen for copying a 512-bit object fails to use avx instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89226 --- Comment #2 from Jakub Jelinek --- That is because in copy1 it is a normal memcpy expansion. And, the generic move_by_pieces case is done in preference to target specific one. In i386.h we have: /* Max number of bytes we can move from memory to memory in one reasonably fast instruction. */ #define MOVE_MAX 16 /* MOVE_MAX_PIECES is the number of bytes at a time which we can move efficiently, as opposed to MOVE_MAX which is the maximum number of bytes we can move with a single instruction. ??? We should use TImode in 32-bit mode and use OImode or XImode if they are available. But since by_pieces_ninsns determines the widest mode with MAX_FIXED_MODE_SIZE, we can only use TImode in 64-bit mode. */ #define MOVE_MAX_PIECES \ ((TARGET_64BIT \ && TARGET_SSE2 \ && TARGET_SSE_UNALIGNED_LOAD_OPTIMAL \ && TARGET_SSE_UNALIGNED_STORE_OPTIMAL) \ ? GET_MODE_SIZE (TImode) : UNITS_PER_WORD) and in defaults.h /* MOVE_MAX_PIECES is the number of bytes at a time which we can move efficiently, as opposed to MOVE_MAX which is the maximum number of bytes we can move with a single instruction. */ #ifndef MOVE_MAX_PIECES #define MOVE_MAX_PIECES MOVE_MAX #endif /* STORE_MAX_PIECES is the number of bytes at a time that we can store efficiently. Due to internal GCC limitations, this is MOVE_MAX_PIECES limited by the number of bytes GCC can represent for an immediate constant. */ #ifndef STORE_MAX_PIECES #define STORE_MAX_PIECES MIN (MOVE_MAX_PIECES, 2 * sizeof (HOST_WIDE_INT)) #endif /* Likewise for block comparisons. */ #ifndef COMPARE_MAX_PIECES #define COMPARE_MAX_PIECES MOVE_MAX_PIECES #endif #ifndef MAX_MOVE_MAX #define MAX_MOVE_MAX MOVE_MAX #endif
[Bug fortran/71860] [7/8/9 Regression] [OOP] ICE on pointing to null(mold), verify_gimple failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71860 --- Comment #6 from Thomas Koenig --- Author: tkoenig Date: Wed Feb 6 20:34:42 2019 New Revision: 268590 URL: https://gcc.gnu.org/viewcvs?rev=268590&root=gcc&view=rev Log: 2019-02-06 Thomas Koenig PR fortran/71860 * gfortran.dg/null_10.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/null_10.f90 Modified: trunk/gcc/testsuite/ChangeLog
[Bug target/89226] codegen for copying a 512-bit object fails to use avx instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89226
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2019-02-06
CC||hjl.tools at gmail dot com,
||jakub at gcc dot gnu.org,
||uros at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #3 from Jakub Jelinek ---
Seems most of the *by_pieces code actually uses widest_int_mode_for_size which
already handles even the wider modes as long as they have a mov
instruction. With this completely untested patch I get roughly the same code
with -mavx and better with -mavx512f, just as a drawback for some reason the
functions have frame pointer (dunno if that is caused by the OI/XImode, while
vector modes can be handled or what else). Tried memset with zero too, but
haven't tried other memsets (those could be problematic already) or
comparisons.
Thoughts on this? Not a GCC9 material though. Perhaps it should also depend
on the selected preferred vector width, so that we don't e.g. enable AVX512F if
that is undesirable from power consumption POV.
--- gcc/config/i386/i386.h.jj 2019-01-01 12:37:32.988715207 +0100
+++ gcc/config/i386/i386.h 2019-02-06 21:13:01.047765193 +0100
@@ -1886,7 +1886,9 @@ typedef struct ix86_args {
&& TARGET_SSE2 \
&& TARGET_SSE_UNALIGNED_LOAD_OPTIMAL \
&& TARGET_SSE_UNALIGNED_STORE_OPTIMAL) \
- ? GET_MODE_SIZE (TImode) : UNITS_PER_WORD)
+ ? (TARGET_AVX512F ? GET_MODE_SIZE (XImode) \
+ : TARGET_AVX ? GET_MODE_SIZE (OImode) \
+ : GET_MODE_SIZE (TImode)) : UNITS_PER_WORD)
/* If a memory-to-memory move would take MOVE_RATIO or more simple
move-instruction pairs, we will do a movmem or libcall instead.
--- gcc/expr.c.jj 2019-01-22 10:09:47.304587822 +0100
+++ gcc/expr.c 2019-02-06 21:23:18.041603623 +0100
@@ -713,14 +713,31 @@ convert_modes (machine_mode mode, machin
return temp;
}
+/* Return the widest integer mode that is narrower than SIZE bytes. */
+
+static scalar_int_mode
+widest_int_mode_for_size (unsigned int size)
+{
+ scalar_int_mode result = NARROWEST_INT_MODE;
+
+ gcc_checking_assert (size > 1);
+
+ opt_scalar_int_mode tmode;
+ FOR_EACH_MODE_IN_CLASS (tmode, MODE_INT)
+if (GET_MODE_SIZE (tmode.require ()) < size)
+ result = tmode.require ();
+
+ return result;
+}
+
/* Return the largest alignment we can use for doing a move (or store)
of MAX_PIECES. ALIGN is the largest alignment we could use. */
static unsigned int
alignment_for_piecewise_move (unsigned int max_pieces, unsigned int align)
{
- scalar_int_mode tmode
-= int_mode_for_size (max_pieces * BITS_PER_UNIT, 1).require ();
+ scalar_int_mode tmode = widest_int_mode_for_size (max_pieces + 1);
+ gcc_assert (GET_MODE_SIZE (tmode) == max_pieces);
if (align >= GET_MODE_ALIGNMENT (tmode))
align = GET_MODE_ALIGNMENT (tmode);
@@ -743,23 +760,6 @@ alignment_for_piecewise_move (unsigned i
return align;
}
-/* Return the widest integer mode that is narrower than SIZE bytes. */
-
-static scalar_int_mode
-widest_int_mode_for_size (unsigned int size)
-{
- scalar_int_mode result = NARROWEST_INT_MODE;
-
- gcc_checking_assert (size > 1);
-
- opt_scalar_int_mode tmode;
- FOR_EACH_MODE_IN_CLASS (tmode, MODE_INT)
-if (GET_MODE_SIZE (tmode.require ()) < size)
- result = tmode.require ();
-
- return result;
-}
-
/* Determine whether an operation OP on LEN bytes with alignment ALIGN can
and should be performed piecewise. */
[Bug fortran/71860] [7/8 Regression] [OOP] ICE on pointing to null(mold), verify_gimple failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71860 Thomas Koenig changed: What|Removed |Added Keywords|ice-on-invalid-code | CC||tkoenig at gcc dot gnu.org Summary|[7/8/9 Regression] [OOP]|[7/8 Regression] [OOP] ICE |ICE on pointing to |on pointing to null(mold), |null(mold), verify_gimple |verify_gimple failed |failed | --- Comment #7 from Thomas Koenig --- I do not think it is invalid. The test case also passes with current gcc-8 and gcc-7. I have committed a test case to trunk. Let's wait for a few days to see if any regressions turn up, then we can also backport the test case to the other open branches and close.
[Bug target/89226] codegen for copying a 512-bit object fails to use avx instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89226 --- Comment #4 from Jakub Jelinek --- Maybe i386.c would need its own ix86_use_by_pieces_infrastructure_p target hook if the default wouldn't do the right thing with this. Maybe we'll need to split STORE_MAX_PIECES into separately overridable CLEAR_MAX_PIECES, SET_MAX_PIECES and STORE_MAX_PIECES macros, storing 32-byte or 64-byte zeros is cheap, but for e.g. store_by_pieces that might not be the case. And see what can be done to avoid the frame pointer.
[Bug go/89199] libgo regression in implementation of CompareAndSwap functions resulting in intermittent testcase failures on ppc64le power9 after r268458
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89199 --- Comment #2 from ian at gcc dot gnu.org --- Author: ian Date: Wed Feb 6 20:46:00 2019 New Revision: 268591 URL: https://gcc.gnu.org/viewcvs?rev=268591&root=gcc&view=rev Log: PR go/89199 sync/atomic: use strong form of atomic_compare_exchange_n In the recent change to use atomic_compare_exchange_n I thought we could use the weak form, which can spuriously fail. But that is not how it is implemented in the gc library, and it is not what the rest of the library expects. Thanks to Lynn Boger for identifying the problem. Fixes https://gcc.gnu.org/PR89199 Reviewed-on: https://go-review.googlesource.com/c/161359 Modified: trunk/gcc/go/gofrontend/MERGE trunk/libgo/go/sync/atomic/atomic.c
[Bug go/89199] libgo regression in implementation of CompareAndSwap functions resulting in intermittent testcase failures on ppc64le power9 after r268458
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89199 Ian Lance Taylor changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Ian Lance Taylor --- Should be fixed, thanks for identifying the problem.
[Bug libstdc++/89164] can construct vector with non-copyable-but-trivially-copyable elements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89164 Jonathan Wakely changed: What|Removed |Added Keywords||patch Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org --- Comment #5 from Jonathan Wakely --- Patch posted to https://gcc.gnu.org/ml/gcc-patches/2019-02/msg00356.html but I don't plan to fix it for GCC 9.1 (maybe 9.2 though).
[Bug go/89227] gotools test cmd/go fails with link error "call lacks nop, can't restore toc; recompile with -fPIC"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89227 boger at gcc dot gnu.org changed: What|Removed |Added CC||seurer at gcc dot gnu.org --- Comment #2 from boger at gcc dot gnu.org --- I configured without lto and I still see the error. I don't understand why the gcc-testresults show this failure intermittently, I see it consistently in my builds. This failure is in gotools cmd/go.
[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 #5 from seurer at gcc dot gnu.org --- Note that the change was backported to gcc 8 (r268578) and the test case fails there now the same way.
[Bug target/89226] codegen for copying a 512-bit object fails to use avx instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89226
--- Comment #5 from H.J. Lu ---
(In reply to Jakub Jelinek from comment #3)
> Seems most of the *by_pieces code actually uses widest_int_mode_for_size
> which already handles even the wider modes as long as they have a mov
> instruction. With this completely untested patch I get roughly the same
> code with -mavx and better with -mavx512f, just as a drawback for some
> reason the functions have frame pointer (dunno if that is caused by the
> OI/XImode, while vector modes can be handled or what else). Tried memset
> with zero too, but haven't tried other memsets (those could be problematic
> already) or comparisons.
>
> Thoughts on this? Not a GCC9 material though. Perhaps it should also
> depend on the selected preferred vector width, so that we don't e.g. enable
> AVX512F if that is undesirable from power consumption POV.
>
> --- gcc/config/i386/i386.h.jj 2019-01-01 12:37:32.988715207 +0100
> +++ gcc/config/i386/i386.h2019-02-06 21:13:01.047765193 +0100
> @@ -1886,7 +1886,9 @@ typedef struct ix86_args {
> && TARGET_SSE2 \
> && TARGET_SSE_UNALIGNED_LOAD_OPTIMAL \
> && TARGET_SSE_UNALIGNED_STORE_OPTIMAL) \
> - ? GET_MODE_SIZE (TImode) : UNITS_PER_WORD)
> + ? (TARGET_AVX512F ? GET_MODE_SIZE (XImode) \
> + : TARGET_AVX ? GET_MODE_SIZE (OImode) \
> + : GET_MODE_SIZE (TImode)) : UNITS_PER_WORD)
We need to take prefer_vector_width_type into account.
[Bug other/78063] libbacktrace fails to handle cross CU DW_AT_abstract_origin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78063 Tom de Vries changed: What|Removed |Added CC||vries at gcc dot gnu.org --- Comment #4 from Tom de Vries --- Created attachment 45622 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45622&action=edit Tentative patch "[libbacktrace] Handle DW_FORM_ref_addr" Patch passes regular bootstrap and reg-test.
[Bug tree-optimization/86020] [8 Regression] Performance regression in Eigen geometry.cpp test starting with r248334
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86020 Bill Schmidt changed: What|Removed |Added Known to work||9.0 --- Comment #10 from Bill Schmidt --- Correct.
