[Bug c++/54348] confusing error reported for type mismatch in conditional expression : "error: no match for ternary 'operator?:' in 'false ?"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54348
--- Comment #9 from Jonathan Wakely 2012-08-22
07:37:18 UTC ---
(In reply to comment #5)
> strct s struct_strct( items, myItems, name, myName ) ;
> }
>
>
> This works!
Only because NULL can be converted to std::string - but it would crash at
runtime if that branch was taken.
(In reply to comment #7)
> > void f()
> > {
> > false ? a : b;
> > }
>
> but this is not the same. surely ? the above is not a valid statement -
It's exactly the same. It's not valid because the types are incompatible, just
like your example. e.g. this is fine:
false ? a : a;
> I was saying:
>
> some_type some_object = false ? a : b;
As I said previously, the fact the conditional expression is used as an
initializer is irrelevant to the error.
(In reply to comment #8)
> All I'm suggesting is that g++ should try to find the most basic error,
Exactly. And the error is in the conditional expression, it has nothing to do
with the object being initialized.
> which is that different type objects are returned as the result of a
> conditional expression, and not "no match for ternary 'operator?:'" -
> what does this mean, it was searching namespace std:: for string::operator::?:
> ?
> then this succeeded, and it found it could not apply it because the types
> were different - shouldn't it complain about the root cause, that the types
> were different, rather than the symptom of not being able to satisfy
> operator std::string::?:() ?
It *is* complaining that the types are different (just not very clearly.)
The error has nothing to do with the type being initialized.
Here's a simpler form of your original which might convince you of that:
#include
#include
using namespace std;
void f()
{
list myItems;
string myName;
false ? myItems : myName;
}
This still gives the same error. Understand now?
[Bug rtl-optimization/54269] [4.8 Regression] memory usage too large when optimizing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54269 Joost VandeVondele changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #6 from Joost VandeVondele 2012-08-22 07:40:26 UTC --- Fixed for current trunk, maybe a dup of PR54332
[Bug rtl-optimization/54269] [4.8 Regression] memory usage too large when optimizing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54269 --- Comment #7 from Joost VandeVondele 2012-08-22 07:43:30 UTC --- Fixed for current trunk, maybe a dup of PR54332
[Bug c/52991] attribute packed broken on mingw32?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52991
--- Comment #5 from Mikael Pettersson 2012-08-22
08:34:46 UTC ---
The following variation of the test case was compiled with both gcc-4.7.1 and
MS Visual Studio 2008:
#include
#if defined(__GNUC__)
struct A1 {
short s;
struct { int i; } x;
} __attribute__((__packed__));
#endif
#pragma pack(1)
struct A2 {
short s;
struct { int i; } x;
};
#pragma pack()
int main(void)
{
#if defined(__GNUC__)
printf("sizeof(struct A1) == %u\n", (unsigned)sizeof(struct A1));
#endif
printf("sizeof(struct A2) == %u\n", (unsigned)sizeof(struct A2));
return 0;
}
Note that structs A1 and A2 are identical, except A1 is packed (when compiled
by gcc) using the attribute syntax and A2 is packed using the #pragma syntax.
Compiling this with gcc-4.7.1 (target x86_64-w64-mingw32) with -mms-bitfields
(which is the default) gives:
sizeof(struct A1) == 8
sizeof(struct A2) == 6
proving that attribute packed doesn't work. With -mno-ms-bitfields both
structs are reported as being 6 bytes.
Compiling with Visual Studio 2008 gives:
sizeof(struct A2) == 6
as expected.
[Bug middle-end/53676] [4.7 regression] empty loop is not always removed now
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53676 --- Comment #13 from Richard Guenther 2012-08-22 08:46:54 UTC --- (In reply to comment #12) > I've been doing research into LLVM 3.1 and other GCC versions. LLVM 3.1 > correctly eliminate the (near) empty loop, and their current trunk does not > regress like 4.7 has. > > Is the trunk patch coupled to other changes that are too invasive for 4.7? I'm > confused and curious about what optimization regressions are serious enough to > warrant a back port, if any. No, it's only the commit referenced in this PR. No optimization regressions warrant a backport as they always come with the risk of regressing something worse than performance. Trivial restoring of old behavior might be worth backporting but the patch introduces a completely new non-trivial transform into a core analysis engine that is shared among many passes.
[Bug middle-end/53676] [4.7 regression] empty loop is not always removed now
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53676 Steven Bosscher changed: What|Removed |Added CC||steven at gcc dot gnu.org --- Comment #14 from Steven Bosscher 2012-08-22 08:55:05 UTC --- (In reply to comment #13) > No, it's only the commit referenced in this PR. No optimization regressions > warrant a backport as they always come with the risk of regressing something > worse than performance. Trivial restoring of old behavior might be worth > backporting but the patch introduces a completely new non-trivial transform > into a core analysis engine that is shared among many passes. FWIW, it seems to me that small patches, even non-trivial ones, should be candidates for back-porting after they've been on the trunk or on a later release branch for a reasonable period of time. E.g. after 3 months on the GCC 4.8 trunk and with no resulting bugs reported, this patch should be considered for back-porting IMHO.
[Bug rtl-optimization/54269] [4.8 Regression] memory usage too large when optimizing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54269 Steven Bosscher changed: What|Removed |Added Resolution|FIXED |DUPLICATE --- Comment #8 from Steven Bosscher 2012-08-22 08:59:04 UTC --- No question, this was a dup. *** This bug has been marked as a duplicate of bug 54332 ***
[Bug middle-end/54332] [4.8 Regression] 481.wrf in SPEC CPU 2006 takes > 10GB memory to compile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54332 Steven Bosscher changed: What|Removed |Added CC||Joost.VandeVondele at mat ||dot ethz.ch --- Comment #28 from Steven Bosscher 2012-08-22 08:59:04 UTC --- *** Bug 54269 has been marked as a duplicate of this bug. ***
[Bug middle-end/53676] [4.7 regression] empty loop is not always removed now
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53676 --- Comment #15 from Richard Guenther 2012-08-22 09:17:10 UTC --- (In reply to comment #14) > (In reply to comment #13) > > No, it's only the commit referenced in this PR. No optimization regressions > > warrant a backport as they always come with the risk of regressing something > > worse than performance. Trivial restoring of old behavior might be worth > > backporting but the patch introduces a completely new non-trivial transform > > into a core analysis engine that is shared among many passes. > > FWIW, it seems to me that small patches, even non-trivial ones, should be > candidates for back-porting after they've been on the trunk or on a later > release branch for a reasonable period of time. E.g. after 3 months on the GCC > 4.8 trunk and with no resulting bugs reported, this patch should be considered > for back-porting IMHO. Testing coverage during stage1 isn't very good IMHO, so we should wait at least until we enter stage3. But again, patch size isn't a good metric, it is the coverage that counts - for this patch, changing SCEV analysis in a non-trivial way is very intrusive.
[Bug rtl-optimization/54343] RTL postreload leaks DF memory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54343 --- Comment #4 from Richard Guenther 2012-08-22 09:32:13 UTC --- (In reply to comment #3) > HJ's fix for PR 54332 will probably fix this one, too. Could you re-test? > > Thanks. Doesn't fix it. ==18936== 3,984 bytes in 249 blocks are definitely lost in loss record 28,126 of 29,883 ==18936==at 0x4C29ADD: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==18936==by 0xCE2D27: xmalloc (xmalloc.c:147) ==18936==by 0x6B05FD: df_refs_add_to_chains(df_collection_rec*, basic_block_def*, rtx_def*) (df-scan.c:2669) ==18936==by 0x6B50B4: df_bb_refs_record(int, bool) (df-scan.c:3644) ==18936==by 0x6B51BC: df_scan_blocks() (df-scan.c:678) ==18936==by 0x7B6C1D: rest_of_handle_reload() (ira.c:4390) ==18936==by 0x818CEA: execute_one_pass(opt_pass*) (passes.c:2157) ==18936==by 0x819034: execute_pass_list(opt_pass*) (passes.c:2212) ==18936==by 0x819046: execute_pass_list(opt_pass*) (passes.c:2213) ==18936==by 0x68F533: expand_function(cgraph_node*) (cgraphunit.c:1609) ==18936==by 0x690998: compile() (cgraphunit.c:1714) ==18936==by 0x690F14: finalize_compilation_unit() (cgraphunit.c:2089)
[Bug middle-end/53695] [4.8 Regression] ICE: in dfs_enumerate_from, at cfganal.c:1221 with -O2 -ftracer and labels/gotos
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53695 --- Comment #5 from Richard Guenther 2012-08-22 09:36:10 UTC --- Patch that was posted (no comments yet): http://gcc.gnu.org/ml/gcc-patches/2012-06/msg01754.html
[Bug debug/53671] [4.8 Regression] Many guality test failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53671 Igor Zamyatin changed: What|Removed |Added CC||izamyatin at gmail dot com --- Comment #11 from Igor Zamyatin 2012-08-22 10:13:03 UTC --- For r190586: FAIL: gfortran.dg/guality/pr41558.f90 -O0 line 7 s == 'foo' FAIL: gfortran.dg/guality/pr41558.f90 -O1 line 7 s == 'foo' FAIL: gfortran.dg/guality/pr41558.f90 -O2 line 7 s == 'foo' FAIL: gfortran.dg/guality/pr41558.f90 -O3 -fomit-frame-pointer line 7 s == 'foo' FAIL: gfortran.dg/guality/pr41558.f90 -O3 -fomit-frame-pointer -funroll-loops line 7 s == 'foo' FAIL: gfortran.dg/guality/pr41558.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions line 7 s == 'foo' FAIL: gfortran.dg/guality/pr41558.f90 -O3 -g line 7 s == 'foo' FAIL: gfortran.dg/guality/pr41558.f90 -Os line 7 s == 'foo'
[Bug debug/53671] [4.8 Regression] Many guality test failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53671 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||mark at gcc dot gnu.org --- Comment #12 from Jakub Jelinek 2012-08-22 10:39:22 UTC --- The last one is an unrelated issue, caused by http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190543 (you'll notice also that all of the C and C++ guality testing is not performed any longer). The issue is that with the above change one needs to use GDB 7.5 or later (or at least have the constant class DW_AT_high_pc support patch backported to GDB 7.4.*). Mark, can you point to the commit with the fix?
[Bug debug/53671] [4.8 Regression] Many guality test failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53671 --- Comment #13 from Mark Wielaard 2012-08-22 11:10:21 UTC --- [PATCH] gdb: dwarf2read.c handle DW_AT_high_pc constant form for DWARF 4+. http://sourceware.org/ml/gdb-patches/2012-04/msg00982.html
[Bug debug/53671] [4.8 Regression] Many guality test failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53671 --- Comment #14 from Igor Zamyatin 2012-08-22 11:24:17 UTC --- Thanks!
[Bug tree-optimization/46590] [4.6/4.7/4.8 Regression] long compile time with -O2 and many loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46590 --- Comment #27 from Richard Guenther 2012-08-22 11:39:56 UTC --- The issue with loop header copying is that we use incremental SSA updating with PHI insertion for each individual loop header copied. That computes dominance frontiers which is always for the whole function. I thought that loop header copying wouldn't need to insert new PHI nodes and thus can do with TODO_update_ssa_no_phi if we are in loop-closed SSA form, but appearantly that is not the case (I didn't inverstigate further here, but possibly that's just because virtual operands are not in loop-closed SSA form).
[Bug tree-optimization/53852] [4.8 Regression] -ftree-loop-linear: large compile time / memory usage
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53852 --- Comment #5 from Joost VandeVondele 2012-08-22 11:58:00 UTC --- simplified testcase and some analysis: SUBROUTINE build_d_tensor_gks(d5f,v,d5) INTEGER, PARAMETER :: dp=8 REAL(KIND=dp), DIMENSION(3, 3, 3, 3, 3), & INTENT(OUT) :: d5f REAL(KIND=dp), DIMENSION(3), INTENT(IN) :: v REAL(KIND=dp), INTENT(IN) :: d5 INTEGER :: k1, k2, k3, k4, k5 REAL(KIND=dp) :: w d5f = 0.0_dp DO k1=1,3 DO k2=1,3 DO k3=1,3 DO k4=1,3 DO k5=1,3 d5f(k5,k4,k3,k2,k1)=d5f(k5,k4,k3,k2,k1)+ & v(k1)*v(k2)*v(k3)*v(k4)*v(k5)*d5 ENDDO w=v(k1)*v(k2)*v(k3)*d4 d5f(k1,k2,k3,k4,k4)=d5f(k1,k2,k3,k4,k4)+w d5f(k1,k2,k4,k3,k4)=d5f(k1,k2,k4,k3,k4)+w d5f(k1,k4,k2,k3,k4)=d5f(k1,k4,k2,k3,k4)+w d5f(k4,k1,k2,k3,k4)=d5f(k4,k1,k2,k3,k4)+w d5f(k1,k2,k4,k4,k3)=d5f(k1,k2,k4,k4,k3)+w ! d5f(k1,k4,k2,k4,k3)=d5f(k1,k4,k2,k4,k3)+w ! d5f(k4,k1,k2,k4,k3)=d5f(k4,k1,k2,k4,k3)+w ! d5f(k1,k4,k4,k2,k3)=d5f(k1,k4,k4,k2,k3)+w ! d5f(k4,k1,k4,k2,k3)=d5f(k4,k1,k4,k2,k3)+w ! d5f(k4,k4,k1,k2,k3)=d5f(k4,k4,k1,k2,k3)+w ENDDO ENDDO ENDDO ENDDO END SUBROUTINE build_d_tensor_gks the issue is that the compile time grows exponentially in the number of uncommented lines of the d5f=d5f+w type: 1 0m1.112s 2 0m4.448s 3 0m11.513s 4 0m21.514s 5 0m35.529s
[Bug tree-optimization/54317] [4.8 Regression] FAIL: c45532m c45532n c45532o c45532p
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54317
--- Comment #4 from Marc Glisse 2012-08-22 12:29:34
UTC ---
Author: glisse
Date: Wed Aug 22 12:29:23 2012
New Revision: 190591
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190591
Log:
2012-08-22 Marc Glisse
PR tree-optimization/54317
gcc/
* tree-vrp.c (extract_range_from_binary_expr_1): Test for
double_int overflow.
Remove dead tests.
gcc/testsuite/
* gcc.dg/tree-ssa/vrp79.c: New testcase.
Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/vrp79.c (with props)
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vrp.c
Propchange: trunk/gcc/testsuite/gcc.dg/tree-ssa/vrp79.c
('svn:eol-style' added)
Propchange: trunk/gcc/testsuite/gcc.dg/tree-ssa/vrp79.c
('svn:keywords' added)
[Bug tree-optimization/54317] [4.8 Regression] FAIL: c45532m c45532n c45532o c45532p
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54317 --- Comment #5 from Marc Glisse 2012-08-22 12:38:36 UTC --- Hello, I have no idea if the last commit helped, feel free to reconfirm the bug.
[Bug rtl-optimization/54343] RTL postreload leaks DF memory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54343 --- Comment #5 from dnovillo at google dot com 2012-08-22 12:43:02 UTC --- On 2012-08-22 05:32 , rguenth at gcc dot gnu.org wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54343 > > --- Comment #4 from Richard Guenther 2012-08-22 > 09:32:13 UTC --- > (In reply to comment #3) >> HJ's fix for PR 54332 will probably fix this one, too. Could you re-test? >> >> Thanks. > > Doesn't fix it. OK, then it wasn't related. Do you know if this started happening with rev 190402? Diego.
[Bug rtl-optimization/54343] RTL postreload leaks DF memory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54343 --- Comment #6 from rguenther at suse dot de 2012-08-22 13:01:53 UTC --- On Wed, 22 Aug 2012, dnovillo at google dot com wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54343 > > --- Comment #5 from dnovillo at google dot com > 2012-08-22 12:43:02 UTC --- > On 2012-08-22 05:32 , rguenth at gcc dot gnu.org wrote: > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54343 > > > > --- Comment #4 from Richard Guenther > > 2012-08-22 09:32:13 UTC --- > > (In reply to comment #3) > >> HJ's fix for PR 54332 will probably fix this one, too. Could you re-test? > >> > >> Thanks. > > > > Doesn't fix it. > > OK, then it wasn't related. Do you know if this started happening with > rev 190402? I don't and I don't believe it did.
[Bug tree-optimization/46590] [4.6/4.7/4.8 Regression] long compile time with -O2 and many loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46590 --- Comment #28 from Richard Guenther 2012-08-22 13:17:42 UTC --- Author: rguenth Date: Wed Aug 22 13:17:26 2012 New Revision: 190594 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190594 Log: 2012-08-22 Richard Guenther PR tree-optimization/46590 * tree-ssa-alias.h (get_continuation_for_phi): Add alias query counter output argument. (walk_non_aliased_vuses): Add alias query counter argument to the walker callback. * tree-ssa-alias.c (maybe_skip_until): Add alias query counter output argument and count alias queries. (get_continuation_for_phi_1): Likewise. (get_continuation_for_phi): Likewise. (walk_non_aliased_vuses): Add alias query counter argument to the walker callback and allow it to abort the walk by returning -1. * tree-ssa-pre.c (translate_vuse_through_block): Adjust. * tree-ssa-sccvn.c (vn_reference_lookup_2): Add alias query counter parmeter, abort walk if that is bigger than --param sccvn-max-alias-queries-per-access. * params.def (sccvn-max-alias-queries-per-access): New param. * doc/invoke.texi (sccvn-max-alias-queries-per-access): Document. Modified: trunk/gcc/ChangeLog trunk/gcc/doc/invoke.texi trunk/gcc/params.def trunk/gcc/tree-ssa-alias.c trunk/gcc/tree-ssa-alias.h trunk/gcc/tree-ssa-pre.c trunk/gcc/tree-ssa-sccvn.c
[Bug target/54347] REAL_VALUE_TO_TARGET_LONG_DOUBLE shouldn't be used with XFmode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54347 H.J. Lu changed: What|Removed |Added Target Milestone|--- |4.8.0 --- Comment #1 from H.J. Lu 2012-08-22 13:56:00 UTC --- This is similar to PR 15290.
[Bug target/54349] New: _mm_cvtsi128_si64 unnecessary stores value at stack
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54349
Bug #: 54349
Summary: _mm_cvtsi128_si64 unnecessary stores value at stack
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: nel...@seznam.cz
Consider following program:
#include
#include
int64_t foo(__m128i a){return _mm_cvtsi128_si64(a);}
int64_t bar(double b){ return *((int64_t*)&b);}
A _mm_cvtsi128_si64 does unnecesary store into stack instead moving to register
directly. Same problem is present when interpreting double as integer.
.file "e.c"
.text
.p2align 4,,15
.globl foo
.type foo, @function
foo:
.LFB517:
.cfi_startproc
movq %xmm0, -16(%rsp)
movq -16(%rsp), %rax
ret
.cfi_endproc
.LFE517:
.size foo, .-foo
.p2align 4,,15
.globl bar
.type bar, @function
bar:
.LFB518:
.cfi_startproc
movsd %xmm0, -8(%rsp)
movq -8(%rsp), %rax
ret
.cfi_endproc
.LFE518:
.size bar, .-bar
.ident "GCC: (Debian 20120820-1) 4.8.0 20120820 (experimental) [trunk
revision 190537]"
.section .note.GNU-stack,"",@progbits
[Bug target/54349] _mm_cvtsi128_si64 unnecessary stores value at stack
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54349 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution||INVALID --- Comment #1 from Jakub Jelinek 2012-08-22 14:57:54 UTC --- Not a bug. You need to tune for a CPU where inter-unit moves are desirable. The default is generic tuning, which is a compromise between Intel CPUs (where they are desirable) and AMD CPUs (where they are undesirable). In this particular case the generic tuning doesn't do inter-unit moves as part of the compromise. If you -mtune=corei7 or similar, you'll get an inter-unit move in both cases.
[Bug target/47440] Use LCM for vzeroupper insertion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47440 Vladimir Yakovlev changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #3 from Vladimir Yakovlev 2012-08-22 15:25:54 UTC --- I implemented vzeroupper insertion using mode switching technique. http://gcc.gnu.org/ml/gcc-patches/2012-08/msg01429.html
[Bug debug/13111] g++ debuginfo incorrect for verify.cc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13111 Tom Tromey changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #3 from Tom Tromey 2012-08-22 15:42:54 UTC --- I tried this today and it all seems to work ok. I didn't look to see if the bug was in gcc or gdb.
[Bug fortran/54350] New: [4.8 Regression] FAIL: gfortran.dg/realloc_on_assign_*.f90 -O (internal compiler error) at r190586
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54350 Bug #: 54350 Summary: [4.8 Regression] FAIL: gfortran.dg/realloc_on_assign_*.f90 -O (internal compiler error) at r190586 Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: domi...@lps.ens.fr CC: bur...@net-b.de, hjl.to...@gmail.com Revision 190586 caused several failures in the gfortran test suite: FAIL: gfortran.dg/realloc_on_assign_14.f90 -O (internal compiler error) FAIL: gfortran.dg/realloc_on_assign_14.f90 -O (internal compiler error) FAIL: gfortran.dg/realloc_on_assign_14.f90 -O (test for excess errors) FAIL: gfortran.dg/realloc_on_assign_14.f90 -O (test for excess errors) FAIL: gfortran.dg/realloc_on_assign_15.f90 -O0 (internal compiler error) FAIL: gfortran.dg/realloc_on_assign_15.f90 -O0 (internal compiler error) FAIL: gfortran.dg/realloc_on_assign_15.f90 -O0 (test for excess errors) FAIL: gfortran.dg/realloc_on_assign_15.f90 -O0 (test for excess errors) FAIL: gfortran.dg/realloc_on_assign_15.f90 -O1 (internal compiler error) FAIL: gfortran.dg/realloc_on_assign_15.f90 -O1 (internal compiler error) FAIL: gfortran.dg/realloc_on_assign_15.f90 -O1 (test for excess errors) FAIL: gfortran.dg/realloc_on_assign_15.f90 -O1 (test for excess errors) FAIL: gfortran.dg/realloc_on_assign_15.f90 -O2 (internal compiler error) FAIL: gfortran.dg/realloc_on_assign_15.f90 -O2 (internal compiler error) FAIL: gfortran.dg/realloc_on_assign_15.f90 -O2 (test for excess errors) FAIL: gfortran.dg/realloc_on_assign_15.f90 -O2 (test for excess errors) FAIL: gfortran.dg/realloc_on_assign_15.f90 -O3 -fomit-frame-pointer (internal compiler error) FAIL: gfortran.dg/realloc_on_assign_15.f90 -O3 -fomit-frame-pointer (internal compiler error) FAIL: gfortran.dg/realloc_on_assign_15.f90 -O3 -fomit-frame-pointer (test for excess errors) FAIL: gfortran.dg/realloc_on_assign_15.f90 -O3 -fomit-frame-pointer (test for excess errors) FAIL: gfortran.dg/realloc_on_assign_15.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions (internal compiler error) FAIL: gfortran.dg/realloc_on_assign_15.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions (internal compiler error) FAIL: gfortran.dg/realloc_on_assign_15.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions (test for excess errors) FAIL: gfortran.dg/realloc_on_assign_15.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions (test for excess errors) FAIL: gfortran.dg/realloc_on_assign_15.f90 -O3 -fomit-frame-pointer -funroll-loops (internal compiler error) FAIL: gfortran.dg/realloc_on_assign_15.f90 -O3 -fomit-frame-pointer -funroll-loops (internal compiler error) FAIL: gfortran.dg/realloc_on_assign_15.f90 -O3 -fomit-frame-pointer -funroll-loops (test for excess errors) FAIL: gfortran.dg/realloc_on_assign_15.f90 -O3 -fomit-frame-pointer -funroll-loops (test for excess errors) FAIL: gfortran.dg/realloc_on_assign_15.f90 -O3 -g (internal compiler error) FAIL: gfortran.dg/realloc_on_assign_15.f90 -O3 -g (internal compiler error) FAIL: gfortran.dg/realloc_on_assign_15.f90 -O3 -g (test for excess errors) FAIL: gfortran.dg/realloc_on_assign_15.f90 -O3 -g (test for excess errors) FAIL: gfortran.dg/realloc_on_assign_15.f90 -Os (internal compiler error) FAIL: gfortran.dg/realloc_on_assign_15.f90 -Os (internal compiler error) FAIL: gfortran.dg/realloc_on_assign_15.f90 -Os (test for excess errors) FAIL: gfortran.dg/realloc_on_assign_15.f90 -Os (test for excess errors) FAIL: gfortran.dg/realloc_on_assign_2.f03 -O0 (internal compiler error) FAIL: gfortran.dg/realloc_on_assign_2.f03 -O0 (internal compiler error) FAIL: gfortran.dg/realloc_on_assign_2.f03 -O0 (test for excess errors) FAIL: gfortran.dg/realloc_on_assign_2.f03 -O0 (test for excess errors) FAIL: gfortran.dg/realloc_on_assign_2.f03 -O1 (internal compiler error) FAIL: gfortran.dg/realloc_on_assign_2.f03 -O1 (internal compiler error) FAIL: gfortran.dg/realloc_on_assign_2.f03 -O1 (test for excess errors) FAIL: gfortran.dg/realloc_on_assign_2.f03 -O1 (test for excess errors) FAIL: gfortran.dg/realloc_on_assign_2.f03 -O2 (internal compiler error) FAIL: gfortran.dg/realloc_on_assign_2.f03 -O2 (internal compiler error) FAIL: gfortran.dg/realloc_on_assign_2.f03 -O2 (test for excess errors) FAIL: gfortran.dg/realloc_on_assign_2.f03 -O2 (test for excess errors) FAIL: gfortran.dg/realloc_on_assign_2.f03 -O3 -fomit-frame-pointer (internal compiler error) FAIL: gfortran.dg/realloc_on_assign_2.f03 -O3 -fomit-frame-pointer (internal compiler error) FAIL: gfortran.dg/realloc_on_assign_2.f03 -O3 -fomit-frame-pointer (test for excess errors) FAIL: gfortran.dg/realloc_on_assign_2.
[Bug libgcj/51498] make dejagnu work in libjava testsuite with cross-build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51498 gee changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||WONTFIX --- Comment #11 from gee 2012-08-22 17:04:43 UTC --- (In reply to comment #8) > Oh, and why is this a regression? dejagnu failed to detect the built gcj compiler in canadian cross. and dejagnu.am of automake is responsible for not exporting makefile variables CC, CXX, GCJ,... etc to shell. so the cause is not gcc. and this bug isn't applicable to gcc bugzilla. so i'm closing the bug.
[Bug tree-optimization/46590] [4.6/4.7/4.8 Regression] long compile time with -O2 and many loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46590 --- Comment #29 from stevenb.gcc at gmail dot com 2012-08-22 17:33:00 UTC --- > I thought that loop header copying wouldn't need to insert new PHI nodes > and thus can do with TODO_update_ssa_no_phi if we are in loop-closed SSA form, > but appearantly that is not the case (I didn't inverstigate further here, > but possibly that's just because virtual operands are not in loop-closed > SSA form). I'll experiment with VOPs in LC-SSA.
[Bug libstdc++/54351] New: ~unique_ptr() should not set __p to null
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54351
Bug #: 54351
Summary: ~unique_ptr() should not set __p to null
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: gro...@google.com
libstdc++'s unique_ptr destructor is currently implemented as:
~unique_ptr() noexcept { reset(); }
This has the effect of resetting the stored pointer to null, and then invoking
the deleter on the formerly-stored pointer. I believe this is inconsistent with
the language standard, which specifies the destructor as "If get() == nullptr
there are no effects. Otherwise get_deleter()(get())." (note no mention of any
side effects on the value of the stored pointer). This is a problem because
this implementation will break code that (legitimately, AFAICT) relies on being
able to continue to invoke operations on the scoped_ptr while the destructor is
executing.
The fix is to reimplement the destructor (in both the base template and the
array specialization) as
~unique_ptr() noexcept {
if (__p != pointer())
get_deleter()(__p);
}
If the intent is to zero out __p to help catch use-after-destruction errors, I
believe it would be permissible to set __p to null after the call to
get_deleter(), because at that point the change would no longer be visible to
conforming code.
To make this concrete, here's an example: the following program prints "bad"
under libstdc++, but I believe a standard-conforming implementation is required
to print "good":
=
#include
#include
using std::cout;
using std::endl;
using std::unique_ptr;
struct A;
struct B {
unique_ptr a;
};
struct A {
B* b;
~A() {
if (b->a == nullptr) {
cout << "bad" << endl;
} else {
cout << "good" << endl;
}
}
};
int main(int argc, char** argv) {
B b;
b.a.reset(new A);
b.a->b = &b;
}
===
As a point of comparison, MSVC++ 2010 prints "good" on this example program.
[Bug libstdc++/54351] ~unique_ptr() should not set __p to null
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54351 --- Comment #1 from Jonathan Wakely 2012-08-22 18:43:47 UTC --- Hmm, the behaviour was probalby correct prior to fixing PR 43183, as the old implementation of reset() did exactly what is required of the destructor. However, the lifetime of the unique_ptr ends when the destructor starts ([basic.life]/1) so I don't believe it is legitimate to access it at that point.
[Bug libstdc++/54351] ~unique_ptr() should not set __p to null
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54351 --- Comment #2 from Jonathan Wakely 2012-08-22 18:47:07 UTC --- That said, whether the testcase is valid or not, I don't see any harm in making the change.
[Bug libstdc++/54351] ~unique_ptr() should not set __p to null
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54351 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-08-22 Ever Confirmed|0 |1 --- Comment #3 from Jonathan Wakely 2012-08-22 18:51:27 UTC --- Looking more closely, [basic.life]/5 and [class.cdtor]/1 do seem to allow your testcase. So confirmed.
[Bug libstdc++/54351] ~unique_ptr() should not set __p to null
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54351
--- Comment #4 from Jonathan Wakely 2012-08-22
18:58:22 UTC ---
I'll test this change:
@@ -169,7 +169,13 @@
#endif
// Destructor.
- ~unique_ptr() noexcept { reset(); }
+ ~unique_ptr() noexcept
+ {
+ auto& __ptr = std::get<0>(_M_t);
+ if (__ptr != pointer())
+ get_deleter()(__ptr);
+ __ptr = pointer();
+ }
// Assignment.
unique_ptr&
[Bug libstdc++/54351] ~unique_ptr() should not set __p to null
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54351 --- Comment #5 from Geoff Romer 2012-08-22 19:11:17 UTC --- Don't forget the array specialization. Doesn't the first line of your new destructor shadow the __p member with a __p local variable? Why is that line needed at all?
[Bug libstdc++/51823] [DR 198] reverse iterator returns uninitialized values
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51823 Jonathan Wakely changed: What|Removed |Added Keywords||ABI --- Comment #12 from Jonathan Wakely 2012-08-22 19:19:15 UTC --- setting ABI keyword as this can't be properly fixed without an incompatible change
[Bug libstdc++/49204] [C++0x] remaining issues in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49204 Jonathan Wakely changed: What|Removed |Added Keywords||ABI --- Comment #9 from Jonathan Wakely 2012-08-22 19:20:19 UTC --- (In reply to comment #7) > timed waiting functions do nto return future_status::deferred if the shared > state contains a deferred function (requires an additional virtual function to > be added to the vtable) setting ABI keyword as this can't be properly fixed without an incompatible change
[Bug middle-end/53695] [4.8 Regression] ICE: in dfs_enumerate_from, at cfganal.c:1221 with -O2 -ftracer and labels/gotos
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53695
Steven Bosscher changed:
What|Removed |Added
CC||steven at gcc dot gnu.org
--- Comment #6 from Steven Bosscher 2012-08-22
19:26:03 UTC ---
(In reply to comment #4)
Wouldn't this patch disable all loop detection for loops with exceptions and so
on in them? That seems a rather big hammer to this problem. It should be enough
to check only for EH_ABNORMAL.
What caused the ICE to appear anyway? There is a problem I can see in
dfs_enumerate_from that could cause it to ICE.
At the point of the ICE, we have the following CFG (cc1 -O2 -ftracer):
(gdb) p current_pass->name
$5 = 0x13195b0 "local-pure-const"
(gdb) p brief_dump_cfg(stderr,-1)
;; basic block 2, loop depth 0, count 0, freq 6667, maybe hot
;; prev block 0, next block 3, flags: (NEW, REACHABLE)
;; pred: ENTRY [100.0%] (FALLTHRU,EXECUTABLE)
;; succ: 3 [100.0%] (FALLTHRU,EXECUTABLE)
;; basic block 3, loop depth 0, count 0, freq 6667, maybe hot
;; prev block 2, next block 4, flags: (NEW, REACHABLE, IRREDUCIBLE_LOOP)
;; pred: 2 [100.0%] (FALLTHRU,EXECUTABLE)
;; succ: 5 [100.0%] (FALLTHRU,IRREDUCIBLE_LOOP,EXECUTABLE)
;; basic block 4, loop depth 0, count 0, freq 0
;; Invalid sum of incoming frequencies , should be 0
;; prev block 3, next block 5, flags: (NEW, REACHABLE, IRREDUCIBLE_LOOP)
;; pred: 5 [33.3%] (ABNORMAL,IRREDUCIBLE_LOOP,EXECUTABLE)
;; succ: 5 [100.0%] (FALLTHRU,DFS_BACK,IRREDUCIBLE_LOOP,EXECUTABLE)
;; basic block 5, loop depth 1, count 0, freq 1, maybe hot
;; prev block 4, next block 6, flags: (NEW, REACHABLE)
;; pred: 4 [100.0%] (FALLTHRU,DFS_BACK,IRREDUCIBLE_LOOP,EXECUTABLE)
;; 6 [100.0%] (FALLTHRU,DFS_BACK,EXECUTABLE)
;; 3 [100.0%] (FALLTHRU,IRREDUCIBLE_LOOP,EXECUTABLE)
;; succ: 4 [33.3%] (ABNORMAL,IRREDUCIBLE_LOOP,EXECUTABLE)
;; 6 [33.3%] (ABNORMAL,EXECUTABLE)
;; 7 [33.3%] (ABNORMAL,EXECUTABLE)
;; basic block 6, loop depth 1, count 0, freq , maybe hot
;; prev block 5, next block 7, flags: (NEW, REACHABLE)
;; pred: 5 [33.3%] (ABNORMAL,EXECUTABLE)
;; succ: 5 [100.0%] (FALLTHRU,DFS_BACK,EXECUTABLE)
;; basic block 7, loop depth 0, count 0, freq , maybe hot
;; prev block 6, next block 1, flags: (NEW, REACHABLE)
;; pred: 5 [33.3%] (ABNORMAL,EXECUTABLE)
;; succ: EXIT [100.0%]
Or in human-readable form:
ENTRY
|
V
|
2(0)
|
|
V
|
3(0)
|
\
\
\
\
\
\
+-->--+ | +--<---+
| \ V / |
| \ | /|
+-4(1)-<-5(1)->-6(1)-+
(a) | (a)
|
|(a)
|
7(0)
|
EXIT
where "(a)" denotes abnormal edge, of course, and (0) or (1) is the loop depth
at this point.
The loop detected here is the region with the abnormal edges, for blocks 4, 5,
and 6. The detected "loop" has header bb 5 and latch bb 6, which is not clearly
wrong: this is just two loops with the same header. But this confuses
dfs_enumerate_from, which does a reverse DFS from basic block 5 with predicate
glb_enum_p. The DFS visits block 5, 4, and 6, but dfs_enumerate_from is told to
expect to visit only 2 basic blocks, not 3. The reason it sees 3 is that
glb_enum_p is this:
/* Enumeration predicate for get_loop_body_with_size. */
static bool
glb_enum_p (const_basic_block bb, const void *glb_loop)
{
const struct loop *const loop = (const struct loop *) glb_loop;
return (bb != loop->header
&& dominated_by_p (CDI_DOMINATORS, bb, loop->header));
}
called with loop->header == bb5, and called with bb==4 and bb==6. And since bb5
dominates both bb4 and bb6, the predicate returns true for both, and
dfs_enumerate_from ends up visiting 3 basic blocks. So why is it told to expect
two blocks in the first place, instead of 3?
dfs_enumerate_from is called, via get_loop_body_with_size, from get_loop_body:
tv = get_loop_body_with_size (loop, body, loop->num_nodes);
The natural loop 1 has only two nodes, namely bb5 and bb6. So where does bb4
come from? That's tracer at work.
So the root cause here, is that tracer should either update the loop tree or
refrain from duplicating blocks if it results in a single loop header
dominating two separate loops.
Irreducibility and updating the loop tree are the key to fixing this bug, not
the big hammer patch of comment #4.
[Bug libstdc++/54351] ~unique_ptr() should not set __p to null
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54351 --- Comment #6 from Jonathan Wakely 2012-08-22 19:28:15 UTC --- (In reply to comment #5) > Don't forget the array specialization. I won't :-) > Doesn't the first line of your new destructor shadow the __p member with a __p > local variable? Why is that line needed at all? There is no __p member.
[Bug target/54347] REAL_VALUE_TO_TARGET_LONG_DOUBLE shouldn't be used with XFmode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54347 --- Comment #2 from hjl at gcc dot gnu.org 2012-08-22 19:44:04 UTC --- Author: hjl Date: Wed Aug 22 19:43:58 2012 New Revision: 190598 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190598 Log: Replace REAL_VALUE_TO_TARGET_LONG_DOUBLE with real_to_target PR target/54347 * config/i386/i386.c (ix86_split_to_parts): Replace REAL_VALUE_TO_TARGET_LONG_DOUBLE with real_to_target. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c
[Bug libstdc++/49561] [C++0x] std::list::size complexity
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49561 Jonathan Wakely changed: What|Removed |Added Keywords||ABI --- Comment #18 from Jonathan Wakely 2012-08-22 19:47:03 UTC --- setting ABI keyword as this can't be properly fixed without an incompatible change
[Bug libstdc++/54351] ~unique_ptr() should not set stored pointer to null
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54351 --- Comment #7 from Geoff Romer 2012-08-22 19:49:28 UTC --- (In reply to comment #6) > (In reply to comment #5) > > Don't forget the array specialization. > > I won't :-) > > > Doesn't the first line of your new destructor shadow the __p member with a > > __p > > local variable? Why is that line needed at all? > > There is no __p member. Ah, sorry, I was evidently misreading something. I've corrected the bug description.
[Bug fortran/54350] [4.8 Regression] FAIL: gfortran.dg/realloc_on_assign_*.f90 -O (internal compiler error) at r190586
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54350 Hans-Peter Nilsson changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-08-22 CC||burnus at gcc dot gnu.org, ||hp at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from Hans-Peter Nilsson 2012-08-22 19:59:16 UTC --- Seeing something like this for cris-elf too, specifically a regression for gfortran.sum gfortran.dg/realloc_on_assign_14.f90 gfortran.sum gfortran.dg/realloc_on_assign_15.f90 gfortran.sum gfortran.dg/realloc_on_assign_2.f03 for exactly r190586 except in my case (cross from x86_64-linux to cris-elf) the ICE message is the less specific: /tmp/hpautotest-gcc0/gcc/gcc/testsuite/gfortran.dg/realloc_on_assign_14.f90: In function 'MAIN__': /tmp/hpautotest-gcc0/gcc/gcc/testsuite/gfortran.dg/realloc_on_assign_14.f90:31:0: internal compiler error: Segmentation fault Adding committers' @gcc.gnu.org address to CC.
[Bug libstdc++/46906] istreambuf_iterator is late?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46906 Marc Glisse changed: What|Removed |Added Keywords||ABI CC||glisse at gcc dot gnu.org --- Comment #12 from Marc Glisse 2012-08-22 20:00:11 UTC --- Adding keyword ABI following Paolo's comment. (not a bug, according to Daniel, but that's orthogonal to being ABI-related)
[Bug middle-end/53695] [4.8 Regression] ICE: in dfs_enumerate_from, at cfganal.c:1221 with -O2 -ftracer and labels/gotos
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53695 --- Comment #7 from Steven Bosscher 2012-08-22 20:13:32 UTC --- Before tracer we have this CFG: ENTRY | V | 2(0) | | V |(a) | +-<-+ V /| | / / (a) 3(1)->-4(1)-->--5(1)-+ /\ | / +-<--+ / | V(a) | 6(0) | EXIT and (BASIC_BLOCK(3)->flags & IRREDUCIBLE_LOOP) is true. The IRREDUCIBLE_LOOP flags appear to be out-of-date because the flag is not set on BASIC_BLOCK(4) but it's set on all edges out of it so that's good enough. Tracer goes to work on this and finds the following traces: Trace seed 4 [1],4 [1],3 [6667] forward 2 [6667],3 [6667],4 [1] Duplicated 3 as 7 [6667] covered now 66.7 Trace seed 6 [] forward 6 [] covered now 100.0 The resulting flow graph was already shown in comment #6, but now with the basic block numbers before the CFG is cleaned up: ENTRY | V | 2(0) | | V | 7(0) | \ \ \ \ \ \ +-->--+ | +--<---+ | \ V / | | \ | /| +-3(1)-<-4(1)->-5(1)-+ (a) | (a) | |(a) | 6(0) | EXIT
[Bug middle-end/53695] [4.8 Regression] ICE: in dfs_enumerate_from, at cfganal.c:1221 with -O2 -ftracer and labels/gotos
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53695
--- Comment #8 from Steven Bosscher 2012-08-22
20:20:22 UTC ---
FWIW, GCC handles loops with one header and multiple latches just fine:
void do_something_1 (void);
void do_something_2 (void);
int some_cond (void);
void
foo (void)
{
while (1)
{
switch (some_cond ())
{
case 1:
do_something_1 ();
continue;
case 2:
do_something_2 ();
continue;
default:
return;
}
}
}
;; 2 loops found
;;
;; Loop 0
;; header 0, latch 1
;; depth 0, outer -1
;; nodes: 0 1 2 3 4 5 6 7
;;
;; Loop 1
;; header 4, latch 3
;; depth 1, outer 0
;; nodes: 4 3 6 5
;; 2 succs { 4 }
;; 3 succs { 4 }
;; 4 succs { 7 5 6 }
;; 5 succs { 3 }
;; 6 succs { 3 }
;; 7 succs { 1 }
foo ()
{
int _4;
:
goto ;
:
:
_4 = some_cond ();
switch (_4) , case 1: , case 2: >
:
do_something_1 ();
goto ;
:
do_something_2 ();
goto ;
:
return;
}
Note the single latch.
[Bug libstdc++/51653] More compact std::tuple
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51653 Marc Glisse changed: What|Removed |Added Keywords||ABI CC||glisse at gcc dot gnu.org --- Comment #3 from Marc Glisse 2012-08-22 20:23:46 UTC --- The suggestion in this PR is quite wild, but the fact that sizeof(tuple)==20 is a real issue that could probably be solved with less trouble (still ABI-breaking). Maybe I should have split the PR...
[Bug libstdc++/54352] New: relaxed data race rules for ~condition_variable_any
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54352
Bug #: 54352
Summary: relaxed data race rules for ~condition_variable_any
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Keywords: ABI
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: r...@gcc.gnu.org
(related to PR 54185, but for condition_variable_any)
As Howard pointed out in c++std-lib-32966 this should work:
#include
#include
#include
#include
#include
#include
#include
#include
template
class locked_list
{
std::mutex mut_;
std::list list_;
public:
typedef typename std::list::iterator iterator;
typedef typename T::key key;
template
void emplace_back(Args&& ...args)
{list_.emplace_back(std::forward(args)...);}
iterator find(const key& k)
{
std::unique_lock lk(mut_);
while (true)
{
iterator ep = std::find(list_.begin(), list_.end(), k);
if (ep == list_.end())
return ep;
if (!ep->busy())
{
ep->set_busy();
return ep;
}
ep->wait(lk);
}
}
void erase(iterator i)
{
std::lock_guard _(mut_);
assert(i->busy());
i->notify_all();
list_.erase(i);
}
iterator end() {return list_.end();}
};
template
class elt
{
Key key_;
std::condition_variable_any notbusy_;
bool busy_;
public:
typedef Key key;
explicit elt(const Key& k) : key_(k), busy_(false) {}
bool busy() const {return busy_;}
void set_busy() {busy_ = true;}
void unset_busy() {busy_ = false;}
template
void wait(Lock& lk) {notbusy_.wait(lk);}
void notify_all() {notbusy_.notify_all();}
bool operator==(const Key& k) const {return key_ == k;}
};
void
f1(locked_list>& list)
{
auto i = list.find(1);
assert(i != list.end());
std::this_thread::sleep_for(std::chrono::milliseconds(500));
list.erase(i);
}
void
f2(locked_list>& list)
{
auto i = list.find(1);
assert(i == list.end());
}
int main()
{
locked_list> list;
list.emplace_back(1);
std::thread t1 = std::thread(f1, std::ref(list));
std::this_thread::sleep_for(std::chrono::milliseconds(250));
std::thread t2 = std::thread(f2, std::ref(list));
t1.join();
t2.join();
}
This test doesn't actually crash with libstdc++, but valgrind shows it's
faulty.
Fixing this involves replacing std::condition_variable_any::_M_mutex with a
std::shared_ptr
[Bug bootstrap/54353] New: bootstrap-debug-ckovw bootstrap fails because of -fcompare-debug-not-overridden
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54353
Bug #: 54353
Summary: bootstrap-debug-ckovw bootstrap fails because of
-fcompare-debug-not-overridden
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ed...@email.it
I tried to bootstrap with GCC 4.7 branch with the options indicated below, but
it fails when it configures the 2nd stage for libgcc. I don't have the
config.log but it says as error:
error: unrecognised command line option ‘-fcompare-debug-not-overridden’
configuration:
../gccsrc/configure --enable-languages=c,c++ --prefix=$HOME/buildgcc
--program-suffix=-4.7-svn --with-build-config='bootstrap-debug-lean
bootstrap-debug-lib bootstrap-debug-ckovw'
probably the fault is the gccsrc/config/bootstrap-debug-ckovw.mk file:
FORCE_COMPARE_DEBUG = \
GCC_COMPARE_DEBUG=$${GCC_COMPARE_DEBUG--fcompare-debug-not-overridden}; \
export GCC_COMPARE_DEBUG;
POSTSTAGE1_HOST_EXPORTS += $(FORCE_COMPARE_DEBUG)
BASE_TARGET_EXPORTS += $(FORCE_COMPARE_DEBUG)
I can't verify this for the other versions.
>From what I heard in chat it seems that option was never tested it in these
years.
[Bug libstdc++/54352] relaxed data race rules for ~condition_variable_any
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54352 --- Comment #1 from Jonathan Wakely 2012-08-22 20:43:34 UTC --- Created attachment 28066 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28066 patch against 4.8 trunk
[Bug c++/28656] duplicated null argument warning on memcpy()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28656 Paolo Carlini changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.8.0 --- Comment #8 from Paolo Carlini 2012-08-22 20:45:25 UTC --- I guess we can close this as fixed for 4.8.0.
[Bug fortran/54350] [4.8 Regression] FAIL: gfortran.dg/realloc_on_assign_*.f90 -O (internal compiler error) at r190586
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54350 Tobias Burnus changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |burnus at gcc dot gnu.org |gnu.org | --- Comment #2 from Tobias Burnus 2012-08-22 20:49:08 UTC --- Yes, that's a side-effect of my recent patch - sorry. I know about the issue since this morning, but I didn't manage to fix it as quickly as I had hoped for. Debugging memory leaks and understanding the scalarizer took longer than anticipated. The simplest is to revert http://gcc.gnu.org/ml/fortran/2012-08/msg00120.html Some issues and a possible approach to fix them is given in http://gcc.gnu.org/ml/fortran/2012-08/msg00131.html and the reply http://gcc.gnu.org/ml/fortran/2012-08/msg00133.html I have a patch which is currently building, but with build fixes, other changes, and regtesting it will probably take a while until it is ready.
[Bug c++/32197] ICE when compiling with gcov options
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32197 Paolo Carlini changed: What|Removed |Added CC|gcc-bugs at gcc dot gnu.org | --- Comment #2 from Paolo Carlini 2012-08-22 20:52:24 UTC --- Is this still an issue?
[Bug c++/32658] Supposedly illegal conversion compiles without errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32658 Paolo Carlini changed: What|Removed |Added CC|gcc-bugs at gcc dot gnu.org | --- Comment #11 from Paolo Carlini 2012-08-22 20:56:01 UTC --- Nathan, shall we close this?
[Bug libstdc++/54352] relaxed data race rules for ~condition_variable_any
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54352 --- Comment #2 from Jonathan Wakely 2012-08-22 20:58:10 UTC --- (In reply to comment #1) > Created attachment 28066 [details] > patch against 4.8 trunk That patch needs some additional exports: _ZNSt16_Sp_counted_baseILN9__gnu_cxx12_Lock_policy*; _ZNKSt16_Sp_counted_baseILN9__gnu_cxx12_Lock_policy*; _ZT[ISV]St16_Sp_counted_baseILN9__gnu_cxx12_Lock_policyE2EE;
[Bug c++/33255] A warning for "unused" typedefs?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33255 Paolo Carlini changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC|gcc-bugs at gcc dot gnu.org | Resolution||FIXED Target Milestone|--- |4.8.0 --- Comment #29 from Paolo Carlini 2012-08-22 21:00:06 UTC --- I suppose we can close this, right? In case there are issues with the implementation, belong to new, separate PRs.
[Bug target/53291] Code generated for xtest is wrong
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53291 --- Comment #11 from eraman at gcc dot gnu.org 2012-08-22 21:07:39 UTC --- Author: eraman Date: Wed Aug 22 21:07:30 2012 New Revision: 190601 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190601 Log: 2012-08-22 Easwaran Raman Backport r187387 and r187477 from trunk. r187387: 2012-05-11 Uros Bizjak PR target/53291 * config/i386/i386.md (xtest): Use NE condition in ix86_expand_setcc. r187477: 2012-05-14 Andrew Pinski H.J. Lu Jakub Jelinek PR target/53315 * config/i386/i386.md (xbegin_1): Use + in constraint and match_dup. (xbegin): Updated. gcc/testsuite/ChangeLog.google-4_7: 2012-08-22 Easwaran Raman Backport r187477 from trunk: 2012-05-14 Andi Kleen Jakub Jelinek PR target/53315 * gcc.target/i386/i386.exp (check_effective_target_rtm): New. * gcc.target/i386/rtm-check.h: New file. * gcc.target/i386/pr53315.c: New test. Added: branches/google/gcc-4_7/gcc/testsuite/gcc.target/i386/pr53315.c - copied unchanged from r187477, trunk/gcc/testsuite/gcc.target/i386/pr53315.c branches/google/gcc-4_7/gcc/testsuite/gcc.target/i386/rtm-check.h - copied unchanged from r187477, trunk/gcc/testsuite/gcc.target/i386/rtm-check.h Modified: branches/google/gcc-4_7/gcc/ChangeLog.google-4_7 branches/google/gcc-4_7/gcc/config/i386/i386.md branches/google/gcc-4_7/gcc/testsuite/ChangeLog.google-4_7 branches/google/gcc-4_7/gcc/testsuite/gcc.target/i386/i386.exp
[Bug target/53315] simple xtest program generates ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53315 --- Comment #19 from eraman at gcc dot gnu.org 2012-08-22 21:07:40 UTC --- Author: eraman Date: Wed Aug 22 21:07:30 2012 New Revision: 190601 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190601 Log: 2012-08-22 Easwaran Raman Backport r187387 and r187477 from trunk. r187387: 2012-05-11 Uros Bizjak PR target/53291 * config/i386/i386.md (xtest): Use NE condition in ix86_expand_setcc. r187477: 2012-05-14 Andrew Pinski H.J. Lu Jakub Jelinek PR target/53315 * config/i386/i386.md (xbegin_1): Use + in constraint and match_dup. (xbegin): Updated. gcc/testsuite/ChangeLog.google-4_7: 2012-08-22 Easwaran Raman Backport r187477 from trunk: 2012-05-14 Andi Kleen Jakub Jelinek PR target/53315 * gcc.target/i386/i386.exp (check_effective_target_rtm): New. * gcc.target/i386/rtm-check.h: New file. * gcc.target/i386/pr53315.c: New test. Added: branches/google/gcc-4_7/gcc/testsuite/gcc.target/i386/pr53315.c - copied unchanged from r187477, trunk/gcc/testsuite/gcc.target/i386/pr53315.c branches/google/gcc-4_7/gcc/testsuite/gcc.target/i386/rtm-check.h - copied unchanged from r187477, trunk/gcc/testsuite/gcc.target/i386/rtm-check.h Modified: branches/google/gcc-4_7/gcc/ChangeLog.google-4_7 branches/google/gcc-4_7/gcc/config/i386/i386.md branches/google/gcc-4_7/gcc/testsuite/ChangeLog.google-4_7 branches/google/gcc-4_7/gcc/testsuite/gcc.target/i386/i386.exp
[Bug middle-end/53695] [4.8 Regression] ICE: in dfs_enumerate_from, at cfganal.c:1221 with -O2 -ftracer and labels/gotos
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53695 --- Comment #9 from Steven Bosscher 2012-08-22 21:33:18 UTC --- I think the right fix for this bug is to use disambiguate_multiple_latches in the loop updating code (fix_loop_structure), but I'm not sure where to put it.
[Bug rtl-optimization/54342] [4.8 Regression] Wrong mode of call argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54342 Uros Bizjak changed: What|Removed |Added CC||hjl.tools at gmail dot com --- Comment #4 from Uros Bizjak 2012-08-22 22:01:52 UTC --- I believe that OImode is currently handled inconsistently in the compiler, and should be handled exactly in the way TImode is handled for xmm registers. There are some examples: -function_pass_avx256_p: OImode is handled together with VALID_AVX256_REG_MODE in parallels, but not in registers. -construct_container: OImode is created for container member -ix86_hard_regno_mode_ok: OImode is handled together with VALID_AVX256_REG_MODE. I think that OImode should be a member of VALID_AVX256_REG_MODE.
[Bug rtl-optimization/54342] [4.8 Regression] Wrong mode of call argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54342 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2012-08-22 Ever Confirmed|0 |1 --- Comment #5 from H.J. Lu 2012-08-22 22:08:54 UTC --- Is an ABI issue? Why isn't shown up in gcc.target/x86_64/abi/avx tests?
[Bug rtl-optimization/54342] [4.8 Regression] Wrong mode of call argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54342 --- Comment #6 from H.J. Lu 2012-08-22 22:10:51 UTC --- This may be related to PR 54315.
[Bug rtl-optimization/54342] [4.8 Regression] Wrong mode of call argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54342
--- Comment #7 from Uros Bizjak 2012-08-22 22:26:22
UTC ---
Please note that there is currently no way to generate OImode directly:
$ more oi.c
typedef int OItype __attribute__ ((mode (OI)));
OItype test (OItype a)
{
return a;
}
$ gcc -O2 -mavx oi.c
oi.c:1:1: error: unable to emulate ‘OI’
[Bug target/54089] [SH] Refactor shift patterns
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089 --- Comment #15 from Oleg Endo 2012-08-22 22:52:25 UTC --- Author: olegendo Date: Wed Aug 22 22:52:17 2012 New Revision: 190603 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190603 Log: PR target/54089 * config/sh/predicates (p27_rshift_count_operand, not_p27_rshift_count_operand): New predicates. * config/sh/sh.c (sh_ashlsi_clobbers_t_reg_p, sh_lshrsi_clobbers_t_reg_p, sh_dynamicalize_shift_p): Handle special case when shift amount is 31. (gen_ashift): Emit gen_shlr instead of gen_lshrsi3_m. * config/sh/sh.md (ashlsi3_d): Set type to 'dyn_shift' instead of 'arith'. (ashlsi_c): Rename to shll. Adapt calls to gen_ashlsi_c throughout the file. (lshrsi3): Remove clobber from expander. Use shift_count_operand instead of nonmemory_operand predicate for second operand. Add handling of case lshrsi3_n_clobbers_t. (lshrsi3_k): Use p27_rshift_count_operand for second operand. (lshrsi3_d): Make insn_and_split. Split dynamic shift to constant shift sequences if beneficial. (lshrsi3_n): Make insn_and_split. Split constant shift sequence to dynamic shift if beneficial. (lshrsi3_n_clobbers_t): New insn_and_split. (lshrsi3_m): Delete. PR target/54089 * gcc.target/sh/pr54089-2.c: New. Added: trunk/gcc/testsuite/gcc.target/sh/pr54089-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/sh/predicates.md trunk/gcc/config/sh/sh.c trunk/gcc/config/sh/sh.md trunk/gcc/testsuite/ChangeLog
[Bug middle-end/52939] [4.7/4.8 Regression] ice in gimple_get_virt_method_for_binfo with -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52939 Bryce Lelbach (wash) changed: What|Removed |Added CC||blelbach at cct dot lsu.edu --- Comment #9 from Bryce Lelbach (wash) 2012-08-22 23:52:55 UTC --- Is the fix for this in a released version of GCC?
[Bug libstdc++/54354] New: TODO extended iomanip manipulators std::get_time and std::put_time (C++11, section 27.7.5)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54354 Bug #: 54354 Summary: TODO extended iomanip manipulators std::get_time and std::put_time (C++11, section 27.7.5) Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: libstdc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: facorr...@gmail.com Hello, keep up the great work with GCC. I wanted to bring to your attention that the extended manipulators std::get_time and std::put_time have not been declared (C++11, section 27.7.5). I checked iomanip at http://repo.or.cz/w/official-gcc.git/blob_plain/HEAD:/libstdc%2B%2B-v3/include/std/iomanip For the time being, you might want to put a notice about the lack of these two manipulators in http://gcc.gnu.org/onlinedocs/libstdc++/manual/status.html#iso.2011.specific
[Bug rtl-optimization/54342] [4.8 Regression] Wrong mode of call argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54342 --- Comment #8 from H.J. Lu 2012-08-23 04:04:36 UTC --- I don't think AVX supports true 256-bit integer. On the other hand, I was also puzzled by compute_record_mode, which excludes UNION_TYPE and QUAL_UNION_TYPE. Will including them break union?
