[Bug testsuite/51645] FAIL: g++.dg/cpp0x/alias-decl-debug-0.C (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51645 --- Comment #2 from uros at gcc dot gnu.org 2011-12-22 08:16:26 UTC --- Author: uros Date: Thu Dec 22 08:16:12 2011 New Revision: 182615 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=182615 Log: PR testsuite/51645 * g++.dg/cpp0x/alias-decl-debug-0.C: Add dg-skip-if. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/cpp0x/alias-decl-debug-0.C
[Bug testsuite/51645] FAIL: g++.dg/cpp0x/alias-decl-debug-0.C (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51645 Uros Bizjak ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED URL||http://gcc.gnu.org/ml/gcc-p ||atches/2011-12/msg01601.htm ||l Resolution||FIXED Target Milestone|--- |4.7.0 --- Comment #3 from Uros Bizjak ubizjak at gmail dot com 2011-12-22 08:20:11 UTC --- Fixed.
[Bug fortran/51652] [F03] ICE with allocatable scalarstype parameter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51652 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Keywords||accepts-invalid, ||diagnostic, wrong-code CC||burnus at gcc dot gnu.org Summary|[F03] ICE with allocatable |[F03] ICE with allocatable |scalars |scalarstype parameter --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2011-12-22 08:40:10 UTC --- (In reply to comment #0) type keyword ! character(60), allocatable :: c(:) ! works but should it? ! character(80), allocatable :: c(:) ! works character(:), allocatable :: c(:) end type keyword Unfortunately, deferred-length type parameters (i.e. allocatable string lengths) are not yet supported for components of derived types. The current version does not crash (ICE, internal compiler error) but prints an error: character(:), allocatable :: c(:) 1 Error: Deferred-length character component 'c' at (1) is not yet supported As this is already tracked in PR 51550, PR 47545, PR 49050, PR 51075 - and PR 45170, I ignore the issue in this PR and concentrate on your second issue. * * * Regarding the allocation: character(60), allocatable :: c(:) allocate(character(80) :: c(10)) That's invalid; currently, the value in the allocate statement is ignored by gfortran. The standard requires that this is diagnosed: If type-spec appears and the value of a type parameter it specifies differs from the value of the corresponding nondeferred type parameter specified in the declaration of any allocate-object, an error condition occurs. If the value of a nondeferred length type parameter of an allocate-object differs from the value of the corresponding type parameter of source-expr, an error condition occurs. Note that this cannot always diagnosed at compile time, given that also the following is valid: subroutine sub(n) integer :: n character(len=n), allocatable :: str(:) allocate(character(n) :: str(1)) print *, len(str), size(str) end call sub(4) call sub(5) end
[Bug fortran/51652] Allocate with type-spec and source-expr: check whether length type-parameter is the same is lacking
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51652 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Summary|[F03] ICE with allocatable |Allocate with type-spec and |scalarstype parameter |source-expr: check whether ||length type-parameter is ||the same is lacking --- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org 2011-12-22 08:44:08 UTC --- (In reply to comment #1) If the value of a nondeferred length type parameter of an allocate-object differs from the value of the corresponding type parameter of source-expr, an error condition occurs. The postscripts: Remember that source-expr covers both SOURCE= and MOLD=. And I forgot to mention that the source of the quote: Fortran 2008, 6.7.1 ALLOCATE statement, paragraph 6.
[Bug lto/51635] [4.7 regression] ICE in in dwarf2out_finish, at dwarf2out.c:22494 when building Firefox's libxul
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51635
--- Comment #25 from Markus Trippelsdorf markus at trippelsdorf dot de
2011-12-22 09:48:27 UTC ---
(In reply to comment #23)
Another fun (well ...) patch that is worth trying is
Index: gcc/gimple.c
===
--- gcc/gimple.c(revision 182590)
+++ gcc/gimple.c(working copy)
@@ -4488,16 +4488,7 @@ gimple_register_type_1 (tree t, bool reg
tree
gimple_register_type (tree t)
{
- gcc_assert (TYPE_P (t));
-
- if (!gimple_type_leader)
-gimple_type_leader = ggc_alloc_cleared_vec_gimple_type_leader_entry_s
- (GIMPLE_TYPE_LEADER_SIZE);
-
- if (gimple_types == NULL)
-gimple_types = htab_create_ggc (16381, gimple_type_hash, gimple_type_eq,
0);
-
- return gimple_register_type_1 (t, false);
+ return t;
}
/* The TYPE_CANONICAL merging machinery. It should closely resemble
where you need to configure with --disable-werror (because of now unused
functions in gimple.c). The above will simply disable all type merging
and thus may in theory increase memory usage a lot (I think so more for
ltrans stage than wpa stage, it also may increase ltrans file size a lot).
It also probably increases the size of the emitted debug information.
Not really feasible:
13.5 minutes CPU-time, 7.5GB RAM used, 6.3GB ltrans files
(and then lto1 on the individual partitions also takes ~2min per instance)
88.80% lto1 [.] lto_read_decls
0.51% lto1 [.] htab_expand
0.42% libz.so.1.2.5.1[.] inflate_fast
0.35% lto1 [.] htab_find_slot_with_hash
0.30% lto1 [.] gimple_canonical_types_compatible_p
[Bug rtl-optimization/27468] sign-extending Alpha instructions not exploited
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27468 Uros Bizjak ubizjak at gmail dot com changed: What|Removed |Added Status|NEW |ASSIGNED URL||http://gcc.gnu.org/ml/gcc-p ||atches/2011-12/msg01606.htm ||l AssignedTo|unassigned at gcc dot |ubizjak at gmail dot com |gnu.org | Target Milestone|--- |4.7.0 --- Comment #4 from Uros Bizjak ubizjak at gmail dot com 2011-12-22 10:14:44 UTC --- Patch at [1]. [1] http://gcc.gnu.org/ml/gcc-patches/2011-12/msg01606.html
[Bug rtl-optimization/27468] sign-extending Alpha instructions not exploited
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27468 --- Comment #5 from Uros Bizjak ubizjak at gmail dot com 2011-12-22 10:25:10 UTC --- With proposed patch to enable REE pass, we still generate: f5: 0: 20 05 f0 43 negqa0,v0 4: c0 08 10 46 cmovge a0,a0,v0 8: 00 00 e0 43 sextl v0,v0 c: 01 80 fa 6b ret However, we need a sign extend somewhere, and in above case, we apply sign extension to the result, where Compaq C applies extension to the arguments of cmove. These sequences are equivalent an all aspects. FYI: Proposed optimal f5 sequence is wrong. Since cmov always operates on the whole DImode register, garbage in bits 31+ of a0 can pass unmodified to the function result. Compaq C is correct to produce: f5: 0:10 00 f0 43 sextla0,a0 4:20 01 f0 43 negla0,v0 8:c0 08 10 46 cmovgea0,a0,v0 c:00 00 fe 2f unop 10:01 80 fa 6b ret but this is effectively no different than gcc sequence above.
[Bug c++/39658] [C++0x] wrong number of template arguments in variadic template specialization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39658 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com 2011-12-22 11:10:39 UTC --- Ah thanks for noticing. Thus this is at most a diagnostic issue. But in fact, modulo the - well known - benefits of the caret, EDG for example is providing a very similar diagnostics. I think we can close this.
[Bug debug/51650] [4.7 regression] LTO ICE in dwarf2out_finish, at dwarf2out.c:22501 while building libxul
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51650 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011-12-22 Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-12-22 11:28:57 UTC --- Mine.
[Bug debug/51650] [4.7 regression] LTO ICE in dwarf2out_finish, at dwarf2out.c:22501 while building libxul
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51650
--- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2011-12-22
11:44:04 UTC ---
Reduced testcase:
struct T;
class C
{
public:
typedef ::T T;
static T *m ()
{
static T *d;
return d;
}
};
int
fn ()
{
C::m ();
}
int main() {}
[Bug debug/51650] [4.7 regression] LTO ICE in dwarf2out_finish, at dwarf2out.c:22501 while building libxul
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51650 --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2011-12-22 12:00:27 UTC --- In non-LTO mode we create the DIE for 'C' (which we do not create at all with -flto) via #3 0x00d54c57 in rest_of_type_compilation (type=0x75b8f3f0, toplev=1) at /space/rguenther/src/svn/trunk/gcc/passes.c:238 238 debug_hooks-type_decl (TYPE_STUB_DECL (type), !toplev); we do not do something equivalent for LTO (but LTO expects to have those DIEs created lazily ...). But dwarf2out isn't prepared to deal with this situation it seems :/ I'm not sure we want to add corresponding debug_hooks calls to the LTO machinery, but if, then one place to do that would be here: Index: gcc/lto/lto.c === --- gcc/lto/lto.c (revision 182617) +++ gcc/lto/lto.c (working copy) @@ -881,6 +881,8 @@ uniquify_nodes (struct data_in *data_in, lto_register_var_decl_in_symtab (data_in, t); else if (TREE_CODE (t) == FUNCTION_DECL !DECL_BUILT_IN (t)) lto_register_function_decl_in_symtab (data_in, t); + else if (!flag_wpa TREE_CODE (t) == TYPE_DECL) + debug_hooks-type_decl (t, DECL_FILE_SCOPE_P (t)); else if (TYPE_P (t) !TYPE_CANONICAL (t)) TYPE_CANONICAL (t) = gimple_register_canonical_type (t); } but I'm not sure we won't confuse dwarf2out.c with the order we are calling type_decl () either (might be we start with T, and then the one for its context C). The above patch fixes the reduced testcase at least. Markus, can you give it a shot?
[Bug libstdc++/51653] New: More compact std::tuple
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51653 Bug #: 51653 Summary: More compact std::tuple Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: libstdc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: marc.gli...@normalesup.org Created attachment 26166 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26166 proof of concept Hello, as a low priority enhancement possibility, I think it would be nice if std::tuple was more compact. This would allow people to just use tuplefield1, field2,field3 instead of having to think about the likelihood of the size of each field to get a good layout. For instance, sizeof(tuplechar,int,char) could be 2*sizeof(int) (on platforms where sizeof(int)1) instead of the current 3*sizeof(int) by reordering internally as int,char,char. Empty fields could all be moved to the beginning to avoid problems with tupleEmpty,Empty,int having size 2*sizeof(int) (an ABI weirdness). Independently, derivation could be used more often for _Head_base (not final and not virtual? more restrictions?) so that tuplechar,tuplechar,int has only size 2*sizeof(int) (note that this kind of compression won't happen for POD). The main drawback is that it will complicate code. In many cases, tuple is just used as an intermediate (forward_as_tuple followed by get) and we don't care about the tuple layout, so it would needlessly slow down compilation and, as any complication, it might hinder some flaky optimizations. There are 2 main ways to implement this. - a compiler intrinsic could be created that asks the compiler to reorder bases for a dense layout (suggested by Jonathan Wakely). Note that this is not pragma pack, as things should remain properly aligned. - a pure library solution is possible too. I am attaching a proof of concept. I know my code tends to be unreadable, but it shows that, taking out the ordering function, the remaining tuple code can be fairly simple (mytuple__ is 6 lines, the body of myget is 1 line, and the rest is implemented on top without needing to know how the basis is implemented). Obviously I didn't implement the whole interface.
[Bug libstdc++/48362] pretty printer fails for zero-size std::tuple
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48362 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2011-12-22 12:33:27 UTC --- Author: redi Date: Thu Dec 22 12:33:15 2011 New Revision: 182620 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=182620 Log: PR libstdc++/48362 * python/libstdcxx/v6/printers.py (StdTuplePrinter): Handle empty tuples. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/python/libstdcxx/v6/printers.py
[Bug libstdc++/48362] pretty printer fails for zero-size std::tuple
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48362 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.7.0 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2011-12-22 12:35:24 UTC --- fixed for 4.7
[Bug debug/51650] [4.7 regression] LTO ICE in dwarf2out_finish, at dwarf2out.c:22501 while building libxul
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51650 --- Comment #4 from Markus Trippelsdorf markus at trippelsdorf dot de 2011-12-22 12:51:08 UTC --- (In reply to comment #3) In non-LTO mode we create the DIE for 'C' (which we do not create at all with -flto) via #3 0x00d54c57 in rest_of_type_compilation (type=0x75b8f3f0, toplev=1) at /space/rguenther/src/svn/trunk/gcc/passes.c:238 238 debug_hooks-type_decl (TYPE_STUB_DECL (type), !toplev); we do not do something equivalent for LTO (but LTO expects to have those DIEs created lazily ...). But dwarf2out isn't prepared to deal with this situation it seems :/ I'm not sure we want to add corresponding debug_hooks calls to the LTO machinery, but if, then one place to do that would be here: Index: gcc/lto/lto.c === --- gcc/lto/lto.c (revision 182617) +++ gcc/lto/lto.c (working copy) @@ -881,6 +881,8 @@ uniquify_nodes (struct data_in *data_in, lto_register_var_decl_in_symtab (data_in, t); else if (TREE_CODE (t) == FUNCTION_DECL !DECL_BUILT_IN (t)) lto_register_function_decl_in_symtab (data_in, t); + else if (!flag_wpa TREE_CODE (t) == TYPE_DECL) + debug_hooks-type_decl (t, DECL_FILE_SCOPE_P (t)); else if (TYPE_P (t) !TYPE_CANONICAL (t)) TYPE_CANONICAL (t) = gimple_register_canonical_type (t); } but I'm not sure we won't confuse dwarf2out.c with the order we are calling type_decl () either (might be we start with T, and then the one for its context C). The above patch fixes the reduced testcase at least. Markus, can you give it a shot? libxul still fails to build with the same error message (but there is only one instance of this ICE now instead of three before your patch). Reducing...
[Bug target/29997] various targets: GCC fails to encode epilogues in unwind-info
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29997 --- Comment #4 from joseph at codesourcery dot com joseph at codesourcery dot com 2011-12-22 12:53:39 UTC --- On Thu, 22 Dec 2011, pinskia at gcc dot gnu.org wrote: I think we encode proligue and epilogues now for all targets. It's been done for several targets, but when looking recently I got the impression that it hadn't been done yet for SH, for example.
[Bug libstdc++/51653] More compact std::tuple
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51653 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2011-12-22 12:57:06 UTC --- Neat! Thanks for demonstrating this. I'm not yet convinced we want to apply it, but it's nice to know it can be done without *too* much trouble.
[Bug debug/51650] [4.7 regression] LTO ICE in dwarf2out_finish, at dwarf2out.c:22501 while building libxul
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51650 --- Comment #5 from Richard Guenther rguenth at gcc dot gnu.org 2011-12-22 13:10:44 UTC --- (In reply to comment #4) (In reply to comment #3) Markus, can you give it a shot? libxul still fails to build with the same error message (but there is only one instance of this ICE now instead of three before your patch). Reducing... Sorry that it's going slow ... I hope we can populate the testsuite with some more decent -flto -g coverage.
[Bug debug/51650] [4.7 regression] LTO ICE in dwarf2out_finish, at dwarf2out.c:22501 while building libxul
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51650
--- Comment #6 from Markus Trippelsdorf markus at trippelsdorf dot de
2011-12-22 13:17:46 UTC ---
% cat test.ii
typedef struct { } X;
void test ()
{
typedef X **P;
P g = 0;
}
% g++ test.ii -g -flto -flto-partition=none
lto1: internal compiler error: in dwarf2out_finish, at dwarf2out.c:22501
(Will try to reduce again without -flto-partition=none)
[Bug debug/51650] [4.7 regression] LTO ICE in dwarf2out_finish, at dwarf2out.c:22501 while building libxul
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51650
--- Comment #7 from Markus Trippelsdorf markus at trippelsdorf dot de
2011-12-22 13:26:26 UTC ---
(In reply to comment #6)
% cat test.ii
typedef struct { } X;
void test ()
{
typedef X **P;
P g = 0;
}
% g++ test.ii -g -flto -flto-partition=none
lto1: internal compiler error: in dwarf2out_finish, at dwarf2out.c:22501
(Will try to reduce again without -flto-partition=none)
Not necessary:
% g++ -r- g -flto test.ii
lto1: internal compiler error: in dwarf2out_finish, at dwarf2out.c:22501
[Bug debug/51650] [4.7 regression] LTO ICE in dwarf2out_finish, at dwarf2out.c:22501 while building libxul
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51650 --- Comment #8 from Richard Guenther rguenth at gcc dot gnu.org 2011-12-22 13:34:15 UTC --- Oops, typo - it should be else if (!flag_wpa TREE_CODE (t) == TYPE_DECL) debug_hooks-type_decl (t, !DECL_FILE_SCOPE_P (t)); (note the negation before the predicate).
[Bug c++/51413] Broken diagnostic with __builtin_offsetof
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51413 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011-12-22 AssignedTo|unassigned at gcc dot |paolo.carlini at oracle dot |gnu.org |com Ever Confirmed|0 |1 --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2011-12-22 13:43:34 UTC --- On it.
[Bug target/51643] Incorrect code produced for tail-call of weak function with -O2/-O3 option
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51643 Richard Earnshaw rearnsha at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011-12-22 Ever Confirmed|0 |1
[Bug target/51643] Incorrect code produced for tail-call of weak function with -O2/-O3 option
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51643 --- Comment #8 from Richard Earnshaw rearnsha at gcc dot gnu.org 2011-12-22 14:13:16 UTC --- Author: rearnsha Date: Thu Dec 22 14:13:09 2011 New Revision: 182621 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=182621 Log: PR target/51643 * arm.c (arm_function_ok_for_sibcall): Don't try to tailcall a weak function on bare-metal EABI targets. * gcc.target/arm/sibcall-2.c: New test. Added: trunk/gcc/testsuite/gcc.target/arm/sibcall-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm.c trunk/gcc/testsuite/ChangeLog
[Bug target/51643] Incorrect code produced for tail-call of weak function with -O2/-O3 option
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51643 --- Comment #9 from Richard Earnshaw rearnsha at gcc dot gnu.org 2011-12-22 14:28:45 UTC --- Author: rearnsha Date: Thu Dec 22 14:28:39 2011 New Revision: 182622 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=182622 Log: PR target/51643 * arm.c (arm_function_ok_for_sibcall): Don't try to tailcall a weak function on bare-metal EABI targets. * gcc.target/arm/sibcall-2.c: New test. Added: branches/gcc-4_6-branch/gcc/testsuite/gcc.target/arm/sibcall-2.c Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/config/arm/arm.c branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
[Bug target/51643] Incorrect code produced for tail-call of weak function with -O2/-O3 option
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51643 Richard Earnshaw rearnsha at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Version|4.6.2 |4.6.3 Resolution||FIXED --- Comment #10 from Richard Earnshaw rearnsha at gcc dot gnu.org 2011-12-22 14:29:54 UTC --- Fixed on 4.6 and trunk.
[Bug rtl-optimization/50396] SSE division by zero generates incorrect code with optimizations enabled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50396 Mathias Gaunard loufoque at gmail dot com changed: What|Removed |Added CC||loufoque at gmail dot com --- Comment #4 from Mathias Gaunard loufoque at gmail dot com 2011-12-22 15:01:02 UTC --- What's missing to get this fixed? Previous comment suggests the fix is trivial.
[Bug target/51654] New: C++ preprocessor bug with -maltivec and typedefs involving 'vector'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51654
Bug #: 51654
Summary: C++ preprocessor bug with -maltivec and typedefs
involving 'vector'
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: math...@gaunard.com
The following C++ code
templateclass T
struct test
{
typedef T::vector vector;
};
when preprocessed using the following command
g++ -maltivec -E test.cpp
generates the following output:
templateclass T
struct test
{
typedef T::vector;
};
Expected output should be the file unchanged.
In particular, this prevents from using significant parts of the Boost C++
libraries with AltiVec enabled.
I'm not sure which is the best place to affect this bug (c++, preprocessor,
target), feel free to move it.
Affecting to target because it seems similar to bug #39558.
[Bug rtl-optimization/50396] SSE division by zero generates incorrect code with optimizations enabled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50396 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | --- Comment #5 from Richard Guenther rguenth at gcc dot gnu.org 2011-12-22 15:14:32 UTC --- Sorry, forgot about this issue.
[Bug target/51654] C++ preprocessor bug with -maltivec and typedefs involving 'vector'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51654
--- Comment #1 from Mathias Gaunard mathias at gaunard dot com 2011-12-22
15:16:18 UTC ---
Excuse the typo, the above code should have been
templateclass T
struct test
{
typedef typename T::vector vector;
};
to be valid C++ code.
The vector bit is incorrectly removed in both cases though.
[Bug debug/51650] [4.7 regression] LTO ICE in dwarf2out_finish, at dwarf2out.c:22501 while building libxul
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51650 --- Comment #9 from Richard Guenther rguenth at gcc dot gnu.org 2011-12-22 15:28:32 UTC --- Author: rguenth Date: Thu Dec 22 15:28:24 2011 New Revision: 182625 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=182625 Log: 2011-12-22 Richard Guenther rguent...@suse.de PR lto/51650 * lto.c (uniquify_nodes): Register TYPE_DECLs with the debuginfo machinery. * g++.dg/lto/pr51650-1_0.C: New testcase. * g++.dg/lto/pr51650-2_0.C: Likewise. Added: trunk/gcc/testsuite/g++.dg/lto/pr51650-1_0.C trunk/gcc/testsuite/g++.dg/lto/pr51650-2_0.C Modified: trunk/gcc/ChangeLog trunk/gcc/lto/lto.c trunk/gcc/testsuite/ChangeLog
[Bug debug/51650] [4.7 regression] LTO ICE in dwarf2out_finish, at dwarf2out.c:22501 while building libxul
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51650 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #10 from Richard Guenther rguenth at gcc dot gnu.org 2011-12-22 15:32:06 UTC --- Fixed.
[Bug debug/51650] [4.7 regression] LTO ICE in dwarf2out_finish, at dwarf2out.c:22501 while building libxul
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51650 Markus Trippelsdorf markus at trippelsdorf dot de changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Comment #11 from Markus Trippelsdorf markus at trippelsdorf dot de 2011-12-22 15:33:55 UTC --- I still hit the same spot when building Firefox. delta is running...
[Bug target/51654] C++ preprocessor bug with -maltivec and typedefs involving 'vector'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51654 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2011-12-22 Ever Confirmed|0 |1 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2011-12-22 15:36:34 UTC --- you haven't said what version you're using http://gcc.gnu.org/bugs/
[Bug middle-end/51472] ICE: verify_gimple failed: invalid rhs for gimple memory store with -fgnu-tm --param tm-max-aggregate-size=32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51472 Uros Bizjak ubizjak at gmail dot com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Comment #6 from Uros Bizjak ubizjak at gmail dot com 2011-12-22 15:43:24 UTC --- (In reply to comment #5) fixed Not really... it still fails on alpha-linux-gnu and powerpc64-unknown-linux-gnu, although with a different error: pr51472.c: In function ‘foo’: pr51472.c:8:1: error: missing definition for SSA_NAME: v.0_2 in statement: # .MEM_9 = VDEF .MEM_6 D.1459 = v.0_2; pr51472.c:8:1: internal compiler error: verify_ssa failed (This can be also triggered from x86_64 - alpha cross.)
[Bug target/51654] C++ preprocessor bug with -maltivec and typedefs involving 'vector'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51654 --- Comment #3 from Mathias Gaunard mathias at gaunard dot com 2011-12-22 15:54:20 UTC --- The workarounds #undef vector or compiling with -Dvector=vector seem to work. But shouldn't this not be necessary when altivec.h is not included?
[Bug c++/51507] [C++0x] Function parameter pack doesn't use in template-argument-list
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51507 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011-12-22 CC||jason at gcc dot gnu.org AssignedTo|unassigned at gcc dot |jason at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1
[Bug target/48308] [4.6/4.7 Regression] crosscompiling to arm fails with assembler: can't resolve '.LC4' {.rodata.str1.1 section} - '.LPIC4' {*UND* section}
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48308
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #14 from Jakub Jelinek jakub at gcc dot gnu.org 2011-12-22
16:05:52 UTC ---
Note, can't be reproduced on the trunk, the strcmp isn't DCEd there, but guess
the problem is just latent there.
It looks like a target bug to me. Before RTL loop opts we have:
(insn 91 90 92 13 (set (reg:SI 167)
(unspec:SI [
(const:SI (unspec:SI [
(symbol_ref/v/f:SI (*.LC4) [flags 0x82]
var_decl 0x7f5ebb0a5500 *.LC4)
(const:SI (plus:SI (unspec:SI [
(const_int 4 [0x4])
] 21)
(const_int 8 [0x8])))
] 27))
] 3)) pr48308.i:228 170 {pic_load_addr_32bit}
(nil))
(insn 92 91 94 13 (set (reg:SI 167)
(unspec:SI [
(reg:SI 167)
(const_int 8 [0x8])
(const_int 4 [0x4])
] 4)) pr48308.i:228 173 {pic_add_dot_plus_eight}
(expr_list:REG_EQUAL (symbol_ref/v/f:SI (*.LC4) [flags 0x82] var_decl
0x7f5ebb0a5500 *.LC4)
(nil)))
and the pseudo 167 is then used to load one of the strcmp parameters.
Then (probably loop invariant motion) moves insn 91 before the loop, as it
looks to be loop invariant, but insn 92 is kept in the loop.
Next during RA, the register pressure is high and thus pseudo 167 is spilled,
so
before the loop there is a store. Then during the *.csa pass DCE is performed
and the strcmp is removed, which means insn 92 is removed as well, but the
store before the loop of course is kept. And there is no further DSE pass that
would optimize that (now dead) store away.
So, IMHO arm_reorg needs to handle this case, find out what minipool entries
don't have the corresponding UNSPEC_PIC_BASE insn and handle them somehow
(either by emitting there a dummy 0 or similar, or trying to replace the insn
with UNSPEC_PIC_SYM with something else, ...).
That said, perhaps it would be nice to help the loop optimizers somehow figure
out that even the UNSPEC_PIC_BASE is loop invariant (wrap it into CONST?).
[Bug target/48308] [4.6/4.7 Regression] crosscompiling to arm fails with assembler: can't resolve '.LC4' {.rodata.str1.1 section} - '.LPIC4' {*UND* section}
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48308 --- Comment #15 from Michael Hope michael.hope at linaro dot org 2011-12-22 16:07:46 UTC --- I'm away of holiday until the 4th of January. For anything urgent, please contact k...@linaro.org. -- Michael
[Bug fortran/51652] Allocate with type-spec and source-expr: check whether length type-parameter is the same is lacking
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51652 --- Comment #3 from David Kinniburgh davidgkinniburgh at yahoo dot co.uk 2011-12-22 16:21:09 UTC --- Sorry, I wasn't up-to-date on the long history of allocatable scalars and dt components, and hadn't checked the documentation in detail recently. Anyway thanks for all your work on this - I greatly appreciate your effort.
[Bug rtl-optimization/27468] sign-extending Alpha instructions not exploited
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27468 --- Comment #6 from uros at gcc dot gnu.org 2011-12-22 16:35:25 UTC --- Author: uros Date: Thu Dec 22 16:35:16 2011 New Revision: 182626 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=182626 Log: PR target/27468 * common/config/alpha/alpha-common.c (alpha_option_optimization_table): Enable flag_ree at -O2 or higher. Modified: trunk/gcc/ChangeLog trunk/gcc/common/config/alpha/alpha-common.c
[Bug rtl-optimization/27468] sign-extending Alpha instructions not exploited
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27468 Uros Bizjak ubizjak at gmail dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #7 from Uros Bizjak ubizjak at gmail dot com 2011-12-22 16:36:51 UTC --- Fixed.
[Bug testsuite/51655] New: FAIL: c-c++-common/tm/memcpy-1.c (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51655 Bug #: 51655 Summary: FAIL: c-c++-common/tm/memcpy-1.c (test for excess errors) Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassig...@gcc.gnu.org ReportedBy: domi...@lps.ens.fr CC: al...@redhat.com Host: x86_64-apple-darwin10 Target: x86_64-apple-darwin10 Build: x86_64-apple-darwin10 On x86_64-apple-darwin10 the test c-c++-common/tm/memcpy-1.c fails with FAIL: c-c++-common/tm/memcpy-1.c (test for excess errors) Excess errors: /opt/gcc/work/gcc/testsuite/c-c++-common/tm/memcpy-1.c:8:12: error: unsafe function call '__inline_memcpy_chk' within 'transaction_safe' function /opt/gcc/work/gcc/testsuite/c-c++-common/tm/memcpy-1.c:8:12: error: unsafe function call '__builtin___memcpy_chk' within 'transaction_safe' function /opt/gcc/work/gcc/testsuite/c-c++-common/tm/memcpy-1.c:8:12: error: unsafe function call '__builtin_object_size' within 'transaction_safe' function /opt/gcc/work/gcc/testsuite/c-c++-common/tm/memcpy-1.c:8:12: error: unsafe function call '__builtin_object_size' within 'transaction_safe' function I also see the failures reported in pr51124: Running target unix/-m32 FAIL: libitm.c/memcpy-1.c execution test FAIL: libitm.c/memset-1.c execution test WARNING: libitm.c++/static_ctor.C compilation failed to produce executable ... Running target unix/-m64 WARNING: libitm.c++/static_ctor.C compilation failed to produce executable due to libitm: pr_undoLogCode not supported FAIL: libitm.c/memcpy-1.c execution test ... libitm: pr_undoLogCode not supported FAIL: libitm.c/memset-1.c execution test ... XFAIL: libitm.c++/static_ctor.C (test for excess errors) Excess errors: /opt/gcc/work/libitm/testsuite/libitm.c++/static_ctor.C:12:18: error: unsafe function call 'void __cxa_guard_release(long long int*)' within 'transaction_safe' function /opt/gcc/work/libitm/testsuite/libitm.c++/static_ctor.C:12:18: error: unsafe function call 'int __cxa_guard_acquire(long long int*)' within 'transaction_safe' function
[Bug target/51643] Incorrect code produced for tail-call of weak function with -O2/-O3 option
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51643 --- Comment #11 from Richard Earnshaw rearnsha at gcc dot gnu.org 2011-12-22 17:31:58 UTC --- Author: rearnsha Date: Thu Dec 22 17:31:50 2011 New Revision: 182628 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=182628 Log: PR target/51643 * arm.c (arm_function_ok_for_sibcall): Use DECL_WEAK in previous change. Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm.c
[Bug target/51643] Incorrect code produced for tail-call of weak function with -O2/-O3 option
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51643 --- Comment #12 from Richard Earnshaw rearnsha at gcc dot gnu.org 2011-12-22 17:33:04 UTC --- Author: rearnsha Date: Thu Dec 22 17:32:58 2011 New Revision: 182629 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=182629 Log: PR target/51643 * arm.c (arm_function_ok_for_sibcall): Use DECL_WEAK in previous change. Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/config/arm/arm.c
[Bug target/47643] x86 -mtune docs still imply i386 is the default for codegen
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47643 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2011-12-22 17:35:14 UTC --- Author: redi Date: Thu Dec 22 17:35:05 2011 New Revision: 182630 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=182630 Log: PR target/47643 * doc/invoke.texi (i386 and x86-64 Options): Fix description of -mtune without -march. Modified: trunk/gcc/ChangeLog trunk/gcc/doc/invoke.texi
[Bug target/47643] x86 -mtune docs still imply i386 is the default for codegen
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47643 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.7.0 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2011-12-22 17:36:14 UTC --- fixed on trunk
[Bug c++/24986] g++ is confused when function is defined inside and outside some namespace and called with '::' prefix
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24986 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC|gcc-bugs at gcc dot gnu.org | Resolution||INVALID --- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com 2011-12-22 18:15:19 UTC --- Closing.
[Bug target/51654] C++ preprocessor bug with -maltivec and typedefs involving 'vector'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51654 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Target||powerpc*-*-* --- Comment #4 from Andrew Pinski pinskia at gcc dot gnu.org 2011-12-22 18:43:37 UTC --- Can you provide the output of gcc -v?
[Bug debug/51650] [4.7 regression] LTO ICE in dwarf2out_finish, at dwarf2out.c:22501 while building libxul
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51650
--- Comment #12 from Markus Trippelsdorf markus at trippelsdorf dot de
2011-12-22 18:45:24 UTC ---
% cat pr51650.ii
class nsQueryFrame
{
};
struct PLDHashEntryHdr {
};
template class class nsPtrHashKey:PLDHashEntryHdr
{
};
class nsIFrame;
namespace mozilla
{
struct FramePropertyDescriptor {
};
class FramePropertyTable
{
public:
FramePropertyTable ():mLastFrame (), mLastEntry () {
}
void *Get (nsIFrame *, FramePropertyDescriptor *, bool *);
class Entry:nsPtrHashKey nsIFrame
{
};
nsIFrame *mLastFrame;
Entry *mLastEntry;
};
class FrameProperties
{
public:
FrameProperties ():mTable (), mFrame () {
}
void *Get (FramePropertyDescriptor * aProperty) {
mTable-Get (0, aProperty, 0);
}
FramePropertyTable *mTable;
nsIFrame *mFrame;
};
}
class nsFrameList;
class nsIFrame:nsQueryFrame
{
public:
typedef mozilla::FramePropertyDescriptor FramePropertyDescriptor;
typedef mozilla::FrameProperties FrameProperties;
virtual nsFrameList GetChildList ();
FrameProperties Properties () {
}
static FramePropertyDescriptor *EmbeddingLevelProperty () {
static FramePropertyDescriptor descriptor;
return descriptor;
}
};
void
nsCaretGetCaretFrameForNodeOffset ()
{
nsIFrame *theFrame;
theFrame-Properties ().Get (nsIFrame::EmbeddingLevelProperty ());
}
% g++ -r -nostdlib -g -flto -O1 pr51650.ii
lto1: internal compiler error: in dwarf2out_finish, at dwarf2out.c:22501
Please submit a full bug report,
with preprocessed source if appropriate.
[Bug libstdc++/50982] AIX libstdc++ GTHREADS incompatibility
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50982 --- Comment #49 from David Edelsohn dje at gcc dot gnu.org 2011-12-22 18:46:20 UTC --- libstdc++ testsuite does not appear to run 30_ thread tests on AIX. What controls this? The testsuite probably assumes that it is testing single-threaded multilib.
[Bug target/51654] C++ preprocessor bug with -maltivec and typedefs involving 'vector'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51654 --- Comment #5 from Mathias Gaunard mathias at gaunard dot com 2011-12-22 18:48:36 UTC --- gaunard@emeria:~$ g++-4.6 -v Using built-in specs. COLLECT_GCC=g++-4.6 COLLECT_LTO_WRAPPER=/usr/lib/gcc/powerpc-linux-gnu/4.6.0/lto-wrapper Target: powerpc-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.6-20101220-1' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-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.6 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-plugin --enable-gold --enable-ld=default --with-plugin-ld=ld.gold --enable-objc-gc --enable-secureplt --disable-softfloat --enable-targets=powerpc-linux,powerpc64-linux --with-cpu=default32 --disable-werror --with-long-double-128 --enable-checking=release --build=powerpc-linux-gnu --host=powerpc-linux-gnu --target=powerpc-linux-gnu Thread model: posix gcc version 4.6.0 20101220 (experimental) [trunk revision 168097] (Ubuntu/Linaro 4.6-20101220-1)
[Bug libstdc++/48362] pretty printer fails for zero-size std::tuple
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48362 --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org 2011-12-22 18:58:20 UTC --- Author: redi Date: Thu Dec 22 18:58:15 2011 New Revision: 182632 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=182632 Log: PR libstdc++/48362 * testsuite/libstdc++-prettyprinters/48362.cc: New. Added: trunk/libstdc++-v3/testsuite/libstdc++-prettyprinters/48362.cc Modified: trunk/libstdc++-v3/ChangeLog
[Bug libstdc++/50982] AIX libstdc++ GTHREADS incompatibility
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50982
--- Comment #50 from Jonathan Wakely redi at gcc dot gnu.org 2011-12-22
19:03:02 UTC ---
Those tests have a target selector, which doesn't include AIX:
{ target *-*-freebsd* *-*-netbsd* *-*-linux* *-*-solaris* *-*-cygwin
*-*-darwin* alpha*-*-osf* mips-sgi-irix6* }
So I should have realised they wouldn't run.
Ideally we'd add AIX to all those files but I imagine not all of them will
pass, so it would have to be removed again for the ones that fail, if the
failure isn't something easily fixable
[Bug debug/51650] [4.7 regression] LTO ICE in dwarf2out_finish, at dwarf2out.c:22501 while building libxul
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51650
--- Comment #13 from Markus Trippelsdorf markus at trippelsdorf dot de
2011-12-22 19:14:38 UTC ---
Reduced (it almost identical to the first testcase):
struct T;
class C
{
public:
typedef ::T T;
virtual void E();
static T *m ()
{
static T *d;
return d;
}
};
int
fn ()
{
C::m ();
}
int main() {}
[Bug fortran/51310] -finit-bla doesn't initialize *all* items of type bla to the requested constant.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51310 --- Comment #8 from toon at gcc dot gnu.org 2011-12-22 19:23:31 UTC --- Author: toon Date: Thu Dec 22 19:23:26 2011 New Revision: 182634 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=182634 Log: 2011-12-22 Toon Moene t...@moene.org PR fortran/51310 * resolve.c (build_default_init_expr): Allow non-allocatable, non-compile-time-constant-shape arrays to have a default initializer. * invoke.texi: Delete the restriction on automatic arrays not being initialized by -finit-type=constant. Modified: branches/gcc-4_6-branch/gcc/fortran/ChangeLog branches/gcc-4_6-branch/gcc/fortran/invoke.texi branches/gcc-4_6-branch/gcc/fortran/resolve.c
[Bug middle-end/51212] ICE: verify_flow_info failed: BB 3 can not throw but has an EH edge with -fgnu-tm -fnon-call-exceptions and transaction_callable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51212 --- Comment #4 from Aldy Hernandez aldyh at gcc dot gnu.org 2011-12-22 20:18:20 UTC --- Author: aldyh Date: Thu Dec 22 20:18:11 2011 New Revision: 182636 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=182636 Log: PR middle-end/51212 * opts.c (finish_options): Call sorry on -fgnu-tm and -fnon-call-exceptions combination. Added: trunk/gcc/testsuite/g++.dg/tm/pr51212.C Modified: trunk/gcc/ChangeLog trunk/gcc/opts.c
[Bug middle-end/51212] ICE: verify_flow_info failed: BB 3 can not throw but has an EH edge with -fgnu-tm -fnon-call-exceptions and transaction_callable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51212 Aldy Hernandez aldyh at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #5 from Aldy Hernandez aldyh at gcc dot gnu.org 2011-12-22 20:19:24 UTC --- fixed
[Bug c/51656] New: C front end and strtold handle hexadecimal floating differently
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51656
Bug #: 51656
Summary: C front end and strtold handle hexadecimal floating
differently
Classification: Unclassified
Product: gcc
Version: 4.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: exponent-b...@yandex.ru
Consider this program:
#include stdlib.h
#include stdio.h
long double f;
int main(void)
{
f = 0x9.1a1c9420419a1a08p0L;
printf(%.15La\n, f);
f = strtold(0x9.1a1c9420419a1a08p0, NULL);
printf(%.15La\n, f);
return EXIT_SUCCESS;
}
That program prints:
0x9.1a1c9420419a1a0p+0
0x9.1a1c9420419a1a1p+0
Note the difference in the last mantissas' digits. I believe that difference
can be considered a bug by at least two reasons: 1) the strtold() function
seems to be rounding hexadecimals by rules that don't match neither of the
standard rounding mode (including the to-nearest mode for which it should
return 0x9.1a1c9420419a1a0p+0) and 2) that difference breaks user's
expectations in that these two ways of acquiring floating-point values should
behave identically under the same rounding mode.
Command-line options used:
gcc --float-store -g -O0 -o test test.c
Compiler version:
gcc-4.4.real (Ubuntu 4.4.3-4ubuntu5) 4.4.3
Host and target platforms:
32-bit x86 system
[Bug libfortran/51646] Make libgfortran compile on Android - without S_IREAD
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51646 --- Comment #3 from Janne Blomqvist jb at gcc dot gnu.org 2011-12-22 20:44:44 UTC --- Author: jb Date: Thu Dec 22 20:44:32 2011 New Revision: 182638 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=182638 Log: PR 51646 Use POSIX mode flags in open() argument. 2011-12-22 Janne Blomqvist j...@gcc.gnu.org Tobias Burnus bur...@net-b.de PR libfortran/51646 * acinclude.m4 (LIBGFOR_CHECK_UNLINK_OPEN_FILE): Use POSIX mode flags, omit mode argument when flags argument does not have O_CREAT. * io/unix.c (tempfile): Use POSIX mode flags. * configure: Regenerate. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/acinclude.m4 trunk/libgfortran/configure trunk/libgfortran/io/unix.c
[Bug libfortran/51646] Make libgfortran compile on Android
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51646 Janne Blomqvist jb at gcc dot gnu.org changed: What|Removed |Added Status|NEW |WAITING Summary|Make libgfortran compile on |Make libgfortran compile on |Android - without S_IREAD |Android Severity|normal |enhancement --- Comment #4 from Janne Blomqvist jb at gcc dot gnu.org 2011-12-22 20:50:26 UTC --- Mode flags patch committed to trunk. Leaving the PR open as an enhancement in case the reason behind the hack-patch comes to light.
[Bug libstdc++/51657] New: bind1st multiplies a pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51657
Bug #: 51657
Summary: bind1st multiplies a pointer
Classification: Unclassified
Product: gcc
Version: 4.5.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: giecr...@stegny.2a.pl
Host: i586-suse-linux
Target: i586-suse-linux
Build: i586-suse-linux
Created attachment 26167
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26167
Preprocessed source
The following code multiplies a pointer by 2 with no warning:
#include iostream
int main (int, char *argv [])
{
::std ::cout
::std ::bind1st (::std ::multiplies ptrdiff_t (), argv) (02); }
This code should not compile.
[Bug c++/51658] New: [C++0x] delegating constructor ICE in build_data_member_initialization, at cp/semantics.c:5806
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51658
Bug #: 51658
Summary: [C++0x] delegating constructor ICE in
build_data_member_initialization, at
cp/semantics.c:5806
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: r...@gcc.gnu.org
templatetypename T
struct S
{
constexpr S() : t() { }
constexpr S(int) : S() { }
T t;
};
Sint p(1);
ice.ii: In instantiation of ‘constexpr ST::S(int) [with T = int]’:
ice.ii:11:11: required from here
ice.ii:6:28: internal compiler error: in build_data_member_initialization, at
cp/semantics.c:5806
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
[Bug libstdc++/51657] bind1st multiplies a pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51657 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2011-12-22 21:27:56 UTC --- The standard says bind1st(const Op op, const T x) returns: binder1stOp(op, typename Op::first_argument_type(x)). note the explicit type conversion
[Bug target/51643] Incorrect code produced for tail-call of weak function with -O2/-O3 option
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51643 --- Comment #13 from Alexander Osipenko sipych at gmail dot com 2011-12-22 21:31:56 UTC --- Thanks, Richard! It now works fine with -mabi=aapcs Perhaps I don't understand some details, could you tell me why the -mabi=aapcs-linux is not included in this fix?
[Bug c++/51658] [C++0x] delegating constructor ICE in build_data_member_initialization, at cp/semantics.c:5806
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51658 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||paolo.carlini at oracle dot ||com --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2011-12-22 21:40:20 UTC --- Jon, I quickly tried this (I have a couple of patches locally applied but should be unrelated) and I cannot reproduce it with 182640, can you double check?
[Bug libstdc++/51657] bind1st multiplies a pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51657 --- Comment #2 from Christopher Yeleighton giecrilj at stegny dot 2a.pl 2011-12-22 21:46:58 UTC --- The standard is obviously wrong. URL: http://groups.google.com/group/comp.std.c++/browse_thread/thread/de856e5116876ff3/b34116c5e51b1d07?lnk=gstq=bind1st#b34116c5e51b1d07 Report silently ignored.
[Bug libstdc++/51657] bind1st multiplies a pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51657 --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com 2011-12-22 22:00:44 UTC --- Too bad was ignored, but really, if you are interested in my advice, you should get in touch with somebody very active in the LWG if you want to be sure nothing is forgotten (eg, these days, Alisdair Meredith, or Daniel Krugler) and double check that an ISO DR is actually opened for you. That mailing list isn't official in any sense, beware, isn't an ISO reflector. Anyway, all these considerations are for the future, for other issues, because the specific facilities discussed here are deprecated, very unlikely that will be changed at all again post-C++11.
[Bug libstdc++/51657] bind1st multiplies a pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51657 --- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org 2011-12-22 22:28:39 UTC --- (In reply to comment #2) Report silently ignored. No it wasn't, see the note at the top of the post: [Moderator's note: this defect report has been forwarded to the C++ committee. -moderator.] It was opened as an issue and rejected as not a defect: http://open-std.org/JTC1/SC22/WG21/docs/lwg-defects.html#362 Stop making unfounded and incorrect claims such as This code should not compile and silently ignored Stating everything with such certainty when you haven't checked and are wrong just makes it harder to take your bug reports seriously.
[Bug c++/51658] [C++0x] delegating constructor ICE in build_data_member_initialization, at cp/semantics.c:5806
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51658 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2011-12-22 22:29:52 UTC --- Bah, it's probably a local change I was testing a few weeks ago on gcc20 - I'll try again - thanks for checking it
[Bug c++/51658] [C++0x] delegating constructor ICE in build_data_member_initialization, at cp/semantics.c:5806
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51658 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org 2011-12-22 22:32:55 UTC --- works with a different build - my bad
[Bug target/51643] Incorrect code produced for tail-call of weak function with -O2/-O3 option
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51643 --- Comment #14 from Richard Earnshaw rearnsha at gcc dot gnu.org 2011-12-22 23:27:29 UTC --- Because the ABI says it only works for bare metal. On a system with shared libraries, you can't tell at static link time if a weak symbol will be resolved by a shared library, so it has to left up to the dynamic linker which will fill in a PLT stub. Once you have those, it's pretty hard to make the call become a stub (and even if it were, it wouldn't be a NOP (the linker would have to turn the call into something that simply returned as the PLT sequence can't be patched). Tail-calling PLT sequences is perfectly safe, so there's no reason not to perform the optimization.
[Bug target/51643] Incorrect code produced for tail-call of weak function with -O2/-O3 option
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51643 --- Comment #15 from Alexander Osipenko sipych at gmail dot com 2011-12-23 00:40:13 UTC --- Oh, I see, thanks!
[Bug libstdc++/51657] bind1st multiplies a pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51657 --- Comment #5 from Christopher Yeleighton giecrilj at stegny dot 2a.pl 2011-12-23 00:45:28 UTC --- Well, I am astonished at the carelessness of the LWG. If something is plainly wrong, it should be fixed (which would be trivial in this case) or withdrawn, not deprecated. Deprecation is for things that are slightly inconvenient. Anyway, could we get a warning like for gets?
[Bug libstdc++/51657] bind1st multiplies a pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51657 --- Comment #6 from Paolo Carlini paolo.carlini at oracle dot com 2011-12-23 01:31:05 UTC --- Yeah, it's unbelievable, you should help these poor souls.
[Bug libstdc++/51657] bind1st multiplies a pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51657 --- Comment #7 from Jonathan Wakely redi at gcc dot gnu.org 2011-12-23 01:31:23 UTC --- (In reply to comment #5) Well, I am astonished at the carelessness of the LWG. If something is plainly wrong, it should be fixed (which would be trivial in this case) or withdrawn, not deprecated. Deprecation is for things that are slightly inconvenient. Maybe you'd like to report an issue with the Standard then, because the Standard doesn't use your definition of slightly inconvenient so must be wrong: -2- These are deprecated features, where deprecated is defined as: Normative for the current edition of the Standard, but not guaranteed to be part of the Standard in future revisions. The old binders have been superseded by better features. There is no good reason to use them, and fixing them to be non-standard would be a waste of time.
[Bug middle-end/51252] FAIL: c-c++-common/tm/freq.c (internal compiler error)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51252 --- Comment #8 from John David Anglin danglin at gcc dot gnu.org 2011-12-23 01:53:20 UTC --- Author: danglin Date: Fri Dec 23 01:53:13 2011 New Revision: 182646 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=182646 Log: PR middle-end/51252 * config/pa/pa.c (pa_som_tm_clone_table_section): New function. (som_tm_clone_table_section): Declare. (pa_file_start_space): Create $TM_CLONE_TABLE$ subspace. (pa_som_asm_init_sections): Init som_tm_clone_table_section. * config/pa/som.h (TARGET_ASM_TM_CLONE_TABLE_SECTION): Define. Modified: trunk/gcc/ChangeLog trunk/gcc/config/pa/pa.c trunk/gcc/config/pa/som.h
[Bug middle-end/51252] FAIL: c-c++-common/tm/freq.c (internal compiler error)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51252 --- Comment #9 from John David Anglin danglin at gcc dot gnu.org 2011-12-23 02:03:03 UTC --- Fixed on PA.
[Bug testsuite/50722] FAIL: gcc.dg/pr49994-3.c (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50722 --- Comment #5 from John David Anglin danglin at gcc dot gnu.org 2011-12-23 02:11:03 UTC --- Author: danglin Date: Fri Dec 23 02:10:52 2011 New Revision: 182647 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=182647 Log: PR testsuite/50722 gcc.dg/pr49994-3.c: xfail on hppa*-*-*. Modified: trunk/gcc/testsuite/gcc.dg/pr49994-3.c
[Bug testsuite/50722] FAIL: gcc.dg/pr49994-3.c (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50722 John David Anglin danglin at gcc dot gnu.org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Comment #6 from John David Anglin danglin at gcc dot gnu.org 2011-12-23 02:20:42 UTC --- Now fixed.
[Bug target/51659] New: ICE in function output_move_double
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51659 Bug #: 51659 Summary: ICE in function output_move_double Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: car...@google.com Target: arm-linux-gnueabi Created attachment 26168 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26168 test Compile the attached code and profile data with following command, I got an ICE /usr/local/google/home/carrot/disk2/armobja/gcc/cc1 -fpreprocessed function.i -mbionic -quiet -dumpbase function.c -march=armv7-a -mfloat-abi=softfp -mthumb-interwork -mfpu=vfpv3-d16 -mthumb -auxbase-strip obj/function.o -O2 -Wno-unused -fpic -fprofile-use -o function.s src/function.c: In function 'get_func_frame_size': src/function.c:516:1: internal compiler error: in output_move_double, at config/arm/arm.c:13933 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions.
[Bug target/51659] ICE in function output_move_double
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51659
--- Comment #1 from Carrot carrot at google dot com 2011-12-23 02:29:49 UTC
---
(gdb) cont
Continuing.
Breakpoint 2, output_move_double (operands=0x19be680, emit=1 '\001', count=0x0)
at ../../../trunk/gcc/config/arm/arm.c:13933
13933 gcc_assert (!emit);
(gdb) print debug_rtx(operands[0])
(reg:DI 2 r2 [orig:139 f_1(D)-x_frame_offset ] [139])
$1 = void
(gdb) print debug_rtx(operands[1])
(reg:SI 3 r3)
$2 = void
(gdb) bt
#0 output_move_double (operands=0x19be680, emit=1 '\001', count=0x0) at
../../../trunk/gcc/config/arm/arm.c:13933
#1 0x00fdb969 in output_642 (operands=0x19be680, insn=0x7643d900)
at ../../../trunk/gcc/config/arm/vfp.md:202
#2 0x0079d73b in get_insn_template (code=642, insn=0x7643d900) at
../../../trunk/gcc/final.c:1817
#3 0x0079f2ed in final_scan_insn (insn=0x7643d900, file=0x1a451a0,
optimize_p=2, nopeepholes=0, seen=0x7fffe208) at
../../../trunk/gcc/final.c:2682
#4 0x0079d5d9 in final (first=0x76ae6940, file=0x1a451a0,
optimize_p=2) at ../../../trunk/gcc/final.c:1786
#5 0x007a2280 in rest_of_handle_final () at
../../../trunk/gcc/final.c:4319
#6 0x00a1f9ae in execute_one_pass (pass=0x1865060) at
../../../trunk/gcc/passes.c:2080
#7 0x00a1fb9c in execute_pass_list (pass=0x1865060) at
../../../trunk/gcc/passes.c:2135
#8 0x00a1fbbd in execute_pass_list (pass=0x1865ea0) at
../../../trunk/gcc/passes.c:2136
#9 0x00a1fbbd in execute_pass_list (pass=0x1865e40) at
../../../trunk/gcc/passes.c:2136
#10 0x00bc3b26 in tree_rest_of_compilation (fndecl=0x76c44a00) at
../../../trunk/gcc/tree-optimize.c:421
#11 0x00699e81 in cgraph_expand_function (node=0x76937360) at
../../../trunk/gcc/cgraphunit.c:1818
#12 0x0069a04c in cgraph_expand_all_functions () at
../../../trunk/gcc/cgraphunit.c:1885
#13 0x0069ab8d in cgraph_optimize () at
../../../trunk/gcc/cgraphunit.c:2198
#14 0x00697bce in cgraph_finalize_compilation_unit () at
../../../trunk/gcc/cgraphunit.c:1327
#15 0x004c8b3c in c_write_global_declarations () at
../../../trunk/gcc/c-decl.c:10026
#16 0x00b11a52 in compile_file () at ../../../trunk/gcc/toplev.c:573
#17 0x00b13c8b in do_compile () at ../../../trunk/gcc/toplev.c:1935
#18 0x00b13e02 in toplev_main (argc=20, argv=0x7fffe658) at
../../../trunk/gcc/toplev.c:2011
#19 0x005c9d90 in main (argc=20, argv=0x7fffe658) at
../../../trunk/gcc/main.c:36
(gdb) f 3
#3 0x0079f2ed in final_scan_insn (insn=0x7643d900, file=0x1a451a0,
optimize_p=2, nopeepholes=0, seen=0x7fffe208) at
../../../trunk/gcc/final.c:2682
2682templ = get_insn_template (insn_code_number, insn);
(gdb) print debug_rtx(insn)
(insn:TI 6 3 7 2 (set (reg:DI 2 r2 [orig:139 f_1(D)-x_frame_offset ] [139])
(mem/s:DI (plus:SI (reg:SI 0 r0 [ f ])
(const_int 152 [0x98])) [6 f_1(D)-x_frame_offset+0 S8 A64]))
src/function.c:512 642 {*movdi_vfp_cortexa8}
(expr_list:REG_DEAD (reg:SI 0 r0 [ f ])
(nil)))
$3 = void
Apparently operands[1] doesn't match the actual operand (MEM ...) in the insn.
(gdb) print recog_data.operand
$6 = {0x75ff7100, 0x75ff77a0, 0xabababababababab repeats 28 times}
(gdb) print recog_data.operand[0]
$7 = (rtx) 0x75ff7100
(gdb) print recog_data.operand[1]
$8 = (rtx) 0x75ff77a0
(gdb) print debug_rtx(recog_data.operand[0])
(reg:DI 2 r2 [orig:139 f_1(D)-x_frame_offset ] [139])
$9 = void
(gdb) print debug_rtx(recog_data.operand[1])
(reg:SI 3 r3)
For some unknown reason, recog_data.operand[1] is corrupted.
[Bug tree-optimization/43491] Unnecessary temporary for global register variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43491 --- Comment #6 from jye2 at gcc dot gnu.org 2011-12-23 05:43:17 UTC --- Author: jye2 Date: Fri Dec 23 05:43:09 2011 New Revision: 182650 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=182650 Log: 2011-12-22 Bin Cheng bin.ch...@arm.com Richard Guenther rguent...@suse.de PR tree-optimization/43491 * tree-ssa-pre.c (eliminate): Don't replace global register variable when it is the RHS of a single assign. testsuite: * gcc.dg/tree-ssa/pr43491.c: New test. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/pr43491.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-pre.c
[Bug c++/51660] New: ICE on function missing argument list
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51660
Bug #: 51660
Summary: ICE on function missing argument list
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ca...@cs.stanford.edu
g++ crashes on this (invalid) program:
struct s
{
static int x {return 0;}
};
Output:
crashes/6.cpp:3:16: warning: extended initializer lists only available with
-std=c++11 or -std=gnu++11 [enabled by default]
crashes/6.cpp:3:19: error: expected primary-expression before ‘return’
crashes/6.cpp:3:19: error: expected ‘}’ before ‘return’
crashes/6.cpp:3:19: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
How to run: g++ file.cpp
Note that this program does not cause gcc to crash if compiled as C.
Compiler version:
Using built-in specs.
COLLECT_GCC=/new-gcc/i-4.7/bin/g++
COLLECT_LTO_WRAPPER=/new-gcc/i-4.7/libexec/gcc/x86_64-unknown-linux-gnu/4.7.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../s-4.7/configure --prefix=/new-gcc/i-4.7
Thread model: posix
gcc version 4.7.0 20111223 (experimental) (GCC)
[Bug c++/51661] New: ICE when template class list repeated
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51661
Bug #: 51661
Summary: ICE when template class list repeated
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ca...@cs.stanford.edu
g++ crashes when compiling this program:
namespace
{
templateclass T struct s{s();};
templateclass T sTT::s(){}
extern template struct sint;
}
How to run: g++ prog.cpp
Output:
prog.cpp:4:19: error: ‘{anonymous}::sT’ is not a template
prog.cpp:4:30: error: declaration of ‘{anonymous}::sT s()’ not in a namespace
surrounding ‘::’
prog.cpp:4:30: error: ‘{anonymous}::sT s()’ should have been declared inside
‘::’
prog.cpp:5:24: error: using typedef-name ‘sint’ after ‘struct’
prog.cpp:5:24: internal compiler error: tree check: expected tree that contains
‘decl minimal’ structure, have ‘template_id_expr’ in
check_elaborated_type_specifier, at cp/decl.c:11443
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
Compiler version:
COLLECT_GCC=/new-gcc/i-4.7/bin/g++
COLLECT_LTO_WRAPPER=/new-gcc/i-4.7/libexec/gcc/x86_64-unknown-linux-gnu/4.7.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../s-4.7/configure --prefix=/new-gcc/i-4.7
Thread model: posix
gcc version 4.7.0 20111223 (experimental) (GCC)
