[Bug middle-end/39976] [4.5/4.6/4.7 Regression] Big sixtrack degradation on powerpc 32/64 after revision r146817
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39976 --- Comment #44 from Jiangning Liu jiangning.liu at arm dot com 2012-02-24 08:09:25 UTC --- I'm not sure if this kind of bug has been completely fixed, and posted a qeustion in mail list at http://gcc.gnu.org/ml/gcc/2012-02/msg00415.html .
[Bug rtl-optimization/37516] ~(-2 - a) is not being optimized into a + 1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37516
--- Comment #5 from rguenther at suse dot de rguenther at suse dot de
2012-02-24 08:38:19 UTC ---
On Thu, 23 Feb 2012, pinskia at gcc dot gnu.org wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37516
--- Comment #4 from Andrew Pinski pinskia at gcc dot gnu.org 2012-02-23
22:15:05 UTC ---
Maybe get away with these old-stylish names ('tree' and 'fold') and
make it match reality, gimple-ssa-combine.c ;)
That sounds like a good idea. I have done that.
Still have to have a look at your branch - do you have a brief
overview documentation, for example on the wiki? What I'd like
to do is have an interface that I can re-use for VN combining,
basically replace its simplify_*_expression functions.
I don't have one yet. But I hope to create one this weekend.
Right now replacing the VN combining with this new functionality will not work
as it scans the defs itself. Though I am moving all the def scanning to its
own function which should allow for the code to be more modular and allow for
the VN combining to work with it.
I think def scanning is ok, but all SSA names should be valueized via
a hook first.
Richard.
[Bug rtl-optimization/52060] [4.6 Regression] Invalid constant simplification in combine with parallel result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52060 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|4.6.4 |4.6.3
[Bug tree-optimization/52361] gcc.dg/pr48141.c times out with checking enabled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52361 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2012-02-24 09:16:43 UTC --- Well, that's sort-of expected ...
[Bug middle-end/52355] [4.7 regression] address difference between array elements is not considered to be a compile time constant anymore
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52355 --- Comment #5 from Richard Guenther rguenth at gcc dot gnu.org 2012-02-24 09:47:33 UTC --- We fold end up trying to fold (long int) (*(a + 256))[0][0] - (long int) (*a)[0][0] because a is of type char[16][16] *. I have a patch.
[Bug tree-optimization/52361] gcc.dg/pr48141.c times out with checking enabled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52361 --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2012-02-24 10:35:32 UTC --- Actually I have a simple patch that speeds things up a bit, but not significantly so.
[Bug tree-optimization/52361] gcc.dg/pr48141.c times out with checking enabled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52361 --- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE 2012-02-24 10:43:02 UTC --- --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2012-02-24 10:35:32 UTC --- Actually I have a simple patch that speeds things up a bit, but not significantly so. I wonder if the testcase couldn't be reduced a bit, or instead marked with dg-require-effective-target run_expensive_tests I doubt there is much point routinely running such a compile time hog. Rainer
[Bug middle-end/52355] [4.7 regression] address difference between array elements is not considered to be a compile time constant anymore
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52355 --- Comment #6 from Richard Guenther rguenth at gcc dot gnu.org 2012-02-24 11:14:24 UTC --- Author: rguenth Date: Fri Feb 24 11:14:17 2012 New Revision: 184548 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=184548 Log: 2012-02-24 Richard Guenther rguent...@suse.de PR middle-end/52355 * fold-const.c (fold_addr_of_array_ref_difference): New function. (fold_binary_loc): Use it to extend the existing a[i] - a[j] folding. * gcc.dg/pr52355.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/pr52355.c Modified: trunk/gcc/ChangeLog trunk/gcc/fold-const.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/52365] Procedure interface wrongly imported into interface without IMPORT
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52365 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2012-02-24 11:16:09 UTC --- Note: I think the following variant is valid, where the symbol is in the same interface block. (Correctly accepted.) interface subroutine foo() end subroutine foo subroutine bar(x) procedure(foo) :: x end subroutine bar end interface end While the following variant is also invalid (but accepted): module m interface subroutine bar(x) procedure(foo) :: x end subroutine bar end interface contains subroutine foo() end subroutine foo end Hence, a simple check in decl.c is not possible as it will come too early for the second example. Still, some check should probably added to decl.c's match_procedure_interface - similarly to the gfc_current_ns-proc_name-attr.if_source == IFSRC_IFBODY check in variable_decl. Another check should be done at resolve_procedure_interface - or possibly the only check, if one modifies the way where the decl is declared for IFSRC_IFBODY.
[Bug c++/52369] New: Const-qualified non-class base member and defaulted default constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52369
Bug #: 52369
Summary: Const-qualified non-class base member and defaulted
default constructor
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ai.az...@gmail.com
Created attachment 26740
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26740
Output of -v option and preprocessed file
The following ill-formed code is wrongly accepted by GCC 4.7.0 20120218
(experimental).
class B
{
private:
int const v_;
};
class D
: public B
{};
int main()
{
D d;
}
B's default constructor is implicitly-declared and has no ctor-initializer. So,
B::v_ is not designated by any mem-initializer-id and subject to
default-initialization. However, default-initialization of a const-qualified
non-class type is ill-formed. Therefore, the use of B's constructor is
ill-formed (and it should be defined as deleted in -std=c++11 mode), and the
use of D's is also ill-formed.
N.B. A similar (but a bit different) problem seems to have been resolved in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29043 .
[Bug target/52367] Many incorrect thumb insn lengths
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52367 Richard Earnshaw rearnsha at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-02-24 Ever Confirmed|0 |1 Severity|normal |enhancement --- Comment #1 from Richard Earnshaw rearnsha at gcc dot gnu.org 2012-02-24 11:35:23 UTC --- Over estimating is safe, though potentially sub-optimal. The concern is mainly around under-estimating, which can lead to broken code. Beware, however that if an insn pattern generates more than one assembly language instruction then all the length costs will be associated with one instruction (normally the last). R.
[Bug tree-optimization/52361] gcc.dg/pr48141.c times out with checking enabled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52361 --- Comment #5 from Richard Guenther rguenth at gcc dot gnu.org 2012-02-24 11:38:43 UTC --- Author: rguenth Date: Fri Feb 24 11:38:39 2012 New Revision: 184549 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=184549 Log: 2012-02-24 Richard Guenther rguent...@suse.de PR middle-end/52361 * passes.c (execute_function_todo): When verifying SSA form verify gimple form first. * tree-ssa.c (verify_ssa): Do not verify gimple form here. Modified: trunk/gcc/ChangeLog trunk/gcc/passes.c trunk/gcc/tree-ssa.c
[Bug tree-optimization/52361] gcc.dg/pr48141.c times out with checking enabled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52361 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2012-02-24 11:45:37 UTC --- Test taking 17s on x86_64 isn't that unreasonable, nothing close to being a compile time hog, if it is slow even when cross-compiling to sparc, I guess it should be investigated why so much more time is spent there.
[Bug middle-end/52355] [4.7 regression] address difference between array elements is not considered to be a compile time constant anymore
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52355 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #7 from Richard Guenther rguenth at gcc dot gnu.org 2012-02-24 11:56:07 UTC --- Fixed.
[Bug target/46092] Improve constant handling of thumb2 instructions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46092 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC||ramana at gcc dot gnu.org Resolution||FIXED Target Milestone|--- |4.7.0 Severity|normal |enhancement --- Comment #4 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2012-02-24 12:24:04 UTC --- Trunk generates this today. Thus fixed. Ramana tv: @ args = 0, pretend = 0, frame = 0 @ frame_needed = 0, uses_anonymous_args = 0 @ link register save eliminated. movwr3, #65520 cmpr0, r3 itthi subhir0, r0, #65280 subhir0, r0, #241 bxlr .sizetv, .-tv .identGCC: (GNU) 4.7.0 20120116 (experimental)
[Bug tree-optimization/52361] gcc.dg/pr48141.c times out with checking enabled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52361 --- Comment #7 from Richard Guenther rguenth at gcc dot gnu.org 2012-02-24 12:48:00 UTC --- Author: rguenth Date: Fri Feb 24 12:47:56 2012 New Revision: 184552 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=184552 Log: 2012-02-24 Richard Guenther rguent...@suse.de PR middle-end/52361 * gimple.c (walk_gimple_op): Use predicates with less redundant tests. (is_gimple_reg_type): Move inline ... * gimple.h (is_gimple_reg_type): ... here. Modified: trunk/gcc/ChangeLog trunk/gcc/gimple.c trunk/gcc/gimple.h
[Bug c++/52371] New: [C++11] ICE in noexcept with constexpr conversion function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52371
Bug #: 52371
Summary: [C++11] ICE in noexcept with constexpr conversion
function
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ai.az...@gmail.com
The following well-formed code causes ICE on GCC 4.7.0 20120218 (experimental).
//
templatetypename T, T v
struct integral_constant
{
typedef T value_type;
static constexpr value_type value = v;
constexpr operator value_type() { return value; }
};
templatetypename T
struct B
{
B()
noexcept(integral_constantbool, noexcept(T())()) // - ICE
: v_()
{}
T v_;
};
int main()
{
Bint b;
}
//
If I use the static constexpr `value' instread of the constexpr conversion
function, the ICE disappears.
[Bug c++/52371] [C++11] ICE in noexcept with constexpr conversion function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52371 --- Comment #1 from Ai Azuma ai.azuma at gmail dot com 2012-02-24 13:54:18 UTC --- Created attachment 26741 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26741 Output of -v option and preprocessed file
[Bug c++/52371] [C++11] ICE in noexcept with constexpr conversion function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52371 --- Comment #2 from Ai Azuma ai.azuma at gmail dot com 2012-02-24 14:01:41 UTC --- I'm sorry. I forgot to write that this ICE appears with -std=c++11 option.
[Bug c++/52369] Const-qualified non-class base member and defaulted default constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52369 fabien at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-02-24 CC||fabien at gcc dot gnu.org AssignedTo|unassigned at gcc dot |fabien at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 Known to fail||4.1.2, 4.2.4, 4.3.6, 4.5.3, ||4.7.0 --- Comment #1 from fabien at gcc dot gnu.org 2012-02-24 14:05:19 UTC --- Confirmed. Can someone please test it on 4.6.0 and 4.6.2 ? Thanks.
[Bug fortran/52370] Spurious may be used uninitialized warning for check of optional argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52370 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Keywords||diagnostic --- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org 2012-02-24 14:05:32 UTC --- (In reply to comment #1) The warning is not printed for the last line where one dereferences a pointer (line 8), but for the b.0 = assignment. I have the impression that problem is rather line 8 - i.e. related to the pointer dereference. The warning vanishes if one comments/moves the a = line - unless b is volatile - or if one makes a a VALUE or a function result. I assume that's because it is then simpler to merge the implicitly and the explicitly created if (present(b)) lines.
[Bug c++/52369] Const-qualified non-class base member and defaulted default constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52369 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2012-02-24 14:17:17 UTC --- With 4.6.2 and -Wall gives the same as 4.7.0: l.cc:4:13: warning: non-static const member 'const int B::v_' in class without a constructor [-Wuninitialized] l.cc: In function 'int main()': l.cc:13:5: warning: unused variable 'd' [-Wunused-variable] 4.5.2 gives the same (except doesn't print the [-W...] info after the warnings)
[Bug target/49461] boehm-gc and gcj incompatible with pie
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49461 --- Comment #13 from pmarlier at gcc dot gnu.org 2012-02-24 15:21:20 UTC --- Author: pmarlier Date: Fri Feb 24 15:21:12 2012 New Revision: 184555 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=184555 Log: 2012-02-23 Patrick Marlier patrick.marl...@gmail.com Jack Howarth howa...@bromo.med.uc.edu boehm-gc/ PR boehm-gc/52179 * include/gc_config.h.in: Undefine HAVE_PTHREAD_GET_STACKADDR_NP. * include/private/gcconfig.h (DARWIN): Define STACKBOTTOM with pthread_get_stackaddr_np when available. * configure.ac (THREADS): Check availability of pthread_get_stackaddr_np. * configure: Regenerate. libjava/ PR target/49461 * configure.ac (SYSTEMSPEC): No longer pass -no_pie for darwin11. * configure: Regenerate. Modified: trunk/boehm-gc/ChangeLog trunk/boehm-gc/configure trunk/boehm-gc/configure.ac trunk/boehm-gc/include/gc_config.h.in trunk/boehm-gc/include/private/gcconfig.h trunk/libjava/ChangeLog trunk/libjava/configure trunk/libjava/configure.ac
[Bug boehm-gc/52179] boehm-gc incompatible with aslr on darwin11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52179 --- Comment #27 from pmarlier at gcc dot gnu.org 2012-02-24 15:21:20 UTC --- Author: pmarlier Date: Fri Feb 24 15:21:12 2012 New Revision: 184555 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=184555 Log: 2012-02-23 Patrick Marlier patrick.marl...@gmail.com Jack Howarth howa...@bromo.med.uc.edu boehm-gc/ PR boehm-gc/52179 * include/gc_config.h.in: Undefine HAVE_PTHREAD_GET_STACKADDR_NP. * include/private/gcconfig.h (DARWIN): Define STACKBOTTOM with pthread_get_stackaddr_np when available. * configure.ac (THREADS): Check availability of pthread_get_stackaddr_np. * configure: Regenerate. libjava/ PR target/49461 * configure.ac (SYSTEMSPEC): No longer pass -no_pie for darwin11. * configure: Regenerate. Modified: trunk/boehm-gc/ChangeLog trunk/boehm-gc/configure trunk/boehm-gc/configure.ac trunk/boehm-gc/include/gc_config.h.in trunk/boehm-gc/include/private/gcconfig.h trunk/libjava/ChangeLog trunk/libjava/configure trunk/libjava/configure.ac
[Bug target/50580] gcc.target/mips/interrupt_handler-[23].c FAIL on IRIX 6.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50580 --- Comment #1 from Rainer Orth ro at gcc dot gnu.org 2012-02-24 15:52:09 UTC --- Author: ro Date: Fri Feb 24 15:52:01 2012 New Revision: 184557 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=184557 Log: [testsuite] Skip gcc.target/mips/interrupt_handler-[23].c on IRIX (PR target/50580) PR target/50580 * gcc.target/mips/interrupt_handler-2.c: Skip on mips-sgi-irix6*. * gcc.target/mips/interrupt_handler-3.c: Likewise. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/mips/interrupt_handler-2.c trunk/gcc/testsuite/gcc.target/mips/interrupt_handler-3.c
[Bug target/50580] gcc.target/mips/interrupt_handler-[23].c FAIL on IRIX 6.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50580 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW URL||http://gcc.gnu.org/ml/gcc-p ||atches/2012-02/msg01243.htm ||l Last reconfirmed||2012-02-24 Ever Confirmed|0 |1 --- Comment #2 from Rainer Orth ro at gcc dot gnu.org 2012-02-24 15:59:01 UTC --- Analysis in workaround patch.
[Bug target/52261] [avr] Add support for AVR Xmega cores
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52261 --- Comment #7 from Georg-Johann Lay gjl at gcc dot gnu.org 2012-02-24 16:26:46 UTC --- Author: gjl Date: Fri Feb 24 16:26:35 2012 New Revision: 184559 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=184559 Log: PR target/52261 * config/avr/avr.c (avr_out_movhi_mr_r_xmega): Use base to test for unusedness in st X addressing. Modified: trunk/gcc/ChangeLog trunk/gcc/config/avr/avr.c
[Bug target/52372] New: gcc.target/mips/mips16-attributes{,-4}.c SEGV in dwf_regno
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52372
Bug #: 52372
Summary: gcc.target/mips/mips16-attributes{,-4}.c SEGV in
dwf_regno
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: r...@gcc.gnu.org
CC: rsand...@gcc.gnu.org
Host: mips-sgi-irix6.5
Target: mips-sgi-irix6.5
Build: mips-sgi-irix6.5
The mips16-attributes{, -4}.c tests ICE on IRIX 6:
FAIL: gcc.target/mips/mips16-attributes-4.c (internal compiler error)
FAIL: gcc.target/mips/mips16-attributes-4.c (test for excess errors)
FAIL: gcc.target/mips/mips16-attributes.c (internal compiler error)
FAIL: gcc.target/mips/mips16-attributes.c (test for excess errors)
In the first case, I find:
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.target/mips/mips16-attributes-4.c:
In function 'bar':
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.target/mips/mips16-attributes-4.c:9:1:
internal compiler error: Segmentation fault
The failure boils down to
$ cc1 -fpreprocessed mips16-attributes-4.i -quiet -mabi=o64 -mlong32 -mno-synci
-o mips16-attributes-4.s
In gdb,I see
Program received signal SIGSEGV, Segmentation fault.
0x104b4048 in dwf_regno (reg=0x40280b8) at
/vol/gcc/src/hg/trunk/local/gcc/dwarf2cfi.c:912
(gdb) p reg
$1 = (const_rtx) 0x40280b8
(gdb) pr
(pc)
(gdb) where
#0 0x104b4048 in dwf_regno (reg=0x40280b8) at
/vol/gcc/src/hg/trunk/local/gcc/dwarf2cfi.c:912
#1 dwarf2out_flush_queued_reg_saves () at
/vol/gcc/src/hg/trunk/local/gcc/dwarf2cfi.c:994
#2 0x104b56d4 in dwarf2out_frame_debug (insn=0x40f05e0) at
/vol/gcc/src/hg/trunk/local/gcc/dwarf2cfi.c:2038
#3 scan_insn_after (insn=insn@entry=0x4033048) at
/vol/gcc/src/hg/trunk/local/gcc/dwarf2cfi.c:2361
#4 0x104b6b74 in scan_trace (trace=optimized out) at
/vol/gcc/src/hg/trunk/local/gcc/dwarf2cfi.c:2505
#5 0x104b7e0c in create_cfi_notes () at
/vol/gcc/src/hg/trunk/local/gcc/dwarf2cfi.c:2549
#6 execute_dwarf2_frame () at /vol/gcc/src/hg/trunk/local/gcc/dwarf2cfi.c:2907
#7 0x104f5bec in execute_one_pass (pass=pass@entry=0x10dc3708) at
/vol/gcc/src/hg/trunk/local/gcc/passes.c:2081
#8 0x104f6088 in execute_pass_list (pass=0x10dc3708) at
/vol/gcc/src/hg/trunk/local/gcc/passes.c:2136
#9 0x104f60a4 in execute_pass_list (pass=0x10dc3970) at
/vol/gcc/src/hg/trunk/local/gcc/passes.c:2137
#10 0x104f60a4 in execute_pass_list (pass=0x10dc39a8) at
/vol/gcc/src/hg/trunk/local/gcc/passes.c:2137
#11 0x1078c50c in tree_rest_of_compilation (fndecl=0x40b9100) at
/vol/gcc/src/hg/trunk/local/gcc/tree-optimize.c:422
#12 0x105d533c in cgraph_expand_function (node=0x40d80a8) at
/vol/gcc/src/hg/trunk/local/gcc/cgraphunit.c:1837
#13 0x105d7564 in cgraph_output_in_order () at
/vol/gcc/src/hg/trunk/local/gcc/cgraphunit.c:2002
#14 cgraph_optimize () at /vol/gcc/src/hg/trunk/local/gcc/cgraphunit.c:2213
#15 0x105d792c in cgraph_finalize_compilation_unit () at
/vol/gcc/src/hg/trunk/local/gcc/cgraphunit.c:1344
#16 0x10187cf4 in c_write_global_declarations () at
/vol/gcc/src/hg/trunk/local/gcc/c-decl.c:10031
#17 0x10277148 in compile_file () at
/vol/gcc/src/hg/trunk/local/gcc/toplev.c:573
#18 do_compile () at /vol/gcc/src/hg/trunk/local/gcc/toplev.c:1938
#19 toplev_main (argc=9, argv=0x7ffb7f04) at
/vol/gcc/src/hg/trunk/local/gcc/toplev.c:2014
#20 0x101723f0 in __start ()
I didn't easily see how to find the equivalent of REGNO(reg) in dwf_regno.
Rainer
[Bug target/52372] [4.7 regression] gcc.target/mips/mips16-attributes{,-4}.c SEGV in dwf_regno
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52372
Rainer Orth ro at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|--- |4.7.0
Summary|gcc.target/mips/mips16-attr |[4.7 regression]
|ibutes{,-4}.c SEGV in |gcc.target/mips/mips16-attr
|dwf_regno |ibutes{,-4}.c SEGV in
||dwf_regno
--- Comment #1 from Rainer Orth ro at gcc dot gnu.org 2012-02-24 16:29:38 UTC
---
I just see that this is a regression from the 4.6 branch.
[Bug c++/52373] New: template usage drops some checks on the accessibility of a member
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52373
Bug #: 52373
Summary: template usage drops some checks on the accessibility
of a member
Classification: Unclassified
Product: gcc
Version: 4.6.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: sylves...@debian.org
Considering this code:
class A
{
struct st
{
static void f();
};
};
template typename t void foo()
{
A::st::f();
}
---
g++ accepts it.
If I remove template typename t, an error is triggered (which is the
expected behavior):
plop.cpp: In function ‘void foo()’:
plop.cpp:4:12: error: ‘struct A::st’ is private
plop.cpp:12:5: error: within this context
[Bug rtl-optimization/37272] [4.5 Regression] IRA has caused ppc64-double-1.c to fail
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37272 --- Comment #7 from Peter Bergner bergner at gcc dot gnu.org 2012-02-24 16:42:37 UTC --- This looks to be fixed, probably by Mike's fp convert changes from a while back. I'm now seeing the following src code being generated: fctidz 1,1 fcfid 1,1 blr Can we close this now?
[Bug c++/52374] New: [C++11] Fails to transform id-expression into dependent base member access in lambda expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52374
Bug #: 52374
Summary: [C++11] Fails to transform id-expression into
dependent base member access in lambda expression
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ai.az...@gmail.com
Created attachment 26742
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26742
Output of -v option and preprocessed file
In the lambda expression's compound statement, id-expressions referring to
non-static members should be transformed into class member access expressions
by prefixing `(*this).'. However, GCC fails the transformation when
id-expressions involved are qualified-ids and refer to dependent base members.
A test case is as follows;
struct B
{
int get() const { return 42; }
};
templatetypename X
struct D
: public X
{
int get() const { return [this]() - int { return X::get(); }(); }
};
int main()
{
DB d;
d.get();
}
For the above mentioned well-formed code, 4.7.0 20120218 (experimental) with
-std=c++11 complains as follows;
main.cpp: In instantiation of 'DX::get() const [with X = B]::lambda()':
main.cpp:10:29: required from 'struct DX::get() const [with X =
B]::lambda()'
main.cpp:10:65: required from 'int DX::get() const [with X = B]'
main.cpp:16:9: required from here
main.cpp:10:60: error: cannot call member function 'int B::get() const' without
object
`X::get' in the lambda expression should be implicitly transformed into
`(*this).X::get', and the test case should compile successfully.
[Bug c++/52373] template usage drops some checks on the accessibility of a member
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52373 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2012-02-24 16:50:25 UTC --- dup *** This bug has been marked as a duplicate of bug 41437 ***
[Bug c++/41437] No access control for classes in template functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41437 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added CC||sylvestre at debian dot org --- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org 2012-02-24 16:50:25 UTC --- *** Bug 52373 has been marked as a duplicate of this bug. ***
[Bug c++/52374] [C++11] Fails to transform id-expression into dependent base member access in lambda expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52374 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-02-24 Ever Confirmed|0 |1
[Bug target/16458] PowerPC - redundant compare
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16458 Peter Bergner bergner at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.8.0 --- Comment #7 from Peter Bergner bergner at gcc dot gnu.org 2012-02-24 17:20:18 UTC --- Richi mentioned this isn't suitable for 4.7 stage4, so re-targeting this for 4.8.
[Bug c++/52282] [C++0x] ICE / confused by earlier errors with decltype/constexpr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52282 --- Comment #2 from andyg1001 at hotmail dot co.uk 2012-02-24 17:42:59 UTC --- Created attachment 26743 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26743 test-case for decltype ICE / incorrect evaluation of constexpr The attached test-case source expands on my previous bug report and shows where the ICE occurs with decltype but also where the compiler fails to detect that a value is actually constexpr (lines marked incorrect evaluation). What is interesting is that the incorrect evaluation does not occur for comparable use inside main(). GCC version: g++ (GCC) 4.7.0 20120224 (experimental)
[Bug target/52352] [x32] - Wrong code to access addresses 0x80000000 to 0xFFFFFFFF using registers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52352
--- Comment #10 from Uros Bizjak ubizjak at gmail dot com 2012-02-24 18:32:56
UTC ---
(In reply to comment #9)
It is fixed on hjl/x32/addr32, hjl/x32/gcc-4_6-branch and
hjl/x32/gcc-4_6-branch+mx32 branches.
The problem is
;; Stores and loads of ax to arbitrary constant address.
;; We fake an second form of instruction to force reload to load address
;; into register when rax is not available
(define_insn *movabsmode_1
[(set (mem:SWI1248x (match_operand:DI 0 x86_64_movabs_operand i,r))
(match_operand:SWI1248x 1 nonmemory_operand a,er))]
TARGET_64BIT ix86_check_movabs (insn, 0)
@
movabs{imodesuffix}\t{%1, %P0|%P0, %1}
mov{imodesuffix}\t{%1, %a0|%a0, %1}
DImode is incorrect for x32, especially for register operand.
That is where
movq$-18874360, %rax
movl(%rax), %edx
comes from. It should be in Pmode. However, the immediate operand
must be in DImode for x86_64_movabs_operand.
But this is the _address_ that we are talking, see the MEM RTX. So, following
(untested) patch can help - access is in PTR mode, and a modifier should
handle this without problems.
--cut here--
Index: config/i386/i386.md
===
--- config/i386/i386.md (revision 184560)
+++ config/i386/i386.md (working copy)
@@ -2360,7 +2360,7 @@
;; We fake an second form of instruction to force reload to load address
;; into register when rax is not available
(define_insn *movabsmode_1
- [(set (mem:SWI1248x (match_operand:DI 0 x86_64_movabs_operand i,r))
+ [(set (mem:SWI1248x (match_operand:PTR 0 x86_64_movabs_operand i,r))
(match_operand:SWI1248x 1 nonmemory_operand a,er))]
TARGET_64BIT ix86_check_movabs (insn, 0)
@
@@ -2375,7 +2375,7 @@
(define_insn *movabsmode_2
[(set (match_operand:SWI1248x 0 register_operand =a,r)
-(mem:SWI1248x (match_operand:DI 1 x86_64_movabs_operand i,r)))]
+(mem:SWI1248x (match_operand:PTR 1 x86_64_movabs_operand i,r)))]
TARGET_64BIT ix86_check_movabs (insn, 1)
@
movabs{imodesuffix}\t{%P1, %0|%0, %P1}
--cut here--
[Bug target/52352] [x32] - Wrong code to access addresses 0x80000000 to 0xFFFFFFFF using registers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52352
--- Comment #11 from H.J. Lu hjl.tools at gmail dot com 2012-02-24 19:14:19
UTC ---
(In reply to comment #10)
But this is the _address_ that we are talking, see the MEM RTX. So,
following
(untested) patch can help - access is in PTR mode, and a modifier should
handle this without problems.
--cut here--
Index: config/i386/i386.md
===
--- config/i386/i386.md (revision 184560)
+++ config/i386/i386.md (working copy)
@@ -2360,7 +2360,7 @@
;; We fake an second form of instruction to force reload to load address
;; into register when rax is not available
(define_insn *movabsmode_1
- [(set (mem:SWI1248x (match_operand:DI 0 x86_64_movabs_operand i,r))
+ [(set (mem:SWI1248x (match_operand:PTR 0 x86_64_movabs_operand i,r))
(match_operand:SWI1248x 1 nonmemory_operand a,er))]
TARGET_64BIT ix86_check_movabs (insn, 0)
@
@@ -2375,7 +2375,7 @@
(define_insn *movabsmode_2
[(set (match_operand:SWI1248x 0 register_operand =a,r)
-(mem:SWI1248x (match_operand:DI 1 x86_64_movabs_operand i,r)))]
+(mem:SWI1248x (match_operand:PTR 1 x86_64_movabs_operand i,r)))]
TARGET_64BIT ix86_check_movabs (insn, 1)
@
movabs{imodesuffix}\t{%P1, %0|%0, %P1}
--cut here--
I checked a similar fix into hjl/x32/addr32, hjl/x32/gcc-4_6-branch and
hjl/x32/gcc-4_6-branch+mx32 branches. I also added I code to print
constant address as positive 32bit integer for x32:
http://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=c6d9aee05cb3bfbe3c2a1b63f3f842e8d3fcb8e0
I used :P instead of :PTR which will be removed when I submit patches
to use SImode for Pmode with x32.
[Bug target/52364] The unnecessary second form in *movabsmode_[12]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52364 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #2 from H.J. Lu hjl.tools at gmail dot com 2012-02-24 19:15:08 UTC --- The second form is needed for -ffixed-rax.
[Bug target/52352] [x32] - Wrong code to access addresses 0x80000000 to 0xFFFFFFFF using registers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52352 --- Comment #12 from Uros Bizjak ubizjak at gmail dot com 2012-02-24 19:29:20 UTC --- (In reply to comment #11) I checked a similar fix into hjl/x32/addr32, hjl/x32/gcc-4_6-branch and hjl/x32/gcc-4_6-branch+mx32 branches. I also added I code to print constant address as positive 32bit integer for x32: I think we can simply disable these two patterns on x32. This is with disabled patterns: x32_O3_main: 0: b8 00 00 e0 fe mov$0xfee0,%eax 5: 8b 00 mov(%rax),%eax 7: a8 01 test $0x1,%al 9: 74 01 je c x32_O3_main+0xc b: 90 nop c: b8 00 00 e0 fe mov$0xfee0,%eax 11: 8b 50 08mov0x8(%rax),%edx 14: 89 50 04mov%edx,0x4(%rax) 17: c3 retq and with enabled patterns: x32_O3_main: 0: a1 00 00 e0 fe 00 00movabs 0xfee0,%eax 7: 00 00 9: a8 01 test $0x1,%al b: 74 01 je e x32_O3_main+0xe d: 90 nop e: a1 08 00 e0 fe 00 00movabs 0xfee8,%eax 15: 00 00 17: a3 04 00 e0 fe 00 00movabs %eax,0xfee4 1e: 00 00 20: c3 retq There is simply no need for movabs from/to mem, since there is no 64bit addresses. And code size is horrible (and I bet that the former code runs faster).
[Bug middle-end/52375] New: [4.7 Regression] internal compiler error: in extract_insn, at recog.c:2123 at -O3 -mfpu=neon
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52375 Bug #: 52375 Summary: [4.7 Regression] internal compiler error: in extract_insn, at recog.c:2123 at -O3 -mfpu=neon Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: bernhard.rosenkran...@linaro.org Created attachment 26744 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26744 Preprocessed source (not yet reduced) $ /opt/android-toolchain-4.7/bin/arm-linux-androideabi-g++ -march=armv7-a -mfloat-abi=softfp -mfpu=neon -O3 -o Input.o -c Input.i frameworks/base/libs/ui/Input.cpp: In member function 'void android::VelocityTracker::addMovement(const android::MotionEvent*)': frameworks/base/libs/ui/Input.cpp:866:1: error: unrecognizable insn: (insn 71 70 72 9 (set (reg:V4SI 271) (lshiftrt:V4SI (reg:V4SI 272) (subreg:V4SI (reg:OI 250 [ vect_array.1112 ]) 0))) frameworks/base/include/utils/BitSet.h:36 -1 (nil)) frameworks/base/libs/ui/Input.cpp:866:1: internal compiler error: in extract_insn, at recog.c:2123 Reducing the optimization level to -O2 or omitting -mfpu=neon allows the compile to proceed.
[Bug gcov-profile/52376] New: [4.7 regression] ICE in lto_input_tree_ref, at lto-streamer-in.c:266 while linking LTO-PGO libxul
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52376 Bug #: 52376 Summary: [4.7 regression] ICE in lto_input_tree_ref, at lto-streamer-in.c:266 while linking LTO-PGO libxul Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: gcov-profile AssignedTo: unassig...@gcc.gnu.org ReportedBy: mar...@trippelsdorf.de While linking libxul of a LTO-PGO Firefox build, I get this ICE: ... In member function ‘HandleComment’: lto1: internal compiler error: in lto_input_tree_ref, at lto-streamer-in.c:266 Please submit a full bug report, with preprocessed source if appropriate. Delta reduction points to a single input object file: /var/tmp/mozilla-central/moz-build-dir/content/xml/document/src/nsXMLContentSink.o % c++ -fprofile-use -flto -fno-fat-lto-objects -c -o nsXMLContentSink.o -I../../../../dist/stl_wrappers -I../../../../dist/system_wrappers -include /var/tmp/mozilla-central/config/gcc_hidden.h -DMOZ_GLUE_IN_PROGRAM -DMOZILLA_INTERNAL_API -D_IMPL_NS_COM -DEXPORT_XPT_API -DEXPORT_XPTC_API -D_IMPL_NS_GFX -D_IMPL_NS_WIDGET -DIMPL_XREAPI -DIMPL_NS_NET -DIMPL_THEBES -DSTATIC_EXPORTABLE_JS_API -DOSTYPE=\Linux3.3\ -DOSARCH=Linux -D_IMPL_NS_LAYOUT -I/var/tmp/mozilla-central/content/xml/document/src -I/var/tmp/mozilla-central/content/xml/document/src/../../../xsl/document/src -I/var/tmp/mozilla-central/content/xml/document/src/../../../html/document/src -I/var/tmp/mozilla-central/content/xml/document/src/../../../../layout/style -I/var/tmp/mozilla-central/content/xml/document/src/../../../base/src -I/var/tmp/mozilla-central/content/xml/document/src/../../../xul/content/src -I/var/tmp/mozilla-central/content/xml/document/src/../../../events/src -I/var/tmp/mozilla-central/content/xml/document/src/../../../../dom/base -I/var/tmp/mozilla-central/content/xml/document/src/../../../../caps/include -I/var/tmp/mozilla-central/xpcom/ds -I/var/tmp/mozilla-central/content/xml/document/src -I. -I../../../../dist/include -I../../../../dist/include/nsprpub -I/var/tmp/mozilla-central/moz-build-dir/dist/include/nspr -I/var/tmp/mozilla-central/moz-build-dir/dist/include/nss -fPIC -fno-rtti -pedantic -Wall -Wpointer-arith -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wcast-align -Wno-invalid-offsetof -Wno-variadic-macros -Werror=return-type -Wno-long-long -march=native -Wno-delete-non-virtual-dtor -fpermissive -fno-exceptions -fno-strict-aliasing -std=gnu++0x -pthread -ffunction-sections -fdata-sections -pipe -DNDEBUG -DTRIMMED -O3 -fomit-frame-pointer -DMOZILLA_CLIENT -include ../../../../mozilla-config.h -MD -MF .deps/nsXMLContentSink.pp /var/tmp/mozilla-central/content/xml/document/src/nsXMLContentSink.cpp % c++ -flto nsXMLContentSink.o In member function ‘HandleComment’: lto1: internal compiler error: in lto_input_tree_ref, at lto-streamer-in.c:266 Please submit a full bug report, The error above only happens with -fprofile-use and -fno-fat-lto-objects. With -fprofile-use -flto I get: ... /var/tmp/mozilla-central/content/xml/document/src/nsXMLContentSink.cpp: In member function ‘nsXMLContentSink::HandleComment(unsigned short const*)’: /var/tmp/mozilla-central/content/xml/document/src/nsXMLContentSink.cpp:1195:54: internal compiler error: in emit_move_insn, at expr.c:3435 But I don't know how to reduce the testcase further, because it depends on nsXMLContentSink.gcda data.
[Bug gcov-profile/52376] [4.7 regression] ICE in lto_input_tree_ref, at lto-streamer-in.c:266 while linking LTO-PGO libxul
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52376 --- Comment #1 from Markus Trippelsdorf markus at trippelsdorf dot de 2012-02-24 19:42:43 UTC --- Created attachment 26745 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26745 nsXMLContentSink.o
[Bug middle-end/52201] FAIL: 29_atomics/atomic/operators/51811.cc (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52201
--- Comment #4 from Andrew Macleod amacleod at redhat dot com 2012-02-24
19:47:18 UTC ---
Created attachment 26746
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26746
disable tests if no atomic support present
That test case really shouldn't be running. To make sure we're on the right
track, add the line
// { dg-require-atomic-builtins }
at the top of the test case (patch attached for the 2 you mention)
Presumably it won't execute the test case anymore, thus avoiding the failure...
Can you give it a try?
Are those the only 2 failing? interesting.
[Bug middle-end/52375] [4.7 Regression] internal compiler error: in extract_insn, at recog.c:2123 at -O3 -mfpu=neon
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52375 Mikael Pettersson mikpe at it dot uu.se changed: What|Removed |Added CC||mikpe at it dot uu.se --- Comment #1 from Mikael Pettersson mikpe at it dot uu.se 2012-02-24 19:52:14 UTC --- On arm-linux-gnueabi this ICEs gcc 4.7 and 4.6, but not 4.5 or 4.4.
[Bug target/52352] [x32] - Wrong code to access addresses 0x80000000 to 0xFFFFFFFF using registers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52352 --- Comment #13 from H.J. Lu hjl.tools at gmail dot com 2012-02-24 20:03:59 UTC --- (In reply to comment #12) (In reply to comment #11) I checked a similar fix into hjl/x32/addr32, hjl/x32/gcc-4_6-branch and hjl/x32/gcc-4_6-branch+mx32 branches. I also added I code to print constant address as positive 32bit integer for x32: I think we can simply disable these two patterns on x32. This is with disabled patterns: x32_O3_main: 0: b8 00 00 e0 fe mov$0xfee0,%eax 5: 8b 00 mov(%rax),%eax 7: a8 01 test $0x1,%al 9: 74 01 je c x32_O3_main+0xc b: 90 nop c: b8 00 00 e0 fe mov$0xfee0,%eax 11: 8b 50 08mov0x8(%rax),%edx 14: 89 50 04mov%edx,0x4(%rax) 17: c3 retq and with enabled patterns: x32_O3_main: 0: a1 00 00 e0 fe 00 00movabs 0xfee0,%eax 7: 00 00 9: a8 01 test $0x1,%al b: 74 01 je e x32_O3_main+0xe d: 90 nop e: a1 08 00 e0 fe 00 00movabs 0xfee8,%eax 15: 00 00 17: a3 04 00 e0 fe 00 00movabs %eax,0xfee4 1e: 00 00 20: c3 retq There is simply no need for movabs from/to mem, since there is no 64bit addresses. And code size is horrible (and I bet that the former code runs faster). I think it is a good idea.
[Bug libstdc++/50349] /usr/bin/ld: warning: wildcard match appears in both version 'GLIBCXX_3.4' and 'CXXABI_1.3' in script
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50349 Benjamin Kosnik bkoz at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.7.0
[Bug middle-end/52375] [4.7 Regression] internal compiler error: in extract_insn, at recog.c:2123 at -O3 -mfpu=neon
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52375 Bernhard Rosenkränzer Bernhard.Rosenkranzer at linaro dot org changed: What|Removed |Added Attachment #26744|0 |1 is obsolete|| --- Comment #2 from Bernhard Rosenkränzer Bernhard.Rosenkranzer at linaro dot org 2012-02-24 20:35:08 UTC --- Created attachment 26747 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26747 Reduced test case Reduced test case
[Bug middle-end/52375] [4.7 Regression] internal compiler error: in extract_insn, at recog.c:2123 at -O3 -mfpu=neon
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52375 Bernhard Rosenkränzer Bernhard.Rosenkranzer at linaro dot org changed: What|Removed |Added Known to fail||4.7.0 --- Comment #3 from Bernhard Rosenkränzer Bernhard.Rosenkranzer at linaro dot org 2012-02-24 20:37:45 UTC --- Works here with the Linaro version of 4.6.3 (didn't try stock 4.6.3 yet), ICEs with stock 4.7 from a couple of days ago
[Bug middle-end/52375] [4.7 Regression] internal compiler error: in extract_insn, at recog.c:2123 at -O3 -mfpu=neon
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52375 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-02-24 Ever Confirmed|0 |1
[Bug c++/52377] New: C++11 non-static initializers in unions are not used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52377
Bug #: 52377
Summary: C++11 non-static initializers in unions are not used
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: kenwayne...@hotmail.com
Created attachment 26748
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26748
command-line output and preprocessed file
Given the following code
#include cstdio
union Test
{
int a{4};
};
int main()
{
Test t;
printf(%d, t.a);
return 0;
}
the output is all junk data, unless I specify a -O option, in which case it
prints 0. Either way, t.a is not being properly initialized to 4.
[Bug boehm-gc/48299] [4.7 Regression] FAIL: boehm-gc.c/thread_leak_test.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48299 --- Comment #16 from Jack Howarth howarth at nitro dot med.uc.edu 2012-02-25 02:23:06 UTC --- Created attachment 26749 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26749 back port of thread_leak_test.c from ivmai-bdwgc-8b168d0 The random failures in testsuite/boehm-gc.c/thread_leak_test.c on darwin are eliminated if the current structure of tests/thread_leak_test.c in ivmai-bdwgc-8b168d0 is back ported to gcc's boehm-gc. Note that the MS windows specific changes were left out. In particular... #ifdef GC_PTHREADS # include pthread.h #else # include windows.h #endif and #ifdef GC_PTHREADS void * test(void * arg) #else DWORD WINAPI test(LPVOID arg) #endif
[Bug boehm-gc/48299] [4.7 Regression] FAIL: boehm-gc.c/thread_leak_test.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48299 --- Comment #17 from Jack Howarth howarth at nitro dot med.uc.edu 2012-02-25 02:27:14 UTC --- (In reply to comment #16) Note that at r184560 with the back ported thread_leak_test.c changes applied, I am able to run the 64-bit thread_leak_test test repeatedly without failures.
[Bug target/52378] New: Can't build most recent svn version
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52378 Bug #: 52378 Summary: Can't build most recent svn version Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: l...@qtrac.plus.com I did the svn read-only checkout for trunk: : svn info Path: . URL: svn://gcc.gnu.org/svn/gcc/trunk Repository Root: svn://gcc.gnu.org/svn/gcc Repository UUID: 138bc75d-0d04-0410-961f-82ee72b054a4 Revision: 184569 Node Kind: directory Schedule: normal Last Changed Author: ian Last Changed Rev: 184569 Last Changed Date: 2012-02-25 02:11:29 + (Sat, 25 Feb 2012) This is into /home/mark/opt/gcc-svn-src I then configured with ./configure --prefix=/home/mark/opt/gcc I then did make: ... make[3]: Entering directory `/home/mark/opt/gcc-svn-src/host-x86_64-unknown-linux-gnu/gcc' gcc -g -fkeep-inline-functions -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wc++-compat -fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE -o build/gengtype \ build/gengtype.o build/errors.o build/gengtype-lex.o build/gengtype-parse.o build/gengtype-state.o build/version.o ../../build-x86_64-unknown-linux-gnu/libiberty/libiberty.a gcc -g -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wc++-compat -fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE -o build/gencheck \ build/gencheck.o ../../build-x86_64-unknown-linux-gnu/libiberty/libiberty.a build/gengtype.o: In function `create_optional_field_': /home/mark/opt/gcc-svn-src/host-x86_64-unknown-linux-gnu/gcc/../.././gcc/gengtype.c:854: undefined reference to `lexer_line' build/gengtype.o: In function `adjust_field_rtx_def': /home/mark/opt/gcc-svn-src/host-x86_64-unknown-linux-gnu/gcc/../.././gcc/gengtype.c:989: undefined reference to `lexer_line' /home/mark/opt/gcc-svn-src/host-x86_64-unknown-linux-gnu/gcc/../.././gcc/gengtype.c:1045: undefined reference to `lexer_line' /home/mark/opt/gcc-svn-src/host-x86_64-unknown-linux-gnu/gcc/../.././gcc/gengtype.c:1055: undefined reference to `lexer_line' /home/mark/opt/gcc-svn-src/host-x86_64-unknown-linux-gnu/gcc/../.././gcc/gengtype.c:1120: undefined reference to `lexer_line' build/gengtype.o:/home/mark/opt/gcc-svn-src/host-x86_64-unknown-linux-gnu/gcc/../.././gcc/gengtype.c:1159: more undefined references to `lexer_line' follow build/gengtype-parse.o: In function `token': /home/mark/opt/gcc-svn-src/host-x86_64-unknown-linux-gnu/gcc/../.././gcc/gengtype-parse.c:53: undefined reference to `yylex' build/gengtype-parse.o: In function `parse_error': /home/mark/opt/gcc-svn-src/host-x86_64-unknown-linux-gnu/gcc/../.././gcc/gengtype-parse.c:142: undefined reference to `lexer_line' /home/mark/opt/gcc-svn-src/host-x86_64-unknown-linux-gnu/gcc/../.././gcc/gengtype-parse.c:142: undefined reference to `lexer_line' build/gengtype-parse.o: In function `struct_field_seq': /home/mark/opt/gcc-svn-src/host-x86_64-unknown-linux-gnu/gcc/../.././gcc/gengtype-parse.c:692: undefined reference to `lexer_line' build/gengtype-parse.o: In function `type': /home/mark/opt/gcc-svn-src/host-x86_64-unknown-linux-gnu/gcc/../.././gcc/gengtype-parse.c:726: undefined reference to `lexer_line' /home/mark/opt/gcc-svn-src/host-x86_64-unknown-linux-gnu/gcc/../.././gcc/gengtype-parse.c:758: undefined reference to `lexer_line' build/gengtype-parse.o:/home/mark/opt/gcc-svn-src/host-x86_64-unknown-linux-gnu/gcc/../.././gcc/gengtype-parse.c:758: more undefined references to `lexer_line' follow build/gengtype-parse.o: In function `parse_file': /home/mark/opt/gcc-svn-src/host-x86_64-unknown-linux-gnu/gcc/../.././gcc/gengtype-parse.c:951: undefined reference to `yybegin' /home/mark/opt/gcc-svn-src/host-x86_64-unknown-linux-gnu/gcc/../.././gcc/gengtype-parse.c:986: undefined reference to `lexer_toplevel_done' /home/mark/opt/gcc-svn-src/host-x86_64-unknown-linux-gnu/gcc/../.././gcc/gengtype-parse.c:991: undefined reference to `yyend' collect2: ld returned 1 exit status make[3]: *** [build/gengtype] Error 1 make[3]: *** Waiting for unfinished jobs make[3]: Leaving directory `/home/mark/opt/gcc-svn-src/host-x86_64-unknown-linux-gnu/gcc' make[2]: *** [all-stage1-gcc] Error 2 make[2]: Leaving directory `/home/mark/opt/gcc-svn-src' make[1]: *** [stage1-bubble] Error 2 make[1]: Leaving directory `/home/mark/opt/gcc-svn-src' make: *** [all] Error 2 I would be happy to try to build a slightly earlier and more stable version but don't know how. (With mercurial I'd do 'hg update _an_earlier_tag' but don't know the svn equivalent if there is one.)
[Bug target/52378] Can't build most recent svn version, i.e., trunk 4.7.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52378 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2012-02-25 Ever Confirmed|0 |1 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2012-02-25 07:46:51 UTC --- ./configure I bet this is just a problem with you building in the src directory. This is not always supported and not always 100% working. Can you try building in an object directory? Also do you have flex since that is required while building from subversion (but not from the release tarballs)?
