[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.
