[Bug rtl-optimization/78952] Combine does not convert 8-bit sign-extract to a zero-extract for QImode operations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78952
--- Comment #2 from Uroš Bizjak ---
Another testcase:
--cut here--
extern void foo (void);
extern void bar (void);
struct S1
{
char pad1;
char val;
short pad2;
};
void test (struct S1 a)
{
if (a.val)
foo ();
else
bar ();
}
--cut here--
Trying 6 -> 7:
Failed to match this instruction:
(set (reg:CCZ 17 flags)
(compare:CCZ (subreg:QI (sign_extract:SI (reg/v:SI 88 [ a ])
(const_int 8 [0x8])
(const_int 8 [0x8])) 0)
(const_int 0 [0])))
This pattern should match:
(define_insn "*cmpqi_ext_2"
[(set (reg FLAGS_REG)
(compare
(subreg:QI
(zero_extract:SI
(match_operand 0 "ext_register_operand" "Q")
(const_int 8)
(const_int 8)) 0)
(match_operand:QI 1 "const0_operand")))]
"ix86_match_ccmode (insn, CCNOmode)"
"test{b}\t%h0, %h0"
[(set_attr "type" "test")
(set_attr "length_immediate" "0")
(set_attr "mode" "QI")])
[Bug other/65530] [meta-bug] -mmpx -fcheck-pointer-bounds failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65530 Bug 65530 depends on bug 63994, which changed state. Bug 63994 Summary: Ada bootstrap fails with -fcheck-pointer-bounds -mmpx https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63994 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WORKSFORME
[Bug middle-end/63994] Ada bootstrap fails with -fcheck-pointer-bounds -mmpx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63994 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ebotcazou at gcc dot gnu.org Resolution|--- |WORKSFORME Target Milestone|--- |7.0 --- Comment #9 from Eric Botcazou --- .
[Bug target/78954] New: optimization: broadcast of non-constant scalar into SSE2 register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78954
Bug ID: 78954
Summary: optimization: broadcast of non-constant scalar into
SSE2 register
Product: gcc
Version: 6.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jens.maurer at gmx dot net
Target Milestone: ---
The following code goes through the stack instead of directly moving from the
register for "x" into (the low part of) "v":
#pragma GCC target ("sse2")
typedef unsigned int V __attribute__((vector_size(16)));
V f(int x)
{
V v = { x, x, x, x };
return v;
}
$ gcc -v -O3 -S x.cc
Target: x86_64-pc-linux-gnu
gcc version 6.3.0 (GCC)
snippet from assembly:
movl%edi, -12(%rsp)
movd-12(%rsp), %xmm1
pshufd $0, %xmm1, %xmm0
ret
Why do we move through the stack, instead of using a simple register move?
movd%edi, %xmm1
pshufd $0, %xmm1, %xmm0
[Bug target/78954] optimization: broadcast of non-constant scalar into SSE2 register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78954 --- Comment #1 from Andrew Pinski --- Try -mcpu=intel . IIRC some AMD processors perform worse when going directly from the gprs here.
[Bug target/78954] optimization: broadcast of non-constant scalar into SSE2 register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78954 --- Comment #2 from Jakub Jelinek --- That depends on which CPU you tune for. E.g. with -mtune=intel or -mtune=core2 etc. you get what you are asking for, -mtune=generic takes into account that the movd%edi, %xmm1 insn is very slow on some AMD CPUs and because moving through stack isn't that slower on Intel CPUs, it is a compromise between those tunings. /* X86_TUNE_INTER_UNIT_MOVES_TO_VEC: Enable moves in from integer to SSE registers. If disabled, the moves will be done by storing the value to memory and reloading. */ DEF_TUNE (X86_TUNE_INTER_UNIT_MOVES_TO_VEC, "inter_unit_moves_to_vec", ~(m_AMD_MULTIPLE | m_GENERIC)) /* X86_TUNE_INTER_UNIT_MOVES_TO_VEC: Enable moves in from SSE to integer registers. If disabled, the moves will be done by storing the value to memory and reloading. */ DEF_TUNE (X86_TUNE_INTER_UNIT_MOVES_FROM_VEC, "inter_unit_moves_from_vec", ~m_ATHLON_K8) where #define m_AMD_MULTIPLE (m_ATHLON_K8 | m_AMDFAM10 | m_BDVER | m_BTVER \ | m_ZNVER1)
[Bug target/78954] optimization: broadcast of non-constant scalar into SSE2 register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78954 --- Comment #3 from Jens Maurer --- Ok, thanks. So, this essentially says most/all AMD CPUs have bad general-reg -> xmm move performance. Oh well. Please close.
[Bug target/78954] optimization: broadcast of non-constant scalar into SSE2 register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78954 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |INVALID --- Comment #4 from Jakub Jelinek --- .
[Bug fortran/71880] pointer to allocatable character
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71880 --- Comment #3 from Dominique d'Humieres --- When compiled with '-m64 -fsanitize=address' the test give at run time = ==81688==ERROR: AddressSanitizer: negative-size-param: (size=-1) #0 0x10f4d9b3b in wrap_memmove (/opt/gcc/gcc7a/lib/libasan.4.dylib+0x41b3b) #1 0x10f3e0032 in list_formatted_write_scalar (/opt/gcc/gcc7a/lib/libgfortran.4.dylib+0x142032) 0x60200150 is located 0 bytes inside of 10-byte region [0x60200150,0x6020015a) allocated by thread T0 here: #0 0x10f4fa96d in wrap_malloc (/opt/gcc/gcc7a/lib/libasan.4.dylib+0x6296d) #1 0x10f29b10d in MAIN__ (/Users/dominiq/Documents/Fortran/g95bench/win/f90/bug/a.out+0x1110d) #2 0x10f29b956 in main (/Users/dominiq/Documents/Fortran/g95bench/win/f90/bug/a.out+0x11956) #3 0x7fff94598254 in start (/usr/lib/system/libdyld.dylib+0x5254) SUMMARY: AddressSanitizer: negative-size-param (/opt/gcc/gcc7a/lib/libasan.4.dylib+0x41b3b) in wrap_memmove ==81688==ABORTING Program received signal SIGABRT: Process abort signal. Backtrace for this error: #0 0x10f2a0979 #1 0x10f29fd13 #2 0x7fff947a5bb9 Abort When compiled with '-m32 -fsanitize=address' they give ASAN:DEADLYSIGNAL = ==75073==ERROR: AddressSanitizer: SEGV on unknown address 0x2400 (pc 0x00357260 bp 0x0002 sp 0xbfffba20 T0) #0 0x35725f in __sanitizer::mem_is_zero(char const*, unsigned long) (/opt/gcc/gcc7a/lib/i386/libasan.4.dylib+0x8425f) AddressSanitizer can not provide additional info. SUMMARY: AddressSanitizer: SEGV (/opt/gcc/gcc7a/lib/i386/libasan.4.dylib+0x8425f) in __sanitizer::mem_is_zero(char const*, unsigned long) ==75073==ABORTING Program received signal SIGABRT: Process abort signal. Backtrace for this error: #0 0xf124f #1 0xf05be #2 0x9f98beba Abort
[Bug translation/78745] Truncated messages in po file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78745 --- Comment #8 from Jakub Jelinek --- Author: jakub Date: Fri Dec 30 19:15:42 2016 New Revision: 243981 URL: https://gcc.gnu.org/viewcvs?rev=243981&root=gcc&view=rev Log: PR translation/78745 * exgettext: Handle multi-line help texts in *.opt files. * gcc.pot: Regenerate. Modified: trunk/gcc/po/ChangeLog trunk/gcc/po/exgettext trunk/gcc/po/gcc.pot
[Bug translation/78745] Truncated messages in po file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78745 --- Comment #9 from Jakub Jelinek --- Author: jakub Date: Fri Dec 30 19:18:25 2016 New Revision: 243982 URL: https://gcc.gnu.org/viewcvs?rev=243982&root=gcc&view=rev Log: PR translation/78745 * exgettext: Handle multi-line help texts in *.opt files. * gcc.pot: Regenerate. Modified: branches/gcc-6-branch/gcc/po/ChangeLog branches/gcc-6-branch/gcc/po/exgettext branches/gcc-6-branch/gcc/po/gcc.pot
[Bug translation/78745] Truncated messages in po file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78745 --- Comment #10 from Jakub Jelinek --- Author: jakub Date: Fri Dec 30 19:21:22 2016 New Revision: 243983 URL: https://gcc.gnu.org/viewcvs?rev=243983&root=gcc&view=rev Log: PR translation/78745 * exgettext: Handle multi-line help texts in *.opt files. * gcc.pot: Regenerate. Modified: branches/gcc-5-branch/gcc/po/ChangeLog branches/gcc-5-branch/gcc/po/exgettext branches/gcc-5-branch/gcc/po/gcc.pot
[Bug translation/78745] Truncated messages in po file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78745 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC||jsm28 at gcc dot gnu.org Resolution|--- |FIXED --- Comment #11 from Jakub Jelinek --- Fixed on the trunk and release branches, gcc.pot regenerated, but I haven't submitted it to the translation project, will defer that to Joseph.
[Bug target/78900] ICE in gcc.target/powerpc/signbit-3.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78900 Michael Meissner changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2016-12-30 Ever confirmed|0 |1
[Bug target/78900] ICE in gcc.target/powerpc/signbit-3.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78900 --- Comment #1 from Michael Meissner --- Created attachment 40432 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40432&action=edit Proposed patch to fix the problem
[Bug fortran/71880] pointer to allocatable character
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71880 Harald Anlauf changed: What|Removed |Added CC||anlauf at gmx dot de --- Comment #4 from Harald Anlauf --- For a minor variant with NULLified p I get an ICE with trunk: program t character(:), dimension(:), allocatable, target :: c character(:), dimension(:), pointer :: p => NULL() allocate(c(10),source='X') p=>c end program t % gfc-trunk -c pr71880.f90 pr71880.f90:1:0: program t internal compiler error: in gfc_get_symbol_decl, at fortran/trans-decl.c:1738 0x838f263 gfc_get_symbol_decl(gfc_symbol*) ../../trunk/gcc/fortran/trans-decl.c:1738 0x838f9b7 generate_local_decl ../../trunk/gcc/fortran/trans-decl.c:5356 0x8341e23 do_traverse_symtree ../../trunk/gcc/fortran/symbol.c:3986 0x83934c8 generate_local_vars ../../trunk/gcc/fortran/trans-decl.c:5556 0x83934c8 gfc_generate_function_code(gfc_namespace*) ../../trunk/gcc/fortran/trans-decl.c:6220 0x8312713 translate_all_program_units ../../trunk/gcc/fortran/parse.c:6008 0x8312713 gfc_parse_file() ../../trunk/gcc/fortran/parse.c:6208 0x8357ea5 gfc_be_parse_file ../../trunk/gcc/fortran/f95-lang.c:202
[Bug libstdc++/77528] std::queue default constructor unnecessarily creates temporary of underlying Container
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77528
jerryct changed:
What|Removed |Added
CC||jerry.c.t at web dot de
--- Comment #4 from jerryct ---
Hi,
i would like to add another issue besides the number of allocations. I am using
special containers which have fixed size and don't use dynamic memory
allocation at all. Thus for example we use a static_vector. The
container can get rather big, e.g., 4 mega byte. Using std::stack from
libstdc++ with this container produces a stack overflow in the constructor,
because of this temporary. Running the same code with libcxx does not produce
this error - it does not use such a temporary in the constructor.
Thus a constructor like libcxx has:
_LIBCPP_INLINE_VISIBILITY
stack()
_NOEXCEPT_(is_nothrow_default_constructible::value)
: c() {}
would solve two problems:
- reduce the number of allocations
- make container adapaters usable for rather big containers.
jerry
[Bug c++/78955] New: [c++ concepts] Concept requirements on functions cancels the private section method check in the following code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78955 Bug ID: 78955 Summary: [c++ concepts] Concept requirements on functions cancels the private section method check in the following code Product: gcc Version: c++-concepts Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: sergstrukovlink at gmail dot com CC: webrown.cpp at gmail dot com Target Milestone: --- CC: webrown.cpp at gmail dot com See the attached code example. Checked on https://gcc.godbolt.org with gcc-6.2.0 , gcc-6.3.0 anf gcc-7.0.0. Options: -std=c++1z -fconcepts .
[Bug libobjc/78698] [7 regression] Using static PIC libgc fails when it has dependencies
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78698 --- Comment #4 from Matthias Klose --- patch posted at https://gcc.gnu.org/ml/gcc-patches/2016-12/msg02004.html
[Bug libobjc/78697] --with-target-bdw-gc-include shouldn't be required to be per multilib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78697 --- Comment #2 from Matthias Klose --- patch posted at https://gcc.gnu.org/ml/gcc-patches/2016-12/msg02003.html
