[Bug fortran/54384] gfortran memory leaks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54384 --- Comment #8 from Tobias Burnus 2012-08-28 05:37:37 UTC --- (In reply to comment #0) > With gfortran.dg/proc_ptr_result_1.f90: > by 0x5F0D3C: gfc_copy_formal_args(gfc_symbol*, gfc_symbol*, ifsrc) That issue is now fixed by comment 7 - the others remain.
[Bug fortran/54384] gfortran memory leaks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54384 --- Comment #7 from Tobias Burnus 2012-08-28 05:35:22 UTC --- Author: burnus Date: Tue Aug 28 05:35:15 2012 New Revision: 190738 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190738 Log: 2012-08-28 Tobias Burnus PR fortran/54384 * symbol.c (gfc_copy_formal_args): Set also sym->formal_ns. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/symbol.c
[Bug libstdc++/54388] New: std::array.at() const results in undefined behaviour
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54388
Bug #: 54388
Summary: std::array.at() const results in undefined behaviour
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: lukeallard...@yahoo.co.uk
array line 166:
#ifdef __EXCEPTIONS
constexpr const_reference
at(size_type __n) const
{
return __n < _Nm ?
_M_instance[__n] : throw out_of_range(__N("array::at"));
}
#else
const_reference
at(size_type __n) const
{
return __n < _Nm ?
_M_instance[__n] : __throw_out_of_range(__N("array::at"));
}
#endif
Refer to
http://stackoverflow.com/questions/12136394/issue-with-bounds-checking-a-member-stdarray-inside-a-const-function
A conditional with a throw operand evaluates to a prvalue, which expires at the
end of the return statement.
[Bug target/49743] -g enables var_tracking on -O0 - causes long compilations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49743 --- Comment #3 from Gary Funck 2012-08-28 02:20:38 UTC --- Recently, I've been reviewing changes that we made on the GUPC branch (see comment #2) that are candidates for the trunk revision (or in this case, possibly the 4.7 branch). Index: gcc/config/darwin.c === --- gcc/config/darwin.c (.../trunk) (revision 190707) +++ gcc/config/darwin.c (.../branches/gupc) (revision 190718) @@ -3039,6 +3039,7 @@ darwin_override_options (void) } if (flag_var_tracking + && optimize >= 1 && generating_for_darwin_version >= 9 && (flag_gtoggle ? (debug_info_level == DINFO_LEVEL_NONE) : (debug_info_level >= DINFO_LEVEL_NORMAL)) Reading the problem description, unless the option scanning logic has changed for Darwin, it looks as if this change might still be necessary to suppress var tracking at -O0?
[Bug tree-optimization/53395] [4.8 Regression] The LAPACK functions i(d|s)amax are more than two times slower after revision 187183
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53395 --- Comment #8 from Andrew Pinski 2012-08-28 01:18:17 UTC --- Created attachment 28091 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28091 New patch based on Richard's comments Testing a new fix which includes Richard's comments.
[Bug tree-optimization/54132] [4.8 Regression] Incorrect loop transformation with -ftree-loop-distribute-patterns
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54132 --- Comment #2 from Mans Rullgard 2012-08-28 00:10:48 UTC --- I came upon another couple of cases where I believe this bug is causing wrong code. Let me know if you need more tests, and I'll reduce them.
[Bug fortran/54387] Proc-pointer: Wronlgy accepts non-proc result variable on the RHS of a pointer assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54387 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #1 from Tobias Burnus 2012-08-27 22:23:31 UTC --- As postscript: (Intel, g95 and (with target attribute) PGI also accept the program of comment 0.) Crayftn correctly rejects the program of comment 0: i => foo ! Invalid RHS - in this context "foo" the RESULT variable ^ Invalid proc-target for this procedure pointer assignment statement. For the following, the diagnostic works and one gets the message: Error: Expected a procedure for argument 'x' at (1) function foo() integer :: foo call bar(foo) contains subroutine bar(x) integer, external :: x end subroutine bar end
[Bug fortran/54375] FAIL: gfortran.dg/realloc_on_assign_14.f90
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54375 John David Anglin changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #4 from John David Anglin 2012-08-27 22:17:50 UTC --- Fixed.
[Bug fortran/54387] New: Proc-pointer: Wronlgy accepts non-proc result variable on the RHS of a pointer assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54387 Bug #: 54387 Summary: Proc-pointer: Wronlgy accepts non-proc result variable on the RHS of a pointer assignment Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Keywords: accepts-invalid Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org CC: ja...@gcc.gnu.org Found by James Van Buskirk in c.l.f's "Function questions?" thread: https://groups.google.com/forum/?fromgroups=#!topic/comp.lang.fortran/r4PVbtaBnFM The following program is invalid as "foo" inside the function is the result variable - hence "i => foo" doesn't make sense. function foo() integer :: foo procedure(), pointer :: i i => foo ! Invalid RHS - in this context "foo" the RESULT variable ! To use the procedure name, a RESULT(...) has to be specified end
[Bug target/46254] ICE: in find_reloads, at reload.c:3806 (unable to generate reloads) with -fPIC -mcmodel={medium|large} and __sync_val_compare_and_swap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46254 Uros Bizjak changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-08-27 AssignedTo|unassigned at gcc dot |ubizjak at gmail dot com |gnu.org | Target Milestone|--- |4.7.2 Ever Confirmed|0 |1
[Bug target/46254] ICE: in find_reloads, at reload.c:3806 (unable to generate reloads) with -fPIC -mcmodel={medium|large} and __sync_val_compare_and_swap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46254 --- Comment #1 from uros at gcc dot gnu.org 2012-08-27 21:13:13 UTC --- Author: uros Date: Mon Aug 27 21:13:07 2012 New Revision: 190732 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190732 Log: PR target/46254 * config/i386/predicates.md (cmpxchg8b_pic_memory_operand): Return true for TARGET_64BIT or !flag_pic. * config/i386/sync.md (*atomic_compare_and_swap_doubledi_pic): Remove. (atomic_compare_and_swap_double): Change operand 2 predicate to cmpxchg8b_pic_memory_operand. Use DWIH mode iterator. Add insn constraint. Conditionally emit xchg asm insns. (atomic_compare_and_swap): Update calls. Check only cmpxchg8b_pic_memory_operand in memory address fixup. (DCASMODE): Remove. (CASHMODE): Rename from DCASHMODE. (doublemodesuffix): Update modes. (regprefix): New mode attribute. (unspecv) : Remove. : New constant. (atomic_compare_and_swap_1): Rename from atomic_compare_and_swap_single. Update calls and unspec_volatile constants. (atomic_compare_and_swap_doubleword): Rename from atomic_compare_and_swap_double. Update calls and unspec_volatile constants. testsuite/ChangeLog: PR target/46254 * gcc.target/i386/pr46254.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr46254.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/predicates.md trunk/gcc/config/i386/sync.md trunk/gcc/testsuite/ChangeLog
[Bug fortran/54384] gfortran memory leaks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54384 --- Comment #6 from Tobias Burnus 2012-08-27 20:54:53 UTC --- (In reply to comment #4) > Others still not tested, but doduc.f90 fails with: This one (and hence all of doduc.f90) - and some of the failures in aermod.f90 are fixed with comment 5. TODO: * match_data_constant (mbdx.f90, comment 5) * gfortran.dg/proc_ptr_result_1.f90 (comment 0) * aermod.f90: by 0x5F0EC7: gfc_new_symbol(char const*, gfc_namespace*) (symbol.c:2569) by 0x5F1242: gfc_get_sym_tree(char const*, gfc_namespace*, gfc_symtree**, bool) (symbol.c:2753) by 0x5F12C3: gfc_get_symbol(char const*, gfc_namespace*, gfc_symbol**) (symbol.c:2807) by 0x57184A: gfc_match_formal_arglist(gfc_symbol*, int, int) (decl.c:4462) by 0x573E65: gfc_match_subroutine() (decl.c:5655) -- and -- by 0x5F0B1E: gfc_get_namespace(gfc_namespace*, int) (symbol.c:2325) by 0x5C064E: parse_spec(gfc_statement) (parse.c:2390) by 0x5C2318: parse_progunit(gfc_statement) (parse.c:4131) by 0x5C3243: gfc_parse_file() (parse.c:4579) -- and -- by 0x57F00F: gfc_get_expr() (expr.c:49) by 0x57F973: gfc_copy_expr(gfc_expr*) (expr.c:272) by 0x56BBD4: gfc_assign_data_value(gfc_expr*, gfc_expr*, __mpz_struct*, __mpz_struct (*) [1]) (data.c:60) by 0x5D86DB: traverse_data_var(gfc_data_variable*, locus*) (resolve.c:13341) by 0x5D8C0D: traverse_data_var(gfc_data_variable*, locus*) (resolve.c:13426) by 0x5D9E83: resolve_types(gfc_namespace*) (resolve.c:13525) -- and -- some more * gfortran.dg/g77/cpp6.f: by 0x5DE174: preprocessor_line(unsigned int*) (scanner.c:1803) by 0x5DE6EA: load_file(char const*, char const*, bool) (scanner.c:2038) by 0x5E0422: gfc_new_file() (scanner.c:2106)
[Bug fortran/54384] gfortran memory leaks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54384 --- Comment #5 from Tobias Burnus 2012-08-27 20:51:57 UTC --- Author: burnus Date: Mon Aug 27 20:51:52 2012 New Revision: 190731 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190731 Log: 2012-08-27 Tobias Burnus PR fortran/54384 * resolve.c (gfc_resolve_character_operator): Free temporary variables. * trans-expr.c (gfc_conv_statement_function): Ditto. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/fortran/trans-expr.c
[Bug libstdc++/54376] incorrect complaint about redefinition
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54376 --- Comment #16 from Paolo Carlini 2012-08-27 20:40:39 UTC --- Thanks. I will make sure to apply the library changes to the branch too.
[Bug target/49263] SH Target: underutilized "TST #imm, R0" instruction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49263
Oleg Endo changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Last reconfirmed||2012-08-27
Resolution|FIXED |
AssignedTo|unassigned at gcc dot |olegendo at gcc dot gnu.org
|gnu.org |
Ever Confirmed|0 |1
--- Comment #18 from Oleg Endo 2012-08-27
19:51:42 UTC ---
Not quite so done, actually. The following example case does not work
properly:
void test00 (int* x, int xb)
{
if (! (xb & 128))
x[0] = 0;
}
-O2 -m4:
mov r5,r0
and #128,r0
tst r0,r0
bf .L3
mov.l r0,@r4
.L3:
rts
nop
void test01 (int* x, int xb)
{
if (! (xb & 0x55))
x[0] = 0;
}
-O2 -m4:
mov r5,r0
and #85,r0
tst r0,r0
bf .L7
mov.l r0,@r4
.L7:
rts
nop
It seems that combine is trying to look for the following patterns:
Failed to match this instruction:
(set (pc)
(if_then_else (ne (zero_extract:SI (reg:SI 5 r5 [ xb ])
(const_int 1 [0x1])
(const_int 7 [0x7]))
(const_int 0 [0]))
(label_ref:SI 15)
(pc)))
Failed to match this instruction:
(set (pc)
(if_then_else (ne (and:SI (reg:SI 5 r5 [ xb ])
(const_int 85 [0x55]))
(const_int 0 [0]))
(label_ref:SI 15)
(pc)))
Another case that could see some improvement ...
bool test04 (int* x, int xb)
{
return ! (xb & 0x55);
}
-O2 -m4 (OK):
mov r5,r0
tst #85,r0
rts
movtr0
bool test02 (int* x, int xb)
{
return ! (xb & (1 << 6));
}
-O2 -m4 (NG):
mov r5,r0
mov #-6,r1
shldr1,r0
xor #1,r0
rts
and #1,r0
[Bug middle-end/54386] New: Unaligned mem load wrongly generated for inlined inline/static function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54386
Bug #: 54386
Summary: Unaligned mem load wrongly generated for inlined
inline/static function
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: olege...@gcc.gnu.org
Target: sh*-*-*
I've tested this only on SH, but it might be a generic case.
The following code snippet...
static __inline__ int
__testbit (unsigned long nr, unsigned long* a)
{
return (*a & (1 << nr)) != 0;
}
typedef struct page2
{
void* x[2];
unsigned long flags;
void* a;
void* b;
} page2_t;
void activate_page3(struct page2 * page)
{
if ( ! __testbit (7, &(page->flags)) )
{
page->a = 0;
page->b = 0;
}
}
...compiled with -O2 expands to the following RTL:
void activate_page3(page2*) (struct page2 * page)
{
long unsigned int _4;
long unsigned int _7;
;; basic block 2, loop depth 0
;;pred: ENTRY
_4 = MEM[(long unsigned int *)page_2(D) + 8B];
_7 = _4 & 128;
if (_7 == 0)
goto ;
else
goto ;
;;succ: 3
;;4
;; basic block 3, loop depth 0
;;pred: 2
page_2(D)->a = 0B;
page_2(D)->b = 0B;
;;succ: 4
;; basic block 4, loop depth 0
;;pred: 2
;;3
return;
;;succ: EXIT
}
;; Generating RTL for gimple basic block 2
;; if (_7 == 0)
(insn 7 5 8 (set (reg:QI 165)
(mem:QI (plus:SI (reg/v/f:SI 162 [ page ])
(const_int 8 [0x8])) [0+0 S1 A8])) sh_tmp.cpp:699 -1
(nil))
(insn 8 7 9 (set (reg:SI 163)
(zero_extend:SI (reg:QI 165))) sh_tmp.cpp:699 -1
(nil))
(insn 9 8 11 (set (reg:SI 166)
(ashift:SI (reg:SI 163)
(const_int 24 [0x18]))) sh_tmp.cpp:699 -1
(nil))
(insn 11 9 12 (set (reg:QI 169)
(mem:QI (plus:SI (reg/v/f:SI 162 [ page ])
(const_int 9 [0x9])) [0+1 S1 A8])) sh_tmp.cpp:699 -1
(nil))
[...]
For some reason the SI mem access is converted to four QI mem accesses, which
looks like an unaligned load. Since only one QI part is needed of the QI loads
disappear after the combine pass has done its thing.
On the other hand, removing 'static' and 'inline' for the function __testbit,
like:
int
__testbit (unsigned long nr, unsigned long* a)
would still do the inlining (as expected) and expand to (aligned) SI mem load:
void activate_page3(page2*) (struct page2 * page)
{
long unsigned int _6;
long unsigned int _7;
;; basic block 2, loop depth 0
;;pred: ENTRY
_6 = MEM[(long unsigned int *)page_2(D) + 8B];
_7 = _6 & 128;
if (_7 == 0)
goto ;
else
goto ;
;;succ: 3
;;4
;; basic block 3, loop depth 0
;;pred: 2
page_2(D)->a = 0B;
page_2(D)->b = 0B;
;;succ: 4
;; basic block 4, loop depth 0
;;pred: 2
;;3
return;
;;succ: EXIT
}
;; Generating RTL for gimple basic block 2
;; if (_7 == 0)
(insn 6 5 7 (set (reg:SI 164)
(mem:SI (plus:SI (reg/v/f:SI 162 [ page ])
(const_int 8 [0x8])) [2 MEM[(long unsigned int *)page_2(D) +
8B]+0 S4 A32])) swap.i:20 -1
(nil))
(insn 7 6 8 (set (reg:SI 163 [ D.1692 ])
(and:SI (reg:SI 164)
(const_int 128 [0x80]))) swap.i:20 -1
(nil))
The unaligned loads are generated if the __testbit function is
- 'static'
- 'inline'
- 'static inline'
sh-elf-gcc -v
Using built-in specs.
COLLECT_GCC=sh-elf-gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/sh-elf/4.8.0/lto-wrapper
Target: sh-elf
Configured with: ../gcc-trunk-van/configure --target=sh-elf --prefix=/usr/local
--enable-languages=c,c++ --enable-multilib --disable-libssp --disable-nls
--disable-werror --enable-lto --with-newlib --with-gnu-as --with-gnu-ld
--with-system-zlib
Thread model: single
gcc version 4.8.0 20120827 (experimental) (GCC)
[Bug fortran/54384] gfortran memory leaks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54384 --- Comment #4 from Tobias Burnus 2012-08-27 18:52:29 UTC --- (In reply to comment #0) > With Polyhedron 2005's nf.f90: > With Polyhedron 2005's capacita.f90: Those are fixed by comment 3 > With Polyhedron 2005's capacita.f90 (and some more): I think that's aermod.f90 not capacita.f90 - the latter has no leaks any more. > With Polyhedron 2005's mdbx.f90: > by 0x57D7BF: gfc_get_expr() (expr.c:49) > by 0x57E123: gfc_copy_expr(gfc_expr*) (expr.c:272) > by 0x5C63EA: gfc_match_rvalue(gfc_expr**) (primary.c:2788) > by 0x56D3A2: match_data_constant(gfc_expr**) (decl.c:354) Reduced test case: DIMENSION cmul(3,7) PARAMETER (HALF=0.5D0,ONE=1.D0,TWO=2.D0,FOUR=4.D0,TWELVE=12.D0) PARAMETER (SQRT2=1.41421356237310D0,SQRT3=1.73205080756888D0, & & SQRT8=TWO*SQRT2,SQ8BY3=SQRT8/SQRT3,SQ4BY3=TWO/SQRT3, & & SQ16B3=FOUR/SQRT3) DATA cmul/SQRT2 , SQRT2 , SQRT2 , ONE , ONE , SQRT8 , ONE , & & SQRT2 , TWO , ONE , SQRT3 , SQ8BY3 , ONE , SQRT3 , SQ8BY3 , & & ONE , ONE , SQRT8 , SQ4BY3 , SQ4BY3 , SQ16B3/ END Not fixing this issue, but I think still required: --- a/gcc/fortran/data.c +++ b/gcc/fortran/data.c @@ -142,2 +142,4 @@ create_character_initializer (gfc_expr *init, gfc_typespec *ts, gfc_extract_int (end_expr, &end); + gfc_free_expr (start_expr); + gfc_free_expr (end_expr); } > Also leaking, but I lost the overview whether those are already covered: > doduc.f90. Others still not tested, but doduc.f90 fails with: by 0x63624D: _ZL22gfc_conv_function_exprP6gfc_seP8gfc_expr.part.22 (trans-expr.c:4999) by 0x63951B: gfc_conv_expr_op(gfc_se*, gfc_expr*) (trans-expr.c:2158) by 0x63951B: gfc_conv_expr_op(gfc_se*, gfc_expr*) (trans-expr.c:2158) by 0x638553: gfc_conv_expr_val(gfc_se*, gfc_expr*) (trans-expr.c:5851) by 0x638620: gfc_conv_unary_op(tree_code, gfc_se*, gfc_expr*) (trans-expr.c:1535) by 0x639AFF: gfc_conv_expr_op(gfc_se*, gfc_expr*) (trans-expr.c:2031) by 0x6394F6: gfc_conv_expr_op(gfc_se*, gfc_expr*) (trans-expr.c:2153) by 0x63C163: gfc_trans_assignment_1(gfc_expr*, gfc_expr*, bool, bool) (trans-expr.c:7278)
[Bug fortran/54384] gfortran memory leaks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54384 --- Comment #3 from Tobias Burnus 2012-08-27 18:48:03 UTC --- Author: burnus Date: Mon Aug 27 18:47:57 2012 New Revision: 190728 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190728 Log: 2012-08-27 Tobias Burnus PR fortran/54384 * dependency.c (check_section_vs_section): Use gfc_free_expr instead of free. * trans-intrinsic.c (conv_generic_with_optional_char_arg): Use gfc_free_symbol instead of free. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/dependency.c trunk/gcc/fortran/trans-intrinsic.c
[Bug libstdc++/54376] incorrect complaint about redefinition
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54376 Jason Merrill changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #15 from Jason Merrill 2012-08-27 18:13:46 UTC --- Indeed, the code is in error. You can't have multiple instantiations of a class template that define the same friend signature, as the definition might depend on the class template parameters.
[Bug target/54385] [4.8 regression] ICE in pre_and_rev_post_order_compute, at cfganal.c:873
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54385 --- Comment #2 from Steven Bosscher 2012-08-27 17:54:51 UTC --- Created attachment 28090 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28090 Try to delete unreachable blocks if any edges were removed
[Bug libstdc++/43852] Embedded systems friendly libstdc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43852 --- Comment #19 from Jonathan Wakely 2012-08-27 17:18:34 UTC --- I finally got time to work on this and have posted an updated patch to http://gcc.gnu.org/ml/gcc-patches/2012-08/msg01879.html I went with your original idea of disabling the "verbose" default rather than enabling a "quiet" alternative. On reflection I thought your name was better as it's consistent with the verbose terminate handler. Sorry this took so long to deal with!
[Bug target/54385] [4.8 regression] ICE in pre_and_rev_post_order_compute, at cfganal.c:873
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54385
Steven Bosscher changed:
What|Removed |Added
CC|steven at gcc dot gnu.org |
--- Comment #1 from Steven Bosscher 2012-08-27
17:18:27 UTC ---
Starting program: /home/stevenb/devel/build-debug/gcc/cc1plus -quiet PR54385.cc
-O2 -fnon-call-exceptions
Breakpoint 1, fancy_abort (file=0x1147c0a0 "../../trunk/gcc/cfganal.c",
line=873, function=0x1147c1c0 "pre_and_rev_post_order_compute")
at ../../trunk/gcc/diagnostic.c:1011
1011 internal_error ("in %s, at %s:%d", function, trim_filename (file),
line);
(gdb) up
#1 0x105d7d4c in pre_and_rev_post_order_compute (pre_order=0x0,
rev_post_order=0x116d5580, include_entry_exit=false) at
../../trunk/gcc/cfganal.c:873
873 gcc_assert (pre_order_num == n_basic_blocks - NUM_FIXED_BLOCKS);
(gdb) p brief_dump_cfg(stderr,-1)
;; basic block 2, loop depth 0, count 0, freq 1, maybe hot
;; prev block 0, next block 3, flags: (REACHABLE, RTL, MODIFIED)
;; pred: ENTRY [100.0%] (FALLTHRU)
;; succ: 3 [100.0%] (FALLTHRU)
;; basic block 3, loop depth 0, count 0, freq 1, maybe hot
;; prev block 2, next block 4, flags: (REACHABLE, RTL, MODIFIED)
;; pred: 2 [100.0%] (FALLTHRU)
;; succ: EXIT [100.0%] (ABNORMAL,SIBCALL)
;; basic block 4, loop depth 0, count 0, freq 0
;; prev block 3, next block 1, flags: (REACHABLE, RTL, MODIFIED)
;; pred:
;; succ:
$5 = void
(gdb) p current_pass->name
$6 = 0x114a27d8 "postreload"
So there's an unreachable block and it confuses pre_and_rev_post_order_compute.
Someone has removed a critical edge between the ICE point and the start of
postreload. This is the CFG on entry to rest_of_handle_postreload:
;; basic block 2, loop depth 0, count 0, freq 1, maybe hot
;; prev block 0, next block 3, flags: (REACHABLE, RTL, MODIFIED)
;; pred: ENTRY [100.0%] (FALLTHRU)
;; succ: 4 (ABNORMAL,EH)
;; 3 [100.0%] (FALLTHRU)
;; basic block 3, loop depth 0, count 0, freq 1, maybe hot
;; prev block 2, next block 4, flags: (REACHABLE, RTL, MODIFIED)
;; pred: 2 [100.0%] (FALLTHRU)
;; succ: EXIT [100.0%] (ABNORMAL,SIBCALL)
;; basic block 4, loop depth 0, count 0, freq 0
;; prev block 3, next block 1, flags: (REACHABLE, RTL, MODIFIED)
;; pred: 2 (ABNORMAL,EH)
;; succ:
The edge disappears in reload_cse_regs_1, which is not CFG aware (like most of
postreload, it seems).
This is a pre-existing problem that happens to be exposed by my patch.
[Bug target/54385] [4.8 regression] ICE in pre_and_rev_post_order_compute, at cfganal.c:873
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54385 Steven Bosscher changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-08-27 AssignedTo|unassigned at gcc dot |steven at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1
[Bug target/54385] New: [4.8 regression] ICE in pre_and_rev_post_order_compute, at cfganal.c:873
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54385 Bug #: 54385 Summary: [4.8 regression] ICE in pre_and_rev_post_order_compute, at cfganal.c:873 Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Keywords: build, ice-on-valid-code Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: sch...@linux-m68k.org CC: ste...@gcc.gnu.org Target: m68k-*-* Created attachment 28089 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28089 Reduced from libjava/java/lang/natClassLoader.cc $ gcc/xgcc -B gcc/ -O2 -fnon-call-exceptions natClassLoader.ii -S natClassLoader.ii: In function ‘void _Jv_PushClass(jclass)’: natClassLoader.ii:51:1: internal compiler error: in pre_and_rev_post_order_compute, at cfganal.c:873 Started with r190602.
[Bug preprocessor/53469] #pragma GCC diagnostic works, but using _Pragma doesn't for -Wunused-local-typedefs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53469 Dodji Seketeli changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #3 from Dodji Seketeli 2012-08-27 15:45:33 UTC --- Fixed in trunk (4.8).
[Bug preprocessor/53469] #pragma GCC diagnostic works, but using _Pragma doesn't for -Wunused-local-typedefs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53469
--- Comment #2 from Dodji Seketeli 2012-08-27
15:41:44 UTC ---
Author: dodji
Date: Mon Aug 27 15:41:38 2012
New Revision: 190714
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190714
Log:
PR preprocessor/53469 - argument tokens of _Pragma miss virtual location
Consider this short test snippet:
-8---
#define STRINGIFY(x) #x
#define TEST(x) \
_Pragma(STRINGIFY(GCC diagnostic ignored "-Wunused-local-typedefs")) \
typedef int myint;
void bar ()
{
TEST(myint)
}
-8---
The _Pragma is effectively ignored, and compiling with
-Wunused-local-typedefs warns on the local typedef, even though the
pragma should have prevented the warning to be emitted.
This is because when the preprocessor sees the _Pragma operator and
then goes to handle the first token ('GCC' here) that makes up its
operands, it retains the spelling location of that token, not its
virtual location.
Later when diagnostic_report_diagnostic is called to emit the warning
(or ignore it because of the pragma), it compares the location of the
first operand of the pragma with the location of the unused location,
(by calling linemap_location_before_p) and that comparison fails
because in this case, both locations should be virtual.
This patch fixes the issue by teaching the pragma handling to use
virtual locations.
Bootstrapped and tested on x86_64-unknown-linux-gnu against trunk.
libcpp/
PR preprocessor/53469
* directives.c (do_pragma): Use the virtual location for the
pragma token, instead of its spelling location.
gcc/testsuite/
PR preprocessor/53469
* gcc.dg/cpp/_Pragma7.c: New test case.
Added:
trunk/gcc/testsuite/gcc.dg/cpp/_Pragma7.c
Modified:
trunk/gcc/testsuite/ChangeLog
trunk/libcpp/ChangeLog
trunk/libcpp/directives.c
[Bug fortran/54384] gfortran memory leaks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54384 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #2 from Tobias Burnus 2012-08-27 14:57:21 UTC --- The patch of comment 0 fixed the gfc_trans_assignment->gfc_trans_arrayfunc_assign issue of channel.f90 and rnflow.f90. The other issues remain.
[Bug fortran/54384] gfortran memory leaks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54384 --- Comment #1 from Tobias Burnus 2012-08-27 14:42:54 UTC --- Author: burnus Date: Mon Aug 27 14:42:50 2012 New Revision: 190713 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190713 Log: 2012-08-27 Tobias Burnus PR fortran/54384 * trans-expr.c (gfc_trans_arrayfunc_assign): Free se.ss and loop. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-expr.c
[Bug fortran/41093] memory leaks with gfc_namespace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41093 Tobias Burnus changed: What|Removed |Added Status|NEW |RESOLVED CC||burnus at gcc dot gnu.org Resolution||FIXED --- Comment #4 from Tobias Burnus 2012-08-27 12:19:42 UTC --- (Mostly) FIXED on the GCC 4.8 trunk. See PR 54384 for some remaining issues. Janus: As gfortran.dg/proc_ptr_result_1.f90 (see PR54384) shows, the PROCEDURE statement leaks memory which is allocated in gfc_match_procedure and resolve_procedure_interface. As PROCEDURE expert, can you have a look? All: At least on x86-64, you might need a valgrind which has the patch at https://bugs.kde.org/show_bug.cgi?id=295808 (the current SVN version has, but 3.8.0 is too old).
[Bug fortran/41093] memory leaks with gfc_namespace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41093 --- Comment #3 from Tobias Burnus 2012-08-27 12:07:52 UTC --- Author: burnus Date: Mon Aug 27 12:07:43 2012 New Revision: 190710 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190710 Log: 2012-08-27 Tobias Burnus PR fortran/41093 * gfortran.h (gfc_common_head): Add "int refs". * match.c (gfc_match_common): Increment refs. * resolve.c (resolve_symbol): Only increment formal_ns->refs if formal_ns is not sym->ns. * symbol.c (gfc_free_symbol): Only free formal_ns if if formal_ns is not sym->ns. Free common_block if refs is one. (gfc_release_symbol): Release formal_ns only if the symbol is not ENTRY of a module. * decl.c (get_proc_name): Don't increment gfc_current_ns->refs. * parse.c (parse_interface): Incement proc_unit->refs++ for proc-pointer result variables. * module.c (mio_symbol): Don't increase sym->refs for its use in sym->formal_ns->proc_name. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/match.c trunk/gcc/fortran/module.c trunk/gcc/fortran/parse.c trunk/gcc/fortran/resolve.c trunk/gcc/fortran/symbol.c
[Bug fortran/54370] error: non-trivial conversion in unary operation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54370 --- Comment #3 from Tobias Burnus 2012-08-27 12:03:45 UTC --- Author: burnus Date: Mon Aug 27 12:03:41 2012 New Revision: 190709 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190709 Log: 2012-08-27 Tobias Burnus PR fortran/54370 * trans-stmt.c (gfc_trans_do_while): Don't change the logical kind for negation of the condition. 2012-08-27 Tobias Burnus PR fortran/54370 * gfortran.dg/do_5.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/do_5.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-stmt.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/54384] New: gfortran memory leaks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54384 Bug #: 54384 Summary: gfortran memory leaks Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org Running valgrind on gfortran (or rather f951) -fsyntax-only shows the following leaks. (This PR assumed that my patch http://gcc.gnu.org/ml/fortran/2012-08/msg00180.html has been applied plus a follow up for module.c's mio_symbol which removes the "sym->refs++".) With Polyhedron 2005's channel.f90 (and rnflow.f90): by 0x606B33: gfc_get_array_ss(gfc_ss*, gfc_expr*, int, gfc_ss_type) (trans-array.c:561) by 0x612F00: gfc_walk_expr(gfc_expr*) (trans-array.c:8787) by 0x639F98: gfc_trans_arrayfunc_assign(gfc_expr*, gfc_expr*) (trans-expr.c:6749) by 0x63B911: gfc_trans_assignment(gfc_expr*, gfc_expr*, bool, bool) (trans-expr.c:7438) With Polyhedron 2005's mdbx.f90: by 0x57D7BF: gfc_get_expr() (expr.c:49) by 0x57E123: gfc_copy_expr(gfc_expr*) (expr.c:272) by 0x5C63EA: gfc_match_rvalue(gfc_expr**) (primary.c:2788) by 0x56D3A2: match_data_constant(gfc_expr**) (decl.c:354) With Polyhedron 2005's nf.f90: by 0x57E1807: __gmpz_init (in /usr/lib64/libgmp.so.10.0.5) by 0x57D9EB: gfc_get_constant_expr(bt, int, locus*) (expr.c:161) by 0x57DB17: gfc_get_int_expr(int, locus*, int) (expr.c:217) by 0x5F592C: _ZL24check_section_vs_sectionP13gfc_array_refS0_i.part.4 (dependency.c:1213) by 0x5F6C47: gfc_dep_resolver(gfc_ref*, gfc_ref*, gfc_reverse*) (dependency.c:1155) by 0x60C585: gfc_conv_resolve_dependencies(gfc_loopinfo*, gfc_ss*, gfc_ss*) (trans-array.c:4309) by 0x63A891: gfc_trans_assignment_1(gfc_expr*, gfc_expr*, bool, bool) (trans-expr.c:7238) With Polyhedron 2005's capacita.f90: Several. I think the only new one is: by 0x5EF33E: gfc_get_namespace(gfc_namespace*, int) (symbol.c:2325) by 0x5F0F09: gfc_copy_formal_args_intr(gfc_symbol*, gfc_intrinsic_sym*) (symbol.c:4161) by 0x63C50C: gfc_get_symbol_for_expr(gfc_expr*) (trans-intrinsic.c:2334) by 0x64A0EB: gfc_conv_intrinsic_function(gfc_se*, gfc_expr*) (trans-intrinsic.c:4525) With Polyhedron 2005's capacita.f90 (and some more): by 0x57D9EB: gfc_get_constant_expr(bt, int, locus*) (expr.c:161) by 0x57DB17: gfc_get_int_expr(int, locus*, int) (expr.c:217) by 0x55C016: gfc_simplify_iterator_var(gfc_expr*) (array.c:1445) by 0x5826E4: gfc_simplify_expr(gfc_expr*, int) (expr.c:1894) by 0x56A394: gfc_assign_data_value(gfc_expr*, gfc_expr*, __mpz_struct*, __mpz_struct (*) [1]) (data.c:61) With gfortran.dg/proc_ptr_result_1.f90: by 0x5EF6E7: gfc_new_symbol(char const*, gfc_namespace*) (symbol.c:2569) by 0x5716DA: gfc_match_procedure() (decl.c:4916) and by 0x5EF6E7: gfc_new_symbol(char const*, gfc_namespace*) (symbol.c:2569) by 0x5EFA62: gfc_get_sym_tree(char const*, gfc_namespace*, gfc_symtree**, bool) (symbol.c:2753) by 0x56B76C: find_special(char const*, gfc_symbol**, bool) (decl.c:802) by 0x574F28: attr_decl() (decl.c:6174) and by 0x5EF33E: gfc_get_namespace(gfc_namespace*, int) (symbol.c:2325) by 0x5F0D3C: gfc_copy_formal_args(gfc_symbol*, gfc_symbol*, ifsrc) (symbol.c:4104) by 0x5F0E30: gfc_copy_formal_args(gfc_symbol*, gfc_symbol*, ifsrc) (symbol.c:4117) by 0x5D7A5E: resolve_procedure_interface(gfc_symbol*) (resolve.c:228) by 0x5CC420: resolve_symbol(gfc_symbol*) (resolve.c:12581) and by 0x5EF33E: gfc_get_namespace(gfc_namespace*, int) (symbol.c:2325) by 0x5B4040: load_needed(pointer_info*) (module.c:4375) by 0x5B4DCB: read_module() (module.c:4773) and the gfc_match_rvalue issue of mdbx.f90. Also leaking, but I lost the overview whether those are already covered: doduc.f90. (I also haven't tested all of Polyhedron.)
[Bug libstdc++/54296] using the object in the map to erase element from the map crashes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54296 --- Comment #8 from Paolo Carlini 2012-08-27 09:36:08 UTC --- Ah, very well, thanks Francois.
[Bug tree-optimization/54077] [4.7/4.8 Regression] Bytemark FP EMULATION 44% slower than with clang
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54077 Richard Guenther changed: What|Removed |Added Target Milestone|--- |4.7.2 --- Comment #12 from wbrana 2012-08-27 08:42:38 UTC --- 4.8 has improved 20120813 FP EMULATION: 229.84 : 110.29 : 25.45 20120827 FP EMULATION: 281.4 : 135.03 : 31.16
[Bug c++/54383] New: Internal compiler error for lamba function using this-> with -std=c++0x
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54383
Bug #: 54383
Summary: Internal compiler error for lamba function using
this-> with -std=c++0x
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ger...@pfeifer.com
The following snippet fails with an internal compiler error on
current SVN:
auto foo = [&](int a) { return a > this->b; };
~/gcc-x86_64/bin/g++ -std=c++0x x.cc
x.cc: In lambda function:
x.cc:1:36: internal compiler error: Segmentation fault
auto foo = [&](int a) { return a > this->b; };
^
[Bug bootstrap/54329] gcc/reginfo.o differs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54329 wbrana changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #4 from wbrana 2012-08-27 08:27:45 UTC --- it seems to be fixed
[Bug libstdc++/54296] using the object in the map to erase element from the map crashes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54296 --- Comment #7 from François Dumont 2012-08-27 07:58:49 UTC --- I confirm that it is an old issue, it has surely always be there. I managed to reproduce it from the testsuite. The problem is that the current code works fine when the key instance is taken from the container keys but doesn't work when it is extracted from the container values. The current address check is not reliable because the passed key instance could be anywhere within the mapped value. I am preparing a patch to separate the loop used to find the nodes to erase from the loop used to deallocate them.
[Bug rtl-optimization/54365] ARM optimization bug when pointer arithmetic wraps
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54365 Florian Weimer changed: What|Removed |Added CC||fweimer at redhat dot com --- Comment #4 from Florian Weimer 2012-08-27 07:39:15 UTC --- (In reply to comment #0) > $ gcc -O2 compilerbug.c > $ ./a.out > no wrap > $ # Oh dear! Could you try with "-O2 -fwrapv" for completeness? Thanks.
