[Bug target/52205] unwinding through signal handler fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52205 Eric Botcazou changed: What|Removed |Added Status|ASSIGNED|NEW AssignedTo|ebotcazou at gcc dot|unassigned at gcc dot |gnu.org |gnu.org
[Bug target/52205] unwinding through signal handler fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52205 --- Comment #11 from Eric Botcazou 2012-02-15 08:13:29 UTC --- Author: ebotcazou Date: Wed Feb 15 08:13:22 2012 New Revision: 184256 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184256 Log: PR target/51921 PR target/52205 * config/sparc/sol2-unwind.h (sparc64_is_sighandler): Add support for Solaris 11 and slightly reformat. (sparc_is_sighandler): Likewise. Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/config/sparc/sol2-unwind.h
[Bug target/51921] [4.6/4.7 regression] EH unwinding support is broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51921 --- Comment #14 from Eric Botcazou 2012-02-15 08:13:29 UTC --- Author: ebotcazou Date: Wed Feb 15 08:13:22 2012 New Revision: 184256 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184256 Log: PR target/51921 PR target/52205 * config/sparc/sol2-unwind.h (sparc64_is_sighandler): Add support for Solaris 11 and slightly reformat. (sparc_is_sighandler): Likewise. Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/config/sparc/sol2-unwind.h
[Bug target/51921] [4.6/4.7 regression] EH unwinding support is broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51921 --- Comment #13 from Eric Botcazou 2012-02-15 08:13:20 UTC --- Author: ebotcazou Date: Wed Feb 15 08:13:09 2012 New Revision: 184255 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184255 Log: PR target/51921 PR target/52205 * config/sparc/sol2-unwind.h (sparc64_is_sighandler): Add support for Solaris 11 and slightly reformat. (sparc_is_sighandler): Likewise. Modified: trunk/libgcc/ChangeLog trunk/libgcc/config/sparc/sol2-unwind.h
[Bug target/51921] [4.6/4.7 regression] EH unwinding support is broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51921 Eric Botcazou changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #15 from Eric Botcazou 2012-02-15 08:14:23 UTC --- .
[Bug target/52205] unwinding through signal handler fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52205 --- Comment #10 from Eric Botcazou 2012-02-15 08:13:20 UTC --- Author: ebotcazou Date: Wed Feb 15 08:13:09 2012 New Revision: 184255 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184255 Log: PR target/51921 PR target/52205 * config/sparc/sol2-unwind.h (sparc64_is_sighandler): Add support for Solaris 11 and slightly reformat. (sparc_is_sighandler): Likewise. Modified: trunk/libgcc/ChangeLog trunk/libgcc/config/sparc/sol2-unwind.h
[Bug tree-optimization/52256] New: CSE the memory load from both branches of if statement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52256
Bug #: 52256
Summary: CSE the memory load from both branches of if statement
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: car...@google.com
Target: arm-unknown-linux-gnueabi
In mcfutils.c of mcf from SPEC, function refresh_potential() contains following
code snippet
...
85 if( node->orientation == UP )
86 node->potential = node->basic_arc->cost +
node->pred->potential;
87 else /* == DOWN */
88 {
89 node->potential = node->pred->potential -
node->basic_arc->cost;
90 checksum++;
91 }
...
Compile it with options -march=armv7-a -mthumb -Os, gcc 4.7 generates
...
71 ldr r2, [r3, #4]
72 ldr r4, [r3, #12]
73 cmp r2, #1
74 ldr r2, [r3, #24]
75 bne .L8
76 ldr r5, [r2, #0]//common memory load
77 ldr r2, [r4, #0]//common memory load
78 addsr2, r5, r2
79 str r2, [r3, #0]
80 b .L9
81 .L8:
82 ldr r4, [r4, #0]//common memory load
83 addsr0, r0, #1
84 ldr r2, [r2, #0]//common memory load
85 subsr2, r4, r2
86 str r2, [r3, #0]
87 .L9:
...
The memory node->basic_arc->cost and node->pred->potential are loaded in both
branches of the if statement, so we can CSE them. But current gcc CSE only
node->basic_arc and node->pred.
[Bug c++/52241] Performance degradation of 447.dealII on corei7 at spec2006_base32.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52241 --- Comment #1 from Igor Zamyatin 2012-02-15 09:06:49 UTC --- BTW, this is a 4.7 regression
[Bug c++/52257] New: [C++11] switch cases accept floating point constants
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52257
Bug #: 52257
Summary: [C++11] switch cases accept floating point constants
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: daniel.krueg...@googlemail.com
gcc 4.7.0 20120211 (experimental) accepts the following program, when using
-std=c++11 (with or without -Wall -pedantic):
int main()
{
int i = 3;
switch (i) {
case 2: ;
case 3.7: ;
}
}
The program is correctly rejected when compiling w/o -std=c++11.
Nonetheless, a C++11 compiler has to reject this code. We have [stmt.switch]
p2:
"[..] Any statement within the switch statement can be labeled with one or more
case labels as follows:
case constant-expression :
where the constant-expression shall be a converted constant expression (5.19)
of the promoted type of the switch condition.[..]"
According to [expr.const] p3 we have:
"A converted constant expression of type T is a literal constant expression,
implicitly converted to type T, where the implicit conversion (if any) is
permitted in a literal constant expression and the implicit conversion
sequence contains only user-defined conversions, lvalue-to-rvalue conversions
(4.1), integral promotions (4.5), and integral conversions (4.7) other than
narrowing conversions (8.5.4)."
This clearly excludes floating-integral conversions from 4.9 [conv.fpint].
[Bug c++/51930] [4.7 regression] Explicitly instantiated template gets hidden visibility
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51930 --- Comment #7 from Philipp 2012-02-15 09:29:27 UTC --- The test struct might come from an external library I have no control of, which will make it difficult to change its visibility. Currently, I have quite some code that depends on the behaviour of gcc-4.6 and lower that won't be easy to change.
[Bug fortran/47486] gfortran -M exits with fatal error when -o option is used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47486
--- Comment #3 from Tobias Burnus 2012-02-15
09:33:45 UTC ---
Untested patch:
--- a/gcc/fortran/lang-specs.h
+++ b/gcc/fortran/lang-specs.h
@@ -68,7 +68,8 @@
{"@f95",
"f951 %i %{E:%{!cpp:%egfortran does not support -E without -cpp}}\
%{cpp:" F951_CPP_OPTIONS ";: " CPP_FORWARD_OPTIONS "} \
- %{!E:" F951_OPTIONS "}", 0, 0, 0},
+ %{!E:%{!M:%{!MM:%{!MT:%{!MQ:%{MD|MMD:" F951_OPTIONS "}}",
+ 0, 0, 0},
#undef CPP_ONLY_OPTIONS
[Bug fortran/47486] gfortran -M exits with fatal error when -o option is used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47486
--- Comment #4 from Tobias Burnus 2012-02-15
09:40:40 UTC ---
Missed some parts. Better patch - still completely untested (not even built). A
shorter version would be "%{!E:%{!M*:", which is also completely untested.
--- a/gcc/fortran/lang-specs.h
+++ b/gcc/fortran/lang-specs.h
@@ -56,3 +56,4 @@
%{cpp:" F951_CPP_OPTIONS ";: " CPP_FORWARD_OPTIONS "} \
- %{!E:" F951_OPTIONS "}", 0, 0, 0},
+ %{!E:%{!M:%{!MM:%{!MT:%{!MQ:%{!MD:%{!MMD:" F951_OPTIONS "}}}",
+ 0, 0, 0},
{".F90", "@f95-cpp-input", 0, 0, 0},
@@ -70,3 +71,4 @@
%{cpp:" F951_CPP_OPTIONS ";: " CPP_FORWARD_OPTIONS "} \
- %{!E:" F951_OPTIONS "}", 0, 0, 0},
+ %{!E:%{!M:%{!MM:%{!MT:%{!MQ:%{!MD:%{!MMD:" F951_OPTIONS "}}}",
+ 0, 0, 0},
[Bug fortran/52251] Nonadvancing I/O and the t edit descriptor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52251 --- Comment #3 from Tobias Burnus 2012-02-15 10:10:22 UTC --- I wonder whether that's a [4.2-4.7] regression (backported to 4.1) due to the patch for PR 25463. (I have not recompiled to check.) My impression is that without that patch, commen 0 might be correctly handled. The patch in PR 25463 fixed the case: write (*,'(A)',advance="no") 'ab' write (*,'(T1,A)') 'c' (should be "abc" and not "c" or "ab c" or ...) I think one needs to save the skips (for advanced='no') somewhere in dtp->u.p.current_unit as the dtp->u.p.skips are currently gone after _gfortran_st_write_done, if I understand the code correctly.
[Bug c++/51930] [4.7 regression] Explicitly instantiated template gets hidden visibility
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51930 --- Comment #8 from Jonathan Wakely 2012-02-15 10:15:06 UTC --- (In reply to comment #7) > The test struct might come from an external library I have no control of, > which > will make it difficult to change its visibility. You could declare the struct before including that library's headers and set its visibility with a pragma: #pragma GCC visibility push(default) struct test; #pragma GCC visibility pop
[Bug fortran/47486] gfortran -M exits with fatal error when -o option is used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47486
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #5 from Jakub Jelinek 2012-02-15
10:18:53 UTC ---
Can't you do
"%{E|M|MM|MT|MQ|MD|MMD:;:" F951_OPTIONS "}"
instead?
[Bug target/52258] New: __builtin_isgreaterequal is sometimes signaling on ARM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52258
Bug #: 52258
Summary: __builtin_isgreaterequal is sometimes signaling on ARM
Classification: Unclassified
Product: gcc
Version: 4.6.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: aurel...@aurel32.net
Host: armv7l-unknown-linux-gnueabihf
Target: armv7l-unknown-linux-gnueabihf
Build: armv7l-unknown-linux-gnueabihf
__builtin_isgreaterequal is supposed to be non-signaling in case a qNaN is
provided in input. It works when the function is alone, but when combined with
another test, it sometimes triggered an invalid FP exception at -O1 and above
optimization levels.
For example:
int sel_fmax (double x, double y)
{
return __builtin_isgreaterequal(x, y) || isnan(y);
}
At -O0, the corresponding assembly code is:
:
0: b580push{r7, lr}
2: b084sub sp, #16
4: af00add r7, sp, #0
6: ed87 0b02 vstrd0, [r7, #8]
a: ed87 1b00 vstrd1, [r7]
e: ed97 6b02 vldrd6, [r7, #8]
12: ed97 7b00 vldrd7, [r7]
16: eeb4 6b47 vcmp.f64d6, d7
1a: eef1 fa10 vmrsAPSR_nzcv, fpscr
1e: bfacite ge
20: 2300movge r3, #0
22: 2301movlt r3, #1
24: b2dbuxtbr3, r3
26: f083 0301 eor.w r3, r3, #1
2a: b2dbuxtbr3, r3
2c: 2b00cmp r3, #0
2e: d106bne.n 3e
30: ed97 0b00 vldrd0, [r7]
34: f7ff fffe bl 0 <__isnan>
34: R_ARM_THM_CALL __isnan
38: 4603mov r3, r0
3a: 2b00cmp r3, #0
3c: d002beq.n 44
3e: f04f 0301 mov.w r3, #1
42: e001b.n 48
44: f04f 0300 mov.w r3, #0
48: 4618mov r0, r3
4a: f107 0710 add.w r7, r7, #16
4e: 46bdmov sp, r7
50: bd80pop {r7, pc}
52: bf00nop
At -O1, the corresponding assembly code is:
:
0: b508push{r3, lr}
2: eeb4 0bc1 vcmpe.f64 d0, d1
6: eef1 fa10 vmrsAPSR_nzcv, fpscr
a: da07bge.n 1c
c: eeb0 0b41 vmov.f64d0, d1
10: f7ff fffe bl 0 <__isnan>
10: R_ARM_THM_CALL __isnan
14: 3000addsr0, #0
16: bf18it ne
18: 2001movne r0, #1
1a: bd08pop {r3, pc}
1c: f04f 0001 mov.w r0, #1
20: bd08pop {r3, pc}
22: bf00nop
Note how the vcmp.f64 is changed into a vcmpe.f64, triggering an invalid
exception. This means that a lot of the FP functions in the GNU libc trigger an
invalid exception where they should not, therefore rendering FP exceptions
unusable on ARM.
[Bug c++/51930] [4.7 regression] Explicitly instantiated template gets hidden visibility
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51930 --- Comment #9 from Jason Merrill 2012-02-15 10:53:37 UTC --- (In reply to comment #8) > You could declare the struct before including that library's headers and set > its visibility with a pragma: > > #pragma GCC visibility push(default) > struct test; > #pragma GCC visibility pop Or just wrap the #include in these pragmas. If the instantiation needs to have default visibility, presumably the library has default visibility and so should its header.
[Bug tree-optimization/46886] [4.5/4.6 Regression] wrong code with -ftree-parallelize-loops -fno-tree-ch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46886 --- Comment #12 from Richard Guenther 2012-02-15 11:05:31 UTC --- Author: rguenth Date: Wed Feb 15 11:05:26 2012 New Revision: 184263 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184263 Log: 2012-02-15 Richard Guenther Backport from mainline 2012-02-08 Richard Guenther PR tree-optimization/46886 * tree-flow.h (do_while_loop_p): Declare. * tree-ssa-loop-ch.c (do_while_loop_p): Export. * tree-parloops.c (parallelize_loops): Only parallelize do-while loops. * testsuite/libgomp.c/pr46886.c: New testcase. Added: branches/gcc-4_6-branch/libgomp/testsuite/libgomp.c/pr46886.c Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/tree-flow.h branches/gcc-4_6-branch/gcc/tree-parloops.c branches/gcc-4_6-branch/gcc/tree-ssa-loop-ch.c branches/gcc-4_6-branch/libgomp/ChangeLog
[Bug tree-optimization/46886] [4.5/4.6 Regression] wrong code with -ftree-parallelize-loops -fno-tree-ch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46886 Richard Guenther changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||4.6.3 Resolution||FIXED Target Milestone|4.5.4 |4.6.3 --- Comment #13 from Richard Guenther 2012-02-15 11:06:01 UTC --- Fixed for 4.6.3.
[Bug c++/52248] [4.7 Regression] timevar ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52248 Richard Guenther changed: What|Removed |Added Target Milestone|--- |4.7.0
[Bug tree-optimization/52256] Hoist the memory load from both branches of if statement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52256 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE Summary|CSE the memory load from|Hoist the memory load from |both branches of if |both branches of if |statement |statement --- Comment #1 from Richard Guenther 2012-02-15 11:19:55 UTC --- That's not CSE that's code hoisting. *** This bug has been marked as a duplicate of bug 23286 ***
[Bug tree-optimization/23286] missed fully redundant expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23286 --- Comment #34 from Richard Guenther 2012-02-15 11:19:55 UTC --- *** Bug 52256 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/52254] VRP does not fold (~a) & N to a ^ N if a has range [0, N]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52254 Richard Guenther changed: What|Removed |Added Severity|normal |enhancement --- Comment #2 from Richard Guenther 2012-02-15 11:21:53 UTC --- The combine stage should have access to a valueize() hook as well, to query SSA propagator/VNs lattice. That hook can maybe supply this extra info (I wanted to make VRP info persistent for some time, in SSA_NAME_PTR_INFO much like we have alignment info there which really is kind of a value-range)
[Bug middle-end/52253] wrong code generation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52253 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #3 from Richard Guenther 2012-02-15 11:31:44 UTC --- I think it's perfectly ok - we see that tbl.len is 0 and optimize based on that.
[Bug rtl-optimization/52250] [4.7 Regression] ICE: in sel_remove_bb, at sel-sched-ir.c:5213 with -fsel-sched-pipelining -fsel-sched-pipelining-outer-loops -fselective-scheduling2 and other flags
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52250 Richard Guenther changed: What|Removed |Added Target Milestone|--- |4.7.0
[Bug tree-optimization/52255] [4.7 Regression] ICE: verify_ssa failed, block does not dominate use
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52255 --- Comment #3 from Jakub Jelinek 2012-02-15 11:47:15 UTC --- The problem is that lsm doesn't cleanup unnecessary VOP PHI after changing: : # b.2_21 = PHI # .MEM_22 = PHI <.MEM_18(10), .MEM_16(8)> # prephitmp.8_6 = PHI D.1720_7 = prephitmp.8_6; D.1721_8 = D.1720_7 | 1; # .MEM_17 = VDEF <.MEM_22> c[0] = D.1721_8; b.3_10 = b.2_21 + 1; # .MEM_18 = VDEF <.MEM_17> b = b.3_10; if (b.3_10 != 0) goto ; else goto ; : goto ; into: # VUSE <.MEM_17> pretmp.7_1 = c[0]; # VUSE <.MEM_17> c_I_lsm.9_12 = c[0]; # VUSE <.MEM_17> b_lsm.10_11 = b; : # b.2_21 = PHI # .MEM_22 = PHI <.MEM_22(10), .MEM_17(8)> # prephitmp.8_6 = PHI D.1720_7 = prephitmp.8_6; D.1721_8 = D.1720_7 | 1; c_I_lsm.9_24 = D.1721_8; b.3_10 = b.2_21 + 1; b_lsm.10_28 = b.3_10; if (b.3_10 != 0) goto ; else goto ; : # c_I_lsm.9_32 = PHI # b_lsm.10_33 = PHI # .MEM_29 = VDEF <.MEM_22> c[0] = c_I_lsm.9_32; # .MEM_30 = VDEF <.MEM_29> b = b_lsm.10_33; goto ; : goto ; and there is no dom/phicprop pass in between lim1 and vect that would clean this mess up (with -O3 -fno-tree-vectorize first dom2 changes that # .MEM_22 = PHI <.MEM_22(10), .MEM_17(8)> into # .MEM_22 = PHI <.MEM_17(10), .MEM_17(8)> and then phicprop removes it, but e.g. with -O3 -fno-tree-vectorize -fno-tree-dominator-opts it survives until *.optimized dump). The vectorizer then ignores virtual PHIs, assuming everything will be handled well by the data ref analysis and adjustments to the stores in the loop. Which works if the loop has any stores, because then the stores will have their vdefs renamed, but if the loop doesn't have any stores, we end up with the verification ICE here. I think the vectorizer can't rely on these unnecessary virtual PHIs not being present, so either it could give up on them, or at least for the simple cases (like this when the virtual PHI on loop->header bb uses itself and some .MEM from before the loop) could be handled by just propagating the .MEM from before the loop into all the uses of this vdef.
[Bug tree-optimization/52252] An opportunity for x86 gcc vectorizer (gain up to 3 times)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52252
Richard Guenther changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2012-02-15
Component|target |tree-optimization
Version|unknown |4.7.0
Ever Confirmed|0 |1
Severity|normal |enhancement
--- Comment #1 from Richard Guenther 2012-02-15
11:53:58 UTC ---
We fail to SLP vectorize this because of
6: Build SLP failed: different operation in stmt k_15 = MIN_EXPR ;
thus,
out[0] = c - k;
out[1] = m - k;
out[2] = y - k;
out[3] = k;
isn't detected as equivalent to
out[0] = c - k;
out[1] = m - k;
out[2] = y - k;
out[3] = - k;
or
out[3] = k - 0;
whatever would be more suitable (the latter would fail to be detected as
induction I guess, the former would fail with a similar issue for the
definition of ).
With
out[3] = y - k;
we fail with
6: Load permutation 0 1 2 2 1 1 1 1 0 0 0 0 2 2 2 2
6: Build SLP failed: unsupported load permutation *out_37 = D.1721_16;
we can vectorize
void convert_image(byte *in, byte *out, int size) {
int i;
for(i = 0; i < size; i++) {
byte r = in[0];
byte g = in[1];
byte b = in[2];
byte a = in[3];
byte c, m, y, k, z, tmp;
c = 255 - r;
m = 255 - g;
y = 255 - b;
z = 255 - a;
tmp = MIN(m, y);
k = MIN(c, tmp);
out[0] = c - k;
out[1] = m - k;
out[2] = y - k;
out[3] = z - k;
in += 4;
out += 4;
}
}
though.
[Bug c++/51930] [4.7 regression] Explicitly instantiated template gets hidden visibility
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51930 --- Comment #10 from Philipp 2012-02-15 12:02:09 UTC --- But think about a header only library. My test case isn't that far fetched. A simple struct with no member functions (except for the implicitly generated ones) should need no visibility at all, in my opinion. I can work around this somehow, but wouldn't it be better to fix it?
[Bug tree-optimization/52255] [4.7 Regression] ICE: verify_ssa failed, block does not dominate use
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52255 --- Comment #4 from Richard Guenther 2012-02-15 12:08:38 UTC --- It can also, when encountering a virtual PHI, simply rename all VOPs. LIM could also fixup those PHIs after performing store-motion.
[Bug testsuite/52259] New: All tm tests fail on targets without pthread support
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52259 Bug #: 52259 Summary: All tm tests fail on targets without pthread support Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassig...@gcc.gnu.org ReportedBy: greta.yo...@arm.com Target: arm-none-eabi All tm tests fail on arm-none-eabi, for example: /work/builds/a9-feb15/arm-none-eabi/gcc2/gcc/xgcc -B/work/builds/a9-feb15/arm-none-eabi/gcc2/gcc/ /work/local-checkouts/gcc-fsf/gcc/testsuite/c-c++-common/tm/20100127.c -fgnu-tm -O -fdump-tree-tmmark -DSTACK_SIZE=16384 -S-o 20100127.s (timeout = 60) xgcc: error: unrecognized command line option '-pthread' compiler exited with status 1 Caused by trunk r184174, which added -pthread to the command line of all tm tests without checking that the target supports pthread: http://gcc.gnu.org/ml/gcc-patches/2012-02/msg00558.html
[Bug target/52260] New: [4.7 Regression] ICE in clone_tree_hash, at dwarf2out.c:7424
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52260
Bug #: 52260
Summary: [4.7 Regression] ICE in clone_tree_hash, at
dwarf2out.c:7424
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: d...@gcc.gnu.org
Created attachment 26663
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26663
preprocessed source
seen with 20120214 r184236 in stage1 building the debug libstdc++, last
successful build was 20120210 on arm-linux-gnueabi, configured with:
--enable-libstdcxx-debug
--enable-libstdcxx-time=yes
--with-arch=armv7-a
--with-float=hard
--with-fpu=vfpv3-d16
--with-mode=thumb
omitting -gdwarf-4 avoids the ICE.
$ build/gcc/xgcc -Bbuild/gcc/ -c -fno-implicit-templates -std=gnu++11 -gdwarf-4
funcexecpt.ii
../../../../../../src/libstdc++-v3/src/c++11/functexcept.cc:194:1: internal
compiler error: in clone_tree_hash, at dwarf2out.c:7424
Please submit a full bug report,
with preprocessed source if appropriate.
Breakpoint 1, fancy_abort (file=0x9d63d0 "../../src/gcc/dwarf2out.c",
line=7424,
function=0x9d9c58 "clone_tree_hash") at ../../src/gcc/diagnostic.c:899
899 internal_error ("in %s, at %s:%d", function, trim_filename (file),
line);
(gdb) bt
#0 fancy_abort (file=0x9d63d0 "../../src/gcc/dwarf2out.c", line=7424,
function=0x9d9c58 "clone_tree_hash") at ../../src/gcc/diagnostic.c:899
#1 0x00269f4a in clone_tree_hash (die=0xb1736540, decl_table=0xeabab0)
at ../../src/gcc/dwarf2out.c:7424
#2 0x0026a04c in copy_decls_walk (unit=0xb1770750, die=0xb161c2a0,
decl_table=0xeabab0)
at ../../src/gcc/dwarf2out.c:7474
#3 0x0026a142 in copy_decls_walk (unit=0xb1770750, die=0xb3fc42d0,
decl_table=0xeabab0)
at ../../src/gcc/dwarf2out.c:7522
#4 0x0026a142 in copy_decls_walk (unit=0xb1770750, die=0xb1770750,
decl_table=0xeabab0)
at ../../src/gcc/dwarf2out.c:7522
#5 0x0026a18e in copy_decls_for_unworthy_types (unit=0xb1770750)
at ../../src/gcc/dwarf2out.c:7538
#6 0x00284302 in dwarf2out_finish (
filename=0xd30328
"../../../../../../src/libstdc++-v3/src/c++11/functexcept.cc")
at ../../src/gcc/dwarf2out.c:22614
#7 0x0048f312 in compile_file () at ../../src/gcc/toplev.c:611
#8 0x0049169a in do_compile () at ../../src/gcc/toplev.c:1938
#9 0x00491822 in toplev_main (argc=20, argv=0xbefff644) at
../../src/gcc/toplev.c:2014
#10 0x001c5e7e in main (argc=20, argv=0xbefff644) at ../../src/gcc/main.c:36
[Bug tree-optimization/50561] [4.7 regression] ICE when compiling zlib with -O2 -floop-flatten -floop-strip-mine
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50561 --- Comment #10 from Richard Guenther 2012-02-15 12:20:23 UTC --- Author: rguenth Date: Wed Feb 15 12:20:10 2012 New Revision: 184265 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184265 Log: 2012-02-15 Tobias Grosser PR tree-optimization/50561 * graphite-flattening.c (lst_project_loop): Do not remove old scattering dimensions after flattening. (lst_do_flatten): Likewise. * gcc.dg/graphite/pr50561.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/graphite/pr50561.c Modified: trunk/gcc/ChangeLog trunk/gcc/graphite-flattening.c trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/50561] [4.7 regression] ICE when compiling zlib with -O2 -floop-flatten -floop-strip-mine
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50561 Richard Guenther changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #11 from Richard Guenther 2012-02-15 12:21:18 UTC --- Fixed.
[Bug target/52261] New: [avr] Add support for AVR Xmega cores
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52261 Bug #: 52261 Summary: [avr] Add support for AVR Xmega cores Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: g...@gcc.gnu.org CC: eric.wedding...@atmel.com Target: avr Xmega core are special with respect to I-flag instruction and writing SPL (low byte of stack pointer SP): In old cores, setting I-flag by means of SEI/RETI/OUT has a latency of 1 instruction In Xmega cores, setting I-flag by means of SEI/RETI/OUT has a latency of 0 instructions. This, writing to SP by a sequence like IN tmp_reg, SREG CLI OUT SP_H, %B1 OUT SREG, tmp_reg OUT SP_L, %A1 is no move correct because write of SP with that sequence is no more atomic. Xmega's OUT SP_L,* inhibits IRQs for 4 instructions so that the following sequence can be used instead to write to SP: OUT SP_L, %A1 OUT SP_H, %B1
[Bug target/52261] [avr] Add support for AVR Xmega cores
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52261 Georg-Johann Lay changed: What|Removed |Added Priority|P3 |P4 Status|UNCONFIRMED |NEW Last reconfirmed||2012-02-15 Target Milestone|--- |4.7.0 Ever Confirmed|0 |1 --- Comment #1 from Georg-Johann Lay 2012-02-15 12:35:38 UTC --- For Xmega cores and MCUs supported by binutils, see src/gas/config/tc-avr.c http://sourceware.org/cgi-bin/cvsweb.cgi/src/gas/config/tc-avr.c?content-type=text/x-cvsweb-markup&cvsroot=src
[Bug target/52261] [avr] Add support for AVR Xmega cores
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52261 --- Comment #2 from Georg-Johann Lay 2012-02-15 13:16:01 UTC --- Author: gjl Date: Wed Feb 15 13:15:56 2012 New Revision: 184269 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184269 Log: libgcc/ PR target/52261 * config/avr/lib1funcs.S (__prologue_saves__): Handle AVR_XMEGA (__epilogue_restores__): Ditto. gcc/ PR target/52261 * config/avr/avr-devices.c (avr_arch_types): Add avrxmega2, avrxmega4, avrxmega5, avrxmega6, avrxmega7. Rewrite initializers for .macro. * config/avr/avr-mcus.def (AVR_MCU): Add known MCUs: avrxmega2: atxmega16a4, atxmega16d4, atxmega16x1, atxmega32a4 atxmega32d4, atxmega32x1. avrxmega4: atxmega64a3, atxmega64d3. avrxmega5: atxmega64a1, atxmega64a1u. avrxmega6: atxmega128a3, atxmega128d3, atxmega192a3, atxmega192d3, atxmega256a3, atxmega256a3b, atxmega256a3bu, atxmega256d3. avrxmega7: atxmega128a1, atxmega128a1u. * config/avr/multilib.h: Regenerate. * config/avr/t-multilib: Regenerate. * config/avr/avr-tables.opt: Regenerate. * config/avr/avr.h (enum avr_arch): Add: ARCH_AVRXMEGA2, ARCH_AVRXMEGA4,ARCH_AVRXMEGA5, ARCH_AVRXMEGA6, ARCH_AVRXMEGA7. (struct base_arch_s): Rename reserved to xmega_p. Rename reserved2 to have_rampd. (AVR_XMEGA): New define. (AVR_HAVE_RAMPD, AVR_HAVE_RAMPX, AVR_HAVE_RAMPY): New defines. (AVR_HAVE_RAMPZ): Change definition to fit xmega. * config/avr/predicates.md (io_address_operand): Take into account SFR offset. (low_io_address_operand): Ditto. (high_io_address_operand): Ditto. * config/avr/avr.md (isa): Add alternatives no_xmega, xmega. (enabled, movhi_sp_r): Use them. * config/avr/avr-c.c (avr_cpu_cpp_builtins): Use cpp_define_formatted to built-in define __AVR_ARCH__. (__AVR_XMEGA__): New built-in define. (__AVR_HAVE_RAMPD__): New built-in define. (__AVR_HAVE_RAMPX__): New built-in define. (__AVR_HAVE_RAMPY__): New built-in define. (__AVR_HAVE_RAMPZ__): Change condition when to built-in define it. * config/avr/avr.c (avr_addr_t): Add ccp, rampd, rampx, rampy. (avr_option_override): Initialize them. (sreg_rtx, rampd_rtx, rampx_rtx, rampy_rtx): New GTY rtx. (avr_init_expanders): Initialize them. No more block several calls. (emit_push_sfr): New static function. (avr_prologue_setup_frame): Use it to push SREG, RAMPD/X/Y/Z as needed. Handle AVR_XMEGA. (expand_epilogue): Handle AVR_XMEGA. Pop RAMPD/X/Y/Z as needed. (avr_print_operand): Print addreeses as symbols for RAMPX, RAMPY, RAMPD, CCP. (output_movhi): Handle AVR_XMEGA when writing to SP. (avr_out_movhi_mr_r_xmega): New static function. (out_movhi_mr_r): Forward to avr_out_movhi_mr_r_xmega for AVR_XMEGA. (avr_file_start): Print symbol defines for __RAMPX__, __RAMPY__, __RAMPD__, __CCP__ as needed. Modified: trunk/gcc/ChangeLog trunk/gcc/config/avr/avr-c.c trunk/gcc/config/avr/avr-devices.c trunk/gcc/config/avr/avr-mcus.def trunk/gcc/config/avr/avr-tables.opt trunk/gcc/config/avr/avr.c trunk/gcc/config/avr/avr.h trunk/gcc/config/avr/avr.md trunk/gcc/config/avr/multilib.h trunk/gcc/config/avr/predicates.md trunk/gcc/config/avr/t-multilib trunk/libgcc/ChangeLog trunk/libgcc/config/avr/lib1funcs.S
[Bug testsuite/52259] All tm tests fail on targets without pthread support
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52259 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2012-02-15 CC||ebotcazou at gcc dot ||gnu.org Ever Confirmed|0 |1 --- Comment #1 from Eric Botcazou 2012-02-15 13:38:35 UTC --- > Caused by trunk r184174, which added -pthread to the command line of all tm > tests without checking that the target supports pthread: > http://gcc.gnu.org/ml/gcc-patches/2012-02/msg00558.html Please read the patch, it incorporates a method to address this issue. Does arm-none-eabi really support -fgnu-tm? If no, then the problem might already have been fixed by http://gcc.gnu.org/ml/gcc-cvs/2012-02/msg00458.html
[Bug c++/51930] [4.7 regression] Explicitly instantiated template gets hidden visibility
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51930
--- Comment #11 from Paolo Carlini 2012-02-15
13:50:07 UTC ---
("... wouldn't it be better to fix it?" should read "... to change it?",
otherwise you are begging the question, eh)
[Bug testsuite/52259] All tm tests fail on targets without pthread support
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52259 Greta Yorsh changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED --- Comment #2 from Greta Yorsh 2012-02-15 14:10:40 UTC --- You are right, the problem has been fixed by r184237. Thank you, Greta
[Bug c++/41518] copy initialization of volatile objects
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41518
lucdanton at free dot fr changed:
What|Removed |Added
CC||lucdanton at free dot fr
--- Comment #3 from lucdanton at free dot fr 2012-02-15 15:08:11 UTC ---
Reproducible with const:
$ cat main.cpp
struct copyable {
copyable() {}
copyable(copyable&) {}
};
struct wrapper {
copyable c;
wrapper(int) {}
};
int
main()
{
wrapper const w = 0;
}
$ g++-snapshot -Wall -Wextra -pedantic main.cpp
main.cpp: In function 'int main()':
main.cpp:15:23: error: no matching function for call to 'wrapper::wrapper(const
wrapper)'
main.cpp:15:23: note: candidates are:
main.cpp:9:5: note: wrapper::wrapper(int)
main.cpp:9:5: note: no known conversion for argument 1 from 'const wrapper'
to 'int'
main.cpp:6:8: note: wrapper::wrapper(wrapper&)
main.cpp:6:8: note: no known conversion for argument 1 from 'const wrapper'
to 'wrapper&'
$ g++-snapshot -Wall -Wextra -pedantic -std=c++11 main.cpp
main.cpp: In function 'int main()':
main.cpp:15:23: error: no matching function for call to 'wrapper::wrapper(const
wrapper)'
main.cpp:15:23: note: candidates are:
main.cpp:9:5: note: wrapper::wrapper(int)
main.cpp:9:5: note: no known conversion for argument 1 from 'const wrapper'
to 'int'
main.cpp:6:8: note: wrapper::wrapper(wrapper&)
main.cpp:6:8: note: no known conversion for argument 1 from 'const wrapper'
to 'wrapper&'
$ g++-snapshot -v
...
gcc version 4.7.0 20120128 (experimental) [trunk revision 183664] (Debian
20120128-1)
I noticed a similar problem when using copy-initialization on a const object of
a class that is movable (with move constructor accepting T&&, not T const&&)
but not copyable. I noticed that in C++11 8.5 Initializers [dcl.init] takes
great care to specify:
> [...] if the function is a constructor, the call initializes a temporary of
> the cv-unqualified version of the destination type.
on paragraph 16 (I'm using n3290). I'm not as familiar with C++03 but
apparently the text only mentions creation of a temporary, without exactly
specifying of which type.
[Bug target/52260] [4.7 Regression] ICE in clone_tree_hash, at dwarf2out.c:7424
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52260 Andrew Stubbs changed: What|Removed |Added CC||ams at gcc dot gnu.org, ||jakub at redhat dot com --- Comment #1 from Andrew Stubbs 2012-02-15 15:23:12 UTC --- SVN r184223 builds, r184224 does not. This is perhaps unsurprising given that that's the revision in which Jakub introduced the crashing function: 2012-02-14 Jakub Jelinek PR debug/51950 * dwarf2out.c (clone_tree_hash): New function. (copy_decls_walk): Use it instead of clone_tree.
[Bug fortran/47486] gfortran -M exits with fatal error when -o option is used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47486 --- Comment #6 from Kai Tietz 2012-02-15 15:30:58 UTC --- I have tested variant suggested in #comment 4 and those in #comment 5. Both are fixing the ICE. The file test.d (as used as crash example) will be created empty.
[Bug fortran/47486] gfortran -M exits with fatal error when -o option is used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47486
--- Comment #7 from Tobias Burnus 2012-02-15
15:51:45 UTC ---
(In reply to comment #5)
> "%{E|M|MM|MT|MQ|MD|MMD:;:" F951_OPTIONS "}"
Good idea - and looks cleaner. Except (my bug) that -MD and -MMD do not imply
"-E". Thus, those shouldn't appear in that list.
Additionally, with -M the output goes - according to Kai (thanks for testing!)
- still to stdout. I think the "if (gfc_cpp_preprocess_only ())" in
fortran/cpp.c's gfc_cpp_init_0 needs to be modified.
[Bug c++/44783] implement -ftemplate-backtrace-limit=
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44783 Paolo Carlini changed: What|Removed |Added Attachment #26658|0 |1 is obsolete|| --- Comment #13 from Paolo Carlini 2012-02-15 15:55:26 UTC --- Created attachment 26664 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26664 Draft 2 As regtested.
[Bug target/52260] [4.7 Regression] ICE in clone_tree_hash, at dwarf2out.c:7424
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52260 Richard Guenther changed: What|Removed |Added Target Milestone|--- |4.7.0
[Bug c++/41518] copy initialization of volatile objects
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41518 Paolo Carlini changed: What|Removed |Added CC|gcc-bugs at gcc dot gnu.org |jason at gcc dot gnu.org --- Comment #4 from Paolo Carlini 2012-02-15 16:04:41 UTC --- Let's ask Jason to double check the triage.
[Bug tree-optimization/23286] missed fully redundant expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23286 Richard Guenther changed: What|Removed |Added Attachment #19634|0 |1 is obsolete|| --- Comment #35 from Richard Guenther 2012-02-15 15:55:52 UTC --- Created attachment 26665 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26665 forward ported patch I made the patch apply and build again (unbootstrapped/tested). Steven, if you happen to have a "latest" patch around from yours somewhere I'd appreciate if you can make it appear in my inbox somehow ... I'll integrate it with my changes. Thx.
[Bug c++/51912] [C++11] G++ accepts floating point case labels
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51912 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-02-15 Ever Confirmed|0 |1
[Bug c++/52257] [C++11] switch cases accept floating point constants
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52257 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #1 from Paolo Carlini 2012-02-15 16:20:55 UTC --- Dup. *** This bug has been marked as a duplicate of bug 51912 ***
[Bug c++/51912] [C++11] G++ accepts floating point case labels
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51912 Paolo Carlini changed: What|Removed |Added CC||daniel.kruegler at ||googlemail dot com --- Comment #1 from Paolo Carlini 2012-02-15 16:20:55 UTC --- *** Bug 52257 has been marked as a duplicate of this bug. ***
[Bug c++/52241] Performance degradation of 447.dealII on corei7 at spec2006_base32.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52241 --- Comment #2 from Paolo Carlini 2012-02-15 16:39:00 UTC --- I don't understand what you mean by "inlining", since '_Rb_tree_node_base' is a *type* not a function. Anyway, I don't see how Benjamin's split could have caused inlining issues.
[Bug fortran/51825] Fortran runtime error: Cannot match namelist object name
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51825 --- Comment #4 from Jerry DeLisle 2012-02-15 17:08:51 UTC --- I have been working on this one. The order of the lines within the namelist file can cause the error to go away. I have also found that the read of the character string acutally completes OK. Its an elusive bug, but I am still working to isolate it. I o think we are leaving the chracer read in a wrong state. I will see if I can map it out.
[Bug middle-end/43548] internal compiler error: in ggc_set_mark, at ggc-page.c:1338
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43548 Kai Tietz changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ktietz at gcc dot gnu.org Resolution||FIXED --- Comment #8 from Kai Tietz 2012-02-15 17:09:59 UTC --- This bug was fixed. Can't reproduce it with 4.5.x, 4.6.x, and 4.7.x. IIRC it was related to a fixed bug about push/pop-macro.
[Bug translation/52262] New: translatable string typos (3): "REAl"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52262 Bug #: 52262 Summary: translatable string typos (3): "REAl" Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: translation AssignedTo: unassig...@gcc.gnu.org ReportedBy: sti...@antcom.de E.g. "Interpret any REAl(4) as a REAL(8)" 1. gcc/fortran/lang.opt:503 2. gcc/fortran/lang.opt:511 3. gcc/fortran/lang.opt:523
[Bug tree-optimization/52255] [4.7 Regression] ICE: verify_ssa failed, block does not dominate use
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52255 Jakub Jelinek changed: What|Removed |Added Keywords||ice-checking --- Comment #5 from Jakub Jelinek 2012-02-15 18:10:47 UTC --- We actually do that, but only at the end of the vectorize_loops after all vectorization: mark_sym_for_renaming (gimple_vop (cfun)); + TODO_update_ssa. The problem is that this diagnostic is triggered sooner than that, when gimple_duplicate_loop_to_header_edge calls #ifdef ENABLE_CHECKING if (loops_state_satisfies_p (LOOP_CLOSED_SSA)) verify_loop_closed_ssa (true); #endif during vect_loop_versioning, and the function that messes up the VOPs which triggers the checking failure is slpeel_tree_peel_loop_to_edge. If I change the above to (false), then it passes and generates correct IL.
[Bug target/52152] MIPS ELF targets should use dbxelf.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52152 --- Comment #2 from Rainer Orth 2012-02-15 18:24:37 UTC --- Author: ro Date: Wed Feb 15 18:24:30 2012 New Revision: 184280 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184280 Log: XFAIL objc.dg/stabs-1.m on IRIX (PR target/52152) PR target/52152 * objc.dg/stabs-1.m: xfail on mips-sgi-irix6.5. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/objc.dg/stabs-1.m
[Bug target/52238] -mms-bitfields: __attribute__ ((aligned (n))) ignored for struct members
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52238
Kai Tietz changed:
What|Removed |Added
CC||ktietz at gcc dot gnu.org
--- Comment #2 from Kai Tietz 2012-02-15 18:34:40
UTC ---
in stor-layout.c function place_field() it is said "We already align ms_struct
fields, so don't re-align them". This isn't completely true, as desired_align
isn't handled in ms_struct case.
Following patch seems to solve this issue:
Index: stor-layout.c
===
--- stor-layout.c (revision 184262)
+++ stor-layout.c (working copy)
@@ -1141,15 +1141,14 @@
}
/* Does this field automatically have alignment it needs by virtue
- of the fields that precede it and the record's own alignment?
- We already align ms_struct fields, so don't re-align them. */
- if (known_align < desired_align
- && !targetm.ms_bitfield_layout_p (rli->t))
+ of the fields that precede it and the record's own alignment? */
+ if (known_align < desired_align)
{
/* No, we need to skip space before this field.
Bump the cumulative size to multiple of field alignment. */
- if (DECL_SOURCE_LOCATION (field) != BUILTINS_LOCATION)
+ if (!targetm.ms_bitfield_layout_p (rli->t)
+ && DECL_SOURCE_LOCATION (field) != BUILTINS_LOCATION)
warning (OPT_Wpadded, "padding struct to align %q+D", field);
/* If the alignment is still within offset_align, just align
@@ -1302,7 +1301,7 @@
type size!) */
HOST_WIDE_INT bitsize = tree_low_cst (DECL_SIZE (field), 1);
- if (rli->remaining_in_alignment < bitsize)
+ if (rli->remaining_in_alignment < bitsize) /* */
{
HOST_WIDE_INT typesize = tree_low_cst (TYPE_SIZE (type), 1);
[Bug tree-optimization/23286] missed fully redundant expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23286 --- Comment #36 from Steven Bosscher 2012-02-15 18:37:40 UTC --- The patch was on one of the gsyprf machines, which are gone (didn't I already tell you this before??). So the "latest" patch is lost...
[Bug c++/52263] New: Zero-initialization doesn't seem to work correctly for virtual inheritance
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52263 Bug #: 52263 Summary: Zero-initialization doesn't seem to work correctly for virtual inheritance Classification: Unclassified Product: gcc Version: 4.6.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: ryan_at_work_a...@hotmail.com Created attachment 2 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=2 error testcase Using: g++ (GCC) 4.6.1 20110908 (Red Hat 4.6.1-9) Copyright (C) 2011 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. The following code will abort due to the failed check on deconstruction at exit (damaged memory). Uncomment the constructor of "Derived" and things work fine. The larger workspace I found this in actually had data being zeroed for other objects in memory (from a "rep stos" instruction). It looked like the initialization of the "Base" object occurred followed by a zero-initialization of that same object (which had already been created) occurred, BUT at the wrong memory address in my case (over memory used by other objects in my application). The output from compilation: g++ -Wall -Wextra -o gcc_fail gcc_fail.cxx cc_fail.cxx:53:2: warning: #warning "When uncommented, everything works fine - when commented, abort occurs" [-Wcpp] gcc_fail.cxx:66:1: warning: unused parameter ‘argc’ [-Wunused-parameter] gcc_fail.cxx:66:1: warning: unused parameter ‘argv’ [-Wunused-parameter]
[Bug c++/52263] Zero-initialization doesn't seem to work correctly for virtual inheritance
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52263 --- Comment #1 from Ryan 2012-02-15 18:39:38 UTC --- I forgot to add the system - Linux 2.6.40.3-0.fc15.x86_64
[Bug libitm/52042] libitm.c/clone-1.c (all darwin) and libitm.c/stackundo.c (darwin 11) execution tests fail with -fpie
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52042 --- Comment #10 from pmarlier at gcc dot gnu.org 2012-02-15 19:17:47 UTC --- Author: pmarlier Date: Wed Feb 15 19:17:42 2012 New Revision: 184281 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184281 Log: 2012-02-15 Iain Sandoe Patrick Marlier PR libitm/52042 * config/darwin-crt-tm.c (getTMCloneTable): New function. (__doTMRegistrations): Call it. (__doTMdeRegistrations): Likewise. Modified: trunk/libgcc/ChangeLog trunk/libgcc/config/darwin-crt-tm.c
[Bug tree-optimization/52255] [4.7 Regression] ICE: verify_ssa failed, block does not dominate use
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52255 --- Comment #6 from Jakub Jelinek 2012-02-15 19:20:55 UTC --- Created attachment 26667 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26667 gcc47-pr52255.patch Untested fix.
[Bug rtl-optimization/52208] [4.7 Regression] Useless store
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52208
Vladimir Makarov changed:
What|Removed |Added
CC||vmakarov at redhat dot com
--- Comment #4 from Vladimir Makarov 2012-02-15
19:34:06 UTC ---
(In reply to comment #3)
> The -1000 costs comes from the scan_one_insn subtracting there
> ira_memory_move_cost[][][] * frequency (i.e. memory_cost becomes -4000) and
> on the plus we add just 3000 to memory_cost.
> I wonder if we shouldn't limit this subtraction of mem_cost / setting of
> counted_mem e.g. to general_operand (SET_SRC (set), GET_MODE (SET_SRC (set)))
> and leave the specialized memory loads alone (I know, it would be a hack, but
> works for this and shouldn't pessimize the cases for which this hunk has been
> added).
I would not name this a hack, Jakub. It is a heuristic :) This solution is ok
for me. I checked SPEC2000 and did not find any effect of this patch on
generated code. So the patch is ok but it would be great if you add some
comment for the change.
And would at least tiny bit model what reload will do with such
> non-standard mems - as on this testcase it doesn't use the orignal mem, but
> does the load, followed by store to another mem, followed by load from that
> mem.
>
> --- ira-costs.c.jj 2012-01-20 12:35:17.0 +0100
> +++ ira-costs.c 2012-02-14 14:54:52.297356053 +0100
> @@ -1313,7 +1313,8 @@ scan_one_insn (rtx insn)
>|| (CONSTANT_P (XEXP (note, 0))
>&& targetm.legitimate_constant_p (GET_MODE (SET_DEST (set)),
> XEXP (note, 0))
> - && REG_N_SETS (REGNO (SET_DEST (set))) == 1)))
> + && REG_N_SETS (REGNO (SET_DEST (set))) == 1))
> + && general_operand (SET_SRC (set), GET_MODE (SET_SRC (set
> {
>enum reg_class cl = GENERAL_REGS;
>rtx reg = SET_DEST (set);
[Bug c++/41518] copy initialization of volatile objects
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41518 --- Comment #5 from Jason Merrill 2012-02-15 19:49:29 UTC --- I agree with the analysis.
[Bug libstdc++/51368] libstdc++ python pretty printers should use --with-python-dir just like libjava
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51368 --- Comment #2 from Benjamin Kosnik 2012-02-15 19:56:12 UTC --- Author: bkoz Date: Wed Feb 15 19:56:07 2012 New Revision: 184282 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184282 Log: 2012-02-15 Benjamin Kosnik PR libstdc++/51368 * acinclude.m4 (GLIBCXX_ENABLE_PYTHON): New. * configure.ac: Use it. * python/Makefile.am: Same. * configure: Regenerate. * python/Makefile.in: Regenerate. * Makefile.in: Same. * doc/Makefile.in: Same. * include/Makefile.in: Same. * po/Makefile.in: Same. * src/Makefile.in: Same. * src/c++11/Makefile.in: Same. * src/c++98/Makefile.in: Same. * testsuite/Makefile.in: Same. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/Makefile.in trunk/libstdc++-v3/acinclude.m4 trunk/libstdc++-v3/configure trunk/libstdc++-v3/configure.ac trunk/libstdc++-v3/doc/Makefile.in trunk/libstdc++-v3/include/Makefile.in trunk/libstdc++-v3/libsupc++/Makefile.in trunk/libstdc++-v3/po/Makefile.in trunk/libstdc++-v3/python/Makefile.am trunk/libstdc++-v3/python/Makefile.in trunk/libstdc++-v3/src/Makefile.in trunk/libstdc++-v3/src/c++11/Makefile.in trunk/libstdc++-v3/src/c++98/Makefile.in trunk/libstdc++-v3/testsuite/Makefile.in
[Bug libstdc++/51368] libstdc++ python pretty printers should use --with-python-dir just like libjava
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51368 --- Comment #3 from Benjamin Kosnik 2012-02-15 20:11:24 UTC --- Mine.
[Bug translation/52264] New: translatable string typo: "refernece"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52264 Bug #: 52264 Summary: translatable string typo: "refernece" Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: translation AssignedTo: unassig...@gcc.gnu.org ReportedBy: sti...@antcom.de gcc/cgraphunit.c:670: "Alias has non-alias refernece" -> "... reference
[Bug libstdc++/51967] FAIL: libstdc++-prettyprinters/48362.cc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51967 --- Comment #6 from Benjamin Kosnik 2012-02-15 20:20:24 UTC --- what's the python version you are using that is not working? I am using 2.7.2
[Bug libstdc++/51368] libstdc++ python pretty printers should use --with-python-dir just like libjava
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51368 --- Comment #4 from Benjamin Kosnik 2012-02-15 20:24:51 UTC --- This probably needs changing http://gcc.gnu.org/install/configure.html
[Bug translation/52264] translatable string typo: "refernece"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52264 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-02-15 CC||jakub at gcc dot gnu.org AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org | Target Milestone|--- |4.7.0 Ever Confirmed|0 |1
[Bug fortran/52265] New: [OOP] TREE dump confusing with nested SELECT TYPE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52265
Bug #: 52265
Summary: [OOP] TREE dump confusing with nested SELECT TYPE
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bur...@gcc.gnu.org
CC: pa...@gcc.gnu.org
The following program seems to work as expected, however, the dump is very
irritating:
switch (a._vptr->_hash)
{
case 6231989:;
__tmp_type_t = a._data;
{
struct t * __tmp_type_t;
switch (b._vptr->_hash)
{
case 6231989:;
__tmp_type_t = b._data;
*__tmp_type_t = *__tmp_type_t;
There are two variables called "__tmp_type_t", one pointing to a._data and the
other to b._data. Most striking is the last line where both variables occur.
That's very confusing and would be impossible to do in C, C++, or Fortran.
Expected: Use different variable names, e.g. via
gfc_create_var (type, "__tmp_type_t")
type t
integer :: i = 5
end type t
class(t), allocatable :: a, b
allocate(a,b)
b%i = 77
select type (a)
type is (t)
select type (b)
type is (t)
a = b
b%i = 88
end select
end select
if (a%i /= 77) call abort ()
if (a%i /= 88) call abort ()
end
[Bug fortran/52227] [OOP] TARGET attribute mishandled in polymorphic types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52227 --- Comment #1 from Tobias Burnus 2012-02-15 20:59:06 UTC --- A related issue, for class(t), target, allocatable :: a(:) target :: a no error is printed - but it should! The problem seems to be that already for the first line, the class symbol is created - and the attr.target does not seem to get stored properly. The same problem occurs for ALLOCATABLE or POINTER - but only if the variable is a dummy, otherwise class_ok is false and the creation is deferred. Example: type t end type t contains subroutine foo(a,b) class(t) :: a, b allocatable :: a, b allocate(a,b) end subroutine end which fails with "ALLOCATABLE attribute conflicts with POINTER" while using "pointer" fails with "Duplicate POINTER attribute specified"
[Bug target/52199] V2DI vec_duplicate ICE on valid code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52199 --- Comment #2 from Michael Meissner 2012-02-15 21:17:46 UTC --- Author: meissner Date: Wed Feb 15 21:17:42 2012 New Revision: 184285 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184285 Log: [gcc] 2012-02-15 Michael Meissner PR target/52199 * config/rs6000/rs6000.c (rs6000_expand_vector_init): Use force_reg instead of copy_to_reg for better optimization. Force non-register or memory operands into a register. [gcc/testsuite] 2012-02-15 Michael Meissner PR target/52199 * gcc.target/powerpc/pr52199.c: New file. Added: branches/gcc-4_6-branch/gcc/testsuite/gcc.target/powerpc/pr52199.c Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/config/rs6000/rs6000.c branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
[Bug middle-end/52236] segfault in program that results from compiling sha512-hash.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52236 Zooko Wilcox-O'Hearn changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID --- Comment #4 from Zooko Wilcox-O'Hearn 2012-02-15 21:22:28 UTC --- Thanks to Samuel Neves, the bug was identified in the application (pycryptopp), not in gcc. Thanks!
[Bug target/52199] V2DI vec_duplicate ICE on valid code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52199 Michael Meissner changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-02-15 Ever Confirmed|0 |1
[Bug libffi/52221] [libffi] r183675,r184021 needs to be fixed.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52221 gee changed: What|Removed |Added Summary|[libffi] r184021 needs to |[libffi] r183675,r184021 |be fixed. |needs to be fixed. Severity|normal |blocker --- Comment #7 from gee 2012-02-15 21:32:10 UTC --- there is an big mistake in r183675 - ffi_call_win32(ffi_prep_args_raw, &ecif, cif->bytes, cif->flags, - ecif.rvalue, fn); + ffi_call_win32(ffi_prep_args, &ecif, cif->abi, cif->bytes, cif->flags, + ecif.rvalue, fn); and below the mistake, another one. +if (passed_regs < 2 && abi == FFI_FASTCALL) + abi = FFI_THISCALL; +if (passed_regs < 1 && abi == FFI_THISCALL) + abi = FFI_STDCALL; +ffi_call_win32(ffi_prep_args, &ecif, abi, cif->bytes, cif->flags, + ecif.rvalue, fn); + } why ffi_prep_args_raw changed to ffi_prep_args?? this explains why i succeed but not sigsegving in ExtraClassLoader. because of this, i decidec to raise the severity to blocker.
[Bug target/52199] V2DI vec_duplicate ICE on valid code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52199 --- Comment #3 from Michael Meissner 2012-02-15 21:42:04 UTC --- Author: meissner Date: Wed Feb 15 21:42:00 2012 New Revision: 184287 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184287 Log: [gcc] 2012-02-15 Michael Meissner PR target/52199 * config/rs6000/rs6000.c (rs6000_expand_vector_init): Use force_reg instead of copy_to_reg for better optimization. Force non-register or memory operands into a register. [gcc/testsuite] 2012-02-15 Michael Meissner PR target/52199 * gcc.target/powerpc/pr52199.c: New file. Added: trunk/gcc/testsuite/gcc.target/powerpc/pr52199.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/rs6000.c trunk/gcc/testsuite/ChangeLog
[Bug target/52199] V2DI vec_duplicate ICE on valid code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52199 Michael Meissner changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #4 from Michael Meissner 2012-02-15 21:49:58 UTC --- Trunk fixed in subversion id 184287. GCC 4.6 branch fixed in subversion id 184283.
[Bug go/52266] New: [4.7 Regression] syntax error in libgo/configure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52266
Bug #: 52266
Summary: [4.7 Regression] syntax error in libgo/configure
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: go
AssignedTo: i...@airs.com
ReportedBy: d...@gcc.gnu.org
seen in 4.7.0, not 4.6.2:
checking for stdint.h... yes
checking for unistd.h... yes
/scratch/packages/gcc/4.7/gcc-4.7-4.7-20120210/src/libgo/configure: line 4750:
#include:
command not found
checking for a sed that does not truncate output... /bin/sed
checking for fgrep... /bin/grep -F
checking how to print strings... printf
configure:
[...]
eval as_val=\$$as_ac_Header
if test "x$as_val" = x""yes; then :
cat >>confdefs.h <<_ACEOF
#define `$as_echo "HAVE_$ac_header" | $as_tr_cpp` 1
_ACEOF
fi
done
$ac_includes_default
{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for a sed that does not
truncate output" >
&5
$as_echo_n "checking for a sed that does not truncate output... " >&6; }
if test "${ac_cv_path_SED+set}" = set; then :
$as_echo_n "(cached) " >&6
else
[...]
[Bug go/46986] Go is not supported on Darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46986 --- Comment #19 from Anders F Björklund 2012-02-15 22:08:59 UTC --- (In reply to comment #17) > I think that now the only thing which will need to change in the Go frontend > proper is using otool instead of objcopy in libgo/Makefile.am. The otool was simple enough, but the other go_export issues still remain. And there are some new issues with ucontext being deprecated on Mac OS X.
[Bug go/46986] Go is not supported on Darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46986 --- Comment #22 from Anders F Björklund 2012-02-15 22:16:41 UTC --- Created attachment 26670 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26670 gcc-ucontext.diff ucontext is deprecated on Mac OS X 10.5-10.6, including ucontext.h gives error: In file included from ../../../gcc/libgo/runtime/runtime.h:20:0, from ../../../gcc/libgo/runtime/go-main.c:21: /usr/include/ucontext.h:42:2: error: #error ucontext routines are deprecated, and require _XOPEN_SOURCE to be defined ucontext is missing altogether from Mac OS X 10.7, but there is no TLS either: error: thread-local storage not supported for this target
[Bug go/46986] Go is not supported on Darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46986 --- Comment #21 from Anders F Björklund 2012-02-15 22:12:24 UTC --- Created attachment 26669 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26669 gcc-go_export.diff Need to give both segment and section for export on Darwin: /var/folders/SU/SU8yve9tFP4OXneVoY+KsU+++TI/-Tmp-//ccWicBIX.s:3:Expected comma after segment-name /var/folders/SU/SU8yve9tFP4OXneVoY+KsU+++TI/-Tmp-//ccWicBIX.s:3:Rest of line ignored. 1st junk character valued 32 ( ). /var/folders/SU/SU8yve9tFP4OXneVoY+KsU+++TI/-Tmp-//ccWicBIX.s:3:Junk character 92 (\). /var/folders/SU/SU8yve9tFP4OXneVoY+KsU+++TI/-Tmp-//ccWicBIX.s:3:Rest of line ignored. 1st junk character valued 49 (1).
[Bug go/46986] Go is not supported on Darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46986 --- Comment #20 from Anders F Björklund 2012-02-15 22:10:09 UTC --- Created attachment 26668 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26668 updated patch for trunk
[Bug go/46986] Go is not supported on Darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46986 m...@gcc.gnu.org changed: What|Removed |Added CC||mrs at gcc dot gnu.org --- Comment #23 from mrs at gcc dot gnu.org 2012-02-15 22:41:37 UTC --- I'm fine with the last patch, though, I think it needs Ian to approve.
[Bug libitm/52220] FAIL: libitm.c++/eh-1.C execution test due to Xcode 4 weakref linker bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52220 --- Comment #1 from pmarlier at gcc dot gnu.org 2012-02-15 23:39:50 UTC --- Author: pmarlier Date: Wed Feb 15 23:39:28 2012 New Revision: 184293 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184293 Log: libitm/ 2012-02-15 Iain Sandoe Patrick Marlier PR libitm/52220 * alloc_cpp.cc: No dummy definitions for darwin. * eh_cpp.cc: Likewise. libgcc/ 2012-02-15 Iain Sandoe Patrick Marlier PR libitm/52220 * config/darwin-crt-tm.c: Generate dummy functions. Modified: trunk/libgcc/ChangeLog trunk/libgcc/config/darwin-crt-tm.c trunk/libitm/ChangeLog trunk/libitm/alloc_cpp.cc trunk/libitm/eh_cpp.cc
[Bug libstdc++/51967] FAIL: libstdc++-prettyprinters/48362.cc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51967 --- Comment #7 from dave.anglin at bell dot net 2012-02-16 00:28:25 UTC --- On 15-Feb-12, at 3:20 PM, bkoz at gcc dot gnu.org wrote: > what's the python version you are using that is not working? It's 2.4.2. If I get a chance, I'll try an update it this weekend. Dave -- John David Anglindave.ang...@bell.net
[Bug tree-optimization/52254] VRP does not fold (~a) & N to a ^ N if a has range [0, N]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52254 --- Comment #3 from Andrew Pinski 2012-02-16 03:00:22 UTC --- (In reply to comment #2) > The combine stage should have access to a valueize() hook as well, to query > SSA propagator/VNs lattice. That hook can maybe supply this extra info > (I wanted to make VRP info persistent for some time, in SSA_NAME_PTR_INFO > much like we have alignment info there which really is kind of a value-range) I was thinking about adding that. Even using nonzero bits to create a simple range.
[Bug c++/52263] Zero-initialization doesn't seem to work correctly for virtual inheritance
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52263 --- Comment #2 from Andrew Pinski 2012-02-16 03:04:24 UTC --- I think this has been fixed already on both the 4.6 branch and the trunk.
[Bug libitm/52220] FAIL: libitm.c++/eh-1.C execution test due to Xcode 4 weakref linker bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52220 Jack Howarth changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #2 from Jack Howarth 2012-02-16 03:12:45 UTC --- Confirmed as fixed on x86_64-apple-darwin11 at r184293.
[Bug tree-optimization/52267] New: a&~N where N has all the bits set up till a specific point can be folded to ((unsigned)a) < N
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52267
Bug #: 52267
Summary: a&~N where N has all the bits set up till a specific
point can be folded to ((unsigned)a) < N
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: pins...@gcc.gnu.org
Take the following two functions.
int f(int a, int b)
{
if (a>3||a<0) return a;
a&=3;
return a&3;
}
int f1(int a)
{
if (a&~03) return a;
return a&3;
}
They should return just the argument. Right now the first function does but
not the second.
[Bug go/46986] Go is not supported on Darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46986 --- Comment #24 from Jack Howarth 2012-02-16 03:47:05 UTC --- (In reply to comment #22) > > ucontext is missing altogether from Mac OS X 10.7, but there is no TLS either: > > error: thread-local storage not supported for this target There is tis support within clang in Xcode 4.2 (see radar:10291355, "Xcode 4.2 miscompiles tls support in MPFR 3.1.0" which was fixed in Xcode 4.2.1), however FSF gcc currently doesn't generate the required assembly for tis support.
[Bug target/52268] New: tls support should be added for darwin11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52268 Bug #: 52268 Summary: tls support should be added for darwin11 Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: howa...@nitro.med.uc.edu The clang compiler in clang 3.0 and Xcode 4.2 currently provides tis support on darwin11. This same ability to generate the required tis assembly for darwin11 should be added to FSF gcc.
[Bug target/52268] tls support should be added for darwin11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52268 Jack Howarth changed: What|Removed |Added Target||x86_64-apple-darwin11 Host||x86_64-apple-darwin11 Build||x86_64-apple-darwin11 Severity|normal |enhancement
[Bug translation/52264] translatable string typo: "refernece"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52264 --- Comment #1 from Jakub Jelinek 2012-02-16 06:29:19 UTC --- Author: jakub Date: Thu Feb 16 06:29:12 2012 New Revision: 184298 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184298 Log: PR translation/52264 * cgraphunit.c (verify_cgraph_node): Fix a typo. Modified: trunk/gcc/ChangeLog trunk/gcc/cgraphunit.c
[Bug fortran/52265] [OOP] TREE dump confusing with nested SELECT TYPE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52265
--- Comment #1 from paul.richard.thomas at gmail dot com 2012-02-16 06:58:10 UTC ---
Dear Tobias,
I have encountered this in the work on PR41600. I thought to append a
numeric identifier that increments with each new temporary. In fact,
I had wondered whether, once the SELECT TYPE is working properly, we
should not simplify the name to __tmp.###? The present complexity
serves no purpose, since we can tell from the type what tehse things
are.
Cheers
Paul
PS PR41600 is fixed, barring some cleaning up. Correct code is being
produced but the compiler segfaults at the due to attempted double
frees of array_specs. I am pretty sure that I know where this is
happening - I'll let you know at lunchtime.
On Wed, Feb 15, 2012 at 9:51 PM, burnus at gcc dot gnu.org
wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52265
>
> Bug #: 52265
> Summary: [OOP] TREE dump confusing with nested SELECT TYPE
> Classification: Unclassified
> Product: gcc
> Version: 4.7.0
> Status: UNCONFIRMED
> Keywords: diagnostic
> Severity: normal
> Priority: P3
> Component: fortran
> AssignedTo: unassig...@gcc.gnu.org
> ReportedBy: bur...@gcc.gnu.org
> CC: pa...@gcc.gnu.org
>
>
> The following program seems to work as expected, however, the dump is very
> irritating:
>
> switch (a._vptr->_hash)
> {
> case 6231989:;
> __tmp_type_t = a._data;
> {
> struct t * __tmp_type_t;
>
> switch (b._vptr->_hash)
> {
> case 6231989:;
> __tmp_type_t = b._data;
> *__tmp_type_t = *__tmp_type_t;
>
> There are two variables called "__tmp_type_t", one pointing to a._data and the
> other to b._data. Most striking is the last line where both variables occur.
> That's very confusing and would be impossible to do in C, C++, or Fortran.
>
> Expected: Use different variable names, e.g. via
> gfc_create_var (type, "__tmp_type_t")
>
>
> type t
> integer :: i = 5
> end type t
>
> class(t), allocatable :: a, b
>
> allocate(a,b)
> b%i = 77
> select type (a)
> type is (t)
> select type (b)
> type is (t)
> a = b
> b%i = 88
> end select
> end select
> if (a%i /= 77) call abort ()
> if (a%i /= 88) call abort ()
> end
>
> --
> Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email
> --- You are receiving this mail because: ---
> You are on the CC list for the bug.
[Bug translation/52264] translatable string typo: "refernece"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52264 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #2 from Jakub Jelinek 2012-02-16 07:05:28 UTC --- Fixed, thanks for reporting it.
[Bug go/51874] Many libgo testsuite failures on Solaris, IRIX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51874 --- Comment #12 from ian at gcc dot gnu.org 2012-02-16 07:17:15 UTC --- Author: ian Date: Thu Feb 16 07:17:03 2012 New Revision: 184300 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184300 Log: PR go/51874 math: Don't use libc log2 and trunc functions. Modified: trunk/libgo/go/math/floor.go trunk/libgo/go/math/log10.go
[Bug middle-end/51929] [4.7 Regression] ICE: verify_cgraph_node failed with -O2 -fno-guess-branch-probability -fipa-cp-clone
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51929 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #11 from Jakub Jelinek 2012-02-16 07:27:28 UTC --- Fixed.
[Bug middle-end/51929] [4.7 Regression] ICE: verify_cgraph_node failed with -O2 -fno-guess-branch-probability -fipa-cp-clone
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51929 --- Comment #10 from Jakub Jelinek 2012-02-16 07:26:08 UTC --- Author: jakub Date: Thu Feb 16 07:25:58 2012 New Revision: 184301 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184301 Log: PR middle-end/51929 * cgraphunit.c (verify_edge_corresponds_to_fndecl): If node is a same_body_alias, also test whether e->callee isn't a former or current clone of the decl this is a same body alias of. * g++.dg/ipa/pr51929.C: New test. Added: trunk/gcc/testsuite/g++.dg/ipa/pr51929.C Modified: trunk/gcc/ChangeLog trunk/gcc/cgraphunit.c trunk/gcc/testsuite/ChangeLog
[Bug c++/52269] New: [C++11]Body of constexpr function templates instantiated too eagerly in unevaluated operands
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52269
Bug #: 52269
Summary: [C++11]Body of constexpr function templates
instantiated too eagerly in unevaluated operands
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 cannot be compiled with GCC 4.7.0 20120211
(experimental) and -std=c++11 flag.
template
int f(T x)
{
return x.get();
}
// O.K. The body of `f' is not required.
decltype(f(0)) a;
template
constexpr int g(T x)
{
return x.get();
}
// Seems to instantiate the body of `g'
// and results in an error.
decltype(g(0)) b;
Similar problems also arise in the case of non-template member functions of a
class template.
