[Bug c++/51461] New: [c++0x] [4.7 Regression] ICE with invalid initialization of static data member
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51461
Bug #: 51461
Summary: [c++0x] [4.7 Regression] ICE with invalid
initialization of static data member
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: reich...@gcc.gnu.org
The following invalid code snippet triggers an ICE on trunk when compiled with
"-std=c++0x":
=
struct A
{
static const A a = 0;
};
=
bug.cc:3:22: internal compiler error: in literal_type_p, at cp/semantics.c:5578
Please submit a full bug report, [etc.]
[Bug c++/51461] [c++0x] [4.7 Regression] ICE with invalid initialization of static data member
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51461 Volker Reichelt changed: What|Removed |Added Keywords||ice-on-invalid-code Target Milestone|--- |4.7.0
[Bug c++/51462] New: [c++0x] ICE in cx_check_missing_mem_inits
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51462
Bug #: 51462
Summary: [c++0x] ICE in cx_check_missing_mem_inits
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: reich...@gcc.gnu.org
The following invalid code snippet triggers an ICE on trunk:
=
struct A
{
int i = 0;
};
struct B
{
A a;
constexpr B() : a(0) {}
};
=
bug.cc: In constructor 'constexpr B::B()':
bug.cc:9:22: error: no matching function for call to 'A::A(int)'
bug.cc:9:22: note: candidates are:
bug.cc:1:8: note: constexpr A::A()
bug.cc:1:8: note: candidate expects 0 arguments, 1 provided
bug.cc:1:8: note: constexpr A::A(const A&)
bug.cc:1:8: note: no known conversion for argument 1 from 'int' to 'const A&'
bug.cc:1:8: note: constexpr A::A(A&&)
bug.cc:1:8: note: no known conversion for argument 1 from 'int' to 'A&&'
bug.cc:9:25: internal compiler error: in cx_check_missing_mem_inits, at
cp/semantics.c:5999
Please submit a full bug report, [etc.]
[Bug c++/51463] New: [c++0x] [4.7 Regression] ICE declaring a member function virtual and static
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51463
Bug #: 51463
Summary: [c++0x] [4.7 Regression] ICE declaring a member
function virtual and static
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: reich...@gcc.gnu.org
The following invalid code snippet triggers an ICE on trunk when compiled with
"-std=c++0x":
==
struct A
{
virtual static int i = 0;
};
==
bug.cc:3:26: error: member 'i' cannot be declared both virtual and static
bug.cc:3:26: error: 'i' declared as a 'virtual' field
bug.cc:4:1: internal compiler error: tree check: expected default_arg, have
integer_cst in cp_parser_late_parse_one_default_arg, at cp/parser.c:21781
Please submit a full bug report, [etc.]
[Bug c++/51463] [c++0x] [4.7 Regression] ICE declaring a member function virtual and static
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51463 Volker Reichelt changed: What|Removed |Added Keywords||error-recovery, ||ice-checking, ||ice-on-invalid-code Target Milestone|--- |4.7.0
[Bug c++/51464] New: [c++0x] ICE with invalid use of []
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51464
Bug #: 51464
Summary: [c++0x] ICE with invalid use of []
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: reich...@gcc.gnu.org
The following invalid code snippet triggers an ICE since GCC 4.5.0:
===
template struct A {};
===
bug.cc:1:23: error: lambda-expression in unevaluated context
bug.cc:1:24: error: definition of 'struct' inside template parameter
list
bug.cc:1:24: internal compiler error: tree check: expected class 'type', have
'exceptional' (error_mark) in begin_lambda_type, at cp/semantics.c:8609
Please submit a full bug report, [etc.]
[Bug lto/48437] [4.6/4.7 Regression] LTO crashes with block-local function declarations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48437 --- Comment #5 from Richard Guenther 2011-12-08 08:50:40 UTC --- Author: rguenth Date: Thu Dec 8 08:50:35 2011 New Revision: 182100 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182100 Log: 2011-12-08 Richard Guenther PR lto/48437 * lto-streamer-out.c (tree_is_indexable): Exclude block-local extern declarations. * gcc.dg/lto/20111207-2_0.c: New testcase. * gcc.dg/guality/pr48437.c: Likewise. Added: trunk/gcc/testsuite/gcc.dg/guality/pr48437.c trunk/gcc/testsuite/gcc.dg/lto/20111207-2_0.c Modified: trunk/gcc/ChangeLog trunk/gcc/lto-streamer-out.c trunk/gcc/testsuite/ChangeLog
[Bug lto/48437] [4.6 Regression] LTO crashes with block-local function declarations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48437 Richard Guenther changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||4.7.0 Resolution||FIXED Target Milestone|4.6.3 |4.7.0 Summary|[4.6/4.7 Regression] LTO|[4.6 Regression] LTO |crashes with block-local|crashes with block-local |function declarations |function declarations Known to fail||4.6.2 --- Comment #6 from Richard Guenther 2011-12-08 08:51:54 UTC --- Fixed on trunk, I'll not backport this kind of patches (for -flto -g, that is).
[Bug middle-end/39509] [4.4 Regression] bad optimization(?) pure virtual function call with -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39509 Richard Guenther changed: What|Removed |Added Known to work||4.5.2, 4.6.2, 4.7.0 Summary|[4.4/4.5/4.6/4.7|[4.4 Regression] bad |Regression] bad |optimization(?) pure |optimization(?) pure|virtual function call with |virtual function call with |-O2 |-O2 | --- Comment #24 from Richard Guenther 2011-12-08 08:55:29 UTC --- Works with 4.5 and 4.6 because tree-ssa-sink.c is basically "broken" for memory there (after alias improvements merge). That was fixed for 4.7 which was in turn broken again for this testcase which indeed was fixed by Michas patch. Thus, a 4.4. regression only now.
[Bug rtl-optimization/48496] [4.7 Regression] 'asm' operand requires impossible reload in libffi/src/ia64/ffi.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48496 Jakub Jelinek changed: What|Removed |Added Status|WAITING |NEW CC||bernds at gcc dot gnu.org, ||jakub at gcc dot gnu.org, ||uweigand at gcc dot gnu.org --- Comment #8 from Jakub Jelinek 2011-12-08 08:57:16 UTC --- Can be still reproduced with current trunk, at least on the short testcase.
[Bug tree-optimization/49772] [4.7 Regression] ICE: in ipa_pta_execute, at tree-ssa-structalias.c:6790 with -fipa-pta
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49772
--- Comment #11 from rguenther at suse dot de
2011-12-08 08:57:22 UTC ---
On Thu, 8 Dec 2011, pinskia at gcc dot gnu.org wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49772
>
> --- Comment #10 from Andrew Pinski 2011-12-08
> 04:54:41 UTC ---
> A better non specific to tree-ssa-structaliasing patch:
> Index: cgraphunit.c
> ===
> --- cgraphunit.c(revision 182098)
> +++ cgraphunit.c(working copy)
> @@ -1817,6 +1817,9 @@ cgraph_expand_function (struct cgraph_no
>/* Generate RTL for the body of DECL. */
>tree_rest_of_compilation (decl);
>
> + if (seen_error ())
> +return;
> +
>/* Make sure that BE didn't give up on compiling. */
>gcc_assert (TREE_ASM_WRITTEN (decl));
>current_function_decl = NULL;
> Index: passes.c
> ===
> --- passes.c(revision 182098)
> +++ passes.c(working copy)
> @@ -2074,7 +2074,7 @@ execute_one_pass (struct opt_pass *pass)
> timevar_push (pass->tv_id);
>
>/* Do it! */
> - if (pass->execute)
> + if (pass->execute && !seen_error ())
> {
>todo_after = pass->execute ();
>do_per_function (clear_last_verified, NULL);
We don't want late warnings in random functions to be suppressed
by earlier errors.
[Bug tree-optimization/51315] [4.6/4.7 regression] unaligned memory accesses generated with -ftree-sra
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51315 --- Comment #10 from Eric Botcazou 2011-12-08 09:05:42 UTC --- Author: ebotcazou Date: Thu Dec 8 09:05:38 2011 New Revision: 182102 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182102 Log: PR tree-optimization/51315 * tree.h (get_object_or_type_alignment): Declare. * expr.c (get_object_or_type_alignment): Move to... * builtins.c (get_object_or_type_alignment): ...here. Add assertion. * tree-sra.c (tree_non_mode_aligned_mem_p): Rename to... (tree_non_aligned_mem_p): ...this. Add ALIGN parameter. Look into MEM_REFs and use get_object_or_type_alignment for them. (build_accesses_from_assign): Adjust for above change. (access_precludes_ipa_sra_p): Likewise. Added: trunk/gcc/testsuite/gcc.c-torture/execute/20111208-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/builtins.c trunk/gcc/expr.c trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-sra.c trunk/gcc/tree.h
[Bug c++/51461] [c++0x] [4.7 Regression] ICE with invalid initialization of static data member
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51461 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-12-08 CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from Jakub Jelinek 2011-12-08 09:11:08 UTC --- Started with http://gcc.gnu.org/viewcvs?view=revision&revision=173683 aka PR48948.
[Bug tree-optimization/51315] [4.6/4.7 regression] unaligned memory accesses generated with -ftree-sra
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51315 --- Comment #11 from Eric Botcazou 2011-12-08 09:12:15 UTC --- Author: ebotcazou Date: Thu Dec 8 09:12:12 2011 New Revision: 182103 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182103 Log: PR tree-optimization/51315 * tree-sra.c (tree_non_mode_aligned_mem_p): Rename to... (tree_non_aligned_mem_p): ...this. Add ALIGN parameter. Look into MEM_REFs and use get_object_or_type_alignment for them. (build_accesses_from_assign): Adjust for above change. (access_precludes_ipa_sra_p): Likewise. ada/ Backport from mainline 2011-09-25 Eric Botcazou * gcc-interface/decl.c (gnat_to_gnu_entity) : Do not promote the alignment if this doesn't prevent BLKmode access to the object. Added: branches/gcc-4_6-branch/gcc/testsuite/gcc.c-torture/execute/20111208-1.c - copied unchanged from r182102, trunk/gcc/testsuite/gcc.c-torture/execute/20111208-1.c branches/gcc-4_6-branch/gcc/testsuite/gnat.dg/frame_overflow.ads - copied unchanged from r182090, trunk/gcc/testsuite/gnat.dg/frame_overflow.ads Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/ada/ChangeLog branches/gcc-4_6-branch/gcc/ada/gcc-interface/decl.c branches/gcc-4_6-branch/gcc/testsuite/ChangeLog branches/gcc-4_6-branch/gcc/testsuite/gnat.dg/frame_overflow.adb branches/gcc-4_6-branch/gcc/testsuite/gnat.dg/specs/addr1.ads branches/gcc-4_6-branch/gcc/tree-sra.c
[Bug c++/51416] [c++0x] [4.6/4.7 Regression] ICE with invalid use of auto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51416 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-12-08 CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from Jakub Jelinek 2011-12-08 09:15:21 UTC --- Started with http://gcc.gnu.org/viewcvs?view=revision&revision=163896
[Bug tree-optimization/51315] [4.6/4.7 regression] unaligned memory accesses generated with -ftree-sra
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51315 Eric Botcazou changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #12 from Eric Botcazou 2011-12-08 09:18:55 UTC --- Reopen if not.
[Bug ada/48835] Porting GNAT to GNU/Linux/m68k
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48835 --- Comment #48 from Mikael Pettersson 2011-12-08 09:25:55 UTC --- (In reply to comment #47) > (In reply to comment #42) > > -O2 -W -Wall -gnatpg -nostdinc a-assert.adb -o a-assert.o > > +===GNAT BUG DETECTED==+ > > | 4.7.0 20111203 (experimental) (m68k-unknown-linux) GCC error:| > > | in fp_size_to_prec, at ada/gcc-interface/misc.c:781 | > > This is caused by the float changes in r177137 plus the enumerate_modes fix in > r177141 (without the latter it won't compile). I instrumented fp_prec_to_size and fp_size_to_prec to log who called them with what parameters and what they then computed, and saw something strange: fp_prec_to_size_(32, /tmp/gcc-4.7-r177137/gcc/ada/gcc-interface/targtyps.c, 116): mode 27 prec 32 bitsize 32 fp_prec_to_size_(32, /tmp/gcc-4.7-r177137/gcc/ada/gcc-interface/targtyps.c, 116): mode 27 prec 32 bitsize 32 fp_prec_to_size_(64, /tmp/gcc-4.7-r177137/gcc/ada/gcc-interface/targtyps.c, 122): mode 27 prec 32 bitsize 32 fp_prec_to_size_(64, /tmp/gcc-4.7-r177137/gcc/ada/gcc-interface/targtyps.c, 122): mode 28 prec 64 bitsize 64 fp_prec_to_size_(80, /tmp/gcc-4.7-r177137/gcc/ada/gcc-interface/targtyps.c, 128): mode 27 prec 32 bitsize 32 fp_prec_to_size_(80, /tmp/gcc-4.7-r177137/gcc/ada/gcc-interface/targtyps.c, 128): mode 28 prec 64 bitsize 64 fp_prec_to_size_(80, /tmp/gcc-4.7-r177137/gcc/ada/gcc-interface/targtyps.c, 128): mode 29 prec 80 bitsize 96 fp_prec_to_size_(80, /tmp/gcc-4.7-r177137/gcc/ada/gcc-interface/decl.c, 401): mode 27 prec 32 bitsize 32 fp_prec_to_size_(80, /tmp/gcc-4.7-r177137/gcc/ada/gcc-interface/decl.c, 401): mode 28 prec 64 bitsize 64 fp_prec_to_size_(80, /tmp/gcc-4.7-r177137/gcc/ada/gcc-interface/decl.c, 401): mode 29 prec 80 bitsize 96 gnat_to_gnu_entity: esize 80 max_esize 96 LONG_DOUBLE_TYPE_SIZE 80 fp_size_to_prec_(80, /tmp/gcc-4.7-r177137/gcc/ada/gcc-interface/decl.c, 1842): mode 27 bitsize 32 prec 32 fp_size_to_prec_(80, /tmp/gcc-4.7-r177137/gcc/ada/gcc-interface/decl.c, 1842): mode 28 bitsize 64 prec 64 fp_size_to_prec_(80, /tmp/gcc-4.7-r177137/gcc/ada/gcc-interface/decl.c, 1842): mode 29 bitsize 96 prec 80 +===GNAT BUG DETECTED==+ | 4.7.0 20110802 (experimental) (m68k-unknown-linux-gnu) GCC error:| | in fp_size_to_prec_, at ada/gcc-interface/misc.c:793 | That is, first ada maps precisions 32, 64, and 80 to bit sizes 32, 64, and 96, respectively. Then ada turns around and tries to map _bit_size_ 80 to a precision, but bit size 80 doesn't exist so fp_size_to_prec() asserts. Did something confuse precision with bit size somewhere?
[Bug middle-end/51460] [4.6/4.7 Regression] Struct with two boost mutexes allocated on the heap inside of a while loop causes compiler segfault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51460 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-12-08 Component|c++ |middle-end Target Milestone|--- |4.6.3 Summary|[4.6 regression] Struct |[4.6/4.7 Regression] Struct |with two boost mutexes |with two boost mutexes |allocated on the heap |allocated on the heap |inside of a while loop |inside of a while loop |causes compiler segfault|causes compiler segfault Ever Confirmed|0 |1 --- Comment #4 from Richard Guenther 2011-12-08 10:05:34 UTC --- Confirmed with -O1. Program received signal SIGSEGV, Segmentation fault. 0x00bb9511 in VEC_edge_base_index (vec_=0x752e2cf8, ix_=0, file_=Cannot access memory at address 0x7f7feff8 ) at /space/rguenther/src/svn/gcc-4_6-branch/gcc/basic-block.h:64 64 DEF_VEC_P(edge); (gdb) bt #1 0x00bb9500 in ei_edge (i=...) at /space/rguenther/src/svn/gcc-4_6-branch/gcc/basic-block.h:671 #2 0x00bb942d in ei_cond (ei=..., p=0x7f7ff0e8) at /space/rguenther/src/svn/gcc-4_6-branch/gcc/basic-block.h:692 #3 0x00bbdd75 in predict_paths_for_bb (cur=0x719a3888, bb=0x71b2f270, pred=PRED_CONTINUE, taken=NOT_TAKEN) at /space/rguenther/src/svn/gcc-4_6-branch/gcc/predict.c:1801 #4 0x00bbdda6 in predict_paths_for_bb (cur=0x71b2f270, bb=0x71b2f270, pred=PRED_CONTINUE, taken=NOT_TAKEN) at /space/rguenther/src/svn/gcc-4_6-branch/gcc/predict.c:1836 ... we endlessly recurse in predict_paths_for_bb walking for (son = first_dom_son (CDI_POST_DOMINATORS, cur); son; son = next_dom_son (CDI_POST_DOMINATORS, son)) predict_paths_for_bb (son, bb, pred, taken); (we never do anything else in the loop above it). Sequence of recursion is (cur, bb): (7, 9) (3, 3) (9, 9) (7, 9) ... ;; basic block 2, loop depth 0, count 0 ;; prev block 0, next block 9 ;; pred: ENTRY (fallthru,exec) ;; succ: 9 [100.0%] (fallthru) : ;; basic block 9, loop depth 1, count 0 ;; prev block 2, next block 3 ;; pred: 2 [100.0%] (fallthru) 7 (fallthru,exec) ;; succ: 3 [100.0%] (fallthru,exec) 8 (eh,exec) : f_1 = operator new (80); D.102841_9 = &f_1->bar; boost::mutex::mutex (D.102841_9); ;; basic block 3, loop depth 1, count 0 ;; prev block 9, next block 4 ;; pred: 9 [100.0%] (fallthru,exec) ;; succ: 7 [100.0%] (fallthru,exec) 4 (eh,exec) : D.102840_10 = &f_1->baz; boost::mutex::mutex (D.102840_10); goto ; ;; basic block 7, loop depth 1, count 0 ;; prev block 6, next block 8 ;; pred: 3 [100.0%] (fallthru,exec) ;; succ: 9 (fallthru,exec) : // predicted unlikely by continue predictor. goto ; ... so it seems post-dominators do not honor EH-edges, or at least it is inconsistent with the way we add fake exit edges for infinite loops.
[Bug java/51465] New: internal compiler error: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51465 Bug #: 51465 Summary: internal compiler error: Segmentation fault Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: java AssignedTo: unassig...@gcc.gnu.org ReportedBy: gykar...@all.hu Created attachment 26020 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26020 Two File : BugZilla_Err_Msg.txt & cntanMegMinden.s Helo, I like to make native .exe file from a Java application. I make a Jar file from Java classes and I like to compile - link this for .exe file. This is all on Windows 7 and CygWin envirnment. But I give the above error message for command line: gcj -v -Wextra -mwindows -fassert -mwin32 -fno-strict-aliasing -fwrapv -save-temps --main=com.all .alldio.dlr.main.WindowStarterClassLocal -o cntanMegMinden.exe cntanMegMinden.jar
[Bug c++/51459] [4.7 Regression] 'double free or corruption' involving std::function and lambdas
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51459 Richard Guenther changed: What|Removed |Added Target Milestone|--- |4.7.0
[Bug middle-end/51446] -fno-trapping-math generates NaN constant with different sign
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51446 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-12-08 Component|tree-optimization |middle-end Ever Confirmed|0 |1 --- Comment #4 from Richard Guenther 2011-12-08 10:10:17 UTC --- (In reply to comment #3) > I've looked through the code in real.c a bit (and perhaps the component of > this > bug report should be changed). > > It appears that do_divide, when given 0.0/0.0, calls get_canonical_qnan with > sign=0 (line 816 in real.c), but divsd actually returns a qnan with sign bit = > 1. > > Similarly, do_add when given Inf - Inf, calls get_canonical_qnan with sign bit > = 0 (line 574 of real.c), while subsd returns a qnan with sign bit = 1. > > It seems that the sign bit in this situation should be target-dependent if you > want the constants to match what the actual instructions will provide. Interesting. Does IEEE say anything about the sign of the qnan? Do the architecture manuals say anything about the sign of the qnan?
[Bug libstdc++/51456] gcc-4.5.3 ARM misaligned relocation for __gxx_personality_v0 in libstdc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51456 Richard Earnshaw changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #4 from Richard Earnshaw 2011-12-08 10:41:09 UTC --- http://infocenter.arm.com/help/topic/com.arm.doc.ihi0044d/IHI0044D_aaelf.pdf (in section 4.7.1.3) states that R_ARM_ABS32 should work for a relocation place with any alignment.
[Bug middle-end/51460] [4.6/4.7 Regression] Struct with two boost mutexes allocated on the heap inside of a while loop causes compiler segfault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51460
Richard Guenther changed:
What|Removed |Added
Known to work||4.5.3
Known to fail||4.6.2, 4.7.0
--- Comment #5 from Richard Guenther 2011-12-08
10:43:21 UTC ---
Reduced testcase that fails with both 4.7 and 4.6:
class mx {
public:
mx();
};
int main()
{
while (true) {
mx *bar = new mx;
mx *baz = new mx;
continue;
}
return 0;
}
4.5 happens to work.
[Bug target/51393] Wrong parameter type for _mm256_insert_epi64 in avxintrin.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51393 --- Comment #9 from Jakub Jelinek 2011-12-08 10:43:18 UTC --- Author: jakub Date: Thu Dec 8 10:43:13 2011 New Revision: 182106 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182106 Log: Backported from mainline 2011-12-04 Jérémie Detrey PR target/51393 * config/i386/avxintrin.h (_mm256_insert_epi64): Declare second parameter as long long. 2011-12-04 Uros Bizjak Jérémie Detrey PR target/51393 * gcc.target/i386/pr51393.c: New test. Added: branches/gcc-4_4-branch/gcc/testsuite/gcc.target/i386/pr51393.c Modified: branches/gcc-4_4-branch/gcc/ChangeLog branches/gcc-4_4-branch/gcc/config/i386/avxintrin.h branches/gcc-4_4-branch/gcc/testsuite/ChangeLog
[Bug middle-end/51460] [4.6/4.7 Regression] Struct with two boost mutexes allocated on the heap inside of a while loop causes compiler segfault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51460 Richard Guenther changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #6 from Richard Guenther 2011-12-08 10:58:54 UTC --- For the reduced testcase we recurse endlessly through /* If there is non-abnormal path leaving e->src, predict edge using predictor. Otherwise we need to look for paths leading to e->src. */ if (found) predict_edge_def (e, pred, taken); else predict_paths_for_bb (e->src, e->src, pred, taken); instead. That recursion is new in 4.6. I think it wants to recurse not to e->src but get_immediate_dominator (CDI_DOMINATORS, cur) (outside of the loop?) Caused by rev. 161691, thus Honza.
[Bug c++/51464] [c++0x] ICE with invalid use of []
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51464 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011-12-08 AssignedTo|unassigned at gcc dot |paolo.carlini at oracle dot |gnu.org |com Target Milestone|--- |4.7.0 Ever Confirmed|0 |1 --- Comment #1 from Paolo Carlini 2011-12-08 11:09:08 UTC --- On it.
[Bug c++/51459] [4.7 Regression] 'double free or corruption' involving std::function and lambdas
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51459
--- Comment #3 from Jonathan Wakely 2011-12-08
11:26:55 UTC ---
sans library:
struct func {
virtual ~func() { }
virtual void operator()() const = 0;
virtual func* clone() const = 0;
};
template
struct funcimpl : func {
explicit funcimpl(T t) : t(t) { }
void operator()() const { t(); }
func* clone() const { return new funcimpl(*this); }
T t;
};
struct function
{
func* p;
template
function(T t) : p(new funcimpl(t)) { }
~function() { delete p; }
function(const function& f) : p(f.p->clone()) { }
function& operator=(const function& ) = delete;
void operator()() const { (*p)(); }
};
template
function animate(F f) { return [=]{ f(); }; }
int main()
{
function linear1 = []{};
function av(animate(linear1));
av();
}
[Bug tree-optimization/49772] [4.7 Regression] ICE: in ipa_pta_execute, at tree-ssa-structalias.c:6790 with -fipa-pta
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49772
--- Comment #12 from Richard Guenther 2011-12-08
11:39:21 UTC ---
It's a complete mystery to me how this cgraph node cloning and edge code
works. We create the inline clone for a completely different edge
(that _is_ decided to be inlined) than the one we later fail on
(that one is _not_ marked inline and does _not_ have an inline clone callee).
Thus, we shouldn't arrive at this situation at all. Instead we seem to fail
to inline a call that we should inline (and decided to inline) because of:
/* Expand calls to inline functions in the body of FN. */
unsigned int
optimize_inline_calls (tree fn)
{
...
/* There is no point in performing inlining if errors have already
occurred -- and we might crash if we try to inline invalid
code. */
if (seen_error ())
return 0;
which leaves us with such state.
So this is yet another case of overeager fail to complete our task.
I suppose we can remove that late fail now that we bail out way earlier
at proper IPA "scope".
The ICE is fixed with removing the above out.
[Bug middle-end/49945] [4.7 Regression] gcc.dg/guality/vla-1.c FAILs with -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49945 --- Comment #7 from Richard Guenther 2011-12-08 11:43:16 UTC --- Author: rguenth Date: Thu Dec 8 11:43:12 2011 New Revision: 182107 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182107 Log: 2011-12-08 Richard Guenther PR lto/49945 * lto-streamer-out.c (tree_is_indexable): Localize variably modified types and their FIELD_DECLs. Modified: trunk/gcc/ChangeLog trunk/gcc/lto-streamer-out.c
[Bug c++/51459] [4.7 Regression] 'double free or corruption' involving std::function and lambdas
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51459 Paolo Carlini changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |NEW Last reconfirmed||2011-12-08 CC||jason at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #4 from Paolo Carlini 2011-12-08 11:55:05 UTC --- Thanks a lot Jon, I was hoping for somebody like *you* doing this ;) Anyway, the issue seems serious.
[Bug c++/51459] [4.7 Regression] 'double free or corruption' involving std::function and lambdas
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51459
--- Comment #5 from Jakub Jelinek 2011-12-08
11:55:48 UTC ---
Indeed, with 4.6.x preprocessed source for the reduced testcase this started
failing with http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175158 aka
PR43912.
The only important difference at *.gimple level (except for renaming arguments
and similar debug info only related changes) seems to be:
-animate(F) [with F = std::function]:: (const struct
__lambda0 * this)
+animate(F) [with F = std::function]:: (const struct
__lambda0 * __closure)
{
- const struct function * D.9363;
+ const struct function * D.9367;
+ const struct function * D.9368;
+ const struct function f [value-expr: __closure->__f];
- D.9363 = &this->__f;
- std::function::operator() (D.9363);
+ try
+{
+ D.9367 = &__closure->__f;
+ std::function::operator() (D.9367);
+}
+ finally
+{
+ D.9368 = &__closure->__f;
+ std::function::~function (D.9368);
+}
}
so before this change __closure->__f wouldn't be destructed, now it is, and
supposedly it is destructed in the caller too.
[Bug other/39933] make clean fails in libgcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39933 Dave Korn changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-12-08 CC||davek at gcc dot gnu.org Version|4.4.0 |4.7.0 Ever Confirmed|0 |1 Known to fail||4.4.0 --- Comment #3 from Dave Korn 2011-12-08 12:08:34 UTC --- Still present on HEAD at r.182098, with some minor differences in the error messages for me: make[1]: -B/n/10/davek/usr/x86_64-unknown-linux-gnu/bin/: Command not found make[1]: Entering directory `/home/davek/gcc/obj.clean/x86_64-unknown-linux-gnu/libgcc' make[1]: -B/n/10/davek/usr/x86_64-unknown-linux-gnu/bin/: Command not found make[1]: -B/n/10/davek/usr/x86_64-unknown-linux-gnu/bin/: Command not found /bin/sh: line 0: test: !=: unary operator expected rm -f config.h libgcc_tm.h stamp-h stmp-ldirs libgcc.map Makefile:165: *** Recursive variable `AR_FOR_TARGET' references itself (eventually). Stop. make[1]: Leaving directory `/home/davek/gcc/obj.clean/x86_64-unknown-linux-gnu/libgcc' make: *** [clean-stage3-target-libgcc] Error 2
[Bug other/39933] make clean fails in libgcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39933 Dave Korn changed: What|Removed |Added CC||ich at az2000 dot de --- Comment #4 from Dave Korn 2011-12-08 12:10:28 UTC --- *** Bug 40322 has been marked as a duplicate of this bug. ***
[Bug other/40322] make clean fails (/bin/bash: -/: invalid option)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40322 Dave Korn changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||davek at gcc dot gnu.org Resolution||DUPLICATE --- Comment #1 from Dave Korn 2011-12-08 12:10:28 UTC --- Same as bug 39933. *** This bug has been marked as a duplicate of bug 39933 ***
[Bug other/45994] During 'make clean', some variables not propagating properly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45994 Dave Korn changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||davek at gcc dot gnu.org Resolution||DUPLICATE --- Comment #1 from Dave Korn 2011-12-08 12:10:35 UTC --- Same as bug 39933. *** This bug has been marked as a duplicate of bug 39933 ***
[Bug other/39933] make clean fails in libgcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39933 Dave Korn changed: What|Removed |Added CC||phantall at gmail dot com --- Comment #5 from Dave Korn 2011-12-08 12:10:35 UTC --- *** Bug 45994 has been marked as a duplicate of this bug. ***
[Bug middle-end/41043] [4.4 Regression] virtual memory exhausted: Cannot allocate memory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41043 --- Comment #15 from Dominique d'Humieres 2011-12-08 12:15:58 UTC --- > Probably not a very good idea for backporting this late. IIUC 4.4 will no longer be supported soon. Is there still some plan to backport the fix or can I close this PR as fixed?
[Bug lto/50747] [4.7 Regression] ICE in produce_symtab, at lto-streamer-out.c:1435
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50747 --- Comment #6 from Richard Guenther 2011-12-08 12:32:24 UTC --- Author: rguenth Date: Thu Dec 8 12:32:19 2011 New Revision: 182108 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182108 Log: 2011-12-08 Richard Guenther PR lto/50747 * lto-streamer-out.c (produce_symtab): Remove asserts. * g++.dg/opt/pr50747-1_0.C: New testcase. * g++.dg/opt/pr50747-2_0.C: Likewise. Added: trunk/gcc/testsuite/g++.dg/opt/pr50747-1_0.C trunk/gcc/testsuite/g++.dg/opt/pr50747-2_0.C Modified: trunk/gcc/ChangeLog trunk/gcc/lto-streamer-out.c trunk/gcc/testsuite/ChangeLog
[Bug middle-end/49945] [4.7 Regression] gcc.dg/guality/vla-1.c FAILs with -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49945 Richard Guenther changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #8 from Richard Guenther 2011-12-08 12:32:59 UTC --- Fixed.
[Bug lto/50747] [4.7 Regression] ICE in produce_symtab, at lto-streamer-out.c:1435
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50747 Richard Guenther changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #7 from Richard Guenther 2011-12-08 12:32:37 UTC --- Fixed.
[Bug tree-optimization/51315] [4.6/4.7 regression] unaligned memory accesses generated with -ftree-sra
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51315 --- Comment #13 from Georg-Johann Lay 2011-12-08 12:38:41 UTC --- Author: gjl Date: Thu Dec 8 12:38:35 2011 New Revision: 182109 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182109 Log: PR tree-optimization/51315 * gcc.c-torture/execute/20111208-1.c: Fix wrong assumption sizeof(int)==4. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.c-torture/execute/20111208-1.c
[Bug tree-optimization/49772] [4.7 Regression] ICE: in ipa_pta_execute, at tree-ssa-structalias.c:6790 with -fipa-pta
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49772 --- Comment #13 from Richard Guenther 2011-12-08 13:23:59 UTC --- Author: rguenth Date: Thu Dec 8 13:23:54 2011 New Revision: 182110 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182110 Log: 2011-12-08 Richard Guenther PR tree-optimization/49772 * tree-inline.c (optimize_inline_calls): Remove bail out on errors. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-inline.c
[Bug tree-optimization/49772] [4.7 Regression] ICE: in ipa_pta_execute, at tree-ssa-structalias.c:6790 with -fipa-pta
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49772 Richard Guenther changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Comment #14 from Richard Guenther 2011-12-08 13:25:50 UTC --- Fixed.
[Bug rtl-optimization/48721] [4.6 Regression] ICE: verify_flow_info failed: missing barrier after block 6 with -foptimize-sibling-calls -fsched2-use-superblocks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48721 --- Comment #13 from Jakub Jelinek 2011-12-08 13:34:02 UTC --- Author: jakub Date: Thu Dec 8 13:33:58 2011 New Revision: 182111 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182111 Log: Backport from mainline 2011-11-30 Jakub Jelinek PR rtl-optimization/48721 * sched-deps.c (sched_analyze_insn): For SIBLING_CALL_P set reg_pending_barrier to TRUE_BARRIER. * gcc.target/i386/pr48721.c: New test. Added: branches/gcc-4_6-branch/gcc/testsuite/gcc.target/i386/pr48721.c Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/sched-deps.c branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
[Bug middle-end/51323] [4.6 Regression] g++ confuses this with function argument in optimized call
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51323 --- Comment #12 from Jakub Jelinek 2011-12-08 13:36:46 UTC --- Author: jakub Date: Thu Dec 8 13:36:40 2011 New Revision: 182112 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182112 Log: Backport from mainline 2011-12-05 Jakub Jelinek Eric Botcazou PR middle-end/51323 PR middle-end/50074 * calls.c (internal_arg_pointer_exp_state): New variable. (internal_arg_pointer_based_exp_1, internal_arg_pointer_exp_scan): New functions. (internal_arg_pointer_based_exp): New function. (mem_overlaps_already_clobbered_arg_p): Use it. (expand_call): Free internal_arg_pointer_exp_state.cache vector and clear internal_arg_pointer_exp_state.scan_start. 2011-11-26 Joern Rennecke PR middle-end/50074 * calls.c (mem_overlaps_already_clobbered_arg_p): Return false if no outgoing arguments have been stored so far. 2011-12-05 Jakub Jelinek Eric Botcazou PR middle-end/51323 PR middle-end/50074 * gcc.c-torture/execute/pr51323.c: New test. Added: branches/gcc-4_6-branch/gcc/testsuite/gcc.c-torture/execute/pr51323.c Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/calls.c branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
[Bug middle-end/50074] [4.7 Regression] gcc.dg/sibcall-6.c execution test on x86_64 with -fPIC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50074 --- Comment #20 from Jakub Jelinek 2011-12-08 13:36:46 UTC --- Author: jakub Date: Thu Dec 8 13:36:40 2011 New Revision: 182112 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182112 Log: Backport from mainline 2011-12-05 Jakub Jelinek Eric Botcazou PR middle-end/51323 PR middle-end/50074 * calls.c (internal_arg_pointer_exp_state): New variable. (internal_arg_pointer_based_exp_1, internal_arg_pointer_exp_scan): New functions. (internal_arg_pointer_based_exp): New function. (mem_overlaps_already_clobbered_arg_p): Use it. (expand_call): Free internal_arg_pointer_exp_state.cache vector and clear internal_arg_pointer_exp_state.scan_start. 2011-11-26 Joern Rennecke PR middle-end/50074 * calls.c (mem_overlaps_already_clobbered_arg_p): Return false if no outgoing arguments have been stored so far. 2011-12-05 Jakub Jelinek Eric Botcazou PR middle-end/51323 PR middle-end/50074 * gcc.c-torture/execute/pr51323.c: New test. Added: branches/gcc-4_6-branch/gcc/testsuite/gcc.c-torture/execute/pr51323.c Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/calls.c branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
[Bug c/51339] [4.6 Regression] ICE: in convert_move, at expr.c:326 with -fopenmp and parallel for
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51339 --- Comment #5 from Jakub Jelinek 2011-12-08 13:37:48 UTC --- Author: jakub Date: Thu Dec 8 13:37:44 2011 New Revision: 182113 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182113 Log: Backport from mainline 2011-12-05 Jakub Jelinek PR c/51339 * c-decl.c (c_finish_incomplete_decl, finish_decl): Call relayout_decl instead of layout_decl. * gcc.dg/gomp/pr51339.c: New test. Added: branches/gcc-4_6-branch/gcc/testsuite/gcc.dg/gomp/pr51339.c Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/c-decl.c branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
[Bug debug/51410] [4.5/4.6 Regression] duplicate variable DIE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51410 --- Comment #5 from Jakub Jelinek 2011-12-08 13:39:38 UTC --- Author: jakub Date: Thu Dec 8 13:39:34 2011 New Revision: 182114 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182114 Log: Backport from mainline 2011-12-05 Jakub Jelinek PR debug/51410 * c-decl.c (pop_scope): Don't add DECL_EXTERNAL decls for debug info if scope is file_scope. * gcc.dg/debug/dwarf2/pr51410.c: New test. Added: branches/gcc-4_6-branch/gcc/testsuite/gcc.dg/debug/dwarf2/pr51410.c Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/c-decl.c branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
[Bug middle-end/51323] [4.6 Regression] g++ confuses this with function argument in optimized call
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51323 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #13 from Jakub Jelinek 2011-12-08 13:41:53 UTC --- Fixed.
[Bug rtl-optimization/48721] [4.6 Regression] ICE: verify_flow_info failed: missing barrier after block 6 with -foptimize-sibling-calls -fsched2-use-superblocks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48721 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #14 from Jakub Jelinek 2011-12-08 13:42:18 UTC --- Fixed.
[Bug c/51339] [4.6 Regression] ICE: in convert_move, at expr.c:326 with -fopenmp and parallel for
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51339 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #6 from Jakub Jelinek 2011-12-08 13:41:28 UTC --- Fixed.
[Bug tree-optimization/51315] [4.6/4.7 regression] unaligned memory accesses generated with -ftree-sra
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51315 --- Comment #14 from Georg-Johann Lay 2011-12-08 13:57:51 UTC --- Author: gjl Date: Thu Dec 8 13:57:43 2011 New Revision: 182115 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182115 Log: * gcc.c-torture/execute/20111208-1.c (int16_t): Use __INT16_TYPE__ for typedef. (int32_t): Use __INT32_TYPE__ for typedef. PR tree-optimization/51315 Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.c-torture/execute/20111208-1.c
[Bug tree-optimization/51466] New: [4.7 Regression] ICE in gimple_rhs_has_side_effects,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51466
Bug #: 51466
Summary: [4.7 Regression] ICE in gimple_rhs_has_side_effects,
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ja...@gcc.gnu.org
int
foo (int i)
{
volatile int v[4];
int *p;
v[i] = 6;
p = (int *) &v[i];
return *p;
}
int
bar (int i)
{
volatile int v[4];
int *p;
v[i] = 6;
p = (int *) &v[i];
*p = 8;
return v[i];
}
int
baz (int i)
{
volatile int v[4];
int *p;
v[i] = 6;
p = (int *) &v[0];
*p = 8;
return v[i];
}
ICEs with current trunk at -O2 (well, just foo, bar & baz are an unsuccessful
attempt to reproduce something similar on the lhs).
[Bug middle-end/51446] -fno-trapping-math generates NaN constant with different sign
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51446 --- Comment #5 from lucier at math dot purdue.edu 2011-12-08 14:30:00 UTC --- Re: Do the architecture manuals say anything about the sign of the qnan? Amazingly enough, they do! I downloaded the combined x86-64 manuals from http://www.intel.com/content/www/us/en/architecture-and-technology/64-ia-32-architectures-software-developer-manual-325462-rmver.html and found the following: Table 4-3: Floating-point number and NaN encodings: QNaN Floating-point indefinite: sign is 1 Section 4.8.3.7: Description of QNaN for floating-point indefinite Section 8.5.1.2: 0/0, 0*Inf, Inf-Inf, etc., return this QNaN floating-point indefinite. So at least for Intel x87 processors, the sign bit of the canonical QNaN for floating-point indefinite should be 1.
[Bug middle-end/51446] -fno-trapping-math generates NaN constant with different sign
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51446 --- Comment #6 from lucier at math dot purdue.edu 2011-12-08 14:31:23 UTC --- PS: I don't know whether IEEE says anything about the sign bit, but I doubt it. Brad
[Bug middle-end/50199] [4.7 Regression] wrong code with -flto -fno-merge-constants
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50199 --- Comment #4 from Richard Guenther 2011-12-08 14:37:14 UTC --- Which means - taking addresses of literals should be disallowed (that includes the prominent example of STRING_CSTs, but possibly that is not the only existing case?). Instead when a literal needs its address taken it needs to be put into a CONST_DECL of which we can take the address (thus, entered into the "constant pool"). Those CONST_DECLs should be entered into the varpool so that we properly partition them with LTO. The C frontend is probably the oldest and most prominent offender of creating ADDR_EXPR . GIMPLE-side "fix": Index: gimple.c === --- gimple.c(revision 182107) +++ gimple.c(working copy) @@ -2903,9 +2903,7 @@ is_gimple_id (tree t) return (is_gimple_variable (t) || TREE_CODE (t) == FUNCTION_DECL || TREE_CODE (t) == LABEL_DECL - || TREE_CODE (t) == CONST_DECL - /* Allow string constants, since they are addressable. */ - || TREE_CODE (t) == STRING_CST); + || TREE_CODE (t) == CONST_DECL); } (and watch it explode, obviously) Probably not 4.7 material to change though.
[Bug target/50395] Infinite loop when bootstrapping java
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50395 --- Comment #1 from Andreas Krebbel 2011-12-08 14:37:24 UTC --- Author: krebbel Date: Thu Dec 8 14:37:19 2011 New Revision: 182116 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182116 Log: 2011-12-08 Andreas Krebbel PR target/50395 * config/s390/s390.c (s390_mainpool_finish): Emit the jump over the literal pool as jump insn. Modified: trunk/gcc/ChangeLog trunk/gcc/config/s390/s390.c
[Bug tree-optimization/51466] [4.7 Regression] ICE in gimple_rhs_has_side_effects,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51466 --- Comment #1 from Jakub Jelinek 2011-12-08 14:45:44 UTC --- Created attachment 26021 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26021 gcc47-pr51466.patch Possible fix. Though, I wonder if this isn't unnecessarily pessimistic. The reason why we ICE is because when clearing TREE_THIS_VOLATILE on the new_rhs, we don't also clear TREE_SIDE_EFFECTS. So another alternative would be perhaps to also copy TREE_SIDE_EFFECTS in all the 4 places where we currently copy TREE_THIS_VOLATILE. That fixes this too.
[Bug middle-end/50199] [4.7 Regression] wrong code with -flto -fno-merge-constants
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50199
--- Comment #5 from Richard Guenther 2011-12-08
15:02:34 UTC ---
Created attachment 26022
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26022
gimple predicate patches
GIMPLE predicate patches - that will now commit STRING_CSTs to a local
temporary via the
static enum gimplify_status
gimplify_addr_expr (tree *expr_p, gimple_seq *pre_p, gimple_seq *post_p)
{
...
default:
/* We use fb_either here because the C frontend sometimes takes
the address of a call that returns a struct; see
gcc.dg/c99-array-lval-1.c. The gimplifier will correctly make
the implied temporary explicit. */
/* Make the operand addressable. */
ret = gimplify_expr (&TREE_OPERAND (expr, 0), pre_p, post_p,
is_gimple_addressable, fb_either);
which is of course bogus.
[Bug other/51467] New: Stack Smashing Protector: Canary is destroyed in RAX partially only on x86_64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51467 Bug #: 51467 Summary: Stack Smashing Protector: Canary is destroyed in RAX partially only on x86_64 Classification: Unclassified Product: gcc Version: 4.4.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassig...@gcc.gnu.org ReportedBy: ogm256-fo...@yahoo.de Created attachment 26023 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26023 Sample code vuln.c and its corresponding assembly code vuln-with-ssp.s I compiled the attached vuln.c to assembly code with the following command on CentOS 6.0 on a x86_64: gcc -fstack-protector -S -o vuln-with-ssp.s vuln.c In the assembly code the canary is put on the stack as follows: ... movq%fs:40, %rax movq%rax, -8(%rbp) xorl%eax, %eax ... The canary is a 64 bit value as %rax indicates. Unfortunately only the lower 32 bit of the canary in %rax are destroyed because the xor operation takes effect on %eax only. In my opinion to leave no hint on the canary to an attacker the whole canary should be destroyed in %rax.
[Bug target/50395] Infinite loop when bootstrapping java
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50395 Andreas Krebbel changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #2 from Andreas Krebbel 2011-12-08 15:12:30 UTC --- Fixed per comment above.
[Bug other/51467] Stack Smashing Protector: Canary is destroyed in RAX partially only on x86_64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51467 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution||INVALID --- Comment #1 from Jakub Jelinek 2011-12-08 15:21:16 UTC --- Please read the AMD64 architecture manuals. xorl %eax, %eax is just a shorter alternative to xorq %rax, %rax, both clear all 64 bits of that register.
[Bug middle-end/51446] -fno-trapping-math generates NaN constant with different sign
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51446 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #7 from kargl at gcc dot gnu.org 2011-12-08 15:29:17 UTC --- (In reply to comment #6) > PS: I don't know whether IEEE says anything about the sign bit, but I doubt > it. > > Brad 6.3 The Sign Bit This standard does not interpret the sign of an NaN. -- steve
[Bug tree-optimization/51466] [4.7 Regression] ICE in gimple_rhs_has_side_effects,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51466 Jakub Jelinek changed: What|Removed |Added Attachment #26021|0 |1 is obsolete|| --- Comment #2 from Jakub Jelinek 2011-12-08 15:32:20 UTC --- Created attachment 26024 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26024 gcc47-pr51466.patch Another alternative. Note that apparently gimple_rhs_has_side_effects has been removed in the mean time, still having TREE_SIDE_EFFECTS consistent doesn't hurt.
[Bug tree-optimization/51466] [4.7 Regression] ICE in gimple_rhs_has_side_effects,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51466 --- Comment #3 from Richard Guenther 2011-12-08 15:41:50 UTC --- (In reply to comment #2) > Created attachment 26024 [details] > gcc47-pr51466.patch > > Another alternative. Note that apparently gimple_rhs_has_side_effects has > been > removed in the mean time, still having TREE_SIDE_EFFECTS consistent doesn't > hurt. Hm, well. It doesn't hurt, yes. But maybe it confuses people as to what is actually needed to be kept up-to-date? (that's not 100% clear to me either - GIMPLE at least does not care about TREE_SIDE_EFFECTS, though older RTL expansion code might).
[Bug ada/48835] Porting GNAT to GNU/Linux/m68k
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48835 --- Comment #49 from Eric Botcazou 2011-12-08 16:00:34 UTC --- > That is, first ada maps precisions 32, 64, and 80 to bit sizes 32, 64, and 96, > respectively. Then ada turns around and tries to map _bit_size_ 80 to a > precision, but bit size 80 doesn't exist so fp_size_to_prec() asserts. Did > something confuse precision with bit size somewhere? No, but the new code (cstand.adb:Register_Float_Type) makes an invalid assumption about the size of a FP mode given its precision and alignment, instead of using the proper interface. enumerate_modes should probably pass GET_MODE_BITSIZE to its callback. I'd suggest opening a new regression PR for this problem.
[Bug other/51467] Stack Smashing Protector: Canary is destroyed in RAX partially only on x86_64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51467 --- Comment #2 from Oliver Mueller 2011-12-08 16:04:17 UTC --- Oh yes! It's the "promoted to 64 bit" thing. I forgot. Sorry.
[Bug middle-end/51446] -fno-trapping-math generates NaN constant with different sign
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51446 --- Comment #8 from Dominique d'Humieres 2011-12-08 16:06:43 UTC --- > Does IEEE say anything about the sign of the qnan? >From "Draft 1.2.5 DRAFT Standard for Floating-Point Arithmetic P754 October 4, 2006" at http://www.validlab.com/754R/drafts/archive/2006-10-04.pdf : 8.2.1 NaN encodings in binary formats ... All binary NaN bitstrings have all the bits of the biased exponent field E set to 1 (see 5.4). A quiet NaN bitstring should be encoded with the first bit (d1) of the trailing significand field T being 1. A signaling NaN bitstring should be encoded with the first bit of the trailing significand field being 0. If the first bit of the trailing significand is 0, some other bit of the trailing significand field must be non-zero to distinguish the NaN from infinity. In the preferred encoding, a signaling NaN should be quieted by setting d1 to 1, leaving the remaining bits of T unchanged. ... 8.3 The sign bit 8.3.0 When either an input or result is NaN, this standard does not interpret the sign of a NaN. Note however that operations on bitstrings – copy, negate, abs, copySign – specify the sign bit of a NaN result, sometimes based upon the sign bit of a NaN operand. The logical predicate totalOrder is also affected by the sign bit of a NaN operand. For all other operations, this standard does not specify the sign bit of a NaN result, even when there is only one input NaN, or when the NaN is produced from an invalid operation. ...
[Bug c++/51468] New: cannot find -ldl and collect 2 ld returned 1 exit status
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51468 Bug #: 51468 Summary: cannot find -ldl and collect 2 ld returned 1 exit status Classification: Unclassified Product: gcc Version: 4.4.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: dwi...@wwwalker.com.au When I run a build using scons build script with g++ and -ldl switch, it returns cannot find -ldl and collect 2 ld returned 1 exit status and compile fails to build an exe. I am using g++ in mingw on Windows 7.
[Bug c++/51468] cannot find -ldl and collect 2 ld returned 1 exit status
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51468 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2011-12-08 Ever Confirmed|0 |1 --- Comment #1 from Jonathan Wakely 2011-12-08 16:33:43 UTC --- Why do you think it's a g++ bug? Please follow the bug reporting guidelines, your report doesn't have enough information for anyone to help. http://gcc.gnu.org/bugs/
[Bug rtl-optimization/51374] [avr] insn combine reorders volatile memory accesses
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51374
Georg-Johann Lay changed:
What|Removed |Added
Known to work|4.7.0 |
Known to fail||4.7.0
--- Comment #5 from Georg-Johann Lay 2011-12-08
16:40:28 UTC ---
This bug also affects 4.7.0 but up to now, the problem for 4.7 is hidden behind
PR51425 because avr-gcc 4.7 fails to produce SBIS/SBIC instructions altogether.
Smaller test case:
void __vector_18 (void)
{
extern char slot;
unsigned char status = (*(volatile unsigned char*) 0x2B);
unsigned char data = (*(volatile unsigned char*) 0x2C);
if (status & 0x10)
slot = 0;
}
[Bug debug/51262] [4.7 Regression] ICE: SIGSEGV in primary_template_instantiation_p (pt.c:2874) with -flto -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51262
Richard Guenther changed:
What|Removed |Added
CC||dodji at gcc dot gnu.org,
||jason at gcc dot gnu.org
--- Comment #3 from Richard Guenther 2011-12-08
16:46:41 UTC ---
Program received signal SIGSEGV, Segmentation fault.
0x00569d33 in primary_template_instantiation_p (t=0x75b8f930)
at /space/rguenther/src/svn/trunk/gcc/cp/pt.c:2874
2874 else if (CLASS_TYPE_P (t) && !TYPE_DECL_ALIAS_P (TYPE_NAME (t)))
(gdb)
but TYPE_NAME (t) is NULL:
(gdb) call debug_tree (t)
constant 64>
unit size constant 8>
align 64 symtab -173746304 alias set -1 canonical type 0x75b8f930
fields
sizes-gimplified asm_written unsigned type_6 DI size unit size
align 64 symtab -173747024 alias set -1 canonical type
0x75a472a0>
used unsigned nonlocal decl_3 DI file t.C line 6 col 12 size
unit size
align 64 offset_align 128
offset
bit offset context > context
full-name "union"
X() X(constX&) this=(X&)
chain >
cleared by the C++ free_lang_data langhook:
if (CP_AGGREGATE_TYPE_P (t)
&& TYPE_NAME (t))
{
tree name = TYPE_NAME (t);
if (TREE_CODE (name) == TYPE_DECL)
name = DECL_NAME (name);
/* Drop anonymous names. */
if (name != NULL_TREE
&& ANON_AGGRNAME_P (name))
TYPE_NAME (t) = NULL_TREE;
the type is anonymous before:
chain >
does not have DECL_LANG_FLAG_6 set (TYPE_DECL_ALIAS_P).
Dodji, Jason, can such anonymous name types ever have TYPE_DECL_ALIAS_P
set? Thus, is a valid fix
Index: pt.c
===
--- pt.c(revision 182117)
+++ pt.c(working copy)
@@ -2871,7 +2871,8 @@ primary_template_instantiation_p (const_
return DECL_LANG_SPECIFIC (t)
&& DECL_TEMPLATE_INSTANTIATION (t)
&& PRIMARY_TEMPLATE_P (DECL_TI_TEMPLATE (t));
- else if (CLASS_TYPE_P (t) && !TYPE_DECL_ALIAS_P (TYPE_NAME (t)))
+ else if (CLASS_TYPE_P (t)
+ && TYPE_NAME (t) && !TYPE_DECL_ALIAS_P (TYPE_NAME (t)))
return CLASSTYPE_TEMPLATE_INSTANTIATION (t)
&& PRIMARY_TEMPLATE_P (CLASSTYPE_TI_TEMPLATE (t));
else if (TYPE_P (t)
?
Technically clearing the anonymous names is probably no longer necessary,
I'm testing a patch to remove that.
[Bug middle-end/51446] -fno-trapping-math generates NaN constant with different sign
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51446 --- Comment #9 from lucier at math dot purdue.edu 2011-12-08 17:05:43 UTC --- Table 4.7 of the AMD64 Architecture Programmer’s Manual Volume 1: Application Programming has a footnote 3 that says 3. The floating-point indefinite value is a QNaN with a negative sign and a significand whose value is 1.100 ... 000. Table 4.8 gives the encodings for all the indefinite values again.
[Bug c++/51468] cannot find -ldl and collect 2 ld returned 1 exit status
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51468 --- Comment #2 from Dwight Walker 2011-12-08 17:07:52 UTC --- QtSDK 1.1.4 built GCC (Mingw) Windows 7 Home Premium C:\Users\Dwight\Downloads\nokia\ZXing-1.7\zxing\cpp>c:\python27\python scons\sco ns.py scons: Reading SConscript files ... scons: done reading SConscript files. scons: Building targets ... g++ -o build\testrunner.exe -ldl build\core\tests\src\TestRunner.o build\core\te sts\src\common\BitArrayTest.o build\core\tests\src\common\BitMatrixTest.o build\ core\tests\src\common\BitSourceTest.o build\core\tests\src\common\BlackPointEsti matorTest.o build\core\tests\src\common\CountedTest.o build\core\tests\src\commo n\PerspectiveTransformTest.o build\core\tests\src\qrcode\ErrorCorrectionLevelTes t.o build\core\tests\src\qrcode\FormatInformationTest.o build\core\tests\src\qrc ode\VersionTest.o build\core\tests\src\common\reedsolomon\ReedSolomonTest.o buil d\core\tests\src\qrcode\decoder\DataMaskTest.o build\core\tests\src\qrcode\decod er\ModeTest.o build\libzxing.a -lcppunit c:/qtsdk2/mingw/bin/../lib/gcc/mingw32/4.4.0/../../../../mingw32/bin/ld.exe: can not find -ldl collect2: ld returned 1 exit status scons: *** [build\testrunner.exe] Error 1 scons: building terminated because of errors. I think the dl library is not in the path. I cannot set the path for the gcc so that is why the library is not found and the compile fails.
[Bug c++/51468] cannot find -ldl and collect 2 ld returned 1 exit status
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51468 --- Comment #3 from Jonathan Wakely 2011-12-08 17:23:24 UTC --- (In reply to comment #2) > I think the dl library is not in the path. I cannot set the path for the gcc > so > that is why the library is not found and the compile fails. If you can add -ldl why can't you add -L/path/to/lib ?
[Bug tree-optimization/51117] [4.7 regression] rev.181172 causes glibc build failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51117
Jakub Jelinek changed:
What|Removed |Added
Status|REOPENED|ASSIGNED
AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org
|gnu.org |
--- Comment #5 from Jakub Jelinek 2011-12-08
17:24:27 UTC ---
Created attachment 26025
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26025
gcc47-pr51117.patch
Untested fix. This improves e.g.:
struct A { char buf[64]; };
void bar (A *);
void
foo ()
{
{
A a;
bar (&a);
if (a.buf[13])
throw 1;
}
{
A b;
bar (&b);
if (b.buf[13])
throw 2;
}
}
back to 4.6 generated code quality, but it doesn't already e.g.:
struct A
{
char buf[64];
};
void bar (A *);
void
foo ()
{
A c;
bar (&c);
try
{
{
A a;
bar (&a);
if (a.buf[13])
throw 1;
else if (a.buf[52])
throw 3;
}
{
A b;
bar (&b);
if (b.buf[13])
throw 2;
}
}
catch ( ...)
{
throw;
}
}
I think it should be safe to move the clobbers to the EH destination of the
!stmt_can_throw_external (stmt) GIMPLE_RESX for that, but am not 100% sure
about that yet and would prefer to do it incrementally anyway.
[Bug c++/51468] cannot find -ldl and collect 2 ld returned 1 exit status
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51468 --- Comment #4 from Dwight Walker 2011-12-08 17:40:16 UTC --- C:\Users\Dwight>gcc -v Using built-in specs. Target: i686-w64-mingw32 Configured with: ../gcc44-svn/configure --target=i686-w64-mingw32 --host=i686-w6 4-mingw32 --disable-multilib --disable-nls --disable-win32-registry --prefix=/mi ngw32 --with-gmp=/mingw32 --with-mpfr=/mingw32 --enable-languages=c,c++ Thread model: win32 gcc version 4.4.3 (GCC) I don't know what library dlopen etc are in. I am googling it. Surely there is a simple config (bat file, .ini, config file, command line switch) I can use to fix this bug.
[Bug c++/51468] cannot find -ldl and collect 2 ld returned 1 exit status
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51468 Andrew Pinski changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID --- Comment #5 from Andrew Pinski 2011-12-08 17:42:54 UTC --- MIngw does not have dlopen, they have the windows shared library APIs.
[Bug c++/51468] cannot find -ldl and collect 2 ld returned 1 exit status
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51468 --- Comment #6 from Dwight Walker 2011-12-08 18:18:54 UTC --- http://code.google.com/p/dlfcn-win32/ I can't get it to work with mingw: gcc -ldlfcn -> not found Libraries on Mingw are in about 10 different folders. I may use cygwin. Linux may be better for this C++ development for Nokia Qt. I only have a Windows PC. I have MSYS which helps a little with configuring Cppunit.
[Bug c++/51468] cannot find -ldl and collect 2 ld returned 1 exit status
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51468 --- Comment #7 from Jonathan Wakely 2011-12-08 18:24:36 UTC --- (In reply to comment #6) > I can't get it to work with mingw: Bugzilla is for bugs, "I can't get it to work" is not a bug. Please find a more suitable forum for seeking help with this problem. > gcc -ldlfcn -> not found -l is for linking to libraries, but dlfcn is a function, not a library. If you've downloaded that dlfcn package you should be able to link using -ldl and -Lblah/lib where blah is the location of the dlfcn files.
[Bug c++/51459] [4.7 Regression] 'double free or corruption' involving std::function and lambdas
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51459 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |jason at gcc dot gnu.org |gnu.org |
[Bug middle-end/51446] -fno-trapping-math generates NaN constant with different sign
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51446 --- Comment #10 from lucier at math dot purdue.edu 2011-12-08 18:32:56 UTC --- Near the end of section 5.3.2 of Book E: Enhanced PowerPC Architecture Version 1.0 May 7, 2002 it says Any instruction that generates a QNaN as the result of a disabled Invalid Operation must generate this QNaN (i.e., 0x7FF8___). The string x7ff8 does not otherwise occur in the manual. The book PowerPC User Instruction Set Architecture Book I Version 2.02 January 28, 2005 has the same text. And a small test on my 10-year-old Mac Cube with a G4 powerpc processor shows that the results have sign bit = 0, i.e., the output is 9221120237041090560 9221120237041090560 So the result is architecture dependent. Blah. Brad
[Bug c++/51468] cannot find -ldl and collect 2 ld returned 1 exit status
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51468 --- Comment #8 from Dwight Walker 2011-12-08 18:35:46 UTC --- I guess your system does not work in Windows very well. It is a bug as the libraries are not installing properly but I can't give you exact reason.
[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 #4 from toon at gcc dot gnu.org 2011-12-08 18:38:39 UTC --- Author: toon Date: Thu Dec 8 18:38:32 2011 New Revision: 182127 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182127 Log: 2011-12-08 Toon Moene PR fortran/51310 * invoke.texi: Itemize the cases for which -finit-= doesn't work. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/invoke.texi
[Bug middle-end/51460] [4.6/4.7 Regression] Struct with two boost mutexes allocated on the heap inside of a while loop causes compiler segfault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51460 Andrew Pinski changed: What|Removed |Added Keywords||ice-on-valid-code Depends on||48600 --- Comment #7 from Andrew Pinski 2011-12-08 18:38:46 UTC --- I think this is a dup of bug 48600 which also deals with predict_paths_for_bb .
[Bug libgcj/50053] [4.7 regression] SIGSEGV in natClass.cc:651
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50053 --- Comment #6 from gee 2011-12-08 18:45:46 UTC --- Created attachment 26026 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26026 generated zip file
[Bug c++/51468] cannot find -ldl and collect 2 ld returned 1 exit status
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51468 --- Comment #9 from Jonathan Wakely 2011-12-08 18:46:13 UTC --- The libraries you're trying to use are nothing to do with GCC, talk to the MinGW people, or to the person who wrote that dlfcn wrapper - it's nothing to do with GCC. If you have the libraries installed and you use the correct -L option it will work, but if you do it wrong it won't work, that's not GCC's fault.
[Bug libgcj/50053] [4.7 regression] SIGSEGV in natClass.cc:651
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50053 --- Comment #7 from gee 2011-12-08 18:47:29 UTC --- Created attachment 26027 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26027 generated tree from gnu.zip /tmp/gcc/host-i686-pc-cygwin/gcc/jc1.exe -fhash-synchronization -fuse-divide-subroutine -fcheck-references -fuse-boehm-gc -fkeep-inline-functions -mtune=generic -march=pentiumpro -g -O2 -Wno-deprecated -version -ffloat-store -fno-omit-frame-pointer -fencoding=UTF-8 -fbootstrap-classes -fsource-filename=/tmp/gcc/i686-pc-mingw32/libjava/classpath/lib/classes -fbootclasspath=./:../.././libjava/classpath/lib/ gnu.zip -fdump-tree-optimized
[Bug libgcj/50053] [4.7 regression] SIGSEGV in natClass.cc:651
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50053 --- Comment #8 from gee 2011-12-08 18:49:10 UTC --- Created attachment 26028 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26028 generated rtl from gnu.zip /tmp/gcc/host-i686-pc-cygwin/gcc/jc1.exe -fno-shrink-wrap -quiet -fhash-synchronization -fuse-divide-subroutine -fcheck-references -fuse-boehm-gc -fkeep-inline-functions -g -Wno-deprecated -version -ffloat-store -fno-omit-frame-pointer -fencoding=UTF-8 -fbootstrap-classes -fsource-filename=/tmp/gcc/i686-pc-mingw32/libjava/classpath/lib/classes -fbootclasspath=./:../.././libjava/classpath/lib/ gnu.zip -fdump-rtl-expand;cat gnu.zip.150r.expand |grep "cx \[ this \]"
[Bug fortran/51448] [4.6/4.7 Regression] Compiler crash when assigning floating point values of different kinds
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51448 --- Comment #3 from Tobias Burnus 2011-12-08 18:51:33 UTC --- Author: burnus Date: Thu Dec 8 18:51:28 2011 New Revision: 182131 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182131 Log: 2011-12-08 Tobias Burnus PR fortran/51448 * fortran/trans-array.c (get_std_lbound): Fix handling of conversion functions. 2011-12-08 Tobias Burnus PR fortran/51448 * gfortran.dg/realloc_on_assign_8.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/realloc_on_assign_8.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-array.c trunk/gcc/testsuite/ChangeLog
[Bug libfortran/51407] Use of BOZ edit descriptors to edit real and complex data and F2008
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51407 --- Comment #1 from Tobias Burnus 2011-12-08 18:54:31 UTC --- Author: burnus Date: Thu Dec 8 18:54:27 2011 New Revision: 182132 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182132 Log: 2011-12-08 Tobias Burnus PR fortran/51407 * io/transfer.c (require_numeric_type): New function. (formatted_transfer_scalar_read, formatted_transfer_scalar_write): Use it, allow BOZ edit descriptors with F2008. 2011-12-08 Tobias Burnus PR fortran/51407 * gfortran.dg/io_real_boz_3.f90: New. * gfortran.dg/io_real_boz_4.f90: New. * gfortran.dg/io_real_boz_5.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/io_real_boz_3.f90 trunk/gcc/testsuite/gfortran.dg/io_real_boz_4.f90 trunk/gcc/testsuite/gfortran.dg/io_real_boz_5.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/testsuite/ChangeLog
[Bug middle-end/39825] sigsegv compiling ffmpeg svn
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39825 Sean McGovern changed: What|Removed |Added CC||gseanmcg at gmail dot com --- Comment #7 from Sean McGovern 2011-12-08 18:55:21 UTC --- GCC 4.3 has not supported for some time now, and FFMPEG currently builds successfully on PPC Linux with GCC 4.5 (see http://fate.ffmpeg.org/). Please close this bug.
[Bug fortran/51378] [OOP] Structure constructor wrongly rejects parent components if only child has PRIVATE comps
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51378 --- Comment #1 from Tobias Burnus 2011-12-08 18:57:01 UTC --- Author: burnus Date: Thu Dec 8 18:56:58 2011 New Revision: 182133 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182133 Log: 2011-12-08 Tobias Burnus PR fortran/51378 * symbol.c (gfc_find_component): Fix access check of parent components. 2011-12-08 Tobias Burnus PR fortran/51378 * gfortran.dg/private_type_14.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/private_type_14.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/symbol.c trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/51469] New: attr-ifunc-* tests fail on PowerPC if --enable-gnu-indirect-function is used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51469 Bug #: 51469 Summary: attr-ifunc-* tests fail on PowerPC if --enable-gnu-indirect-function is used Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: meiss...@gcc.gnu.org ReportedBy: meiss...@gcc.gnu.org Host: powerpc64-linux power-linux Target: powerpc64-linux Build: powerpc64-linux The tests: gcc.dg/attr-ifunc-1.c gcc.dg/attr-ifunc-3.c gcc.dg/attr-ifunc-4.c gcc.dg/attr-ifunc-5.c g++.dg/ext/attr-ifunc-1.C g++.dg/ext/attr-ifunc-2.C g++.dg/ext/attr-ifunc-3.C all fail on PowerPC linux when the compiler is configured with --enable-gnu-indirect-function I traced this down, and the problem with the tests is that the gnu indirect function (with the ifunc attribute) is in the same module as the call. The SYMBOL_REF_LOCAL bit is set for these functions. Because SYMBOL_REF_LOCAL is set, the PPC compiler assumes the call is in the same module and bypasses putting a NOP after the BL instruction, which is used to restore the TOC. Because the BL is not followed by a NOP, the assembler and linker will not create a PLT for the function and use the indirect function to return the address of the function to use for the call.
[Bug c++/41518] copy initialization of volatile objects
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41518 Sean McGovern changed: What|Removed |Added CC||gseanmcg at gmail dot com --- Comment #1 from Sean McGovern 2011-12-08 18:59:04 UTC --- GCC 4.3 has been unsupported for some time. Go ahead and close this bug. If this issue can be reproduced with a supported version of GCC, please re-open it.
[Bug middle-end/51446] -fno-trapping-math generates NaN constant with different sign
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51446 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #11 from Jakub Jelinek 2011-12-08 18:59:12 UTC --- find libgcc/config -name sfp-machine.h | xargs grep NANSIGN shows we already track it for a banch of targets, just in libgcc soft-fp configuration and not in the compiler itself. Not sure how accurrate it is on all targets, but i?86/x86_64/ia64 use negative qNaNs, others positive.
[Bug fortran/50815] ICE on allocation of deferred length character scalar dummy argument when -fbounds-check
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50815 --- Comment #3 from Tobias Burnus 2011-12-08 19:01:00 UTC --- Author: burnus Date: Thu Dec 8 19:00:55 2011 New Revision: 182134 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182134 Log: 2011-12-08 Tobias Burnus PR fortran/50815 * trans-decl.c (add_argument_checking): Skip bound checking for deferred-length strings. 2011-12-08 Tobias Burnus PR fortran/50815 * gfortran.dg/bounds_check_16.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/bounds_check_16.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-decl.c trunk/gcc/testsuite/ChangeLog trunk/libgfortran/io/transfer.c
[Bug target/29189] Error during CPP build of Mozilla
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29189 Sean McGovern changed: What|Removed |Added CC||gseanmcg at gmail dot com --- Comment #12 from Sean McGovern 2011-12-08 19:06:11 UTC --- Please close this bug, unless it is still reproducible with a supported version of GCC.
[Bug libgcj/50053] [4.7 regression] jc1 doesn't emit static initializer or initializer code for super class without -findirect-dispatch.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50053
gee changed:
What|Removed |Added
Summary|[4.7 regression] SIGSEGV in |[4.7 regression] jc1
|natClass.cc:651 |doesn't emit static
||initializer or initializer
||code for super class
||without
||-findirect-dispatch.
--- Comment #9 from gee 2011-12-08 19:12:48 UTC ---
;; Function () (_ZN3gnu3gcj7convert10Input_UTF8C1Ev, funcdef_no=47,
decl_uid=4320, cgraph_uid=94)
() (struct gnu.gcj.convert.Input_UTF8 * this)
{
:
# DEBUG D.4331 => &gnu.gcj.convert.Input_UTF8.class$$
# DEBUG D.4333 => &_CD_gnu_gcj_convert_Input_UTF8
# DEBUG D.4335 => this_3(D)
# DEBUG this => this_3(D)
# DEBUG D.10917 => &gnu.gcj.convert.BytesToUnicode.class$$
# DEBUG D.10918 => &_CD_gnu_gcj_convert_BytesToUnicode
# DEBUG D.10919 => this_3(D)
# DEBUG this => this_3(D)
# DEBUG D.10911 => &gnu.gcj.convert.IOConverter.class$$
# DEBUG D.10921 => &_CD_gnu_gcj_convert_IOConverter
# DEBUG D.10913 => this_3(D)
(this_3(D));
# DEBUG D.4339 => this_3(D)
this_3(D)->partial = 0;
# DEBUG D.4342 => this_3(D)
this_3(D)->partial_bytes_expected = 0;
return;
}
we can see there isn't any code for {static} initializer of super classes,
isn't it design flaw?
[Bug libgcj/50053] [4.7 regression] jc1 doesn't emit static initializer or initializer code for super class without -findirect-dispatch.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50053
--- Comment #10 from gee 2011-12-08 19:15:47 UTC ---
(In reply to comment #9)
whereas with -findirect-dispatch, initializer code isn't omitted.
;; Function () (_ZN3gnu3gcj7convert10Input_UTF8C1Ev, funcdef_no=47,
decl_uid=3185, cgraph_uid=94)
() (struct gnu.gcj.convert.Input_UTF8 * this)
{
int D.9476;
struct java.lang.Object * D.3210;
int #slot#2#4;
struct java.lang.Object * D.3207;
void * #ref#1#2;
struct java.lang.Object * D.3203;
void * #ref#0#0;
int * D.9474;
sizetype D.9473;
int D.9472;
void * _ref_1_2.1045;
int * iftmp.1044;
int * D.9467;
sizetype D.9466;
int D.9465;
void * _ref_1_2.1043;
int * iftmp.1042;
void gnu.gcj.convert.BytesToUnicode:: (struct
gnu.gcj.convert.BytesToUnicode *) * D.9460;
void * D.9459;
void * _ref_1_2.1041;
:
D.3203_2 = this_1(D);
#ref#1#2_3 = D.3203_2;
_ref_1_2.1041_4 = #ref#1#2_3;
D.9459_5 = _atable_gnu_gcj_convert_Input_UTF8[1];
D.9460_6 = (void gnu.gcj.convert.BytesToUnicode:: (struct
gnu.gcj.convert.BytesToUnicode *) *) D.9459_5;
D.9460_6 (_ref_1_2.1041_4);
D.3207_7 = this_1(D);
#ref#1#2_8 = D.3207_7;
#slot#2#4_9 = 0;
_ref_1_2.1043_10 = #ref#1#2_8;
if (_ref_1_2.1043_10 == 0B)
goto ;
else
goto ;
:
_Jv_ThrowNullPointerException ();
:
iftmp.1042_11 = _ref_1_2.1043_10;
D.9465_12 = _otable_gnu_gcj_convert_Input_UTF8[1];
D.9466_13 = (sizetype) D.9465_12;
D.9467_14 = iftmp.1042_11 + D.9466_13;
*D.9467_14 = #slot#2#4_9;
D.3210_15 = this_1(D);
#ref#1#2_16 = D.3210_15;
#slot#2#4_17 = 0;
_ref_1_2.1045_18 = #ref#1#2_16;
if (_ref_1_2.1045_18 == 0B)
goto ;
else
goto ;
:
_Jv_ThrowNullPointerException ();
:
iftmp.1044_19 = _ref_1_2.1045_18;
D.9476_20 = _otable_gnu_gcj_convert_Input_UTF8[2];
D.9472_21 = D.9476_20;
D.9473_22 = (sizetype) D.9472_21;
D.9474_23 = iftmp.1044_19 + D.9473_22;
*D.9474_23 = #slot#2#4_17;
:
return;
}
