[Bug c++/60893] New: Unable to use link time optimizer with profiler
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60893
Bug ID: 60893
Summary: Unable to use link time optimizer with profiler
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dturnbull at gmail dot com
The following works with gcc-4.8.2.
It fails with gcc-4.9.0-RC-20140411.
Using this simple main.cpp:
#include
#include
#include
int main() {
std::vector > data(10);
std::cout << "Hello World.\n";
}
Attempt to compile and run as such:
rm main.gcda
g++-4.9 -o profiler main.cpp -flto -O3 -fprofile-generate
./profiler
g++-4.9 -o helloworld main.cpp -flto -O3 -fprofile-use
./helloworld
The linker error output is:
Assertion failed: (cfiStartsArray[i] != cfiStartsArray[i-1]), function parse,
file /SourceCache/ld64/ld64-236.4/src/ld/parsers/macho_relocatable_file.cpp,
line 1685.
0 0x10227e0e7 __assert_rtn + 144
1 0x1022a3759
mach_o::relocatable::Parser::parse(mach_o::relocatable::ParserOptions
const&) + 3213
2 0x1022889e2 mach_o::relocatable::Parser::parse(unsigned char
const*, unsigned long long, char const*, long, ld::File::Ordinal,
mach_o::relocatable::ParserOptions const&) + 374
3 0x1022c8303 ld::tool::InputFiles::makeFile(Options::FileInfo const&, bool)
+ 651
4 0x1022c9ff9 ld::tool::InputFiles::parseWorkerThread() + 271
5 0x7fff84598899 _pthread_body + 138
6 0x7fff8459872a _pthread_struct_init + 0
[Bug c++/60872] Cannot memcpy array of restricted pointers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60872 Jason Merrill changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-04-19 CC||jason at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #3 from Jason Merrill --- Fixed on trunk so far.
[Bug sanitizer/60892] New: GCC fails to build with Linux 2.6.21 headers.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60892 Bug ID: 60892 Summary: GCC fails to build with Linux 2.6.21 headers. Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: toojays at toojays dot net CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at gcc dot gnu.org I got the following errors while trying to build gcc-4.9 (from the 20140416 snapshot) for a Linux 2.6.21 system (Maemo 4 / diablo). Configuration was run via ../gcc-4.9-20140416/configure --program-suffix=-4.9 --disable-shared --enable-languages=c,c++ --enable-checking=release I got not complaints from the, but the build failed at: xgcc -B/home/maemo/gcc-4.9-20140416/build-dir/./gcc/ -B/usr/i686-pc-linux-gnu/bin/ -B/usr/i686-pc-linux-gnu/lib/ -isystem /usr/i686-pc-linux-gnu/include -isystem /usr/i686-pc-linux-gnu/sys-include -DHAVE_CONFIG_H -I. -I../../../gcc-4.9-20140416/libquadmath -I ../../../gcc-4.9-20140416/libquadmath/../include -g -O2 -MT math/catanq.lo -MD -MP -MF $depbase.Tpo -c -o math/catanq.lo ../../../gcc-4.9-20140416/libquadmath/math/catanq.c &&\ mv -f $depbase.Tpo $depbase.Plo ../../../../gcc-4.9-20140416/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc:390:30: error: 'EVIOCGREP' was not declared in this scope unsigned IOCTL_EVIOCGREP = EVIOCGREP; ^ ../../../../gcc-4.9-20140416/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc:399:30: error: 'EVIOCSREP' was not declared in this scope unsigned IOCTL_EVIOCSREP = EVIOCSREP; ^ ../../../../gcc-4.9-20140416/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc:682:36: error: 'FS_IOC_GETFLAGS' was not declared in this scope unsigned IOCTL_FS_IOC_GETFLAGS = FS_IOC_GETFLAGS; ^ ../../../../gcc-4.9-20140416/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc:683:38: error: 'FS_IOC_GETVERSION' was not declared in this scope unsigned IOCTL_FS_IOC_GETVERSION = FS_IOC_GETVERSION; ^ ../../../../gcc-4.9-20140416/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc:684:36: error: 'FS_IOC_SETFLAGS' was not declared in this scope unsigned IOCTL_FS_IOC_SETFLAGS = FS_IOC_SETFLAGS; ^ ../../../../gcc-4.9-20140416/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc:685:38: error: 'FS_IOC_SETVERSION' was not declared in this scope unsigned IOCTL_FS_IOC_SETVERSION = FS_IOC_SETVERSION; http://gcc.gnu.org/install/specific.html does not mention a minimum kernel version for GCC. http://gcc.gnu.org/install/configure.html does not explain how to disable building the sanitizer. I don't particularly mind if I can't have the sanitizer, but expect the GCC configure script to detect that, and disable the sanitizer build automatically. This bug is similar in spirit to bug 59068, but I'm filing a separate issue since the root cause is different.
[Bug c/21664] array-of-empty-structure extension not properly defined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21664 Marek Polacek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Marek Polacek --- ...so marking as "fixed".
[Bug c/50773] float values are printed with greater precision than the float data type has when given as an argument to printf()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50773 Marek Polacek changed: What|Removed |Added Status|REOPENED|RESOLVED CC||mpolacek at gcc dot gnu.org Resolution|--- |INVALID --- Comment #5 from Marek Polacek --- Closing as not a bug then.
[Bug bootstrap/60830] [4.9 Regression] ICE on bootstrapping on cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830 --- Comment #27 from Bernd Edlinger --- (In reply to Denis Excoffier from comment #26) > After more investigation, it seems that the culprit can be > --disable-sjlj-exceptions. Since the beginning (last Sunday), each time i > use it on the command line, the build fails and each time i don't use it, > the build succeeds. > Please would you mind trying again a cygwin build, but > with --disable-sjlj-exceptions this time. Especially for those where the > build succeeded. For Mikael (see comment #2), it is more than probable that > he used --disable-sjlj-exceptions instead of my gmp kludges known by nobody > except by me. Yes, adding --disable-sjlj-exceptions makes the build fail: mkdir -p -- i686-pc-cygwin/libgcc Checking multilib configuration for libgcc... Configuring stage 2 in i686-pc-cygwin/libgcc configure: creating cache ./config.cache checking build system type... i686-pc-cygwin checking host system type... i686-pc-cygwin checking for --enable-version-specific-runtime-libs... no checking for a BSD-compatible install... /usr/bin/install -c checking for gawk... gawk xgcc: error: unrecognized command line option '-isystem' xgcc: error: unrecognized command line option '-isystem' xgcc: error: unrecognized command line option '-mtune=generic' xgcc: error: unrecognized command line option '-march=pentiumpro' checking for i686-pc-cygwin-ar... ar checking for i686-pc-cygwin-lipo... lipo checking for i686-pc-cygwin-nm... /home/ED/gnu/gcc-build/./gcc/nm checking for i686-pc-cygwin-ranlib... ranlib checking for i686-pc-cygwin-strip... strip checking whether ln -s works... yes checking for i686-pc-cygwin-gcc... /home/ED/gnu/gcc-build/./gcc/xgcc -B/home/ED/gnu/gcc-build/./gcc/ -B/home/ed/gnu/install/i686-pc-cygwin/bin/ -B/home/ed/gnu/install/i686-pc-cygwin/lib/ -isystem /home/ed/gnu/install/i686-pc-cygwin/include -isystem /home/ed/gnu/install/i686-pc-cygwin/sys-include checking for C compiler default output file name... configure: error: in `/home/ED/gnu/gcc-build/i686-pc-cygwin/libgcc': configure: error: C compiler cannot create executables See `config.log' for more details. Makefile:17788: recipe for target 'configure-stage2-target-libgcc' failed make[2]: *** [configure-stage2-target-libgcc] Error 77 make[2]: Leaving directory '/home/ED/gnu/gcc-build' Makefile:20606: recipe for target 'stage2-bubble' failed make[1]: *** [stage2-bubble] Error 2 make[1]: Leaving directory '/home/ED/gnu/gcc-build' Makefile:897: recipe for target 'all' failed make: *** [all] Error 2
[Bug tree-optimization/60891] New: [4.9/4.10 Regression] ICE: SIGSEGV (Invalid write/read) in pre_and_rev_post_order_compute_fn with -O -fno-tree-ch -fno-tree-cselim -fno-tree-dominator-opts
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60891 Bug ID: 60891 Summary: [4.9/4.10 Regression] ICE: SIGSEGV (Invalid write/read) in pre_and_rev_post_order_compute_fn with -O -fno-tree-ch -fno-tree-cselim -fno-tree-dominator-opts Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Created attachment 32633 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32633&action=edit reduced testcase Compiler output (under valgrind): $ gcc -O -fno-tree-ch -fno-tree-cselim -fno-tree-dominator-opts testcase.c ==2497== Invalid write of size 4 ==2497==at 0x7464DF: pre_and_rev_post_order_compute_fn(function*, int*, int*, bool) (cfganal.c:981) ==2497==by 0x7465F7: pre_and_rev_post_order_compute(int*, int*, bool) (cfganal.c:1014) ==2497==by 0xC9FBE7: (anonymous namespace)::pass_reassoc::execute() (tree-ssa-reassoc.c:4632) ==2497==by 0xA49D49: execute_one_pass(opt_pass*) (passes.c:2229) ==2497==by 0xA49FE5: execute_pass_list(opt_pass*) (passes.c:2282) ==2497==by 0xA49FF7: execute_pass_list(opt_pass*) (passes.c:2283) ==2497==by 0x786448: expand_function(cgraph_node*) (cgraphunit.c:1774) ==2497==by 0x78842B: compile() (cgraphunit.c:1908) ==2497==by 0x788B94: finalize_compilation_unit() (cgraphunit.c:2329) ==2497==by 0x63C8B3: c_write_global_declarations() (c-decl.c:10401) ==2497==by 0xB3E69C: compile_file() (toplev.c:562) ==2497==by 0xB4066F: toplev_main(int, char**) (toplev.c:1914) ==2497==by 0x5A46BF4: (below main) (in /lib64/libc-2.17.so) ==2497== Address 0x610ecb8 is 0 bytes after a block of size 40 alloc'd ==2497==at 0x4C2C820: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==2497==by 0x143DA37: xmalloc (xmalloc.c:147) ==2497==by 0xC9FB88: (anonymous namespace)::pass_reassoc::execute() (tree-ssa-reassoc.c:4618) ==2497==by 0xA49D49: execute_one_pass(opt_pass*) (passes.c:2229) ==2497==by 0xA49FE5: execute_pass_list(opt_pass*) (passes.c:2282) ==2497==by 0xA49FF7: execute_pass_list(opt_pass*) (passes.c:2283) ==2497==by 0x786448: expand_function(cgraph_node*) (cgraphunit.c:1774) ==2497==by 0x78842B: compile() (cgraphunit.c:1908) ==2497==by 0x788B94: finalize_compilation_unit() (cgraphunit.c:2329) ==2497==by 0x63C8B3: c_write_global_declarations() (c-decl.c:10401) ==2497==by 0xB3E69C: compile_file() (toplev.c:562) ==2497==by 0xB4066F: toplev_main(int, char**) (toplev.c:1914) ==2497==by 0x5A46BF4: (below main) (in /lib64/libc-2.17.so) ==2497== ==2497== Invalid read of size 4 ==2497==at 0xC9FCE6: (anonymous namespace)::pass_reassoc::execute() (tree-ssa-reassoc.c:4648) ==2497==by 0xA49D49: execute_one_pass(opt_pass*) (passes.c:2229) ==2497==by 0xA49FE5: execute_pass_list(opt_pass*) (passes.c:2282) ==2497==by 0xA49FF7: execute_pass_list(opt_pass*) (passes.c:2283) ==2497==by 0x786448: expand_function(cgraph_node*) (cgraphunit.c:1774) ==2497==by 0x78842B: compile() (cgraphunit.c:1908) ==2497==by 0x788B94: finalize_compilation_unit() (cgraphunit.c:2329) ==2497==by 0x63C8B3: c_write_global_declarations() (c-decl.c:10401) ==2497==by 0xB3E69C: compile_file() (toplev.c:562) ==2497==by 0xB4066F: toplev_main(int, char**) (toplev.c:1914) ==2497==by 0x5A46BF4: (below main) (in /lib64/libc-2.17.so) ==2497== Address 0x610ecb8 is 0 bytes after a block of size 40 alloc'd ==2497==at 0x4C2C820: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==2497==by 0x143DA37: xmalloc (xmalloc.c:147) ==2497==by 0xC9FB88: (anonymous namespace)::pass_reassoc::execute() (tree-ssa-reassoc.c:4618) ==2497==by 0xA49D49: execute_one_pass(opt_pass*) (passes.c:2229) ==2497==by 0xA49FE5: execute_pass_list(opt_pass*) (passes.c:2282) ==2497==by 0xA49FF7: execute_pass_list(opt_pass*) (passes.c:2283) ==2497==by 0x786448: expand_function(cgraph_node*) (cgraphunit.c:1774) ==2497==by 0x78842B: compile() (cgraphunit.c:1908) ==2497==by 0x788B94: finalize_compilation_unit() (cgraphunit.c:2329) ==2497==by 0x63C8B3: c_write_global_declarations() (c-decl.c:10401) ==2497==by 0xB3E69C: compile_file() (toplev.c:562) ==2497==by 0xB4066F: toplev_main(int, char**) (toplev.c:1914) ==2497==by 0x5A46BF4: (below main) (in /lib64/libc-2.17.so) ==2497==
[Bug tree-optimization/60890] Performance regression in 4.8 for memory postinc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60890 --- Comment #1 from Andrew Pinski --- This just sounds like IV-opts going wrong.
[Bug tree-optimization/60890] New: Performance regression in 4.8 for memory postinc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60890 Bug ID: 60890 Summary: Performance regression in 4.8 for memory postinc Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: hariharan.gcc at gmail dot com Created attachment 32632 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32632&action=edit The source testcase The attached testcase is a simplified version of the code where i saw this problem initially. At the end of tree stages, 4.7 compiler used to generate two consecutive stores, and then add to update the pointer as shown below for the stores in the innermost loop. MEM[base: aptr_54, offset: 0B] = res1_22; MEM[base: aptr_54, offset: 4B] = res2_27; D.1771_63 = (sizetype) aptr_54; D.1772_64 = D.1771_63 + 8; 4.8 compiler generates MEM[base: base_76, offset: 0B] = res1_32; _29 = (unsigned long) base_76; _83 = _29 + 8; base_84 = (int *) _83; MEM[base: base_84, offset: -4B] = res2_37; for the same 2 stores. In our private port, which can do post-inc on load/store operations, 4.7 used to generate optimal code whereas 4.8 code is not very pretty. The problem seems to stem from the fix made to Bug 48814, which generates post-inc operations in a different order from 4.7. Should the tree optimization passes have fixed it up? At the end of tree-optimization passes, i can see the problem in x86 as well. Compile the attached code with 4.7.x and 4.8.x to see the difference.
[Bug c++/60872] Cannot memcpy array of restricted pointers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60872 --- Comment #2 from Jason Merrill --- Author: jason Date: Fri Apr 18 18:11:22 2014 New Revision: 209520 URL: http://gcc.gnu.org/viewcvs?rev=209520&root=gcc&view=rev Log: PR c++/60872 * call.c (standard_conversion): Don't try to apply restrict to void. Added: trunk/gcc/testsuite/g++.dg/ext/restrict2.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c
[Bug c/25801] bad diagnostic for increment/decrement of pointer to incomplete array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25801 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED CC||mpolacek at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org --- Comment #2 from Marek Polacek --- I'm testing a patch.
[Bug middle-end/60889] New: -Os generate much bigger code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60889
Bug ID: 60889
Summary: -Os generate much bigger code
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
CC: mjambor at suse dot cz
On Linux/x86-64:
[hjl@gnu-6 gcc]$ cat /tmp/space.i
typedef float __v4sf __attribute__ ((__vector_size__ (16)));
typedef float __m128 __attribute__ ((__vector_size__ (16), __may_alias__));
struct S
{
__m128 a, b;
};
struct T
{
int a;
struct S s;
};
void foo (struct T *p, __m128 v)
{
struct S s;
s = p->s;
s.b = (__m128) __builtin_ia32_addps ((__v4sf)s.b, (__v4sf)v);
p->s = s;
}
[hjl@gnu-6 gcc]$ ./xgcc -B./ -S -O2 /tmp/space.i
[hjl@gnu-6 gcc]$ cat space.s
.file"space.i"
.section.text.unlikely,"ax",@progbits
.LCOLDB0:
.text
.LHOTB0:
.p2align 4,,15
.globlfoo
.typefoo, @function
foo:
.LFB0:
.cfi_startproc
addps32(%rdi), %xmm0
movaps%xmm0, 32(%rdi)
ret
.cfi_endproc
.LFE0:
.sizefoo, .-foo
.section.text.unlikely
.LCOLDE0:
.text
.LHOTE0:
.ident"GCC: (GNU) 4.9.0 20140409 (experimental)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-6 gcc]$ ./xgcc -B./ -S -Os /tmp/space.i
[hjl@gnu-6 gcc]$ cat space.s
.file"space.i"
.section.text.unlikely,"ax",@progbits
.LCOLDB0:
.text
.LHOTB0:
.globlfoo
.typefoo, @function
foo:
.LFB0:
.cfi_startproc
movq%rdi, %rax
movl$8, %ecx
leaq-40(%rsp), %rdi
leaq16(%rax), %rsi
rep movsl
addps32(%rax), %xmm0
leaq16(%rax), %rdi
leaq-40(%rsp), %rsi
movb$8, %cl
movaps%xmm0, -24(%rsp)
rep movsl
ret
.cfi_endproc
.LFE0:
.sizefoo, .-foo
.section.text.unlikely
.LCOLDE0:
.text
.LHOTE0:
.ident"GCC: (GNU) 4.9.0 20140409 (experimental)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-6 gcc]$
analyze_all_variable_accesses in tree-sra.c has
max_total_scalarization_size = UNITS_PER_WORD * BITS_PER_UNIT
* MOVE_RATIO (optimize_function_for_speed_p (cfun));
-Os sets MOVE_RATIO to 3. Should we have a different parameter
to control SRA?
[Bug libstdc++/42857] std::istream::ignore(std::streamsize n) calls unnecessary underflow
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42857 Sergey Zubkov changed: What|Removed |Added CC||cubbi at cubbi dot org --- Comment #5 from Sergey Zubkov --- Looking at existing implementations, libstdc++ is the odd one out: LLVM libc++, IBM XL C++, Microsoft Visual Studio, and Oracle libCstd and stlport4 all let me ignore exactly the number of characters requested, without an extra read from the socket.
[Bug target/60879] Wrong decision in decide_alg in i386.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60879
--- Comment #2 from H.J. Lu ---
(In reply to Jakub Jelinek from comment #1)
> Does this ever matter though? I mean, wouldn't we expand it as move by
> pieces or store by pieces for such small constant length anyway and thus
> never reach the target movmem/setmem expansion?
move by pieces or store by pieces are very efficient for
targets with unaligned move/store for integer and vector:
[hjl@gnu-6 partial]$ cat w.i
void
foo5 (const void *src, void *dest, int s)
{
__builtin_memcpy (dest, src, 23);
}
[hjl@gnu-6 partial]$ gcc -S -O2 w.i
[hjl@gnu-6 partial]$ cat w.s
.file"w.i"
.text
.p2align 4,,15
.globlfoo5
.typefoo5, @function
foo5:
.LFB0:
.cfi_startproc
movq(%rdi), %rax
movq%rax, (%rsi)
movq8(%rdi), %rax
movq%rax, 8(%rsi)
movl16(%rdi), %eax
movl%eax, 16(%rsi)
movzwl20(%rdi), %eax
movw%ax, 20(%rsi)
movzbl22(%rdi), %eax
movb%al, 22(%rsi)
ret
I am working on a different set/mov memory strategy to generate
movdqu(%rdi), %xmm0
movups%xmm0, (%rsi)
movq15(%rdi), %rax
movq%rax, 15(%rsi)
ret
by setting MOVE_RATIO to 1 and handling most of set/mov memory in
x86 backend.
[Bug debug/60885] typeless DW_TAG_typedef
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60885 --- Comment #2 from Mark Wielaard --- I think this is caused by the following in add_type_attribute: if (code == ERROR_MARK /* Handle a special case. For functions whose return type is void, we generate *no* type attribute. (Note that no object may have type `void', so this only applies to function return types). */ || code == VOID_TYPE) return;
[Bug tree-optimization/60888] New: x86 vector widen multiplication by constant is not replaced with shift and sub
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60888
Bug ID: 60888
Summary: x86 vector widen multiplication by constant is not
replaced with shift and sub
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: evstupac at gmail dot com
Created attachment 32631
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32631&action=edit
test case
For the following test case:
void
foo(char *out, char *in)
{
int i;
for(i = 0; i < 1024; i++)
out[i] = (in[i] * 32767) >> 15;
}
compiled with:
-O3 -m32 -msse2 -S -fdump-tree-vect-details
Generates the following code at 114t.vect:
vect_cst_.16_106 = { 32767, 32767, 32767, 32767, 32767, 32767, 32767, 32767
};
...
vect_patt_24.15_107 = WIDEN_MULT_LO_EXPR ;
vect_patt_24.15_108 = WIDEN_MULT_HI_EXPR ;
vect_patt_24.15_109 = WIDEN_MULT_LO_EXPR ;
vect_patt_24.15_110 = WIDEN_MULT_HI_EXPR ;
These 4 multiplications stay till final assembler:
...
punpcklbw %xmm0, %xmm2
punpckhbw %xmm0, %xmm5
pmullw %xmm2, %xmm1
movdqa %xmm1, %xmm0
pmulhw %xmm3, %xmm2
...
However:
out[i] = ((in[i] << 15) - in[i]) >> 15;
is faster and calculating the same.
[Bug bootstrap/60887] [4.10 Regression] LTO bootstrap failed with profiledbootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60887 --- Comment #1 from H.J. Lu --- I got /export/project/git/gcc-regression-bootstrap/master/209484/bld/./prev-gcc/xg++ -B/export/project/git/gcc-regression-bootstrap/master/209484/bld/./prev-gcc/ -B/usr/local/x86_64-unknown-linux-gnu/bin/ -nostdinc++ -B/export/project/git/gcc-regression-bootstrap/master/209484/bld/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -B/export/project/git/gcc-regression-bootstrap/master/209484/bld/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -I/export/project/git/gcc-regression-bootstrap/master/209484/bld/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu -I/export/project/git/gcc-regression-bootstrap/master/209484/bld/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include -I/export/project/git/gcc-regression/gcc/libstdc++-v3/libsupc++ -L/export/project/git/gcc-regression-bootstrap/master/209484/bld/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -L/export/project/git/gcc-regression-bootstrap/master/209484/bld/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -g -O2 -flto=jobserver -frandom-seed=1 -ffat-lto-objects -fprofile-use -DIN_GCC-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -static-libstdc++ -static-libgcc -o lto1 \ lto/lto-lang.o lto/lto.o lto/lto-object.o attribs.o lto/lto-partition.o lto/lto-symtab.o libbackend.a main.o tree-browser.o libcommon-target.a libcommon.a ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a -lmpc -lmpfr -lgmp -rdynamic -ldl -lz libcommon.a ../libcpp/libcpp.a ../libbacktrace/.libs/libbacktrace.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a /tmp/ccR2WYVX.ltrans4.ltrans.o:(.debug_info+0x988e2): undefined reference to `.L958' collect2: error: ld returned 1 exit status make[3]: *** [lto1] Error 1
[Bug bootstrap/60887] New: [4.10 Regression] LTO bootstrap failed with profiledbootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60887 Bug ID: 60887 Summary: [4.10 Regression] LTO bootstrap failed with profiledbootstrap Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: hjl.tools at gmail dot com CC: jakub at gcc dot gnu.org On Linux/x86-64, r209484 caused LTO bootstrap failed with bootstrap-profiled. GCC is configured with --prefix=/usr/local --enable-clocale=gnu --with-system-zlib --with-demangler-in-ld MAKEINFO=/usr/bin/false --enable-languages=c,c++ --enable-bootstrap --with-build-config=bootstrap-lto --disable-werror and built with profiledbootstrap.
[Bug debug/60885] typeless DW_TAG_typedef
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60885 Mark Wielaard changed: What|Removed |Added CC||mark at gcc dot gnu.org --- Comment #1 from Mark Wielaard --- The DWARFv4 specification section 5.2 Unspecified Type Entries says "Some languages have constructs in which a type may be left unspecified or the absence of a type may be explicitly indicated. An unspecified (implicit, unknown, ambiguous or nonexistent) type is represented by a debugging information entry with the tag DW_TAG_unspecified_type. [...] For example, in C and C++ the language implementation can provide an unspecified type entry with the name “void” which can be referenced by the type attribute of pointer types and typedef declarations for 'void'"
[Bug c++/60886] poor parse error recovery for missing parenthesis in mem-initializer-list
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60886 Jonathan Wakely changed: What|Removed |Added Keywords||error-recovery Status|UNCONFIRMED |NEW Last reconfirmed||2014-04-18 Summary|poor parse error recovery |poor parse error recovery |for missing parenthesis in |for missing parenthesis in |initializer-list|mem-initializer-list Ever confirmed|0 |1
[Bug c++/60886] New: poor parse error recovery for missing parenthesis in initializer-list
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60886
Bug ID: 60886
Summary: poor parse error recovery for missing parenthesis in
initializer-list
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: manu at gcc dot gnu.org
class A {
A(int _a, int _b) : a(_a, b(_b) {}
int a, b;
}
manuel@gcc10:~$ clang++ bug.C
bug.C:4:12: error: expected ')'
int a,b;
^
bug.C:2:24: note: to match this '('
A(int _a, int _b) : a(_a, b(_b) {}
^
1 error generated.
manuel@gcc10:~$ ~/test1/208648/build/gcc/cc1plus bug.C
A::A(int, int)
bug.C:2:23: error: class ‘A’ does not have any field named ‘a’
A(int _a, int _b) : a(_a, b(_b) {}
^
bug.C:2:33: error: ‘b’ was not declared in this scope
A(int _a, int _b) : a(_a, b(_b) {}
^
bug.C:4:11: error: expected ‘)’ at end of input
int a,b;
^
bug.C:4:11: error: expected ‘{’ at end of input
[Bug target/60539] [SH] builtin string functions ignore loop and label alignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60539 --- Comment #3 from Oleg Endo --- As mentioned here http://gcc.gnu.org/ml/gcc-patches/2014-03/msg01692.html: > IMHO the problem is with the > non-aligned loop stems from to the generic alignment code in final.c. > Further tuning of static branch estimations, or tuning of the LOOP_ALIGN > macro is needed. This PR is about the fact that loops expanded by builtins don't get the loop labels aligned automatically. It just happens that on SH we have only the strlen-like builtins so far that expand loops.
[Bug bootstrap/60830] [4.9 Regression] ICE on bootstrapping on cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830 --- Comment #26 from Denis Excoffier --- After more investigation, it seems that the culprit can be --disable-sjlj-exceptions. Since the beginning (last Sunday), each time i use it on the command line, the build fails and each time i don't use it, the build succeeds. Please would you mind trying again a cygwin build, but with --disable-sjlj-exceptions this time. Especially for those where the build succeeded. For Mikael (see comment #2), it is more than probable that he used --disable-sjlj-exceptions instead of my gmp kludges known by nobody except by me.
[Bug debug/60885] New: typeless DW_TAG_typedef
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60885
Bug ID: 60885
Summary: typeless DW_TAG_typedef
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: pmachata at redhat dot com
GCC emits DW_TAG_typedef without DW_AT_type when the typedef'd type is void:
typedef void VOID;
int foo (VOID *v) {}
$ gcc void.c -g -c
[2d]typedef
name (strp) "VOID"
decl_file(data1) 1
decl_line(data1) 1
DWARF4 states:
"""If the debugging information entry for a typedef represents a
declaration of the type that is not also a definition, it does not contain a
type attribute."""
As I understand things, a typedef defines a new type, and as such should
contain a DW_AT_type even though it's void.
[Bug libstdc++/60883] std::ostringstream::str(const std::string&) works strangely
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60883 Michal Strnad changed: What|Removed |Added CC||michal at mistrnet dot cz --- Comment #2 from Michal Strnad --- Comment on attachment 32630 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32630 Demonstrate ostringstream::str(const string&) side effect std::ostringstream o(std::ios_base::out | std::ios_base::app);//std::ios_base::app sets append mode
[Bug target/60884] New: [SH] improve inlined strlen-like builtin functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60884 Bug ID: 60884 Summary: [SH] improve inlined strlen-like builtin functions Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: olegendo at gcc dot gnu.org Target: sh*-*-* This is a carry over from the proposed improvement to the strlen-like builtin functions by Christian. The idea is to unroll some of the loops that are expanded: http://gcc.gnu.org/ml/gcc-patches/2014-03/msg01406.html As mentioned in http://gcc.gnu.org/ml/gcc-patches/2014-03/msg01687.html maybe the unrolling should be done at -O3 and not at -O2, since it increases code size in some places, but does not seem to lead to significant speed improvements (~ 1% as measured by Christian).
[Bug libstdc++/60883] std::ostringstream::str(const std::string&) works strangely
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60883 Andreas Schwab changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Andreas Schwab --- Since o isn't in append mode ostringstream::str(const string&) will set pptr() == pbase().
[Bug libstdc++/60883] New: std::ostringstream::str(const std::string&) works strangely
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60883 Bug ID: 60883 Summary: std::ostringstream::str(const std::string&) works strangely Product: gcc Version: 4.6.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: michal at mistrnet dot cz Created attachment 32630 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32630&action=edit Demonstrate ostringstream::str(const string&) side effect ostringstream::str(const string&) sets successfully content but next call of operator<< ignores this content.
[Bug target/60882] New: [ARM] Execution fail on spec2K/197.parser
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60882 Bug ID: 60882 Summary: [ARM] Execution fail on spec2K/197.parser Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: izamyatin at gmail dot com Looks like the infinite recursion of read_dict.c/insert_list routine Options: -Ofast -funroll-loops -flto -marm -mcpu=cortex-a15 -mfloat-abi=hard -mfpu=neon Compiler: Target: arm-linux-gnueabihf Configured with: /configure --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --enable-objc-gc --disable-sjlj-exceptions --with-arch=armv7-a --with-float=hard --with-mode=thumb --with-fpu=vfpv3-d16 --target=arm-linux-gnueabihf --host=arm-linux-gnueabihf --build=arm-linux-gnueabihf --with-multiarch-defaults=arm-linux-gnueabihf --enable-bootstrap=no --enable-languages=c,c++,fortran --enable-shared --enable-linker-build-id --disable-werror Thread model: posix gcc version 4.10.0 20140416 (experimental) (GCC) I believe 4.9.0 also has this fail
[Bug fortran/60881] ICE on dummy argument that extends a type with scalar and scalar coarry components
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60881 Dominique d'Humieres changed: What|Removed |Added Keywords||ice-on-valid-code Status|UNCONFIRMED |NEW Last reconfirmed||2014-04-18 Ever confirmed|0 |1 Known to fail||4.10.0, 4.7.4, 4.8.3, 4.9.0 --- Comment #1 from Dominique d'Humieres --- Confirmed on 4.7.4, 4.8.3, 4.9.0, and trunk.
[Bug fortran/60881] New: ICE on dummy argument that extends a type with scalar and scalar coarry components
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60881 Bug ID: 60881 Summary: ICE on dummy argument that extends a type with scalar and scalar coarry components Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: rouson at stanford dot edu The code and error message below demonstrate an ICE that occurs when passing an actual argument that extends a type with two components: a default-initialized scalar and an allocatable scalar coarray. Damian $ cat all.f90 program main implicit none type co_object logical :: defined=.false. real, allocatable :: dummy_to_facilitate_extension[:] end type type, extends(co_object) :: global_field end type type(global_field) T call assign_local_field(T) contains subroutine assign_local_field(lhs) type(global_field) lhs end subroutine end program $ gfortran -fcoarray=single all.f90 all.f90: In function 'MAIN__': all.f90:9:0: internal compiler error: in fold_convert_loc, at fold-const.c:2116 type(global_field) T ^ all.f90:9:0: internal compiler error: Abort trap: 6 gfortran: internal compiler error: Abort trap: 6 (program f951) Abort trap: 6 $ gfortran --version GNU Fortran (MacPorts gcc49 4.9-20140406_0) 4.9.0 20140406 (experimental) Copyright (C) 2014 Free Software Foundation, Inc.
[Bug target/60062] [4.7 Regression] wrong code (for code with the optimize attribute) at -O1 and above on x86_64-linux-gnu in 32-bit mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60062 Jakub Jelinek changed: What|Removed |Added CC||mnp at agtmt dot com --- Comment #10 from Jakub Jelinek --- *** Bug 60877 has been marked as a duplicate of this bug. ***
[Bug target/60877] __attribute__optimize("O0") conflict with static function at -O1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60877 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #2 from Jakub Jelinek --- Dup. *** This bug has been marked as a duplicate of bug 60062 ***
[Bug target/60879] Wrong decision in decide_alg in i386.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60879 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- Does this ever matter though? I mean, wouldn't we expand it as move by pieces or store by pieces for such small constant length anyway and thus never reach the target movmem/setmem expansion?
[Bug target/60851] [4.9/4.10 Regression] ICE: in extract_constrain_insn_cached, at recog.c:2117 with -flive-range-shrinkage -mdispatch-scheduler -march=bdver4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60851 --- Comment #4 from Zdenek Sojka --- Created attachment 32629 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32629&action=edit testsuite ICEs with -flive-range-shrinkage/-mdispatch-scheduler/-march=bdver3 I did a testsuite run with RUNTESTFLAGS="--target_board=unix/-flive-range-shrinkage/-mdispatch-scheduler/-march=bdver3", and grepped for 'internal compiler error'. I didn't have a look at all the failing files, but the ones I had was about converting long double to/from an integer.
