[IRA] Segfault in ira_costs.c:find_costs_and_classes for AVR target
Hi, gcc.c-torture/compile/pr34856.c and a couple of other tests segfault for the AVR target. Looking at the code, I found that the x_ira_register_move_cost array[TImode] is NULL, while the code goes on to dereference it (ira_register_move_cost [ALLOCNO_MODE (a)][best][aclass] at line 1832). I looked at the code that populates the array, and found that it does explicitly allow the array to have NULL entries for certain modes, atleast during initialization. I'm not really sure how this should be fixed - is NULL valid or is the AVR target violating some invariant? Regards Senthil
Re: What does 'experimental support for C++11' exactly mean for production work?
On Wed, Dec 25, 2013 at 7:19 PM, Luca Risolia luca.riso...@linux-projects.org wrote: I would like to propose the adoption of C++11 to my colleagues for our production code. We use to rebuild everything with the same compiler version each time (GCC 4.7.3 for now), so ABI incompatibilities between different GCC versions are not an issue for us. However, with C++11 in mind everything would have to be rebuilt with the -std=c++11 compiler flag turned on, as we could not accept any possible binary incompatibilities between C++11 and C++98. I have been personally using almost all the supported C++11 compiler features for long time without any particular problems. I am also aware of the fact that some big companies already decided to switch from C++98 to C++11 entirely. However, some of my colleagues might not be familiar with C++11 at all and might wonder what the claim experimental support for C++11 from the official GCC 4.7.3 status pages means in terms of risks for our code. Apart from some (minor) C++11 features not being implemented in the standard library or in the compiler yet, I'd like to know what else intrinsic to C++11 with GCC we should consider before switching. Questions like this should go to gcc-h...@gcc.gnu.org rather than gcc@gcc.gnu.org, which is a developer list. Please take any followups to gcc-help. Thanks. The major work on GCC 4.7 was completed before the C++11 standard was finalized, so it more or less had to be considered experimental. There were no substantial revisions in later versions of GCC, except for adding new features required by the standard. I don't think there are any substantial risks due to the experimental label of the C++11 support in GCC 4.7. Of course support for the new C++11 features was new and as such more likely to have bugs, though of course known bugs were fixed by the current 4.7.3 release. You'll have to judge for yourself how much of that sort of risk you want to tolerate. Hope this helps. Ian
gcc-4.8-20131226 is now available
Snapshot gcc-4.8-20131226 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.8-20131226/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.8 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_8-branch revision 206215 You'll find: gcc-4.8-20131226.tar.bz2 Complete GCC MD5=9a40fc8c3d7e0ca4f6c414dda6f27e46 SHA1=1b33f1a94d71df5df798236886e29aaf9f874ea6 Diffs from 4.8-20131219 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.8 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
[Bug sanitizer/59600] no_sanitize_address mishandled when function is inlined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59600 --- Comment #6 from Andrew Pinski pinskia at gcc dot gnu.org --- Comment on attachment 31516 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31516 New patch based on Andrew's review No this wrong in two ways. Move the check to before the check of the target attribute table. And second you should compare the current function attribute to fndecl attribute.
[Bug target/59601] [4.9 Regression] __attribute__ ((target(arch=corei7))) won't match Westmere processor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59601 --- Comment #1 from Uroš Bizjak ubizjak at gmail dot com --- (In reply to H.J. Lu from comment #0) 1. No change. __attribute__ ((target(arch=corei7))) won't match Westmere and function won't be optimized for Westmere. 2. Make PROCESSOR_NEHALEM to match corei7 for function versioning. But __attribute__ ((target(arch=nehalem))) function may be used on Westmere. I think it is OK since function versioning doesn't support extra ISAs on Westmere. I don't see the problem here. If corei7 is requested, then we want to cover all corei7 subtypes, including Nehalem. So, choice 1 - no change. mv.C failure migh be a testcase problem. However, the testcase works for me on ivybridge, which is also corei7 arch with popcnt.
[Bug sanitizer/59600] no_sanitize_address mishandled when function is inlined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59600 --- Comment #7 from Yury Gribov y.gribov at samsung dot com --- (In reply to Andrew Pinski from comment #6) Move the check to before the check of the target attribute table. My bad. And second you should compare the current function attribute to fndecl attribute. You mean compare caller's and callee's attributes? Makes a lot of sense but I don't think this info is available at the time function_attribute_inlinable_p is called: (gdb) b function_attribute_inlinable_p (gdb) r (gdb) call debug_generic_stmt(fndecl) mark_maybe_pointer (gdb) call debug_generic_stmt(current_function_decl) mark_maybe_pointer Perhaps this check should be moved to e.g. expand_call_inline?
[Bug target/59601] [4.9 Regression] __attribute__ ((target(arch=corei7))) won't match Westmere processor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59601
--- Comment #2 from Uroš Bizjak ubizjak at gmail dot com ---
(In reply to Uroš Bizjak from comment #1)
mv1.C failure migh be a testcase problem. However, the testcase works for me
on ivybridge, which is also corei7 arch with popcnt.
It also fails for me if I remove avx alternative. Looks like a bug, indeed.
Following test doesn't work on ivbridge (a corei7 cpu):
--cut here--
#include assert.h
/* Default version. */
int foo (); // Extra declaration that is merged with the second one.
int foo () __attribute__ ((target(default)));
int foo () __attribute__ ((target(arch=corei7)));
int (*p)() = foo;
int main ()
{
int val = foo ();
assert (val == (*p)());
/* Check in the exact same order in which the dispatching
is expected to happen. */
if (__builtin_cpu_is (corei7))
assert (val == 5);
else
assert (val == 0);
return 0;
}
int __attribute__ ((target(default)))
foo ()
{
return 0;
}
int __attribute__ ((target(arch=corei7)))
foo ()
{
return 5;
}
--cut here--
It looks to me that dispatcher doesn't call corei7 version, while
__builtin_cpu_is works OK.
[Bug target/59601] [4.9 Regression] __attribute__ ((target(arch=corei7))) won't match Westmere processor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59601 Uroš Bizjak ubizjak at gmail dot com changed: What|Removed |Added Target Milestone|--- |4.9.0
[Bug target/59601] [4.9 Regression] __attribute__ ((target(arch=corei7))) won't match Westmere processor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59601 Uroš Bizjak ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-12-26 Ever confirmed|0 |1 --- Comment #3 from Uroš Bizjak ubizjak at gmail dot com --- 4.8 generates: _Z3foov.resolver: subq$8, %rsp call__cpu_indicator_init cmpl$3, __cpu_model+4(%rip) movl$_Z3foov.arch_corei7, %eax movl$_Z3foov, %edx cmovne%rdx, %rax addq$8, %rsp ret 4.9: _Z3foov.resolver: subq$8, %rsp call__cpu_indicator_init cmpl$1, __cpu_model+8(%rip) movl$_Z3foov.arch_corei7, %edx movl$_Z3foov, %eax cmove%rdx, %rax addq$8, %rsp ret 4.9 looks at subtype (__cpu_model+8), which is wrong. corei7 is processor type, located at (__cpu_model+4).
[Bug target/59576] sorry, unimplemented: making multiple clones error on *-apple-darwin*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59576 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- AFAICT this has been fixed by r206182.
[Bug c++/41090] [4.7/4.8/4.9 Regression] Using static label reference in c++ class constructor produces wrong code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41090 --- Comment #21 from Dominique d'Humieres dominiq at lps dot ens.fr --- The test g++.dg/ext/label13.C XPASS after r20182 on darwin.
[Bug target/59601] [4.9 Regression] __attribute__ ((target(arch=corei7))) won't match Westmere processor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59601
--- Comment #4 from H.J. Lu hjl.tools at gmail dot com ---
Before my cleanup, get_builtin_code_for_version had
switch (new_target-arch)
{
case PROCESSOR_CORE2:
arg_str = core2;
priority = P_PROC_SSSE3;
break;
case PROCESSOR_COREI7:
arg_str = corei7;
priority = P_PROC_SSE4_2;
break;
case PROCESSOR_COREI7_AVX:
arg_str = corei7-avx;
priority = P_PROC_SSE4_2;
break;
and fold_builtin_cpu had
enum processor_model
{
M_INTEL = 1,
M_AMD,
M_CPU_TYPE_START,
M_INTEL_ATOM,
M_INTEL_CORE2,
M_INTEL_COREI7,
M_AMDFAM10H,
M_AMDFAM15H,
M_INTEL_SLM,
M_CPU_SUBTYPE_START,
M_INTEL_COREI7_NEHALEM,
M_INTEL_COREI7_WESTMERE,
M_INTEL_COREI7_SANDYBRIDGE,
...
const arch_names_table[] =
{
{amd, M_AMD},
{intel, M_INTEL},
{atom, M_INTEL_ATOM},
{slm, M_INTEL_SLM},
{core2, M_INTEL_CORE2},
{corei7, M_INTEL_COREI7},
{nehalem, M_INTEL_COREI7_NEHALEM},
{westmere, M_INTEL_COREI7_WESTMERE},
{sandybridge, M_INTEL_COREI7_SANDYBRIDGE},
__attribute__ ((target(arch=corei7))) is mapped to
M_INTEL_COREI7. After my cleanup, get_builtin_code_for_version has
switch (new_target-arch)
{
case PROCESSOR_CORE2:
arg_str = core2;
priority = P_PROC_SSSE3;
break;
case PROCESSOR_NEHALEM:
arg_str = nehalem;
priority = P_PROC_SSE4_2;
break;
case PROCESSOR_SANDYBRIDGE:
arg_str = sandybridge;
priority = P_PROC_AVX;
break;
case PROCESSOR_HASWELL:
arg_str = haswell;
priority = P_PROC_AVX2;
break;
and fold_builtin_cpu has
enum processor_model
{
M_INTEL = 1,
M_AMD,
M_CPU_TYPE_START,
M_INTEL_BONNELL,
M_INTEL_CORE2,
M_INTEL_COREI7,
M_AMDFAM10H,
M_AMDFAM15H,
M_INTEL_SILVERMONT,
M_AMD_BOBCAT,
M_AMD_JAGUAR,
M_CPU_SUBTYPE_START,
M_INTEL_COREI7_NEHALEM,
M_INTEL_COREI7_WESTMERE,
M_INTEL_COREI7_SANDYBRIDGE,
...
const arch_names_table[] =
{
{amd, M_AMD},
{intel, M_INTEL},
{atom, M_INTEL_BONNELL},
{slm, M_INTEL_SILVERMONT},
{core2, M_INTEL_CORE2},
{corei7, M_INTEL_COREI7},
{nehalem, M_INTEL_COREI7_NEHALEM},
{westmere, M_INTEL_COREI7_WESTMERE},
{sandybridge, M_INTEL_COREI7_SANDYBRIDGE},
{ivybridge, M_INTEL_COREI7_IVYBRIDGE},
{haswell, M_INTEL_COREI7_HASWELL},
{bonnell, M_INTEL_BONNELL},
{silvermont, M_INTEL_SILVERMONT},
__attribute__ ((target(arch=corei7))) is translated to
PROCESSOR_NEHALEM mapped to M_INTEL_COREI7_NEHALEM. We
used to have __attribute__ ((target(arch=corei7)))
to cover M_INTEL_COREI7_. Now it only covers
M_INTEL_COREI7_NEHALEM. We have PROCESSOR_SANDYBRIDGE
and PROCESSOR_HASWELL. But there is nothing to mark
Westmere and Ivy Bridge. Since function versioning
doesn't support extra ISAs in Westmere and Ivy Bridge,
we don't lose anything. The solution is to map
__attribute__ ((target(arch=corei7))) and
__attribute__ ((target(arch=nehalem))) to
M_INTEL_COREI7 with
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index 37bb656..69438c1 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -30010,7 +30010,10 @@ get_builtin_code_for_version (tree decl, tree
*predicate_list)
priority = P_PROC_SSSE3;
break;
case PROCESSOR_NEHALEM:
-arg_str = nehalem;
+/* We translate arch=corei7 and arch=nehelam to
+ corei7 so that it will be mapped to M_INTEL_COREI7
+ as cpu type. */
+arg_str = corei7;
priority = P_PROC_SSE4_2;
break;
case PROCESSOR_SANDYBRIDGE:
[Bug target/59379] [4.9 Regression] gomp_init_num_threads is compiled into an infinite loop with --with-arch=corei7 --with-cpu=slm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59379 --- Comment #10 from Igor Zamyatin izamyatin at gmail dot com --- I could build profiled bootstrap for r204980 successfully
[Bug target/59379] [4.9 Regression] gomp_init_num_threads is compiled into an infinite loop with --with-arch=corei7 --with-cpu=slm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59379 --- Comment #11 from H.J. Lu hjl.tools at gmail dot com --- (In reply to Igor Zamyatin from comment #10) I could build profiled bootstrap for r204980 successfully Is that possible to find a testcase?
[Bug fortran/56674] [4.7/4.8/4.9 Regression] ICE in check_sym_interfaces
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56674 --- Comment #5 from Dominique d'Humieres dominiq at lps dot ens.fr --- This appeared at r181425.
[Bug fortran/59023] [4.9 regression] ICE in gfc_search_interface with BIND(C)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59023 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added CC||bur...@net-b.de --- Comment #3 from Dominique d'Humieres dominiq at lps dot ens.fr --- The ICE appeared between r199034 (2013-05-17, no ICE) and r199221 (2013-05-22, ICE).
[Bug c/59602] New: ARM, __attribute__((interrupt(FIQ))) causes internal compiler error with -O0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59602
Bug ID: 59602
Summary: ARM, __attribute__((interrupt(FIQ))) causes internal
compiler error with -O0
Product: gcc
Version: 4.8.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: Sergey.Belyashov at gmail dot com
I try to compile simple program. If I use some level of optimization more than
zero then no problem. But without optimization compiler dies:
$ arm-none-eabi-gcc -O0 -marm -march=armv4 -nostdlib -std=gnu99 -c -o bootldr.o
bootldr.c
bootldr.c: In function 'fiqHandler':
bootldr.c:5:1: error: insn does not satisfy its constraints:
}
^
(insn 13 12 14 (set (reg/f:SI 13 sp)
(plus:SI (reg/f:SI 11 fp)
(const_int 4 [0x4]))) bootldr.c:5 5 {*arm_addsi3}
(nil))
bootldr.c:5:1: internal compiler error: in note_invalid_constants, at
config/arm/arm.c:15751
$ cat bootldr.c
void fiqHandler(void) __attribute__ ((interrupt(FIQ)));
void fiqHandler(void)
{
__asm__ volatile(nop);
}
$ arm-none-eabi-gcc -v
Using built-in specs.
COLLECT_GCC=arm-none-eabi-gcc
COLLECT_LTO_WRAPPER=/usr/bin/../lib/gcc/arm-none-eabi/4.8.3/lto-wrapper
Target: arm-none-eabi
Configured with: /build/buildd/gcc-arm-none-eabi-4-8-2013q4/src/gcc/configure
--target=arm-none-eabi
--prefix=/build/buildd/gcc-arm-none-eabi-4-8-2013q4/install-native
--libexecdir=/build/buildd/gcc-arm-none-eabi-4-8-2013q4/install-native/lib
--infodir=/build/buildd/gcc-arm-none-eabi-4-8-2013q4/install-native/share/doc/gcc-arm-none-eabi/info
--mandir=/build/buildd/gcc-arm-none-eabi-4-8-2013q4/install-native/share/doc/gcc-arm-none-eabi/man
--htmldir=/build/buildd/gcc-arm-none-eabi-4-8-2013q4/install-native/share/doc/gcc-arm-none-eabi/html
--pdfdir=/build/buildd/gcc-arm-none-eabi-4-8-2013q4/install-native/share/doc/gcc-arm-none-eabi/pdf
--enable-languages=c,c++ --enable-plugins --disable-decimal-float
--disable-libffi --disable-libgomp --disable-libmudflap --disable-libquadmath
--disable-libssp --disable-libstdcxx-pch --disable-nls --disable-shared
--disable-threads --disable-tls --with-gnu-as --with-gnu-ld --with-newlib
--with-headers=yes --with-python-dir=share/gcc-arm-none-eabi
--with-sysroot=/build/buildd/gcc-arm-none-eabi-4-8-2013q4/install-native/arm-none-eabi
--with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm'
--with-pkgversion='GNU Tools for ARM Embedded Processors'
--with-multilib-list=armv6-m,armv7-m,armv7e-m,armv7-r
Thread model: single
gcc version 4.8.3 20131129 (release) [ARM/embedded-4_8-branch revision 205641]
(GNU Tools for ARM Embedded Processors)
$ lsb_release -d
Description:Ubuntu 12.04.3 LTS
[Bug fortran/56169] Installation the Chromium from ports fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56169 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #4 from Dominique d'Humieres dominiq at lps dot ens.fr --- The error in the log configure: failed program was: | | program foo | real, parameter :: bar = sin (12.34 / 2.5) | end program foo indicates a problem with gmp or mpfr (see http://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVEDcf_known_to_fail_type=allwordscf_known_to_work_type=allwordslist_id=78083longdesc=real%2C%20parameter%20%3A%3A%20bar%20%3D%20sinlongdesc_type=allwordssubstrquery_format=advancedresolution=INVALID for duplicates).
[Bug fortran/46485] gfortran.dg/allocatable_scalar_5.f90 fails on s390-ibm-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46485 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr --- No feedback since more than six months. Closing as FIXED.
[Bug fortran/53035] ICE with deferred-length module variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53035 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #8 from Dominique d'Humieres dominiq at lps dot ens.fr --- The tests in comments #4 and #5 compile with revision 187834 (2012-05-24), but not with revision 187440 (2012-05-13). Could you test that your application compiles with gfortran 4.8.1? I have tested that the original submittal compiles with 4.8.2. No feedback since six months. Closing as FIXED.
[Bug fortran/50552] type name cannot be statement function dummy argument (r178939)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50552 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #5 from Dominique d'Humieres dominiq at lps dot ens.fr --- Poster more than two years ago: I am traveling in Korea, and I cannot look at the standard now. If you believe this is a non-issue then please close it. Posted more than six months ago: Before I close this PR as INVALID, could someone have a look at it? No feedback, closing as INVALID.
[Bug target/59379] [4.9 Regression] gomp_init_num_threads is compiled into an infinite loop with --with-arch=corei7 --with-cpu=slm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59379 --- Comment #12 from H.J. Lu hjl.tools at gmail dot com --- (In reply to Igor Zamyatin from comment #10) I could build profiled bootstrap for r204980 successfully It isn't about profiled bootstrap. It is about make check in libgomp. All libgomp tests go into an infinite loop. It still happens with r206208.
[Bug target/59601] [4.9 Regression] __attribute__ ((target(arch=corei7))) won't match Westmere processor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59601 --- Comment #5 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org --- Author: hjl Date: Thu Dec 26 14:47:15 2013 New Revision: 206212 URL: http://gcc.gnu.org/viewcvs?rev=206212root=gccview=rev Log: Map arch=corei7/arch=nehalem to M_INTEL_COREI7 After Intel processor name cleanup, __attribute__ ((target(arch=corei7))) is translated to PROCESSOR_NEHALEM and mapped to M_INTEL_COREI7_NEHALEM. __attribute__ ((target(arch=corei7))) used to cover M_INTEL_COREI7_. Now it only covers M_INTEL_COREI7_NEHALEM. We have PROCESSOR_SANDYBRIDGE and PROCESSOR_HASWELL. But there is nothing to mark Westmere and Ivy Bridge. Since function versioning doesn't support extra ISAs in Westmere and Ivy Bridge, we don't lose anything. The solution is to map __attribute__ ((target(arch=corei7))) and __attribute__ ((target(arch=nehalem))) to M_INTEL_COREI7. gcc/ PR target/59601 * config/i386/i386.c (get_builtin_code_for_version): Map PROCESSOR_NEHALEM to corei7. gcc/testsuite/ PR target/59601 * g++.dg/ext/mv14.C: New tests. * g++.dg/ext/mv15.C: Likewise. Added: trunk/gcc/testsuite/g++.dg/ext/mv14.C trunk/gcc/testsuite/g++.dg/ext/mv15.C Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/59023] [4.9 regression] ICE in gfc_search_interface with BIND(C)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59023 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added CC||tkoenig at gcc dot gnu.org --- Comment #4 from Thomas Koenig tkoenig at gcc dot gnu.org --- Valgrind backtrace: ==19413== Memcheck, a memory error detector ==19413== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al. ==19413== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info ==19413== Command: /home/ig25/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/f951 foo.f90 ==19413== ==19413== Invalid read of size 4 ==19413==at 0x57708A: gfc_search_interface(gfc_interface*, int, gfc_actual_arglist**) (interface.c:3439) ==19413==by 0x5BD333: gfc_resolve_expr(gfc_expr*) (resolve.c:2480) ==19413==by 0x5C1C03: resolve_code(gfc_code*, gfc_namespace*) (resolve.c:9775) ==19413==by 0x5C4BBE: resolve_codes(gfc_namespace*) (resolve.c:14566) ==19413==by 0x5C4AC7: resolve_codes(gfc_namespace*) (resolve.c:14552) ==19413==by 0x5C4CA2: gfc_resolve(gfc_namespace*) [clone .part.45] (resolve.c:14594) ==19413==by 0x5B0BEF: gfc_parse_file() (parse.c:4672) ==19413==by 0x5EE8C5: gfc_be_parse_file() (f95-lang.c:188) ==19413==by 0x9F9E55: compile_file() (toplev.c:547) ==19413==by 0x9FBE27: toplev_main(int, char**) (toplev.c:1887) ==19413==by 0x5A54BE4: (below main) (in /lib64/libc-2.18.so) ==19413== Address 0x8b4853fd89495554 is not stack'd, malloc'd or (recently) free'd ==19413==
[Bug ipa/58721] [4.9 Regression] The subroutine perdida is no longer inlined in fatigue.f90
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58721 --- Comment #17 from Jan Hubicka hubicka at gcc dot gnu.org --- Created attachment 31517 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31517action=edit Patch to extend __builtin_expect Hi, this patch adds internal use only parameter to builtin_expect that Fortran can use to specify type of in builtin_unlikely/likely.
[Bug target/59588] No need to check generic nor change i686 for -mtune=
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59588 --- Comment #3 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org --- Author: hjl Date: Thu Dec 26 16:10:55 2013 New Revision: 206213 URL: http://gcc.gnu.org/viewcvs?rev=206213root=gccview=rev Log: Don't check/change generic/i686 tuning gcc/ PR target/59588 * config/i386/i386.c (ix86_option_override_internal): Don't check generic tuning. Don't change i686 tuning. gcc/testsuite/ PR target/59588 * gcc.target/i386/pr59588-1.c: New file. * gcc.target/i386/pr59588-2.c: Likewise. Added: trunk/gcc/testsuite/gcc.target/i386/pr59588-1.c trunk/gcc/testsuite/gcc.target/i386/pr59588-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/testsuite/ChangeLog
[Bug libstdc++/59603] New: std::random_shuffle tries to swap element with itself
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59603
Bug ID: 59603
Summary: std::random_shuffle tries to swap element with itself
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: fab at orlen dot de
When using the debugging macro _GLIBCXX_DEBUG, calling random_shuffle fails on
some types, because it might try to swap an element with itself.
Output of attached program:
/tmp$ g++ -o random_shuffle_bug -std=c++11 random_shuffle_bug.cc
/tmp$ ./random_shuffle_bug
/usr/include/c++/4.8.2/debug/vector:159:error: attempt to self move assign.
Objects involved in the operation:
sequence this @ 0x0xa600c8 {
type = NSt7__debug6vectorIiSaIiEEE;
}
Aborted (core dumped)
return code: 134
I could not find any information about whether swapping an element with itself
is allowed.
[Bug libstdc++/59603] std::random_shuffle tries to swap element with itself
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59603 --- Comment #1 from Fabian Emmes fab at orlen dot de --- Created attachment 31518 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31518action=edit program triggering the error
[Bug fortran/58003] internal compiler error: in convert_mpz_to_unsigned, at fortran/simplify.c:165
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58003 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED CC||tkoenig at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |tkoenig at gcc dot gnu.org --- Comment #4 from Thomas Koenig tkoenig at gcc dot gnu.org --- I have a patch.
[Bug fortran/59604] New: Constant comparisons with -fno-range-check and int(z'...')
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59604 Bug ID: 59604 Summary: Constant comparisons with -fno-range-check and int(z'...') Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: tkoenig at gcc dot gnu.org Trying out a fix for PR 58003, I found that the following program was of the opinion that -1 does not equal -1: ig25@linux-fd1f:~/Krempel/NoRange cat bar.f90 program test use iso_fortran_env implicit none integer, parameter :: wt = int32 print *, int(z'',wt) print *, int(z'',wt) /= -1 end program test ig25@linux-fd1f:~/Krempel/NoRange gfortran -fno-range-check bar.f90 ig25@linux-fd1f:~/Krempel/NoRange ./a.out -1 T
[Bug target/59601] [4.9 Regression] __attribute__ ((target(arch=corei7))) won't match Westmere processor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59601 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from H.J. Lu hjl.tools at gmail dot com --- Fixed.
[Bug c++/41090] [4.7/4.8/4.9 Regression] Using static label reference in c++ class constructor produces wrong code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41090 --- Comment #22 from dave.anglin at bell dot net --- On 26-Dec-13, at 7:28 AM, dominiq at lps dot ens.fr wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41090 --- Comment #21 from Dominique d'Humieres dominiq at lps dot ens.fr --- The test g++.dg/ext/label13.C XPASS after r20182 on darwin. Likewise on hppa2.0w-hp-hpux11.11. Dave -- John David Anglindave.ang...@bell.net
[Bug target/59588] No need to check generic nor change i686 for -mtune=
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59588 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from H.J. Lu hjl.tools at gmail dot com --- Fixed on trunk. No plan to backport to release branches.
[Bug c++/59598] very simple code using file open for read
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59598
Denis Kolesnik denis.v.koles...@safe-mail.net changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID |---
--- Comment #6 from Denis Kolesnik denis.v.koles...@safe-mail.net ---
please tell me where in this corrected code I made mistake:
// a small text file filter.c //
#include stdio.h
main(int argc, char* argv[])
{
char c, previous_c;
int word_begin_position[3000];
int spec_symbol[7]={0xAE,0xBB,0xAB,0xA9,0x22,0x2F,0x27};
int eof_symbol[2]={0x0D,0x0A};
int search_result;
int this_is_the_same_word;
int words_count;
int word_number;
int search_result_A_count;
int search_result_space;
FILE *stream,*stream2;
int i, j, characters_count, character_number;
characters_count=0;
stream = fopen (argv[1],r);
while ((c = fgetc(stream)) != EOF)
{
characters_count++;
}
fclose(stream);
//printf(total characters are %i\n, characters_count);
character_number=1;
words_count=0;
previous_c=0;
stream = fopen (argv[1],r);
while ((c = fgetc(stream)) != EOF)
{
if(((c!=0x20) (character_number==1)) || ((previous_c==0x20)
(c!=0x20) (c!=0x0A)) || ((previous_c!=0x20) (c==0x0D)) || ((c!=0x20)
(c!=0x0D) (c!=0x0A) (previous_c==0x0A)) || ((previous_c!=0x20)
(previous_c!=0x0A) (character_number==characters_count) (c==0x20)))
//1. ((c!=0x20) (character_number==1))
//2. ((previous_c==0x20) (c!=0x20) (c!=0x0A))
//3. ((previous_c!=0x20) (c==0x0D))
//!((previous_c!=0x0D) (c==0x0A))
//4. ((c!=0x20) (c!=0x0D) (c!=0x0A) (previous_c==0x0A))
//5. ((previous_c!=0x20) (previous_c!=0x0A)
(character_number==characters_count) (c==0x20))
this_is_the_same_word=0;
else
this_is_the_same_word=1;
if(this_is_the_same_word==0)
{
words_count++;
word_begin_position[words_count]=character_number;
//printf( the begin char is .
%i,word_begin_position[words_count]);
}
//if(character_number==characters_count)
//printf(the last character);
/*
printf( the number of words is %i\n, words_count);
printf( the current character is . %c\n, c);
if(c==0x0D)
printf( the current character is . 0x0D\n);
if(c==0x0A)
printf( the current character is . 0x0A\n);
*/
previous_c=c;
character_number++;
}
fclose(stream);
word_number=1;
character_number=1;
stream = fopen (argv[1],r);
//stream2 = fopen (argv[2],w);
while ((c = fgetc(stream)) != EOF)
{
//if((character_number = word_begin_position[word_number])
(character_number = word_begin_position[word_number+1]))
if(c==0x0D)
then
{
//fprintf(stream2,%s, \\r\\n);
//if(c==EOF)
//then
//printf(A);
//else
//printf(%s,c);
printf(%s, c);
}
//else
//word_number++;
character_number++;
}
fclose(stream);
//printf( the number of words is %i, words_count);
return 0;
}
why this portion of code:
if(c==0x0D)
then
{
//fprintf(stream2,%s, \\r\\n);
//if(c==EOF)
//then
//printf(A);
//else
//printf(%s,c);
printf(%s, c);
}
//else
//word_number++;
reports:
replace_1.c: In function 'main':
replace_1.c:112:3: error: 'then' undeclared (first use in this function)
replace_1.c:112:3: note: each undeclared identifier is reported only once for
ea
ch function it appears in
replace_1.c:113:3: error: expected ';' before '{' token
[Bug c++/59598] very simple code using file open for read
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59598 --- Comment #7 from Denis Kolesnik denis.v.koles...@safe-mail.net --- I found my error, sorry for it.
[Bug c++/59598] very simple code using file open for read
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59598 Denis Kolesnik denis.v.koles...@safe-mail.net changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #8 from Denis Kolesnik denis.v.koles...@safe-mail.net --- I found my mistake
[Bug c++/59598] very simple code using file open for read
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59598 Denis Kolesnik denis.v.koles...@safe-mail.net changed: What|Removed |Added Resolution|FIXED |INVALID --- Comment #9 from Denis Kolesnik denis.v.koles...@safe-mail.net --- I found my mistake
[Bug c++/59598] very simple code using file open for read
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59598 --- Comment #10 from Denis Kolesnik denis.v.koles...@safe-mail.net --- : the then is obivious,
[Bug c++/59598] very simple code using file open for read
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59598
Denis Kolesnik denis.v.koles...@safe-mail.net changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID |---
--- Comment #11 from Denis Kolesnik denis.v.koles...@safe-mail.net ---
why in this code:
// a small text file filter.c //
#include stdio.h
main(int argc, char* argv[])
{
char c, previous_c;
int word_begin_position[3000];
int spec_symbol[7]={0xAE,0xBB,0xAB,0xA9,0x22,0x2F,0x27};
int eof_symbol[2]={0x0D,0x0A};
int search_result;
int this_is_the_same_word;
int words_count;
int word_number;
int search_result_A_count;
int search_result_space;
FILE *stream,*stream2;
int i, j, characters_count, character_number;
characters_count=0;
stream = fopen (argv[1],r);
while ((c = fgetc(stream)) != EOF)
{
characters_count++;
}
fclose(stream);
//printf(total characters are %i\n, characters_count);
character_number=1;
words_count=0;
previous_c=0;
stream = fopen (argv[1],r);
while ((c = fgetc(stream)) != EOF)
{
if(((c!=0x20) (character_number==1)) || ((previous_c==0x20)
(c!=0x20) (c!=0x0A)) || ((previous_c!=0x20) (c==0x0D)) || ((c!=0x20)
(c!=0x0D) (c!=0x0A) (previous_c==0x0A)) || ((previous_c!=0x20)
(previous_c!=0x0A) (character_number==characters_count) (c==0x20)))
//1. ((c!=0x20) (character_number==1))
//2. ((previous_c==0x20) (c!=0x20) (c!=0x0A))
//3. ((previous_c!=0x20) (c==0x0D))
//!((previous_c!=0x0D) (c==0x0A))
//4. ((c!=0x20) (c!=0x0D) (c!=0x0A) (previous_c==0x0A))
//5. ((previous_c!=0x20) (previous_c!=0x0A)
(character_number==characters_count) (c==0x20))
this_is_the_same_word=0;
else
this_is_the_same_word=1;
if(this_is_the_same_word==0)
{
words_count++;
word_begin_position[words_count]=character_number;
//printf( the begin char is .
%i,word_begin_position[words_count]);
}
//if(character_number==characters_count)
//printf(the last character);
/*
printf( the number of words is %i\n, words_count);
printf( the current character is . %c\n, c);
if(c==0x0D)
printf( the current character is . 0x0D\n);
if(c==0x0A)
printf( the current character is . 0x0A\n);
*/
previous_c=c;
character_number++;
}
fclose(stream);
word_number=1;
character_number=1;
stream = fopen (argv[1],r);
//stream2 = fopen (argv[2],w);
while ((c = fgetc(stream)) != EOF)
{
if((character_number = word_begin_position[word_number])
(character_number = word_begin_position[word_number+1]))
{
if(c==0x0D)
printf(A);
else
printf(%s, c);
}
//else
//word_number++;
character_number++;
}
fclose(stream);
//printf( the number of words is %i, words_count);
return 0;
}
the portion:
if(c==0x0D)
printf(A);
else
printf(%s, c);
results in error while program run??
[Bug middle-end/59605] New: [4.9 Regression] error: wrong number of branch edges after unconditional jump in bb 11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59605
Bug ID: 59605
Summary: [4.9 Regression] error: wrong number of branch edges
after unconditional jump in bb 11
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
On Linux/x86, r206213 gave
[hjl@gnu-18 gcc]$ cat bad.c
#define BUFFER_SIZE (16*1024*1024 + AVG_SIZE*2)
/*#define MEMORY_COPIES (1024*1024*64*(long long)10)*/
char t[BUFFER_SIZE];
main()
{
unsigned int i;
for (i=0;i((long long)MEMORY_COPIES + AVG_SIZE * 2 - 1)/AVG_SIZE*2;i++)
#ifdef test_memset
__builtin_memset (t+(i*1024*1024+i*1)%(BUFFER_SIZE - AVG_SIZE*2), i,
(AVG_SIZE + i) % (AVG_SIZE * 2 + 0));
#else
__builtin_memcpy (t+(i*1024*1024+i*1)%(BUFFER_SIZE - AVG_SIZE*2),
t+((i+1)*1024*1024*4+i*1)%(BUFFER_SIZE - AVG_SIZE *2), (AVG_SIZE + i) %
(AVG_SIZE * 2 + 0));
#endif
return 0;
}
[hjl@gnu-18 gcc]$ ./xgcc -B ./ -x c -O3 -minline-stringops-dynamically
-DAVG_SIZE=8192000 -DMEMORY_COPIES=64000 bad.c
bad.c: In function ‘main’:
bad.c:14:1: error: wrong number of branch edges after unconditional jump in bb
11
}
^
bad.c:14:1: error: wrong number of branch edges after unconditional jump in bb
7
bad.c:14:1: internal compiler error: verify_flow_info failed
0x666c23 verify_flow_info()
/export/gnu/import/git/gcc/gcc/cfghooks.c:260
0xe25a53 try_optimize_cfg
/export/gnu/import/git/gcc/gcc/cfgcleanup.c:2857
0xe25a53 cleanup_cfg(int)
/export/gnu/import/git/gcc/gcc/cfgcleanup.c:3022
0x665412 gimple_expand_cfg
/export/gnu/import/git/gcc/gcc/cfgexpand.c:5837
0x665412 execute
/export/gnu/import/git/gcc/gcc/cfgexpand.c:5932
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See http://gcc.gnu.org/bugs.html for instructions.
[hjl@gnu-18 gcc]$
[Bug target/59605] [4.9 Regression] error: wrong number of branch edges after unconditional jump in bb 11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59605 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added CC||hubicka at ucw dot cz Component|middle-end |target Target Milestone|--- |4.9.0 --- Comment #1 from H.J. Lu hjl.tools at gmail dot com --- It is caused by r203937.
[Bug c++/59598] very simple code using file open for read
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59598 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #12 from Andrew Pinski pinskia at gcc dot gnu.org --- You want %c. This is not the correct place to ask questions about C programming. This is a place to report bugs in GCC.
[Bug c++/59598] very simple code using file open for read
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59598 --- Comment #13 from Denis Kolesnik denis.v.koles...@safe-mail.net --- (In reply to Andrew Pinski from comment #12) You want %c. This is not the correct place to ask questions about C programming. This is a place to report bugs in GCC. : thanks for help
[Bug c++/59606] New: Internal compiler error: Error reporting routines re-entered.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59606 Bug ID: 59606 Summary: Internal compiler error: Error reporting routines re-entered. Product: gcc Version: 4.7.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: vyf at princeton dot edu Everything was working fine until I changed some things in the source (specifically, added an aligned_storage member), and then I get this output from Eclipse: Building file: ../main.cpp Invoking: GCC C++ Compiler g++ -D__cplusplus=201103L -O0 -g3 -Wall -c -fmessage-length=0 -std=c++11 -MMD -MP -MFmain.d -MTmain.d -o main.o ../main.cpp ‘ Internal compiler error: Error reporting routines re-entered. Please submit a full bug report, with preprocessed source if appropriate. See file:///usr/share/doc/gcc-4.7/README.Bugs for instructions. Preprocessed source stored into /tmp/ccJaexzT.out file, please attach this to your bugreport. make: *** [main.o] Error 1 The file is attached, as requested.
[Bug c++/59607] New: Internal compiler error: Error reporting routines re-entered.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59607 Bug ID: 59607 Summary: Internal compiler error: Error reporting routines re-entered. Product: gcc Version: 4.7.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: vyf at princeton dot edu Everything was working fine until I changed some things in the source (specifically, added an aligned_storage member), and then I get this output from Eclipse: Building file: ../main.cpp Invoking: GCC C++ Compiler g++ -D__cplusplus=201103L -O0 -g3 -Wall -c -fmessage-length=0 -std=c++11 -MMD -MP -MFmain.d -MTmain.d -o main.o ../main.cpp ‘ Internal compiler error: Error reporting routines re-entered. Please submit a full bug report, with preprocessed source if appropriate. See file:///usr/share/doc/gcc-4.7/README.Bugs for instructions. Preprocessed source stored into /tmp/ccJaexzT.out file, please attach this to your bugreport. make: *** [main.o] Error 1 The file is attached, as requested.
[Bug regression/59608] New: Unable to build working poedit v.1.5.x using gcc 4.8.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59608 Bug ID: 59608 Summary: Unable to build working poedit v.1.5.x using gcc 4.8.2 Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: critical Priority: P3 Component: regression Assignee: unassigned at gcc dot gnu.org Reporter: je at ktf dot rtu.lv Hi! I am not sure whetehr it is the right place to report a bug, but I am unable to compile working poedit 1.5.7 on Slackware64-14/gcc 4.8.2/glibc-2.17. During compile time there are some warnings, but compilation ends successfully. Unfortunately, compiled app either dies with segfault or produces messages about incorrectly used functions of wxWindows library. I tried to invoke the app built for Ubuntu 12.04 and, to my surprise, app works as expected, using libraries I have on my system. That led me to the conclusion that something wrong happens during compilation. Flags given to compiler: -O2 -fPIC
[Bug regression/59608] Unable to build working poedit v.1.5.x using gcc 4.8.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59608 --- Comment #1 from Janis je at ktf dot rtu.lv --- Created attachment 31520 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31520action=edit configure log
[Bug regression/59608] Unable to build working poedit v.1.5.x using gcc 4.8.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59608 Janis je at ktf dot rtu.lv changed: What|Removed |Added Attachment #31519|0 |1 is obsolete|| --- Comment #2 from Janis je at ktf dot rtu.lv --- Created attachment 31521 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31521action=edit make log
[Bug bootstrap/48415] GC Warning: Repeated allocation of very large block
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48415 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WORKSFORME --- Comment #2 from Steven Bosscher steven at gcc dot gnu.org --- gcc-testresults has java results for powerpc64 and s390.
[Bug target/59605] [4.9 Regression] error: wrong number of branch edges after unconditional jump in bb 11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59605
H.J. Lu hjl.tools at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2013-12-26
Ever confirmed|0 |1
--- Comment #2 from H.J. Lu hjl.tools at gmail dot com ---
ix86_expand_set_or_movmem has
rtx jump_around_label = NULL;
/* Misaligned move sequences handles both prologues and epilogues at once.
Default code generation results in smaller code for large alignments and
also avoids redundant job when sizes are known precisely. */
if (misaligned_prologue_used)
{
/* Misaligned move prologue handled small blocks by itself. */
expand_set_or_movmem_prologue_epilogue_by_misaligned_moves
(dst, src, destreg, srcreg,
move_mode, promoted_val, vec_promoted_val,
count_exp,
jump_around_label,
desired_align align
? MAX (desired_align, epilogue_size_needed) : epilogue_size_needed,
desired_align, align, min_size, dynamic_check, issetmem);
if (!issetmem)
src = change_address (src, BLKmode, srcreg);
...
else
{
rtx hot_label = gen_label_rtx ();
jump_around_label = gen_label_rtx ();
^
When jump_around_label != NULL, the previous jump_around_label
is lost.
emit_cmp_and_jump_insns (count_exp, GEN_INT (dynamic_check - 1),
LEU, 0, GET_MODE (count_exp), 1, hot_label);
predict_jump (REG_BR_PROB_BASE * 90 / 100);
if (issetmem)
set_storage_via_libcall (dst, count_exp, val_exp, false);
else
emit_block_move_via_libcall (dst, src, count_exp, false);
emit_jump (jump_around_label);
emit_label (hot_label);
}
[Bug rtl-optimization/29589] incorrect conversion of (ior (ashiftrt (plus ...))) in combine.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29589 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #11 from Steven Bosscher steven at gcc dot gnu.org --- Merry Christmas! *** This bug has been marked as a duplicate of bug 57829 ***
[Bug rtl-optimization/57829] Wrong constant folding
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57829 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added CC||cqfu at transmeta dot com --- Comment #5 from Steven Bosscher steven at gcc dot gnu.org --- *** Bug 29589 has been marked as a duplicate of this bug. ***
[Bug target/59605] [4.9 Regression] error: wrong number of branch edges after unconditional jump in bb 11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59605
--- Comment #3 from H.J. Lu hjl.tools at gmail dot com ---
Does this
---
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index 0cf0a9d..07f9a86 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -24015,7 +24015,8 @@ ix86_expand_set_or_movmem (rtx dst, rtx src, rtx
count_exp, rtx val_exp,
else
{
rtx hot_label = gen_label_rtx ();
- jump_around_label = gen_label_rtx ();
+ if (jump_around_label == NULL_RTX)
+jump_around_label = gen_label_rtx ();
emit_cmp_and_jump_insns (count_exp, GEN_INT (dynamic_check - 1),
LEU, 0, GET_MODE (count_exp), 1, hot_label);
predict_jump (REG_BR_PROB_BASE * 90 / 100);
---
make any senses?
[Bug c/35579] false negatives in warn_unused_result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35579 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||steven at gcc dot gnu.org Resolution|--- |WONTFIX --- Comment #10 from Steven Bosscher steven at gcc dot gnu.org --- But the false negatives cannot be fixed in the front end. And it's not the result of foo() that is unused: It's assigned to result. That result is unused is a different issue.
[Bug middle-end/38219] gcc.dg/tree-ssa/vrp47.c fails on powerpc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38219 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed|2011-02-16 18:44:32 |2013-12-27 --- Comment #16 from Steven Bosscher steven at gcc dot gnu.org --- http://gcc.gnu.org/ml/gcc-testresults/2013-12/msg02265.html
[Bug c/41624] RFE: -fno-nested-functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41624 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #2 from Steven Bosscher steven at gcc dot gnu.org --- Switching on/off individual language dialect features won't happen. (NB: I'd actually encourage anyone to use a strict non-gnu mode, for portability reasons.)
[Bug libgomp/42519] bootstrap fails on powerpc64-linux because of libgomp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42519 --- Comment #6 from Steven Bosscher steven at gcc dot gnu.org --- A serious candidate for WONTFIX... Laurent?
[Bug rtl-optimization/50180] insn does not satisfy constraints for 444.namd when generating profile data
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50180 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2013-12-26 Ever confirmed|0 |1 --- Comment #1 from Steven Bosscher steven at gcc dot gnu.org --- gcc 4.6 is no longer maintained. Is there still a bug here to fix?
[Bug target/50181] insn does not satisfy constraints for 481.wrf when generating profile data
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50181 --- Comment #2 from Steven Bosscher steven at gcc dot gnu.org --- gcc 4.6 is no longer maintained. Is there still a bug here to fix? (The testcase of comment #1 works for me with r206195 on ppc64-linux.)
[Bug tree-optimization/53804] branch reordering missed optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53804 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added Keywords||missed-optimization Target||powerpc*-*-* Status|UNCONFIRMED |NEW Last reconfirmed||2013-12-26 Ever confirmed|0 |1 Known to fail||4.7.0, 4.8.0, 4.9.0
[Bug target/59605] [4.9 Regression] error: wrong number of branch edges after unconditional jump in bb 11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59605 --- Comment #4 from H.J. Lu hjl.tools at gmail dot com --- A patch is posted at http://gcc.gnu.org/ml/gcc-patches/2013-12/msg01907.html
[Bug c++/59607] Internal compiler error: Error reporting routines re-entered.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59607 vyf at princeton dot edu changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from vyf at princeton dot edu --- There were bugs in my code: std::forward(args)... should have been std::forwardArgs(args)... new (get()) T(std::forwardArgs(args)...) should have been new (get()) optional(std::forwardArgs(args)...). I don't know why gcc had an error during compilation because of this (it should have just pointed out these problems), but everything works fine now that I fixed the bugs.
[Bug sanitizer/59600] no_sanitize_address mishandled when function is inlined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59600 --- Comment #8 from Yury Gribov y.gribov at samsung dot com --- Created attachment 31522 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31522action=edit Patch which inlines based on caller/callee attribute match (In reply to Yury Gribov from comment #7) And second you should compare the current function attribute to fndecl attribute. You mean compare caller's and callee's attributes? Makes a lot of sense but I don't think this info is available at the time function_attribute_inlinable_p is called: ... Perhaps this check should be moved to e.g. expand_call_inline? I'm giving this a try with this new patch. Does it look reasonable for you?
[Bug c/59609] New: LRA generates bad code for libgcc function udivmoddi4 on thumb1 target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59609 Bug ID: 59609 Summary: LRA generates bad code for libgcc function udivmoddi4 on thumb1 target Product: gcc Version: unknown Status: UNCONFIRMED Severity: blocker Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: terry.guo at arm dot com Created attachment 31523 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31523action=edit a reduced case Thumb-1 target like cortex-m0 hasn't hardware div instruction, thus the function __udivmoddi4 in libgcc is used. However this function is wrongly compiled by LRA which is enabled in recent gcc, codes that use __udivmoddi4 will get a wrong results. When print unsigned long long value using printf function, the printf function will use __udivmoddi4 and eventually will end up with dead loop. Attachment is a reduced case based on __udivmoddi4 function.And I am using the latest gcc trunk code. Compile the attached case with command: arm-none-eabi-gcc -mthumb -mcpu=cortex-m0 -O2 -S myudi.c then check the assembly code: sub r3, r3, #32 should initialize ip after this insn bpl .LCB31 b .L4 @long jump .LCB31: mov ip, r3 mov r3, r9 mov r2, ip lsl r3, r3, r2 mov r7, r3 .L5: mov r3, r9 lsl r3, r3, r1 mov r6, r3 cmp r7, r5 bhi .L20 beq .L29 .L22: mov r3, ip Here is the wrong code, the ip is uninitialized. sub r4, r4, r6 sbc r5, r5, r7 cmp r3, #0 bge .LCB50
[Bug target/59609] [4.9 Regression] LRA generates bad code for libgcc function udivmoddi4 on thumb1 target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59609 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Version|unknown |4.9.0 Target Milestone|--- |4.9.0
[Bug target/59609] [4.9 Regression] LRA generates bad code for libgcc function udivmoddi4 on thumb1 target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59609
--- Comment #1 from Terry Guo terry.guo at arm dot com ---
Here are some investigations. In the dump of IRA pass, we have jump insn like:
(jump_insn 31 24 172 5 (parallel [
(set (pc)
(if_then_else (lt (plus:SI (reg/v:SI 119 [ i ])
(const_int -32 [0xffe0]))
(const_int 0 [0]))
(label_ref 35)
(pc)))
(set (reg:SI 181)
(plus:SI (reg/v:SI 119 [ i ])
(const_int -32 [0xffe0])))
(clobber (scratch:SI))
]) myudi.c:13 225 {*addsi3_cbranch}
(int_list:REG_BR_PROB 2100 (nil))
- 35)
Next in the dump of reload pass, it is turned into:
(jump_insn 31 254 255 5 (parallel [
(set (pc)
(if_then_else (lt (plus:SI (reg:SI 3 r3 [181])
(const_int -32 [0xffe0]))
(const_int 0 [0]))
(label_ref 35)
(pc)))
(set (reg:SI 3 r3 [181])
(plus:SI (reg:SI 3 r3 [181])
(const_int -32 [0xffe0])))
(clobber (scratch:SI))
]) myudi.c:13 225 {*addsi3_cbranch}
(int_list:REG_BR_PROB 2100 (nil))
- 35)
(insn 255 31 172 5 (set (reg:SI 12 ip [181])
(reg:SI 3 r3 [181])) myudi.c:13 197 {*thumb1_movsi_insn}
(nil))
The subsequent passes will change the position of insn 255 and cause ip
uninitialized when do jump.
When disable LRA, in reload pass the jump_insn 31 will be turned into something
like:
(jump_insn 31 255 172 5 (parallel [
(set (pc)
(if_then_else (lt (plus:SI (reg:SI 0 r0)
(const_int -32 [0xffe0]))
(const_int 0 [0]))
(label_ref 35)
(pc)))
(set (reg:SI 12 ip [181])
(plus:SI (reg:SI 0 r0)
(const_int -32 [0xffe0])))
(clobber (reg:SI 0 r0))
]) myudi.c:13 225 {*addsi3_cbranch}
(int_list:REG_BR_PROB 2100 (nil))
- 35)
This is good and will produce correct code.
[Bug target/59609] [4.9 Regression] LRA generates bad code for libgcc function udivmoddi4 on thumb1 target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59609 --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org --- (In reply to Terry Guo from comment #1) Here are some investigations. In the dump of IRA pass, we have jump insn like: And this is why the old saying of reload not cannot reload a jump instruction comes true.
Re: [Patch, i386] PR 59422 - Support more targets for function multi versioning
On Thu, Dec 26, 2013 at 7:28 AM, Gopalasubramanian, Ganesh ganesh.gopalasubraman...@amd.com wrote: (get_amd_cpu): Handle AMD_BOBCAT, AMD_JAGUAR, AMDFAM15H_BDVER2 and AMDFAM15H_BDVER3. As mentioned earlier, we would like to stick with BTVER1 and BTVER2 instead of using BOBCAT or JAGUAR. Attached patch does the changes. OK. I'm sorry I didn't notice previous conversation. Please install ASAP. Thanks, Uros.
RE: [Patch, i386] PR 59422 - Support more targets for function multi versioning
I'm sorry I didn't notice previous conversation. Please install ASAP. Thanks Uros! Committed to revision 206210. - Ganesh
Re: [PATCH i386 4/8] [AVX512] [7/8] Add substed patterns: `round for expand' subst.
Hello Uros, On 23 Dec 17:46, Uros Bizjak wrote: This round_expand_predicate is the predicate substitution I was referred to in the review of 5/8. Please use it also in insn patterns, perhaps renamed as round_predicate This is drawback of substs. We bind given subst attribute to given subst strictly. So, this guy: +(define_subst_attr round_expand_predicate round_expand nonimmediate_operand register_operand) is binded to round_expand (second argument of definition) subst and to it only. That is way name is round_expand..., it reflects subst it relates to. For rest substs I'll introduce dedicated attributes. -- Thanks, K
Re: [Patch, i386] PR 59422 - Support more targets for function multi versioning
On Thursday 26 December 2013, Gopalasubramanian, Ganesh wrote: Hi, (get_amd_cpu): Handle AMD_BOBCAT, AMD_JAGUAR, AMDFAM15H_BDVER2 and AMDFAM15H_BDVER3. As mentioned earlier, we would like to stick with BTVER1 and BTVER2 instead of using BOBCAT or JAGUAR. Attached patch does the changes. Sorry for missing your comment. Thanks for fixing it. Renaming the comments with the AMD family names might be overdoing it though. `Allan
Re: PATCH: PR target/59588: Don't check/change generic/i686 tuning
Hi Honza, We have combined generic32 and generic64 into generic. There is no need to check generic anymore. Also we shouldn't change -mtune=i686 into -mtune=generic. OK to install? The i686-generic change was intended to get generic optimized code for i686-linux configuration rather than pentiumpro. I think it still makes sense to use this, since it is what most 32bit distros still configure for? Honza
Re: [PATCH i386 4/8] [AVX512] [5/8] Add substed patterns: rounding subst.
Hello,
On 23 Dec 17:26, Uros Bizjak wrote:
On Mon, Dec 23, 2013 at 5:11 PM, Uros Bizjak ubiz...@gmail.com wrote:
So, OK for mainline, but I would kindly ask you to please wait a
couple of days for possible Richard's comments
When substituting constraints, please also substitute corresponding
operand predicate:
nonimmediate_operand - register_operand in 1st and 3rd case
memory_operand - register_operand in 2nd case.
Thanks! I've introduced new subst attribute:
+(define_subst_attr round_nimm_predicate round nonimmediate_operand
register_operand)
which name reflect:
1. affilation to `round' subst (`round')
2. predicate it intended to affect (`nimm_predicate')
TESTING
1. Bootstrap pass.
2. make check shows no regressions.
3. Spec 2000 2006 build show no regressions both with and without -mavx512f
option.
4. Spec 2000 2006 run shows no regressions without -m512f option.
If no more inputs - I'll check it in after 24 hrs from now.
--
Thanks, K
---
gcc/config/i386/i386.c | 32
gcc/config/i386/i386.md | 10 +
gcc/config/i386/sse.md | 480 ---
gcc/config/i386/subst.md | 42 +
4 files changed, 331 insertions(+), 233 deletions(-)
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index ecf5e0b..a3dd307 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -15041,6 +15041,38 @@ ix86_print_operand (FILE *file, rtx x, int code)
fputs ({z}, file);
return;
+ case 'R':
+ gcc_assert (CONST_INT_P (x));
+
+ if (ASSEMBLER_DIALECT == ASM_INTEL)
+ fputs (, , file);
+
+ switch (INTVAL (x))
+ {
+ case ROUND_NEAREST_INT:
+ fputs ({rn-sae}, file);
+ break;
+ case ROUND_NEG_INF:
+ fputs ({rd-sae}, file);
+ break;
+ case ROUND_POS_INF:
+ fputs ({ru-sae}, file);
+ break;
+ case ROUND_ZERO:
+ fputs ({rz-sae}, file);
+ break;
+ case ROUND_SAE:
+ fputs ({sae}, file);
+ break;
+ default:
+ gcc_unreachable ();
+ }
+
+ if (ASSEMBLER_DIALECT == ASM_ATT)
+ fputs (, , file);
+
+ return;
+
case '*':
if (ASSEMBLER_DIALECT == ASM_ATT)
putc ('*', file);
diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
index ab5b33f..30b8d74 100644
--- a/gcc/config/i386/i386.md
+++ b/gcc/config/i386/i386.md
@@ -241,6 +241,16 @@
(ROUND_NO_EXC 0x8)
])
+;; Constants to represent AVX512F embeded rounding
+(define_constants
+ [(ROUND_NEAREST_INT 0)
+ (ROUND_NEG_INF 1)
+ (ROUND_POS_INF 2)
+ (ROUND_ZERO 3)
+ (NO_ROUND 4)
+ (ROUND_SAE 5)
+ ])
+
;; Constants to represent pcomtrue/pcomfalse variants
(define_constants
[(PCOM_FALSE 0)
diff --git a/gcc/config/i386/sse.md b/gcc/config/i386/sse.md
index adedf44..119d0b0 100644
--- a/gcc/config/i386/sse.md
+++ b/gcc/config/i386/sse.md
@@ -1229,23 +1229,23 @@
}
[(set_attr isa noavx,noavx,avx,avx)])
-(define_expand plusminus_insnmode3mask_name
+(define_expand plusminus_insnmode3mask_nameround_name
[(set (match_operand:VF 0 register_operand)
(plusminus:VF
- (match_operand:VF 1 nonimmediate_operand)
- (match_operand:VF 2 nonimmediate_operand)))]
- TARGET_SSE mask_mode512bit_condition
+ (match_operand:VF 1 round_nimm_predicate)
+ (match_operand:VF 2 round_nimm_predicate)))]
+ TARGET_SSE mask_mode512bit_condition round_mode512bit_condition
ix86_fixup_binary_operands_no_copy (CODE, MODEmode, operands);)
-(define_insn *plusminus_insnmode3mask_name
+(define_insn *plusminus_insnmode3mask_nameround_name
[(set (match_operand:VF 0 register_operand =x,v)
(plusminus:VF
- (match_operand:VF 1 nonimmediate_operand comm0,v)
- (match_operand:VF 2 nonimmediate_operand xm,vm)))]
- TARGET_SSE ix86_binary_operator_ok (CODE, MODEmode, operands)
mask_mode512bit_condition
+ (match_operand:VF 1 round_nimm_predicate comm0,v)
+ (match_operand:VF 2 round_nimm_predicate
xm,round_constraint)))]
+ TARGET_SSE ix86_binary_operator_ok (CODE, MODEmode, operands)
mask_mode512bit_condition round_mode512bit_condition
@
plusminus_mnemonicssemodesuffix\t{%2, %0|%0, %2}
- vplusminus_mnemonicssemodesuffix\t{%2, %1,
%0mask_operand3|%0mask_operand3, %1, %2}
+ vplusminus_mnemonicssemodesuffix\t{round_mask_op3%2, %1,
%0mask_operand3|%0mask_operand3, %1, %2round_mask_op3}
[(set_attr isa noavx,avx)
(set_attr type sseadd)
(set_attr prefix mask_prefix3)
@@ -1268,23 +1268,23 @@
(set_attr prefix orig,vex)
(set_attr mode ssescalarmode)])
-(define_expand mulmode3mask_name
+(define_expand
PATCH: PR target/59601: [4.9 Regression] __attribute__ ((target(arch=corei7))) won't match Westmere processor
Hi,
After my Intel processor name cleanup,
__attribute__ ((target(arch=corei7))) is translated to PROCESSOR_NEHALEM
mapped to M_INTEL_COREI7_NEHALEM. We used to hav
e __attribute__ ((target(arch=corei7)))
to cover M_INTEL_COREI7_. Now it only covers M_INTEL_COREI7_NEHALEM.
We have PROCESSOR_SANDYBRIDGE and PROCESSOR_HASWELL. But there is nothing
to mark Westmere and Ivy Bridge. Since function versioning doesn't support
extra ISAs in Westmere and Ivy Bridge, we don't lose anything. The solution
is to map
__attribute__ ((target(arch=corei7)))
and
__attribute__ ((target(arch=nehalem)))
to M_INTEL_COREI7. I tested mv14.C and mv15.C on Nehalem, Westmere,
Sandy Bride and Ivy Bridge. OK to install?
Thanks.
H.J.
gcc/
2013-12-26 H.J. Lu hongjiu...@intel.com
PR target/59601
* config/i386/i386.c (get_builtin_code_for_version): Map
PROCESSOR_NEHALEM to corei7.
gcc/testsuite/
2013-12-26 Uros Bizjak ubiz...@gmail.com
H.J. Lu hongjiu...@intel.com
PR target/59601
* g++.dg/ext/mv14.C: New tests.
* g++.dg/ext/mv15.C: Likewise.
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index 37bb656..e3d693a 100644
--- a/gcc/config/i386/i386.c
++ b/gcc/config/i386/i386.c
@@ -30010,7 +30010,10 @@ get_builtin_code_for_version (tree decl, tree
*predicate_list)
priority = P_PROC_SSSE3;
break;
case PROCESSOR_NEHALEM:
- arg_str = nehalem;
+ /* We translate arch=corei7 and arch=nehelam to
+corei7 so that it will be mapped to M_INTEL_COREI7
+as cpu type to cover all M_INTEL_COREI7_XXXs. */
+ arg_str = corei7;
priority = P_PROC_SSE4_2;
break;
case PROCESSOR_SANDYBRIDGE:
diff --git a/gcc/testsuite/g++.dg/ext/mv14.C b/gcc/testsuite/g++.dg/ext/mv14.C
new file mode 100644
index 000..e36e08d
--- /dev/null
+++ b/gcc/testsuite/g++.dg/ext/mv14.C
@@ -0,0 +1,40 @@
+/* Test case to check if Multiversioning works. */
+/* { dg-do run { target i?86-*-* x86_64-*-* } } */
+/* { dg-require-ifunc } */
+/* { dg-options -O2 -fPIC } */
+
+#include assert.h
+
+/* Default version. */
+int foo (); // Extra declaration that is merged with the second one.
+int foo () __attribute__ ((target(default)));
+
+int foo () __attribute__ ((target(arch=corei7)));
+
+int (*p)() = foo;
+int main ()
+{
+ int val = foo ();
+ assert (val == (*p)());
+
+ /* Check in the exact same order in which the dispatching
+ is expected to happen. */
+ if (__builtin_cpu_is (corei7))
+assert (val == 5);
+ else
+assert (val == 0);
+
+ return 0;
+}
+
+int __attribute__ ((target(default)))
+foo ()
+{
+ return 0;
+}
+
+int __attribute__ ((target(arch=corei7)))
+foo ()
+{
+ return 5;
+}
diff --git a/gcc/testsuite/g++.dg/ext/mv15.C b/gcc/testsuite/g++.dg/ext/mv15.C
new file mode 100644
index 000..42e39d2
--- /dev/null
+++ b/gcc/testsuite/g++.dg/ext/mv15.C
@@ -0,0 +1,40 @@
+/* Test case to check if Multiversioning works. */
+/* { dg-do run { target i?86-*-* x86_64-*-* } } */
+/* { dg-require-ifunc } */
+/* { dg-options -O2 -fPIC } */
+
+#include assert.h
+
+/* Default version. */
+int foo (); // Extra declaration that is merged with the second one.
+int foo () __attribute__ ((target(default)));
+
+int foo () __attribute__ ((target(arch=nehalem)));
+
+int (*p)() = foo;
+int main ()
+{
+ int val = foo ();
+ assert (val == (*p)());
+
+ /* Check in the exact same order in which the dispatching
+ is expected to happen. */
+ if (__builtin_cpu_is (corei7))
+assert (val == 5);
+ else
+assert (val == 0);
+
+ return 0;
+}
+
+int __attribute__ ((target(default)))
+foo ()
+{
+ return 0;
+}
+
+int __attribute__ ((target(arch=nehalem)))
+foo ()
+{
+ return 5;
+}
Re: [RFC][gomp4] Offloading: Add device initialization and host-target function mapping
Ping.
(Patch is slightly updated)
On 20 Dec 21:18, Ilya Verbin wrote:
Hi Jakub,
Could you please take a look at this patch for libgomp?
It adds new function GOMP_register_lib, that should be called from every
exec/lib with target regions (that was done in patch [1]). This function
maintains the array of pointers to the target shared library descriptors.
Also this patch adds target device initialization into GOMP_target and
GOMP_target_data. At first, it calls device_init function from the plugin.
This function takes array of target-images as input, and returns the array of
target-side addresses. Currently, it always uses the first target-image from
the descriptor, this should be generalized later. Then libgomp reads the
tables
from host-side exec/libs. After that, it inserts host-target address mapping
into the splay tree.
[1] http://gcc.gnu.org/ml/gcc-patches/2013-12/msg01486.html
Thanks,
-- Ilya
-- Ilya
---
libgomp/libgomp.map |1 +
libgomp/target.c| 154 ---
2 files changed, 146 insertions(+), 9 deletions(-)
diff --git a/libgomp/libgomp.map b/libgomp/libgomp.map
index 2b64d05..792047f 100644
--- a/libgomp/libgomp.map
+++ b/libgomp/libgomp.map
@@ -208,6 +208,7 @@ GOMP_3.0 {
GOMP_4.0 {
global:
+ GOMP_register_lib;
GOMP_barrier_cancel;
GOMP_cancel;
GOMP_cancellation_point;
diff --git a/libgomp/target.c b/libgomp/target.c
index d84a1fa..7677c28 100644
--- a/libgomp/target.c
+++ b/libgomp/target.c
@@ -84,6 +84,19 @@ struct splay_tree_key_s {
bool copy_from;
};
+enum library_descr {
+ DESCR_TABLE_START,
+ DESCR_TABLE_END,
+ DESCR_IMAGE_START,
+ DESCR_IMAGE_END
+};
+
+/* Array of pointers to target shared library descriptors. */
+static void **libraries;
+
+/* Total number of target shared libraries. */
+static int num_libraries;
+
/* Array of descriptors of all available devices. */
static struct gomp_device_descr *devices;
@@ -117,11 +130,16 @@ struct gomp_device_descr
TARGET construct. */
int id;
+ /* Set to true when device is initialized. */
+ bool is_initialized;
+
/* Plugin file handler. */
void *plugin_handle;
/* Function handlers. */
- bool (*device_available_func) (void);
+ bool (*device_available_func) (int);
+ void (*device_init_func) (void **, int *, int, void ***, int *);
+ void (*device_run_func) (void *, uintptr_t);
/* Splay tree containing information about mapped memory regions. */
struct splay_tree_s dev_splay_tree;
@@ -466,6 +484,89 @@ gomp_update (struct gomp_device_descr *devicep, size_t
mapnum,
gomp_mutex_unlock (devicep-dev_env_lock);
}
+void
+GOMP_register_lib (const void *openmp_target)
+{
+ libraries = realloc (libraries, (num_libraries + 1) * sizeof (void *));
+
+ if (libraries == NULL)
+return;
+
+ libraries[num_libraries] = (void *) openmp_target;
+
+ num_libraries++;
+}
+
+static void
+gomp_init_device (struct gomp_device_descr *devicep)
+{
+ void **target_images = malloc (num_libraries * sizeof (void *));
+ int *target_img_sizes = malloc (num_libraries * sizeof (int));
+ if (target_images == NULL || target_img_sizes == NULL)
+gomp_fatal (Can not allocate memory);
+
+ /* Collect target images from the library descriptors and calculate the total
+ size of host address table. */
+ int i, host_table_size = 0;
+ for (i = 0; i num_libraries; i++)
+{
+ void **lib = libraries[i];
+ void **host_table_start = lib[DESCR_TABLE_START];
+ void **host_table_end = lib[DESCR_TABLE_END];
+ /* FIXME: Select the proper target image. */
+ target_images[i] = lib[DESCR_IMAGE_START];
+ target_img_sizes[i] = lib[DESCR_IMAGE_END] - lib[DESCR_IMAGE_START];
+ host_table_size += host_table_end - host_table_start;
+}
+
+ /* Initialize the target device and receive the address table from target.
*/
+ void **target_table = NULL;
+ int target_table_size = 0;
+ devicep-device_init_func (target_images, target_img_sizes, num_libraries,
+target_table, target_table_size);
+ free (target_images);
+ free (target_img_sizes);
+
+ if (host_table_size != target_table_size)
+gomp_fatal (Can't map target objects);
+
+ /* Initialize the mapping data structure. */
+ void **target_entry = target_table;
+ for (i = 0; i num_libraries; i++)
+{
+ void **lib = libraries[i];
+ void **host_table_start = lib[DESCR_TABLE_START];
+ void **host_table_end = lib[DESCR_TABLE_END];
+ void **host_entry;
+ for (host_entry = host_table_start; host_entry host_table_end;
+ host_entry += 2, target_entry += 2)
+ {
+ struct target_mem_desc *tgt = gomp_malloc (sizeof (*tgt));
+ tgt-refcount = 1;
+ tgt-array = gomp_malloc (sizeof (*tgt-array));
+ tgt-tgt_start = (uintptr_t) *target_entry;
+ tgt-tgt_end = tgt-tgt_start + *((uint64_t *) target_entry + 1);
+
Re: PATCH: PR target/59588: Don't check/change generic/i686 tuning
On Thu, Dec 26, 2013 at 4:38 AM, Jan Hubicka hubi...@ucw.cz wrote: Hi Honza, We have combined generic32 and generic64 into generic. There is no need to check generic anymore. Also we shouldn't change -mtune=i686 into -mtune=generic. OK to install? The i686-generic change was intended to get generic optimized code for i686-linux configuration rather than pentiumpro. I think it still makes sense to use this, since it is what most 32bit distros still configure for? Should -mtune=i686 define __tune_i686__? If not, how can it be defined? Don't we default -mtune to generic for i686-linux? -- H.J.
Re: PATCH: PR target/59601: [4.9 Regression] __attribute__ ((target(arch=corei7))) won't match Westmere processor
On Thu, Dec 26, 2013 at 2:25 PM, H.J. Lu hongjiu...@intel.com wrote: After my Intel processor name cleanup, __attribute__ ((target(arch=corei7))) is translated to PROCESSOR_NEHALEM mapped to M_INTEL_COREI7_NEHALEM. We used to hav e __attribute__ ((target(arch=corei7))) to cover M_INTEL_COREI7_. Now it only covers M_INTEL_COREI7_NEHALEM. We have PROCESSOR_SANDYBRIDGE and PROCESSOR_HASWELL. But there is nothing to mark Westmere and Ivy Bridge. Since function versioning doesn't support extra ISAs in Westmere and Ivy Bridge, we don't lose anything. The solution is to map __attribute__ ((target(arch=corei7))) and __attribute__ ((target(arch=nehalem))) to M_INTEL_COREI7. I tested mv14.C and mv15.C on Nehalem, Westmere, Sandy Bride and Ivy Bridge. OK to install? gcc/ 2013-12-26 H.J. Lu hongjiu...@intel.com PR target/59601 * config/i386/i386.c (get_builtin_code_for_version): Map PROCESSOR_NEHALEM to corei7. gcc/testsuite/ 2013-12-26 Uros Bizjak ubiz...@gmail.com H.J. Lu hongjiu...@intel.com PR target/59601 * g++.dg/ext/mv14.C: New tests. * g++.dg/ext/mv15.C: Likewise. OK. Thanks, Uros.
[PATCH, i386]: Use vendor signatures from cpuid.h in cpuinfo.c
Hello!
Use the same definitions from common header.
2013-12-26 Uros Bizjak ubiz...@gmail.com
* config/i386/cpuinfo.c (enum vendor_signatures): Remove.
(__cpu_indicator_init): Use signature_INTEL_ebx and signature_AMD_ebx
from cpuid.h to check vendor signatures.
No functional changes.
Bootstrapped on x86_64-pc-linux-gnu and committed to mainline SVN.
Uros.
Index: config/i386/cpuinfo.c
===
--- config/i386/cpuinfo.c (revision 206210)
+++ config/i386/cpuinfo.c (working copy)
@@ -36,12 +36,6 @@ see the files COPYING3 and COPYING.RUNTIME respect
int __cpu_indicator_init (void)
__attribute__ ((constructor CONSTRUCTOR_PRIORITY));
-enum vendor_signatures
-{
- SIG_INTEL = 0x756e6547 /* Genu */,
- SIG_AMD =0x68747541 /* Auth */
-};
-
/* Processor Vendor and Models. */
enum processor_vendor
@@ -368,7 +362,7 @@ __cpu_indicator_init (void)
extended_model = (eax 12) 0xf0;
extended_family = (eax 20) 0xff;
- if (vendor == SIG_INTEL)
+ if (vendor == signature_INTEL_ebx)
{
/* Adjust model and family for Intel CPUS. */
if (family == 0x0f)
@@ -385,7 +379,7 @@ __cpu_indicator_init (void)
get_available_features (ecx, edx, max_level);
__cpu_model.__cpu_vendor = VENDOR_INTEL;
}
- else if (vendor == SIG_AMD)
+ else if (vendor == signature_AMD_ebx)
{
/* Adjust model and family for AMD CPUS. */
if (family == 0x0f)
Re: PATCH: PR target/59588: Don't check/change generic/i686 tuning
On Thu, Dec 26, 2013 at 4:38 AM, Jan Hubicka hubi...@ucw.cz wrote: Hi Honza, We have combined generic32 and generic64 into generic. There is no need to check generic anymore. Also we shouldn't change -mtune=i686 into -mtune=generic. OK to install? The i686-generic change was intended to get generic optimized code for i686-linux configuration rather than pentiumpro. I think it still makes sense to use this, since it is what most 32bit distros still configure for? Should -mtune=i686 define __tune_i686__? If not, how can it be defined? Don't we default -mtune to generic for i686-linux? If i686-linux defaults to -mtune=generic, then I think it is all fine. i686 is bit misbehaved since it was used as both CPU name for PPro (that does not make much sense) and for the overall architecture... Honza -- H.J.
Re: PATCH: PR target/59588: Don't check/change generic/i686 tuning
On Thu, Dec 26, 2013 at 7:45 AM, Jan Hubicka hubi...@ucw.cz wrote: On Thu, Dec 26, 2013 at 4:38 AM, Jan Hubicka hubi...@ucw.cz wrote: Hi Honza, We have combined generic32 and generic64 into generic. There is no need to check generic anymore. Also we shouldn't change -mtune=i686 into -mtune=generic. OK to install? The i686-generic change was intended to get generic optimized code for i686-linux configuration rather than pentiumpro. I think it still makes sense to use this, since it is what most 32bit distros still configure for? Should -mtune=i686 define __tune_i686__? If not, how can it be defined? Don't we default -mtune to generic for i686-linux? If i686-linux defaults to -mtune=generic, then I think it is all fine. We have defaulted [hjl@gnu-6 gcc]$ ./xgcc -B./ -S /tmp/x.i -v Reading specs from ./specs COLLECT_GCC=./xgcc Target: i686-linux Configured with: /export/gnu/import/git/gcc/configure --enable-languages=c,c++ --disable-bootstrap i686-linux --prefix=/usr/gcc-4.9.0 --with-local-prefix=/usr/local --enable-targets=all --with-fpmath=sse : (reconfigured) /export/gnu/import/git/gcc/configure --enable-languages=c,c++ --disable-bootstrap i686-linux --prefix=/usr/gcc-4.9.0 --with-local-prefix=/usr/local --enable-targets=all --with-fpmath=sse Thread model: posix gcc version 4.9.0 20131224 (experimental) (GCC) COLLECT_GCC_OPTIONS='-B' './' '-S' '-v' '-mtune=generic' '-march=pentium4' ./cc1 -fpreprocessed /tmp/x.i -quiet -dumpbase x.i -mtune=generic -march=pentium4 -auxbase x -version -o x.s GNU C (GCC) version 4.9.0 20131224 (experimental) (i686-linux) compiled by GNU C version 4.8.2 20131212 (Red Hat 4.8.2-7), GMP version 5.1.1, MPFR version 3.1.1, MPC version 1.0.1 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 GNU C (GCC) version 4.9.0 20131224 (experimental) (i686-linux) compiled by GNU C version 4.8.2 20131212 (Red Hat 4.8.2-7), GMP version 5.1.1, MPFR version 3.1.1, MPC version 1.0.1 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: 8d0a04c49875a54ef44488e5406c52dd COMPILER_PATH=./ LIBRARY_PATH=./:/lib/../lib/:/usr/lib/../lib/:/lib/:/usr/lib/ COLLECT_GCC_OPTIONS='-B' './' '-S' '-v' '-mtune=generic' '-march=pentium4' [hjl@gnu-6 gcc]$ I will check in my patch. i686 is bit misbehaved since it was used as both CPU name for PPro (that does not make much sense) and for the overall architecture... Thanks. -- H.J.
Re: PATCH: PR target/59587: cpu_names in i386.c is accessed with wrong index
On Wed, Dec 25, 2013 at 12:49 PM, Uros Bizjak ubiz...@gmail.com wrote: TARGET_CPU_DEFAULT is left over for 32-bit target before --with-arch= and --with-cpu= were added. Today, -mtune=xxx -march=xxx are always passed to cc1 by GCC driver. If cc1 is run by hand and -mtune=xxx -march=xxx aren't passed to cc1, we should do 1. For 64-bit, it should be the same as -mtune=generic -march=x86_64 are passed. 2. For 32-bit, it should be the same as -mtune=cpu -march=cpu are passed, where cpu is the target cpu used to configure GCC, like i386 in i386-linux, i486 in i486-linux, But there is no i786 cpu. i786 is treated as i686. If SUBTARGET32_DEFAULT_CPU is defined, it should be the same -mtune=SUBTARGET32_DEFAULT_CPU -march=SUBTARGET32_DEFAULT_CPU. Here is the patch to implement this. Let's do one step at a time. So, let's split the patch back to target/59587 fix: I am not formally submitting the patch to define target_cpu_default for i[34567]86 targets: http://gcc.gnu.org/git/?p=gcc.git;a=patch;h=c5d2157c8c9181286441317cf55570d8e33741c2 since it has no impact on x86-64 nor when GCC driver is used. It only changes the default arch/tune when cc1/cc1plus is run by hand, which is very unusual. I will leave the patch on hjl/arch branch just in case someone is interested. Thanks. -- H.J.
Re: PATCH: PR target/59588: Don't check/change generic/i686 tuning
On Thu, Dec 26, 2013 at 8:06 AM, H.J. Lu hjl.to...@gmail.com wrote:
On Thu, Dec 26, 2013 at 7:45 AM, Jan Hubicka hubi...@ucw.cz wrote:
On Thu, Dec 26, 2013 at 4:38 AM, Jan Hubicka hubi...@ucw.cz wrote:
Hi Honza,
We have combined generic32 and generic64 into generic. There is no need
to check generic anymore. Also we shouldn't change -mtune=i686 into
-mtune=generic. OK to install?
The i686-generic change was intended to get generic optimized code
for i686-linux configuration rather than pentiumpro. I think it still
makes
sense to use this, since it is what most 32bit distros still configure
for?
Should -mtune=i686 define __tune_i686__? If not, how can
it be defined? Don't we default -mtune to generic for
i686-linux?
If i686-linux defaults to -mtune=generic, then I think it is all fine.
...
I will check in my patch.
My patch exposes a testsuite bug:
spawn -ignore SIGHUP /export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/
/export/gnu/import/git/gcc/gcc/testsuite/gcc.target/i386/andor-2.c
-fno-diagnostics-show-caret -fdiagnostics-color=never -O2 -mtune=i686
-ffat-lto-objects -ffat-lto-objects -S -o andor-2.s^M
/export/gnu/import/git/gcc/gcc/testsuite/gcc.target/i386/andor-2.c:1:0:
error: CPU you selected does not support x86-64 instruction set^M
compiler exited with status 1
output is:
/export/gnu/import/git/gcc/gcc/testsuite/gcc.target/i386/andor-2.c:1:0:
error: CPU you selected does not support x86-64 instruction set^M
FAIL: gcc.target/i386/andor-2.c (test for excess errors)
We used to silently turn -mtune=i686 into -mtune=generic.
Now we don't. It is wrong to accept -mtune=i686 when compiling
for x86-64. I am checking in this patch as an obvious fix.
Thanks.
--
H.J.
--
diff --git a/gcc/testsuite/gcc.target/i386/andor-2.c
b/gcc/testsuite/gcc.target/i386/andor-2.c
index 88118aa..eacc7b1 100644
--- a/gcc/testsuite/gcc.target/i386/andor-2.c
+++ b/gcc/testsuite/gcc.target/i386/andor-2.c
@@ -1,5 +1,5 @@
/* { dg-do compile } */
-/* { dg-options -O2 -mtune=i686 } */
+/* { dg-options -O2 -mtune=generic } */
int h(int x, int y)
{
Re: New prologue/epilogue code for i386 string functions
On Tue, Oct 22, 2013 at 8:58 AM, Jan Hubicka hubi...@ucw.cz wrote: Hi, this patch adds code to produce prologues/epilogues as suggested by Ondrej Bilka (I described more the approach in http://gcc.gnu.org/ml/gcc-patches/2013-09/msg02082.html) This patch is updated and cleaned up version after Mikhail changes merging memset/memcpy generation code. (I will continue with some incremental cleanups for the code dulication we ended up with). For now I don't have value range code in, but all logic is in place once http://gcc.gnu.org/ml/gcc-patches/2013-09/msg02011.html gets reviewed. Bootstrapped/regtesed x86_64-linux also with -minline-all-stringops and tested on SPEC2k6. I will commit it later today after more testing. Honza * i386.h (TARGET_MISALIGNED_MOVE_STRING_PROLOGUES_EPILOGUES): New tuning flag. * x86-tune.def (TARGET_MISALIGNED_MOVE_STRING_PROLOGUES): Define it. * i386.c (expand_small_movmem_or_setmem): New function. (expand_set_or_movmem_prologue_epilogue_by_misaligned_moves): New function (alg_usable_p): Add support for value ranges; cleanup. (ix86_expand_set_or_movmem): Add support for misaligned moves. This caused: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59605 -- H.J.
Re: PATCH: PR target/59588: Don't check/change generic/i686 tuning
On Thu, Dec 26, 2013 at 11:11 AM, H.J. Lu hjl.to...@gmail.com wrote:
On Thu, Dec 26, 2013 at 8:06 AM, H.J. Lu hjl.to...@gmail.com wrote:
On Thu, Dec 26, 2013 at 7:45 AM, Jan Hubicka hubi...@ucw.cz wrote:
On Thu, Dec 26, 2013 at 4:38 AM, Jan Hubicka hubi...@ucw.cz wrote:
Hi Honza,
We have combined generic32 and generic64 into generic. There is no need
to check generic anymore. Also we shouldn't change -mtune=i686 into
-mtune=generic. OK to install?
The i686-generic change was intended to get generic optimized code
for i686-linux configuration rather than pentiumpro. I think it still
makes
sense to use this, since it is what most 32bit distros still configure
for?
Should -mtune=i686 define __tune_i686__? If not, how can
it be defined? Don't we default -mtune to generic for
i686-linux?
If i686-linux defaults to -mtune=generic, then I think it is all fine.
...
I will check in my patch.
My patch exposes a testsuite bug:
spawn -ignore SIGHUP /export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/
/export/gnu/import/git/gcc/gcc/testsuite/gcc.target/i386/andor-2.c
-fno-diagnostics-show-caret -fdiagnostics-color=never -O2 -mtune=i686
-ffat-lto-objects -ffat-lto-objects -S -o andor-2.s^M
/export/gnu/import/git/gcc/gcc/testsuite/gcc.target/i386/andor-2.c:1:0:
error: CPU you selected does not support x86-64 instruction set^M
compiler exited with status 1
output is:
/export/gnu/import/git/gcc/gcc/testsuite/gcc.target/i386/andor-2.c:1:0:
error: CPU you selected does not support x86-64 instruction set^M
FAIL: gcc.target/i386/andor-2.c (test for excess errors)
We used to silently turn -mtune=i686 into -mtune=generic.
Now we don't. It is wrong to accept -mtune=i686 when compiling
for x86-64. I am checking in this patch as an obvious fix.
Thanks.
--
H.J.
--
diff --git a/gcc/testsuite/gcc.target/i386/andor-2.c
b/gcc/testsuite/gcc.target/i386/andor-2.c
index 88118aa..eacc7b1 100644
--- a/gcc/testsuite/gcc.target/i386/andor-2.c
+++ b/gcc/testsuite/gcc.target/i386/andor-2.c
@@ -1,5 +1,5 @@
/* { dg-do compile } */
-/* { dg-options -O2 -mtune=i686 } */
+/* { dg-options -O2 -mtune=generic } */
int h(int x, int y)
{
Another one happens with -mx32. I checked in
this patch to fix it.
--
H.J.
---
diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
index 98d22b3e..ad98f63 100644
--- a/gcc/testsuite/ChangeLog
+++ b/gcc/testsuite/ChangeLog
@@ -1,5 +1,11 @@
2013-12-26 H.J. Lu hongjiu...@intel.com
+ * g++.old-deja/g++.other/store-expr1.C (dg-options): Replace
+ -mtune=i686 with -mtune=generic.
+ * g++.old-deja/g++.other/store-expr2.C (dg-options): Likewise.
+
+2013-12-26 H.J. Lu hongjiu...@intel.com
+
* gcc.target/i386/andor-2.c (dg-options): Replace -mtune=i686
with -mtune=generic.
diff --git a/gcc/testsuite/g++.old-deja/g++.other/store-expr1.C
b/gcc/testsuite/g++.old-deja/g++.other/store-expr1.C
index 72d30eb..af5e415 100644
--- a/gcc/testsuite/g++.old-deja/g++.other/store-expr1.C
+++ b/gcc/testsuite/g++.old-deja/g++.other/store-expr1.C
@@ -1,7 +1,7 @@
// { dg-do run { target i?86-*-* x86_64-*-* } }
// { dg-require-effective-target ilp32 }
// { dg-require-effective-target fpic }
-// { dg-options -mtune=i686 -O2 -fpic }
+// { dg-options -mtune=generic -O2 -fpic }
class G {};
struct N {
diff --git a/gcc/testsuite/g++.old-deja/g++.other/store-expr2.C
b/gcc/testsuite/g++.old-deja/g++.other/store-expr2.C
index 99e0943..1dffbcc 100644
--- a/gcc/testsuite/g++.old-deja/g++.other/store-expr2.C
+++ b/gcc/testsuite/g++.old-deja/g++.other/store-expr2.C
@@ -1,6 +1,6 @@
// { dg-do run { target i?86-*-* x86_64-*-*} }
// { dg-require-effective-target ilp32 }
-// { dg-options -mtune=i686 -O2 }
+// { dg-options -mtune=generic -O2 }
class G {};
struct N {
Re: [patch] powerpc64 FreeBSD support for boehm-gc
On 12/26/2013 12:11 AM, Andreas Tobler wrote: On 21.12.13 18:27, Andrew Haley wrote: On 12/20/2013 10:15 PM, Andreas Tobler wrote: Ok for gcc trunk? OK, thanks. May I get this one down to 4.8 too? Not really needed, but for completeness. Results will follow... No objections from me. Andrew.
PATCH: PR target/59605: Create jump_around_label only if it doesn't exist
Hi Honza,
r203937 may create jump_around_label earlier. But later code doesn't
check if jump_around_label exists. This patch fixes it. Tested
on Linux/x86-64. OK to install?
Thanks.
H.J.
--
gcc/
2013-12-26 H.J. Lu hongjiu...@intel.com
PR target/59605
* config/i386/i386.c (ix86_expand_set_or_movmem): Create
jump_around_label only if it doesn't exist.
gcc/testsuite/
2013-12-26 H.J. Lu hongjiu...@intel.com
PR target/59605
* gcc.dg/pr59605.c: New test.
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index 0cf0a9d..07f9a86 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -24015,7 +24015,8 @@ ix86_expand_set_or_movmem (rtx dst, rtx src, rtx
count_exp, rtx val_exp,
else
{
rtx hot_label = gen_label_rtx ();
- jump_around_label = gen_label_rtx ();
+ if (jump_around_label == NULL_RTX)
+ jump_around_label = gen_label_rtx ();
emit_cmp_and_jump_insns (count_exp, GEN_INT (dynamic_check - 1),
LEU, 0, GET_MODE (count_exp), 1, hot_label);
predict_jump (REG_BR_PROB_BASE * 90 / 100);
diff --git a/gcc/testsuite/gcc.dg/pr59605.c b/gcc/testsuite/gcc.dg/pr59605.c
new file mode 100644
index 000..4556843
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr59605.c
@@ -0,0 +1,55 @@
+/* { dg-do run } */
+/* { dg-options -O2 } */
+/* { dg-additional-options -minline-stringops-dynamically { target {
i?86-*-* x86_64-*-* } } } */
+
+extern void abort (void);
+
+#define MAX_OFFSET (sizeof (long long))
+#define MAX_COPY (1024 + 8192)
+#define MAX_EXTRA (sizeof (long long))
+
+#define MAX_LENGTH (MAX_OFFSET + MAX_COPY + MAX_EXTRA)
+
+static union {
+ char buf[MAX_LENGTH];
+ long long align_int;
+ long double align_fp;
+} u;
+
+char A[MAX_LENGTH];
+
+int
+main ()
+{
+ int off, len, i;
+ char *p, *q;
+
+ for (i = 0; i MAX_LENGTH; i++)
+A[i] = 'A';
+
+ for (off = 0; off MAX_OFFSET; off++)
+for (len = 1; len MAX_COPY; len++)
+ {
+ for (i = 0; i MAX_LENGTH; i++)
+ u.buf[i] = 'a';
+
+ p = __builtin_memcpy (u.buf + off, A, len);
+ if (p != u.buf + off)
+ abort ();
+
+ q = u.buf;
+ for (i = 0; i off; i++, q++)
+ if (*q != 'a')
+ abort ();
+
+ for (i = 0; i len; i++, q++)
+ if (*q != 'A')
+ abort ();
+
+ for (i = 0; i MAX_EXTRA; i++, q++)
+ if (*q != 'a')
+ abort ();
+ }
+
+ return 0;
+}
Re: [PATCH][x86] march aliases
On Mon, 23 Dec 2013 05:10:06 -0800 H.J. Lu hjl.to...@gmail.com wrote: This is the patch I checked in. I will submit separate patches for other parts. Please be sure to update changes.html. -- Ryan Hillpsn: dirtyepic_sk gcc-porting/toolchain/wxwidgets @ gentoo.org 47C3 6D62 4864 0E49 8E9E 7F92 ED38 BD49 957A 8463 signature.asc Description: PGP signature
Re: [Patch] PR55189 enable -Wreturn-type by default
2013/12/21 Sylvestre Ledru sylves...@debian.org: Hello Following this thread http://gcc.gnu.org/ml/gcc/2013-11/msg00260.html and this bug, http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55189 I would like to propose the two following patches: I am activating -Wreturn-type by defaut and add the option -Wmissing-return [snip] Index: gcc/ChangeLog === --- gcc/ChangeLog (révision 206154) +++ gcc/ChangeLog (copie de travail) @@ -1,3 +1,11 @@ +2013-12-20 Sylvestre Ledru sylves...@debian.org + +PR target/55189 +* -Wreturn-type enabled by default. + * Introduce back the option -Wmissing-return (enabled by -Wall) + It was included by default with -Wreturn-type + * Update all tests failing because of these changes. + 2013-12-20 Eric Botcazou ebotca...@adacore.com * config/arm/arm.c (arm_expand_prologue): In a nested APCS frame with Hi, Sylvestre, Sorry I have no right to approve this patch. But I notice your ChangeLog formatting is not correct. You can refer to other entries in ChangeLog to refine yours, and then resubmit the patch for review. :) Best regards, jasonwucj
Re: [Patch] PR55189 enable -Wreturn-type by default
Chung-Wu wrote: But I notice your ChangeLog formatting is not correct. You can refer to other entries in ChangeLog to refine yours, and then resubmit the patch for review. :) Or - use contrib/mklog to autogenerate template ChangeLog for you. -Y
