[Bug c++/52241] Performance degradation of 447.dealII on corei7 at spec2006_base32.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52241 --- Comment #19 from Jakub Jelinek jakub at gcc dot gnu.org 2012-02-20 08:37:09 UTC --- Nice, so we want Paolo's patch. Out of interest, what are the 447.deal numbers when comparing linking against old (pre-Benjamin's commit) libstdc++.a and current libstdc++.a with Paolo's patch (or libstdc++.so.6, i.e. without -static)?
[Bug tree-optimization/52298] ICE: verify_ssa failed: definition in block follows use
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52298
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|NEW
AssignedTo|jakub at gcc dot gnu.org|unassigned at gcc dot
||gnu.org
--- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2012-02-20
08:57:40 UTC ---
Unassigning myself, not familiar enough with the nested_in_vect_loop stuff,
Richard, could you please have a look at this?
Just random comments:
Shorter testcase (-O3):
int a, b, i[2];
int
foo (void)
{
int l = 0;
for (a = 0; a = 3; a++)
for (b = 1; b = 0; b--)
l |= i[b];
return l;
}
The immediate problem I see is that in vectorizable_load we initialize
negative = tree_int_cst_compare (DR_STEP (dr), size_zero_node) 0;
i.e. from the inner loop's step (which is really negative), while we actually
use STMT_VINFO_DR_STEP when deciding if it is invariant and how to adjust the
read in each loop. STMT_VINFO_DR_STEP is 0 here, i.e. invariant, and
vectorizable_load in that case inserts stmts after the original stmt, but as
negative is true, we then put a permutation of it (which doesn't make any sense
for invariant loads, as all the vector elements are the same) before the
original stmt. So, a quick hack of ignoring negative if inv_p !bb_vinfo
fixes this, but can't be the right fix. I guess negative flag should be taken
from STMT_VINFO_DR_STEP if nested_in_vect_loop, but not sure if always, and the
question is what to do with the testing for the negative case, which needs to
pass a dr around, and for the outer loop we don't have any dr with the right
step etc.
I think the testcase shows several other issues, which can be observed also on
(-O3):
int a, b, i[2];
int
foo (void)
{
int l = 0;
for (a = 0; a = 3; a++)
for (b = 0; b = 1; b++)
l |= i[b];
return l;
}
1) it is unfortunately cunrolli pass doesn't do anything here, then the
vectorizer wouldn't make such weird decisions; but when cunrolli is run, lim
hasn't moved out the b variable loads/stores from the loop yet, and the next
complete unrolling happens only after vectorization. Perhaps another inner
loop complete unrolling a couple of passes before vectorization would help
here, but the question is if it would help even real-world apps.
2) if the outer loop has zero step and inner non-zero step, the question is if
it is worthwhile to do the vectorization at all, and at least on the above
testcase the cost model should say that it can't be beneficial given the large
cost of the reduction for a single iteration.
3) after complete unrolling, we end up with:
vect_var_.18_27 = vect_cst_.17_14 | { 0, 0, 0, 0 };
but nothing at the tree level optimizes that away into just
vect_var_.18_27 = vect_cst_.17_14;
So, the resulting assembly:
movdi(%rip), %xmm0
movl$2, b(%rip)
movdi+4(%rip), %xmm2
movl$4, a(%rip)
pshufd $0, %xmm0, %xmm1
pshufd $0, %xmm2, %xmm0
por %xmm1, %xmm0
movdqa %xmm0, %xmm1
psrldq $8, %xmm1
por %xmm1, %xmm0
movdqa %xmm0, %xmm1
psrldq $4, %xmm1
por %xmm1, %xmm0
movd%xmm0, -12(%rsp)
movl-12(%rsp), %eax
ret
really can't be faster than
movli+4(%rip), %edx
movli(%rip), %eax
movl$2, b(%rip)
movl$4, a(%rip)
orl %edx, %eax
orl %edx, %eax
ret
(but even for the non-vectorized loop, we should optimize away the second orl).
While playing with this, I ended up with a wrong-code testcase as opposed to
ice-on-valid:
/* { dg-options -O1 -ftree-vectorize -fno-tree-pre -fno-tree-loop-im } */
extern void abort (void);
int c[80];
__attribute__((noinline)) int
foo (void)
{
int l = 0;
int a, b;
for (a = 3; a = 0; a--)
for (b = 7; b = 0; b--)
l |= c[a+60];
return l;
}
int
main ()
{
int i;
for (i = 0; i 60; i++)
c[i] = 1;
for (; i 64; i++)
c[i] = 1 (i - 59);
if (foo () != 30)
abort ();
return 0;
}
And last minor thing (shouldn't we have a warning for it, at least static code
analyzers should and usually do warn about it):
vect_analyze_data_ref_access does:
tree step = DR_STEP (dr);
...
HOST_WIDE_INT dr_step = TREE_INT_CST_LOW (step);
...
if (loop_vinfo !step)
{
if (vect_print_dump_info (REPORT_DETAILS))
fprintf (vect_dump, bad data-ref access in loop);
return false;
}
So, either the if should go, because we'd segfault if step is NULL, or
initialization of dr_step needs to be moved after this test.
[Bug tree-optimization/51782] -ftree-sra: Missing address-space information leads to wrong
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51782 --- Comment #19 from rguenther at suse dot de rguenther at suse dot de 2012-02-20 09:27:48 UTC --- On Fri, 17 Feb 2012, jamborm at gcc dot gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51782 --- Comment #17 from Martin Jambor jamborm at gcc dot gnu.org 2012-02-17 17:59:43 UTC --- Created attachment 26695 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26695 Untested proposed fix This untested patch fixes the issue for me on a cross-compiler. It would be great if someone who is set up to run the testsuite on a platform with multiple address spaces or a simulator of one could test it a bit. My plan is to discuss this with maintainers next week and if they like the approach, give it a formal bootstrap and test run on x86_64 and submit shortly thereafter if everything goes fine. base returned from get_base_address should never be NULL, so it's safe to assume it isn't. Otherwise the patch looks ok to me. Richard.
[Bug c++/52315] New: [C++11] constexpr object of nested class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52315
Bug #: 52315
Summary: [C++11] constexpr object of nested class
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: oleg.e...@t-online.de
I'm not sure whether this is valid/invalid C++11, but it seems a little weird.
The following works as expected:
struct B
{
constexpr B (unsigned v) noexcept : val (v) { }
constexpr unsigned value (void) const noexcept { return val; }
unsigned val;
};
struct A
{
int stuff[B (16).value ()];
};
But moving struct B inside of struct A ...
struct A
{
struct B
{
constexpr B (unsigned v) noexcept : val (v) { }
constexpr unsigned value (void) const noexcept { return val; }
unsigned val;
};
int stuff[ B (16).value () ];
};
... results in error: size of array 'stuff' is not an integral
constant-expression
Using built-in specs.
COLLECT_GCC=sh-elf-gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/sh-elf/4.7.0/lto-wrapper
Target: sh-elf
Configured with: ../gcc-trunk/configure --target=sh-elf --prefix=/usr/local
--enable-languages=c,c++ --enable-multilib --disable-libssp --disable-nls
--disable-werror --enable-lto --with-newlib --with-gnu-as --with-gnu-ld
--with-system-zlib
Thread model: single
gcc version 4.7.0 20120220 (experimental) (GCC)
[Bug c++/52241] Performance degradation of 447.dealII on corei7 at spec2006_base32.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52241 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-02-20 AssignedTo|unassigned at gcc dot |paolo.carlini at oracle dot |gnu.org |com Target Milestone|--- |4.7.0 Ever Confirmed|0 |1
[Bug libstdc++/52309] [c++0x] unordered_set illegally requires value_type::operator!=
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52309 --- Comment #2 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org 2012-02-20 11:11:44 UTC --- Author: paolo Date: Mon Feb 20 11:11:39 2012 New Revision: 184388 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=184388 Log: 2012-02-20 Paolo Carlini paolo.carl...@oracle.com PR libstdc++/52309 * include/bits/hashtable_policy.h (_Equality_base, true,:: _M_equal(const _Hashtable)): Compare values with operator==. * testsuite/23_containers/unordered_set/operators/52309.cc: New. Added: trunk/libstdc++-v3/testsuite/23_containers/unordered_set/operators/52309.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/hashtable_policy.h
[Bug tree-optimization/52285] [4.7 Regression] libgcrypt _gcry_burn_stack slowdown
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52285
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||ebotcazou at gcc dot
||gnu.org, vmakarov at gcc
||dot gnu.org
--- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2012-02-20
11:13:33 UTC ---
void
foo (int x)
{
char buf[64];
do
{
volatile char *p = buf;
unsigned long l = sizeof buf;
while (l)
{
*p = 0;
p++;
l--;
}
x -= sizeof buf;
}
while (x 0);
}
is a testcase without tail call. With r184317 we keep the buf[64] inside of
the loop, but unfortunately buf[64] is (reg:DI 20 frame) here (buf[0] is
frame-64), and therefore RTL lim doesn't do anything with it.
And when reload reloads that (reg:DI frame) into (minus:DI (reg:DI sp)
(const_int -8)), it doesn't place the lea before the loop, even when the
register pressure is low. And no further pass does the loop invariant move
either.
I wonder if we shouldn't in RTL lim just load (frame) and other most likely
eliminable registers before the loop into some new pseudo (with REG_EQUIV) and
use it in the loop, I think if register pressure is high RA should
rematerialize those inside of the loop, shouldn't it?
[Bug target/52261] [avr] Add support for AVR Xmega cores
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52261 --- Comment #4 from Georg-Johann Lay gjl at gcc dot gnu.org 2012-02-20 11:17:58 UTC --- (In reply to comment #3) Could you add support for the few new devices with USB Support aswell? example Xmega32A4U. I am not sure if that would help much because there is no support in binutils. http://sourceware.org/cgi-bin/cvsweb.cgi/src/gas/config/tc-avr.c?rev=1.79content-type=text/x-cvsweb-markupcvsroot=src Con you compile with -mmcu=avrxmega2 -D__AVR_XMEGA32A4U__ and then assemble and link appropriately?
[Bug libstdc++/52309] [c++0x] unordered_set illegally requires value_type::operator!=
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52309 --- Comment #3 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org 2012-02-20 11:31:07 UTC --- Author: paolo Date: Mon Feb 20 11:31:01 2012 New Revision: 184389 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=184389 Log: 2012-02-20 Paolo Carlini paolo.carl...@oracle.com PR libstdc++/52309 * include/bits/hashtable_policy.h (_Equality_base, true,:: _M_equal(const _Hashtable)): Compare values with operator==. * testsuite/23_containers/unordered_set/operators/52309.cc: New. Added: branches/gcc-4_6-branch/libstdc++-v3/testsuite/23_containers/unordered_set/operators/52309.cc Modified: branches/gcc-4_6-branch/libstdc++-v3/ChangeLog branches/gcc-4_6-branch/libstdc++-v3/include/bits/hashtable_policy.h
[Bug libstdc++/52309] [c++0x] unordered_set illegally requires value_type::operator!=
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52309 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.6.3 --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com 2012-02-20 11:31:56 UTC --- Fixed mainline and 4.6.3.
[Bug libstdc++/52188] [4.7 regression] IPA-CP change broke libstdc++ symbol versioning on Solaris
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52188 --- Comment #13 from Richard Guenther rguenth at gcc dot gnu.org 2012-02-20 11:38:41 UTC --- (In reply to comment #8) First and foremost, sorry for the big delay but I could not have a look at this PR earlier. Nevertheless, I doubt that the decision of the new IPA-CP not to clone the function in question can be called a bug. Yes, if the heuristics or other early optimizations results change, the cloning decision might change again in the future - even in between minor versions if we are really unlucky. Can/do we mark all clones having hidden visibility? Would a matching regexp in the linker script override that? Isn't that a bug?
[Bug middle-end/45472] [4.5/4.6/4.7 Regression] [Middle-end volatile semantics] ICE: in move_op_ascend, at sel-sched.c:6124 with -fselective-scheduling2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45472
--- Comment #21 from Richard Guenther rguenth at gcc dot gnu.org 2012-02-20
11:43:01 UTC ---
(In reply to comment #19)
It seems to me that volatile reads/writes should get their own gimple
statements, not be part of a larger block move. So instead of
vv1 = vv2;
we should have
vv1.a ={v} vv2.a;
vv1.b ={v} vv2.b;
I agree with Paolo's comment in #12 that we want to copy the non-volatile
parts
as a block when possible. It seems like breaking a simple struct assignment
into these separate statements would be best done in the gimplifier so that
front ends don't need to get this right independently.
Out of curiousity, what is the use case for a non-volatile struct object with
volatile members?
There is no valid use-case for this. So I think we should just declare this
issue a non-issue (middle-end wise). If the C or C++ standards say that
vv1 = vv2 should behave as if the copy was elementwise then the frontends
need changing. Certainly not the gimplifier - that's not the kitchen-sink
for things you don't want to properly describe in GENERIC to the middle-end ;)
[Bug tree-optimization/52286] [4.6/4.7 Regression] wrong code bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52286 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.6.3
[Bug bootstrap/52287] [4.7 regression] ICE in ready_remove_first, at haifa-sched.c:1927
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52287 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.7.0
[Bug c/52304] Gcc does not notice missing header instead it shows a warning. The compiled code may work or not.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52304 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #5 from Richard Guenther rguenth at gcc dot gnu.org 2012-02-20 12:03:40 UTC --- indeed
[Bug middle-end/52314] [4.4/4.5/4.6/4.7 Regression] gimplifier produces volatile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52314 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2012-02-20 11:57:38 UTC --- Once I made create_tmp_var_raw use TYPE_MAIN_VARIANT (type) - but I don't remember what the fallout from this was. I suppose at least create_tmp_from_val should do that though, at least strip CV qualifiers and address-space (retaining restrict only?).
[Bug tree-optimization/23286] missed fully redundant expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23286
--- Comment #39 from Richard Guenther rguenth at gcc dot gnu.org 2012-02-20
11:50:00 UTC ---
Apart from that libada bootstrap issue (reproduces with the stage1 compiler),
the testsuite is clean apart from vectorizer testcases which show that
do_hoist_insertion is hoisting stmts across loops
for (i = 0; i N; i++) {
diff = 0;
for (j = k; j M; j+=4) {
diff += in[j+i]*coeff[j];
}
out[i] = out[i] + diff;
}
is turned into
for (i = 0; i N; i++) {
diff = 0;
tem = out[i];
for (j = k; j M; j+=4) {
diff += in[j+i]*coeff[j];
}
out[i] = tem + diff;
}
which confuses outer loop vectorization enough to make it fail for
FAIL: gcc.dg/vect/vect-outer-fir-big-array.c -flto scan-tree-dump-times vect
OU
TER LOOP VECTORIZED 2
FAIL: gcc.dg/vect/vect-outer-fir-lb-big-array.c -flto scan-tree-dump-times vect
OUTER LOOP VECTORIZED 2
FAIL: gcc.dg/vect/vect-outer-fir-lb.c -flto scan-tree-dump-times vect OUTER
LOO
P VECTORIZED 2
FAIL: gcc.dg/vect/vect-outer-fir.c -flto scan-tree-dump-times vect OUTER LOOP
V
ECTORIZED 2
[Bug c++/52302] [4.6.2] cc1plus.exe hungs when compiling
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52302 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.7.0 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2012-02-20 12:10:53 UTC --- .
[Bug c/52283] error: case label does not reduce to an integer constant for constant folded cast expr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52283 --- Comment #11 from chrbr at gcc dot gnu.org 2012-02-20 11:58:28 UTC --- The problem stems from the unconditional forcing of TREE_NO_WARNING in convert_to_integer. This was done to fix PR26632. I don't see how such a forcing can be correct, since the NO_WARNING on a constant would depend on the fact that is casted or not, regardless of the use of the expression in the front end.
[Bug c++/52299] GCC warns on compile time division by zero erroneously
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52299
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed||2012-02-20
Ever Confirmed|0 |1
--- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2012-02-20
12:13:03 UTC ---
Your testcase does not compile. Using
templateunsigned int x
struct test {
static const unsigned int a_
= x ? 10 / x : 10;
};
instead does not reproduce the warning (not even with -Wall).
Please provide preprocessed source and the command-line you are using
to reproduce the issue.
[Bug testsuite/52297] [4.7 Regression] FAIL: gcc.dg/lto/trans-mem-1 c_lto_trans-mem-1_0.o-c_lto_trans-mem-1_1.o link, -flto -fgnu-tm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52297 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target|hppa64-hp-hpux11.11 |hppa64-hp-hpux11.11, ||x86_64-*-* Component|driver |testsuite Target Milestone|--- |4.7.0 Summary|FAIL: |[4.7 Regression] FAIL: |gcc.dg/lto/trans-mem-1 |gcc.dg/lto/trans-mem-1 |c_lto_trans-mem-1_0.o-c_lto |c_lto_trans-mem-1_0.o-c_lto |_trans-mem-1_1.o link, |_trans-mem-1_1.o link, |-flto -fgnu-tm |-flto -fgnu-tm --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2012-02-20 12:15:08 UTC --- Yes, I'm seeing this as well.
[Bug c/52290] [4.4/4.5/4.6/4.7 Regression] internal compiler error: tree check: expected function_decl, have var_decl in start_function, at c-decl.c:7712
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52290 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Known to work||4.0.4 Keywords||error-recovery, ||ice-on-invalid-code Last reconfirmed||2012-02-20 Ever Confirmed|0 |1 Summary|internal compiler error:|[4.4/4.5/4.6/4.7 |tree check: expected|Regression] internal |function_decl, have |compiler error: tree check: |var_decl in start_function, |expected function_decl, |at c-decl.c:7712|have var_decl in ||start_function, at ||c-decl.c:7712 Target Milestone|--- |4.4.7 Known to fail||4.1.0 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2012-02-20 12:17:27 UTC --- Confirmed. Regression from 4.0.
[Bug tree-optimization/52298] ICE: verify_ssa failed: definition in block follows use
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52298 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2012-02-20 12:14:17 UTC --- Mine.
[Bug tree-optimization/52272] [4.7 regression] Performance regresswion of 410.bwaves on x86.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52272 --- Comment #7 from Richard Guenther rguenth at gcc dot gnu.org 2012-02-20 12:21:19 UTC --- Even though it makes sense (I think) the patch regresses more benchmarks than it fixes, and it does not fix the 410.bwaves regression fully. Defering to 4.8 as I don't have any better ideas off my head.
[Bug target/52294] [4.7 Regression] [ARM Thumb] generated asm code produces branch out of range error in gas with -Os -mcpu=cortex-a9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52294 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.7.0
[Bug tree-optimization/52286] [4.6/4.7 Regression] wrong code bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52286 --- Comment #9 from Jakub Jelinek jakub at gcc dot gnu.org 2012-02-20 12:19:54 UTC --- Author: jakub Date: Mon Feb 20 12:19:47 2012 New Revision: 184391 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=184391 Log: PR tree-optimization/52286 * fold-const.c (fold_binary_loc): For (X C1) | C2 optimization use double_int_to_tree instead of build_int_cst_wide, rewrite to use double_int vars. * gcc.c-torture/execute/pr52286.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr52286.c Modified: trunk/gcc/ChangeLog trunk/gcc/fold-const.c trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/52286] [4.6 Regression] wrong code bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52286 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Summary|[4.6/4.7 Regression] wrong |[4.6 Regression] wrong code |code bug|bug --- Comment #10 from Jakub Jelinek jakub at gcc dot gnu.org 2012-02-20 12:52:41 UTC --- Fixed for 4.7 so far.
[Bug rtl-optimization/52208] [4.7 Regression] Useless store
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52208 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org | --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2012-02-20 12:56:19 UTC --- Fixed.
[Bug tree-optimization/52272] [4.7/4.8 regression] Performance regresswion of 410.bwaves on x86.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52272 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org Target Milestone|4.7.0 |4.8.0 Summary|[4.7 regression]|[4.7/4.8 regression] |Performance regresswion of |Performance regresswion of |410.bwaves on x86. |410.bwaves on x86.
[Bug libstdc++/52188] [4.7 regression] IPA-CP change broke libstdc++ symbol versioning on Solaris
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52188 --- Comment #14 from Martin Jambor jamborm at gcc dot gnu.org 2012-02-20 12:57:01 UTC --- (In reply to comment #13) Can/do we mark all clones having hidden visibility? Would a matching regexp in the linker script override that? Isn't that a bug? I believe they are made static, at least TREE_PUBLIC is cleared for their new decls in cgraph_create_virtual_clone. I think the problem was that the original un-cloned function was exported (because IPA-CP decided to ignore it) rather than the cloned one?
[Bug testsuite/52297] [4.7 Regression] FAIL: gcc.dg/lto/trans-mem-1 c_lto_trans-mem-1_0.o-c_lto_trans-mem-1_1.o link, -flto -fgnu-tm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52297 --- Comment #3 from Dominique d'Humieres dominiq at lps dot ens.fr 2012-02-20 13:22:36 UTC --- The tests pass on powerpc-apple-darwin9 and x86_64-apple-darwin10, but not on i686-pc-linux-gnu; so x86_64-*-* does not seem the right target descriptor.
[Bug c++/52315] [C++11] constexpr object of nested class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52315 Daniel Krügler daniel.kruegler at googlemail dot com changed: What|Removed |Added CC||daniel.kruegler at ||googlemail dot com --- Comment #1 from Daniel Krügler daniel.kruegler at googlemail dot com 2012-02-20 13:27:46 UTC --- The code looks ok to me: A::B is considered complete after the };.
[Bug tree-optimization/52298] ICE: verify_ssa failed: definition in block follows use
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52298
--- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2012-02-20
13:41:59 UTC ---
DOM optimizes the |s with zero if you adjust the integer_..._p predicates like
Index: gcc/tree.c
===
--- gcc/tree.c (revision 184390)
+++ gcc/tree.c (working copy)
@@ -1714,12 +1714,25 @@ integer_zerop (const_tree expr)
{
STRIP_NOPS (expr);
- return ((TREE_CODE (expr) == INTEGER_CST
- TREE_INT_CST_LOW (expr) == 0
- TREE_INT_CST_HIGH (expr) == 0)
- || (TREE_CODE (expr) == COMPLEX_CST
- integer_zerop (TREE_REALPART (expr))
- integer_zerop (TREE_IMAGPART (expr;
+ switch (TREE_CODE (expr))
+{
+case INTEGER_CST:
+ return (TREE_INT_CST_LOW (expr) == 0
+ TREE_INT_CST_HIGH (expr) == 0);
+case COMPLEX_CST:
+ return (integer_zerop (TREE_REALPART (expr))
+ integer_zerop (TREE_IMAGPART (expr)));
+case VECTOR_CST:
+ {
+ tree elt;
+ for (elt = TREE_VECTOR_CST_ELTS (expr); elt; elt = TREE_CHAIN (elt))
+ if (!integer_zerop (TREE_VALUE (elt)))
+ return false;
+ return true;
+ }
+default:
+ return false;
+}
}
/* Return 1 if EXPR is the integer constant one or the corresponding
@@ -1730,12 +1743,25 @@ integer_onep (const_tree expr)
{
STRIP_NOPS (expr);
- return ((TREE_CODE (expr) == INTEGER_CST
- TREE_INT_CST_LOW (expr) == 1
- TREE_INT_CST_HIGH (expr) == 0)
- || (TREE_CODE (expr) == COMPLEX_CST
- integer_onep (TREE_REALPART (expr))
- integer_zerop (TREE_IMAGPART (expr;
+ switch (TREE_CODE (expr))
+{
+case INTEGER_CST:
+ return (TREE_INT_CST_LOW (expr) == 1
+ TREE_INT_CST_HIGH (expr) == 0);
+case COMPLEX_CST:
+ return (integer_onep (TREE_REALPART (expr))
+ integer_zerop (TREE_IMAGPART (expr)));
+case VECTOR_CST:
+ {
+ tree elt;
+ for (elt = TREE_VECTOR_CST_ELTS (expr); elt; elt = TREE_CHAIN (elt))
+ if (!integer_onep (TREE_VALUE (elt)))
+ return false;
+ return true;
+ }
+default:
+ return false;
+}
}
/* Return 1 if EXPR is an integer containing all 1's in as much precision as
@@ -1754,6 +1780,15 @@ integer_all_onesp (const_tree expr)
integer_zerop (TREE_IMAGPART (expr)))
return 1;
+ else if (TREE_CODE (expr) == VECTOR_CST)
+{
+ tree elt;
+ for (elt = TREE_VECTOR_CST_ELTS (expr); elt; elt = TREE_CHAIN (elt))
+ if (!integer_all_onesp (TREE_VALUE (elt)))
+ return 0;
+ return 1;
+}
+
else if (TREE_CODE (expr) != INTEGER_CST)
return 0;
I'll queue that for 4.8.
[Bug rtl-optimization/50063] [4.6/4.7 Regression] DSE: wrong code for gcc.dg/torture/pta-ptrarith-3.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50063 --- Comment #19 from Georg-Johann Lay gjl at gcc dot gnu.org 2012-02-20 13:41:39 UTC --- FYI, after updating to SVN 184386 (2012-02-20) I see 14 new FAILs in the avr test suite; all of which can be cured with -fno-dse: FAIL: gcc.c-torture/execute/20020215-1.c execution, -O1 FAIL: gcc.c-torture/execute/20020215-1.c execution, -Os FAIL: gcc.c-torture/execute/930126-1.c execution, -O1 FAIL: gcc.c-torture/execute/991118-1.c execution, -O1 FAIL: gcc.c-torture/execute/991118-1.c execution, -Os FAIL: gcc.c-torture/execute/bf64-1.c execution, -O1 FAIL: gcc.c-torture/execute/bf64-1.c execution, -Os FAIL: gcc.c-torture/execute/pr51877.c execution, -O1 FAIL: gcc.c-torture/execute/pr51877.c execution, -O2 FAIL: gcc.c-torture/execute/pr51877.c execution, -O3 -fomit-frame-pointer FAIL: gcc.c-torture/execute/pr51877.c execution, -O3 -g FAIL: gcc.c-torture/execute/pr51877.c execution, -Os plugin -flto-partition=none FAIL: gcc.c-torture/execute/pr51877.c execution, -O2 -flto -fno-use-linker-plugin -flto-partition=none FAIL: gcc.c-torture/execute/pr51877.c execution, -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects
[Bug rtl-optimization/50063] [4.6/4.7 Regression] DSE: wrong code for gcc.dg/torture/pta-ptrarith-3.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50063 --- Comment #20 from Jakub Jelinek jakub at gcc dot gnu.org 2012-02-20 13:52:50 UTC --- Please just fix up your backend, e.g. by turning that sp = hfp move (insn 47 above) into an UNSPEC move.
[Bug tree-optimization/52298] ICE: verify_ssa failed: definition in block follows use
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52298 --- Comment #5 from Richard Guenther rguenth at gcc dot gnu.org 2012-02-20 14:14:48 UTC --- Not sure why in vect_model_reduction_cost we do not consider the reduction at all if nested_in_vect_loop_p (loop, orig_stmt). I think simply dropping that conditional would model the cost more appropriately (though the question is how outer loop vectorization uses the costs).
[Bug middle-end/52316] New: Loops not optimized away, though result is not used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52316 Bug #: 52316 Summary: Loops not optimized away, though result is not used Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org The following program takes 7.5s without optimization and 1.5s with -O1 to -Ofast. However, for -Ofast, I had expected that the loops are optimized away. However, that does not seem to happen. With ifort -fast, the program takes 0.0s. Found at http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/5ee459a4ddaeab9e# program hello implicit none real :: x, y, n, i, j, t1, t2 call CPU_TIME(t1) n = 3.0 j = 1.0 do while (j n) i = 1.0 do while (i n) x = sin(45.0) * asin(0.5) * sqrt(5.00) * atan(2.) i = i + 1.0 end do j = j + 1 end do call CPU_TIME(t2) print *, t2-t1 !call sleep(10) end program hello
[Bug c++/52315] [C++11] constexpr object of nested class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52315 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-02-20 CC||jason at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2012-02-20 14:53:36 UTC --- I can't see any reason it's not valid either, but I note that clang has exactly the same behaviour. Let's ask Jason.
[Bug middle-end/52316] Loops not optimized away, though result is not used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52316 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2012-02-20 15:07:27 UTC --- Is it sufficiently common to do something that insane though? We optimize away the dead code in there of course, but the problem is that it uses a floating point iterator. I guess our number of iterations analysis just gives up when the IV is floating, here for known compile time constant init value and condition operand if both values are sufficiently small we could compute the number of iterations anyway, but as soon as adding 1 to a floating point value doesn't change it, for IEEE single when the value is 16777216.0f, you end up with an endless loop, and that should be honored even for -Ofast.
[Bug middle-end/52316] Loops not optimized away, though result is not used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52316 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2012-02-20 15:08:05 UTC --- can not prove finiteness of loop 1 can not prove finiteness of loop 2 number of iteration analysis does not work on non-integral IVs.
[Bug tree-optimization/52298] ICE: verify_ssa failed: definition in block follows use
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52298 --- Comment #6 from Richard Guenther rguenth at gcc dot gnu.org 2012-02-20 15:16:00 UTC --- Author: rguenth Date: Mon Feb 20 15:15:52 2012 New Revision: 184396 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=184396 Log: 2012-02-20 Richard Guenther rguent...@suse.de PR tree-optimization/52298 * tree-vect-stmts.c (vectorizable_store): Properly use STMT_VINFO_DR_STEP instead of DR_STEP when vectorizing outer loops. (vectorizable_load): Likewise. * tree-vect-data-refs.c (vect_analyze_data_ref_access): Access DR_STEP after ensuring it is not NULL. * gcc.dg/torture/pr52298.c: New testcase. * gcc.dg/vect/pr52298.c: Likewise. Added: trunk/gcc/testsuite/gcc.dg/torture/pr52298.c trunk/gcc/testsuite/gcc.dg/vect/pr52298.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-data-refs.c trunk/gcc/tree-vect-stmts.c
[Bug tree-optimization/52298] ICE: verify_ssa failed: definition in block follows use
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52298 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #7 from Richard Guenther rguenth at gcc dot gnu.org 2012-02-20 15:16:25 UTC --- Fixed.
[Bug c/52283] error: case label does not reduce to an integer constant for constant folded cast expr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52283 --- Comment #12 from chrbr at gcc dot gnu.org 2012-02-20 15:27:38 UTC --- Created attachment 26705 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26705 Tentative fix. Testing this patch. Avoids setting TREE_NO_WARNING if not necessary, and strip nops to check for unused values, for PR 26632.
[Bug c/52283] error: case label does not reduce to an integer constant for constant folded cast expr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52283 --- Comment #13 from Richard Guenther rguenth at gcc dot gnu.org 2012-02-20 15:40:44 UTC --- Related to PR37985, which is caused by the fix for PR26632, too. I still think that patch should possibly be reverted instead.
[Bug libstdc++/52317] New: incorrect FSF address
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52317 Bug #: 52317 Summary: incorrect FSF address Classification: Unclassified Product: gcc Version: 4.6.3 Status: UNCONFIRMED Severity: trivial Priority: P3 Component: libstdc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: giecr...@stegny.2a.pl the exact version of GCC: gcc-4_6-branch revision 18 the system type: SUSE Linux the options given when GCC was configured/built: + ../configure --prefix=/usr --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64 --enable-languages=c,c++ --enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.6 --enable-ssp --disable-libssp --disable-plugin --with-bugurl=http://bugs.opensuse.org/ '--with-pkgversion=SUSE Linux' --disable-libgcj --disable-libmudflap --with-slibdir=/lib64 --with-system-zlib --enable-__cxa_atexit --enable-libstdcxx-allocator=new --disable-libstdcxx-pch --enable-version-specific-runtime-libs --enable-linker-build-id --program-suffix=-4.6 --enable-linux-futex --without-system-libunwind --with-arch-32=i586 --with-tune=generic --build=x86_64-suse-linux --disable-bootstrap the complete command line that triggers the bug; + exec rpmbuild -ba --define '_srcdefattr (-,root,root)' --define 'disturl obs://build.opensuse.org/home:yecril71pl:branches:devel:gcc/openSUSE_12.1/b48d8f9a68842f6894dde471794ff262-gcc46' --eval %suse_insert_debug_package /home/abuild/rpmbuild/SOURCES/gcc46.spec the compiler output (error messages, warnings, etc.); and libstdc++6-devel.x86_64: W: incorrect-fsf-address /usr/include/c++/4.6/profile/impl/profiler.h libstdc++6-devel.x86_64: W: incorrect-fsf-address /usr/include/c++/4.6/profile/impl/profiler_list_to_slist.h libstdc++6-devel.x86_64: W: incorrect-fsf-address /usr/include/c++/4.6/profile/impl/profiler_trace.h libstdc++6-devel.x86_64: W: incorrect-fsf-address /usr/include/c++/4.6/profile/impl/profiler_vector_to_list.h libstdc++6-devel.x86_64: W: incorrect-fsf-address /usr/include/c++/4.6/profile/impl/profiler_map_to_unordered_map.h libstdc++6-devel.x86_64: W: incorrect-fsf-address /usr/include/c++/4.6/profile/impl/profiler_node.h libstdc++6-devel.x86_64: W: incorrect-fsf-address /usr/include/c++/4.6/profile/impl/profiler_vector_size.h libstdc++6-devel.x86_64: W: incorrect-fsf-address /usr/include/c++/4.6/profile/impl/profiler_container_size.h libstdc++6-devel.x86_64: W: incorrect-fsf-address /usr/include/c++/4.6/profile/impl/profiler_list_to_vector.h libstdc++6-devel.x86_64: W: incorrect-fsf-address /usr/include/c++/4.6/profile/impl/profiler_state.h libstdc++6-devel.x86_64: W: incorrect-fsf-address /usr/include/c++/4.6/profile/impl/profiler_algos.h libstdc++6-devel.x86_64: W: incorrect-fsf-address /usr/include/c++/4.6/profile/base.h libstdc++6-devel.x86_64: W: incorrect-fsf-address /usr/include/c++/4.6/profile/impl/profiler_hashtable_size.h libstdc++6-devel.x86_64: W: incorrect-fsf-address /usr/include/c++/4.6/profile/impl/profiler_hash_func.h The Free Software Foundation address in this file seems to be outdated or misspelled. Ask upstream to update the address, or if this is a license file, possibly the entire file with a new copy available from the FSF.
[Bug libstdc++/52317] incorrect FSF address
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52317 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-02-20 Ever Confirmed|0 |1 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2012-02-20 15:49:49 UTC --- more importantly, those files are GPLv2
[Bug libstdc++/52317] incorrect FSF address
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52317 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2012-02-20 15:51:38 UTC --- Confirmed. It also contains still a GPLv2 and old exception license. Also broken on trunk.
[Bug libstdc++/52317] incorrect FSF address
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52317 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Severity|trivial |normal --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org 2012-02-20 15:54:30 UTC --- the GPLv3 change happened Apr 9 2009, so it looks as though the profile mode authors created their branch before then and never merged the license change, so the profile mode files got added with the wrong license
[Bug libstdc++/52317] incorrect FSF address
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52317 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Severity|normal |trivial --- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2012-02-20 15:56:00 UTC --- Likewise testsuite/20_util/reference_wrapper/invoke-2.cc testsuite/21_strings/basic_string/numeric_conversions/wchar_t/dr1261.cc testsuite/21_strings/basic_string/numeric_conversions/char/dr1261.cc and include/profile/base.h include/profile/unordered_set include/profile/vector include/profile/map.h include/profile/unordered_map include/profile/set include/profile/map
[Bug c/52283] error: case label does not reduce to an integer constant for constant folded cast expr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52283 --- Comment #14 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-02-20 15:59:39 UTC --- (In reply to comment #13) Related to PR37985, which is caused by the fix for PR26632, too. I still think that patch should possibly be reverted instead. I also think that patch should be reverted, and a proper fix for that bug be implemented instead by making the code that emits the warning smarter. I rather have that PR26632 reopen, and no hacks, than these recent ones. BTW, I cannot reproduce this bug in a recent trunk r184311.
[Bug c++/52299] GCC warns on compile time division by zero erroneously
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52299
--- Comment #2 from Joseph Garvin joseph.h.garvin at gmail dot com 2012-02-20
16:45:21 UTC ---
#include cstddef
templatestd::size_t x
struct test {
static const std::size_t a_
= x ? 10 / x : 10;
};
I just forgot to copy and paste the include. My command line is just g++
alignptrtest.cpp
[Bug c++/52299] GCC warns on compile time division by zero erroneously
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52299 --- Comment #3 from Joseph Garvin joseph.h.garvin at gmail dot com 2012-02-20 16:47:23 UTC --- Also this is x86-64, which could be relevant since it affects the underlying type of std::size_t.
[Bug c++/52299] GCC warns on compile time division by zero erroneously
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52299 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2012-02-20 16:53:03 UTC --- Can't reproduce with that either, tried 4.4.6, 4.6.2 and current trunk, x86_64.
[Bug c++/52299] GCC warns on compile time division by zero erroneously
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52299 --- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org 2012-02-20 17:02:03 UTC --- I can't reproduce it with 4.4.3, but then ... (In reply to comment #0) alignptrtest.cpp: In instantiation of ‘const size_t test0ul::a_’: alignptrtest.cpp:11: instantiated from here alignptrtest.cpp:6: warning: division by zero Your testcase doesn't have 11 lines and doesn't instantiate a template. Please provide the right testcase!
[Bug c++/52299] GCC warns on compile time division by zero erroneously
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52299
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #6 from Jonathan Wakely redi at gcc dot gnu.org 2012-02-20
17:11:03 UTC ---
This reproduces it:
templateunsigned x
struct test {
static const unsigned a_
= x ? 10 / x : 10;
};
int i = test0::a_;
but next time please just provide code to reproduce the problem instead of
wasting three people's time (and however many more read the report and didn't
comment)
[Bug libstdc++/52317] incorrect FSF address
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52317 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |paolo.carlini at oracle dot |gnu.org |com --- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com 2012-02-20 17:13:22 UTC --- If nobody beats me to it, I can take care of resolving this issue in mainline and branch: I gather it's just matter of copy-pasting the current v3 license to the profile/ files + those 3 testcases, right? (just making sure I'm not making some horrible mistake from the licensing point of view)
[Bug fortran/32380] misaligned stores don't get vectorized
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32380 --- Comment #10 from Thomas Koenig tkoenig at gcc dot gnu.org 2012-02-20 17:16:38 UTC --- Author: tkoenig Date: Mon Feb 20 17:16:33 2012 New Revision: 184398 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=184398 Log: 2012-02-13 Thomas Koenig tkoe...@gcc.gnu.org PR testsuite/52229 PR fortran/32380 * gfortran.dg/vect/pr32380.f: XFAIL on PowerPC and ia-64. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/vect/pr32380.f
[Bug testsuite/52229] [4.7 Regression] FAIL: gfortran.dg/vect/pr32380.f -O scan-tree-dump-times vect vectorized 7 loops 1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52229 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #3 from Thomas Koenig tkoenig at gcc dot gnu.org 2012-02-20 17:18:03 UTC --- In the absence of any objections and Dominique's approval, I have committed the XFAIL. Closing.
[Bug testsuite/52229] [4.7 Regression] FAIL: gfortran.dg/vect/pr32380.f -O scan-tree-dump-times vect vectorized 7 loops 1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52229 --- Comment #2 from Thomas Koenig tkoenig at gcc dot gnu.org 2012-02-20 17:16:38 UTC --- Author: tkoenig Date: Mon Feb 20 17:16:33 2012 New Revision: 184398 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=184398 Log: 2012-02-13 Thomas Koenig tkoe...@gcc.gnu.org PR testsuite/52229 PR fortran/32380 * gfortran.dg/vect/pr32380.f: XFAIL on PowerPC and ia-64. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/vect/pr32380.f
[Bug testsuite/52229] [4.7 Regression] FAIL: gfortran.dg/vect/pr32380.f -O scan-tree-dump-times vect vectorized 7 loops 1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52229 --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2012-02-20 17:27:07 UTC --- This is wrong. You should use some vector_* or vect* target predicate, like vect_hw_misalign or whatever you actually need.
[Bug tree-optimization/51782] -ftree-sra: Missing address-space information leads to wrong
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51782 --- Comment #20 from Martin Jambor jamborm at gcc dot gnu.org 2012-02-20 17:27:36 UTC --- (In reply to comment #19) base returned from get_base_address should never be NULL, so it's safe to assume it isn't. Otherwise the patch looks ok to me. Unfortunately, when I was bootstrapping a modified patch without the NULL test on x86_64, it segfaulted. The reason is that expand_debug_expr calls set_mem_attributes_minus_bitpos and in t passes MEM[(struct basic_stringbuf *)__s._M_stringbuf]._M_string which might be OK for debug statements, I don't really know. Even though I guess it might wreck havoc in address spaces in debug info, for now I'm reverting to the original patch from comment #17 for the purposes of this PR. Perhaps get_base_address misses a DECL_P in the condition looking into MEM_REFs?
[Bug c++/52299] GCC warns on compile time division by zero erroneously
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52299
--- Comment #7 from Joseph Garvin joseph.h.garvin at gmail dot com 2012-02-20
17:56:20 UTC ---
Sorry, I should have copy and pasted the whole file. I was trying to save
people's time by providing a condensed snippet ;p
(In reply to comment #6)
This reproduces it:
templateunsigned x
struct test {
static const unsigned a_
= x ? 10 / x : 10;
};
int i = test0::a_;
but next time please just provide code to reproduce the problem instead of
wasting three people's time (and however many more read the report and didn't
comment)
[Bug c++/52299] GCC warns on compile time division by zero erroneously
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52299 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Keywords||diagnostic Known to fail||3.4.3, 4.1.2, 4.4.3, 4.5.2, ||4.6.2, 4.7.0 --- Comment #8 from Jonathan Wakely redi at gcc dot gnu.org 2012-02-20 18:02:46 UTC --- condensed is fine, incomplete is not
[Bug libstdc++/52241] Performance degradation of 447.dealII on corei7 at spec2006_base32.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52241 --- Comment #20 from Vladimir Yakovlev vbyakovl23 at gmail dot com 2012-02-20 18:04:45 UTC --- (In reply to comment #19) Nice, so we want Paolo's patch. Out of interest, what are the 447.deal numbers when comparing linking against old (pre-Benjamin's commit) libstdc++.a and current libstdc++.a with Paolo's patch (or libstdc++.so.6, i.e. without -static)? Runspec numbers (as runspec prints) for both static and dynamic Static Base: Old: 447.dealII 11440324 35.3 * New: 447.dealII 11440302 37.9 * Peak: Old: 447.dealII 11440285 40.2 * New: 447.dealII 11440268 42.6 * Dynamic Base: Old: 447.dealII 11440327 34.9 * New: 447.dealII 11440327 35.0 * Peak: Old: 447.dealII 11440287 39.9 S New: 447.dealII 11440288 39.7 * So, no effect in dynamic case. Is it right?
[Bug c++/52299] GCC warns on compile time division by zero erroneously
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52299 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #9 from Jakub Jelinek jakub at gcc dot gnu.org 2012-02-20 18:27:46 UTC --- case COND_EXPR: return build_x_conditional_expr (RECUR (TREE_OPERAND (t, 0)), RECUR (TREE_OPERAND (t, 1)), RECUR (TREE_OPERAND (t, 2)), complain); For this we'd need to first RECUR (TREE_OPERAND (t, 0)), remember that result in some temporary, and look if it is 0, non-zero or unknown. If 0, maybe increment temporarily c_inhibit_evaluation_warnings around RECUR (TREE_OPERAND (t, 1)) (dunno about cp_unevaluated_operand or fold_*defer_overflow_warnings ()), if non-zero similarly for RECUR (TREE_OPERAND (t, 1)).
[Bug middle-end/52314] [4.4/4.5/4.6/4.7 Regression] gimplifier produces volatile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52314 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|NEW --- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org 2012-02-20 19:20:04 UTC --- Actually I have a patch which works around my current issue with fold wrapping a SAVE_EXPR around a SSA_NAME. I hope to move away from fold soonish in the branch I am working on anyways so I will just use that patch until then.
[Bug tree-optimization/52318] New: [4.7 Regression] ICE: in execute_todo, at passes.c:1748 with -O3 -ftracer -fno-tree-ccp -fno-tree-copy-prop -fno-tree-dce and stpcpy_chk()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52318 Bug #: 52318 Summary: [4.7 Regression] ICE: in execute_todo, at passes.c:1748 with -O3 -ftracer -fno-tree-ccp -fno-tree-copy-prop -fno-tree-dce and stpcpy_chk() Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: zso...@seznam.cz Created attachment 26706 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26706 reduced testcase Looks similiar to PR52045 Compiler output: $ gcc -O3 -ftracer -fno-tree-ccp -fno-tree-copy-prop -fno-tree-dce testcase.c testcase.c: In function 'foo': testcase.c:4:6: internal compiler error: in execute_todo, at passes.c:1748 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. (gdb) bt #0 fancy_abort (file=0x128bb58 /mnt/svn/gcc-trunk/gcc/passes.c, line=1748, function=0x128c109 execute_todo) at /mnt/svn/gcc-trunk/gcc/diagnostic.c:898 #1 0x008f9005 in execute_todo (flags=6) at /mnt/svn/gcc-trunk/gcc/passes.c:1748 #2 0x008fc1fe in execute_one_pass (pass=0x1954280) at /mnt/svn/gcc-trunk/gcc/passes.c:2104 #3 0x008fc585 in execute_pass_list (pass=0x1954280) at /mnt/svn/gcc-trunk/gcc/passes.c:2136 #4 0x008fc597 in execute_pass_list (pass=0x17cdd20) at /mnt/svn/gcc-trunk/gcc/passes.c:2137 #5 0x00a5e84e in tree_rest_of_compilation (fndecl=0x75ba6e00) at /mnt/svn/gcc-trunk/gcc/tree-optimize.c:422 #6 0x006b036a in cgraph_expand_function (node=0x75a976c0) at /mnt/svn/gcc-trunk/gcc/cgraphunit.c:1837 #7 0x006b225c in cgraph_expand_all_functions () at /mnt/svn/gcc-trunk/gcc/cgraphunit.c:1904 #8 cgraph_optimize () at /mnt/svn/gcc-trunk/gcc/cgraphunit.c:2218 #9 0x006b28aa in cgraph_finalize_compilation_unit () at /mnt/svn/gcc-trunk/gcc/cgraphunit.c:1344 #10 0x0058eec0 in c_write_global_declarations () at /mnt/svn/gcc-trunk/gcc/c-decl.c:10031 #11 0x009f10cc in compile_file () at /mnt/svn/gcc-trunk/gcc/toplev.c:573 #12 do_compile () at /mnt/svn/gcc-trunk/gcc/toplev.c:1938 #13 toplev_main (argc=17, argv=0x7fffd748) at /mnt/svn/gcc-trunk/gcc/toplev.c:2014 #14 0x761cc09d in __libc_start_main () from /lib64/libc.so.6 #15 0x00572541 in _start () Tested revisions: r184386 - crash 4.6 r180325 - OK
[Bug tree-optimization/51782] -ftree-sra: Missing address-space information leads to wrong
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51782 --- Comment #21 from rguenther at suse dot de rguenther at suse dot de 2012-02-20 19:44:46 UTC --- On Mon, 20 Feb 2012, jamborm at gcc dot gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51782 --- Comment #20 from Martin Jambor jamborm at gcc dot gnu.org 2012-02-20 17:27:36 UTC --- (In reply to comment #19) base returned from get_base_address should never be NULL, so it's safe to assume it isn't. Otherwise the patch looks ok to me. Unfortunately, when I was bootstrapping a modified patch without the NULL test on x86_64, it segfaulted. The reason is that expand_debug_expr calls set_mem_attributes_minus_bitpos and in t passes MEM[(struct basic_stringbuf *)__s._M_stringbuf]._M_string That's an invalid MEM_REF, and the result of set_mem_attributes_minus_bitpos is probably completely bogus. which might be OK for debug statements, I don't really know. Even though I guess it might wreck havoc in address spaces in debug info, for now I'm reverting to the original patch from comment #17 for the purposes of this PR. Ok, probably safer for 4.7 Perhaps get_base_address misses a DECL_P in the condition looking into MEM_REFs? No, sure not - in the above we have a component-ref inside the ADDR_EXPR. Richard.
[Bug tree-optimization/52318] [4.7 Regression] ICE: in execute_todo, at passes.c:1748 with -O3 -ftracer -fno-tree-ccp -fno-tree-copy-prop -fno-tree-dce and stpcpy_chk()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52318 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-02-20 CC||jakub at gcc dot gnu.org Target Milestone|--- |4.7.0 Ever Confirmed|0 |1 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2012-02-20 20:15:02 UTC --- Started with http://gcc.gnu.org/viewcvs?root=gccview=revrev=178527 Will look at this tomorrow.
[Bug libstdc++/52241] Performance degradation of 447.dealII on corei7 at spec2006_base32.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52241 --- Comment #21 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org 2012-02-20 21:08:55 UTC --- Author: paolo Date: Mon Feb 20 21:08:48 2012 New Revision: 184404 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=184404 Log: 2012-02-20 Paolo Carlini paolo.carl...@oracle.com PR libstdc++/52241 * src/c++98/tree.cc (local_Rb_tree_increment, local_Rb_tree_decrement): Add. (_Rb_tree_increment(const _Rb_tree_node_base*), _Rb_tree_decrement(const _Rb_tree_node_base*)): Use the latter. (_Rb_tree_increment(_Rb_tree_node_base*), _Rb_tree_decrement(_Rb_tree_node_base*)): New. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/src/c++98/tree.cc
[Bug libstdc++/52241] Performance degradation of 447.dealII on corei7 at spec2006_base32.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52241 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #22 from Paolo Carlini paolo.carlini at oracle dot com 2012-02-20 21:10:50 UTC --- Fixed for 4.7.0.
[Bug libstdc++/52241] Performance degradation of 447.dealII on corei7 at spec2006_base32.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52241 --- Comment #23 from Paolo Carlini paolo.carlini at oracle dot com 2012-02-20 21:16:41 UTC --- PS: Vladimir, thanks a lot for all the good testing!
[Bug libstdc++/52300] Gthreads functions linking error at dynamic linking with libstdc++ when using MinGW.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52300 --- Comment #3 from Kai Tietz ktietz at gcc dot gnu.org 2012-02-20 21:22:11 UTC --- Author: ktietz Date: Mon Feb 20 21:22:07 2012 New Revision: 184406 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=184406 Log: PR libstdc++/52300 * gthr.h (GTHREAD_USE_WEAK): Define as zero for mingw. Modified: trunk/libgcc/ChangeLog trunk/libgcc/gthr.h
[Bug libstdc++/52300] Gthreads functions linking error at dynamic linking with libstdc++ when using MinGW.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52300 --- Comment #4 from Kai Tietz ktietz at gcc dot gnu.org 2012-02-20 21:28:41 UTC --- Author: ktietz Date: Mon Feb 20 21:28:36 2012 New Revision: 184408 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=184408 Log: PR libstdc++/52300 * gthr.h (GTHREAD_USE_WEAK): Define as zero for mingw. Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/gthr.h
[Bug libstdc++/52300] Gthreads functions linking error at dynamic linking with libstdc++ when using MinGW.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52300 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #5 from Kai Tietz ktietz at gcc dot gnu.org 2012-02-20 21:29:21 UTC --- Fixed.
[Bug c++/52233] ICE segmentation fault with non-recursive templates
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52233 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-valid-code Status|UNCONFIRMED |NEW Last reconfirmed||2012-02-20 Ever Confirmed|0 |1 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2012-02-20 21:39:43 UTC --- Confirmed.
[Bug c++/52247] [4.5 Regression] ICE with asm goto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52247 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-02-20 Ever Confirmed|0 |1 --- Comment #4 from Andrew Pinski pinskia at gcc dot gnu.org 2012-02-20 21:40:12 UTC --- Confirmed.
[Bug c++/52281] No warnings generated for unused captures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52281 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |NEW Last reconfirmed||2012-02-20 Ever Confirmed|0 |1 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2012-02-20 21:42:11 UTC --- Confirmed.
[Bug translation/52262] translatable string typos (3): REAl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52262 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org 2012-02-20 21:42:58 UTC --- .
[Bug translation/52246] translatable string typo: plural use (one translatable objects)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52246 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org 2012-02-20 21:43:13 UTC --- .
[Bug translation/52232] translatable string typos: conindexed (should be coindexed)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52232 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org 2012-02-20 21:44:03 UTC --- .
[Bug translation/52273] translatable string typo: at at %L
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52273 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #5 from Andrew Pinski pinskia at gcc dot gnu.org 2012-02-20 21:44:49 UTC --- .
[Bug middle-end/52285] [4.7 Regression] libgcrypt _gcry_burn_stack slowdown
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52285 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-02-20 Component|tree-optimization |middle-end Ever Confirmed|0 |1 --- Comment #6 from Andrew Pinski pinskia at gcc dot gnu.org 2012-02-20 21:45:53 UTC --- Confirmed.
[Bug translation/52245] translatable string: Fortran F2003
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52245 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org 2012-02-20 21:43:35 UTC --- .
[Bug middle-end/52316] Loops not optimized away, though result is not used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52316 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-02-20 Depends on||14886 Ever Confirmed|0 |1 --- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org 2012-02-20 21:47:44 UTC --- Related to PR 14886.
[Bug libstdc++/52317] incorrect FSF address
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52317 --- Comment #6 from Christopher Yeleighton giecrilj at stegny dot 2a.pl 2012-02-20 21:54:11 UTC --- Created attachment 26707 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26707 updates the FSF address in boilerplate comments
[Bug target/52238] -mms-bitfields: __attribute__ ((aligned (n))) ignored for struct members
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52238
--- Comment #9 from Kai Tietz ktietz at gcc dot gnu.org 2012-02-20 22:05:12
UTC ---
Author: ktietz
Date: Mon Feb 20 22:05:08 2012
New Revision: 184409
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=184409
Log:
PR target/52238
* stor-layout.c (place_field): Handle desired_align for
ms-bitfields, too.
* gcc.dg/bf-ms-layout-3.c: New testcase.
Added:
trunk/gcc/testsuite/gcc.dg/bf-ms-layout-3.c (with props)
Modified:
trunk/gcc/ChangeLog
trunk/gcc/stor-layout.c
trunk/gcc/testsuite/ChangeLog
Propchange: trunk/gcc/testsuite/gcc.dg/bf-ms-layout-3.c
('svn:eol-style' added)
Propchange: trunk/gcc/testsuite/gcc.dg/bf-ms-layout-3.c
('svn:mime-type' added)
[Bug libstdc++/52317] incorrect FSF address
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52317 --- Comment #7 from Jonathan Wakely redi at gcc dot gnu.org 2012-02-20 22:05:32 UTC --- The entire boilerplate text needs to be updated to GPLv3, and the new text doesn't include the postal address at all, so the patch isn't right.
[Bug libstdc++/52317] incorrect FSF address
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52317 --- Comment #8 from Paolo Carlini paolo.carlini at oracle dot com 2012-02-20 22:08:14 UTC --- Indeed.
[Bug target/52238] -mms-bitfields: __attribute__ ((aligned (n))) ignored for struct members
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52238
--- Comment #10 from Kai Tietz ktietz at gcc dot gnu.org 2012-02-20 22:09:52
UTC ---
Author: ktietz
Date: Mon Feb 20 22:09:48 2012
New Revision: 184410
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=184410
Log:
PR target/52238
* stor-layout.c (place_field): Handle desired_align for
ms-bitfields, too.
* gcc.dg/bf-ms-layout-3.c: New testcase.
Added:
branches/gcc-4_6-branch/gcc/testsuite/gcc.dg/bf-ms-layout-3.c (with
props)
Modified:
branches/gcc-4_6-branch/gcc/ChangeLog
branches/gcc-4_6-branch/gcc/stor-layout.c
branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
Propchange: branches/gcc-4_6-branch/gcc/testsuite/gcc.dg/bf-ms-layout-3.c
('svn:eol-style' added)
Propchange: branches/gcc-4_6-branch/gcc/testsuite/gcc.dg/bf-ms-layout-3.c
('svn:mime-type' added)
[Bug target/52238] -mms-bitfields: __attribute__ ((aligned (n))) ignored for struct members
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52238 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #11 from Kai Tietz ktietz at gcc dot gnu.org 2012-02-20 22:18:33 UTC --- I don't intend to back-port this patch to 4.5, or to 4.4. Therefore close report
[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 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-02-20 Ever Confirmed|0 |1 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2012-02-20 22:25:25 UTC --- Confirmed.
[Bug ada/52319] New: Legal program rejected, use clause in subpackage invalidates use type clause
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52319 Bug #: 52319 Summary: Legal program rejected, use clause in subpackage invalidates use type clause Classification: Unclassified Product: gcc Version: 4.6.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassig...@gcc.gnu.org ReportedBy: nicolas.bouleng...@free.fr The following legal program is rejected by gnatgcc -c proc.adb with proc.adb:17:28: there is no applicable operator And for type Standard.Integer All works fine if P2 is removed. procedure Proc is package P1 is type T is new Integer; function and (L, R : in Integer) return T; end P1; package body P1 is function and (L, R : in Integer) return T is pragma Unreferenced (L, R); begin return 0; end and; end P1; use type P1.T; package P2 is use P1; end P2; G : P1.T := Integer'(1) and Integer'(2); begin null; end Proc;
[Bug c++/52315] [C++11] constexpr object of nested class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52315 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Comment #3 from Jason Merrill jason at gcc dot gnu.org 2012-02-20 22:44:01 UTC --- 3.3.7: 1) The potential scope of a name declared in a class consists not only of the declarative region following the name’s point of declaration, but also of all function bodies, brace-or-equal-initializers of non-static data members, and default arguments in that class (including such things in nested classes). So within B::value, A::stuff is in scope, so we need to wait until A is complete to parse B::value, so B::value can't be used in constant expressions in A.
[Bug c++/52315] [C++11] constexpr object of nested class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52315 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2012-02-20 22:59:43 UTC --- Shouldn't testcases like this be added to the testsuite anyway, with the expected error?
[Bug c++/52312] grokfndecl: valgrind problem
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52312 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2012-02-20 23:34:48 UTC --- Author: jakub Date: Mon Feb 20 23:34:42 2012 New Revision: 184416 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=184416 Log: PR c++/52312 * typeck.c (check_literal_operator_args): Initialize *long_double_p and *long_long_unsigned_p even if processing_template_decl. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/typeck.c
[Bug c++/52312] grokfndecl: valgrind problem
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52312 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2012-02-20 23:36:33 UTC --- Fixed.
[Bug middle-end/52141] [trans-mem] ICE due to asm statement in trans-mem.c:expand_block_tm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52141 --- Comment #3 from Aldy Hernandez aldyh at gcc dot gnu.org 2012-02-20 23:43:35 UTC --- Author: aldyh Date: Mon Feb 20 23:43:31 2012 New Revision: 184417 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=184417 Log: PR middle-end/52141 * trans-mem.c (ipa_tm_scan_irr_block): Error out on GIMPLE_ASM's in a transaction safe function. Added: trunk/gcc/testsuite/gcc.dg/tm/pr52141.c Modified: trunk/gcc/ChangeLog trunk/gcc/trans-mem.c
[Bug middle-end/52141] [trans-mem] ICE due to asm statement in trans-mem.c:expand_block_tm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52141 Aldy Hernandez aldyh at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #4 from Aldy Hernandez aldyh at gcc dot gnu.org 2012-02-20 23:45:58 UTC --- fixed in trunk
[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 Benjamin Kosnik bkoz at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #6 from Benjamin Kosnik bkoz at gcc dot gnu.org 2012-02-21 00:22:31 UTC --- fixed
