[Bug ada/51940] Ada.Finalization of passed function return value skipped if exception raised in routine
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51940 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID --- Comment #3 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-01-23 08:19:35 UTC --- This is GNAT GPL so you need to report this to AdaCore instead.
[Bug middle-end/51893] Wrong subword index computation in store_bit_field_1 on BIG_ENDIAN targets
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51893 --- Comment #8 from Aurelien Buhrig aurelien.buhrig.gcc at gmail dot com 2012-01-23 08:27:22 UTC --- It seems the problem occurs with big endian targets when value is at least 4 times bigger than a word. Example: bitsize=40, value = reg:DI sub words--HI. So wordnum = 3. The for loop should start from LSWord to bitsize MSWord (wordnum). So: subword 3 from value, and calls store_bit_fields_1 with bitsize = BITS_PER_WORD then subword 2, then subword 1 And subword 0 from value should be ignored. Currently, the loop does not begins with subword 3, but with subword wordnum-1 which is 2. It is not the LSword of value, and the value stored in the bitfield is (value BITS_PER_WORD).
[Bug libstdc++/51956] [patch] improve shared_ptr and weak_ptr pretty-printers for gdb
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51956 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-01-23 AssignedTo|unassigned at gcc dot |redi at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 Severity|normal |enhancement --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2012-01-23 09:01:06 UTC --- Thanks, I've been meaning to do that for some time.
[Bug rtl-optimization/51933] [4.7 regression] wrong code due to -free
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51933 --- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org 2012-01-23 09:25:55 UTC --- Author: jakub Date: Mon Jan 23 09:25:52 2012 New Revision: 183416 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=183416 Log: PR rtl-optimization/51933 * ree.c (transform_ifelse): Return true right away if dstreg is already wider or equal to cand-mode. (enum ext_modified_kind, struct ext_modified, ext_state): New types. (make_defs_and_copies_lists): Remove defs_list and copies_list arguments, add state argument, just truncate state-work_list instead of always allocating and freeing the vector. Assert that get_defs succeeds instead of returning 2. Changed return type to bool. (merge_def_and_ext): Add state argument. If SET_DEST doesn't have ext_src_mode, see if it has been modified already with the right kind of extension and has been extended before from the ext_src_mode. If SET_DEST is already wider or equal to cand-mode, just return true. Remember the original mode in state-modified array. (combine_reaching_defs): Add state argument. Don't allocate and free here def_list, copied_list and vec vectors, instead just VEC_truncate the vectors in *state. Don't handle outcome == 2 here. (find_and_remove_re): Set DF_DEFER_INSN_RESCAN df flag. Add state variable, clear vectors in it, initialize state.modified if needed. Free all the vectors at the end and state.modified too. Don't skip a candidate if the extension expression has been modified. * gcc.c-torture/execute/pr51933.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr51933.c Modified: trunk/gcc/ChangeLog trunk/gcc/ree.c trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/51933] [4.7 regression] wrong code due to -free
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51933 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #9 from Jakub Jelinek jakub at gcc dot gnu.org 2012-01-23 09:28:26 UTC --- Fixed.
[Bug fortran/51958] [4.7 Regression] -ffrontend-optimize generates wrong code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51958 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 CC||jakub at gcc dot gnu.org
[Bug middle-end/50325] [4.7 Regression] 76 new fails with rev. 177691
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50325 Alan Modra amodra at gmail dot com changed: What|Removed |Added CC||amodra at gmail dot com --- Comment #39 from Alan Modra amodra at gmail dot com 2012-01-23 09:39:48 UTC --- *** Bug 51926 has been marked as a duplicate of this bug. ***
[Bug middle-end/51926] libstdc++ iterator store bigendian bitfield related
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51926 Alan Modra amodra at gmail dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||DUPLICATE --- Comment #1 from Alan Modra amodra at gmail dot com 2012-01-23 09:39:48 UTC --- Oops, already fixed. *** This bug has been marked as a duplicate of bug 50325 ***
[Bug target/51959] New: [4.7 Regression] ICE in set_mem_alias_set, at emit-rtl.c:1884
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51959 Bug #: 51959 Summary: [4.7 Regression] ICE in set_mem_alias_set, at emit-rtl.c:1884 Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: rgue...@gcc.gnu.org Target: ia64-*-linux Compiling Qt4 results in /usr/lib/gcc/ia64-suse-linux/4.7/cc1plus -fpreprocessed qicon.ii -quiet -dumpbase qicon.cpp -auxbase-strip .obj/release-shared/qicon.o -g -O2 -O2 -Wall -Wextra -version -fmessage-length=0 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -fvisibility=hidden -fvisibility-inlines-hidden -fPIC -o qicon.s In file included from ../../include/QtCore/qlist.h:1:0, from image/qicon.h:47, from image/qicon.cpp:42: ../../include/QtCore/../../src/corelib/tools/qlist.h: In member function 'void QListT::append(const T) [with T = QSize]': ../../include/QtCore/../../src/corelib/tools/qlist.h:373:39: internal compiler error: in set_mem_alias_set, at emit-rtl.c:1884 Please submit a full bug report, with preprocessed source if appropriate. See http://bugs.opensuse.org/ for instructions.
[Bug lto/51916] FAIL: gcc.dg/lto/trans-mem-3 c_lto_trans-mem-3_0.o-c_lto_trans-mem-3_1.o link, -flto (internal compiler error)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51916 --- Comment #10 from Richard Guenther rguenth at gcc dot gnu.org 2012-01-23 10:11:48 UTC --- (In reply to comment #9) (In reply to comment #8) (In reply to comment #7) ... so this is a build/config issue - or, alternatively, the segment name can be specified as above since it is ignored for non-mach-o platforms. note: gcc/lto/lto-object.c hardwires this without any ill effect on other platforms. So, since the test and the section are lto-specific, I'd suspect that this is the right solution rather than some tricky config machinery. Yes. Can you please post it to gcc-patches@ and commit it? It's preapproved as obviously correct. Thx.
[Bug target/51959] [4.7 Regression] ICE in set_mem_alias_set, at emit-rtl.c:1884
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51959 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-01-23 Target Milestone|--- |4.7.0 Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2012-01-23 10:13:34 UTC --- Confirmed on a x86_64 x ia64 cross with -O -fstrict-aliasing. Reducing.
[Bug lto/51916] FAIL: gcc.dg/lto/trans-mem-3 c_lto_trans-mem-3_0.o-c_lto_trans-mem-3_1.o link, -flto (internal compiler error)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51916 --- Comment #11 from Dominique d'Humieres dominiq at lps dot ens.fr 2012-01-23 10:21:38 UTC --- Yes. Can you please post it to gcc-patches@ and commit it? It's preapproved as obviously correct. Thx. A patch has already been submitted by Patrick Marlier at http://gcc.gnu.org/ml/gcc-patches/2012-01/msg01063.html . I have successfully regstrapped with it on x86_64-apple-darwin10 and powerpc-apple-darwin9.
[Bug rtl-optimization/51938] missed optimization: 2 comparisons
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51938 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Keywords||missed-optimization Last reconfirmed||2012-01-23 Component|tree-optimization |rtl-optimization Ever Confirmed|0 |1 Severity|normal |enhancement --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2012-01-23 10:23:31 UTC --- Confirmed. Something for PHI-OPT, recognize bb 2: if (x_2(D) 0.0) goto bb 5; else goto bb 3; bb 3: if (x_2(D) 0.0) goto bb 4; else goto bb 5; bb 4: bb 5: # D.1719_1 = PHI 1(2), -1(4), 0(3) return D.1719_1; I suspect also worthwhile for integral types. Note that for real types you need -ffinite-math-only - I bet the clang result is wrong for NaNs. Btw, what's the optimal assembly you expect? Not sure what's the best way to represent this on the tree level either, so eventually we have to resort to RTL if-conversion (doesn't work there for integral types either).
[Bug tree-optimization/29333] Jump threading getting in the way of PHI-OPT
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29333 --- Comment #7 from Richard Guenther rguenth at gcc dot gnu.org 2012-01-23 10:25:20 UTC --- (In reply to comment #6) (In reply to comment #5) This is the patch which I am testing: I Have a slightly different one since we should do a few more things before the mergephi and also we ccannot remove the first mergephi as that causes vpr to lose some optimizations. I think it makes sense to do mergephi before phiopt. mergephi should not be required for VRP - can you file a bug with a testcase?
[Bug middle-end/51939] [4.7 Regression] ICE: in compute_affine_dependence, at tree-data-ref.c:4103 with -fcheck-data-deps
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51939 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-01-23 CC||rguenth at gcc dot gnu.org, ||spop at gcc dot gnu.org Known to work||4.6.2 Target Milestone|--- |4.7.0 Summary|ICE: in |[4.7 Regression] ICE: in |compute_affine_dependence, |compute_affine_dependence, |at tree-data-ref.c:4103 |at tree-data-ref.c:4103 ||with -fcheck-data-deps Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2012-01-23 10:27:57 UTC --- Confirmed. Might be deliberate changes that were not reflected in the check-data-deps path.
[Bug libstdc++/51960] New: Missing move-assignment operator in raw_storage_iterator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51960
Bug #: 51960
Summary: Missing move-assignment operator in
raw_storage_iterator
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: valy...@gmail.com
It's interesting why raw_storage_iterator (
http://gcc.gnu.org/viewcvs/trunk/libstdc%2B%2B-v3/include/bits/stl_raw_storage_iter.h?revision=169421view=markup
) doesn't provide move-assignment operator? Such an operator would allow moving
items to a raw memory instead of copying them. In this case the
raw_storage_iterator could be properly used with std::move()-like algorithms:
template typename InputIterator, typename T
void move_to_raw_buffer(InputIterator first, InputIterator last, T *raw_buffer)
{
std::move(first, last, std::raw_storage_iteratorT *, T(raw_buffer));
}
Currently this results in items' copying instead of expected items' movement
due to the lack of move-assignment operator in the raw_storage_iterator
implementation.
[Bug middle-end/51949] [4.7 Regression] expand_call: seg fault caused by IPA split
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51949 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2012-01-23 10:35:26 UTC --- Mine.
[Bug middle-end/51949] [4.7 Regression] expand_call: seg fault caused by IPA split
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51949 --- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2012-01-23 10:42:04 UTC --- We do not honor cur_node-local.can_change_signature, and that does not take into account return value removal. I have a smallish workaround.
[Bug debug/51950] [4.6/4.7 Regression] fdebug-types-section regression for member pointers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51950 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Known to work||4.5.3 Target Milestone|--- |4.6.3 Summary|[4.6 Regression]|[4.6/4.7 Regression] |fdebug-types-section|fdebug-types-section |regression for member |regression for member |pointers|pointers
[Bug c++/51910] [4.7 Regression] -frepo linking failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51910 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.7.0
[Bug target/51957] [4.7 Regression] ppc64 .debug_loc toc reference
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51957
--- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2012-01-23
10:48:05 UTC ---
The problem is that during var-tracking adjust_insn doesn't
avoid_constant_pool_reference because we have:
(debug_insn 116 33 34 5 (var_location:DI D#3 (reg:DI 2 2)) -1
(nil))
...
(debug_insn 114 37 113 5 (var_location:DI D#2 (mem/u/c:DI (plus:DI
(debug_expr:DI D#3)
(const:DI (unspec:DI [
(symbol_ref/u:DI (*.LC0) [flags 0x2])
] UNSPEC_TOCREL))) [8 S8 A8])) -1
(nil))
and thus rs6000_delegitimize_address doesn't do anything (as there is
DEBUG_EXPR not REG 2 directly). This means the UNSPEC_TOCREL stuff gets down
into mem_loc_descriptor (with (reg:DI 2) in it). There it is successfully
delegitimized and we do:
case MEM:
{
rtx new_rtl = avoid_constant_pool_reference (rtl);
if (new_rtl != rtl)
{
mem_loc_result = mem_loc_descriptor (new_rtl, mode, mem_mode,
initialized);
if (mem_loc_result != NULL)
return mem_loc_result;
}
}
mem_loc_result = mem_loc_descriptor (XEXP (rtl, 0),
get_address_mode (rtl), mode,
VAR_INIT_STATUS_INITIALIZED);
While mem_loc_descriptor here (unlike loc_descriptor or some other places)
tries
avoid_constant_pool_reference first, mem_loc_descriptor for that fails (because
(symbol_ref w) is external and so it falls back to DW_OP_deref on the .LC0
symbol (but that is apparently what ppc64 ld doesn't like). On other targets,
trying to fallback to the original mem can be a win, if say we end up
dereferencing some word in .got and the linker is fine with it, we can provide
the value to the debugger.
So I'd say that ppc64 should have some target hook that would say that (at
least certain kind of) mem/u/c (on ppc64 if we can limit them to .toc section
references if possible) should never be referenced in the
.debug_info/.debug_loc (or could it be on the symbol_ref's only, can we from
the symbol_ref find out that it is a symbol from .toc section?).
Alan, what do you think about this?
[Bug target/51955] _mm_setzero_si128 intrinsic causes segfault without -O
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51955
--- Comment #5 from Richard Guenther rguenth at gcc dot gnu.org 2012-01-23
10:50:52 UTC ---
void _start() {
main();
}
isn't properly aligning the stack for the ABI GCC assumes. Simply drop it.
[Bug target/51957] [4.7 Regression] ppc64 .debug_loc toc reference
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51957 --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2012-01-23 10:51:39 UTC --- To reject just .toc related SYMBOL_REFs, guess we'd need to set #define SYMBOL_FLAG_TOC_SECTION (1 SYMBOL_FLAG_MACH_DEP_SHIFT) or so flag on the symbol refs when creating them and test it in the target hook.
[Bug middle-end/51949] [4.7 Regression] expand_call: seg fault caused by IPA split
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51949 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #6 from Richard Guenther rguenth at gcc dot gnu.org 2012-01-23 10:53:13 UTC --- Fixed.
[Bug fortran/51961] New: [OOP] ALLOCATE with MOLD= rejects if source-expr has a different rank
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51961 Bug #: 51961 Summary: [OOP] ALLOCATE with MOLD= rejects if source-expr has a different rank Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Keywords: rejects-valid Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org Fortran 2008 has: C638 (R626) Each allocate-object shall be type compatible (4.3.1.3) with source-expr. If SOURCE= appears, source-expr shall be a scalar or have the same rank as each allocate-object. gfortran properly diagnoses this for SOURCE, but it also diagnoses it for MOLD= which is valid: allocate (a(2), mold=b) ! Valid 2 1 Error: Source-expr at (1) must be scalar or have the same rank as the allocate-object at (2) type t end type t class(T), allocatable :: a(:), b(:,:) allocate(b(2,2)) allocate (a(2), source=b) ! Invalid - and correctly rejected allocate (a(2), mold=b) ! Valid - but not accepted end
[Bug middle-end/51949] [4.7 Regression] expand_call: seg fault caused by IPA split
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51949 --- Comment #5 from Richard Guenther rguenth at gcc dot gnu.org 2012-01-23 10:53:01 UTC --- Author: rguenth Date: Mon Jan 23 10:52:57 2012 New Revision: 183424 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=183424 Log: 2012-01-23 Richard Guenther rguent...@suse.de PR tree-optimization/51949 * ipa-split.c (execute_split_functions): Do not split malloc functions. * gcc.dg/torture/pr51949.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr51949.c Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-split.c trunk/gcc/testsuite/ChangeLog
[Bug c++/51962] New: Compiling with -O3 and using the same input produces a different result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51962
Bug #: 51962
Summary: Compiling with -O3 and using the same input produces a
different result
Classification: Unclassified
Product: gcc
Version: 4.6.2
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mario.ach...@gmail.com
Created attachment 26423
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26423
The simple C++ code that causes the bug.
Compile the following simple code without -O3, and run.
Now compile it with -O3 option (for optimization), run again.
Surprisingly 2 different outputs appear.
I have made the program as minimal as possible and traced back the error to the
following line:
if (((k-x[j])*(k-x[j])+(y[j]-ya)*(y[j]-ya))=r[j]*r[j]) { found1 = true; }
(line 17 in the code)
Comment this and the problem is solved.
This caused a huge problem that took me around an hour to figure out that it
was related to compiler optimization. I have provided the simplest case I could
find causing the error.
Thank you for your time and hope you fix it soon.
Please keep me updated.
[Bug testsuite/51941] FAIL: g++.dg/debug/dwarf2/nested-3.C scan-assembler
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51941 Dodji Seketeli dodji at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |dodji at gcc dot gnu.org |gnu.org |
[Bug c++/51962] Compiling with -O3 and using the same input produces a different result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51962 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Severity|critical|normal --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2012-01-23 11:19:39 UTC --- You do not initialise found1. Set that to false and your problem probably goes away.
[Bug testsuite/51941] FAIL: g++.dg/debug/dwarf2/nested-3.C scan-assembler
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51941 --- Comment #2 from Dodji Seketeli dodji at gcc dot gnu.org 2012-01-23 11:22:46 UTC --- Created attachment 26424 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26424 Candidate fix for the bug This candidate fix works for me on both x86_64-unknown-linux-gnu and x86_64-apple-darwin10 built as a cross compiler. The problem was that on darwin, we get an extra line .set L$set$31,LASF0-Lsection__debug_str and I am not sure why. I don't think we need to prevent the test from running on Darwin (because of it generating dwarf4) as, IIUC, we don't rely on anything released by Apple for this. We just scan the assembly output from cc1plus. Could some Darwin savvy people confirm that the fix works for them? Thanks.
[Bug debug/51950] [4.6/4.7 Regression] fdebug-types-section regression for member pointers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51950 --- Comment #1 from Jan Kratochvil jan.kratochvil at redhat dot com 2012-01-23 11:22:36 UTC --- GDB command for the PASS/FAIL output: gdb -nx a.out -ex 'b 6' -ex r -ex 'ptype F'
[Bug c++/51962] Compiling with -O3 and using the same input produces a different result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51962 Mario Achkar mario.achkar at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #2 from Mario Achkar mario.achkar at gmail dot com 2012-01-23 11:24:54 UTC --- yes you are right. That was hard to find. It's weird though how both work differently when it comes to this.
[Bug c++/51962] Compiling with -O3 and using the same input produces a different result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51962 --- Comment #3 from Mario Achkar mario.achkar at gmail dot com 2012-01-23 11:27:48 UTC --- (In reply to comment #1) You do not initialise found1. Set that to false and your problem probably goes away. Thanks for the fast reply.
[Bug libstdc++/51960] Missing move-assignment operator in raw_storage_iterator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51960 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-01-23 Ever Confirmed|0 |1 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2012-01-23 11:29:36 UTC --- I'll check if this has been suggested before and if not will raise it with the committee.
[Bug c++/51962] Compiling with -O3 and using the same input produces a different result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51962 --- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org 2012-01-23 11:33:39 UTC --- It was very easy to find using valgrind, or a static analysis tool.
[Bug fortran/51948] [4.6/4.7 Regression][OOP] Rejects valid: Function result value in MOVE_ALLOC, nested in SELECT TYPE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51948 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.6.3 Summary|[OOP] Rejects valid:|[4.6/4.7 Regression][OOP] |Polymorphic arguments in|Rejects valid: Function |MOVE_ALLOC |result value in MOVE_ALLOC, ||nested in SELECT TYPE --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2012-01-23 11:43:18 UTC --- The second example is wrong - and it works after fixing it: s/func/func2/. This program compiles with GCC 4.5 (and fails with 4.6/4.7) - thus, I marked the PR as regression. Better example (still based on periodic_6th_order.F90). The SELECT TYPE is crucial, a simple ASSOCIATE or BLOCK won't do: call move_alloc (x, func) 1 Error: 'to' argument of 'move_alloc' intrinsic at (1) must be a variable The program type :: t end type t contains function func(x, y) class(t) :: y ! Dummy variable type(t), allocatable :: func ! Can also be CLASS type(t), allocatable :: x ! Can also be CLASS ! call move_alloc (x, func) ! Works select type (y) type is(t) call move_alloc (x, func) ! Error (but no select variable involved) end select end function end
[Bug testsuite/51941] FAIL: g++.dg/debug/dwarf2/nested-3.C scan-assembler
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51941 --- Comment #3 from Iain Sandoe iains at gcc dot gnu.org 2012-01-23 11:46:19 UTC --- (In reply to comment #2) Created attachment 26424 [details] Candidate fix for the bug This candidate fix works for me on both x86_64-unknown-linux-gnu and x86_64-apple-darwin10 built as a cross compiler. The problem was that on darwin, we get an extra line .set L$set$31,LASF0-Lsection__debug_str and I am not sure why. The reason for making the offsets absolute is limitations on what the native tool-chain can handle in terms of generating/using relocs (although there might well be other latent issues since there is no testing of dwarf 2 on darwin so far). I don't think we need to prevent the test from running on Darwin (because of it generating dwarf4) as, IIUC, we don't rely on anything released by Apple for this. We just scan the assembly output from cc1plus. Could some Darwin savvy people confirm that the fix works for them? As a fix for the test-case this works for me (and, logically, there is no reason to exclude darwin if the test works there). We will have to deal with the other issues as and when we have dwarf 2 on Darwin. (obviously the test-case is emitting incorrect assembler for darwin, since it assumes that the target can assemble ELF-style named sections).
[Bug lto/51642] Weak variable reference triggers ICE with -flto option
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51642 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added CC||ramana at gcc dot gnu.org --- Comment #3 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2012-01-23 11:46:42 UTC --- Richi : Is this a case of WONTFIX for 4.6 or is there a feasible backport ? Ramana
[Bug middle-end/51895] [4.7 Regression] ICE in simplify_subreg
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51895 --- Comment #17 from Richard Guenther rguenth at gcc dot gnu.org 2012-01-23 11:59:57 UTC --- Author: rguenth Date: Mon Jan 23 11:59:53 2012 New Revision: 183429 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=183429 Log: 2012-01-23 Richard Guenther rguent...@suse.de PR tree-optimization/51895 * tree-sra.c (decide_one_param_reduction): Avoid sub-optimal parameter decomposition into BLKmode components. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-sra.c
[Bug target/51959] [4.7 Regression] ICE in set_mem_alias_set, at emit-rtl.c:1884
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51959 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2012-01-23 12:26:05 UTC --- Created attachment 26425 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26425 autoreduced testcase
[Bug regression/51963] New: FAIL: g++.dg/torture/pr51344.C
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51963 Bug #: 51963 Summary: FAIL: g++.dg/torture/pr51344.C Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: regression AssignedTo: unassig...@gcc.gnu.org ReportedBy: greta.yo...@arm.com CC: cestra...@gmail.com, ja...@gcc.gnu.org, kti...@gcc.gnu.org, ram...@gcc.gnu.org Target: arm-none-eabi This test fails on arm-none-eabi: arm-none-eabi-g++ -S source/gcc-fsf/gcc/testsuite/g++.dg/torture/pr51344.C -o pr51344.s source/gcc-fsf/gcc/testsuite/g++.dg/torture/pr51344.C:7:58: warning: 'cdecl' attribute directive ignored [-Wattributes] source/gcc-fsf/gcc/testsuite/g++.dg/torture/pr51344.C:7:58: warning: 'cdecl' attribute directive ignored [-Wattributes] Fails on trunk/4.6/4.5.
[Bug regression/51963] FAIL: g++.dg/torture/pr51344.C
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51963 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr 2012-01-23 12:36:59 UTC --- Duplicate of pr 51934. *** This bug has been marked as a duplicate of bug 51934 ***
[Bug target/51934] FAIL: g++.dg/torture/pr51344.C -O0 (test for excess errors) on powerpc*-*-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51934 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added CC||Greta.Yorsh at arm dot com --- Comment #9 from Dominique d'Humieres dominiq at lps dot ens.fr 2012-01-23 12:36:59 UTC --- *** Bug 51963 has been marked as a duplicate of this bug. ***
[Bug target/51934] FAIL: g++.dg/torture/pr51344.C -O0 (test for excess errors) due to cdecl attribute ignored warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51934 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Target|powerpc*-*-*|powerpc*-*-* arm-none-eabi Summary|FAIL: |FAIL: |g++.dg/torture/pr51344.C|g++.dg/torture/pr51344.C |-O0 (test for excess |-O0 (test for excess |errors) on powerpc*-*-* |errors) due to cdecl ||attribute ignored warning --- Comment #10 from Dominique d'Humieres dominiq at lps dot ens.fr 2012-01-23 12:40:36 UTC --- Changed the summary.
[Bug testsuite/51941] FAIL: g++.dg/debug/dwarf2/nested-3.C scan-assembler
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51941 --- Comment #4 from Dominique d'Humieres dominiq at lps dot ens.fr 2012-01-23 12:51:06 UTC --- Could some Darwin savvy people confirm that the fix works for them? As a fix for the test-case this works for me (and, logically, there is no reason to exclude darwin if the test works there). The fix works for me too. Thanks.
[Bug rtl-optimization/51938] missed optimization: 2 comparisons
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51938 --- Comment #2 from Marc Glisse marc.glisse at normalesup dot org 2012-01-23 12:51:42 UTC --- (In reply to comment #1) I suspect also worthwhile for integral types. Note that for real types you need -ffinite-math-only - I bet the clang result is wrong for NaNs. I hadn't thought about it (this code could indeed use -ffinite-math-only), but it appears I am lucky, the code really is equivalent to if(x0) f(); as claimed. Indeed, for a NaN, x0 and x0 are false, so sign returns ZERO which is not NEG. Comparing sign(x) to ZERO would indeed be different than x==0. On the other hand, ucomisd sets ZF to 1 for QNaN. clang's code appears to be right on all variations I tried. Btw, what's the optimal assembly you expect? clang generates: pxor%xmm1, %xmm1 ucomisd%xmm0, %xmm1 ja.LBB1_2 ret .LBB1_2: xorb%al, %al jmpf # TAILCALL No idea if that's optimal (it also depends on which branch is most likely), but one pair of ucomisd+ja is certainly better than 2.
[Bug other/51011] FAIL: gcc.dg/atomic-generic.c (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51011 John David Anglin danglin at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #13 from John David Anglin danglin at gcc dot gnu.org 2012-01-23 12:54:55 UTC --- Fixed.
[Bug rtl-optimization/49847] [4.6/4.7 Regression] m68k gcj-4.6 NULL deref in fold_rtx (prev_insn_cc0 == NULL)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49847 --- Comment #11 from Andreas Schwab sch...@linux-m68k.org 2012-01-23 13:05:35 UTC --- After r183426 this is now dormant on the 4.6 branch again.
[Bug lto/51642] Weak variable reference triggers ICE with -flto option
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51642 --- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2012-01-23 13:07:17 UTC --- No idea what fixed it, so I don't know - I don't even know where it segfaults. I suspect the change to make -fuse-linker-plugin the default maybe had an effect?
[Bug tree-optimization/51964] New: Missed tail merging opportunity
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51964
Bug #: 51964
Summary: Missed tail merging opportunity
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: vr...@gcc.gnu.org
pr51879-5.c:
...
int bar (int);
void baz (int);
void foo2 (void);
void
foo (int y, int z)
{
int a;
if (y == 6)
{
if (z)
foo2 ();
a = bar (7);
}
else
a = bar (7);
baz (a);
}
...
compile:
...
gcc -O2 pr51879-5.c -S -fdump-tree-all-all
...
pr51879-5.c.094t.pre:
...
# BLOCK 5 freq:4877
# PRED: 8 [100.0%] (fallthru) 4 [100.0%] (fallthru,exec)
# .MEMD.1719_6 = PHI .MEMD.1719_8(D)(8), .MEMD.1719_9(4)
# .MEMD.1719_10 = VDEF .MEMD.1719_6
# USE = nonlocal
# CLB = nonlocal
aD.1712_4 = barD.1703 (7);
goto bb 7;
# SUCC: 7 [100.0%] (fallthru,exec)
# BLOCK 6 freq:5123
# PRED: 2 [51.2%] (false,exec)
# .MEMD.1719_11 = VDEF .MEMD.1719_8(D)
# USE = nonlocal
# CLB = nonlocal
aD.1712_5 = barD.1703 (7);
# SUCC: 7 [100.0%] (fallthru,exec)
# BLOCK 7 freq:1
# PRED: 5 [100.0%] (fallthru,exec) 6 [100.0%] (fallthru,exec)
# aD.1712_1 = PHI aD.1712_4(5), aD.1712_5(6)
# .MEMD.1719_7 = PHI .MEMD.1719_10(5), .MEMD.1719_11(6)
# .MEMD.1719_12 = VDEF .MEMD.1719_7
# USE = nonlocal
# CLB = nonlocal
bazD.1705 (aD.1712_1);
# VUSE .MEMD.1719_12
return;
# SUCC: EXIT [100.0%]
...
Blocks 5 and 6 are not merged by tail_merge_optimize (they are merged by rtl
cross-jumping though).
The reason the blocks are not merged by tail_merge_optimize is that
tail_merge_optimize uses value numbering to determine equivalence of blocks.
And since the calls have a different vuse (.MEMD.1719_6 and .MEMD.1719_8(D))
the results of the calls won't have the same value number (even after fixing
PR51879).
However, the reason we can merge the calls is not because the calls have the
same result. It's because the results are used in the same way. To detect this
we should use a different comparison mechanism than the current.
[Bug c++/17729] [4.4/4.5/4.6/4.7 Regression] Duplicate __attribute__((deprecated)) warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17729 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC|gcc-bugs at gcc dot gnu.org | --- Comment #19 from Paolo Carlini paolo.carlini at oracle dot com 2012-01-23 13:40:31 UTC --- Hi Iain, I'm not 100% sure to understand: did your patch in Comment #16 pass the testsuite? Did you get around to submit it?
[Bug tree-optimization/51964] Missed tail merging opportunity
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51964 --- Comment #1 from vries at gcc dot gnu.org 2012-01-23 13:43:33 UTC --- I have a still rather vague idea that we might value number the uses rather than the defs: assign the same number to uses which use a value in the same way. I don't know how that would work exactly, but the idea is something like this: ... syntax: a - b : a is used to copy to b a - b,c,d: a is used as b to define c and d. # .MEMD.1719_7 = PHI .MEMD.1719_10(5), .MEMD.1719_11(6) .MEMD.1719_10(5) - .MEMD.1719_7 .MEMD.1719_11(6) - .MEMD.1719_7 # aD.1712_1 = PHI aD.1712_4(5), aD.1712_5(6) aD.1712_4(5) - aD.1712_1 aD.1712_5(6) - aD.1712_1 # .MEMD.1719_10 = VDEF .MEMD.1719_6 # USE = nonlocal # CLB = nonlocal aD.1712_4 = barD.1703 (7); bar - call, .MEMD.1719_7, aD.1712_1 .MEMD.1719_6 - vuse, .MEMD.1719_7, aD.1712_1 7- callarg0, .MEMD.1719_7, aD.1712_1 # .MEMD.1719_11 = VDEF .MEMD.1719_8(D) # USE = nonlocal # CLB = nonlocal aD.1712_5 = barD.1703 (7); bar - call, .MEMD.1719_7, aD.1712_1 .MEMD.1719_8(D) - vuse, .MEMD.1719_7, aD.1712_1 7 - callarg0, .MEMD.1719_7, aD.1712_1 ... By comparing the value numbers of the uses of the 2 calls, we can conclude that the calls use values in the same way, which means we can merge them. And in order to merge them we need to insert phis to merge the actual values that are used. In the example above, we would only need a phi for .MEMD.1719_6 and .MEMD.1719_8(D). And if we had f.i. 'bar (7)' and 'bar (8)' in the example, this still would compare equal, and we would have to insert a phi (7,8) and use that as argument of the tail-merged call to bar.
[Bug c++/25973] [4.4/4.5/4.6/4.7 Regression] Wrong warning: control reaches end of non-void function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25973 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |ASSIGNED CC|paolo.carlini at oracle dot | |com, vries at gcc dot | |gnu.org | AssignedTo|unassigned at gcc dot |vries at gcc dot gnu.org |gnu.org | --- Comment #16 from Paolo Carlini paolo.carlini at oracle dot com 2012-01-23 13:42:44 UTC --- Assigning then.
[Bug libstdc++/51965] New: Redundant move constructions in heap algorithms
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51965 Bug #: 51965 Summary: Redundant move constructions in heap algorithms Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: libstdc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: valy...@gmail.com Created attachment 26426 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26426 Eliminate unnecessary move constructions in stl_heap.h Currently Heap implementation ( http://gcc.gnu.org/viewcvs/trunk/libstdc%2B%2B-v3/include/bits/stl_heap.h?revision=181987view=markup ) contains redundant move constructions. These constructors are invoked when passing rvalue __value to std::__push_heap() and std::__adjust_heap(). It would be better passing the __value into these functions by reference instead. This eliminates redundant move constructions and results in 3x reduction of the number of move constructor calls inside heap functions such as make_heap() and sort_heap(). See the attached patch for details.
[Bug libstdc++/51965] Redundant move constructions in heap algorithms
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51965 --- Comment #1 from Aliaksandr Valialkin valyala at gmail dot com 2012-01-23 13:51:16 UTC --- Created attachment 26427 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26427 Testcase for determining redundant move constructions in stl_heap
[Bug target/51957] [4.7 Regression] ppc64 .debug_loc toc reference
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51957 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-01-23 AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2012-01-23 13:51:44 UTC --- Created attachment 26428 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26428 gcc47-pr51957.patch Untested fix.
[Bug fortran/51966] New: internal compiler error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51966 Bug #: 51966 Summary: internal compiler error Classification: Unclassified Product: gcc Version: 4.6.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: peter.tro...@gmail.com Created attachment 26429 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26429 fortran module part of a larger code Error message (see complete below): Compiler_error_example.f90:99:0: internal compiler error: in gfc_conv_array_constructor_expr, at fortran/trans-expr.c:4126 Small example code which triggers the error is attached.(It is extracted from a much larger code). Output from compiler: $ gfortran -v -save-temps -fdefault-real-8 -ffree-line-length-0 -O2 -c Compiler_error_example.f90 Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/global/home/install/gcc/4.6.2/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.6.2/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc-4.6.2/configure --prefix=/global/apps/gcc/4.6.2 Thread model: posix gcc version 4.6.2 (GCC) COLLECT_GCC_OPTIONS='-v' '-save-temps' '-fdefault-real-8' '-ffree-line-length-0' '-O2' '-c' '-mtune=generic' '-march=x86-64' /global/home/install/gcc/4.6.2/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.6.2/f951 Compiler_error_example.f90 -quiet -dumpbase Compiler_error_example.f90 -mtune=generic -march=x86-64 -auxbase Compiler_error_example -O2 -version -fdefault-real-8 -ffree-line-length-0 -fintrinsic-modules-path /global/home/install/gcc/4.6.2/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.6.2/finclude -o Compiler_error_example.s GNU Fortran (GCC) version 4.6.2 (x86_64-unknown-linux-gnu) compiled by GNU C version 4.6.2, GMP version 4.3.2, MPFR version 2.4.2, MPC version 0.8.1 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU Fortran (GCC) version 4.6.2 (x86_64-unknown-linux-gnu) compiled by GNU C version 4.6.2, GMP version 4.3.2, MPFR version 2.4.2, MPC version 0.8.1 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler_error_example.f90: In function 'init_ecosystems': Compiler_error_example.f90:99:0: internal compiler error: in gfc_conv_array_constructor_expr, at fortran/trans-expr.c:4126 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions.
[Bug c++/25973] [4.4/4.5/4.6/4.7 Regression] Wrong warning: control reaches end of non-void function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25973 --- Comment #17 from vries at gcc dot gnu.org 2012-01-23 14:04:07 UTC --- I tested an earlier version of this patch without any problems, I just need to retest and submit. Submitted patch: http://gcc.gnu.org/ml/gcc-patches/2012-01/msg01071.html
[Bug libstdc++/51965] Redundant move constructions in heap algorithms
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51965 Chris Jefferson chris at bubblescope dot net changed: What|Removed |Added CC||chris at bubblescope dot ||net --- Comment #2 from Chris Jefferson chris at bubblescope dot net 2012-01-23 14:04:43 UTC --- From my memory of originally writing this, from the old non-moving version, these moves were originally copies. The reason I believe those moves are there is because in some cases the original location is written over. For example trace the behaviour of push_heap / __push_heap. I'm not saying your patch is wrong, and I can't currently compile a g++ svn head to check, but have you run the tester with your patch, and have you checked the logic carefully to make sure you can't scribble over the value in the algorithm? There may will still be a way of reducing the work to just one move of course, at the start of the algorithm. Sorry if you have already considered this, but I remember bits of this being subtle.
[Bug c++/17729] [4.4/4.5/4.6/4.7 Regression] Duplicate __attribute__((deprecated)) warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17729 --- Comment #20 from Iain Sandoe iains at gcc dot gnu.org 2012-01-23 14:08:21 UTC --- (In reply to comment #19) Hi Iain, I'm not 100% sure to understand: did your patch in Comment #16 pass the testsuite? Did you get around to submit it? The problem I was referring to is in making the test-suite harness detect the presence of duplicate messages - and thus to making a test-case to prove that the fix works. == I posted the patch http://gcc.gnu.org/ml/gcc-patches/2010-04/msg01092.html it was reviewed with the conclusion that the patch would not work in all cases, there was some follow-up discussion and a follow-up patch (which is probably mostly OK) in: http://gcc.gnu.org/ml/gcc-patches/2010-07/msg01516.html ... at that point I ran out of time for this particular issue - Jason made a suggestion as to a new implementation but I've not had a chance to look at it. It's quite hard to address because the check is called from different places.
[Bug lto/51916] FAIL: gcc.dg/lto/trans-mem-3 c_lto_trans-mem-3_0.o-c_lto_trans-mem-3_1.o link, -flto (internal compiler error)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51916 --- Comment #12 from Aldy Hernandez aldyh at gcc dot gnu.org 2012-01-23 14:07:49 UTC --- Author: aldyh Date: Mon Jan 23 14:07:41 2012 New Revision: 183433 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=183433 Log: PR lto/51916 * lto-wrapper.c (run_gcc): Pass the LTO section name to simple_object_start_read. Modified: trunk/gcc/ChangeLog trunk/gcc/lto-wrapper.c
[Bug lto/51916] FAIL: gcc.dg/lto/trans-mem-3 c_lto_trans-mem-3_0.o-c_lto_trans-mem-3_1.o link, -flto (internal compiler error)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51916 Aldy Hernandez aldyh at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #13 from Aldy Hernandez aldyh at gcc dot gnu.org 2012-01-23 14:08:42 UTC --- fixed on trunk
[Bug tree-optimization/51879] Missed tail merging with non-const/pure calls
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51879 --- Comment #5 from vries at gcc dot gnu.org 2012-01-23 14:10:38 UTC --- Created attachment 26430 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26430 Tentative patch 2012-01-23 Tom de Vries t...@codesourcery.com PR tree-optimization/51879 tree-ssa-sccvn.c (visit_reference_op_call): Handle gimple_vdef. (visit_use): Handle non-pure/const calls using visit_reference_op_call. gcc.dg/pr51879.c: New test. gcc.dg/pr51879-2.c: Same. gcc.dg/pr51879-3.c: Same. gcc.dg/pr51879-4.c: Same.
[Bug libstdc++/51965] Redundant move constructions in heap algorithms
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51965 --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org 2012-01-23 14:11:08 UTC --- Thanks, Chris. I haven't looked at the patch or test yet, but I'm a little surprised the compiler can't elide the move constructors.
[Bug target/51934] FAIL: g++.dg/torture/pr51344.C -O0 (test for excess errors) due to cdecl attribute ignored warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51934 --- Comment #11 from Jason Merrill jason at gcc dot gnu.org 2012-01-23 14:43:30 UTC --- Author: jason Date: Mon Jan 23 14:43:25 2012 New Revision: 183434 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=183434 Log: PR target/51934 * g++.dg/torture/pr51344.C: Use noreturn instead of cdecl. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/torture/pr51344.C
[Bug target/51934] FAIL: g++.dg/torture/pr51344.C -O0 (test for excess errors) due to cdecl attribute ignored warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51934 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||jason at gcc dot gnu.org Resolution||FIXED --- Comment #12 from Jason Merrill jason at gcc dot gnu.org 2012-01-23 14:50:00 UTC --- Should be fixed now.
[Bug fortran/51966] internal compiler error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51966 --- Comment #1 from Peter Wind peter.tromso at gmail dot com 2012-01-23 14:51:46 UTC --- Created attachment 26431 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26431 compile with gfortran fails small code that exposes the same problem (internal compiler error)
[Bug target/51934] FAIL: g++.dg/torture/pr51344.C -O0 (test for excess errors) due to cdecl attribute ignored warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51934 --- Comment #13 from Dominique d'Humieres dominiq at lps dot ens.fr 2012-01-23 14:55:08 UTC --- Log: PR target/51934 * g++.dg/torture/pr51344.C: Use noreturn instead of cdecl. Should be fixed now. The use of 'noreturn' yields a warning with g++ 4.6.2 and not an infinite loop: [macbook] f90/bug% time g++-fsf-4.6 -c pr51344_db.C pr51344_db.C: In function 'A operator(A, BT)': pr51344_db.C:9:12: warning: function declared 'noreturn' has a 'return' statement [enabled by default] 0.012u 0.024s 0:00.93 3.2%0+0k 3+13io 0pf+0w so IMO the test is no longer testing what has been fixed (see comment #8 for a list of what I have tried).
[Bug libitm/51830] FAIL: libitm.c/mem(cpy|set)-1.c execution test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51830 --- Comment #4 from uros at gcc dot gnu.org 2012-01-23 14:57:50 UTC --- Author: uros Date: Mon Jan 23 14:57:44 2012 New Revision: 183435 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=183435 Log: PR libitm/51830 * builtin-types.def (BT_FN_UINT_UINT_VAR): New. * gtm-builtins.def (BUILT_IN_TM_START): Declare as BT_FN_UINT_UINT_VAR. libitm/ChangeLog: PR libitm/51830 * config/x86/sjlj.S (_ITM_beginTransaction) [!__x86_64__]: Load the first function argument to %eax. Modified: trunk/gcc/ChangeLog trunk/gcc/builtin-types.def trunk/gcc/gtm-builtins.def trunk/libitm/ChangeLog trunk/libitm/config/x86/sjlj.S
[Bug libitm/51830] FAIL: libitm.c/mem(cpy|set)-1.c execution test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51830 Uros Bizjak ubizjak at gmail dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #5 from Uros Bizjak ubizjak at gmail dot com 2012-01-23 15:01:58 UTC --- Fixed.
[Bug fortran/51966] [4.6/4.7 Regression] ICE in gfc_conv_array_constructor_expr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51966 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-valid-code CC||burnus at gcc dot gnu.org Known to work||4.1.2, 4.3.4, 4.4.0, 4.5.3 Target Milestone|--- |4.6.3 Summary|internal compiler error |[4.6/4.7 Regression] ICE in ||gfc_conv_array_constructor_ ||expr Known to fail||4.6.2, 4.7.0 --- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org 2012-01-23 15:06:13 UTC --- Fails at the assert of gfc_conv_array_constructor_expr at fortran/trans-expr.c:4753: 4753 gcc_assert (ss != NULL ss != gfc_ss_terminator); as ss == NULL. Backtrace: #1 gfc_conv_expr (se=0x7fffd260, expr=0x16bf0b0) at trans-expr.c:5421 #2 0x005d0dfe in gfc_trans_subcomponent_assign (expr=0x16bf0b0, cm=0x16bf270, dest=0x2cf250a8) at fortran/trans-expr.c:5179 #3 gfc_trans_structure_assign (dest=0x2ce26280, expr=Unhandled dwarf expression opcode 0xfa ) at fortran/trans-expr.c:5230 #4 0x005d1cb4 in gfc_conv_structure (se=0x7fffd740, expr=0x16c0810, init=0) at fortran/trans-expr.c:5257 #5 0x005d241c in gfc_trans_assignment_1 (expr1=0x16c0090, expr2=0x16c0810, init_flag=false, dealloc=true)
[Bug target/51934] FAIL: g++.dg/torture/pr51344.C -O0 (test for excess errors) due to cdecl attribute ignored warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51934 --- Comment #14 from Jakub Jelinek jakub at gcc dot gnu.org 2012-01-23 15:10:42 UTC --- Well, if it hangs before the fix with the noreturn attribute, then it is trivial to replace the return a; with for (;;);
[Bug fortran/51966] [4.6/4.7 Regression] ICE in gfc_conv_array_constructor_expr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51966 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-01-23 Ever Confirmed|0 |1 --- Comment #3 from Dominique d'Humieres dominiq at lps dot ens.fr 2012-01-23 15:13:18 UTC --- Confirmed on trunk and 4.6.2. The failure is the same as in pr51864. Revision 162456 is OK, revision 164728 gives the ICE.
[Bug libstdc++/51967] New: FAIL: libstdc++-prettyprinters/48362.cc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51967
Bug #: 51967
Summary: FAIL: libstdc++-prettyprinters/48362.cc
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: dang...@gcc.gnu.org
Host: hppa2.0w-hp-hpux11.11
Target: hppa2.0w-hp-hpux11.11
Build: hppa2.0w-hp-hpux11.11
Executing on host: /test/gnu/gcc/objdir/./gcc/g++ -shared-libgcc
-B/test/gnu/gcc
/objdir/./gcc -nostdinc++
-L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++
-v3/src -L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/src/.libs
-B/o
pt/gnu/gcc/gcc-4.7/hppa2.0w-hp-hpux11.11/bin/
-B/opt/gnu/gcc/gcc-4.7/hppa2.0w-hp
-hpux11.11/lib/ -isystem /opt/gnu/gcc/gcc-4.7/hppa2.0w-hp-hpux11.11/include
-isy
stem /opt/gnu/gcc/gcc-4.7/hppa2.0w-hp-hpux11.11/sys-include
-B/test/gnu/gcc/objd
ir/hppa2.0w-hp-hpux11.11/./libstdc++-v3/src/.libs -g -O2 -D_GLIBCXX_ASSERT
-fmes
sage-length=0 -g -O2 -g -O2 -DLOCALEDIR=. -nostdinc++
-I/test/gnu/gcc/objdir/h
ppa2.0w-hp-hpux11.11/libstdc++-v3/include/hppa2.0w-hp-hpux11.11
-I/test/gnu/gcc/
objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include
-I/test/gnu/gcc/gcc/libstdc++-
v3/libsupc++ -I/test/gnu/gcc/gcc/libstdc++-v3/include/backward
-I/test/gnu/gcc/g
cc/libstdc++-v3/testsuite/util
/test/gnu/gcc/gcc/libstdc++-v3/testsuite/libstdc+
+-prettyprinters/48362.cc -g -std=gnu++11 -O0 ./libtestc++.a -lm -o
./4836
2.exe(timeout = 600)
spawn /test/gnu/gcc/objdir/./gcc/g++ -shared-libgcc
-B/test/gnu/gcc/objdir/./gcc
-nostdinc++ -L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/src
-L/te
st/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/src/.libs
-B/opt/gnu/gcc/gc
c-4.7/hppa2.0w-hp-hpux11.11/bin/
-B/opt/gnu/gcc/gcc-4.7/hppa2.0w-hp-hpux11.11/li
b/ -isystem /opt/gnu/gcc/gcc-4.7/hppa2.0w-hp-hpux11.11/include -isystem
/opt/gnu
/gcc/gcc-4.7/hppa2.0w-hp-hpux11.11/sys-include
-B/test/gnu/gcc/objdir/hppa2.0w-h
p-hpux11.11/./libstdc++-v3/src/.libs -g -O2 -D_GLIBCXX_ASSERT
-fmessage-length=0
-g -O2 -g -O2 -DLOCALEDIR=. -nostdinc++
-I/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include/hppa2.0w-hp-hpux11.11
-I/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include
-I/test/gnu/gcc/gcc/libstdc++-v3/libsupc++
-I/test/gnu/gcc/gcc/libstdc++-v3/include/backward
-I/test/gnu/gcc/gcc/libstdc++-v3/testsuite/util
/test/gnu/gcc/gcc/libstdc++-v3/testsuite/libstdc++-prettyprinters/48362.cc -g
-std=gnu++11 -O0 ./libtestc++.a -lm -o ./48362.exe
Setting LD_LIBRARY_PATH to
:/test/gnu/gcc/objdir/gcc:/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libstdc++-v3/../libgomp/.libs:/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libstdc++-v3/src/.libs::/test/gnu/gcc/objdir/gcc:/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libstdc++-v3/../libgomp/.libs:/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libstdc++-v3/src/.libs
spawn [open ...]
PASS: libstdc++-prettyprinters/48362.cc execution test
Spawning: gdb -nx -nw -quiet -batch -x 48362.gdb ./48362.exe
spawn gdb -nx -nw -quiet -batch -x 48362.gdb ./48362.exe
Breakpoint 1 at 0x34f8: file
/test/gnu/gcc/gcc/libstdc++-v3/testsuite/libstdc++-prettyprinters/48362.cc,
line 33.
warning: Private mapping of shared library text was not specified
by the executable; setting a breakpoint in a shared library which
is not privately mapped will not work. See the HP-UX 11i v3 chatr
manpage for methods to privately map shared library text.
Breakpoint 1, main () at
/test/gnu/gcc/gcc/libstdc++-v3/testsuite/libstdc++-prettyprinters/48362.cc:33
33return 0; // Mark SPOT
$1 = {No data fields}
FAIL: libstdc++-prettyprinters/48362.cc print t1
$2 = {_Tuple_impl = {_Tuple_impl = {_Tuple_impl = {_Tuple_impl = {No
data fields}, _Head_base = {tuple = {No data fields}, No data fields},
No data fields}, _Head_base = {_M_head_impl = 5}, No data fields},
_Head_base = {_M_head_impl = {static npos = 4294967295, _M_dataplus =
{allocator = {new_allocator = {No data fields}, No data fields}, _M_p =
0x40003bd4 Johnny}}}, No data fields}, No data fields}
FAIL: libstdc++-prettyprinters/48362.cc print t2
extra_tool_flags are:
-std=gnu++11 -g
[Bug target/51934] FAIL: g++.dg/torture/pr51344.C -O0 (test for excess errors) due to cdecl attribute ignored warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51934
--- Comment #15 from Dominique d'Humieres dominiq at lps dot ens.fr
2012-01-23 15:19:37 UTC ---
Well, if it hangs before the fix with the noreturn attribute, then it is
trivial to replace the return a; with for (;;);
It does not hang:
macbook] f90/bug% cat pr51344_db.C
/* { dg-do compile } */
class A;
template class T
class B
{
friend __attribute__((noreturn)) A operator (A a, B b)
{
for (;;);
/* return a; */
}
};
[macbook] f90/bug% time g++-fsf-4.6 -c pr51344_db.C
0.010u 0.015s 0:00.05 40.0%0+0k 0+4io 0pf+0w
while
[macbook] f90/bug% cat pr51344_db.C
/* { dg-do compile } */
class A;
template class T
class B
{
friend __attribute__((format)) A operator (A a, B b)
{
for (;;);
/* return a; */
}
};
macbook] f90/bug% time g++-fsf-4.6 -c pr51344_db.C
^C0.002u 0.005s 0:37.44 0.0%0+0k 0+1io 0pf+0w
^
| interrupted
[Bug libstdc++/51967] FAIL: libstdc++-prettyprinters/48362.cc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51967
--- Comment #1 from John David Anglin danglin at gcc dot gnu.org 2012-01-23
15:20:35 UTC ---
Similar fail is libstdc++-prettyprinters/simple.cc:
Executing on host: /test/gnu/gcc/objdir/./gcc/g++ -shared-libgcc
-B/test/gnu/gcc
/objdir/./gcc -nostdinc++
-L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++
-v3/src -L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/src/.libs
-B/o
pt/gnu/gcc/gcc-4.7/hppa2.0w-hp-hpux11.11/bin/
-B/opt/gnu/gcc/gcc-4.7/hppa2.0w-hp
-hpux11.11/lib/ -isystem /opt/gnu/gcc/gcc-4.7/hppa2.0w-hp-hpux11.11/include
-isy
stem /opt/gnu/gcc/gcc-4.7/hppa2.0w-hp-hpux11.11/sys-include
-B/test/gnu/gcc/objd
ir/hppa2.0w-hp-hpux11.11/./libstdc++-v3/src/.libs -g -O2 -D_GLIBCXX_ASSERT
-fmes
sage-length=0 -g -O2 -g -O2 -DLOCALEDIR=. -nostdinc++
-I/test/gnu/gcc/objdir/h
ppa2.0w-hp-hpux11.11/libstdc++-v3/include/hppa2.0w-hp-hpux11.11
-I/test/gnu/gcc/
objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include
-I/test/gnu/gcc/gcc/libstdc++-
v3/libsupc++ -I/test/gnu/gcc/gcc/libstdc++-v3/include/backward
-I/test/gnu/gcc/g
cc/libstdc++-v3/testsuite/util
/test/gnu/gcc/gcc/libstdc++-v3/testsuite/libstdc+
+-prettyprinters/simple.cc -g ./libtestc++.a -lm -o ./simple.exe
(timeo
ut = 600)
spawn /test/gnu/gcc/objdir/./gcc/g++ -shared-libgcc
-B/test/gnu/gcc/objdir/./gcc
-nostdinc++ -L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/src
-L/te
st/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/src/.libs
-B/opt/gnu/gcc/gc
c-4.7/hppa2.0w-hp-hpux11.11/bin/
-B/opt/gnu/gcc/gcc-4.7/hppa2.0w-hp-hpux11.11/li
b/ -isystem /opt/gnu/gcc/gcc-4.7/hppa2.0w-hp-hpux11.11/include -isystem
/opt/gnu
/gcc/gcc-4.7/hppa2.0w-hp-hpux11.11/sys-include
-B/test/gnu/gcc/objdir/hppa2.0w-h
p-hpux11.11/./libstdc++-v3/src/.libs -g -O2 -D_GLIBCXX_ASSERT
-fmessage-length=0
-g -O2 -g -O2 -DLOCALEDIR=. -nostdinc++
-I/test/gnu/gcc/objdir/hppa2.0w-hp-hp
ux11.11/libstdc++-v3/include/hppa2.0w-hp-hpux11.11
-I/test/gnu/gcc/objdir/hppa2.
0w-hp-hpux11.11/libstdc++-v3/include -I/test/gnu/gcc/gcc/libstdc++-v3/libsupc++
-I/test/gnu/gcc/gcc/libstdc++-v3/include/backward
-I/test/gnu/gcc/gcc/libstdc++-v3/testsuite/util
/test/gnu/gcc/gcc/libstdc++-v3/testsuite/libstdc++-prettyprinters/simple.cc -g
./libtestc++.a -lm -o ./simple.exe
Setting LD_LIBRARY_PATH to
:/test/gnu/gcc/objdir/gcc:/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libstdc++-v3/../libgomp/.libs:/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libstdc++-v3/src/.libs::/test/gnu/gcc/objdir/gcc:/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libstdc++-v3/../libgomp/.libs:/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libstdc++-v3/src/.libs
spawn [open ...]
zardoz001011onetwoonetwozardozPASS: libstdc++-prettyprinters/simple.cc
execution test
Spawning: gdb -nx -nw -quiet -batch -x simple.gdb ./simple.exe
spawn gdb -nx -nw -quiet -batch -x simple.gdb ./simple.exe
Breakpoint 1 at 0x4970: file
/test/gnu/gcc/gcc/libstdc++-v3/testsuite/libstdc++-prettyprinters/simple.cc,
line 78.
warning: Private mapping of shared library text was not specified
by the executable; setting a breakpoint in a shared library which
is not privately mapped will not work. See the HP-UX 11i v3 chatr
manpage for methods to privately map shared library text.
Breakpoint 1, main () at
/test/gnu/gcc/gcc/libstdc++-v3/testsuite/libstdc++-prettyprinters/simple.cc:79
79std::cout bs;
$1 = {static npos = 4294967295, _M_dataplus = {allocator = {new_allocator =
{No data fields}, No data fields}, _M_p = 0x40004034 zardoz}}
FAIL: libstdc++-prettyprinters/simple.cc print str
$2 = {_Base_bitset = {_M_w = 161}, No data fields}
FAIL: libstdc++-prettyprinters/simple.cc print bs
$3 = {_Deque_base = {_M_impl = {allocator = {new_allocator = {No data
fields}, No data fields}, _M_map = 0x40004048, _M_map_size = 8, _M_start =
{_M_cur = 0x40004070, _M_first = 0x40004070, _M_last = 0x40004270, _M_node =
0x40004054}, _M_finish = {_M_cur = 0x40004078, _M_first = 0x40004070, _M_last =
0x40004270, _M_node = 0x40004054}}}, No data fields}
FAIL: libstdc++-prettyprinters/simple.cc print deq
$4 = {_List_base = {_M_impl = {allocator = {new_allocator = {No data
fields}, No data fields}, _M_node = {_M_next = 0x400042c0, _M_prev =
0x400042f0}}}, No data fields}
FAIL: libstdc++-prettyprinters/simple.cc print lst
$5 = {_M_t = {_M_impl = {allocator = {new_allocator = {No data fields},
No data fields}, _M_key_compare = {binary_function = {No data fields},
No data fields}, _M_header = {_M_color = _S_red, _M_parent = 0x40004328,
_M_left = 0x40004328, _M_right = 0x40004328}, _M_node_count = 1}}}
FAIL: libstdc++-prettyprinters/simple.cc print mp
testcase
/test/gnu/gcc/gcc/libstdc++-v3/testsuite/libstdc++-prettyprinters/prettyprinters.exp
completed in 67 seconds
[Bug debug/51902] lexical_blocks inside inlined_subroutines generate duplicate debug_ranges
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51902 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Attachment #26391|0 |1 is obsolete|| --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org 2012-01-23 15:25:09 UTC --- Created attachment 26432 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26432 gcc47-pr51902.patch Updated patch that ought to fix up redeclaration1.C. It is like the previous patch, but additionally for the duration in between reorder_blocks_1 and blocks_nreverse_all temporarily sets BLOCK_SUPERCONTEXT not to the supercontext origin block, but to the supercontext fragment in which it has been seen. This is then used in extra BLOCK_SAME_RANGE clearing. If we didn't adjust BLOCK_SUPERCONTEXT to the old meaning right away, if BLOCK_FRAGMENT_CHAIN (BLOCK_SUPERCONTEXT (block)) is different from BLOCK_SUPERCONTEXT (BLOCK_FRAGMENT_CHAIN (block)), we clear BLOCK_SAME_RANGE (block) as well. This should IMHO ensure that if BLOCK_SAME_RANGE is set, the .debug_range can be merged or tail merged with the parent. As the patch does adjust BLOCK_SUPERCONTEXT of the block in the same loop to avoid multiple chain walks, we remember it in prev_super variable instead.
[Bug libstdc++/51965] Redundant move constructions in heap algorithms
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51965 --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com 2012-01-23 15:26:34 UTC --- Indeed, I double checked that *before* changing the functions to use moves we had plain copies, that is the original HP/SGI functions had copies, nothing was passed by reference. Thus just doing what is suggested is unlikely to be correct.
[Bug target/51934] FAIL: g++.dg/torture/pr51344.C -O0 (test for excess errors) due to cdecl attribute ignored warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51934 --- Comment #16 from Jason Merrill jason at gcc dot gnu.org 2012-01-23 15:30:58 UTC --- Author: jason Date: Mon Jan 23 15:30:48 2012 New Revision: 183436 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=183436 Log: PR target/51934 * g++.dg/torture/pr51344.C: Limit to x86. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/torture/pr51344.C
[Bug c++/17729] [4.4/4.5/4.6/4.7 Regression] Duplicate __attribute__((deprecated)) warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17729 --- Comment #21 from Paolo Carlini paolo.carlini at oracle dot com 2012-01-23 15:30:25 UTC --- The problem with testing for duplicate diagnostics is by now well known, I guess. What I couldn't figure out from the audit trail was whether the fix itself was ready to go in or not, the trail badly lacked information. Anyway, many thanks for adding it now. I suppose I should not assign the bug to you? Or you actually feel like giving what Jason suggested a try?
[Bug libstdc++/51967] FAIL: libstdc++-prettyprinters/48362.cc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51967
--- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2012-01-23
15:39:52 UTC ---
do the printers ever work, outside the testsuite?
i.e. if you build this:
#include tuple
int main() {
std::tupleint, int t;
return std::tuple_sizedecltype(t)::value;
}
then debug and run
break 4
run
print t
you should see
$1 = std::tuple containing = {
[1] = 0,
[2] = 0
}
does it make any difference if you put this in ~/.gdbinit (with the correct
path to the installed gcc)?
python
import sys
sys.path.insert(0, '/path/to/gcc/share/gcc-4.7.0/python')
from libstdcxx.v6.printers import register_libstdcxx_printers
register_libstdcxx_printers (None)
end
[Bug c++/17729] [4.4/4.5/4.6/4.7 Regression] Duplicate __attribute__((deprecated)) warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17729 --- Comment #22 from Iain Sandoe iains at gcc dot gnu.org 2012-01-23 15:47:18 UTC --- (In reply to comment #21) The problem with testing for duplicate diagnostics is by now well known, I guess. What I couldn't figure out from the audit trail was whether the fix itself was ready to go in or not, the trail badly lacked information. Anyway, many thanks for adding it now. I suppose I should not assign the bug to you? Or you actually feel like giving what Jason suggested a try? I have no time at present - the bug is on my list, so if no-one else addresses it, and some time becomes available, I'll claim it then ;)
[Bug target/51934] FAIL: g++.dg/torture/pr51344.C -O0 (test for excess errors) due to cdecl attribute ignored warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51934 --- Comment #17 from Dominique d'Humieres dominiq at lps dot ens.fr 2012-01-23 15:50:16 UTC --- g++.dg/torture/pr51344.C: Limit to x86. Note that using 'format' instead of 'cdecl' hangs also on powerpc-apple-darwin9: [karma] f90/bug% time g++-fsf-4.6 pr51344_db.C ^C0.002u 0.006s 1:35.05 0.0%0+0k 2+7io 46pf+0w ^ | interrupted [karma] f90/bug% time /opt/gcc/gcc4.7w/bin/g++ -c pr51344_db.C 0.036u 0.071s 0:01.50 6.6%0+0k 16+10io 792pf+0w [karma] f90/bug% /opt/gcc/gcc4.7w/bin/g++ -v Using built-in specs. COLLECT_GCC=/opt/gcc/gcc4.7w/bin/g++ COLLECT_LTO_WRAPPER=/opt/gcc/gcc4.7w/libexec/gcc/powerpc-apple-darwin9.8.0/4.7.0/lto-wrapper Target: powerpc-apple-darwin9.8.0 Configured with: ../work/configure --prefix=/opt/gcc/gcc4.7w --enable-languages=c,c++,fortran,objc,obj-c++,java,ada,lto --with-gmp=/opt/mp --with-system-zlib --with-cloog=/opt/mp --enable-lto --enable-cloog-backend=isl Thread model: posix gcc version 4.7.0 20120121 (experimental) [trunk revision 183381p3] (GCC) If 'format' is invalid in this context, g++ should probably emit an error instead of hanging.
[Bug target/51934] FAIL: g++.dg/torture/pr51344.C -O0 (test for excess errors) due to cdecl attribute ignored warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51934 --- Comment #18 from Jakub Jelinek jakub at gcc dot gnu.org 2012-01-23 15:58:01 UTC --- I bet you'd have to instantiate the template to see the errors. Nevertheless, it would be a bad idea to add __attribute__((format)) to the testcase and expect that we don't error on that, perhaps one day we'd error on it even when not instantiated.
[Bug rtl-optimization/49847] [4.7 Regression] NULL deref in fold_rtx (prev_insn_cc0 == NULL)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49847 Andreas Schwab sch...@linux-m68k.org changed: What|Removed |Added Keywords||build Version|4.6.1 |4.7.0 Target Milestone|4.6.3 |4.7.0 Summary|[4.6/4.7 Regression] m68k |[4.7 Regression] NULL deref |gcj-4.6 NULL deref in |in fold_rtx (prev_insn_cc0 |fold_rtx (prev_insn_cc0 == |== NULL) |NULL) | --- Comment #12 from Andreas Schwab sch...@linux-m68k.org 2012-01-23 16:03:21 UTC --- The problem appears to be due to the exception region on a cc0 setter, which separates it from the cc0 consumer: (insn 4013 4012 8164 949 (set (cc0) (compare (reg:SF 912 [ D.26269 ]) (const_double:SF -2147483648 [0x8000] 2.147483648e+9 [0x0.8p+32]))) ../../../gcc/libjava/interpret.cc:131 -1 (expr_list:REG_EH_REGION (const_int 4 [0x4]) (nil))) (note 8164 4013 4014 950 [bb 950] NOTE_INSN_BASIC_BLOCK) (insn 4014 8164 4015 950 (set (reg:QI 2121) (ge:QI (cc0) (const_int 0 [0]))) ../../../gcc/libjava/interpret.cc:131 -1 (nil)) Happens in trunk since r180192.
[Bug fortran/51966] [4.6/4.7 Regression] ICE in gfc_conv_array_constructor_expr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51966 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 CC||jakub at gcc dot gnu.org
[Bug c++/51925] [4.7 Regression] ICE in tsubst with using and template function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51925 --- Comment #2 from Jason Merrill jason at gcc dot gnu.org 2012-01-23 16:35:44 UTC --- Author: jason Date: Mon Jan 23 16:35:31 2012 New Revision: 183438 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=183438 Log: PR c++/51925 * class.c (add_method): Set OVL_USED for using-decls. * tree.c (ovl_scope): New. * cp-tree.h: Declare it. * parser.c (cp_parser_template_name): Use it. * semantics.c (baselink_for_fns): Likewise. * name-lookup.c (set_inherited_value_binding_p): Likewise. Added: trunk/gcc/testsuite/g++.dg/template/using20.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/class.c trunk/gcc/cp/cp-tree.h trunk/gcc/cp/name-lookup.c trunk/gcc/cp/parser.c trunk/gcc/cp/semantics.c trunk/gcc/cp/tree.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/template/template-id-2.C
[Bug target/51968] New: gcc trunk (ARM) ICEs in final_scan_insn in final.c:2716, with could not split insn error msg
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51968
Bug #: 51968
Summary: gcc trunk (ARM) ICEs in final_scan_insn in
final.c:2716, with could not split insn error msg
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: eric.ba...@allegorithmic.com
Created attachment 26433
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26433
Preprocessed file that triggers the ICE
Trunk gcc compiled with Android's build-gcc.sh ICEs on the attached
preprocessed file.
The actual error message is:
../../../engine/src/filters/cpu/shader/jpeg_simd.cpp:753:1: error: could not
split insn
(insn 2104 4054 4050 (set (reg:V16QI 103 d20 [orig:846 D.35902 ] [846])
(vec_concat:V16QI (reg:V8QI 103 d20 [2317])
(reg:V8QI 105 d21 [2318])))
/home/eb/android-ndk-r6/toolchains/arm-linux-androideabi-4.7.0/prebuilt/linux-x86/lib/gcc/arm-linux-androideabi/4.7.0/include/arm_neon.h:5694
1348 {neon_vcombinev8qi}
(nil))
../../../engine/src/filters/cpu/shader/jpeg_simd.cpp:753:1: internal compiler
error: in final_scan_insn, at final.c:2716
This is a regression caused by commit 183051, and breaks a lot of Neon code in
our codebase :)
cc1plus command:
cc1plus -fpreprocessed jpeg_simd.ii -quiet -dumpbase jpeg_simd.cpp -mandroid
-mbionic -march=armv7-a -mcpu=cortex-a9 -mfloat-abi=softfp -mfpu=vfp -mfpu=neon
-marm -mtls-dialect=gnu -auxbase-strip
tmp/obj/android-g++/release/cpushader_neon/jpeg_simd.o -O2 -O2
-Wno-unused-function -Wno-psabi -Werror=implicit-function-declaration -Wall
-Wextra -Wno-strict-aliasing -Wno-unused -Wno-switch -Wno-comment -version
-fpic -flax-vector-conversions -fdata-sections -ffunction-sections
-fno-short-enums -fno-exceptions -fno-rtti -fvisibility=hidden
-fvisibility-inlines-hidden -fno-strict-aliasing -fPIC -o jpeg_simd.s
gcc -v -save-temps yields:
Using built-in specs.
COLLECT_GCC=/home/eb/android-ndk-r6/toolchains/arm-linux-androideabi-4.7.0/prebuilt/linux-x86/bin/arm-linux-androideabi-g++
COLLECT_LTO_WRAPPER=/home/eb/android-ndk-r6/toolchains/arm-linux-androideabi-4.7.0/prebuilt/linux-x86/libexec/gcc/arm-linux-androideabi/4.7.0/lto-wrapper
Target: arm-linux-androideabi
Configured with: /home/eb/android-ndk-r6/src/build/../gcc/gcc-4.7.0/configure
--prefix=/home/eb/android-ndk-r6/toolchains/arm-linux-androideabi-4.7.0/prebuilt/linux-x86
--target=arm-linux-androideabi --host=i386-linux-gnu --build=i386-linux-gnu
--with-gnu-as --with-gnu-ld --enable-languages=c,c++
--with-gmp=/tmp/ndk-eb/build/toolchain/temp-install
--with-mpfr=/tmp/ndk-eb/build/toolchain/temp-install
--with-mpc=/tmp/ndk-eb/build/toolchain/temp-install --disable-libssp
--enable-threads --disable-nls --disable-libmudflap --disable-libgomp
--disable-libstdc__-v3 --disable-sjlj-exceptions --disable-shared --disable-tls
--with-float=soft --with-fpu=vfp --with-arch=armv5te --enable-target-optspace
--enable-initfini-array --disable-nls
--prefix=/home/eb/android-ndk-r6/toolchains/arm-linux-androideabi-4.7.0/prebuilt/linux-x86
--with-sysroot=/home/eb/android-ndk-r6/toolchains/arm-linux-androideabi-4.7.0/prebuilt/linux-x86/sysroot
--with-binutils-version=2.21.53 --with-mpfr-version=3.0.1
--with-gmp-version=5.0.2 --with-gcc-version=4.7.0 --with-gdb-version=6.6
--with-mpc-version=0.9 --with-arch=armv5te --enable-libstdc__-v3
--program-transform-name='s,^,arm-linux-androideabi-,'
Thread model: posix
gcc version 4.7.0 20120123 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-c' '-mandroid' '-mbionic'
'-Wno-unused-function' '-Wno-psabi' '-march=armv7-a' '-mcpu=cortex-a9'
'-mfloat-abi=softfp' '-mfpu=vfp' '-fpic'
'-Werror=implicit-function-declaration' '-flax-vector-conversions'
'-fdata-sections' '-ffunction-sections' '-fno-short-enums' '-D' 'ANDROID' '-D'
'__ARM_ARCH_5__' '-D' '__ARM_ARCH_5T__' '-D' '__ARM_ARCH_5E__' '-D'
'__ARM_ARCH_5TE__' '-D' '__ARM_NEON__' '-D' 'S_IWRITE=0200' '-D'
'HAVE_USR_INCLUDE_MALLOC_H' '-D' 'MADV_FREE=5' '-D' 'LINUX' '-D'
'PAGE_SIZE=0x400' '-D' 'HAVE_PTHREAD_MUTEX_TIMEDLOCK' '-D' 'HAVE_SYS_SEM_H'
'-D' 'WEBPLUG=0' '-D' 'GAMERELEASE=1' '-D' 'DEBUGMODE=0' '-D' 'UNITY_RELEASE=1'
'-D' 'ENABLE_PROFILER=0' '-D' 'ANDROID' '-D' 'OS_ANDROID' '-D'
'_STLP_HAS_WCHAR_T' '-D' 'BOOST_NO_CWCHAR' '-D' 'ALG_DEBUG_SIMPLEOUTPUT' '-D'
'QT_NO_QWS_TRANSFORMED' '-fno-exceptions' '-fno-rtti' '-fvisibility=hidden'
'-fvisibility-inlines-hidden' '-mfpu=neon' '-O2' '-marm' '-O2'
'-fno-strict-aliasing' '-fPIC' '-D' '_REENTRANT' '-Wall' '-Wextra'
'-Wno-strict-aliasing' '-Wno-unused' '-Wno-switch' '-Wno-comment' '-D'
'ALG_MAIN_CPU_ON' '-D' 'FX_PRJ_RDXM' '-D' 'FX_PRJ_DXTENC' '-D' 'FX_PRJ_PVRENC'
'-D' 'FX_PRJ_ETC' '-D' 'emit=' '-D' 'NDEBUG' '-D' 'ALG_ISA_NEON' '-D'
'FX_ARCH_CURRENT_NEON' '-D' 'FX_ARCH_ON_NEON' '-D' 'ALG_DEBUG_SIMPLEOUTPUT'
'-I' '/usr/lib/qt4/mkspecs/android-g++' '-I
[Bug bootstrap/51969] New: [4.7 regression] gcc 4.7 unable to build gcc 4.6
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51969 Bug #: 51969 Summary: [4.7 regression] gcc 4.7 unable to build gcc 4.6 Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: mar...@trippelsdorf.de gcc-4.7 doesn't build gcc-4.6 anymore: gtype-desc.c:8893:18: error: subscripted value is neither array nor pointer nor vector gtype-desc.c:9012:36: error: subscripted value is neither array nor pointer nor vector gtype-desc.c:9096:31: error: subscripted value is neither array nor pointer nor vector gtype-desc.c:9117:31: error: subscripted value is neither array nor pointer nor vector gtype-desc.c:9124:31: error: subscripted value is neither array nor pointer nor vector gtype-desc.c:9131:31: error: subscripted value is neither array nor pointer nor vector make[3]: *** [gtype-desc.o] Error 1 make[3]: *** Waiting for unfinished jobs or with --enable-build-with-cxx: gtype-desc.c:8893:20: error: no match for ‘operator[]’ in ‘x_rtl[0]’ gtype-desc.c:9012:38: error: no match for ‘operator[]’ in ‘default_target_libfuncs[0]’ gtype-desc.c:9096:33: error: no match for ‘operator[]’ in ‘default_target_rtl[0]’ gtype-desc.c:9117:33: error: no match for ‘operator[]’ in ‘default_target_rtl[0]’ gtype-desc.c:9124:33: error: no match for ‘operator[]’ in ‘default_target_rtl[0]’ gtype-desc.c:9131:33: error: no match for ‘operator[]’ in ‘default_target_rtl[0]’ make[3]: *** [gtype-desc.o] Error 1 make[3]: *** Waiting for unfinished jobs (gcc-4.6.3 builds gcc-4.6 without problems.)
[Bug c++/51925] [4.7 Regression] ICE in tsubst with using and template function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51925 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #3 from Jason Merrill jason at gcc dot gnu.org 2012-01-23 17:00:23 UTC --- Fixed.
[Bug c++/51812] [4.7 regression] Virtual public inheritance and thunks leads to undefined reference in header files.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51812 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |jason at gcc dot gnu.org |gnu.org |
[Bug c++/51398] [4.7 Regression] ICE with invalid template parameter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51398 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |paolo.carlini at oracle dot |gnu.org |com --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com 2012-01-23 17:04:49 UTC --- Mine.
[Bug testsuite/51941] FAIL: g++.dg/debug/dwarf2/nested-3.C scan-assembler
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51941 --- Comment #5 from Dodji Seketeli dodji at gcc dot gnu.org 2012-01-23 17:05:53 UTC --- Author: dodji Date: Mon Jan 23 17:05:46 2012 New Revision: 183441 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=183441 Log: PR testsuite/51941 - FAIL g++.dg/debug/dwarf2/nested-3.C on Darwin gcc/testsuite/ PR testsuite/51941 * g++.dg/debug/dwarf2/nested-3.C: Accept multiple lines between the DW_TAG_class_type and DW_AT_name: Executor. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/debug/dwarf2/nested-3.C
[Bug testsuite/51941] FAIL: g++.dg/debug/dwarf2/nested-3.C scan-assembler
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51941 Dodji Seketeli dodji at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #6 from Dodji Seketeli dodji at gcc dot gnu.org 2012-01-23 17:06:57 UTC --- Fixed in trunk (4.7)
[Bug fortran/51970] New: gimplification failed for an avatar of pr51948
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51970 Bug #: 51970 Summary: gimplification failed for an avatar of pr51948 Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: domi...@lps.ens.fr CC: bur...@net-b.de Compiling the following (invalid?) avatar of pr51948 type t end type t contains function func(x) class(t), allocatable :: x(:), func2(:) call move_alloc (x, func2) ! FAILS: Error: the 'from' and 'to' arguments of 'move_alloc' intrinsic at (1) must have the same rank 0/1 end function function func2(x) type(t), allocatable :: x class(t), allocatable :: func2 call move_alloc (x, func2) ! FAILS: Error: 'to' argument of 'move_alloc' intrinsic at (1) must be a variable end function end gives the following ICE gimplification failed: func2._data addr_expr 0x142d38550 type pointer_type 0x142d332a0 type record_type 0x142d2fdc8 array1_t type_1 BLK size integer_cst 0x142d0db80 constant 384 unit size integer_cst 0x142d0d600 constant 48 align 64 symtab 0 alias set -1 canonical type 0x142d2fe70 fields field_decl 0x142d21a18 data pointer_to_this pointer_type 0x142d332a0 chain type_decl 0x142d310b8 D.1886 public unsigned DI size integer_cst 0x142c0c940 constant 64 unit size integer_cst 0x142c0c960 constant 8 align 64 symtab 0 alias set -1 canonical type 0x142d33348 arg 0 component_ref 0x142d0c540 type record_type 0x142d2fdc8 array1_t arg 0 var_decl 0x142c0e640 func2 type record_type 0x142d2f9d8 __class_MAIN___T_1_a addressable used BLK file pr51948_db.f90 line 6 col 0 size integer_cst 0x142d0d820 constant 448 unit size integer_cst 0x142d0d860 constant 56 align 64 context function_decl 0x142d2a500 func arg 1 field_decl 0x142d32130 _data type record_type 0x142d2fdc8 array1_t BLK file pr51948_db.f90 line 6 col 0 size integer_cst 0x142d0db80 384 unit size integer_cst 0x142d0d600 48 align 64 offset_align 128 offset integer_cst 0x142c0c980 constant 0 bit offset integer_cst 0x142c0c9e0 constant 0 context record_type 0x142d2f9d8 __class_MAIN___T_1_a chain field_decl 0x142d321c8 _vptr pr51948_db.f90:7:0 pr51948_db.f90:7:0 pr51948_db.f90: In function 'func': pr51948_db.f90:7:0: internal compiler error: gimplification failed This may due to the patch at http://gcc.gnu.org/ml/fortran/2012-01/msg00213.html . The code is accepted by trunk r183357.
[Bug c/51971] New: unclear/unverified restrictions on attribute((const|pure))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51971 Bug #: 51971 Summary: unclear/unverified restrictions on attribute((const|pure)) Classification: Unclassified Product: gcc Version: 4.6.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: akim.demai...@gmail.com Created attachment 26434 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26434 Declare pure functions which obviously do not return Hi, The documentation for const and pure is not clear about the fact that functions should return normally: Interesting non-pure functions are functions with infinite loops or those depending on volatile memory or other system resource, that may change between two consecutive calls (such as feof in a multithreading environment). In particular, at that point nothing is said about abort(). This is something which does appear in the documentation of -Wsuggest-attribute, yet at that point it is still unclear (to me?): The compiler only warns for functions visible in other compilation units or (in the case of pure and const) if it cannot prove that the function returns normally. It does not say do not flag as pure if the function does not return normally. It does not tell either how to silence the suggestion if the function is not pure. The warning itself is clearer though: akim@boss ~/src/gcc $ g++-mp-4.6 -O2 -Wsuggest-attribute=pure -c gcc/testsuite/gcc.dg/pure-2.c gcc/testsuite/gcc.dg/pure-2.c: In function 'int foo3(int)': gcc/testsuite/gcc.dg/pure-2.c:38:1: warning: function might be candidate for attribute 'pure' if it is known to return normally [-Wsuggest-attribute=pure] I think that the documentation should also unveil why there is this restriction. The documentation for pure mentions: Such a function can be subject to common subexpression elimination and loop optimization just as an arithmetic operator would be. It also rules out every use of assert, which is a serious limitation, even for pure functions. Does that mean that the function might be called _because_ of the optimization? In which case, yes, indeed, looping or aborting becomes a problem :) Can CSE really introduce extraneous calls? The doc does not say so (it says fewer, not more): For example, int square (int) __attribute__ ((pure)); says that the hypothetical function square is safe to call fewer times than the program says. Finally, if really non-normally returning functions are ruled out, then GCC should diagnose misuses, such as the attached one. akim@padam /tmp $ gcc-mp-4.6 -O2 -Wall -Wextra -Wsuggest-attribute=pure -Wsuggest-attribute=const -c /tmp/pure.c akim@padam /tmp $ echo $? 0 akim@padam /tmp $ gcc-mp-4.6 --version gcc-mp-4.6 (GCC) 4.6.2 Copyright (C) 2011 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
[Bug fortran/51972] New: [OOP] ALLOCATE misses memset/calloc, causing segfault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51972 Bug #: 51972 Summary: [OOP] ALLOCATE misses memset/calloc, causing segfault Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org Created attachment 26435 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26435 Test case The test case is a reduced version of chapter07/strategy_surrogate_f2003, available from http://www.cambridge.org/rouson under Resources available. When compiling and running the program, one might get: Program received signal SIGABRT: Process abort signal. Backtrace for this error: #6 0x400AC5 in __lorenz_module_MOD___copy_lorenz_module_Lorenz at test.F90:42 #7 0x401392 in __runge_kutta_2nd_module_MOD_integrate at test.F90:73 #8 0x40153F in MAIN__ at test.F90:84 And with valgrind: Conditional jump or move depends on uninitialised value(s) at 0x400AD8: __lorenz_module_MOD___copy_lorenz_module_Lorenz (test.F90:42) by 0x4013B2: __runge_kutta_2nd_module_MOD_integrate (test.F90:73) The issue is that there is MEMSET or CALLOC missing in integrate. There is a call to memset in constructor and assign_lorenz.
[Bug target/51968] gcc trunk (ARM) ICEs in final_scan_insn in final.c:2716, with could not split insn error msg
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51968 --- Comment #1 from Eric Batut eric.batut at allegorithmic dot com 2012-01-23 17:36:50 UTC --- Adding Richard Henderson, who committed rev 183051.
[Bug fortran/51946] file compiles properly on IBM xlf compiler and Cray compiler
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51946 --- Comment #10 from Tobias Burnus burnus at gcc dot gnu.org 2012-01-23 17:37:18 UTC --- (In reply to comment #4) Otherwise, as far as I could see, all Fortran examples work except for - chapter07/strategy_surrogate_f2003: Segfaults in __timed_lorenz_module_MOD___copy_timed_lorenz_module_Timed_lorenz (not yet debugged) That's now PR 51972.
[Bug fortran/51970] gimplification failed for an avatar of pr51948
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51970 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC|bur...@net-b.de |burnus at gcc dot gnu.org --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2012-01-23 17:43:32 UTC --- (In reply to comment #0) The code is accepted by trunk r183357. And it crashes in the same way with 4.7.0 2012-01-18 trunk revision 183273. (In any case it is not a (real) regression as GCC 4.6 didn't support polymorphic arrays.)
