[Bug fortran/51514] [OOP] Wrong code when passing a scalar CLASS to a TYPE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51514 --- Comment #6 from Tobias Burnus burnus at gcc dot gnu.org 2012-02-07 08:15:28 UTC --- Author: burnus Date: Tue Feb 7 08:15:14 2012 New Revision: 183954 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=183954 Log: 2012-02-07 Tobias Burnus bur...@net-b.de PR fortran/51514 * trans-expr.c (gfc_conv_procedure_call): Add _data component for calls of scalar CLASS actuals to TYPE dummies. 2012-02-07 Tobias Burnus bur...@net-b.de PR fortran/51514 * gfortran.dg/class_to_type_2.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/class_to_type_2.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/51514] [OOP] Wrong code when passing a scalar CLASS to a TYPE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51514 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #7 from Tobias Burnus burnus at gcc dot gnu.org 2012-02-07 08:16:24 UTC --- FIXED on the trunk (4.7).
[Bug rtl-optimization/52060] [4.7 regression] Invalid constant simplification in combine with parallel result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52060
--- Comment #7 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-02-07
08:46:39 UTC ---
I think the important question is if it is ok that combine_simplify_rtx may
modify the given rtl in place, as opposed to keeping it unmodified and just
allocating new rtx and returning it. A brief look at combine.c suggests that
SUBST () is used in so many places that it is meant to be ok to modify it in
place.
Then we for added_sets_{1,2} should just make copies of i1src resp. i0src
upfront, which means perhaps slightly bigger amount of GC, but at least it
won't miscompile things.
I'm a little uncomfortable with the patch, because I think it's annoying to
have to copy a pattern that you're going to substitute for. On the other hand,
given that combine_simplify_rtx is allowed to SUBST, that's the most reasonable
fix.
Why do you need 2 copies of I0SRC though?
[Bug c/52146] New: [x32] - Wrong code to access addresses 0x80000000 to 0xFFFFFFFF
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52146 Bug #: 52146 Summary: [x32] - Wrong code to access addresses 0x8000 to 0x Classification: Unclassified Product: gcc Version: 4.6.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: steffen-schm...@siemens.com Created attachment 26596 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26596 C code resulting in wrong instructions when compiled with -mx32 and O1 or higher When accessing memory addresses in the region 0x8000 to 0x starting from optimization -O1 or higher -mx32 GCC seems to generate faulty assembler instructions. Using -mx32 GCC will generate code for x86_64 target but using 4 byte pointers (instead of 8 byte pointers when using -m64). Nonetheless we're running on a x86_64 64bit machine. The example shows the problem: typedef unsigned int uint32_t; volatile uint32_t * apic_tpr_addr = (uint32_t*)0xfee00080; *apic_tpr_addr = 0; GCC -mx32 generates the following assembler instructions: movl$0, -18874240 On on x86 32bit system, this instruction would be correct, movl uses signed addresses as destination when directly accessing memory. On an x86_64 system, on the other hand, this instruction does not refer to address 0xFEE00080, but to 0xFEE00080, because the signed address is interpreted in 64bit by the processor, which leads to an error. GCC -m64 generates the correct instructions: xorl%eax, %eax movabsl%eax, 4276093056 It seems to be necessary to use movabsl instruction instead of movl. The problem does not occur by forcing access to memory via a register: volatile uintptr_t ptr = 0xfee00080; volatile uint32_t * apic_tpr_addr = (uint32_t*)ptr; *apic_tpr_addr = 0; In this case -mx32 GCC generates the follwoing code: movl$-18874240, -4(%esp) movl-4(%esp), %eax movl$0, (%eax) Here the access to memory is correct, using 32bit register eax Code generated by -m64 GCC looks similar, but using 64bit addresses and registers. movl$4276093056, %eax movq%rax, -8(%rsp) movq-8(%rsp), %rax movl$0, (%rax)
[Bug c/52146] [x32] - Wrong code to access addresses 0x80000000 to 0xFFFFFFFF
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52146 --- Comment #1 from Steffen Schmidt steffen-schmidt at siemens dot com 2012-02-07 08:58:00 UTC --- Created attachment 26597 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26597 Generated -mx32 assembler
[Bug c/52146] [x32] - Wrong code to access addresses 0x80000000 to 0xFFFFFFFF
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52146 --- Comment #2 from Steffen Schmidt steffen-schmidt at siemens dot com 2012-02-07 08:58:30 UTC --- Created attachment 26598 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26598 Generate -m64 assembler
[Bug rtl-optimization/52060] [4.6/4.7 Regression] Invalid constant simplification in combine with parallel result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52060 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2 Target Milestone|--- |4.6.4 Summary|[4.7 regression] Invalid|[4.6/4.7 Regression] |constant simplification in |Invalid constant |combine with parallel |simplification in combine |result |with parallel result --- Comment #8 from Richard Guenther rguenth at gcc dot gnu.org 2012-02-07 09:18:21 UTC --- Reported for version 4.6.x so it must be a 4.6/4.7 regression. And thus P2 only.
[Bug libstdc++/51296] Several 30_threads tests FAIL on Tru64 UNIX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51296 --- Comment #36 from Jonathan Wakely redi at gcc dot gnu.org 2012-02-07 09:19:35 UTC --- Author: redi Date: Tue Feb 7 09:19:27 2012 New Revision: 183955 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=183955 Log: libgcc/ PR libstdc++/51296 PR libstdc++/51906 * gthr-posix.h: Allow static initializer macros to be disabled. (__gthrw_pthread_cond_init): Define weak reference unconditionally. libstdc++-v3/ PR libstdc++/51296 * include/std/mutex (__mutex_base::~__mutex_base): Declare noexcept. * src/c++11/condition_variable.cc (condition_variable): Use macro for initializer function. PR libstdc++/51906 * config/os/bsd/darwin/os_defines.h: Disable static initializer for recursive mutexes. Modified: trunk/libgcc/ChangeLog trunk/libgcc/gthr-posix.h trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/config/os/bsd/darwin/os_defines.h trunk/libstdc++-v3/include/std/mutex trunk/libstdc++-v3/src/c++11/condition_variable.cc
[Bug libstdc++/51906] thread lock test failures on darwin11 under Xcode 4.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51906 --- Comment #54 from Jonathan Wakely redi at gcc dot gnu.org 2012-02-07 09:19:35 UTC --- Author: redi Date: Tue Feb 7 09:19:27 2012 New Revision: 183955 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=183955 Log: libgcc/ PR libstdc++/51296 PR libstdc++/51906 * gthr-posix.h: Allow static initializer macros to be disabled. (__gthrw_pthread_cond_init): Define weak reference unconditionally. libstdc++-v3/ PR libstdc++/51296 * include/std/mutex (__mutex_base::~__mutex_base): Declare noexcept. * src/c++11/condition_variable.cc (condition_variable): Use macro for initializer function. PR libstdc++/51906 * config/os/bsd/darwin/os_defines.h: Disable static initializer for recursive mutexes. Modified: trunk/libgcc/ChangeLog trunk/libgcc/gthr-posix.h trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/config/os/bsd/darwin/os_defines.h trunk/libstdc++-v3/include/std/mutex trunk/libstdc++-v3/src/c++11/condition_variable.cc
[Bug rtl-optimization/52060] [4.6/4.7 Regression] Invalid constant simplification in combine with parallel result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52060 --- Comment #9 from Jakub Jelinek jakub at gcc dot gnu.org 2012-02-07 09:21:34 UTC --- (In reply to comment #7) I'm a little uncomfortable with the patch, because I think it's annoying to have to copy a pattern that you're going to substitute for. On the other hand, given that combine_simplify_rtx is allowed to SUBST, that's the most reasonable fix. Yeah, I'm also not very happy about it, but we do other copy_rtx calls (e.g. for i0pat/i1pat/i2pat), for the same reason. Why do you need 2 copies of I0SRC though? Because it might be substed twice, once into i1pat (which might clobber it with random changes) and then again into i2pat, if both i1dest and i2dest are needed after the pattern. With the two separate variables we copy_rtx it only when we are actually going to use them in subst. Other alternative would be to create just one copy (i0src_copy) upfront if ((added_sets_1 i0_feeds_i1_n) || (added_sets_2 ((i0_feeds_i1_n i1_feeds_i2_n) || (i0_feeds_i2_n and then right before we subst it into i1pat check the second half of the condition again and if it is true, copy it again, but that would be IMHO uglier than this.
[Bug libstdc++/51906] thread lock test failures on darwin11 under Xcode 4.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51906 --- Comment #55 from Jonathan Wakely redi at gcc dot gnu.org 2012-02-07 09:21:13 UTC --- this should be fixed now - I won't close it until someone can verify it on darwin
[Bug libstdc++/51296] Several 30_threads tests FAIL on Tru64 UNIX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51296 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added AssignedTo|redi at gcc dot gnu.org |ro at gcc dot gnu.org --- Comment #37 from Jonathan Wakely redi at gcc dot gnu.org 2012-02-07 09:22:29 UTC --- Rainer, you should now be able to define _GTHREAD_USE_MUTEX_INIT_FUNC and _GTHREAD_USE_COND_INIT_FUNC (either in gthr-posix.h or os_defines.h or wherever you see fit) and then the tests should pass.
[Bug middle-end/52074] ICE: RTL flag check: MEM_VOLATILE_P used with unexpected rtx code 'plus' in extract_fixed_bit_field, at expmed.c:1734
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52074 --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2012-02-07 09:22:55 UTC --- Author: jakub Date: Tue Feb 7 09:22:51 2012 New Revision: 183956 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=183956 Log: PR middle-end/52074 * expr.c (expand_expr_addr_expr_1): For CONSTANT_CLASS_P or CONST_DECL if modifier EXPAND_SUM call force_operand on the result. * gcc.c-torture/compile/pr52074.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr52074.c Modified: trunk/gcc/ChangeLog trunk/gcc/expr.c trunk/gcc/testsuite/ChangeLog
[Bug middle-end/52074] ICE: RTL flag check: MEM_VOLATILE_P used with unexpected rtx code 'plus' in extract_fixed_bit_field, at expmed.c:1734
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52074 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2012-02-07 09:25:45 UTC --- Fixed.
[Bug middle-end/52142] [trans-mem] inlined transaction_pure functions are instrumented
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52142 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-02-07 Ever Confirmed|0 |1 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2012-02-07 09:27:46 UTC --- You'd need to lower transaction_pure into some IL constructs (similar to how stmts only throw if they are in EH tables, or similar to how we set TREE_NO_TRAP). The other variant would be to never inline transaction_pure functions into non-transaction_pure functions (see can_inline_edge_p for how we for example check DECL_FUNCTION_SPECIFIC_OPTIMIZATION there).
[Bug middle-end/52141] [trans-mem] ICE due to asm statement in trans-mem.c:expand_block_tm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52141 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2012-02-07 09:30:45 UTC --- Might I suggest to instead of case GIMPLE_ASM: gcc_unreachable (); use case GIMPLE_ASM: sorry (asm statements not allowed in transactions); ? It's not a compiler but a user error (well, usually). Btw, what you really want is some simple IPA propagation of the various transaction attributes similar to how we handle pure/const.
[Bug c++/52147] New: Preprocessed Chromium source with long compile time
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52147 Bug #: 52147 Summary: Preprocessed Chromium source with long compile time Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: h...@chromium.org As requested in http://gcc.gnu.org/ml/gcc/2012-02/msg00146.html, here is the preprocessed source for the file that was slowest to compile in my measurements.
[Bug fortran/25020] NAG extension: module F90_UNIX providing access to UNIX functions (abort ...)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25020 Janne Blomqvist jb at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||jb at gcc dot gnu.org Resolution||WONTFIX --- Comment #5 from Janne Blomqvist jb at gcc dot gnu.org 2012-02-07 10:11:56 UTC --- Closing as wontfix. - The PR hasn't seen any activity in almost 5 years - GFortran nowadays has ISO_C_BINDING support, making it easy to create robust interfaces to C functionality without having to integrate it into the compiler. - The GFortran developers have their hands full implementing support for the Fortran standard. - Contributing to GCC is a bit cumbersome, with all kinds of paperwork required etc. Thus I suggest that functionality such as proposed here is better of developed as a separate library, e.g. on github or whatnot. The gtk-fortran project offers an excellent example of such a project: https://github.com/jerryd/gtk-fortran/wiki
[Bug c++/52147] Preprocessed Chromium source with long compile time
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52147 --- Comment #1 from hans at chromium dot org 2012-02-07 10:12:13 UTC --- Created attachment 26599 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26599 the slowest file
[Bug c++/52147] Preprocessed Chromium source with long compile time
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52147 --- Comment #2 from hans at chromium dot org 2012-02-07 10:17:39 UTC --- Created attachment 26600 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26600 file with largest difference between 4.6 and 4.7
[Bug c++/52147] Preprocessed Chromium source with long compile time
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52147 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-02-07 Ever Confirmed|0 |1 --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2012-02-07 10:34:32 UTC --- Thanks. The slowest one looks autogenerated, simply a very large translation unit. Lots of functions with lots of function calls. Nothing special sticks out when looking at -ftime-report. The one with the largest difference spends the most time in the C++ frontend where it also regressed.
[Bug target/40068] GCC fails to apply dllexport attribute to typeinfo.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40068 --- Comment #9 from Kai Tietz ktietz at gcc dot gnu.org 2012-02-07 10:46:06 UTC --- Author: ktietz Date: Tue Feb 7 10:45:59 2012 New Revision: 183962 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=183962 Log: 2012-02-07 Kai Tietz kti...@redhat.com Dave Korn dave.korn.cyg...@gmail.com PR target/40068 * config/i386/winnt-cxx.c (i386_pe_adjust_class_at_definition): Take care that typinfo gets dllexport-attribute. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/winnt-cxx.c
[Bug target/40068] GCC fails to apply dllexport attribute to typeinfo.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40068 --- Comment #10 from Kai Tietz ktietz at gcc dot gnu.org 2012-02-07 10:49:20 UTC --- Author: ktietz Date: Tue Feb 7 10:49:14 2012 New Revision: 183963 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=183963 Log: 2012-02-07 Kai Tietz kti...@redhat.com Dave Korn dave.korn.cyg...@gmail.com PR target/40068 * config/i386/winnt-cxx.c (i386_pe_adjust_class_at_definition): Take care that typinfo gets dllexport-attribute. Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/config/i386/winnt-cxx.c
[Bug c++/52147] Preprocessed Chromium source with long compile time
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52147 Markus Trippelsdorf markus at trippelsdorf dot de changed: What|Removed |Added CC||markus at trippelsdorf dot ||de --- Comment #4 from Markus Trippelsdorf markus at trippelsdorf dot de 2012-02-07 10:51:09 UTC --- perf record -g g++ -O2 -c /var/tmp/V8DerivedSources08.ii with 4.7 shows: # Overhead Command 8.78% cc1plus cc1plus [.] store_binding | --- store_binding 1.94% cc1plus libc-2.15.so[.] memset | --- memset | |--50.00%-- reload_cse_regs_1 | |--25.00%-- ipcp_generate_summary | --24.99%-- inline_analyze_function 1.89% cc1plus cc1plus [.] gt_ggc_mx_lang_tree_node | --- gt_ggc_mx_lang_tree_node 1.86% cc1plus libc-2.15.so[.] _int_malloc | --- _int_malloc 1.73% cc1plus cc1plus [.] ggc_set_mark | --- ggc_set_mark 1.36% cc1plus cc1plus [.] ggc_internal_alloc_stat | --- ggc_internal_alloc_stat 1.27% cc1plus cc1plus [.] htab_find_slot_with_hash | --- htab_find_slot_with_hash | --100.00%-- (nil) 1.24% cc1plus libc-2.15.so[.] _int_free | --- _int_free | --100.00%-- compute_may_aliases 1.07% cc1plus cc1plus [.] push_to_top_level | --- push_to_top_level 0.94% cc1plus cc1plus [.] bitmap_set_bit | --- bitmap_set_bit | |--22.22%-- 0x31cfaa8 | |--22.22%-- (nil) | |--11.11%-- 0x2b260c8 | |--11.11%-- 0x2b26308 | |--11.11%-- 0x31d02b0 | |--11.11%-- 0x2af1290 | --11.11%-- 0x32067c8 0.87% cc1plus cc1plus [.] lookup_fnfields_idx_nolazy | --- lookup_fnfields_idx_nolazy 0.78% cc1plus cc1plus [.] add_function_candidate | --- add_function_candidate 0.77% as as [.] 0x2f5e5 ...
[Bug rtl-optimization/52148] New: [4.7 regression] ICE: in spill_failure, at reload1.c:2120
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52148
Bug #: 52148
Summary: [4.7 regression] ICE: in spill_failure, at
reload1.c:2120
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mhlav...@redhat.com
Created attachment 26601
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26601
pre-processed reproducer
gcc 4.7 fails on code that was working in 4.6 without any problem
Version: 4.7.0-20120204
Target: avr
Problem happens only when optimization (O2 or O3) is used.
Pre-processed reproducer attached.
$ avr-gcc -mmcu=atmega64 -O2 allsrce.cpp -c -o allsrc.o
allsrce.cpp: In function 'void applyExpos(int16_t*, uint8_t)':
allsrce.cpp:68:1: error: unable to find a register to spill in class
'POINTER_REGS'
allsrce.cpp:68:1: error: this is the insn:
(insn 17 16 9 2 (parallel [
(set (mem:BLK (reg:HI 26 r26) [0 A8])
(mem:BLK (reg/v/f:HI 97 [ anas ]) [0 A8]))
(unspec [
(const_int 0 [0])
] UNSPEC_MOVMEM)
(use (reg:QI 24 r24 [99]))
(clobber (reg:HI 26 r26))
(clobber (reg:HI 30 r30))
(clobber (reg:QI 0 r0))
(clobber (reg:QI 24 r24 [99]))
]) allsrce.cpp:49 29 {movmem_qi}
(expr_list:REG_DEAD (reg:QI 24 r24 [99])
(expr_list:REG_DEAD (reg:QI 27 r27)
(expr_list:REG_UNUSED (reg:QI 24 r24 [99])
(expr_list:REG_UNUSED (reg:QI 0 r0)
(expr_list:REG_UNUSED (reg:HI 30 r30)
(expr_list:REG_UNUSED (reg:HI 26 r26)
(nil
allsrce.cpp:68:1: internal compiler error: in spill_failure, at reload1.c:2120
Please submit a full bug report,
with preprocessed source if appropriate.
Additional information:
$ avr-gcc -v
Using built-in specs.
COLLECT_GCC=avr-gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/avr/4.7.0/lto-wrapper
Target: avr
Configured with: ../gcc-4.7-20120204/configure --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info --target=avr
--enable-languages=c,c++ --disable-nls --disable-libssp --with-system-zlib
--enable-version-specific-runtime-libs --with-pkgversion='Fedora 4.7-0.fc16.1'
--with-bugurl=https://bugzilla.redhat.com/
Thread model: single
gcc version 4.7.0 20120204 (experimental) (Fedora 4.7-0.fc16.1)
[Bug libgcj/12708] SIGSEGV, Segmentation fault starting java program
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12708 Gyan Ojha gyanendra.webmaster at gmail dot com changed: What|Removed |Added CC||gyanendra.webmaster at ||gmail dot com --- Comment #14 from Gyan Ojha gyanendra.webmaster at gmail dot com 2012-02-07 10:55:36 UTC --- This Driver version is error free,DataDirect free trial downloads for JDBC drivers, ODBC drivers and ADO.NET providers including connection to Oracle, DB2, Sybase, and MS SQL Server. Download it from: http://www.datadirect.com/products/jdbc/index.html
[Bug rtl-optimization/52148] [4.7 regression] ICE: in spill_failure, at reload1.c:2120
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52148 --- Comment #1 from Michal Hlavinka mhlavink at redhat dot com 2012-02-07 10:58:56 UTC --- note: looks similar to http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50925 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52025 but compared to both bugs above, adding -fno-caller-saves does not fix the problem
[Bug rtl-optimization/52148] [4.7 regression] ICE: in spill_failure, at reload1.c:2120
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52148 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target||avr Target Milestone|--- |4.7.0
[Bug rtl-optimization/52139] [4.5/4.6/4.7 Regression] ICE: in remove_insn, at emit-rtl.c:3960 with -O -fPIC -fno-tree-dominator-opts -fno-tree-fre
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52139
--- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2012-02-07
11:42:35 UTC ---
Created attachment 26602
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26602
gcc47-pr52139.patch
Ugh, this is ugly. The main problem is that delete_insn/remove_insn refuse to
remove insns with NEXT_INSN (insn) == NULL_RTX (unless they are in the current
sequence or in the sequence stack). Unfortunately in the cfglayout mode BB_END
or end of bb-il.rtl-{header,footer} often/always have it NULL.
In this testcase, we are merging two bbs where the first bb ends with an
unconditional jump to the second and second bb contains switch table followed
by barrier in its header, then deleted label, then NOTE_INSN_BASIC_BLOCK and
that is the last insn in that bb. The first problem is that we
delete_insn_chain in the header just all but the last insn, so BB_END (a)
points to a BARRIER. And the second problem is that when removing the
NOTE_INSN_BASIC_BLOCK note using delete_insn, NEXT_INSN (note) is NULL and thus
remove_insn ICEs.
The following ugly hacks fix it, but am not very happy about them.
[Bug fortran/52117] allocated arrays give incorrect results when used with RESHAPE in gcc v4.6.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52117 --- Comment #6 from hirshmansp at ornl dot gov 2012-02-07 11:43:29 UTC --- Tobias Here are the answers to your questions: [qsh@swim SIESTA]$ gfortran -v|grep -E 'gcc version|Target' Target: x86_64-redhat-linux gcc version 4.6.2 20111027 (Red Hat 4.6.2-1) (GCC) It compiles/links with the -std:f95 flag, but gives the same wrong results (did not change B to B(:,:,:) since that is not a practical solution for us, lots of reshapes in our code: [qsh@swim SIESTA]$ gfortran -std=f95 reshape.f90 reshape.f90:37.11: PAUSE 1 Error: Deleted feature: PAUSE statement at (1) [qsh@swim SIESTA]$ a.out A( 1 , 1 ) =1.000 B =3.000 A( 2 , 1 ) =2.000 B =4.000 A( 1 , 2 ) =3.000 B =5.000 A( 2 , 2 ) =4.000 B =6.000 A( 1 , 3 ) =5.000 B =7.000 A( 2 , 3 ) =6.000 B =8.000 A( 1 , 4 ) =7.000 B =0.000 A( 2 , 4 ) =8.000 B =0.000 PAUSE From: Steven Hirshman [mailto:sphirsh...@yahoo.com] Sent: Monday, February 06, 2012 8:02 PM To: Hirshman, Steven Paul Subject: Fw: [Bug fortran/52117] allocated arrays give incorrect results when used with RESHAPE in gcc v4.6.2 - Forwarded Message - From: burnus at gcc dot gnu.org gcc-bugzi...@gcc.gnu.org To: sphirsh...@yahoo.com Sent: Monday, February 6, 2012 3:01 PM Subject: [Bug fortran/52117] allocated arrays give incorrect results when used with RESHAPE in gcc v4.6.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52117 --- Comment #5 from Tobias Burnus burnus at gcc dot gnu.orghttp://gnu.org/ 2012-02-06 20:01:15 UTC --- (In reply to comment #4) Thanks. I tried the -std=f95 flag and it gave the same (wrong) answer as without it, in the test code I sent you. What is not Fortran95 compatible with the code snippet I sent you? I works for me both with GCC 4.6 and GCC 4.7 both with the current version but also with a version which still had bug 52012. Can you please answer the following question? You only kind of answered the third question, namely that you used the original program (of comment 0). Additional, could you provide more information about the version you used (gfortran -v), of interest are the complete of Target and of gcc version. (In reply to comment #3) Can you provides more details? In particular: - How does it fail? At compile time? At run time? With which error? - Which version/platform of the compiler are you using? - Is that with the code of comment 0 with only B = RESHAPE... changed to B(:) = RESHAPE... or is it for some other code? Example on my system for a 4.6 version which has still the bug: $ gfortran-4.6 -v | grep -E 'gcc version|Target' Target: x86_64-suse-linux gcc version 4.6.2 20111212 [gcc-4_6-branch revision 18] (SUSE Linux) $ gfortran-4.6 -std=f95 test.f90 test.f90:37.11: PAUSE 1 Error: Deleted feature: PAUSE statement at (1) And after commenting that line: $ gfortran-4.6 -std=f95 test.f90 A( 1 , 1 ) =1. B =1. A( 2 , 1 ) =2. B =2. A( 1 , 2 ) =3. B =3. A( 2 , 2 ) =4. B =4. A( 1 , 3 ) =5. B =5. A( 2 , 3 ) =6. B =6. A( 1 , 4 ) =7. B =7. A( 2 , 4 ) =8. B =8. The output looks correct and is the same as with other compilers. However, if I use the buggy version of the compiler without -std=f95, I get: $ gfortran-4.6 hj4.f90 ./a.out A( 1 , 1 ) =1. B =3. A( 2 , 1 ) =2. B =4. A( 1 , 2 ) =3. B =5. A( 2 , 2 ) =4. B =6. A( 1 , 3 ) =5. B =7. A( 2 , 3 ) =6. B =8. A( 1 , 4 ) =7. B =3.36311631E-44 A( 2 , 4 ) =8. B =9.62964972E-35 As written, using (:) - or to be more precise (it's a rank-3 array) - B(:,:,:) = , -fno-realloc-lhs, or a newer version of the compiler solves the problem as well. -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You reported the bug.
[Bug middle-end/51231] [4.5/4.6/4.7 Regression] g++ remove placement new with -O1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51231
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||INVALID
--- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2012-02-07
11:45:31 UTC ---
Confirmed. The store of 0xdeadbeef is gone:
void create(allocator_type, boost::interprocess::allocatorint,
boost::interprocess::segment_managerchar,
boost::interprocess::rbtree_best_fitboost::interprocess::mutex_family,
boost::interprocess::iset_index ::value_type, int) (struct allocator_type
allocator, value_type at, int value)
{
value_type * myp;
const ptrdiff_t D.99202;
sizetype D.99201;
struct pointer D.83867;
bb 2:
# USE = nonlocal { D.83867 }
# CLB = nonlocal { D.83867 }
D.83867 = boost::interprocess::allocatorint,
boost::interprocess::segment_managerchar,
boost::interprocess::rbtree_best_fitboost::interprocess::mutex_family,
boost::interprocess::iset_index ::address (allocator_1(D), at_2(D)); [return
slot optimization]
D.99202_7 = D.83867.internal.m_offset;
if (D.99202_7 != 1)
goto bb 3;
else
goto bb 4;
bb 3:
D.99201_8 = (sizetype) D.99202_7;
# PT = { D.83867 }
myp_9 = D.83867 + D.99201_8;
bb 4:
# PT = null { D.83867 }
# myp_10 = PHI 0B(2), myp_9(3)
if (myp_10 != 0B)
goto bb 5;
else
goto bb 6;
bb 5:
value_11 = value_14(D);
*myp_10 = value_11;
bb 6:
D.83867 ={v} {CLOBBER};
return;
}
in ealias. Note that Boost invokes undefined behavior here as it
computes D.83867 + D.83867.internal.m_offset which supposedly
points to an object that is not D.83867 obviously, as that is
automatic in function create() and the store would be dead anyway.
[Bug target/40068] GCC fails to apply dllexport attribute to typeinfo.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40068 --- Comment #11 from Kai Tietz ktietz at gcc dot gnu.org 2012-02-07 11:48:41 UTC --- Author: ktietz Date: Tue Feb 7 11:48:34 2012 New Revision: 183965 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=183965 Log: 2012-02-07 Kai Tietz kti...@redhat.com Dave Korn dave.korn.cyg...@gmail.com PR target/40068 * config/i386/winnt-cxx.c (i386_pe_adjust_class_at_definition): Take care that typinfo gets dllexport-attribute. Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/config/i386/winnt-cxx.c
[Bug rtl-optimization/52139] [4.5/4.6/4.7 Regression] ICE: in remove_insn, at emit-rtl.c:3960 with -O -fPIC -fno-tree-dominator-opts -fno-tree-fre
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52139 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Attachment #26602|0 |1 is obsolete|| --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2012-02-07 12:20:19 UTC --- Created attachment 26603 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26603 gcc47-pr52139.patch Actually, the delete_insn_chain call removed the barrier, but as barriers don't have BLOCK_FOR_INSN, it didn't update BB_END. This is a different approach, which allows remove_insn to remove even the last insn in a bb, if it is equal to BB_END. And adjusts BB_END even if BB_END is a BARRIER. That part alternatively could be handled by forcibly setting BB_END (a) = first; after the delete_insn_chain call for the header. With the emit-rtl.c changes as is, the cfgrtl.c changes are just a cleanup to merge two same code sequences, but if the second part of the emit-rtl.c change is removed, we'd need to add that BB_END (a) = first;
[Bug c++/52147] Preprocessed Chromium source with long compile time
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52147 --- Comment #5 from Richard Guenther rguenth at gcc dot gnu.org 2012-02-07 12:29:24 UTC --- largest regression: trunk -O2: TOTAL : 29.47 3.0632.61 678947 kB 4.6.3-pre -O2: TOTAL : 23.56 3.8027.90 658720 kB 4.6.3-pre -fsyntax-only: Execution times (seconds) garbage collection: 0.44 ( 4%) usr 0.00 ( 0%) sys 0.43 ( 3%) wall 0 kB ( 0%) ggc preprocessing : 0.27 ( 2%) usr 0.34 (14%) sys 0.52 ( 4%) wall 4548 kB ( 1%) ggc parser: 7.70 (67%) usr 0.86 (36%) sys 9.02 (65%) wall 364457 kB (84%) ggc name lookup : 3.00 (26%) usr 1.15 (48%) sys 3.87 (28%) wall 62867 kB (15%) ggc varconst : 0.02 ( 0%) usr 0.02 ( 1%) sys 0.02 ( 0%) wall 4 kB ( 0%) ggc symout: 0.01 ( 0%) usr 0.01 ( 0%) sys 0.01 ( 0%) wall 32 kB ( 0%) ggc TOTAL : 11.44 2.4013.88 433195 kB trunk -fsyntax-only: Execution times (seconds) phase setup : 0.01 ( 0%) usr 0.01 ( 1%) sys 0.01 ( 0%) wall 1438 kB ( 0%) ggc phase parsing : 14.00 (100%) usr 1.86 (99%) sys 15.93 (100%) wall 405002 kB (100%) ggc |name lookup: 6.07 (43%) usr 0.31 (16%) sys 5.88 (37%) wall 30410 kB ( 7%) ggc |overload resolution: 6.55 (47%) usr 0.25 (13%) sys 7.07 (44%) wall 64054 kB (16%) ggc garbage collection : 0.46 ( 3%) usr 0.01 ( 1%) sys 0.46 ( 3%) wall 0 kB ( 0%) ggc preprocessing : 0.27 ( 2%) usr 0.30 (16%) sys 0.68 ( 4%) wall 4876 kB ( 1%) ggc parser (global) : 1.07 ( 8%) usr 0.42 (22%) sys 1.26 ( 8%) wall 88673 kB (22%) ggc parser struct body : 1.79 (13%) usr 0.21 (11%) sys 2.36 (15%) wall 67530 kB (17%) ggc parser enumerator list : 0.02 ( 0%) usr 0.00 ( 0%) sys 0.02 ( 0%) wall 1220 kB ( 0%) ggc parser function body: 1.11 ( 8%) usr 0.09 ( 5%) sys 1.26 ( 8%) wall 21293 kB ( 5%) ggc parser inl. func. body : 1.42 (10%) usr 0.09 ( 5%) sys 1.59 (10%) wall 18676 kB ( 5%) ggc parser inl. meth. body : 1.65 (12%) usr 0.23 (12%) sys 1.85 (12%) wall 53613 kB (13%) ggc template instantiation : 6.19 (44%) usr 0.50 (27%) sys 6.45 (40%) wall 149113 kB (37%) ggc varconst: 0.02 ( 0%) usr 0.01 ( 1%) sys 0.00 ( 0%) wall 4 kB ( 0%) ggc TOTAL : 14.01 1.8815.95 406458 kB
[Bug fortran/52149] New: FAIL: gfortran.dg/vect/vect-8.f90
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52149 Bug #: 52149 Summary: FAIL: gfortran.dg/vect/vect-8.f90 Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: greta.yo...@arm.com CC: tkoe...@gcc.gnu.org Target: arm-none-eabi This new test fails on arm-none-eabi target. The test was added to trunk in r183917, as described in PR32373.
[Bug rtl-optimization/52139] [4.5/4.6/4.7 Regression] ICE: in remove_insn, at emit-rtl.c:3960 with -O -fPIC -fno-tree-dominator-opts -fno-tree-fre
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52139 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Attachment #26603|0 |1 is obsolete|| --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2012-02-07 13:22:45 UTC --- Created attachment 26604 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26604 gcc47-pr52139.patch That patch didn't get too far with rtl checking, we are sometimes remove_insn a barrier after a barrier. So, here is the variant with the second remove_insn change removed and instead with BB_END (a) = first; in cfg_layout_merge_blocks. Could add there gcc_checking_assert (BB_END (a) == first || BARRIER_P (BB_END (a))); before that line if requested.
[Bug c++/52145] [C++11] zero-valued integer constant expression should prefer conversion to pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52145 Daniel Krügler daniel.kruegler at googlemail dot com changed: What|Removed |Added CC||daniel.kruegler at ||googlemail dot com --- Comment #1 from Daniel Krügler daniel.kruegler at googlemail dot com 2012-02-07 13:51:59 UTC --- (In reply to comment #0) The core language is in the process to make it clear, that S().n no longer is a null-pointer constant, see http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#903 This would mean that the current behaviour is as intended. I would make the outcome of this issue dependent on the final CWG 903 decision.
[Bug fortran/52149] FAIL: gfortran.dg/vect/vect-8.f90
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52149
Tobias Burnus burnus at gcc dot gnu.org changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2012-02-07
14:02:18 UTC ---
Was that before or after the additional change was committed?
Namely:
http://gcc.gnu.org/viewcvs?view=revisionrevision=183943
Mon Feb 6 21:24:54 2012 UTC (16 hours, 35 minutes ago)
-! { dg-require-effective-target vect_float }
+! { dg-require-effective-target vect_double }
Does it still fail with that patch?
[Bug fortran/52117] allocated arrays give incorrect results when used with RESHAPE in gcc v4.6.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52117 --- Comment #7 from Tobias Burnus burnus at gcc dot gnu.org 2012-02-07 14:36:48 UTC --- (In reply to comment #6) It compiles/links with the -std:f95 flag, but gives the same wrong results [qsh@swim SIESTA]$ gfortran -std=f95 reshape.f90 reshape.f90:37.11: PAUSE 1 Error: Deleted feature: PAUSE statement at (1) [qsh@swim SIESTA]$ a.out Well, you do not use -std=f95: As the compilation fails with an ERROR, thus no new a.out file is produced. If you then start a.out, a previously compiled file is used. (did not change B to B(:,:,:) since that is not a practical solution for us, lots of reshapes in our code In Fortran 2003, an allocatable (array) on the LHS is automatically allocated (if unallocated) or reallocated (if the shape does not match). Unfortunately, the implementation had a bug, which could appear if the RHS consisted of only a call to an intrinsic function, located the run-time library (libgfortran). Unless you provide me with a time machine, there are only two choices: Avoiding a gfortran version with that bug by using a newer/older version. Or avoiding the (re)allocation on assignment using either compiler flags or modifying the code. The only solutions, I see, which do not require code changes are: - Use any GCC version before GCC 4.6.0; for instance GCC 4.5.x - Use GCC 4.6 older than 2010-11-28 - Use a GCC (any version) newer than 2012-02-03 - Use -fno-realloc-lhs (caveat: Flag not supported before GCC 4.6) - Use -std=f95 (caveat: Requires that the code compiles without error with -std=f95) I personally would use -fno-realloc-lhs [also due to performance reasons] and/or an compiler version without the bug. For completeness, also the following code changes are possible; except for the first one, they are not recommended: - Use an array spec for allocatable LHS, e.g. B(:,:,:) = - Don't use allocatables left of = RESHAPE - Make the expression on the RHS more complicated: add + 0 or surround with ( ). The first solution (B(:,:,:) = ) has the advantage that it avoids additional checks whether the LHS is allocated and have the correct shape. With Fortran 2003/2008 compilers, adding it improves the performance minutely - and in hot loops it might even matter. That's the reason that gfortran has -fno-realloc-lhs, but also that other compiles have similar flags such as -assume norealloc_lhs or -e w.
[Bug c++/52145] [C++11] [DR 903] zero-valued integer constant expression should prefer conversion to pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52145 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |SUSPENDED Last reconfirmed||2012-02-07 Summary|[C++11] zero-valued integer |[C++11] [DR 903] |constant expression should |zero-valued integer |prefer conversion to|constant expression should |pointer |prefer conversion to ||pointer Ever Confirmed|0 |1 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2012-02-07 14:39:07 UTC --- suspending
[Bug fortran/52149] FAIL: gfortran.dg/vect/vect-8.f90
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52149 --- Comment #2 from Greta Yorsh Greta.Yorsh at arm dot com 2012-02-07 14:40:17 UTC --- This patch fixes the problem. Thank you! -- Greta
[Bug fortran/52149] FAIL: gfortran.dg/vect/vect-8.f90
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52149 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org 2012-02-07 14:44:11 UTC --- (In reply to comment #2) This patch fixes the problem. Thank you! Great! Let's close then the PR.
[Bug target/51921] [4.6/4.7 regression] EH unwinding support is broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51921 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |WAITING --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2012-02-07 15:37:54 UTC --- Only sparc-sun-solaris2.10 is a primary target at the moment. Rainer, you say regression from 4.6 but the summary says 4.6/4.7 regression, not 4.7 regression. No known-to-work/known-to-fail field. Does this only affect Ada? Please clarify.
[Bug middle-end/51929] [4.7 Regression] ICE: verify_cgraph_node failed with -O2 -fno-guess-branch-probability -fipa-cp-clone
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51929 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-checking Priority|P3 |P1 Status|UNCONFIRMED |NEW Last reconfirmed||2012-02-07 Ever Confirmed|0 |1 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2012-02-07 15:40:21 UTC --- Confirmed.
[Bug debug/51950] [4.6/4.7 Regression] fdebug-types-section regression for member pointers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51950 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2
[Bug middle-end/51994] [4.6/4.7 Regression] git-1.7.8.3 miscompiled due to negative bitpos from get_inner_reference
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51994 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2
[Bug middle-end/51939] [4.7 Regression] ICE: in compute_affine_dependence, at tree-data-ref.c:4103 with -fcheck-data-deps
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51939 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P5
[Bug c++/52126] [4.7 Regression] compilation error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52126 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||rejects-valid Priority|P3 |P1 Status|UNCONFIRMED |NEW Last reconfirmed||2012-02-07 Known to work||4.6.3 Ever Confirmed|0 |1 --- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2012-02-07 15:46:32 UTC --- Confirmed.
[Bug rtl-optimization/52139] [4.5/4.6/4.7 Regression] ICE: in remove_insn, at emit-rtl.c:3960 with -O -fPIC -fno-tree-dominator-opts -fno-tree-fre
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52139 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2 Target Milestone|4.7.0 |4.5.4
[Bug debug/52132] [4.7 Regression] ICE in loc_descriptor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52132 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1
[Bug rtl-optimization/49847] [4.7 Regression] NULL deref in fold_rtx (prev_insn_cc0 == NULL)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49847 --- Comment #15 from Mikael Pettersson mikpe at it dot uu.se 2012-02-07 15:48:22 UTC --- (In reply to comment #12) The problem appears to be due to the exception region on a cc0 setter, which separates it from the cc0 consumer: (insn 4013 4012 8164 949 (set (cc0) (compare (reg:SF 912 [ D.26269 ]) (const_double:SF -2147483648 [0x8000] 2.147483648e+9 [0x0.8p+32]))) ../../../gcc/libjava/interpret.cc:131 -1 (expr_list:REG_EH_REGION (const_int 4 [0x4]) (nil))) (note 8164 4013 4014 950 [bb 950] NOTE_INSN_BASIC_BLOCK) (insn 4014 8164 4015 950 (set (reg:QI 2121) (ge:QI (cc0) (const_int 0 [0]))) ../../../gcc/libjava/interpret.cc:131 -1 (nil)) Happens in trunk since r180192. r180192 contains two changes: it's the tree-eh.c change that triggers the ICE, the other tree-ssa-forwprop.c change makes no difference to this PR.
[Bug rtl-optimization/52148] [4.7 regression] ICE: in spill_failure, at reload1.c:2120
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52148 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-valid-code Priority|P3 |P4
[Bug rtl-optimization/52060] [4.6/4.7 Regression] Invalid constant simplification in combine with parallel result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52060 --- Comment #10 from Jakub Jelinek jakub at gcc dot gnu.org 2012-02-07 15:48:59 UTC --- Author: jakub Date: Tue Feb 7 15:48:52 2012 New Revision: 183972 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=183972 Log: PR rtl-optimization/52060 * combine.c (try_combine): Add i0src_copy and i0src_copy2 variables, copy i1src to i1src_copy whenever added_sets_2 i1_feeds_i2_n already before i1dest - i1src substitution in newpat, copy i0src to i0src_copy and/or i0src_copy2 when needed. * gcc.dg/torture/pr52060.c: New test. Added: trunk/gcc/testsuite/gcc.dg/torture/pr52060.c Modified: trunk/gcc/ChangeLog trunk/gcc/combine.c trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/52060] [4.6 Regression] Invalid constant simplification in combine with parallel result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52060 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org | Summary|[4.6/4.7 Regression]|[4.6 Regression] Invalid |Invalid constant|constant simplification in |simplification in combine |combine with parallel |with parallel result|result --- Comment #11 from Jakub Jelinek jakub at gcc dot gnu.org 2012-02-07 16:16:21 UTC --- Fixed on the trunk so far.
[Bug target/48743] -march=native mis-detects AMD K6-2+ / K6-3 as Athlon - compiled C fails with illegal instruction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48743 --- Comment #9 from Quentin Neill qneill at gcc dot gnu.org 2012-02-07 16:17:35 UTC --- Author: qneill Date: Tue Feb 7 16:17:26 2012 New Revision: 183973 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=183973 Log: 2012-02-07 Quentin Neill quentin.ne...@amd.com Backport from mainline: 2012-01-19 Quentin Neill quentin.ne...@amd.com PR target/48743 * config/i386/driver-i386.c (host_detect_local_cpu): Also check family to distinguish PROCESSOR_ATHLON. Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/config/i386/driver-i386.c
[Bug fortran/52117] allocated arrays give incorrect results when used with RESHAPE in gcc v4.6.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52117 --- Comment #8 from steven hirshman sphirshman at yahoo dot com 2012-02-07 16:18:33 UTC --- Thank you. I didn't catch the PAUSE problem. It now runs correctly with the -std=f95 flag, which is what we'll use. Thanks for your helpful responses. From: burnus at gcc dot gnu.org gcc-bugzi...@gcc.gnu.org To: sphirsh...@yahoo.com Sent: Tuesday, February 7, 2012 9:36 AM Subject: [Bug fortran/52117] allocated arrays give incorrect results when used with RESHAPE in gcc v4.6.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52117 --- Comment #7 from Tobias Burnus burnus at gcc dot gnu.org 2012-02-07 14:36:48 UTC --- (In reply to comment #6) It compiles/links with the -std:f95 flag, but gives the same wrong results [qsh@swim SIESTA]$ gfortran -std=f95 reshape.f90 reshape.f90:37.11: PAUSE 1 Error: Deleted feature: PAUSE statement at (1) [qsh@swim SIESTA]$ a.out Well, you do not use -std=f95: As the compilation fails with an ERROR, thus no new a.out file is produced. If you then start a.out, a previously compiled file is used. (did not change B to B(:,:,:) since that is not a practical solution for us, lots of reshapes in our code In Fortran 2003, an allocatable (array) on the LHS is automatically allocated (if unallocated) or reallocated (if the shape does not match). Unfortunately, the implementation had a bug, which could appear if the RHS consisted of only a call to an intrinsic function, located the run-time library (libgfortran). Unless you provide me with a time machine, there are only two choices: Avoiding a gfortran version with that bug by using a newer/older version. Or avoiding the (re)allocation on assignment using either compiler flags or modifying the code. The only solutions, I see, which do not require code changes are: - Use any GCC version before GCC 4.6.0; for instance GCC 4.5.x - Use GCC 4.6 older than 2010-11-28 - Use a GCC (any version) newer than 2012-02-03 - Use -fno-realloc-lhs (caveat: Flag not supported before GCC 4.6) - Use -std=f95 (caveat: Requires that the code compiles without error with -std=f95) I personally would use -fno-realloc-lhs [also due to performance reasons] and/or an compiler version without the bug. For completeness, also the following code changes are possible; except for the first one, they are not recommended: - Use an array spec for allocatable LHS, e.g. B(:,:,:) = - Don't use allocatables left of = RESHAPE - Make the expression on the RHS more complicated: add + 0 or surround with ( ). The first solution (B(:,:,:) = ) has the advantage that it avoids additional checks whether the LHS is allocated and have the correct shape. With Fortran 2003/2008 compilers, adding it improves the performance minutely - and in hot loops it might even matter. That's the reason that gfortran has -fno-realloc-lhs, but also that other compiles have similar flags such as -assume norealloc_lhs or -e w.
[Bug target/51921] [4.6/4.7 regression] EH unwinding support is broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51921 --- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE 2012-02-07 16:59:32 UTC --- --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2012-02-07 15:37:54 UTC --- Only sparc-sun-solaris2.10 is a primary target at the moment. Rainer, you say regression from 4.6 but the summary says 4.6/4.7 regression, not 4.7 regression. No known-to-work/known-to-fail field. Does this only affect Ada? Please clarify. I'd only noticed the breakage on mainline at first, but Eric reverted the patch to support Solaris 11 on both mainline and the 4.6 branch, so it indeed regressed on both branches. It doesn't affect only Ada, but Java, too, which chooses to ignore. I'm quite upset about this because the only reason for that reversion he's given so far is a failure (I wouldn't call it regression) on a 7-year-old Solaris 10 beta release (or rather, one of many two-weekly builds). AFAICT, no released version is affected by my rewrite of sparc/sol2-unwind.h, which introduced Solaris 11 support before 4.6.0, which is now completely broken. I don't buy his compatibility argument for several reasons: * Even Sun/Oracle makes no compatibility guarantee of any sort for betas, and can break it if need we. I don't see us making stronger guarantees in FSF GCC, especially to keep prehistoric betas working at the expense of the latest shipping release. * Such versions are completely untestable: I've been in the Solaris 10 Express and Platinum Beta programs myself, and ran practically every single one of those bi-weekly builds (that's what s10_72 is) on my machines, but didn't keep the ISO images for space reasons. * If some AdaCore customer couldn't be bothered to upgrade to a release (I'm talking about any release here, not supported or latest) version of Solaris in 7 years, but needs to run bleeding-edge versions of GCC, I declare that AdaCore's problem, not mine. If the only ill effect of a patch of mine is to break such ancient beta versions (not intentionally or lightly), so be it. I'm not jumping through hoops to fix that. I'm sort of tempted to revert Eric's reversion to restore working Solaris 11 support in 4.6 and mainline, but would only do that as a very last resort. Rainer
[Bug target/52146] [x32] - Wrong code to access addresses 0x80000000 to 0xFFFFFFFF
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52146 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-02-07 Ever Confirmed|0 |1 --- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org 2012-02-07 17:07:23 UTC --- (insn 5 4 0 (set (mem/s/v:SI (const_int -18874240 [0xfee00080]) [3 MEM[(volatile struct apic_test_t *)4276093056B].blubb1+0 S4 A32]) (const_int 0 [0])) t67.c:27 -1 (nil))
[Bug target/51921] [4.6/4.7 regression] EH unwinding support is broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51921 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |NEW --- Comment #4 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-02-07 17:12:26 UTC --- I'm quite upset about this because the only reason for that reversion he's given so far is a failure (I wouldn't call it regression) on a 7-year-old Solaris 10 beta release (or rather, one of many two-weekly builds). AFAICT, no released version is affected by my rewrite of sparc/sol2-unwind.h, which introduced Solaris 11 support before 4.6.0, which is now completely broken. If you give me a proof that no released version whatsoever, from the very first Solaris 8 to the very latest Solaris 10, can be affected by a regression due to the rewrite of the pattern matching code, then I'd (reluctantly) accept the breakage for the Solaris 10 beta. * If some AdaCore customer couldn't be bothered to upgrade to a release (I'm talking about any release here, not supported or latest) version of Solaris in 7 years, but needs to run bleeding-edge versions of GCC, I declare that AdaCore's problem, not mine. If the only ill effect of a patch of mine is to break such ancient beta versions (not intentionally or lightly), so be it. I'm not jumping through hoops to fix that. Let's not misrepresent things, please. Enhancing the existing pattern matching code is trivial: you find the first differing frame in the stack, and you add a new 'else if' somewhere. Again, this pattern matching code is at least one decade old and went through many Solaris versions, so rewriting it from scratch was a wrong decision.
[Bug middle-end/52141] [trans-mem] ICE due to asm statement in trans-mem.c:expand_block_tm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52141 --- Comment #2 from Richard Henderson rth at gcc dot gnu.org 2012-02-07 17:15:41 UTC --- It is a compiler error, because we're supposed to have handled a transaction involving asms differently, earlier in compilation.
[Bug middle-end/51994] [4.6/4.7 Regression] git-1.7.8.3 miscompiled due to negative bitpos from get_inner_reference
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51994 --- Comment #36 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-02-07 17:21:44 UTC --- Author: ebotcazou Date: Tue Feb 7 17:21:36 2012 New Revision: 183974 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=183974 Log: PR middle-end/51994 * expr.c (get_inner_reference): If there is an offset, add a negative bit position to it (if any). Added: trunk/gcc/testsuite/gcc.c-torture/execute/20120207-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/expr.c trunk/gcc/testsuite/ChangeLog
[Bug c++/52126] [4.7 Regression] compilation error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52126
--- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org 2012-02-07
17:23:40 UTC ---
(In reply to comment #2)
Further investigation shows that the issue appears only when inheritance from
the template class (class B : private AT) is provided explicitly. According
to the standard a nested class defined inside a class template is implicitly
template as well.
I don't think that's relevant. The point is that the injected-class-name 'A'
and 'AT' both refer to the class template, and should work equivalently.
It can be reduced to:
templatetypename T
struct A
{
int foo;
struct B : AT
{
using A::foo;
};
};
[Bug middle-end/51994] [4.6/4.7 Regression] git-1.7.8.3 miscompiled due to negative bitpos from get_inner_reference
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51994 --- Comment #37 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-02-07 17:24:32 UTC --- Author: ebotcazou Date: Tue Feb 7 17:24:27 2012 New Revision: 183975 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=183975 Log: PR middle-end/51994 * expr.c (get_inner_reference): If there is an offset, add a negative bit position to it (if any). Added: branches/gcc-4_6-branch/gcc/testsuite/gcc.c-torture/execute/20120207-1.c - copied unchanged from r183974, trunk/gcc/testsuite/gcc.c-torture/execute/20120207-1.c Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/expr.c branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
[Bug gcov-profile/52150] New: [4.7 regression] junk at end of line in Firefox PGO build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52150
Bug #: 52150
Summary: [4.7 regression] junk at end of line in Firefox PGO
build
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: gcov-profile
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mar...@trippelsdorf.de
Consider:
% cat test.i
typedef struct _cairo cairo_t;
cairo_t *_moz_cairo_create ();
__typeof (_moz_cairo_create)
_moz_cairo_create __asm__ (INT__moz_cairo_create);
cairo_t *_moz_cairo_create ()
{
}
% gcc -c -fprofile-generate test.i
/tmp/ccwYenBS.s: Assembler messages:
/tmp/ccwYenBS.s:41: Error: junk at end of line, first unrecognized character is
`*'
/tmp/ccwYenBS.s:42: Error: bad expression
/tmp/ccwYenBS.s:42: Error: junk at end of line, first unrecognized character is
`I'
/tmp/ccwYenBS.s:66: Error: unrecognized symbol type
/tmp/ccwYenBS.s:66: Error: junk at end of line, first unrecognized character is
`*'
/tmp/ccwYenBS.s:67: Error: expected comma after name `__gcov__' in .size
directive
/tmp/ccwYenBS.s:68: Error: invalid character '*' in mnemonic
/tmp/ccwYenBS.s:76: Error: operation combines symbols in different segments
From test.s:
39 __gcov_indirect_call_counters:
40 .zero 8
41 .local __gcov0_*INT__moz_cairo_create
42 .comm __gcov0_*INT__moz_cairo_create,8,8
43 .text
44 .type _GLOBAL__sub_I_65535_0_INT__moz_cairo_create, @function
[Bug middle-end/51994] [4.6/4.7 Regression] git-1.7.8.3 miscompiled due to negative bitpos from get_inner_reference
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51994 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #38 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-02-07 17:28:03 UTC --- Patch applied.
[Bug target/51921] [4.6/4.7 regression] EH unwinding support is broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51921 --- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE 2012-02-07 17:29:37 UTC --- --- Comment #4 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-02-07 17:12:26 UTC --- I'm quite upset about this because the only reason for that reversion he's given so far is a failure (I wouldn't call it regression) on a 7-year-old Solaris 10 beta release (or rather, one of many two-weekly builds). AFAICT, no released version is affected by my rewrite of sparc/sol2-unwind.h, which introduced Solaris 11 support before 4.6.0, which is now completely broken. If you give me a proof that no released version whatsoever, from the very first Solaris 8 to the very latest Solaris 10, can be affected by a regression due to the rewrite of the pattern matching code, then I'd (reluctantly) accept the breakage for the Solaris 10 beta. You know perfectly well that such a proof is practically impossible: that would mean updating a machine through every single Solaris 8/9/10 kernel/libc/libthread patch ever released. The other way round, I'd claim that you cannot prove that the old code works for every since such combination either. * If some AdaCore customer couldn't be bothered to upgrade to a release (I'm talking about any release here, not supported or latest) version of Solaris in 7 years, but needs to run bleeding-edge versions of GCC, I declare that AdaCore's problem, not mine. If the only ill effect of a patch of mine is to break such ancient beta versions (not intentionally or lightly), so be it. I'm not jumping through hoops to fix that. Let's not misrepresent things, please. Enhancing the existing pattern matching code is trivial: you find the first differing frame in the stack, and you add a new 'else if' somewhere. You claimed that before, and that's what I tried at first to make Solaris 11 work, but failed completely. Again, this pattern matching code is at least one decade old and went through many Solaris versions, so rewriting it from scratch was a wrong decision. Why didn't you object then when it was submitted *and accepted*, has been in for almost a year, been shipped with a release, and revert it shortly before the next release? Rainer
[Bug fortran/52151] New: Segfault with realloc on assignment and RESHAPE to unallocated LHS
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52151
Bug #: 52151
Summary: Segfault with realloc on assignment and RESHAPE to
unallocated LHS
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bur...@gcc.gnu.org
CC: pa...@gcc.gnu.org
Follow up to PR 52012 and 52117.
* B is allocated with the shape (n1,n2,n3):
- Works since the patch for PR 52012
(Before, it had the wrong result for the last two elements)
* B is not allocated
- Segfault since the patch for PR 52012
- Before: no segfault but wrong result in for the last two elements
* B allocated with shape (1,1,1)
- Since patch for PR 52012: No crash, but wrong result (2.0 and 3.0 appear
multiple times, 5., 6., 7., 8. are missing and 4. is at the wrong
position)
- Before: no segfault but wrong result in for the last two elements
The test case has been taken from PR 52117 with adaption to show this bug.
chapter08/puppeteer_f2003 of Damian's/Xia's/Xu's book is also affected.
I think there might be an ordering issue with regards to the zero condition and
the bounds condition. Something like the following might work (completely
untested; note also the ORIF):
--- trans-expr.c(revision 183971)
+++ trans-expr.c(working copy)
@@ -6296 +6296 @@ fcncall_realloc_result (gfc_se *se, int
- tree zero_cond;
+ tree zero_cond, cond;
@@ -6324,0 +6325 @@ fcncall_realloc_result (gfc_se *se, int
+ cond = boolean_true_node;
@@ -6344 +6345 @@ fcncall_realloc_result (gfc_se *se, int
- zero_cond);
+ cond);
@@ -6345,0 +6347,4 @@ fcncall_realloc_result (gfc_se *se, int
+
+ zero_cond = fold_build2_loc (input_location, TRUTH_ORIF_EXPR,
+ boolean_type_node, zero_cond,
+ cond);
! Based on the example of PR 52117 by Steven Hirshman
PROGRAM RESHAPEIT
INTEGER, PARAMETER :: n1=2, n2=2, n3=2
INTEGER:: m1, m2, m3, lc
REAL, ALLOCATABLE :: A(:,:), B(:,:,:)
REAL :: val
ALLOCATE (A(n1,n2*n3))
! No allocation: Segfault
! ALLOCATE (B(1,1,1))! Does not segfault, but result is wrong
! ALLOCATE (B(n1,n2,n3)) ! WORKS
val = 0
lc = 0
DO m3=1,n3
DO m2=1,n2
lc = lc+1
DO m1=1,n1
val = val+1
A(m1, lc) = val
END DO
END DO
END DO
B = RESHAPE(A, [n1,n2,n3])
lc = 0
DO m3=1,n3
DO m2=1,n2
lc = lc+1
DO m1=1,n1
PRINT *,'A(',m1,',',lc,') = ',A(m1,lc),' B = ',B(m1,m2,m3)
if (A(m1,lc) /= B(m1,m2,m3)) call abort ()
END DO
END DO
END DO
DEALLOCATE(A, B)
END PROGRAM RESHAPEIT
[Bug gcov-profile/52150] [4.7 regression] junk at end of line in Firefox PGO build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52150 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Keywords||assemble-failure Status|UNCONFIRMED |NEW Last reconfirmed||2012-02-07 Known to work||4.6.3 Target Milestone|--- |4.7.0 Ever Confirmed|0 |1 Known to fail||4.7.0 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2012-02-07 17:41:05 UTC --- Confirmed.
[Bug gcov-profile/52150] [4.7 regression] junk at end of line in Firefox PGO build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52150 --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org 2012-02-07 17:42:41 UTC --- The profiling code forgot to remove the * from the assembly name it looks like. The * means it is defined.
[Bug middle-end/52142] [trans-mem] inlined transaction_pure functions are instrumented
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52142 --- Comment #3 from Richard Henderson rth at gcc dot gnu.org 2012-02-07 17:53:14 UTC --- We were *supposed* to already be disallowing inlining of tm_pure into non-tm_pure functions. At least that's what I remember...
[Bug target/51921] [4.6/4.7 regression] EH unwinding support is broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51921 --- Comment #6 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-02-07 17:54:18 UTC --- You know perfectly well that such a proof is practically impossible: that would mean updating a machine through every single Solaris 8/9/10 kernel/libc/libthread patch ever released. The other way round, I'd claim that you cannot prove that the old code works for every since such combination either. I cannot indeed, but we now have a case where the old code used to work and the new code fails. Granted, this isn't an official release, but it's annoying and casts a legitimate doubt on the robustness of the new code. You claimed that before, and that's what I tried at first to make Solaris 11 work, but failed completely. OK, do you know of a Solaris 11 machine to which I could have access? AdaCore doesn't have one for the time being. Why didn't you object then when it was submitted *and accepted*, has been in for almost a year, been shipped with a release, and revert it shortly before the next release? I already managed to block a backport to the 4.5 branch. :-) As for the shortly, I wrote a first message on 11/28, got no answers, then applied the change on 01/09, that is to say about 3 months before the planned shipping date.
[Bug libstdc++/52068] libc++98.a and libc++11.a are installed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52068 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org 2012-02-07 17:56:56 UTC --- Fixed so closing as such.
[Bug fortran/52151] Segfault with realloc on assignment and RESHAPE to unallocated LHS
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52151 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2012-02-07 18:03:13 UTC --- (In reply to comment #0) I think there might be an ordering issue with regards to the zero condition and the bounds condition. Something like the following might work. Of course, it doesn't. Additionally: Don't forget about the bounds issue, which is unrelated to the segfault.
[Bug target/51753] Many gcc.dg/simultate-thread tests fail on Solaris 10+/x86
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51753 --- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE 2012-02-07 18:09:45 UTC --- Please look at gcc.log files in your testsuite directory. There are extensive single-instruction traces to analyse what went wrong. Comparing your traces to linux execution should give you a hint. The Solaris results were completely nonsensical at first, but ultimately could be explained by a (long-standing, I suppose) and stupid gdb bug: http://sourceware.org/ml/gdb-patches/2012-02/msg00075.html With this fixed, all but the FAIL: gcc.dg/simulate-thread/atomic-load-int128.c -O0 -g thread simulation test failures (at all optimization levels) were gone. I didn't have the Linux/x86_64 gcc.log available for comparison, so I still have to investigate that one. On Solaris 10/x86, I'm sometimes still seeing FAILs, but they may just be timeouts. I've have to check that, too. I'm still seeing a large number of failures both on IRIX 6.5 and Tru64 UNIX V5.1B (both with gdb 7.4), but I suppose those are better filed as separate PRs. I certainly cannot compare gcc.log/g++.log output from other OSes since have no machines running e.g. Linux for comparison. Rainer
[Bug libitm/52042] libitm.c/clone-1.c (all darwin) and libitm.c/stackundo.c (darwin 11) execution tests fail with -fpie
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52042 --- Comment #7 from mrs at gcc dot gnu.org mrs at gcc dot gnu.org 2012-02-07 18:17:33 UTC --- Yes, love to see a patch. I think the argument is important to get right, as otherwise the next bug to track down will be much harder to find (I call this bug pushing). If you can only do part of the job, that's fine, but, please add an assert so that we don't get silently wrong data in cases that aren't handled yet.
[Bug libstdc++/51906] thread lock test failures on darwin11 under Xcode 4.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51906 Jack Howarth howarth at nitro dot med.uc.edu changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #56 from Jack Howarth howarth at nitro dot med.uc.edu 2012-02-07 18:34:35 UTC --- Confirmed fixed at r183971 ... === libstdc++ tests === Running target unix/-m32 === libstdc++ Summary for unix/-m32 === # of expected passes7785 # of expected failures43 # of unsupported tests572 Running target unix/-m64 === libstdc++ Summary for unix/-m64 === # of expected passes7783 # of expected failures43 # of unsupported tests573 === libstdc++ Summary === # of expected passes15568 # of expected failures86 # of unsupported tests1145 Compiler version: gcc libstdc++ Platform: x86_64-apple-darwin11.3.0 configure flags: --prefix=/sw --prefix=/sw/lib/gcc4.7 --mandir=/sw/share/man --infodir=/sw/lib/gcc4.7/info --with-build-config=bootstrap-lto --enable-stage1-languages=c,lto --enable-languages=c,c++,fortran,lto,objc,obj-c++,java --with-gmp=/sw --with-libiconv-prefix=/sw --with-ppl=/sw --with-cloog=/sw --with-mpc=/sw --with-system-zlib --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib --program-suffix=-fsf-4.7 --enable-checking=release --enable-cloog-backend=isl
[Bug target/52152] New: MIPS ELF targets should use dbxelf.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52152 Bug #: 52152 Summary: MIPS ELF targets should use dbxelf.h Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: rsand...@gcc.gnu.org MIPS GNU/Linux targets include dbxelf.h, but plain mips*-elf* ones don't. They should. :-)
[Bug target/52152] MIPS ELF targets should use dbxelf.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52152 rsand...@gcc.gnu.org rsandifo at gcc dot gnu.org changed: What|Removed |Added Target||mips*-*-elf* Status|UNCONFIRMED |NEW Last reconfirmed||2012-02-07 Ever Confirmed|0 |1
[Bug fortran/52153] New: REAL128 gives extended precision, not quad precision
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52153 Bug #: 52153 Summary: REAL128 gives extended precision, not quad precision Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: towns...@astro.wisc.edu The REAL128 parameter defined in ISO_FORTRAN_ENV has the value 10, which corresponds to extended precision. Should it not have a value 16, corresponding to quad precision? As things currently stand, to obtain quad precision reals, I have to use REAL(16) or REAL*16, which is non-portable; I'd rather use REAL(REAL128).
[Bug target/52154] New: va_arg with empty aligned structure fails for MIPS EABI32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52154 Bug #: 52154 Summary: va_arg with empty aligned structure fails for MIPS EABI32 Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: rsand...@gcc.gnu.org Created attachment 26605 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26605 Failing testcase The attached test fails on MIPS EABI32. This doesn't seem to be a regression, so a fix isn't suitable at this stage of 4.7.
[Bug target/52154] va_arg with empty aligned structure fails for MIPS EABI32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52154 rsand...@gcc.gnu.org rsandifo at gcc dot gnu.org changed: What|Removed |Added Target||mipsisa*-*-elf* Status|UNCONFIRMED |NEW Last reconfirmed||2012-02-07 Ever Confirmed|0 |1
[Bug target/52155] New: loongson.h requires -flax-vector-conversions with newlib targets
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52155 Bug #: 52155 Summary: loongson.h requires -flax-vector-conversions with newlib targets Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: rsand...@gcc.gnu.org loongson.h maps V2SI to a vector of int32_t. However, GCC maps SI to integer_type_node in preference to long_integer_type_node, while newlib's stdint.h maps int32_t to long in preference to int. This leads to a lot of conversion errors when including loongson.h unless -flax-vector-conversions is also used. Testcase: gcc.target/mips/loongson-shift-count-truncated-1.c compiled on mipsisa32-elf.
[Bug target/52155] loongson.h requires -flax-vector-conversions with newlib targets
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52155 rsand...@gcc.gnu.org rsandifo at gcc dot gnu.org changed: What|Removed |Added Target||mips*-*-elf* Status|UNCONFIRMED |NEW Last reconfirmed||2012-02-07 Ever Confirmed|0 |1
[Bug target/52154] va_arg with empty aligned structure fails for MIPS EABI32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52154 --- Comment #1 from rsandifo at gcc dot gnu.org rsandifo at gcc dot gnu.org 2012-02-07 19:15:15 UTC --- Author: rsandifo Date: Tue Feb 7 19:15:10 2012 New Revision: 183977 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=183977 Log: gcc/ PR middle-end/24306 * config/mips/mips.c (mips_std_gimplify_va_arg_expr): New function. (mips_gimplify_va_arg_expr): Call it instead of std_gimplify_va_arg_expr. gcc/testsuite/ PR middle-end/24306 PR target/52154 * lib/target-supports.exp (check_effective_target_mips_eabi): New. * gcc.target/mips/va-arg-1.c: New test. Added: trunk/gcc/testsuite/gcc.target/mips/va-arg-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/mips/mips.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/lib/target-supports.exp
[Bug middle-end/24306] [4.0 Regression] va_arg gets confused when skipping over certain zero-sized types with -msse
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24306 --- Comment #19 from rsandifo at gcc dot gnu.org rsandifo at gcc dot gnu.org 2012-02-07 19:15:15 UTC --- Author: rsandifo Date: Tue Feb 7 19:15:10 2012 New Revision: 183977 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=183977 Log: gcc/ PR middle-end/24306 * config/mips/mips.c (mips_std_gimplify_va_arg_expr): New function. (mips_gimplify_va_arg_expr): Call it instead of std_gimplify_va_arg_expr. gcc/testsuite/ PR middle-end/24306 PR target/52154 * lib/target-supports.exp (check_effective_target_mips_eabi): New. * gcc.target/mips/va-arg-1.c: New test. Added: trunk/gcc/testsuite/gcc.target/mips/va-arg-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/mips/mips.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/lib/target-supports.exp
[Bug target/52152] MIPS ELF targets should use dbxelf.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52152 --- Comment #1 from rsandifo at gcc dot gnu.org rsandifo at gcc dot gnu.org 2012-02-07 19:18:33 UTC --- Author: rsandifo Date: Tue Feb 7 19:18:27 2012 New Revision: 183978 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=183978 Log: gcc/testsuite/ PR target/52152 * objc.dg/stabs-1.m: XFAIL for mips*-*-elf*. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/objc.dg/stabs-1.m
[Bug target/52155] loongson.h requires -flax-vector-conversions with newlib targets
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52155 --- Comment #1 from rsandifo at gcc dot gnu.org rsandifo at gcc dot gnu.org 2012-02-07 19:23:40 UTC --- Author: rsandifo Date: Tue Feb 7 19:23:35 2012 New Revision: 183979 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=183979 Log: gcc/testsuite/ PR target/52155 * gcc.target/mips/mips.exp (mips-dg-options): Handle xfail and target. * gcc.target/mips/loongson-shift-count-truncated-1.c: Force -mlong64 for MIPS ELF. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/mips/loongson-shift-count-truncated-1.c trunk/gcc/testsuite/gcc.target/mips/mips.exp
[Bug c++/52156] New: add warning for allocated array being converted to pointer to base
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52156
Bug #: 52156
Summary: add warning for allocated array being converted to
pointer to base
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: enhancement
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: r...@gcc.gnu.org
struct B { int i; B() : i(0) { } };
struct D : B { int j; D() : j(1) { }};
int main()
{
B* b = new D[2]; // warning
return b[1].i;
}
It might be a good idea to warn about this code, the allocated array cannot be
safely indexed or deleted through any type except D*
There should be a warning if a new-expression allocates an array of D and the
result undergoes pointer conversion to a type that is not cv D*
[Bug fortran/52153] REAL128 gives extended precision, not quad precision
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52153 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #1 from kargl at gcc dot gnu.org 2012-02-07 19:41:39 UTC --- (In reply to comment #0) As things currently stand, to obtain quad precision reals, I have to use REAL(16) or REAL*16, which is non-portable; I'd rather use REAL(REAL128). program foo use ISO_FORTRAN_ENV integer, parameter ::knd = selected_real_kind(p=30) real(REAL128) x real(knd) y print *, kind(x), kind(y) end program foo troutmask:sgk[208] gfc4x -o foo foo.f90 ./foo 10 16 Yes, this is problem. However, you can use standard conforming code to get at REAL(16) -- steve
[Bug c++/52156] add warning for allocated array being converted to pointer to base
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52156 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-02-07 Ever Confirmed|0 |1 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2012-02-07 20:08:07 UTC --- Confirmed, yes this direct assignment should have a warning.
[Bug c/43673] Incorrect warning: use of 'D' length modifier with 'a' type character
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43673 Ryan S. Arnold rsa at us dot ibm.com changed: What|Removed |Added CC||bergner at gcc dot gnu.org, ||rsa at us dot ibm.com --- Comment #1 from Ryan S. Arnold rsa at us dot ibm.com 2012-02-07 20:14:38 UTC --- This also warns with %Ha (_Decimal32) and %DDa (_Decimal128). I suspect that the correct way to deal with this is for the compiler to disable this warning (or enable this combination) when __STDC_DEC_FP__ is set, where __STDC_DEC_FP__ indicates BOTH the compiler and library conform to the DFP TR. Currently this define is unavailable due to the inability of the compiler to programmatically determine availability of libdfp at compile time. There is a proposed GLIBC/GCC patch to provide a facility to allow this introduced in the following email: http://sourceware.org/ml/libc-alpha/2009-04/msg5.html
[Bug tree-optimization/14617] [tree-ssa] suboptimal code ('0' = c c = '9') ? c - '0' : 0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14617 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed|2005-12-15 04:47:37 |2012-02-07 0:00 --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org 2012-02-07 20:18:59 UTC --- I have a patch which improves this to: bb 2: D.1957_3 = (unsigned int) c_2(D); D.1958_4 = D.1957_3 + 4294967248; if (D.1958_4 = 9) goto bb 3; else goto bb 4; bb 3: D.1961_5 = (int) c_2(D); D.1955_6 = D.1961_5 + -48; bb 4: # D.1955_1 = PHI D.1955_6(3), 0(2) --- CUT --- Note the addition is found via PRE on the RTL level though and then we convert it to the an ifconversion but we should able to find that on TREE Level.
[Bug tree-optimization/52157] New: Missing FRE because of sign change
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52157
Bug #: 52157
Summary: Missing FRE because of sign change
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: pins...@gcc.gnu.org
Take:
int f(int a)
{
unsigned int t = a;
t-=100;
if (t = 200 )
return a-100;
else
return t;
}
--- CUT ---
We should able to simplify this function just to:
int f(int a)
{
unsigned int t = a;
t-=100;
return t;
}
[Bug tree-optimization/52157] Missing FRE because of sign change
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52157 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Keywords||missed-optimization, TREE Blocks||14617 Severity|normal |enhancement
[Bug fortran/52158] New: Regression on character function with gfortran 4.7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52158 Bug #: 52158 Summary: Regression on character function with gfortran 4.7 Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: dam...@rouson.net A build from a snapshot of the development branch as of February 4 appears to have a regression on deferred-length character functions. The text below shows a test that compiles with gcc 4.6.2 but not with 4.7. $ cat character_function.F90 module foo_class implicit none type foo contains procedure :: bar end type contains function bar(this) class(foo) :: this character(:), allocatable :: bar end function end module $ /opt/local/bin/gfortran-mp-4.6 -c character_function.F90 $ /opt/local/bin/gfortran-mp-4.7 -c character_function.F90 character_function.F90:9.22: class(foo) :: this 1 Error: Deferred-length character component 'bar' at (1) is not yet supported $ /opt/local/bin/gfortran-mp-4.7 --version GNU Fortran (GCC) 4.7.0 20120204 (experimental) Damian
[Bug lto/52159] New: ICE when building qemu with GCC 4.7 trunk: cannot read LTO decls
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52159 Bug #: 52159 Summary: ICE when building qemu with GCC 4.7 trunk: cannot read LTO decls Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassig...@gcc.gnu.org ReportedBy: m...@use.net Using the attached tarball, which is the Ubuntu source package configured with CFLAGS=-O3 -flto -floop-block -floop-interchange and LDFLAGS=-O3 -flto: matt@matt-desktop:~/src/qemu-linaro-1.0.50-2012.01$ dh_auto_build -B system-build dh_auto_build: warning: line 1 of /home/matt/.config/dpkg/buildflags.conf mentions unknown flag BUILD_CONFIG dh_auto_build: warning: line 5 of /home/matt/.config/dpkg/buildflags.conf is invalid, it has been ignored. LINK x86_64-softmmu/qemu-system-x86_64 lto1: error: two or more sections for .gnu.lto_fprintf.4f35e9dac4cf72f5 lto1: internal compiler error: cannot read LTO decls from /tmp/cc9TN5Ma.ltrans1.o Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. lto-wrapper: gcc returned 1 exit status /usr/bin/ld.gold.real: fatal error: lto-wrapper failed collect2: error: ld returned 1 exit status make[1]: *** [qemu-system-x86_64] Error 1 make: *** [subdir-x86_64-softmmu] Error 2 dh_auto_build: make -j1 returned exit code 2 matt@matt-desktop:~/src/qemu-linaro-1.0.50-2012.01$ gcc --version gcc (GCC) 4.7.0 20120207 (experimental) Copyright (C) 2012 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. matt@matt-desktop:~/src/qemu-linaro-1.0.50-2012.01$ ld --version GNU gold (GNU Binutils for Ubuntu 2.22) 1.11 Copyright 2011 Free Software Foundation, Inc.
[Bug rtl-optimization/10050] ifcvt is not smart enough
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10050 --- Comment #10 from Andrew Pinski pinskia at gcc dot gnu.org 2012-02-07 21:05:24 UTC --- Note this optimized I think is invalid with the C11/C++11 memory model.
[Bug tree-optimization/21462] if statement not converted to MIN_EXPR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21462 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Depends on||10050 --- Comment #4 from Andrew Pinski pinskia at gcc dot gnu.org 2012-02-07 21:06:42 UTC --- Only Tst5 is not optimized, we need to do something like what is needed to be done for PR 10050. Note this optimization is invalid for the C11/C++ memory model.
[Bug tree-optimization/33158] missed store sinking opportunity
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33158 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Depends on||10050 --- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org 2012-02-07 21:07:41 UTC --- This is basically the same as PR 10050.
[Bug tree-optimization/24001] Simple redundancy not eliminated
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24001 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #8 from Andrew Pinski pinskia at gcc dot gnu.org 2012-02-07 21:10:52 UTC --- Tail merge (on the tree level) is able to optimize this one on the trunk
