[Bug libgomp/44833] unexpected thread binding for openmp
--- Comment #6 from jv244 at cam dot ac dot uk 2010-07-08 06:24 --- I have also tried to run the testcase with export OMP_WAIT_POLICY=active export GOMP_SPINCOUNT=infinity which I would assume to keep the threads alive, and so there would be no need to create these new threads (the number of active threads is never more than 8), and still this strange binding persists. Jakub, is there any practical way to avoid recreating these threads ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44833
[Bug c++/44815] Compiz Core miscompiles with GCC 4.5
--- Comment #4 from smspillaz at gmail dot com 2010-07-08 06:36 --- (In reply to comment #3) Really I think this is a violation of the One definition rule. What do you mean by this? Is it our bug (do we need to change RTLD_LAZY)? Or GCC's bug? If it is the former, can the documentation for the GCC linker please be updated to reflect this change in behaviour? Thanks, Sam (compiz developer) -- smspillaz at gmail dot com changed: What|Removed |Added CC||smspillaz at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44815
[Bug fortran/44863] Fortran runtime error: internal error: bad hash value in dynamic dispatch
--- Comment #2 from burnus at gcc dot gnu dot org 2010-07-08 07:22 --- Can you update to GCC 4.6? I get the same error with 4.5, but with 4.6 I get the same result as with NAG or Intel. The reason is that gfortran now uses a proper vtable. Or in the words of http://gcc.gnu.org/gcc-4.6/changes.html : * Improved support for polymorphism between libraries and programs and for complicated inheritance patterns (cf. http://gcc.gnu.org/wiki/OOP) Newer binaries can be found at http://gcc.gnu.org/wiki/GFortranBinaries -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44863
[Bug fortran/44864] internal compiler error: Segmentation fault
--- Comment #1 from burnus at gcc dot gnu dot org 2010-07-08 07:26 --- Same solution as in PR 44863: I can reproduce the problem in 4.5, but updating to 4.6 works. Both PRs are kind of a duplicate of PR 41829. As written: 4.6 binaries are available at http://gcc.gnu.org/wiki/GFortranBinaries For the implementation/bug status, see http://gcc.gnu.org/wiki/GFortranBinaries Thanks nevertheless for reporting the bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44864
[Bug fortran/44693] Missed error for invalid SUM
--- Comment #5 from burnus at gcc dot gnu dot org 2010-07-08 07:27 --- Thanks for the bug fix! For completeness, the commit was: Author: tkoenig Date: Tue Jul 6 19:48:58 2010 New Revision: 161884 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161884 Log: 2010-07-06 Thomas Koenig tkoe...@gcc.gnu.org PR fortran/PR44693 * check.c (dim_rank_check): Also check intrinsic functions. Adjust permissible rank for functions which reduce the rank of their argument. Spread is an exception, where DIM can be one larger than the rank of array. 2010-07-06 Thomas Koenig tkoe...@gcc.gnu.org PR fortran/PR44693 * gfortran.dg/dim_range_1.f90: New test. * gfortran.dg/minmaxloc_4.f90: Remove invalid test. Added: trunk/gcc/testsuite/gfortran.dg/dim_range_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/check.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/minmaxloc_4.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44693
[Bug c/44828] [4.3/4.4/4.5 Regression] possible integer wrong code bug
--- Comment #10 from jakub at gcc dot gnu dot org 2010-07-08 07:47 --- I'd say the test instead just should use signed char instead of char. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44828
[Bug libgomp/44833] unexpected thread binding for openmp
--- Comment #7 from jakub at gcc dot gnu dot org 2010-07-08 07:54 --- Currently libgomp terminates all threads immediately, unless mandated by the standard (i.e. in non-nested case the threads need to be kept around until next omp parallel). Yes, it would be possible to keep other threads around, the question is how many and how long, at which point start to destroy them. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44833
[Bug rtl-optimization/44858] likely integer wrong code bug
-- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Component|c |rtl-optimization Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-07-08 08:14:08 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44858
[Bug rtl-optimization/44858] likely integer wrong code bug
--- Comment #1 from jakub at gcc dot gnu dot org 2010-07-08 08:37 ---
Things go wrong in the combiner:
(insn 21 42 22 6 pr44858.c:16 (parallel [
(set (reg/v:SI 62 [ c ])
(and:SI (reg:SI 68)
(const_int 2 [0x2])))
(clobber (reg:CC 17 flags))
]) 375 {*andsi_1} (expr_list:REG_DEAD (reg:SI 68)
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil
(insn 22 21 23 6 pr44858.c:17 (set (reg:CCZ 17 flags)
(compare:CCZ (mem/c/i:SI (symbol_ref:SI (a) [flags 0x2] var_decl
0x7f8d06f05000 a) [0 a+0 S4 A32])
(const_int 0 [0]))) 2 {*cmpsi_ccno_1} (nil))
(insn 23 22 24 6 pr44858.c:17 (set (reg:QI 70)
(ne:QI (reg:CCZ 17 flags)
(const_int 0 [0]))) 570 {*setcc_qi} (expr_list:REG_DEAD (reg:CCZ 17
flags)
(nil)))
(insn 24 23 25 6 pr44858.c:17 (parallel [
(set (reg:SI 69)
(zero_extend:SI (reg:QI 70)))
(clobber (reg:CC 17 flags))
]) 119 {*zero_extendqisi2_movzbl_and} (expr_list:REG_DEAD (reg:QI 70)
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil
(insn 25 24 26 6 pr44858.c:17 (parallel [
(set (reg:SI 65 [ b.2 ])
(ior:SI (reg/v:SI 62 [ c ])
(reg:SI 69)))
(clobber (reg:CC 17 flags))
]) 394 {*iorsi_1} (expr_list:REG_DEAD (reg:SI 69)
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil
changes into:
(note 21 42 22 6 NOTE_INSN_DELETED)
(insn 22 21 23 6 pr44858.c:17 (set (reg:CCZ 17 flags)
(compare:CCZ (mem/c/i:SI (symbol_ref:SI (a) [flags 0x2] var_decl
0x7f8d06f05000 a) [0 a+0 S4 A32])
(const_int 0 [0]))) 2 {*cmpsi_ccno_1} (nil))
(note 23 22 24 6 NOTE_INSN_DELETED)
(insn 24 23 25 6 pr44858.c:17 (parallel [
(set (reg/v:SI 62 [ c ])
(and:SI (reg:SI 68)
(const_int 2 [0x2])))
(clobber (reg:CC 17 flags))
]) 375 {*andsi_1} (expr_list:REG_UNUSED (reg:CC 17 flags)
(expr_list:REG_DEAD (reg:SI 68)
(nil
(insn 25 24 26 6 pr44858.c:17 (set (reg:SI 65 [ b.2 ])
(ne:SI (reg:CCZ 17 flags)
(const_int 0 [0]))) 569 {*setcc_si_1_movzbl} (expr_list:REG_DEAD
(reg:CC 17 flags)
(nil)))
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44858
[Bug debug/44832] [4.6 Regression] -fcompare-debug failure for C++ i386.c
--- Comment #35 from rguenther at suse dot de 2010-07-08 08:46 --- Subject: Re: [4.6 Regression] -fcompare-debug failure for C++ i386.c On Thu, 8 Jul 2010, amylaar at gcc dot gnu dot org wrote: --- Comment #34 from amylaar at gcc dot gnu dot org 2010-07-08 01:10 --- FWIW, this simple patch stops the comparison failures both for my reduced testcase as for the original testcase. I'm not sure if we want to pay the price of carryinig more labels around for -g0, or if we'd rather fix the ordering issues somehow. The ordering issue in VRP needs to be fixed. The sorting can use LABEL_DECL_UID which is dense in a given function. (but watch out for a -1 value where no UID has been assigned) Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44832
[Bug libgomp/44833] unexpected thread binding for openmp
--- Comment #8 from jv244 at cam dot ac dot uk 2010-07-08 08:55 --- (In reply to comment #7) Yes, it would be possible to keep other threads around, the question is how many and how long, at which point start to destroy them. I can test what other implementations are doing, but I suspect that for the non-nested case, OMP_NUM_THREADS will be created and never destroyed. At least for HPC applications this seems to make sense. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44833
[Bug rtl-optimization/44838] [4.6 regression] RTL loop unrolling causes FAIL: gcc.dg/pr39794.c
--- Comment #31 from rguenth at gcc dot gnu dot org 2010-07-08 09:09 --- Subject: Bug 44838 Author: rguenth Date: Thu Jul 8 09:09:15 2010 New Revision: 161945 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161945 Log: 2010-07-08 Richard Guenther rguent...@suse.de PR rtl-optimization/44838 * tree-ssa-alias.c (indirect_refs_may_alias_p): When not in SSA form do not use pointer equivalence. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-alias.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44838
[Bug tree-optimization/44861] internal compiler error: in vectorizable_load, at tree-vect-stmts.c:3812
--- Comment #1 from irar at il dot ibm dot com 2010-07-08 09:14 --- The failure is in vectorizable_store(): /* If accesses through a pointer to vectype do not alias the original memory reference we have a problem. This should never happen. */ gcc_assert (alias_sets_conflict_p (get_alias_set (data_ref), get_alias_set (gimple_assign_lhs (stmt; Since MEM_REF merge the types struct Foo * and struct counted_base * pass types_compatible_p() test in vect_check_interleaving(). But in revision 161655 (the merge) the basic block gets vectorized and there is no ICE. -- irar at il dot ibm dot com changed: What|Removed |Added CC||richard dot guenther at ||gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44861
[Bug rtl-optimization/44838] [4.6 regression] RTL loop unrolling causes FAIL: gcc.dg/pr39794.c
--- Comment #32 from rguenth at gcc dot gnu dot org 2010-07-08 09:16 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44838
[Bug fortran/44702] ISO_C_BINDING does not allow multiple USE, ONLY local names.
--- Comment #2 from burnus at gcc dot gnu dot org 2010-07-08 09:21 --- Joe, as work around you can do the following: splitting the single USE statement into multiple: use ISO_C_Binding, only: C_ptr use ISO_C_Binding, only: C_char_ptr=C_ptr * * * I think there are two (three) bugs: (a) without only, one needs to move the generation into the inner loop and remove the break - though, if no variable was found in the rename list, it needs still be created (i.e. the symbol creation should also be after the loop). (b) For ONLY:, the code sort_iso_c_rename_list in module.c is wrong: It assumes that there can be only one rename ... Maybe, it is the simplest to merge only and not-only and simply add if (!found !only) after the inner rename loop; then, sort_iso_c_rename_list can also be removed. (c) Without only flag, ISO_Fortran_ENV has the same problem (cf. a) - it works with ONLY. The solution is again to move the creation into the loop. But as there are many checks, an auxiliary function should probably be used. Failing example: use iso_fortran_env, one = ERROR_UNIT, ! Works with only two = ERROR_UNIT implicit none if (one /= two) error stop 'Something is fishy' end -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44702
[Bug tree-optimization/44861] [4.6 Regression] internal compiler error: in vectorizable_load, at tree-vect-stmts.c:3812
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-07-08 09:30 --- Mine. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC|richard dot guenther at | |gmail dot com | AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-07-08 09:30:28 date|| Summary|internal compiler error: in |[4.6 Regression] internal |vectorizable_load, at tree- |compiler error: in |vect-stmts.c:3812 |vectorizable_load, at tree- ||vect-stmts.c:3812 Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44861
[Bug middle-end/44866] New: [4.6 regression] internal compiler error: verify_stmts failed: error: Incompatible types in PHI argument 1
This is for Wine, a regression that happened in the last week or two: /files/pfeifer/gcc/bin/gcc -c -O2 nbcmdqueue.i nbcmdqueue.c: In function NBCmdQueueCancel: nbcmdqueue.c:107:7: error: Incompatible types in PHI argument 1 struct _NCB * UCHAR D.9146_56 = PHI D.9167_60(8), D.9168_61(9) nbcmdqueue.c:107:7: internal compiler error: verify_stmts failed Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Interestingly enough, if I use -O1 instead of -O2 the failure remains, alas a few lines earlier. -- Summary: [4.6 regression] internal compiler error: verify_stmts failed: error: Incompatible types in PHI argument 1 Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: gerald at pfeifer dot com GCC host triplet: i386-unknown-freebsd7.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44866
[Bug middle-end/44866] [4.6 regression] internal compiler error: verify_stmts failed: error: Incompatible types in PHI argument 1
--- Comment #1 from gerald at pfeifer dot com 2010-07-08 09:43 --- Created an attachment (id=21138) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21138action=view) Input file triggering the verification failure -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44866
[Bug rtl-optimization/44858] [4.5/4.6 Regression] likely integer wrong code bug
--- Comment #2 from jakub at gcc dot gnu dot org 2010-07-08 09:58 --- Caused by http://gcc.gnu.org/viewcvs?root=gccview=revrev=152642 -- jakub at gcc dot gnu dot org changed: What|Removed |Added CC||uros at gcc dot gnu dot org AssignedTo|jakub at gcc dot gnu dot org|unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW Summary|likely integer wrong code |[4.5/4.6 Regression] likely |bug |integer wrong code bug http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44858
[Bug rtl-optimization/44858] [4.5/4.6 Regression] likely integer wrong code bug
--- Comment #3 from jakub at gcc dot gnu dot org 2010-07-08 10:01 ---
Updated testcase:
extern void abort (void);
int a = 3;
int b = 1;
__attribute__((noinline)) long long
foo (int x, int y)
{
return x / y;
}
__attribute__((noinline)) int
bar (void)
{
int c = 2;
c = foo (1, b) b;
b = (a != 0) | c;
return c;
}
int
main (void)
{
if (bar () != 0 || b != 1)
abort ();
return 0;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44858
[Bug rtl-optimization/44867] New: 10% runtime regression on Polyhedron channel banchmark from 29. June 2010
According to [1] and [2], a 10% runtime regression has hit channel Polyhedron benchmark between 29th and 30th of July. My best uneducated blind shot would be r161570: * recog.c (peep2_do_rebuild_jump_labels, peep2_do_cleanup_cfg): New static variables. (peep2_buf_position): New static function. (peep2_regno_dead_p, peep2_reg_dead_p, peep2_find_free_register, peephole2_optimize): Use it. (peep2_attempt, peep2_update_life): New static functions, broken out of peephole2_optimize. (peep2_fill_buffer): New static function. (peephole2_optimize): Change the main loop to try to fill the buffer with the maximum number of insns before matching them against peepholes. Use a forward scan. Remove special case for targets with conditional execution. * genrecog.c (change_state): Delete dead code. * config/i386/i386.md (peephole2 for arithmetic ops with memory): Rewrite so as not to expect the second insn to have had a peephole applied yet. I will try to confirm this via bisection. [1] http://gcc.opensuse.org/c++bench/polyhedron/polyhedron-summary.txt-2-0.html [2] http://gcc.opensuse.org/c++bench/polyhedron/polyhedron-summary.txt -- Summary: 10% runtime regression on Polyhedron channel banchmark from 29. June 2010 Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ubizjak at gmail dot com GCC build triplet: x86_64-pc-linux-gnu GCC host triplet: x86_64-pc-linux-gnu GCC target triplet: x86_64-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44867
[Bug fortran/44868] New: [OOP] Error recovery: ICE after invalid TBP call
Reported at http://gcc.gnu.org/ml/fortran/2010-07/msg00048.html by Satish.BD The error is properly diagnosed but afterwards, an ICE occurs (on the report's system). For me, only invalid reads and writes are shown in valgrind: http://gcc.gnu.org/ml/fortran/2010-07/msg00051.html I will fill another PR for the follow up problem. -- Summary: [OOP] Error recovery: ICE after invalid TBP call Product: gcc Version: 4.6.0 Status: UNCONFIRMED Keywords: ice-on-invalid-code, error-recovery Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44868
[Bug fortran/44869] New: [OOP] Missing TARGET check - and wrong code or accepts-invalid?
Reported by Satish.BD at http://gcc.gnu.org/ml/fortran/2010-07/msg00059.html The shown (cf. URL) program compiles without any errors, but segfaults when at run time. Two of my other compiles diagnosed the following failure (gfortran not): - In line 220, the access to tst_case = self%list requires a TARGET attribute for self (which is not diagnosed in gfortran). Ditto for lines 231 and 245. One compiler additionally complained that for - call suite%add(first_test, test_a) and call self%assert(1,2, 1233 , generic_tbp.f90, purposely failed) no specific subprogram could be found (I have not checked this) The other compiler, compiles and the resulting program does not segfault but prints: We have4 failure(s). 1) first_test: generic_tbp.f90:1233 purposely failed: expected 1 but was 2 2) second_test: generic_tbp.f90: 324 purposely passed: expected 3.5000E+00 but was 2.6745E+00 3) third_test: generic_tbp.f90:1233 purposely failed: expected 1 but was 2 4) last_test: generic_tbp.f90: 324 purposely passed: expected 3.5000E+00 but was 2.6745E+00 !!! FAILURES !!! Runs: 4 Passes: 0 Fails: 4 -- Summary: [OOP] Missing TARGET check - and wrong code or accepts- invalid? Product: gcc Version: 4.6.0 Status: UNCONFIRMED Keywords: accepts-invalid Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44869
[Bug fortran/44869] [OOP] Missing TARGET check - and wrong code or accepts-invalid?
--- Comment #1 from burnus at gcc dot gnu dot org 2010-07-08 10:29 --- Created an attachment (id=21139) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21139action=view) Test case (without TARGET; corrected line breaks from the mail paste) For the error recovery (first mail in the thread), see PR 44868 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44869
[Bug middle-end/44843] [4.6 regression] All 32-bit fortran execution tests SEGV on SPARC: unaligned access
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2010-07-08 10:31 --- With a cross. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-07-08 10:31:48 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44843
[Bug middle-end/44843] [4.6 regression] All 32-bit fortran execution tests SEGV on SPARC: unaligned access
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2010-07-08 10:32 --- Looking into it. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ebotcazou at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2010-07-08 10:31:48 |2010-07-08 10:32:20 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44843
[Bug fortran/44869] [OOP] Missing TARGET check - and wrong code or accepts-invalid?
--- Comment #2 from burnus at gcc dot gnu dot org 2010-07-08 10:33 --- If one removes the comment from the line marked with Uncomment this for the crash to occur gfortran gives an ICE: call tst%init() !! Uncomment this for the crash to occur 1 Error: Found no matching specific binding for the call to the GENERIC 'init' at (1) bd.f90:68:0: internal compiler error: Segmentation fault -- burnus at gcc dot gnu dot org changed: What|Removed |Added Keywords||ice-on-invalid-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44869
[Bug fortran/44868] [OOP] Error recovery: ICE after invalid TBP call
--- Comment #1 from burnus at gcc dot gnu dot org 2010-07-08 10:33 --- See also PR 44869. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44868
[Bug middle-end/44843] [4.6 regression] All 32-bit fortran execution tests SEGV on SPARC: unaligned access
--- Comment #5 from rguenther at suse dot de 2010-07-08 10:37 --- Subject: Re: [4.6 regression] All 32-bit fortran execution tests SEGV on SPARC: unaligned access On Thu, 8 Jul 2010, ebotcazou at gcc dot gnu dot org wrote: --- Comment #4 from ebotcazou at gcc dot gnu dot org 2010-07-08 10:32 --- Looking into it. I would say that previously TARGET_MEM_REFs were handled quite conservatively in mem-attr setting while now with MEM_REFs we (as for indirect-refs) derive alignment from types (ugh, old latent problem). My plan is to add alignment information to pointers and propagate that and just get rid of the alignment extraction from types during expansion. Thus, in the meantime I had installed that use-the-original dereference type thing (which isn't technically correct, at least for non-zero offsets, as they could be propagated in ...). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44843
[Bug tree-optimization/44831] [4.6 Regression] internal compiler error: verify_stmts failed when compiling wine
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-07-08 10:41 --- *** Bug 44866 has been marked as a duplicate of this bug. *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||gerald at pfeifer dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44831
[Bug middle-end/44866] [4.6 regression] internal compiler error: verify_stmts failed: error: Incompatible types in PHI argument 1
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-07-08 10:41 --- *** This bug has been marked as a duplicate of 44831 *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44866
[Bug tree-optimization/44861] [4.6 Regression] internal compiler error: in vectorizable_load, at tree-vect-stmts.c:3812
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-07-08 10:52 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44861
[Bug tree-optimization/44861] [4.6 Regression] internal compiler error: in vectorizable_load, at tree-vect-stmts.c:3812
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-07-08 10:52 --- Subject: Bug 44861 Author: rguenth Date: Thu Jul 8 10:51:46 2010 New Revision: 161949 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161949 Log: 2010-07-08 Richard Guenther rguent...@suse.de PR tree-optimization/44861 * tree-vect-stmts.c (vectorizable_store): Preserve TBAA information when building MEM_REFs. (vectorizable_load): Likewise. * tree-vect-data-refs.c (vect_setup_realignment): Likewise. * g++.dg/vect/pr44861.cc: New testcase. Added: trunk/gcc/testsuite/g++.dg/vect/pr44861.cc Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-data-refs.c trunk/gcc/tree-vect-stmts.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44861
[Bug debug/44832] [4.6 Regression] -fcompare-debug failure for C++ i386.c
--- Comment #36 from amylaar at gcc dot gnu dot org 2010-07-08 11:04 --- (In reply to comment #35) The ordering issue in VRP needs to be fixed. The sorting can use LABEL_DECL_UID which is dense in a given function. (but watch out for a -1 value where no UID has been assigned) I think that is too late; it would solve this particular failure, but AAUI, once we allow the relative order of decl_uids to become random, we've lost. There is also the wider issue that this entire business of allowing decl_uids to drift as long as ordering is preserved makes impossible to use dump comparisons as an effective means to determine in what pass things go wrong. It appears that in general, we use negative decl_uids for debug symbols, yet we may retain / copy non-debug symbols for reasons of debugging and let them have positive numbers. I wonder if it would be feasible to allocate new negative the uids for such symbols when they only remain for purposes of debugging, and when we somehow end up merging a debug and non-debug copy, the non-debug with its positive decl_uid should prevail. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44832
[Bug rtl-optimization/44867] 10% runtime regression on Polyhedron channel banchmark from 29. June 2010
--- Comment #1 from dominiq at lps dot ens dot fr 2010-07-08 11:08 --- This is likely a duplicate of pr44773. The time increase depends of the size of the cache. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44867
[Bug fortran/44847] ICE: OpenMP with Collapse clause and CYCLE stmt in loop
--- Comment #2 from jakub at gcc dot gnu dot org 2010-07-08 11:14 --- Created an attachment (id=21140) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21140action=view) gcc46-pr44847.patch Untested fix. Thanks for the report. -- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44847
[Bug rtl-optimization/44867] 10% runtime regression on Polyhedron channel banchmark from 29. June 2010
--- Comment #2 from ubizjak at gmail dot com 2010-07-08 11:17 --- (In reply to comment #1) This is likely a duplicate of pr44773. The time increase depends of the size of the cache. Oh, indeed. Thanks for your info and sorry for the noise. -- ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44867
[Bug rtl-optimization/44867] 10% runtime regression on Polyhedron channel banchmark from 29. June 2010
--- Comment #3 from dominiq at lps dot ens dot fr 2010-07-08 11:27 --- Could you mark this pr as duplicate rather than invalid? TIA -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44867
[Bug debug/44832] [4.6 Regression] -fcompare-debug failure for C++ i386.c
--- Comment #37 from rguenther at suse dot de 2010-07-08 11:31 --- Subject: Re: [4.6 Regression] -fcompare-debug failure for C++ i386.c On Thu, 8 Jul 2010, amylaar at gcc dot gnu dot org wrote: --- Comment #36 from amylaar at gcc dot gnu dot org 2010-07-08 11:04 --- (In reply to comment #35) The ordering issue in VRP needs to be fixed. The sorting can use LABEL_DECL_UID which is dense in a given function. (but watch out for a -1 value where no UID has been assigned) I think that is too late; it would solve this particular failure, but AAUI, once we allow the relative order of decl_uids to become random, we've lost. ? We don't allow the relative order of decl_uids to become random. Where do you think that happens? There is also the wider issue that this entire business of allowing decl_uids to drift as long as ordering is preserved makes impossible to use dump comparisons as an effective means to determine in what pass things go wrong. It appears that in general, we use negative decl_uids for debug symbols, yet we may retain / copy non-debug symbols for reasons of debugging and let them have positive numbers. This is what we have the -nouid modifier for. I wonder if it would be feasible to allocate new negative the uids for such symbols when they only remain for purposes of debugging, and when we somehow end up merging a debug and non-debug copy, the non-debug with its positive decl_uid should prevail. ? You have lost me here again. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44832
[Bug tree-optimization/44831] [4.6 Regression] internal compiler error: verify_stmts failed when compiling wine
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-07-08 11:38 --- Subject: Bug 44831 Author: rguenth Date: Thu Jul 8 11:38:43 2010 New Revision: 161950 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161950 Log: 2010-07-08 Richard Guenther rguent...@suse.de PR tree-optimization/44831 * tree-ssa-phiprop.c (phiprop_insert_phi): Properly build a MEM_REF preserving TBAA info of the original dereference. Dereference the original pointer if the address is not invariant. (propagate_with_phi): Fixup type checks wrt MEM_REFs. Require at least one invariant address that we are going to dereference. * gcc.c-torture/compile/pr44831.c: New testcase. * gcc.dg/tree-ssa/pr21463.c: Adjust. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr44831.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/tree-ssa/pr21463.c trunk/gcc/tree-ssa-phiprop.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44831
[Bug tree-optimization/44831] [4.6 Regression] internal compiler error: verify_stmts failed when compiling wine
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-07-08 11:39 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44831
[Bug rtl-optimization/44867] 10% runtime regression on Polyhedron channel banchmark from 29. June 2010
--- Comment #4 from ubizjak at gmail dot com 2010-07-08 11:39 --- Reopened... -- ubizjak at gmail dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44867
[Bug rtl-optimization/44867] 10% runtime regression on Polyhedron channel banchmark from 29. June 2010
--- Comment #5 from ubizjak at gmail dot com 2010-07-08 11:40 --- ... to mark as duplicate. *** This bug has been marked as a duplicate of 44773 *** -- ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44867
[Bug fortran/44773] [4.6 Regression] Unnecessary temporaries increase the runtime for channel.f90 by ~70%
--- Comment #9 from ubizjak at gmail dot com 2010-07-08 11:40 --- *** Bug 44867 has been marked as a duplicate of this bug. *** -- ubizjak at gmail dot com changed: What|Removed |Added CC||ubizjak at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44773
[Bug debug/44832] [4.6 Regression] -fcompare-debug failure for C++ i386.c
--- Comment #38 from rguenth at gcc dot gnu dot org 2010-07-08 11:45
---
Index: gcc/tree-vrp.c
===
--- gcc/tree-vrp.c (revision 161949)
+++ gcc/tree-vrp.c (working copy)
@@ -4534,12 +4538,11 @@ compare_case_labels (const void *p1, con
{
const_tree const case1 = *(const_tree const*)p1;
const_tree const case2 = *(const_tree const*)p2;
- unsigned int uid1 = DECL_UID (CASE_LABEL (case1));
- unsigned int uid2 = DECL_UID (CASE_LABEL (case2));
+ unsigned int uid1 = LABEL_DECL_UID (CASE_LABEL (case1));
+ unsigned int uid2 = LABEL_DECL_UID (CASE_LABEL (case2));
- if (uid1 uid2)
-return -1;
- else if (uid1 == uid2)
+ if (uid1 == uid2
+ || uid1 == -1u || uid2 == -1u)
{
/* Make sure the default label is first in a group. */
if (!CASE_LOW (case1))
@@ -4549,8 +4552,7 @@ compare_case_labels (const void *p1, con
else
return tree_int_cst_compare (CASE_LOW (case1), CASE_LOW (case2));
}
- else
-return 1;
+ return uid1 uid2 ? -1 : 1;
}
fixes the testcase.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44832
[Bug debug/44832] [4.6 Regression] -fcompare-debug failure for C++ i386.c
--- Comment #39 from rguenth at gcc dot gnu dot org 2010-07-08 11:49 --- So you say during inlining we end up generating DECL copies in a different _order_ comparing debug vs. non-debug cases? That would be a bug as well. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44832
[Bug debug/44832] [4.6 Regression] -fcompare-debug failure for C++ i386.c
--- Comment #40 from rguenth at gcc dot gnu dot org 2010-07-08 11:53 --- Indeed we do. -g vs. -g0 diff of non-debug decl copying: --- x 2010-07-08 13:51:02.0 +0200 +++ y 2010-07-08 13:51:09.0 +0200 @@ -476,12 +476,14 @@ mode target vals +half ops op0 op1 half_mode n i +code rt rt i @@ -496,27 +498,25 @@ elt tmp tmp -D.3581 -D.3582 -D.3583 +arg0 D.3584 D.3585 D.3586 D.3587 D.3588 -word_mode.14 +D.3589 D.3590 D.3591 -D.3592 +word_mode.14 D.3593 D.3594 D.3595 D.3596 D.3597 -inner_mode.13 +D.3598 D.3599 D.3600 -D.3601 +inner_mode.13 D.3602 D.3603 D.3604 @@ -527,8 +527,11 @@ D.3609 D.3610 D.3611 -ix86_isa_flags.12 +D.3612 D.3613 +D.3614 +ix86_isa_flags.12 +D.3616 mode.11 L36 L59 @@ -536,7 +539,6 @@ L23 L25 L4 -half L18 retval -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44832
[Bug tree-optimization/44284] vectorization does not work for short variable
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-07-08 11:56 --- Subject: Bug 44284 Author: rguenth Date: Thu Jul 8 11:56:08 2010 New Revision: 161951 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161951 Log: 2010-07-08 Richard Guenther rguent...@suse.de Backport from mainline 2010-05-27 Richard Guenther rguent...@suse.de PR tree-optimization/44284 * tree-vect-stmts.c (vectorizable_assignment): Handle sign-changing conversions as simple copy. * gcc.dg/vect/vect-118.c: New testcase. * gcc.dg/vect/bb-slp-20.c: Adjust. * gcc.dg/vect/no-section-anchors-vect-36.c: Likewise. * gcc.dg/vect/slp-9.c: Likewise. * gcc.dg/vect/slp-reduc-4.c: Likewise. * gcc.dg/vect/vect-10.c: Likewise. * gcc.dg/vect/vect-109.c: Likewise. * gcc.dg/vect/vect-12.c: Likewise. * gcc.dg/vect/vect-36.c: Likewise. * gcc.dg/vect/vect-7.c: Likewise. * gcc.dg/vect/vect-iv-8.c: Likewise. * gcc.dg/vect/vect-multitypes-10.c: Likewise. * gcc.dg/vect/vect-multitypes-13.c: Likewise. * gcc.dg/vect/vect-multitypes-14.c: Likewise. * gcc.dg/vect/vect-multitypes-15.c: Likewise. * gcc.dg/vect/vect-multitypes-7.c: Likewise. * gcc.dg/vect/vect-multitypes-8.c: Likewise. * gcc.dg/vect/vect-multitypes-9.c: Likewise. * gcc.dg/vect/vect-reduc-dot-s16b.c: Likewise. * gcc.dg/vect/vect-reduc-dot-s8a.c: Likewise. * gcc.dg/vect/vect-reduc-dot-s8b.c: Likewise. * gcc.dg/vect/vect-reduc-dot-u16b.c: Likewise. * gcc.dg/vect/vect-strided-a-u32-mult.c: Likewise. * gcc.dg/vect/vect-strided-u32-mult.c: Likewise. * gcc.dg/vect/vect-widen-mult-s16.c: Likewise. * gcc.dg/vect/vect-widen-mult-s8.c: Likewise. * gcc.dg/vect/vect-widen-mult-sum.c: Likewise. * gcc.dg/vect/vect-widen-mult-u16.c: Likewise. 2010-07-06 Richard Guenther rguent...@suse.de PR middle-end/44828 * convert.c (convert_to_integer): Watch out for overflowing MULT_EXPR as well. * gcc.c-torture/execute/pr44828.c: New testcase. Added: branches/gcc-4_5-branch/gcc/testsuite/gcc.c-torture/execute/pr44828.c branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/vect/vect-118.c Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/convert.c branches/gcc-4_5-branch/gcc/testsuite/ChangeLog branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/vect/bb-slp-20.c branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/vect/no-section-anchors-vect-36.c branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/vect/slp-9.c branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/vect/vect-10.c branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/vect/vect-109.c branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/vect/vect-12.c branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/vect/vect-36.c branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/vect/vect-7.c branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/vect/vect-iv-8.c branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/vect/vect-multitypes-10.c branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/vect/vect-multitypes-13.c branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/vect/vect-multitypes-14.c branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/vect/vect-multitypes-15.c branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/vect/vect-multitypes-7.c branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/vect/vect-multitypes-8.c branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/vect/vect-multitypes-9.c branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/vect/vect-reduc-dot-s16a.c branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/vect/vect-reduc-dot-s16b.c branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/vect/vect-reduc-dot-s8a.c branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/vect/vect-reduc-dot-s8b.c branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/vect/vect-reduc-dot-s8c.c branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/vect/vect-reduc-dot-u16b.c branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/vect/vect-strided-a-u32-mult.c branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/vect/vect-strided-u32-mult.c branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/vect/vect-widen-mult-s16.c branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/vect/vect-widen-mult-s8.c branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/vect/vect-widen-mult-sum.c branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/vect/vect-widen-mult-u16.c branches/gcc-4_5-branch/gcc/tree-vect-stmts.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44284
[Bug c/44828] [4.3/4.4/4.5 Regression] possible integer wrong code bug
--- Comment #11 from rguenth at gcc dot gnu dot org 2010-07-08 11:56 --- Subject: Bug 44828 Author: rguenth Date: Thu Jul 8 11:56:08 2010 New Revision: 161951 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161951 Log: 2010-07-08 Richard Guenther rguent...@suse.de Backport from mainline 2010-05-27 Richard Guenther rguent...@suse.de PR tree-optimization/44284 * tree-vect-stmts.c (vectorizable_assignment): Handle sign-changing conversions as simple copy. * gcc.dg/vect/vect-118.c: New testcase. * gcc.dg/vect/bb-slp-20.c: Adjust. * gcc.dg/vect/no-section-anchors-vect-36.c: Likewise. * gcc.dg/vect/slp-9.c: Likewise. * gcc.dg/vect/slp-reduc-4.c: Likewise. * gcc.dg/vect/vect-10.c: Likewise. * gcc.dg/vect/vect-109.c: Likewise. * gcc.dg/vect/vect-12.c: Likewise. * gcc.dg/vect/vect-36.c: Likewise. * gcc.dg/vect/vect-7.c: Likewise. * gcc.dg/vect/vect-iv-8.c: Likewise. * gcc.dg/vect/vect-multitypes-10.c: Likewise. * gcc.dg/vect/vect-multitypes-13.c: Likewise. * gcc.dg/vect/vect-multitypes-14.c: Likewise. * gcc.dg/vect/vect-multitypes-15.c: Likewise. * gcc.dg/vect/vect-multitypes-7.c: Likewise. * gcc.dg/vect/vect-multitypes-8.c: Likewise. * gcc.dg/vect/vect-multitypes-9.c: Likewise. * gcc.dg/vect/vect-reduc-dot-s16b.c: Likewise. * gcc.dg/vect/vect-reduc-dot-s8a.c: Likewise. * gcc.dg/vect/vect-reduc-dot-s8b.c: Likewise. * gcc.dg/vect/vect-reduc-dot-u16b.c: Likewise. * gcc.dg/vect/vect-strided-a-u32-mult.c: Likewise. * gcc.dg/vect/vect-strided-u32-mult.c: Likewise. * gcc.dg/vect/vect-widen-mult-s16.c: Likewise. * gcc.dg/vect/vect-widen-mult-s8.c: Likewise. * gcc.dg/vect/vect-widen-mult-sum.c: Likewise. * gcc.dg/vect/vect-widen-mult-u16.c: Likewise. 2010-07-06 Richard Guenther rguent...@suse.de PR middle-end/44828 * convert.c (convert_to_integer): Watch out for overflowing MULT_EXPR as well. * gcc.c-torture/execute/pr44828.c: New testcase. Added: branches/gcc-4_5-branch/gcc/testsuite/gcc.c-torture/execute/pr44828.c branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/vect/vect-118.c Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/convert.c branches/gcc-4_5-branch/gcc/testsuite/ChangeLog branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/vect/bb-slp-20.c branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/vect/no-section-anchors-vect-36.c branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/vect/slp-9.c branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/vect/vect-10.c branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/vect/vect-109.c branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/vect/vect-12.c branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/vect/vect-36.c branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/vect/vect-7.c branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/vect/vect-iv-8.c branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/vect/vect-multitypes-10.c branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/vect/vect-multitypes-13.c branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/vect/vect-multitypes-14.c branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/vect/vect-multitypes-15.c branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/vect/vect-multitypes-7.c branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/vect/vect-multitypes-8.c branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/vect/vect-multitypes-9.c branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/vect/vect-reduc-dot-s16a.c branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/vect/vect-reduc-dot-s16b.c branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/vect/vect-reduc-dot-s8a.c branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/vect/vect-reduc-dot-s8b.c branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/vect/vect-reduc-dot-s8c.c branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/vect/vect-reduc-dot-u16b.c branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/vect/vect-strided-a-u32-mult.c branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/vect/vect-strided-u32-mult.c branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/vect/vect-widen-mult-s16.c branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/vect/vect-widen-mult-s8.c branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/vect/vect-widen-mult-sum.c branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/vect/vect-widen-mult-u16.c branches/gcc-4_5-branch/gcc/tree-vect-stmts.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44828
[Bug c/44828] [4.3/4.4 Regression] possible integer wrong code bug
--- Comment #12 from rguenth at gcc dot gnu dot org 2010-07-08 11:57 --- Fixed for 4.5.1 as well. Backporting to older branches will regress vectorization if the fix for PR44284 isn't backported as well which IMHO isn't appropriate. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Known to work|4.2.4 4.6.0 |4.2.4 4.5.1 4.6.0 Summary|[4.3/4.4/4.5 Regression]|[4.3/4.4 Regression] |possible integer wrong code |possible integer wrong code |bug |bug http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44828
[Bug c++/44870] New: -pedantic causes error when calling function with rvalue argument inside template
Inside a template function, calling another function that takes an rvalue
reference as argument with a temporary value incorrectly results in an error
when the -pedantic flag is used.
Reduced test case:
void foo(int data);
template typename T
void bar(T t)
{ foo(int()); }
void baz()
{ bar(0); }
Compilation command:
g++-4.5 -std=c++0x -c b.cpp -pedantic
Output from compilation command:
b.cpp: In function void bar(T):
b.cpp:5:12: error: invalid initialization of reference of type int from
expression of type int
b.cpp:1:6: error: in passing argument 1 of void foo(int)
Output of g++-4.5 -v:
Using built-in specs.
COLLECT_GCC=g++-4.5
COLLECT_LTO_WRAPPER=/home/eeyts/root/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.5.0/configure --prefix=/home/eeyts/root
--disable-shared --enable-threads=posix --enable-__cxa_atexit --enable-libgomp
--disable-libunwind-exceptions --enable-languages=c,c++
--with-gmp=/home/eeyts/root --with-mpfr=/home/eeyts/root
--with-mpc=/home/eeyts/root --with-host-libstdcxx=/usr/lib64/libstdc++.so.6
--with-ppl=/home/eeyts/root --with-cloog=/home/eeyts/root
--with-libelf=/home/eeyts/root --program-suffix=-4.5
Thread model: posix
gcc version 4.5.0 (GCC)
--
Summary: -pedantic causes error when calling function with rvalue
argument inside template
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tspiteri at ieee dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44870
[Bug debug/44832] [4.6 Regression] -fcompare-debug failure for C++ i386.c
--- Comment #41 from amylaar at gcc dot gnu dot org 2010-07-08 12:01 --- (In reply to comment #39) So you say during inlining we end up generating DECL copies in a different _order_ comparing debug vs. non-debug cases? That would be a bug as well. Indeed we do; once that is fixed, the vrp ordering should be fixed as well. (In reply to comment #37) This is what we have the -nouid modifier for. But this doesn't allow us to use diff to tell if the relative order is OK in one dump while messed up in the other. It hides all the ordering problems, so this option is no good at all to track down the pass where things go wrong. I wonder if it would be feasible to allocate new negative the uids for such Should have read: I wonder if it would be feasible to allocate new negative uids for such symbols when they only remain for purposes of debugging, and when we somehow end up merging a debug and non-debug copy, the non-debug with its positive decl_uid should prevail. ? You have lost me here again. That's a tentative idea how not only the ordering problem could be solved, but also the debug/no-debug variance of decl_uids on declarations / labels that are present in the no-debug output, to allow for meaningful diffs. I haven't tried to implement this yet, though. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44832
[Bug debug/44832] [4.6 Regression] -fcompare-debug failure for C++ i386.c
--- Comment #42 from amylaar at gcc dot gnu dot org 2010-07-08 12:08 --- (In reply to comment #40) Indeed we do. -g vs. -g0 diff of non-debug decl copying: How did you get this dump? Enumerating DECLs like this in (-nouid) dump files seems to be an alternative way to solve the dump diff problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44832
[Bug middle-end/44843] [4.6 regression] All 32-bit fortran execution tests SEGV on SPARC: unaligned access
--- Comment #6 from mikpe at it dot uu dot se 2010-07-08 12:18 ---
With this short test case:
struct s {
double for_alignment;
struct { int x, y, z; } a[16];
};
void f(struct s *s)
{
unsigned int i;
for (i = 0; i 16; ++i) {
s-a[i].x = 0;
s-a[i].y = 0;
s-a[i].z = 0;
}
}
revision 161840 changes the generated code as follows:
--- pr44843.s-r161839 2010-07-08 14:00:06.0 +0200
+++ pr44843.s-r161840 2010-07-08 14:00:26.0 +0200
@@ -6,10 +6,9 @@
.proc 020
f:
mov 16, %g1
.LL2:
- st %g0, [%o0+8]
- st %g0, [%o0+12]
+ stx %g0, [%o0+8]
st %g0, [%o0+16]
addcc %g1, -1, %g1
bne,pt %icc, .LL2
add%o0, 12, %o0
which will fail at runtime due to misalignment in the 2nd loop iteration.
Removing the double which is there to align the struct and the start of the
array eliminates the bug.
--
mikpe at it dot uu dot se changed:
What|Removed |Added
CC||mikpe at it dot uu dot se
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44843
[Bug fortran/44773] [4.6 Regression] Unnecessary temporaries increase the runtime for channel.f90 by ~70%
--- Comment #10 from pault at gcc dot gnu dot org 2010-07-08 12:29 --- Created an attachment (id=21142) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21142action=view) A first step to fix this bug This does the right thing but has not been regtested because my tree is so broken that even hello world does not run. However, I am confident that it can be persuaded to regtest and will do so tonight. Cheers Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44773
[Bug debug/44832] [4.6 Regression] -fcompare-debug failure for C++ i386.c
--- Comment #43 from rguenth at gcc dot gnu dot org 2010-07-08 12:33
---
I placed a debug_generic_expr () in copy_node_stat and re-directed output ...
Now, I see that in the non-debug case we are copying the LABEL_DECL while
copying statements while in the debug case we are copying it while
copying the block tree. We have to preserve used labels in
the block tree it's just not trivial to do unless we resort to setting
TREE_USED.
Which would be the following, which also fixes the failure.
Index: tree-ssa-live.c
===
--- tree-ssa-live.c (revision 161949)
+++ tree-ssa-live.c (working copy)
@@ -384,6 +384,9 @@ mark_all_vars_used_1 (tree *tp, int *wal
set_is_used (t);
}
+ if (TREE_CODE (t) == LABEL_DECL)
+TREE_USED (t) = true;
+
if (IS_TYPE_OR_DECL_P (t))
*walk_subtrees = 0;
@@ -448,6 +451,13 @@ remove_unused_scope_block_p (tree scope)
else if (TREE_CODE (*t) == VAR_DECL DECL_HAS_VALUE_EXPR_P (*t))
unused = false;
+ /* Labels that are still used in the IL we have to preserve in
+ the block tree as well, otherwise we risk having different
+ordering in debug vs. non-debug builds during inlining
+or versioning. */
+ else if (TREE_CODE (*t) == LABEL_DECL TREE_USED (*t))
+ unused = false;
+
/* Remove everything we don't generate debug info for. */
else if (DECL_IGNORED_P (*t))
{
we don't have var annotations for LABEL_DECLs, so a proper solution
would use a bitmap of UIDs to preserve here I guess.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44832
[Bug middle-end/44843] [4.6 regression] All 32-bit fortran execution tests SEGV on SPARC: unaligned access
--- Comment #7 from rguenth at gcc dot gnu dot org 2010-07-08 12:41 ---
(In reply to comment #6)
With this short test case:
struct s {
double for_alignment;
struct { int x, y, z; } a[16];
};
void f(struct s *s)
{
unsigned int i;
for (i = 0; i 16; ++i) {
s-a[i].x = 0;
s-a[i].y = 0;
s-a[i].z = 0;
}
}
revision 161840 changes the generated code as follows:
--- pr44843.s-r161839 2010-07-08 14:00:06.0 +0200
+++ pr44843.s-r161840 2010-07-08 14:00:26.0 +0200
@@ -6,10 +6,9 @@
.proc 020
f:
mov 16, %g1
.LL2:
- st %g0, [%o0+8]
- st %g0, [%o0+12]
+ stx %g0, [%o0+8]
st %g0, [%o0+16]
addcc %g1, -1, %g1
bne,pt %icc, .LL2
add%o0, 12, %o0
which will fail at runtime due to misalignment in the 2nd loop iteration.
Removing the double which is there to align the struct and the start of the
array eliminates the bug.
We end up with
MEM[(struct s *)D.2742_15 + 8B] = 0;
MEM[(struct s *)D.2742_15 + 12B] = 0;
MEM[(struct s *)D.2742_15 + 16B] = 0;
from which set_mem_attributes_minus_bitpos incorrectly concludes that
D.2742_15 points to sth that is aligned the same as struct s here:
else
/* This technically isn't correct. We can't really derive
alignment information from types. */
align = MAX (align,
TYPE_ALIGN (TREE_TYPE (TREE_TYPE (TREE_OPERAND (t, 1);
and the comment is correct.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44843
[Bug middle-end/44843] [4.6 regression] All 32-bit fortran execution tests SEGV on SPARC: unaligned access
--- Comment #8 from rguenth at gcc dot gnu dot org 2010-07-08 12:47 --- (In reply to comment #7) We end up with MEM[(struct s *)D.2742_15 + 8B] = 0; MEM[(struct s *)D.2742_15 + 12B] = 0; MEM[(struct s *)D.2742_15 + 16B] = 0; from which set_mem_attributes_minus_bitpos incorrectly concludes that D.2742_15 points to sth that is aligned the same as struct s here: else /* This technically isn't correct. We can't really derive alignment information from types. */ align = MAX (align, TYPE_ALIGN (TREE_TYPE (TREE_TYPE (TREE_OPERAND (t, 1); and the comment is correct. Where the alternative would have been else /* This technically isn't correct. We can't really derive alignment information from types. */ align = MAX (align, TYPE_ALIGN (TREE_TYPE (t))); and the comment would still be correct as a MEM_REF has an embedded VIEW_CONVERT_EXPR. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44843
[Bug middle-end/44843] [4.6 regression] All 32-bit fortran execution tests SEGV on SPARC: unaligned access
--- Comment #9 from rguenth at gcc dot gnu dot org 2010-07-08 12:50 --- Still the alternative is probably correct more often. So if that fixes the issue for you we can go with that until I manage to finish the alignment tracking. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44843
[Bug c++/44870] [C++0x] -pedantic causes error when calling function with rvalue argument inside template
--- Comment #1 from paolo dot carlini at oracle dot com 2010-07-08 12:51 --- Confirmed with current mainline. -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||jason at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-07-08 12:51:42 date|| Summary|-pedantic causes error when |[C++0x] -pedantic causes |calling function with rvalue|error when calling function |argument inside template|with rvalue argument inside ||template http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44870
[Bug tree-optimization/44284] vectorization does not work for short variable
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.6.0 |4.5.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44284
[Bug middle-end/44871] New: Invalid type mismatches while merging C and C++ sources
j...@evans:/abuild/jh/mozilla-central/build6/gfx/harfbuzz/src /abuild/jh/trunk-install/bin/gcc -O2 -fwhopr -r -nostdlib hb-blob.i -c j...@evans:/abuild/jh/mozilla-central/build6/gfx/harfbuzz/src /abuild/jh/trunk-install/bin/g++ -O2 -fwhopr -r -nostdlib *.ii -c j...@evans:/abuild/jh/mozilla-central/build6/gfx/harfbuzz/src /abuild/jh/trunk-install/bin/g++ hb-blob.o -O2 -fwhopr -r -nostdlib hb-font.o ../../../../gfx/harfbuzz/src/hb-blob-private.h:53:60: warning: type of _hb_blob_nil does not match original declaration [enabled by default] ../../../../gfx/harfbuzz/src/hb-blob.c:45:11: note: previously declared here -- Summary: Invalid type mismatches while merging C and C++ sources Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hubicka at gcc dot gnu dot org GCC host triplet: x86_64-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44871
[Bug middle-end/44843] [4.6 regression] All 32-bit fortran execution tests SEGV on SPARC: unaligned access
--- Comment #10 from ebotcazou at gcc dot gnu dot org 2010-07-08 13:29 --- Still the alternative is probably correct more often. So if that fixes the issue for you we can go with that until I manage to finish the alignment tracking. Yes, that cannot be worse than the current one. Note that IVOPTS won't generate misaligned accesses out of aligned ones so using the MEM type is correct here. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44843
[Bug middle-end/44871] Invalid type mismatches while merging C and C++ sources
--- Comment #1 from hubicka at gcc dot gnu dot org 2010-07-08 13:31 --- Created an attachment (id=21143) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21143action=view) first part of testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44871
[Bug fortran/44773] [4.6 Regression] Unnecessary temporaries increase the runtime for channel.f90 by ~70%
--- Comment #11 from burnus at gcc dot gnu dot org 2010-07-08 13:33 --- + /* A temporary is not needed if the lhs has never been host +associated and the procedure is contained. */ + if (!sym-attr.host_assoc_in_contained +expr2-value.function.esym-attr.contained) + return false; + /* A temporary is not needed if the variable is local and not a pointer, a target or a result. */ if (sym-ns-parent I have not read the patch in context, but I fear that you might miss a TARGET/POINTER check. Otherwise, I like your patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44773
[Bug middle-end/44871] Invalid type mismatches while merging C and C++ sources
--- Comment #2 from hubicka at gcc dot gnu dot org 2010-07-08 13:37 --- Created an attachment (id=21144) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21144action=view) second part of testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44871
[Bug rtl-optimization/44838] [4.6 regression] RTL loop unrolling causes FAIL: gcc.dg/pr39794.c
--- Comment #33 from hjl at gcc dot gnu dot org 2010-07-08 13:40 --- Subject: Bug 44838 Author: hjl Date: Thu Jul 8 13:40:24 2010 New Revision: 161953 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161953 Log: Add gcc.dg/pr44838.c. 2010-07-08 H.J. Lu hongjiu...@intel.com PR rtl-optimization/44838 * gcc.dg/pr44838.c: New. Added: trunk/gcc/testsuite/gcc.dg/pr44838.c Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44838
[Bug libstdc++/44872] New: [C++0x] Cannot use move constructible class as value for std::map
The std::map class is missing methods for inserting by rvalue reference. As a
consequence, move constructible classes (with copying disabled) cannot be used
as values. This seems like an oversight since std::vector has this
functionality.
The missing methods are:
T operator[](key_type x);
template class... Args pairiterator, bool emplace(Args... args);
template class... Args iterator emplace_hint(const_iterator position,
Args... args);
template class P pairiterator, bool insert(P x);
template class P iterator insert(const_iterator position, P);
These methods appear to be missing in the trunk as well, so this affects later
versions as well.
Similar functionality is missing in std::set, std::multimap, and std::multiset.
testcase:
// Test case for allowing move constructible/assignable classes as values in
// std::map.
#include map
// A move constructible/assignable class.
struct M {
// Default and move constructible.
M() {}
M(M) {}
// Move assignable.
M operator=(M) { return *this; }
// Disable copying.
M(const M) = delete;
M operator=(const M) = delete;
};
int main() {
std::mapint, M m;
m.insert(std::mapint, M::value_type(10, M()));
m.insert(m.begin(), std::mapint, M::value_type(20, M()));
m[30] = M();
return 0;
}
Command line and output:
$ g++ -v -o move_test -std=c++0x -save-temps move_map.cc
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.4.3-4ubuntu5'
--with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--enable-multiarch --enable-linker-build-id --with-system-zlib
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.4 --program-suffix=-4.4 --enable-nls
--enable-clocale=gnu --enable-libstdcxx-debug --enable-plugin --enable-objc-gc
--disable-werror --with-arch-32=i486 --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5)
COLLECT_GCC_OPTIONS='-v' '-o' 'move_test' '-std=c++0x' '-save-temps'
'-shared-libgcc' '-mtune=generic'
/usr/lib/gcc/x86_64-linux-gnu/4.4.3/cc1plus -E -quiet -v -D_GNU_SOURCE
move_map.cc -D_FORTIFY_SOURCE=2 -mtune=generic -std=c++0x -fpch-preprocess
-fstack-protector -o move_map.ii
ignoring nonexistent directory /usr/local/include/x86_64-linux-gnu
ignoring nonexistent directory
/usr/lib/gcc/x86_64-linux-gnu/4.4.3/../../../../x86_64-linux-gnu/include
ignoring nonexistent directory /usr/include/x86_64-linux-gnu
#include ... search starts here:
#include ... search starts here:
/usr/include/c++/4.4
/usr/include/c++/4.4/x86_64-linux-gnu
/usr/include/c++/4.4/backward
/usr/local/include
/usr/lib/gcc/x86_64-linux-gnu/4.4.3/include
/usr/lib/gcc/x86_64-linux-gnu/4.4.3/include-fixed
/usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-o' 'move_test' '-std=c++0x' '-save-temps'
'-shared-libgcc' '-mtune=generic'
/usr/lib/gcc/x86_64-linux-gnu/4.4.3/cc1plus -fpreprocessed move_map.ii -quiet
-dumpbase move_map.cc -mtune=generic -auxbase move_map -std=c++0x -version
-fstack-protector -o move_map.s
GNU C++ (Ubuntu 4.4.3-4ubuntu5) version 4.4.3 (x86_64-linux-gnu)
compiled by GNU C version 4.4.3, GMP version 4.3.2, MPFR version
2.4.2-p1.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++ (Ubuntu 4.4.3-4ubuntu5) version 4.4.3 (x86_64-linux-gnu)
compiled by GNU C version 4.4.3, GMP version 4.3.2, MPFR version
2.4.2-p1.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 88858f45841827736473e527a4e9ab10
In file included from /usr/include/c++/4.4/bits/stl_algobase.h:67,
from /usr/include/c++/4.4/bits/stl_tree.h:63,
from /usr/include/c++/4.4/map:61,
from move_map.cc:4:
move_map.cc: In copy constructor std::pairconst int, M::pair(const
std::pairconst int, M):
/usr/include/c++/4.4/bits/stl_pair.h:68: instantiated from
std::_Rb_tree_node_Val::_Rb_tree_node(_Args ...) [with _Args = const
std::pairconst int, M, _Val = std::pairconst int, M]
/usr/include/c++/4.4/ext/new_allocator.h:111: instantiated from void
__gnu_cxx::new_allocator_Tp::construct(_Tp*, _Args ...) [with _Args = const
std::pairconst int, M, _Tp = std::_Rb_tree_nodestd::pairconst int, M ]
/usr/include/c++/4.4/bits/stl_tree.h:394: instantiated from
std::_Rb_tree_node_Val* std::_Rb_tree_Key, _Val, _KeyOfValue, _Compare,
_Alloc::_M_create_node(_Args ...) [with _Args = const std::pairconst int,
M, _Key = int, _Val = std::pairconst int, M, _KeyOfValue =
[Bug c++/43120] Virtual inheritance with covariant return type confuses GCC
--- Comment #9 from jason at gcc dot gnu dot org 2010-07-08 14:00 --- Subject: Bug 43120 Author: jason Date: Thu Jul 8 14:00:26 2010 New Revision: 161954 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161954 Log: PR c++/43120 * class.c (update_vtable_entry_for_fn): Fix handling of dummy virtual bases for covariant thunks. Added: trunk/gcc/testsuite/g++.dg/inherit/covariant17.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/class.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/abi/covariant1.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43120
[Bug c++/44703] [C++0x] List initialization fail if parameter is typedef name for the std::initializer_list
--- Comment #2 from jason at gcc dot gnu dot org 2010-07-08 14:09 --- Subject: Bug 44703 Author: jason Date: Thu Jul 8 14:08:36 2010 New Revision: 161955 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161955 Log: PR c++/44703 * call.c (is_std_init_list): Look through typedefs. Added: branches/gcc-4_5-branch/gcc/testsuite/g++.dg/cpp0x/initlist41.C Modified: branches/gcc-4_5-branch/gcc/cp/ChangeLog branches/gcc-4_5-branch/gcc/cp/call.c branches/gcc-4_5-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44703
[Bug middle-end/44843] [4.6 regression] All 32-bit fortran execution tests SEGV on SPARC: unaligned access
--- Comment #11 from mikpe at it dot uu dot se 2010-07-08 14:12 --- (In reply to comment #9) Still the alternative is probably correct more often. So if that fixes the issue for you we can go with that until I manage to finish the alignment tracking. The alternative does fix this test case. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44843
[Bug c/44828] [4.3/4.4 Regression] possible integer wrong code bug
--- Comment #13 from bergner at gcc dot gnu dot org 2010-07-08 14:18 --- Subject: Bug 44828 Author: bergner Date: Thu Jul 8 14:17:52 2010 New Revision: 161956 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161956 Log: PR middle-end/44828 * gcc.c-torture/execute/pr44828.c (foo): Use signed char. * gcc.c-torture/execute/pr44828.x: Revert. Removed: trunk/gcc/testsuite/gcc.c-torture/execute/pr44828.x Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.c-torture/execute/pr44828.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44828
[Bug middle-end/44871] Invalid type mismatches while merging C and C++ sources
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-07-08 14:19 --- Created an attachment (id=21145) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21145action=view) reduced testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44871
[Bug middle-end/44871] Invalid type mismatches while merging C and C++ sources
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-07-08 14:19 --- Created an attachment (id=21146) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21146action=view) reduced testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44871
[Bug libstdc++/44436] [C++0x] Implement insert() and emplace* in associative and unordered containers
--- Comment #4 from redi at gcc dot gnu dot org 2010-07-08 14:20 --- *** Bug 44872 has been marked as a duplicate of this bug. *** -- redi at gcc dot gnu dot org changed: What|Removed |Added CC||hyounes at google dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44436
[Bug libstdc++/44872] [C++0x] Cannot use move constructible class as value for std::map
--- Comment #1 from redi at gcc dot gnu dot org 2010-07-08 14:20 --- *** This bug has been marked as a duplicate of 44436 *** -- redi at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44872
[Bug libstdc++/44436] [C++0x] Implement insert() and emplace* in associative and unordered containers
--- Comment #5 from paolo dot carlini at oracle dot com 2010-07-08 14:28 --- Just to clarify a bit: this wasn't an *oversight*. We had the *nasty* problem in the Draft C++0x Standard with std::pair, which essentially made impossible adding the emplace_* members to std::map, std::multimap, etc, without breaking existing user code. Thus we waited on that, until things got clarified in this whole area. Now it's actually possible to work on those facilities. Anyway, much more generally: we are *not* claiming any sort of conformance to non existing (yet) standards, we are still in experimental mode for C++0x. Please be patient. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44436
[Bug rtl-optimization/44858] [4.5/4.6 Regression] likely integer wrong code bug
--- Comment #4 from jakub at gcc dot gnu dot org 2010-07-08 14:44 --- Created an attachment (id=21147) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21147action=view) gcc46-vrp.patch So, combiner seems to be the first to notice that c must be actually zero (2 (x y)). This patch just tries to notice it earlier, during VRP, which of course isn't a fix for this bug (which is somewhere in the combiner where it doesn't notice that when it moves the and insn it clobbers cc which is needed), just makes it latent for -O2 (still present at -O1 or -O2 -fno-tree-vrp). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44858
[Bug middle-end/44871] Invalid type mismatches while merging C and C++ sources
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-07-08 14:47 ---
The C frontend for
typedef struct { hb_atomic_int_t ref_count; } hb_reference_count_t;
has an unnamed (NULL TYPE_NAME) main variant of hb_reference_count_t while
the C++ frontend does not have a main variant different from the type
with the typedef name. That causes us to hash both types differently
(once with tag NULL and once with tag hb_reference_count_t).
Now, our current behavior is to allow C-only merging of 'struct Foo *x'
vs 'Foo_t *x' or 'stuct Foo x' vs. 'Foo_t x' in a structure. We honor
a missing name as ok for merging but still hash in stuff (mostly to avoid
excessive collisions for pointer types).
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2010-07-08 14:47:48
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44871
[Bug testsuite/44797] INQUIRE EXIST variable must be default LOGICAL
--- Comment #5 from zeccav at gmail dot com 2010-07-08 14:49 --- Subject: Re: INQUIRE EXIST variable must be default LOGICAL By the way, the NUMBER variable must be default INTEGER as well. Do you agree there is the same problem as with the EXIST variable? Vittorio -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44797
[Bug testsuite/44873] New: array function not fully defined
In test case retarray.f90 at line 10 the array TEST is not fully defined. I propose to put TEST=0 at line 31 and FOO=0 at line 39. Best regards Vittorio Zecca -- Summary: array function not fully defined Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: zeccav at gmail dot com GCC host triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44873
[Bug middle-end/44824] [4.6 regression] internal compiler error: verify_stmts failed
--- Comment #10 from jojelino at gmail dot com 2010-07-08 15:15 --- (In reply to comment #2) I can't reproduce it with r161865. (on x86_64-linux with -m32) please confirm that this error introduces from -O1? surely, it would not be reproducible just giving -m32 as you says. failed in gcc with target i686-pc-mingw32 again... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44824
[Bug fortran/18918] Eventually support Fortran 2008's coarrays [co-arrays]
--- Comment #27 from burnus at gcc dot gnu dot org 2010-07-08 15:17 --- Subject: Bug 18918 Author: burnus Date: Thu Jul 8 15:17:25 2010 New Revision: 161960 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161960 Log: 2010-07-08 Tobias Burnus bur...@net-b.de PR fortran/18918 * array.c (gfc_match_array_ref): Better error message for coarrays with too few ranks. (match_subscript): Move one diagnostic to caller. * gfortran.h (gfc_get_corank): Add prottype. * expr.c (gfc_get_corank): New function. * iresolve.c (resolve_bound): Fix rank for cobounds. (gfc_resolve_lbound,gfc_resolve_lcobound, gfc_resolve_ubound, gfc_resolve_ucobound, gfc_resolve_this_image): Update resolve_bound call. 2010-07-08 Tobias Burnus bur...@net-b.de PR fortran/18918 * gfortran.dg/coarray_10.f90: Add an additional test. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/array.c trunk/gcc/fortran/expr.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/iresolve.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/coarray_10.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18918
[Bug fortran/44773] [4.6 Regression] Unnecessary temporaries increase the runtime for channel.f90 by ~70%
--- Comment #12 from paul dot richard dot thomas at gmail dot com 2010-07-08 15:32 --- Subject: Re: [4.6 Regression] Unnecessary temporaries increase the runtime for channel.f90 by ~70% Tobias, That is the context - apply it and see. Paul On Thu, Jul 8, 2010 at 3:33 PM, burnus at gcc dot gnu dot org gcc-bugzi...@gcc.gnu.org wrote: --- Comment #11 from burnus at gcc dot gnu dot org 2010-07-08 13:33 --- + /* A temporary is not needed if the lhs has never been host + associated and the procedure is contained. */ + if (!sym-attr.host_assoc_in_contained + expr2-value.function.esym-attr.contained) + return false; + /* A temporary is not needed if the variable is local and not a pointer, a target or a result. */ if (sym-ns-parent I have not read the patch in context, but I fear that you might miss a TARGET/POINTER check. Otherwise, I like your patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44773 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44773
[Bug lto/44871] Invalid type mismatches while merging C and C++ sources
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-07-08 15:32 ---
Testcase to illustrate C / C++ differences:
typedef struct { } T1;
typedef T1 T2;
void foo (T1 a, T2 b)
{
}
TYPE_MAIN_VARIANT of the type of a is T1 for C++, struct {} for C.
TYPE_MAIN_VARIANT of the type of b is T1 for C++, struct {} for C.
typedef struct X { } T1;
typedef T1 T2;
void foo (T1 a, T2 b)
{
}
TYPE_MAIN_VARIANT of the type of a is struct X {} for C++, struct X {} for C.
TYPE_MAIN_VARIANT of the type of b is struct X {} for C++, struct X {} for C.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44871
[Bug other/44874] New: TDF_NOUID dumps miss information about DECL_UID ordering
When comparing dumps from compilations with debugging information generation enabled and disabled, like for -fcompare-debug, commonly dump files generated with TDF_NOUID are used. However, as has become painfully clear while debugging PR44832, such dumps do not help to spot the point where the DECL_UID ordering of declarations / labels varies. There should be a flag to request an enumeration of all declarations / labels of each function to be dumped in the order of their DECL_UID as part of the debugging dump for the function. Also, a dump of FREE_SSANAMES can be useful at times. -- Summary: TDF_NOUID dumps miss information about DECL_UID ordering Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: amylaar at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44874
[Bug libstdc++/44875] New: libstdc++ status documentation fails to mention missing c++0x io members
In http://gcc.gnu.org/onlinedocs/libstdc++/manual/status.html#status.iso.200x, the documentation states that 27 Input/output library is implemented, except for 27.2.3 Thread safety, which is partially implemented. But there are missing move constructors, move assignment operators, move() member functions, and swap() member functions in sections 27.5 to 27.9, so I think that they should be listed as Partial until the functions are implemented. -- Summary: libstdc++ status documentation fails to mention missing c++0x io members Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tspiteri at ieee dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44875
[Bug debug/44832] [4.6 Regression] -fcompare-debug failure for C++ i386.c
--- Comment #44 from amylaar at gcc dot gnu dot org 2010-07-08 15:54 --- (In reply to comment #43) Now, I see that in the non-debug case we are copying the LABEL_DECL while copying statements while in the debug case we are copying it while copying the block tree. We have to preserve used labels in the block tree it's just not trivial to do unless we resort to setting TREE_USED. Which would be the following, which also fixes the failure. I have done a --enable-build-with-cxx bootstrap of trunk trevision 161952 with this patch applied (with tabs for leading whitespace in the comment). The bootstrap finished successfully, and the regression test results look reasonable, although I still have to generate baseline results to compare this to. I have submitted PR other/44874 to track the shortcomings of our debugging dumps for finding DECL_UID ordering issues. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44832
[Bug debug/44832] [4.6 Regression] -fcompare-debug failure for C++ i386.c
--- Comment #45 from rguenther at suse dot de 2010-07-08 16:05 --- Subject: Re: [4.6 Regression] -fcompare-debug failure for C++ i386.c On Thu, 8 Jul 2010, amylaar at gcc dot gnu dot org wrote: --- Comment #44 from amylaar at gcc dot gnu dot org 2010-07-08 15:54 --- (In reply to comment #43) Now, I see that in the non-debug case we are copying the LABEL_DECL while copying statements while in the debug case we are copying it while copying the block tree. We have to preserve used labels in the block tree it's just not trivial to do unless we resort to setting TREE_USED. Which would be the following, which also fixes the failure. I have done a --enable-build-with-cxx bootstrap of trunk trevision 161952 with this patch applied (with tabs for leading whitespace in the comment). The bootstrap finished successfully, and the regression test results look reasonable, although I still have to generate baseline results to compare this to. Using TREE_USED isn't really applicable here (we do never re-set it at least). So an option would be to unconditionally preserve all !DECL_INGNORED_P labels in BLOCKs. Or play fancy with a bitmap or a pointer-map. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44832
[Bug libstdc++/44875] libstdc++ status documentation fails to mention missing c++0x io members
-- redi at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |redi at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Keywords||documentation Last reconfirmed|-00-00 00:00:00 |2010-07-08 16:06:41 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44875
[Bug bootstrap/44455] GCC fails to build if MPFR 3.0.0 (Release Candidate) is used
--- Comment #5 from bonzini at gnu dot org 2010-07-08 16:24 --- The patch is okay, but it should be tested with bootstrap, `make install' and a smoke test after install with: - in-tree GMP, in-tree MPFR 2.3 - in-tree GMP, in-tree MPFR 3.0 - out-of-tree GMP, in-tree MPFR 2.3 - out-of-tree GMP, in-tree MPFR 3.0 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44455
[Bug middle-end/44852] [4.6 Regression]: miscompilation (of e.g. newlib dtoa.c) after mem-ref2 merge
--- Comment #4 from hp at gcc dot gnu dot org 2010-07-08 16:27 --- Removing target specifier as the test-case fails for native x86_64-linux as well, with e.g. r161957, so there's reason to believe the miscompilation is generic. Just mentioned in case there's a target-based priority involved. -- hp at gcc dot gnu dot org changed: What|Removed |Added GCC target triplet|cris-elf| Summary|[4.6 Regression]: |[4.6 Regression]: |miscompilation of newlib|miscompilation (of e.g. |dtoa.c after mem-ref2 merge |newlib dtoa.c) after mem- ||ref2 merge http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44852
[Bug tree-optimization/44710] [4.6 Regression] If-conversion generates redundant statements
--- Comment #3 from spop at gcc dot gnu dot org 2010-07-08 16:38 --- Subject: Bug 44710 Author: spop Date: Thu Jul 8 16:38:00 2010 New Revision: 161964 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161964 Log: Call maybe_fold_or_comparisons to fold OR-ed predicates. 2010-07-08 Sebastian Pop sebastian@amd.com PR tree-optimization/44710 * tree-if-conv.c (parse_predicate): New. (add_to_predicate_list): Call it, call maybe_fold_or_comparisons. Make sure that the predicates are either SSA_NAMEs or gimple_condexpr. * gcc.dg/tree-ssa/ifc-6.c: New. * gcc.dg/tree-ssa/ifc-pr44710.c: New. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/ifc-6.c trunk/gcc/testsuite/gcc.dg/tree-ssa/ifc-pr44710.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-if-conv.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44710
[Bug tree-optimization/44710] [4.6 Regression] If-conversion generates redundant statements
--- Comment #4 from spop at gcc dot gnu dot org 2010-07-08 16:40 --- Fixed. -- spop at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44710
[Bug fortran/44857] [4.6 Regression] ICE in output_constructor_regular_field, at varasm.c:4996
--- Comment #3 from dfranke at gcc dot gnu dot org 2010-07-08 16:47 --- Reduced testcase: Type :: t character (len=32) :: txt(2) End Type Type (t) :: tt = t(/ , /)) print *, tt End Notes: * the vatiable 'tt' must be used, if not used only a warning is printed, no ICE * doing the same with INTEGER instead of CHARACTER works * explicitly assigning the txt component instead of using the structure constructor works -- dfranke at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-07-08 16:47:36 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44857
[Bug c++/44815] Compiz Core miscompiles with GCC 4.5
--- Comment #5 from jason at gcc dot gnu dot org 2010-07-08 17:05 --- I suspect this is a duplicate of PR c++/44059. -- jason at gcc dot gnu dot org changed: What|Removed |Added CC||jakub at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44815
[Bug c++/44059] Static initializers executed more than once when using unique global symbols
--- Comment #11 from jakub at gcc dot gnu dot org 2010-07-08 17:08 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.5.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44059
[Bug debug/44832] [4.6 Regression] -fcompare-debug failure for C++ i386.c
--- Comment #46 from amylaar at gcc dot gnu dot org 2010-07-08 17:21 --- (In reply to comment #45) Using TREE_USED isn't really applicable here (we do never re-set it at least). So an option would be to unconditionally preserve all !DECL_INGNORED_P labels in BLOCKs. Which is what my provisional patch was doing, although it'd need better commenting and deletion of dead tests / code. Or play fancy with a bitmap or a pointer-map. Could we use a different bit that is currently unused for LABEL_DECLs? (With a suitable accessor macro, of course.) The name of base.public_flag sounds about right, but might be a bit dangerous considering the unguarded TREE_PUBLIC accessor and possible mix-ups when code is meant to test TREE_PUBLIC of declarations. OTOH it seems that we could safely snarf base.nothrow_flag for LABEL_DECLs. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44832
[Bug fortran/44847] ICE: OpenMP with Collapse clause and CYCLE stmt in loop
--- Comment #3 from jakub at gcc dot gnu dot org 2010-07-08 17:31 --- Subject: Bug 44847 Author: jakub Date: Thu Jul 8 17:30:41 2010 New Revision: 161967 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161967 Log: PR fortran/44847 * match.c (match_exit_cycle): Error on EXIT also from collapsed !$omp do loops. Error on CYCLE to non-innermost collapsed !$omp do loops. * gfortran.dg/gomp/pr44847.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/gomp/pr44847.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/match.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44847
[Bug fortran/44847] ICE: OpenMP with Collapse clause and CYCLE stmt in loop
--- Comment #4 from jakub at gcc dot gnu dot org 2010-07-08 17:33 --- Subject: Bug 44847 Author: jakub Date: Thu Jul 8 17:33:01 2010 New Revision: 161968 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161968 Log: PR fortran/44847 * match.c (match_exit_cycle): Error on EXIT also from collapsed !$omp do loops. Error on CYCLE to non-innermost collapsed !$omp do loops. * gfortran.dg/gomp/pr44847.f90: New test. Added: branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/gomp/pr44847.f90 Modified: branches/gcc-4_5-branch/gcc/fortran/ChangeLog branches/gcc-4_5-branch/gcc/fortran/match.c branches/gcc-4_5-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44847
