[Bug c++/54769] C++ parser - dependent class method template not found if structure template with the same name is visible
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54769 --- Comment #1 from Daniel Krügler daniel.kruegler at googlemail dot com 2012-10-02 06:04:56 UTC --- In C++03 this was supposed to be ill-formed, but - as Mike Miller explained to me - with the acceptance of CWG (no kidding ;-)) http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html# this code should now become accepted.
[Bug target/54741] GCC 4.4, 4.5, 4.6 4.7 (probably 4.8) Generates un-usable code on AVX supported CPUs (FreeBSD)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54741 --- Comment #8 from M.S. Babaei ace.of.zerosync at gmail dot com 2012-10-02 07:14:32 UTC --- (In reply to comment #3) use disassemble from inside gdb and look for the faulting instruction. Sorry I'm not very familiar with GDB, but I assume you need this: (gdb) disassemble main Dump of assembler code for function main: 0x00400bc4 main+0:push %rbp 0x00400bc5 main+1:mov%rsp,%rbp 0x00400bc8 main+4:push %rbx 0x00400bc9 main+5:sub$0x48,%rsp 0x00400bcd main+9:lea-0x13(%rbp),%rax 0x00400bd1 main+13:mov%rax,%rdi 0x00400bd4 main+16:callq 0x400e7c _ZNSaISt4pairIKSsSsEEC2Ev 0x00400bd9 main+21:lea-0x13(%rbp),%rsi 0x00400bdd main+25:lea-0x12(%rbp),%rcx 0x00400be1 main+29:lea-0x11(%rbp),%rdx 0x00400be5 main+33:lea-0x50(%rbp),%rax 0x00400be9 main+37:mov%rsi,%r8 0x00400bec main+40:mov$0xa,%esi 0x00400bf1 main+45:mov%rax,%rdi 0x00400bf4 main+48:callq 0x400eb0 _ZNSt13unordered_mapISsSsSt4hashISsESt8equal_toISsESaISt4pairIKSsSsEEEC2EmRKS1_RKS3_RKS7_ 0x00400bf9 main+53:lea-0x13(%rbp),%rax 0x00400bfd main+57:mov%rax,%rdi 0x00400c00 main+60:callq 0x400e96 _ZNSaISt4pairIKSsSsEED2Ev 0x00400c05 main+65:mov$0x4016b2,%esi 0x00400c0a main+70:mov$0x602c40,%edi 0x00400c0f main+75:callq 0x4009f0 basic_ostreamIcT_ES5_PKc@plt 0x00400c14 main+80:mov$0x400a40,%esi 0x00400c19 main+85:mov%rax,%rdi 0x00400c1c main+88:callq 0x400a20 _ZNSolsEPFRSoS_E@plt 0x00400c21 main+93:mov$0x0,%ebx 0x00400c26 main+98:lea-0x50(%rbp),%rax 0x00400c2a main+102:mov%rax,%rdi 0x00400c2d main+105:callq 0x400dba _ZNSt13unordered_mapISsSsSt4hashISsESt8equal_toISsESaISt4pairIKSsSsEEED2Ev 0x00400c32 main+110:mov%ebx,%eax 0x00400c34 main+112:add$0x48,%rsp 0x00400c38 main+116:pop%rbx 0x00400c39 main+117:pop%rbp 0x00400c3a main+118:retq 0x00400c3b main+119:mov%rax,%rbx 0x00400c3e main+122:lea-0x13(%rbp),%rax 0x00400c42 main+126:mov%rax,%rdi 0x00400c45 main+129:callq 0x400e96 _ZNSaISt4pairIKSsSsEED2Ev 0x00400c4a main+134:mov%rbx,%rax 0x00400c4d main+137:mov%rax,%rdi 0x00400c50 main+140:callq 0x400a80 _Unwind_Resume@plt 0x00400c55 main+145:mov%rax,%rbx 0x00400c58 main+148:lea-0x50(%rbp),%rax 0x00400c5c main+152:mov%rax,%rdi 0x00400c5f main+155:callq 0x400dba _ZNSt13unordered_mapISsSsSt4hashISsESt8equal_toISsESaISt4pairIKSsSsEEED2Ev 0x00400c64 main+160:mov%rbx,%rax 0x00400c67 main+163:mov%rax,%rdi 0x00400c6a main+166:callq 0x400a80 _Unwind_Resume@plt End of assembler dump. If not then tell me the steps and I'll post what you need.
[Bug target/54741] GCC 4.4, 4.5, 4.6 4.7 (probably 4.8) Generates un-usable code on AVX supported CPUs (FreeBSD)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54741 --- Comment #9 from M.S. Babaei ace.of.zerosync at gmail dot com 2012-10-02 07:18:23 UTC --- (In reply to comment #7) Created attachment 28312 [details] A patch with fixed ChangeLog Now I'm at work. I'll try your patch to build GCC and post later.
[Bug tree-optimization/54776] New: [4.8 Regression] tramp3d-v4: 20% performance regression using -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54776 Bug #: 54776 Summary: [4.8 Regression] tramp3d-v4: 20% performance regression using -O3 Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: mar...@trippelsdorf.de With gcc-4.8 (--enable-checking=release): markus@x4 ~ % time c++ -w -O3 tramp3d-v4.cpp c++ -w -O3 tramp3d-v4.cpp 24.87s user 0.34s system 99% cpu 25.293 total markus@x4 ~ % ./a.out --cartvis 1.0 0.0 --rhomin 1e-8 -n 20 ... Time spent in iteration: 7.35642 With gcc-4.7.2: markus@x4 ~ % time c++ -w -O3 tramp3d-v4.cpp c++ -w -O3 tramp3d-v4.cpp 25.15s user 0.33s system 99% cpu 25.568 total markus@x4 ~ % ./a.out --cartvis 1.0 0.0 --rhomin 1e-8 -n 20 ... Time spent in iteration: 5.81199 LTO doesn't help much (gcc-4.8): markus@x4 ~ % time c++ -w -O3 -flto tramp3d-v4.cpp c++ -w -O3 -flto tramp3d-v4.cpp 45.78s user 0.95s system 99% cpu 47.012 total markus@x4 ~ % ./a.out --cartvis 1.0 0.0 --rhomin 1e-8 -n 20 ... Time spent in iteration: 7.2111 (For comparison here are some clang results: markus@x4 ~ % time clang++ -w -O3 tramp3d-v4.cpp clang++ -w -O3 tramp3d-v4.cpp 14.67s user 0.12s system 99% cpu 14.874 total markus@x4 ~ % ./a.out --cartvis 1.0 0.0 --rhomin 1e-8 -n 20 ... Time spent in iteration: 6.1923 markus@x4 ~ % time clang++ -w -O3 -flto tramp3d-v4.cpp clang++ -w -O3 -flto tramp3d-v4.cpp 20.28s user 0.16s system 99% cpu 20.535 total markus@x4 ~ % ./a.out --cartvis 1.0 0.0 --rhomin 1e-8 -n 20 ... Time spent in iteration: 4.47936 That's an almost 28% improvement due to -flto)
[Bug c++/54777] New: [C++11] Comma operator in constexpr environment can cause ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54777
Bug #: 54777
Summary: [C++11] Comma operator in constexpr environment can
cause ICE
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: daniel.krueg...@googlemail.com
Using gcc 4.8.0 20120923 (experimental) and compiler flags
-Wall -pedantic -std=c++11
the following code gives an ICE:
//-
struct array {
int data[1];
constexpr const int at(unsigned i)
{
return (i 1 ? 0 : throw 1), data[i];
//return i 1 ? data[i] : (throw 0, data[i]); // OK
}
};
int main() {
constexpr array a{};
constexpr int i = a.at(0);
}
//-
main.cpp||In function 'int main()':|
main.cpp|12| in constexpr expansion of 'a.array::at(0u)'|
main.cpp|12|internal compiler error: in adjust_temp_type, at
cp/semantics.c:6425|
The code should be accepted.
[Bug c++/54777] [C++11] Comma operator in constexpr environment can cause ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54777 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-10-02 CC||mpolacek at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org 2012-10-02 09:08:18 UTC --- Happens also with 4.7 HEAD.
[Bug tree-optimization/54713] [4.8 Regression] error: non-trivial conversion at assignment in gcc.c-torture/compile/pr53410-2.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54713 --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org 2012-10-02 09:18:38 UTC --- Created attachment 28322 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28322 gcc48-pr54713.patch Updated version of the verifier. This one doesn't pass regtest, e.g. g++.dg/torture/vshuf*.C fail, because non-gimplified CONSTRUCTORs with non-NULL indexes get into the IL from DECL_INITIAL during fold_stmt.
[Bug fortran/54778] New: an ICE on invalid OO code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54778 Bug #: 54778 Summary: an ICE on invalid OO code Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: sla...@staszic.waw.pl Hi, Enclosing below the steps to reproduce an ICE on an invalid OO code. HTH, Sylwester $ cat bug.f95 module bug_m implicit none type :: arr_t real, dimension(:,:), pointer :: at end type type :: bug_t class(arr_t), allocatable :: elements(:) end type contains function elem(this, i) type(bug_t), intent(in) :: this integer, intent(in) :: i class(arr_t) :: elem elem = this%elements(i) end function end module $ /usr/lib/gcc-snapshot/bin/gfortran bug.f95 bug.f95:14.2: function elem(this, i) 1 Error: CLASS variable 'elem' at (1) must be dummy, allocatable or pointer f951: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See file:///usr/share/doc/gcc-snapshot/README.Bugs for instructions. $ /usr/lib/gcc-snapshot/bin/gfortran --version GNU Fortran (Debian 20120930-1) 4.8.0 20120930 (experimental) [trunk revision 191865] Copyright (C) 2012 Free Software Foundation, Inc. GNU Fortran comes with NO WARRANTY, to the extent permitted by law. You may redistribute copies of GNU Fortran under the terms of the GNU General Public License. For more information about these matters, see the file named COPYING
[Bug tree-optimization/54776] [4.8 Regression] tramp3d-v4: 20% performance regression using -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54776 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-10-02 CC||hubicka at gcc dot gnu.org, ||rguenth at gcc dot gnu.org Target Milestone|--- |4.8.0 Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2012-10-02 09:52:17 UTC --- Confirmed. ISTR the inline predicate stuff is responsible - the flatten numbers are still ok, likewise the results with profile feedback. As for -flto, using -fwhole-program should be enough to get all possible speedup (and a nice reality check if -flto works for single-TU as well as -fwhole-program). Looks like tramp3d is no longer our primary benchmark focus ;)
[Bug testsuite/54772] vectorization broken in gfortran on x86_64-*-freebsd
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54772 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added CC||singhai at gcc dot gnu.org Component|middle-end |testsuite --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2012-10-02 09:53:19 UTC --- Testsuite issue after dumping re-org. Sharad - please close this bug if you think it is fixed by your patch.
[Bug rtl-optimization/54751] [4.8 Regression] slow compile time with rtl loop unroller
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54751 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2012-10-02 09:55:13 UTC --- Err, yes - please check with --enable-checking=release!
[Bug c++/54770] sibling call optimization is not applied where it ought to be
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54770 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2012-10-02 Ever Confirmed|0 |1
[Bug middle-end/54771] scan-ipa-dump failure in gfortran.dg/pr48636.f90
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54771 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target||x86_64-unknown-freebsd10.0 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2012-10-02 09:56:02 UTC --- Works for me on x86_64-linux.
[Bug target/53457] Accommodate non-compliant ioctl() on VxWorks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53457 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-10-02 Component|libstdc++ |target Ever Confirmed|0 |1 --- Comment #10 from Paolo Carlini paolo.carlini at oracle dot com 2012-10-02 09:56:34 UTC --- Ah I see. The problem is that he wants to do the work in a special way, otherwise if we had an unified patch ready to go in as-is I could do the work, of course. Please let me know if I can help (maybe Bruce Korb can do the preparatory work even if he cannot commit?!?). Anyway, this is now target.
[Bug c++/54769] [Core/1111] dependent class method template not found if structure template with the same name is visible
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54769 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-10-02 Summary|C++ parser - dependent |[Core/] dependent class |class method template not |method template not found |found if structure template |if structure template with |with the same name is |the same name is visible |visible | Ever Confirmed|0 |1 --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com 2012-10-02 09:57:55 UTC --- Ok, let's update the Summary then.
[Bug target/54741] GCC 4.4, 4.5, 4.6 4.7 (probably 4.8) Generates un-usable code on AVX supported CPUs (FreeBSD)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54741 --- Comment #10 from Uros Bizjak ubizjak at gmail dot com 2012-10-02 09:59:39 UTC --- (In reply to comment #7) Created attachment 28312 [details] A patch with fixed ChangeLog The patch looks OK, but please introduce some #defines: #define XCR_XFEATURE_ENABLED_MASK 0x0 #define XSTATE_FP 0x1 #define XSTATE_SSE 0x2 #define XSTATE_YMM 0x4 (Please see testsuite/gcc.target/i386/avx-os-support.h)
[Bug middle-end/54779] New: split FRAME variables back into pieces
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54779 Bug #: 54779 Summary: split FRAME variables back into pieces Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: ebotca...@gcc.gnu.org CC: jamb...@gcc.gnu.org Created attachment 28323 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28323 Original implementation When nested functions access local variables of their parent, the compiler creates a special FRAME local variable in the parent, which represents the non-local frame, and puts into it all the variables accessed non-locally. If these nested functions are later inlined into their parent, these FRAME variables generally remain unmodified and this has various drawbacks: 1) the frame of the parent is unnecessarily large, 2) scalarization of aggregates put into the FRAME variables is hindered, 3) debug info for scalars put into the FRAME variables is poor since VTA only works on GIMPLE registers. The attached patch makes it so that the compiler splits FRAME variables back into pieces when all the nested functions have been inlined. The transformation is implemented as a sub-pass of execute_update_addresses_taken. It also comes with a testcase. Prerequisite is revision 191970. * gimple.c (gimple_ior_addresses_taken_1): Handle non-local frame structures specially. * tree-ssa.c (lookup_decl_for_field): New static function. (split_nonlocal_frames_op): Likewise. (execute_update_addresses_taken): Break up non-local frame structures into variables when possible.
[Bug middle-end/54779] split FRAME variables back into pieces
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54779 --- Comment #1 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-10-02 10:12:11 UTC --- Created attachment 28324 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28324 Testcase
[Bug c++/54777] [C++11] Comma operator in constexpr environment can cause ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54777 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 | --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2012-10-02 10:18:27 UTC --- Created attachment 28325 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28325 gcc48-pr54777.patch Untested fix. Guess at least 4.7 and perhaps also 4.6 should get the fix.
[Bug c++/54777] [C++11] Comma operator in constexpr environment can cause ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54777 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.6.4
[Bug middle-end/54779] split FRAME variables back into pieces
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54779 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||missed-optimization Status|UNCONFIRMED |NEW Last reconfirmed||2012-10-02 CC||rguenth at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2012-10-02 10:29:42 UTC --- Confirmed.
[Bug tree-optimization/54735] [4.8 Regression] Segmentation fault in walk_aliased_vdefs_1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54735 --- Comment #8 from Richard Guenther rguenth at gcc dot gnu.org 2012-10-02 10:37:08 UTC --- It seems that SSA form is not up-to-date: ./cc1plus -quiet t.ii -O2 t.ii: In function 'void check_() [with NT = M; int s = 3]': t.ii:163:16: error: no immediate_use list check_() ^ for SSA_NAME: .MEM_62 in statement: # VUSE .MEM_62 __assert_fail (0); t.ii:163:16: internal compiler error: verify_ssa failed which is after PRE. So it might be the reduced testcase is not triggering the same bug as the original one. Tackling the PRE bug now (thus, -fno-tree-pre fixes it).
[Bug rtl-optimization/54751] [4.8 Regression] slow compile time with rtl loop unroller
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54751 --- Comment #4 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch 2012-10-02 10:39:41 UTC --- More reasonable with -enable-checking=release 4.8(checking=yes):~10min 4.8(checking=release): 1min28s. 4.7 : 0min58s maybe some of the checking is a bit excessive in this case.
[Bug debug/54774] insufficient debug info for strong typed enum
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54774 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2012-10-02 10:53:11 UTC --- Guess we'd need to either move ENUM_FIXED_UNDERLYING_TYPE_P bit (and possibly ENUM_UNDERLYING_TYPE convention) out of the FE to tree.h, or add a langhook to query that info from the FE (won't work well with LTO though, but there are tons of things that don't either).
[Bug target/50457] SH2A atomic functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50457 --- Comment #13 from Oleg Endo olegendo at gcc dot gnu.org 2012-10-02 10:57:59 UTC --- (In reply to comment #12) (In reply to comment #11) Created attachment 28321 [details] cleanup libgcc/config/sh/linux-atomic Works fine for me. (three leading underscores) You might get one extra underscore because embed-elf SH compiler uses one underscore as USER_LABEL_PREFIX. It's OK for linux which uses null USER_LABEL_PREFIX. I've got .long__sync_val_compare_and_swap_4 with sh4-unknown-linux-gnu gcc for that case. Thanks for the explanation! Patch submitted: http://gcc.gnu.org/ml/gcc-patches/2012-10/msg00162.html
[Bug tree-optimization/54735] [4.8 Regression] Segmentation fault in walk_aliased_vdefs_1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54735
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
CC||tom at codesourcery dot com
--- Comment #9 from Richard Guenther rguenth at gcc dot gnu.org 2012-10-02
11:17:08 UTC ---
Actually it's tail-merge. Thus, -fno-tree-tail-merge fixes it as well. We
enter update-ssa with
bb 9:
# .MEM_62 = VDEF .MEM_60
D.2632.m_col = 0;
if (a_32(D) == 0)
goto bb 10;
else
goto bb 34;
...
bb 10:
# VUSE .MEM_62
__assert_fail (0);
...
bb 18:
# .MEM_69 = VDEF .MEM_67
D.2632.m_col = 0;
# .MEM_70 = VDEF .MEM_69
D.2632.m_currentBlockRows = 1;
if (a_39(D) == 0)
goto bb 10;
else
goto bb 38;
thus the .MEM_64 use is not dominated by its definition. That's an
expected result from running tail-merge and is supposed to be fixed
by inserting a PHI node in bb 10 - and it does that.
What's the case is that:
static inline void
maybe_replace_use (use_operand_p use_p)
{
tree rdef = NULL_TREE;
tree use = USE_FROM_PTR (use_p);
tree sym = DECL_P (use) ? use : SSA_NAME_VAR (use);
if (marked_for_renaming (sym))
rdef = get_reaching_def (sym);
else if (is_old_name (use))
rdef = get_reaching_def (use);
if (rdef rdef != use)
SET_USE (use_p, rdef);
}
optimizes the rdef == use case but the reaching definition now is
bb 8:
# .MEM_62 = PHI .MEM_74(23), .MEM_70(15), .MEM_74(22)
# VUSE .MEM_62
__assert_fail (0);
and the use operand still has the old value (full SSA rewrite doesn't
require us to substitute .MEM everywhere). But it isn't in the immediate
use list because the name got just re-defined.
Patch:
Index: gcc/tree-into-ssa.c
===
--- gcc/tree-into-ssa.c (revision 191969)
+++ gcc/tree-into-ssa.c (working copy)
@@ -1770,12 +1770,20 @@ maybe_replace_use (use_operand_p use_p)
tree sym = DECL_P (use) ? use : SSA_NAME_VAR (use);
if (marked_for_renaming (sym))
-rdef = get_reaching_def (sym);
+{
+ rdef = get_reaching_def (sym);
+ /* The operand slot may still contain an SSA name but it will
+ be not in the immediate use list as all SSA names were
+re-defined. Do not shortcut the rdef == use case. */
+ if (rdef)
+ SET_USE (use_p, rdef);
+}
else if (is_old_name (use))
-rdef = get_reaching_def (use);
-
- if (rdef rdef != use)
-SET_USE (use_p, rdef);
+{
+ rdef = get_reaching_def (use);
+ if (rdef rdef != use)
+ SET_USE (use_p, rdef);
+}
}
[Bug c++/54770] sibling call optimization is not applied where it ought to be
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54770
Steven Bosscher steven at gcc dot gnu.org changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #2 from Steven Bosscher steven at gcc dot gnu.org 2012-10-02
11:44:41 UTC ---
Confirmed, complete test case:
-- 8 --
typedef long unsigned int size_t;
namespace std
{
using ::size_t;
class exception
{
public:
exception() throw() { }
virtual ~exception() throw();
};
class bad_alloc : public exception
{
public:
bad_alloc() throw() { }
virtual ~bad_alloc() throw();
};
struct nothrow_t { };
extern const nothrow_t nothrow;
}
inline void* operator new(std::size_t, void* __p) throw() { return __p; }
inline void operator delete (void*, void*) throw() { }
templatetypename T struct Intrusive
{
Intrusive(T * p = 0) : px(p) { if(px) incref(px); }
~Intrusive() { if(px) decref(px); }
T * operator-() const { return px; }
T * px;
};
struct Node;
typedef IntrusiveNode NodePtr;
struct Node
{
Node() : refcnt(0) {}
virtual ~Node() {}
virtual void H() {}
unsigned short refcnt;
friend void incref(Node * node) { ++node-refcnt; }
friend void decref(Node * node) { if(--node-refcnt == 0) delete node; }
};
struct MainNode : Node
{
MainNode(NodePtr const arg_) : Node(), arg(arg_) {}
virtual ~MainNode() {}
NodePtr arg;
virtual void H()
{
{
NodePtr tmp(arg);
this-~Node();
new(this) MainNode(tmp);
}
this-H();
}
};
int main()
{
NodePtr arg = NodePtr();
NodePtr root(new MainNode(arg));
root-H();
return 0;
}
-- 8 --
At trunk r191835, compiling with:
./xgcc -B. -S -O3 -fdump-tree-optimized-lineno t.C
Gives the call at line 58:
L6:
tmp ={v} {CLOBBER};
[t.C : 58:15] _13 = MEM[(int (*__vtbl_ptr_type) () *)prephitmp_29+16B];
[t.C : 58:16] OBJ_TYPE_REF(_13;this_3(D)-2) (this_3(D));
[t.C : 59:5] return;
[Bug tree-optimization/54735] [4.8 Regression] Segmentation fault in walk_aliased_vdefs_1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54735 --- Comment #10 from Martin Jambor jamborm at gcc dot gnu.org 2012-10-02 11:58:58 UTC --- I get the SSA verification failure even on the PR 54146 testcase (as opposed to the reduced one). Please re-assign to me if fixing that will cause the originally reported segfault to reemerge. Thanks.
[Bug tree-optimization/54735] [4.8 Regression] Segmentation fault in walk_aliased_vdefs_1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54735 --- Comment #11 from Markus Trippelsdorf markus at trippelsdorf dot de 2012-10-02 12:08:09 UTC --- It's the same bug. The only difference is that I use --enable-checking=release.
[Bug c++/54770] sibling call optimization is not applied where it ought to be
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54770
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2012-10-02
12:52:39 UTC ---
It is not tail call optimized (unless -std=c++11, which generates different
code and is tail call optimized btw), because points-to analysis thinks that
the this-H call in MainNode::H may use the tmp variable:
# .MEM_25 = PHI .MEM_27(6), .MEM_30(4)
# PT = nonlocal escaped
# prephitmp_29 = PHI pretmp_31(6), MEM[(voidD.45 *)_ZTV8MainNodeD.2389 +
16B](4)
L6:
# .MEM_11 = VDEF .MEM_25
tmpD.2422 ={v} {CLOBBER};
# VUSE .MEM_11
# PT = nonlocal escaped
_13 = MEM[(intD.9 (*__vtbl_ptr_typeD.2134) () *)prephitmp_29 + 16B];
# .MEM_14 = VDEF .MEM_11
# USE = nonlocal null { D.2320 D.2389 D.2422 } (glob)
# CLB = nonlocal null { D.2320 D.2389 D.2422 } (glob)
OBJ_TYPE_REF(_13;this_3(D)-2) (this_3(D));
# VUSE .MEM_14
return;
It is true that tmpD.2422 is addressable:
;;pred: 2 (EH,EXECUTABLE)
L4: [LP 1]
[MNT 5] # .MEM_15 = VDEF .MEM_8
# USE = nonlocal null { D.2320 D.2389 D.2422 } (glob)
# CLB = nonlocal null { D.2320 D.2389 D.2422 } (glob)
_ZN9IntrusiveI4NodeED1EvD.2361 (tmpD.2422);
resx 2
;;succ:
but here it is dominated by a clobber stmt for that variable. I wonder if PTA
could be thought something about TREE_CLOBBER_Ps, the question is what exactly.
Here the call is dominated by the clobber stmt and there is no stmt mentioning
that var in any way in between the clobber and the call. Only saying that a
var can't escape to calls dominated by a clobber stmt wouldn't be enough, if
e.g. a loop is unrolled, we could have
bar ();
foo (tmp);
bar ();
tmp ={v} {CLOBBER};
bar ();
foo (tmp);
bar ();
tmp ={v} {CLOBBER};
While it is ok to assume (I think) that tmp can't be used in the 3rd bar call,
in the 4th bar call it can be used.
[Bug tree-optimization/54735] [4.8 Regression] Segmentation fault in walk_aliased_vdefs_1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54735
--- Comment #12 from Richard Guenther rguenth at gcc dot gnu.org 2012-10-02
13:03:07 UTC ---
Actually that just papers over the real issue. The issue is that
cfg-cleanup runs before update-ssa and that removes a basic-block (9)
because we have
bb 8:
D.2778 ={v} {CLOBBER};
if (1 == 0)
goto bb 9;
else
goto bb 33;
bb 9:
# .MEM_62 = VDEF .MEM_60
D.2632.m_col = 0;
bb 10:
# VUSE .MEM_62
__assert_fail (0);
but as you can see this removes the definition for .MEM_62!
That is what confuses update-SSA (rightfully so - it re-assigns .MEM_62
to the inserted PHI node).
Which means we need to update virtual SSA form right here, before
calling cfgcleanup.
[Bug other/54761] FAIL log
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54761 --- Comment #7 from uros at gcc dot gnu.org 2012-10-02 13:14:29 UTC --- Author: uros Date: Tue Oct 2 13:14:25 2012 New Revision: 191981 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=191981 Log: PR other/54761 * configure.ac (EXTRA_FLAGS): New. * Makefile.am (AM_FLAGS): Add $(EXTRA_FLAGS). * configure, Makefile.in: Regenerate. Modified: trunk/libbacktrace/ChangeLog trunk/libbacktrace/Makefile.am trunk/libbacktrace/Makefile.in trunk/libbacktrace/configure trunk/libbacktrace/configure.ac
[Bug c++/54780] New: G++ does not find precompiled headers in some cases
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54780 Bug #: 54780 Summary: G++ does not find precompiled headers in some cases Classification: Unclassified Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: jpakk...@gmail.com Created attachment 28326 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28326 Some dummy sources demonstrating the issue Using GCC of Ubuntu Quantal, version gcc version 4.7.2 (Ubuntu/Linaro 4.7.2-2ubuntu1). Under some circumstances g++ does not find precompiled headers that are in the search path. I have attached a simple test case that demonstrates the issue. Just run compile.sh that comes with it and watch the output. In the test case there is a common.h header that includes a bunch of STL headers. It is in a subdirectory called hdir. The file is first precompiled and placed in the subdirectory pchdir. The script then compiles a bunch of files that include common.h but do very little else. Both pchdir and hdir are passed in with -I. The precompiled header is found and compilation is fast. Next the script copies common.h to the main directory and compiles the sources again using the exact same compiler switches. What happens is that g++ does not find the precompiled header, probably because it first looks in the source dir and finds common.h but not the corresponding pch and just stops looking. This makes the compilation very slow. Then the script copies the precompiled header to the main directory and compiles the files again. Now g++ finds the pch and compilation is again fast. Summing all this up: precompiled headers can not be used if the header is in the source directory and the pch is in some other directory which is included with -I. This is a problem when doing out-of-source builds.
[Bug other/54761] FAIL log
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54761 Uros Bizjak ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #8 from Uros Bizjak ubizjak at gmail dot com 2012-10-02 13:29:51 UTC --- Fixed.
[Bug c++/54770] sibling call optimization is not applied where it ought to be
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54770
--- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2012-10-02
13:31:24 UTC ---
Right now we only have control flow insensitive points to ESCAPED set, so I'm
afraid this is unfixable, unless we change that. Only with control flow
sensitive ESCAPED we'd be able to clear the tmp var out of the escaped set at
the CLOBBER point (but it would need to be kept in other points to sets, as we
could e.g. CSE pure/const calls that return the var's address).
Another example where control flow insensitive ESCAPED prevents some
optimizations:
struct S { char p[40]; };
void bar (struct S *);
void foo (void)
{
struct S a, b, c, d, e;
a.p[0] = 1;
b.p[0] = 1;
c.p[0] = 1;
d.p[0] = 1;
e.p[0] = 1;
a.p[0] = 2;
bar (a);
b.p[0] = 2;
bar (b);
c.p[0] = 2;
bar (c);
d.p[0] = 2;
bar (d);
e.p[0] = 2;
bar (e);
}
As we add all the vars into the ESCAPED set and consider it being used even by
the a call then, DSE can't optimize away the = 1 stores with the exception of
a.p[0] = 1;.
[Bug rtl-optimization/54457] [x32] Fail to combine 64bit index + constant
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54457 Uros Bizjak ubizjak at gmail dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #6 from Uros Bizjak ubizjak at gmail dot com 2012-10-02 13:31:34 UTC --- Fixed.
[Bug tree-optimization/54713] [4.8 Regression] error: non-trivial conversion at assignment in gcc.c-torture/compile/pr53410-2.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54713 --- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org 2012-10-02 13:43:13 UTC --- Author: jakub Date: Tue Oct 2 13:43:09 2012 New Revision: 191983 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=191983 Log: PR tree-optimization/54713 * expr.c (categorize_ctor_elements_1): Don't assume purpose is non-NULL. * tree-cfg.c (verify_gimple_assign_single): Add verification of vector CONSTRUCTORs. * tree-ssa-sccvn.c (vn_reference_lookup_3): For VECTOR_TYPE CONSTRUCTORs, don't do anything if element type is VECTOR_TYPE, and don't check index. * tree-vect-slp.c (vect_get_constant_vectors): VIEW_CONVERT_EXPR ctor elements first if their type isn't compatible with vector element type. Modified: trunk/gcc/ChangeLog trunk/gcc/expr.c trunk/gcc/tree-cfg.c trunk/gcc/tree-ssa-sccvn.c trunk/gcc/tree-vect-slp.c
[Bug c++/54780] G++ does not find precompiled headers in some cases
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54780 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2012-10-02 13:53:13 UTC --- (In reply to comment #0) Next the script copies common.h to the main directory and compiles the sources again using the exact same compiler switches. What happens is that g++ does not find the precompiled header, probably because it first looks in the source dir and finds common.h but not the corresponding pch and just stops looking. This makes the compilation very slow. This is by design. A header included as #include common.h looks in the current dir first, so the compiler looks for ./common.h.gch, then for ./common.h, then stops because it's found. The alternative would be to continue searching *every* other directory looking for common.h.gch, which would be *much* slower (there might be no PCH anywhere, so for projects that don't use PCH it would mean checking every single directory for every single header) Maybe the solution you want is to use #include common.h and add -I. to the compilation commands, ensuring that -Ipchdir comes before -I. because that will not start with the current dir, and will look for pchdir/common.h.gch first and will stop when found. Doing that makes all three steps in your script very fast.
[Bug c++/54770] sibling call optimization is not applied where it ought to be
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54770 --- Comment #5 from Andy Jost andy.m.jost at gmail dot com 2012-10-02 15:25:46 UTC --- Most of the technical discussion is over my head, I'm afraid. Is there a simple workaround? What if the body of H contains only a call to a non-inlineable function to do its work and then the recursive call back to H? For those of us using GCC to compile a functional language, tail recursion is a requirement. We either need to make sure the compiler uses it every time, or resort to more manual methods. The option to specify a required sibling call would be ideal (see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52067).
[Bug fortran/54778] [OOP] an ICE on invalid OO code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54778
janus at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Keywords||ice-on-invalid-code
Last reconfirmed||2012-10-02
CC||janus at gcc dot gnu.org
AssignedTo|unassigned at gcc dot |janus at gcc dot gnu.org
|gnu.org |
Ever Confirmed|0 |1
Summary|an ICE on invalid OO code |[OOP] an ICE on invalid OO
||code
--- Comment #1 from janus at gcc dot gnu.org 2012-10-02 16:12:50 UTC ---
Thanks for reporting. I can reproduce this on 4.7 and trunk.
Here is a patch to fix it:
Index: gcc/fortran/interface.c
===
--- gcc/fortran/interface.c(revision 191869)
+++ gcc/fortran/interface.c(working copy)
@@ -3386,7 +3386,8 @@ matching_typebound_op (gfc_expr** tb_base,
if (base-expr-ts.type == BT_CLASS)
{
-if (CLASS_DATA (base-expr) == NULL)
+if (CLASS_DATA (base-expr) == NULL
+|| !gfc_expr_attr (base-expr).class_ok)
continue;
derived = CLASS_DATA (base-expr)-ts.u.derived;
}
With this I get:
c0.f90:14.2:
function elem(this, i)
1
Error: CLASS variable 'elem' at (1) must be dummy, allocatable or pointer
c0.f90:18.4:
elem = this%elements(i)
1
Error: Variable must not be polymorphic in intrinsic assignment at (1) - check
that there is a matching specific subroutine for '=' operator
Regtesting now ...
[Bug middle-end/54649] [4.8 Regression] Go bootstrap failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54649 Dehao Chen dehao at google dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #6 from Dehao Chen dehao at google dot com 2012-10-02 16:37:44 UTC --- This bug has been fixed by: URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=191614 Log: 2012-09-21 Dehao Chen de...@google.com PR go/54649 * tree-eh.c (lower_try_finally_dup_block): Set the correct block for stmts in the duplicated EH block.
[Bug target/54741] GCC 4.4, 4.5, 4.6 4.7 (probably 4.8) Generates un-usable code on AVX supported CPUs (FreeBSD)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54741 --- Comment #11 from M.S. Babaei ace.of.zerosync at gmail dot com 2012-10-02 16:58:57 UTC --- Well well, something happened here!! This bug does not affect me anymore; Now with or without your patch the above example code works just fine! I even tried crypto++ which I had problem with in the past but it works fine too. # uname -a FreeBSD 13x17.localhost 9.1-PRERELEASE FreeBSD 9.1-PRERELEASE #0: Sat Sep 29 20:53:22 IRST 2012 babaei@13x17.localhost:/usr/obj/usr/src/sys/GENERIC amd64 Two days ago I upgraded my system to 9-STABLE branch (a development branch), looks like the FreeBSD folks implemented AVX support into thier kernel. Hopefully I kept the old kernel. I rebuilt GCC 4.7 with your patch (GCC 4.6.4 is my system wide GCC and I'll won't mess with that one). Then I booted to the old kernel and rebuilt the above example code and, hell yeah!! Your patch does the job, the program finished normally with 'Hello, World!' printed out on screen (Note: with old kernel without your patch, it still get killed by SIGILL). Since this is a development branch and is not out yet I believe your patch is still relevant. Because out there 9.0, 8.3 and 7.4 is being used by people. And one more thing. Your patch is little different from my 'driver-i386.c' file (gcc-4.7-20120929) and my patch command failed to merge it. I merged your patch manually which is attached.
[Bug target/54741] GCC 4.4, 4.5, 4.6 4.7 (probably 4.8) Generates un-usable code on AVX supported CPUs (FreeBSD)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54741 --- Comment #12 from M.S. Babaei ace.of.zerosync at gmail dot com 2012-10-02 17:00:28 UTC --- Created attachment 28327 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28327 After applying patch - gcc4.7
[Bug testsuite/54772] vectorization broken in gfortran on x86_64-*-freebsd
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54772 --- Comment #3 from Sharad Singhai singhai at gcc dot gnu.org 2012-10-02 17:19:14 UTC --- Author: singhai Date: Tue Oct 2 17:19:09 2012 New Revision: 191991 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=191991 Log: 2012-10-02 Sharad Singhai sing...@google.com PR testsuite/54772 * tree-vect-stmts.c (vectorizable_operation): Add missing return. testsuite/ChangeLog 2012-10-02 Sharad Singhai sing...@google.com PR testsuite/54772 * gfortran.dg/vect/vect.exp: Change verbose vectorizor dump options to fix test failures caused by r191883. * gcc.dg/tree-ssa/gen-vect-11.c: Likewise. * gcc.dg/tree-ssa/gen-vect-2.c: Likewise. * gcc.dg/tree-ssa/gen-vect-32.c: Likewise. * gcc.dg/tree-ssa/gen-vect-25.c: Likewise. * gcc.dg/tree-ssa/gen-vect-11a.c: Likewise. * gcc.dg/tree-ssa/gen-vect-26.c: Likewise. * gcc.dg/tree-ssa/gen-vect-11b.c: Likewise. * gcc.dg/tree-ssa/gen-vect-11c.c: Likewise. * gcc.dg/tree-ssa/gen-vect-28.c: Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/tree-ssa/gen-vect-11.c trunk/gcc/testsuite/gcc.dg/tree-ssa/gen-vect-11a.c trunk/gcc/testsuite/gcc.dg/tree-ssa/gen-vect-11b.c trunk/gcc/testsuite/gcc.dg/tree-ssa/gen-vect-11c.c trunk/gcc/testsuite/gcc.dg/tree-ssa/gen-vect-2.c trunk/gcc/testsuite/gcc.dg/tree-ssa/gen-vect-25.c trunk/gcc/testsuite/gcc.dg/tree-ssa/gen-vect-26.c trunk/gcc/testsuite/gcc.dg/tree-ssa/gen-vect-28.c trunk/gcc/testsuite/gcc.dg/tree-ssa/gen-vect-32.c trunk/gcc/testsuite/gfortran.dg/vect/vect.exp trunk/gcc/tree-vect-stmts.c
[Bug testsuite/54772] vectorization broken in gfortran on x86_64-*-freebsd
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54772 Sharad Singhai singhai at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED AssignedTo|unassigned at gcc dot |singhai at gcc dot gnu.org |gnu.org | --- Comment #4 from Sharad Singhai singhai at gcc dot gnu.org 2012-10-02 17:25:46 UTC --- Should be fixed with r191991.
[Bug middle-end/54781] New: [4.8 Regression] ICE in refs_may_alias_p_1, at tree-ssa-alias.c:1124
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54781 Bug #: 54781 Summary: [4.8 Regression] ICE in refs_may_alias_p_1, at tree-ssa-alias.c:1124 Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: bernhard.rosenkran...@linaro.org Created attachment 28328 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28328 Test case, not yet reduced $ /opt/android-toolchain-trunk/bin/arm-linux-androideabi-g++ -c -mfloat-abi=softfp -mfpu=neon -O2 -o out/target/product/maguro/obj/SHARED_LIBRARIES/libskia_intermediates/src/opts/SkBlitRow_opts_arm.o SkBlitRow_opts_arm.i external/skia/src/opts/SkBlitRow_opts_arm.cpp: In function 'void S32A_D565_Opaque_Dither_neon(uint16_t*, const SkPMColor*, int, U8CPU, int, int)': external/skia/src/opts/SkBlitRow_opts_arm.cpp:1681:1: internal compiler error: in refs_may_alias_p_1, at tree-ssa-alias.c:1124 } ^ Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions.
[Bug middle-end/54779] split FRAME variables back into pieces
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54779 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added CC||pinskia at gcc dot gnu.org --- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org 2012-10-02 17:48:23 UTC --- I thought I had an older bug report about this same thing but I cannot find it right now.
[Bug target/53457] Accommodate non-compliant ioctl() on VxWorks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53457 --- Comment #11 from rbmj at verizon dot net 2012-10-02 18:21:50 UTC --- I've tried to split it up as I think Bruce wanted; if you check the thread, those patches should all be ready.
[Bug middle-end/54781] [4.8 Regression] ICE in refs_may_alias_p_1, at tree-ssa-alias.c:1124
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54781 Bernhard Rosenkränzer Bernhard.Rosenkranzer at linaro dot org changed: What|Removed |Added Attachment #28328|0 |1 is obsolete|| --- Comment #1 from Bernhard Rosenkränzer Bernhard.Rosenkranzer at linaro dot org 2012-10-02 18:34:17 UTC --- Created attachment 28329 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28329 (Mostly) reduced test case
[Bug middle-end/54781] [4.8 Regression] ICE in refs_may_alias_p_1, at tree-ssa-alias.c:1124
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54781 --- Comment #2 from Bernhard Rosenkränzer Bernhard.Rosenkranzer at linaro dot org 2012-10-02 18:35:03 UTC --- $ /opt/android-toolchain-trunk/bin/arm-linux-androideabi-g++ -c -mfloat-abi=softfp -mfpu=neon -O2 bug54781.c bug54781.c: In function 'void bug54781(short unsigned int*, int, int)': bug54781.c:75:1: internal compiler error: in refs_may_alias_p_1, at tree-ssa-alias.c:1124 } ^ Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions.
[Bug testsuite/54772] vectorization broken in gfortran on x86_64-*-freebsd
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54772 --- Comment #5 from Steve Kargl sgk at troutmask dot apl.washington.edu 2012-10-02 18:48:12 UTC --- On Tue, Oct 02, 2012 at 05:25:46PM +, singhai at gcc dot gnu.org wrote: --- Comment #4 from Sharad Singhai singhai at gcc dot gnu.org 2012-10-02 17:25:46 UTC --- Should be fixed with r191991. Just tested an up-to-date tree. The problem is fixed. Thanks.
[Bug fortran/54778] [OOP] an ICE on invalid OO code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54778 --- Comment #2 from janus at gcc dot gnu.org 2012-10-02 19:00:34 UTC --- (In reply to comment #1) Regtesting now ... Finished successfully. Will commit as obvious.
[Bug fortran/54778] [OOP] an ICE on invalid OO code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54778 --- Comment #3 from janus at gcc dot gnu.org 2012-10-02 19:31:40 UTC --- Btw, here is a slightly simpler version of the test case with the same symptoms: implicit none type :: arr_t real :: at end type type(arr_t) :: this class(arr_t) :: elem elem = this end
[Bug middle-end/54782] New: [4.8 Regression] ICE: in change_scope, at final.c:1543 with -O -ffast-math -ftree-parallelize-loops=2 -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54782 Bug #: 54782 Summary: [4.8 Regression] ICE: in change_scope, at final.c:1543 with -O -ffast-math -ftree-parallelize-loops=2 -g Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: zso...@seznam.cz Created attachment 28330 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28330 reduced testcase Compiler output: $ gcc -O -ffast-math -ftree-parallelize-loops=2 -g testcase.c testcase.c: In function 'foo._loopfn.0': testcase.c:12:3: internal compiler error: in change_scope, at final.c:1543 for (i = 0; i s-n; i++) ^ 0x7980ea change_scope /mnt/svn/gcc-trunk/gcc/final.c:1543 0x79d68c reemit_insn_block_notes /mnt/svn/gcc-trunk/gcc/final.c:1613 0x79d68c final_start_function(rtx_def*, _IO_FILE*, int) /mnt/svn/gcc-trunk/gcc/final.c:1670 0x7a0585 rest_of_handle_final /mnt/svn/gcc-trunk/gcc/final.c:4291 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. Tested revisions: r191953 - crash r191586 - crash 4.7 r191640 - OK
[Bug target/54741] GCC 4.4, 4.5, 4.6 4.7 (probably 4.8) Generates un-usable code on AVX supported CPUs (FreeBSD)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54741 --- Comment #13 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org 2012-10-02 19:49:05 UTC --- Author: hjl Date: Tue Oct 2 19:49:01 2012 New Revision: 191998 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=191998 Log: Check SSE and YMM state support for -march=native 2012-10-02 H.J. Lu hongjiu...@intel.com PR target/54741 * config/i386/driver-i386.c (XCR_XFEATURE_ENABLED_MASK): New. (XSTATE_FP): Likewise. (XSTATE_SSE): Likewise. (XSTATE_YMM): Likewise. (host_detect_local_cpu): Disable AVX, AVX2, FMA, FMA4 and XOP if SSE and YMM states aren't supported. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/driver-i386.c
[Bug c++/53475] [4.8 Regression] Section type conflict errors in libstdc++ testsuite
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53475 --- Comment #9 from Bernhard Rosenkränzer Bernhard.Rosenkranzer at linaro dot org 2012-10-02 19:52:31 UTC --- This also happens when building iptables with gcc trunk, so it's not C++ related
[Bug rtl-optimization/54783] New: [4.8 Regression] valgrind reports using uninitialised data in mark_pseudo_regno_live and make_object_born on basic code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54783 Bug #: 54783 Summary: [4.8 Regression] valgrind reports using uninitialised data in mark_pseudo_regno_live and make_object_born on basic code Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: zso...@seznam.cz Created attachment 28331 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28331 reduced testcase Compiler output: $ gcc testcase.c -wrapper valgrind,-q,--track-origins=yes,--num-callers=40 ==11379== Conditional jump or move depends on uninitialised value(s) ==11379==at 0x8A14AD: mark_pseudo_regno_live(int) (sparseset.h:147) ==11379==by 0x8A27AC: process_bb_node_lives(ira_loop_tree_node*) (ira-lives.c:1326) ==11379==by 0x888C1A: ira_traverse_loop_tree(bool, ira_loop_tree_node*, void (*)(ira_loop_tree_node*), void (*)(ira_loop_tree_node*)) (ira-build.c:1495) ==11379==by 0x8A3AB1: ira_create_allocno_live_ranges() (ira-lives.c:1591) ==11379==by 0x88B52C: ira_build() (ira-build.c:3093) ==11379==by 0x883936: rest_of_handle_ira() (ira.c:4223) ==11379==by 0x8FF80C: execute_one_pass(opt_pass*) (passes.c:2191) ==11379==by 0x8FFBC4: execute_pass_list(opt_pass*) (passes.c:2246) ==11379==by 0x8FFBD6: execute_pass_list(opt_pass*) (passes.c:2247) ==11379==by 0x6C26A7: expand_function(cgraph_node*) (cgraphunit.c:1601) ==11379==by 0x6C4811: compile() (cgraphunit.c:1794) ==11379==by 0x6C4B34: finalize_compilation_unit() (cgraphunit.c:2080) ==11379==by 0x5A171F: c_write_global_declarations() (c-decl.c:10116) ==11379==by 0x9E6234: compile_file() (toplev.c:560) ==11379==by 0x9E7E09: toplev_main(int, char**) (toplev.c:1863) ==11379==by 0x5A334BC: (below main) (in /lib64/libc-2.15.so) ==11379== Uninitialised value was created by a heap allocation ==11379==at 0x4C29A80: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==11379==by 0x1168107: xmalloc (xmalloc.c:147) ==11379==by 0x9CC85F: sparseset_alloc(unsigned long) (sparseset.c:33) ==11379==by 0x8A3A3F: ira_create_allocno_live_ranges() (ira-lives.c:1583) ==11379==by 0x88B52C: ira_build() (ira-build.c:3093) ==11379==by 0x883936: rest_of_handle_ira() (ira.c:4223) ==11379==by 0x8FF80C: execute_one_pass(opt_pass*) (passes.c:2191) ==11379==by 0x8FFBC4: execute_pass_list(opt_pass*) (passes.c:2246) ==11379==by 0x8FFBD6: execute_pass_list(opt_pass*) (passes.c:2247) ==11379==by 0x6C26A7: expand_function(cgraph_node*) (cgraphunit.c:1601) ==11379==by 0x6C4811: compile() (cgraphunit.c:1794) ==11379==by 0x6C4B34: finalize_compilation_unit() (cgraphunit.c:2080) ==11379==by 0x5A171F: c_write_global_declarations() (c-decl.c:10116) ==11379==by 0x9E6234: compile_file() (toplev.c:560) ==11379==by 0x9E7E09: toplev_main(int, char**) (toplev.c:1863) ==11379==by 0x5A334BC: (below main) (in /lib64/libc-2.15.so) ==11379== ==11379== Conditional jump or move depends on uninitialised value(s) ==11379==at 0x8A138A: make_object_born(ira_object*) (sparseset.h:147) ==11379==by 0x8A14CA: mark_pseudo_regno_live(int) (ira-lives.c:295) ==11379==by 0x8A27AC: process_bb_node_lives(ira_loop_tree_node*) (ira-lives.c:1326) ==11379==by 0x888C1A: ira_traverse_loop_tree(bool, ira_loop_tree_node*, void (*)(ira_loop_tree_node*), void (*)(ira_loop_tree_node*)) (ira-build.c:1495) ==11379==by 0x8A3AB1: ira_create_allocno_live_ranges() (ira-lives.c:1591) ==11379==by 0x88B52C: ira_build() (ira-build.c:3093) ==11379==by 0x883936: rest_of_handle_ira() (ira.c:4223) ==11379==by 0x8FF80C: execute_one_pass(opt_pass*) (passes.c:2191) ==11379==by 0x8FFBC4: execute_pass_list(opt_pass*) (passes.c:2246) ==11379==by 0x8FFBD6: execute_pass_list(opt_pass*) (passes.c:2247) ==11379==by 0x6C26A7: expand_function(cgraph_node*) (cgraphunit.c:1601) ==11379==by 0x6C4811: compile() (cgraphunit.c:1794) ==11379==by 0x6C4B34: finalize_compilation_unit() (cgraphunit.c:2080) ==11379==by 0x5A171F: c_write_global_declarations() (c-decl.c:10116) ==11379==by 0x9E6234: compile_file() (toplev.c:560) ==11379==by 0x9E7E09: toplev_main(int, char**) (toplev.c:1863) ==11379==by 0x5A334BC: (below main) (in /lib64/libc-2.15.so) ==11379== Uninitialised value was created by a heap allocation ==11379==at 0x4C29A80: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==11379==by 0x1168107: xmalloc (xmalloc.c:147) ==11379==by 0x9CC85F: sparseset_alloc(unsigned long) (sparseset.c:33) ==11379==by 0x8A3A3F: ira_create_allocno_live_ranges() (ira-lives.c:1583) ==11379==by 0x88B52C: ira_build()
[Bug debug/54177] [4.8 Regression]: Segfault in cselib_lookup due to NULL_RTX passed from vt_add_function_parameter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54177 --- Comment #6 from Alexandre Oliva aoliva at gcc dot gnu.org 2012-10-02 19:58:41 UTC --- Author: aoliva Date: Tue Oct 2 19:58:37 2012 New Revision: 191999 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=191999 Log: PR debug/54177 * var-tracking.c (vt_add_function_parameter): Bail if var_lowpart fails. Modified: trunk/gcc/ChangeLog trunk/gcc/var-tracking.c
[Bug c++/53475] [4.8 Regression] Section type conflict errors in libstdc++ testsuite
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53475
--- Comment #10 from Bernhard Rosenkränzer Bernhard.Rosenkranzer at linaro dot
org 2012-10-02 20:00:07 UTC ---
Created attachment 28332
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28332
Shorter, plain C, test case extracted from iptables, not yet reduced
Adding shorter, plain C, test case
$ /opt/android-toolchain-trunk/bin/arm-linux-androideabi-gcc -O3
-fdata-sections -g -c -o test.o
libxt_CT.iout/target/product/maguro/obj/STATIC_LIBRARIES/libext_intermediates/libxt_CT.c:58:31:
error: exp_event_tbl causes a section type conflict with exp_event_tbl
static const struct event_tbl exp_event_tbl[] = {
^
[Bug debug/53135] [4.7/4.8 Regression] internal compiler error: in value_format, at dwarf2out.c:8010
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53135 --- Comment #12 from Alexandre Oliva aoliva at gcc dot gnu.org 2012-10-02 20:05:29 UTC --- Author: aoliva Date: Tue Oct 2 20:05:24 2012 New Revision: 192000 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=192000 Log: PR debug/53135 * dwarf2out.c (value_format): Use block4 for dw_val_class_loc when needed. Modified: trunk/gcc/ChangeLog trunk/gcc/dwarf2out.c
[Bug debug/54551] DF resets some DEBUG_INSNs unnecessarily
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54551 --- Comment #5 from Alexandre Oliva aoliva at gcc dot gnu.org 2012-10-02 20:06:13 UTC --- Author: aoliva Date: Tue Oct 2 20:06:08 2012 New Revision: 192001 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=192001 Log: gcc/ChangeLog: PR debug/54551 * Makefile.in (VALTRACK_H): Add hash-table.h. * valtrack.h: Include hash-table.h. (struct dead_debug_global_entry): New. (struct dead_debug_hash_descr): New. (struct dead_debug_global): New. (struct dead_debug): Rename to... (struct dead_debug_local): ... this. Adjust all uses. (dead_debug_global_init, dead_debug_global_finish): New. (dead_debug_init): Rename to... (dead_debug_local_init): ... this. Adjust all callers. (dead_debug_finish): Rename to... (dead_debug_local_finish): ... this. Adjust all callers. * valtrack.c (dead_debug_global_init): New. (dead_debug_init): Rename to... (dead_debug_local_init): ... this. Take global parameter. Save it and initialize used bitmap from it. (dead_debug_global_find, dead_debug_global_insert): New. (dead_debug_global_replace_temp): New. (dead_debug_promote_uses): New. (dead_debug_finish): Rename to... (dead_debug_local_finish): ... this. Promote remaining uses. (dead_debug_global_finish): New. (dead_debug_add): Try to replace global temps first. (dead_debug_insert_temp): Support global replacements. * dce.c (word_dce_process_block, dce_process_block): Add global_debug parameter. Pass it on. (fast_dce): Initialize, pass on and finalize global_debug. * df-problems.c (df_set_unused_notes_for_mw): Adjusted. (df_create_unused_notes, df_note_bb_compute): Likewise. (df_note_compute): Justify local-only dead debug analysis. gcc/testsuite/ChangeLog: PR debug/54551 * gcc.dg/guality/pr54551.c: New. Added: trunk/gcc/testsuite/gcc.dg/guality/pr54551.c Modified: trunk/gcc/ChangeLog trunk/gcc/Makefile.in trunk/gcc/dce.c trunk/gcc/df-problems.c trunk/gcc/testsuite/ChangeLog trunk/gcc/valtrack.c trunk/gcc/valtrack.h
[Bug fortran/54784] New: [oop] allocation of extended types with polymorphic allocatable members
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54784 Bug #: 54784 Summary: [oop] allocation of extended types with polymorphic allocatable members Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: jkoz...@gmail.com (Error also occurs with gcc 4.7.1) When I have a container module with stores a collection of polymorphics types, I sometimes get an error that a pointer is being freed which was not allocated. An example program is below. It can be compiled without errors gfortran bug.f90 It contains four modules each with an associated type. If the type 'block' in 'block_module' the member nFields is commented out the code runs fine. If a print statement is added in the program the code runs fine If the dimension of the member 'x' of types block_cart1d and block_cart2d are changed so that they are not 3 and 4 (only one must be changed), the program works. Finally, if the order in the program of the addBlock command is reversed the bug.f90 module block_module implicit none private public :: block type,abstract :: block ! if commented out code works fine integer ,private :: nFields = 0 end type block end module block_module module block1d_module use block_module, only : block type,extends(block) :: block1d real,dimension(:,:,:),allocatable,private :: fields end type end module module block2d_module use block_module, only : block type,extends(block) :: block2d real,dimension(:,:,:,:),allocatable,private :: fields end type end module module domain_module use block_module, only : block implicit none type :: list class(block),allocatable :: B end type type :: domain type(list),dimension(10) :: L contains procedure :: addBlock end type contains subroutine addBlock(this,i,b) implicit none class(domain),intent(inout) :: this integer,intent(in) :: i class(block),intent(in) :: b allocate(this%L(i)%B,source=b) end subroutine end module program bug use domain_module, only : domain use block1d_module, only : block1d use block2d_module, only : block2d implicit none type(domain) :: d type(block1d) :: b1 type(block2d) :: b2 ! crashes with pointer being freed was not allocated call d%addBlock(1,b1) call d%addBlock(2,b2) ! crashes with invalid memory reference ! call d%addBlock(2,b2) ! call d%addBlock(1,b1) ! runs fine ! call d%addBlock(1,b2) ! call d%addBlock(2,b1) end program bug
[Bug debug/54551] DF resets some DEBUG_INSNs unnecessarily
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54551 --- Comment #6 from Alexandre Oliva aoliva at gcc dot gnu.org 2012-10-02 20:16:33 UTC --- Fixed in the trunk. Backporting to 4.7...
[Bug debug/53135] [4.7/4.8 Regression] internal compiler error: in value_format, at dwarf2out.c:8010
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53135 --- Comment #13 from Alexandre Oliva aoliva at gcc dot gnu.org 2012-10-02 20:17:53 UTC --- The work around is installed in the trunk, and will soon be in the branch as well, but this should ideally be left open until we figure out a better way to avoid all the duplication that triggers the size explosion.
[Bug target/54785] New: -mprefer-avx128 is undocumented
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54785 Bug #: 54785 Summary: -mprefer-avx128 is undocumented Classification: Unclassified Product: gcc Version: 4.7.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: hjl.to...@gmail.com -mprefer-avx128 is added to GCC 4.7, but isn't documented.
[Bug target/54785] -mprefer-avx128 is undocumented
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54785 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added CC||ubizjak at gmail dot com Target Milestone|--- |4.7.3
[Bug other/53889] Gthreads doesn't support destroying recursive mutexes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53889 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2012-10-02 20:22:40 UTC --- Author: redi Date: Tue Oct 2 20:22:32 2012 New Revision: 192002 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=192002 Log: libgcc: PR other/53889 * gthr.h (__gthread_recursive_mutex_destroy): Document new required function. * gthr-posix.h (__gthread_recursive_mutex_destroy): Define. * gthr-single.h (__gthread_recursive_mutex_destroy): Likewise. * config/gthr-rtems.h (__gthread_recursive_mutex_destroy): Likewise. * config/gthr-vxworks.h (__gthread_recursive_mutex_destroy): Likewise. * config/i386/gthr-win32.h (__gthread_recursive_mutex_destroy): Likewise. * config/mips/gthr-mipssde.h (__gthread_recursive_mutex_destroy): Likewise. * config/pa/gthr-dce.h (__gthread_recursive_mutex_destroy): Likewise. * config/s390/gthr-tpf.h (__gthread_recursive_mutex_destroy): Likewise. libstdc++-v3: PR other/53889 * include/std/mutex (__recursive_mutex_base::~__recursive_mutex_base): Use __gthread_recursive_mutex_destroy. (__recursive_mutex_base::_S_destroy): Remove. (__recursive_mutex_base::_S_destroy_win32): Likewise. * include/ext/concurrence.h (__recursive_mutex::~__recursive_mutex): Use __gthread_recursive_mutex_destroy. (__recursive_mutex::_S_destroy): Remove. (__recursive_mutex::_S_destroy_win32): Likewise. Modified: trunk/libgcc/ChangeLog trunk/libgcc/config/gthr-rtems.h trunk/libgcc/config/gthr-vxworks.h trunk/libgcc/config/i386/gthr-win32.c trunk/libgcc/config/i386/gthr-win32.h trunk/libgcc/config/mips/gthr-mipssde.h trunk/libgcc/config/pa/gthr-dce.h trunk/libgcc/config/s390/gthr-tpf.h trunk/libgcc/gthr-posix.h trunk/libgcc/gthr-single.h trunk/libgcc/gthr.h trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/ext/concurrence.h trunk/libstdc++-v3/include/std/mutex
[Bug tree-optimization/54717] [4.8 Regression] Runtime regression: polyhedron test rnflow degraded
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54717 --- Comment #8 from Dominique d'Humieres dominiq at lps dot ens.fr 2012-10-02 20:23:42 UTC --- Created attachment 28333 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28333 bzipped tar archive of a reduced test The tar archive contains the files cptrf2_inl_1.f90 rnflow.in rnflow_red.f90 rnfprm.h and can be used as in [macbook] dbg_rnflow/pr54717% gfc -c -Ofast -funroll-loops rnflow_red.f90 [macbook] dbg_rnflow/pr54717% gfc -c -O2 cptrf2_inl_1.f90 [macbook] dbg_rnflow/pr54717% gfc rnflow_red.o cptrf2_inl_1.o [macbook] dbg_rnflow/pr54717% time a.out /dev/null 21.036u 0.051s 0:21.09 99.9%0+0k 0+0io 0pf+0w [macbook] dbg_rnflow/pr54717% gfc -c -O2 -ftree-loop-if-convert cptrf2_inl_1.f90 [macbook] dbg_rnflow/pr54717% gfc rnflow_red.o cptrf2_inl_1.o [macbook] dbg_rnflow/pr54717% time a.out /dev/null 27.150u 0.051s 0:27.20 100.0%0+0k 0+0io 0pf+0w This shows that the file cptrf2_inl_1.f90 compiled with -ftree-loop-if-convert gives a slow executable without involving inlining or vectorization.
[Bug other/53889] Gthreads doesn't support destroying recursive mutexes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53889 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.8.0 --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org 2012-10-02 20:24:41 UTC --- libgcc changes approved by Ian: http://gcc.gnu.org/ml/gcc-patches/2012-10/msg00123.html This is fixed for 4.8
[Bug target/54741] GCC 4.4, 4.5, 4.6 4.7 (probably 4.8) Generates un-usable code on AVX supported CPUs (FreeBSD)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54741 --- Comment #14 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org 2012-10-02 20:25:13 UTC --- Author: hjl Date: Tue Oct 2 20:25:04 2012 New Revision: 192003 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=192003 Log: Check SSE and YMM state support for -march=native Backported from mainline PR target/54741 * config/i386/driver-i386.c (XCR_XFEATURE_ENABLED_MASK): New. (XSTATE_FP): Likewise. (XSTATE_SSE): Likewise. (XSTATE_YMM): Likewise. (host_detect_local_cpu): Disable AVX, AVX2, FMA, FMA4 and XOP if SSE and YMM states aren't supported. Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/config/i386/driver-i386.c
[Bug c++/53475] [4.8 Regression] Section type conflict errors in libstdc++ testsuite
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53475
Bernhard Rosenkränzer Bernhard.Rosenkranzer at linaro dot org changed:
What|Removed |Added
Attachment #28332|0 |1
is obsolete||
--- Comment #11 from Bernhard Rosenkränzer Bernhard.Rosenkranzer at linaro dot
org 2012-10-02 20:26:32 UTC ---
Created attachment 28334
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28334
Reduced test case
Attaching reduced test case
$ /opt/android-toolchain-trunk/bin/arm-linux-androideabi-gcc -O3
-fdata-sections -g -c -o test.o bug53475.c
bug53475.c:5:23: error: b causes a section type conflict with b
static const struct a b[] = {
^
[Bug target/54741] GCC 4.4, 4.5, 4.6 4.7 (probably 4.8) Generates un-usable code on AVX supported CPUs (FreeBSD)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54741 --- Comment #15 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org 2012-10-02 20:31:43 UTC --- Author: hjl Date: Tue Oct 2 20:31:40 2012 New Revision: 192004 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=192004 Log: Check SSE and YMM state support for -march=native Backported from mainline PR target/54741 * config/i386/driver-i386.c (XCR_XFEATURE_ENABLED_MASK): New. (XSTATE_FP): Likewise. (XSTATE_SSE): Likewise. (XSTATE_YMM): Likewise. (host_detect_local_cpu): Disable AVX, FMA, FMA4 and XOP if SSE and YMM states aren't supported. Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/config/i386/driver-i386.c
[Bug target/54741] GCC 4.4, 4.5, 4.6 4.7 (probably 4.8) Generates un-usable code on AVX supported CPUs (FreeBSD)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54741 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED Target Milestone|--- |4.6.4 --- Comment #16 from H.J. Lu hjl.tools at gmail dot com 2012-10-02 20:32:39 UTC --- Fixed.
[Bug libstdc++/54786] New: Missing fence in std::atomicT::store() triggers wrong reordering.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54786
Bug #: 54786
Summary: Missing fence in std::atomicT::store() triggers
wrong reordering.
Classification: Unclassified
Product: gcc
Version: 4.6.3
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ozabl...@gmail.com
CC: hans_bo...@hp.com
Host: x86_64-linux-gnu
Target: x86_64-linux-gnu
Build: x86_64-linux-gnu
Created attachment 28335
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28335
Preprocessed source
In the standard publish idiom:
#include atomic
double d;
std::atomicint aflag(0);
void publish() {
d = 1.0;
aflag = 1;
}
store to d is reordered (sunk) after store to aflag:
_Z7publishv:
.LFB382:
.cfi_startproc
movabsq$4607182418800017408, %rax
movl$1, aflag(%rip) #== store to aflag
movq%rax, d(%rip) #== store to d
mfence
ret
The reason for it is that in include/c++/4.6/bits/atomic_2.h store() is missing
needed __sync_synchronize() before non-atomic write:
void
store(__int_type __i, memory_order __m = memory_order_seq_cst)
{
__glibcxx_assert(__m != memory_order_acquire);
__glibcxx_assert(__m != memory_order_acq_rel);
__glibcxx_assert(__m != memory_order_consume);
if (__m == memory_order_relaxed)
_M_i = __i;
else
{
// write_mem_barrier(); //OZ: Missing __sync_synchronize();
_M_i = __i;
if (__m == memory_order_seq_cst)
__sync_synchronize();
}
}
Incidentally, load() has unnecessary barrier before non-atomic read:
__int_type
load(memory_order __m = memory_order_seq_cst) const
{
__glibcxx_assert(__m != memory_order_release);
__glibcxx_assert(__m != memory_order_acq_rel);
__sync_synchronize(); //OZ: unnecessary
__int_type __ret = _M_i;
__sync_synchronize();
return __ret;
}
And by unnecessary, I don't mean just for publish, but ever.
$ g++-4.6 -v -save-temps --std=c++0x -O2 -c reorder.cpp
Using built-in specs.
COLLECT_GCC=g++-4.6
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.6/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
4.6.3-1ubuntu5' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.6 --enable-shared --enable-linker-build-id
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object
--enable-plugin --enable-objc-gc --disable-werror --with-arch-32=i686
--with-tune=generic --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++0x' '-O2' '-c' '-shared-libgcc'
'-mtune=generic' '-march=x86-64'
/usr/lib/gcc/x86_64-linux-gnu/4.6/cc1plus -E -quiet -v -imultilib .
-imultiarch x86_64-linux-gnu -D_GNU_SOURCE reorder.cpp -mtune=generic
-march=x86-64 -std=c++0x -O2 -fpch-preprocess -fstack-protector -o reorder.ii
ignoring nonexistent directory /usr/local/include/x86_64-linux-gnu
ignoring nonexistent directory
/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../x86_64-linux-gnu/include
#include ... search starts here:
#include ... search starts here:
/usr/include/c++/4.6
/usr/include/c++/4.6/x86_64-linux-gnu/.
/usr/include/c++/4.6/backward
/usr/lib/gcc/x86_64-linux-gnu/4.6/include
/usr/local/include
/usr/lib/gcc/x86_64-linux-gnu/4.6/include-fixed
/usr/include/x86_64-linux-gnu
/usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++0x' '-O2' '-c' '-shared-libgcc'
'-mtune=generic' '-march=x86-64'
/usr/lib/gcc/x86_64-linux-gnu/4.6/cc1plus -fpreprocessed reorder.ii -quiet
-dumpbase reorder.cpp -mtune=generic -march=x86-64 -auxbase reorder -O2
-std=c++0x -version -fstack-protector -o reorder.s
GNU C++ (Ubuntu/Linaro 4.6.3-1ubuntu5) version 4.6.3 (x86_64-linux-gnu)
compiled by GNU C version 4.6.3, GMP version 5.0.2, MPFR version 3.1.0-p3,
MPC version 0.9
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++ (Ubuntu/Linaro 4.6.3-1ubuntu5) version 4.6.3 (x86_64-linux-gnu)
compiled by GNU C version 4.6.3, GMP version 5.0.2, MPFR version 3.1.0-p3,
[Bug libstdc++/54786] Missing fence in std::atomicT::store() triggers wrong reordering.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54786 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Severity|major |normal --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2012-10-02 20:37:01 UTC --- I think this has been fixed in 4.7.0 as it uses __atomic_store now instead.
[Bug libstdc++/54786] Missing fence in std::atomicT::store() triggers wrong reordering.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54786 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.7.0 --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org 2012-10-02 20:39:31 UTC --- Note in 4.6.x we don't say we fully support C++11. Even in 4.7.x we don't say we do but it is much closer and even closer in implementing C++11/C11's (threading) memory models.
[Bug c/54787] New: Inconsistent -Wtype-limits warning for different-sized bitfields
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54787 Bug #: 54787 Summary: Inconsistent -Wtype-limits warning for different-sized bitfields Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: h...@gcc.gnu.org Host: x86_64-unknown-linux-gnu For the attached test-case, GCC warns inconsistently: it warns when the bit-field is 8 bits, but not 7 nor 9 bits. The c++ front-end warns consistently for all three lines. Observed with trunk r191987, the 4.7 branch (r191916, post 4.7.2), the 4.6 branch (r191812, post4.6.3) as well as local imports from the 4.3-branch and the host compiler, gcc-4.4.3-4.fc12.x86_64). Other targets include crisv32-axis-linux-gnu and mipsisa32r2el-linux-gnu. Example output (note absence of warnings for lines 28 and 30): gcc -Wtype-limits -O2 -c range.c /n/pp_slask/hp/range.c: In function 'main': /n/pp_slask/hp/range.c:29: warning: comparison is always true due to limited range of data type There's a related need to turn off the warning per-expression, to avoid the need to turn it off per-file (by adding -Wno-error=type-limits to compilations using the common idiom of -Werror together with warnings that include -Wtype-limits).
[Bug c/54787] Inconsistent -Wtype-limits warning for different-sized bitfields
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54787 --- Comment #1 from Hans-Peter Nilsson hp at gcc dot gnu.org 2012-10-02 20:47:50 UTC --- Created attachment 28336 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28336 test-case
[Bug fortran/54778] [OOP] an ICE on invalid OO code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54778 --- Comment #4 from janus at gcc dot gnu.org 2012-10-02 21:02:20 UTC --- Author: janus Date: Tue Oct 2 21:02:16 2012 New Revision: 192005 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=192005 Log: 2012-10-02 Janus Weil ja...@gcc.gnu.org PR fortran/54778 * interface.c (matching_typebound_op): Check for 'class_ok' attribute. 2012-10-02 Janus Weil ja...@gcc.gnu.org PR fortran/54778 * gfortran.dg/class_53.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/class_53.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/interface.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/54778] [OOP] an ICE on invalid OO code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54778 janus at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #5 from janus at gcc dot gnu.org 2012-10-02 21:07:43 UTC --- Fixed with r192005. Closing. Thanks again for the report!
[Bug target/54785] -mprefer-avx128 is undocumented
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54785 --- Comment #1 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org 2012-10-02 21:11:24 UTC --- Author: hjl Date: Tue Oct 2 21:11:21 2012 New Revision: 192007 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=192007 Log: Document -mprefer-avx128 PR target/54785 * doc/invoke.texi: Document -mprefer-avx128. Modified: trunk/gcc/ChangeLog trunk/gcc/doc/invoke.texi
[Bug target/54785] -mprefer-avx128 is undocumented
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54785 --- Comment #2 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org 2012-10-02 21:12:55 UTC --- Author: hjl Date: Tue Oct 2 21:12:50 2012 New Revision: 192008 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=192008 Log: Document -mprefer-avx128 Backported from mainline PR target/54785 * doc/invoke.texi: Document -mprefer-avx128. Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/doc/invoke.texi
[Bug target/54785] -mprefer-avx128 is undocumented
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54785 --- Comment #3 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org 2012-10-02 21:24:51 UTC --- Author: hjl Date: Tue Oct 2 21:24:45 2012 New Revision: 192009 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=192009 Log: Document -mprefer-avx128 Backported from mainline PR target/54785 * doc/invoke.texi: Document -mprefer-avx128. Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/doc/invoke.texi
[Bug target/54785] -mprefer-avx128 is undocumented
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54785 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|4.7.3 |4.6.4 --- Comment #4 from H.J. Lu hjl.tools at gmail dot com 2012-10-02 21:29:10 UTC --- Fixed for 4.6.4, 4.7,3 and 4.8.0.
[Bug fortran/54788] New: ICE on pointer-array element assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54788 Bug #: 54788 Summary: ICE on pointer-array element assignment Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: sla...@staszic.waw.pl Hello, I'm sending below a short code causing an ICE of gfortran. HTH, Sylwester P.S. BTW, could you help me in understanding the following error message: $ cat question.f90 program question type :: arr_t real, pointer :: arr(:,:) end type class(arr_t), pointer :: vec(:) allocate(vec(2)) allocate(vec(0)%arr(4,4)) vec(1) = vec(0) end $ gfortran question.f90 question.f90:8.2: vec(1) = vec(0) 1 Error: Expected bounds specification for 'vec' at (1) In principle, I'm trying to define a vector of pointers to arrays, and make two elements of this vector point to the same array. -- $ cat bug.f90 program bug integer, pointer :: a(:) integer :: b allocate(a(0:0)) a(0:0) = b end $ /usr/lib/gcc-snapshot/bin/gfortran bug.f90 f951: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See file:///usr/share/doc/gcc-snapshot/README.Bugs for instructions. $ /usr/lib/gcc-snapshot/bin/gfortran --version GNU Fortran (Debian 20120930-1) 4.8.0 20120930 (experimental) [trunk revision 191865] Copyright (C) 2012 Free Software Foundation, Inc. GNU Fortran comes with NO WARRANTY, to the extent permitted by law. You may redistribute copies of GNU Fortran under the terms of the GNU General Public License. For more information about these matters, see the file named COPYING
[Bug fortran/54784] [OOP] allocation of extended types with polymorphic allocatable members
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54784 janus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Keywords||wrong-code Last reconfirmed||2012-10-02 CC||janus at gcc dot gnu.org Ever Confirmed|0 |1 Summary|[oop] allocation of |[OOP] allocation of |extended types with |extended types with |polymorphic allocatable |polymorphic allocatable |members |members --- Comment #1 from janus at gcc dot gnu.org 2012-10-02 21:51:49 UTC --- Thanks for reporting this. I can reproduce it with 4.7 and trunk. Here is a reduced test case: program bug implicit none type :: block real, allocatable :: fields end type type :: list class(block),allocatable :: B end type type :: domain type(list),dimension(2) :: L end type type(domain) :: d type(block) :: b1 allocate(d%L(2)%B,source=b1) end program bug This fails at runtime with: Program received signal SIGSEGV: Segmentation fault - invalid memory reference. Backtrace for this error: #0 0x7F379D1FDA97 #1 0x7F379D1FE074 #2 0x7F379C72ED9F #3 0x400804 in __copy_bug_Block at bug.f90:9 #4 0x40097C in bug at bug.f90:19 (discriminator 2) Segmentation fault valgrind shows: ==11046== Invalid read of size 8 ==11046==at 0x400804: __copy_bug_Block (bug.f90:9) ==11046==by 0x40097C: MAIN__ (bug.f90:19) ==11046==by 0x400A88: main (bug.f90:21) ==11046== Address 0x0 is not stack'd, malloc'd or (recently) free'd
[Bug libstdc++/54786] Missing fence in std::atomicT::store() triggers wrong reordering.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54786 --- Comment #3 from Oleg Zabluda ozabluda at gmail dot com 2012-10-02 22:04:37 UTC --- I can confirm that it is fixed in 4.7.0, after the move to __atomic builtins, at least on x86_64. It would be nice to have it fixed in currently hypothetical 4.6.4, especially for those whose distro is stuck on 4.6. But at least it's documented now and users can act accordingly. For example add __sync_syncronise() or asm volatile (:::memory) before atomic::store().
[Bug fortran/54784] [OOP] allocation of extended types with polymorphic allocatable members
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54784 --- Comment #2 from Jeremy Kozdon jkozdon at gmail dot com 2012-10-02 22:14:57 UTC --- So there is actually two different bugs, one is the invalid memory reference which happens when you don't allocate in order. There is a second, the one I was really trying to report, and that's when allocating in my original example type(block1d) before type(block2d), namely the call call d%addBlock(1,b1) call d%addBlock(2,b2) as opposed to call d%addBlock(1,b2) call d%addBlock(2,b1) This gives the error: a.out(4678) malloc: *** error for object 0x7fff82ec09be: pointer being freed was not allocated *** set a breakpoint in malloc_error_break to debug Program received signal SIGABRT: Process abort signal. Backtrace for this error: #0 0x14fbe #1 0x156d4 #2 0x7fff82f1f1b9 Abort trap (In reply to comment #1) Thanks for reporting this. I can reproduce it with 4.7 and trunk. Here is a reduced test case: program bug implicit none type :: block real, allocatable :: fields end type type :: list class(block),allocatable :: B end type type :: domain type(list),dimension(2) :: L end type type(domain) :: d type(block) :: b1 allocate(d%L(2)%B,source=b1) end program bug This fails at runtime with: Program received signal SIGSEGV: Segmentation fault - invalid memory reference. Backtrace for this error: #0 0x7F379D1FDA97 #1 0x7F379D1FE074 #2 0x7F379C72ED9F #3 0x400804 in __copy_bug_Block at bug.f90:9 #4 0x40097C in bug at bug.f90:19 (discriminator 2) Segmentation fault valgrind shows: ==11046== Invalid read of size 8 ==11046==at 0x400804: __copy_bug_Block (bug.f90:9) ==11046==by 0x40097C: MAIN__ (bug.f90:19) ==11046==by 0x400A88: main (bug.f90:21) ==11046== Address 0x0 is not stack'd, malloc'd or (recently) free'd
[Bug driver/54789] New: [4.8 Regression] Error in GCC driver when defining GCC_COMPARE_DEBUG
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54789 Bug #: 54789 Summary: [4.8 Regression] Error in GCC driver when defining GCC_COMPARE_DEBUG Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver AssignedTo: unassig...@gcc.gnu.org ReportedBy: d.g.gorbac...@gmail.com GCC 4.8.0 20120930 (experimental) $ gcc -fcompare-debug=-gtoggle a.c $ GCC_COMPARE_DEBUG=yes gcc a.c gcc: error: unrecognized command line option '-fcompare-debug=-gtoggle'
[Bug fortran/54784] [OOP] allocation of extended types with polymorphic allocatable members
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54784 --- Comment #3 from janus at gcc dot gnu.org 2012-10-02 22:35:57 UTC --- (In reply to comment #2) So there is actually two different bugs Or the two different errors you are seeing are really due to the same underlying problem. I'm not quite sure about that yet, but I already have a suspicion ... one is the invalid memory reference which happens when you don't allocate in order. There is a second, the one I was really trying to report, and that's when allocating in my original example type(block1d) before type(block2d), namely the call call d%addBlock(1,b1) call d%addBlock(2,b2) Would be great if you could try to find a maximally reduced test for this case, too. That would definitely help a lot. In the meantime, I will start looking at the case in comment 1 ...
[Bug fortran/54784] [OOP] allocation of extended types with polymorphic allocatable members
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54784
--- Comment #4 from janus at gcc dot gnu.org 2012-10-02 22:45:31 UTC ---
(In reply to comment #1)
allocate(d%L(2)%B,source=b1)
The code generated for this line has two parts: The allocation and the copying
from the source. While the first part looks fine, it seems there is a problem
in the second. -fdump-tree-original shows:
{
struct block D.1890;
struct list[2] * D.1889;
D.1889 = d.l;
D.1890 = b1;
{
integer(kind=8) S.0;
S.0 = 1;
while (1)
{
if (S.0 2) goto L.1;
__vtab_bug_Block._copy (D.1890, (*D.1889)[S.0 + -1].b._data);
S.0 = S.0 + 1;
}
L.1:;
}
}
In principle only one element of the array 'd.l' should be copied. However, it
seems like the while loop does a copy for each element!
[Bug fortran/54784] [OOP] allocation of extended types with polymorphic allocatable members
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54784 janus at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |janus at gcc dot gnu.org |gnu.org | --- Comment #5 from janus at gcc dot gnu.org 2012-10-02 23:43:42 UTC --- The following patch seems to cure the test case in comment 1, as well as both variants in comment 0: Index: gcc/fortran/trans-stmt.c === --- gcc/fortran/trans-stmt.c(revision 192004) +++ gcc/fortran/trans-stmt.c(working copy) @@ -5145,7 +5145,9 @@ gfc_trans_allocate (gfc_code * code) dataref = actual-next-expr-ref; /* Make sure we go up through the reference chain to the _data reference, where the arrayspec is found. */ - while (dataref-next dataref-next-type != REF_ARRAY) + while (!(dataref-type == REF_COMPONENT +strcmp (dataref-u.c.component-name, _data) == 0) + dataref-next) dataref = dataref-next; if (dataref-u.c.component-as)
[Bug fortran/54788] ICE on pointer-array element assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54788 janus at gcc dot gnu.org changed: What|Removed |Added CC||janus at gcc dot gnu.org --- Comment #1 from janus at gcc dot gnu.org 2012-10-03 00:01:59 UTC --- I think both programs are invalid and should be rejected. The error message for the first one is misleading, to say the least. I don't quite understand it either. Note: integer, pointer :: a(:) defines a pointer to an array, and not an array of pointers. Therefore a(0:0) is an element (or rather an array section) of the array which is pointed to by a. It is not a pointer itself and can not be used in a pointer assignment context.
[Bug libstdc++/54786] Missing fence in std::atomicT::store() triggers wrong reordering.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54786 --- Comment #4 from Andrew Pinski pinskia at gcc dot gnu.org 2012-10-03 00:56:25 UTC --- (In reply to comment #3) I can confirm that it is fixed in 4.7.0, after the move to __atomic builtins, at least on x86_64. It would be nice to have it fixed in currently hypothetical 4.6.4, especially for those whose distro is stuck on 4.6. But at least it's documented now and users can act accordingly. For example add __sync_syncronise() or asm volatile (:::memory) before atomic::store(). Considering this is in an experimental part of the compiler (stdc++0x is consider experimental for 4.6), I say you are out of luck from support from the FSF. You can request your distro to have the fix backported though.
[Bug c/54787] Inconsistent -Wtype-limits warning for different-sized bitfields
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54787 --- Comment #2 from Hans-Peter Nilsson hp at gcc dot gnu.org 2012-10-03 03:31:27 UTC --- (In reply to comment #0) ...need to turn it off per-file (by adding -Wno-error=type-limits to compilations using the common idiom of -Werror together with warnings that include -Wtype-limits). Correction: -Wno-error=type-limits only turns off the error-generating property of the warning when used with -Werror; it does not turn off the warning itself. (To turn off the warning, use -Wno-type-limits.)
[Bug debug/53135] [4.7/4.8 Regression] internal compiler error: in value_format, at dwarf2out.c:8010
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53135 --- Comment #14 from Alexandre Oliva aoliva at gcc dot gnu.org 2012-10-03 04:02:43 UTC --- Author: aoliva Date: Wed Oct 3 04:02:38 2012 New Revision: 192021 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=192021 Log: PR debug/53135 * dwarf2out.c (value_format): Use block4 for dw_val_class_loc when needed. Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/dwarf2out.c
