[Bug testsuite/32038] gfortran.dg/pr25603.f is invalid code
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2007-05-24 07:02 --- Please do so -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32038
[Bug testsuite/32062] gcc revision 20070523 - Non-existant sse4 test (with wrong path) causes UNSUPPORTED for working tests
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-05-24 07:16 --- 2.17 does not have SSE 4.1 support, it was added just recently (like say within the last 2 months). So either a FAIL or an UNSUPPORTED. I rather have an UNSUPPORTED as it does not show up in the test results. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32062
[Bug bootstrap/32009] [4.3 Regression] building gcc4-4.3.0-20070518 failed on OSX 10.3.9
--- Comment #13 from dominiq at lps dot ens dot fr 2007-05-24 07:17 --- For me too. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32009
[Bug testsuite/32038] gfortran.dg/pr25603.f is invalid code
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-05-22 13:09:29 |2007-05-24 07:31:14 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32038
[Bug fortran/29786] [4.1/4.2/4.3 Regression] Initialization of overlapping variables: Not implemented
--- Comment #11 from pault at gcc dot gnu dot org 2007-05-24 08:10 --- Just to let you all know; I have had a patch ready for this and PR30875 for somewhile. This was awaiting the commit of Brook's simplify_transfer patch and all the machinery in target-memory.c. Well, during the wait it suffered a bit of x86_ia64 specific bit-rot, whose cause I just do not see right now. Ia m working on it, though:) Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29786
[Bug testsuite/32062] gcc revision 20070523 - Non-existant sse4 test (with wrong path) causes UNSUPPORTED for working tests
--- Comment #6 from ubizjak at gmail dot com 2007-05-24 08:28 --- This is just a problem in the testsuite. gcc figures out that blendpd with 0x03 (and blendps with 0x0f) immediate operand can be substituted with simple move. H.J. has been informed about this and will update the tests. Rest assusred, that your assembler supports _none_ of sse4.1 insns, and after testsuite update, all tests will fail for you ;) Notice that the test of sse4.15233.c uses the path . In addition, the file sse4.15233.c did not exist the other day when I got the SVN _AND_ it still does not exist now when I re-got the SVN a few minutes ago. I checked my HD to see if it was generated, it does not exist. This file that bothers you s much is generated from the testsute check procedure that checks if your assembler includes sse4.1 insns. As you figure out, it is automatically deleted after the test. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32062
[Bug target/32065] New: Many dfp testsuite failures for -msse targets
gcc -march=pentium4 -O2 cast.c cast.c: In function âmainâ: cast.c:88: error: unrecognizable insn: (insn 11 10 12 3 cast.c:52 (set (subreg:TI (reg:TD 63) 0) (subreg:TI (const_double:TD 0 [0x0] 2.0 [N/A]) 0)) -1 (nil) (nil)) cast.c:88: internal compiler error: in extract_insn, at recog.c:2119 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. -- Summary: Many dfp testsuite failures for -msse targets Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ubizjak at gmail dot com GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32065
[Bug target/32065] Many dfp testsuite failures for -msse targets
--- Comment #1 from ubizjak at gmail dot com 2007-05-24 09:05 ---
Rediced testcase (the constant is not important):
_Decimal128 test (void)
{
return 1234123412341234.123412341234dl;
}
gcc -O2 -msse
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32065
[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
--- Comment #153 from rguenther at suse dot de 2007-05-24 09:03 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement
new does not change the dynamic type as it should
On Thu, 23 May 2007, gdr at cs dot tamu dot edu wrote:
--- Comment #151 from gdr at cs dot tamu dot edu 2007-05-24 00:58 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the
dynamic type as it should
rguenther at suse dot de [EMAIL PROTECTED] writes:
[...]
| Gaby's model says that we know less about dynamic types than we
| presently think we do, because there might be a union out there
| somewhere. (Fortunately, as Joseph points out, C99 has already answered
| this question. Surely we can agree that making C99 and C++ different in
| this respect is a bad idea.)
|
| I don't think dragging in unions helps us here ;) Maybe Gaby can clarify
| if and how unions relate here, but I didn't percieve any previous comment
| as making implicit unions relevant here apart from what GCC and
| apperantly C99 agree to.
I believe we all agree that placement new changes the dynamic type.
I brought in the union example to point of a fundamental problem with
this issue. I have been following the discussion without saying much,
until I realized that the interpretation Mark was offering is a
redefinition of the C++ object model that conflicts with the current
standard text. That was the point of the union example. In the
example
void f(int* p, double* q) {
*p = 42;
*q = 3.12;
}
All we know is that after the store to *p, the object there will have
type int (if it did not already have one). Similarly, for the store
to *q, the object there will have type double. Can the stores be
rearranged? Under the current C++ rules (which were inherited from
C90, and not C99) yes if we know that the objects are distinct.
Can we infer the disjoinctness from the types? Not always under
current C++ rules for union, and in this specific case, the answer is
no.
Right, current C++ rules forbid exchanging the stores. But I read it
as it is because the stores may start lifetime of a different
dynamically typed object on the same memory location which p and q
may point to. Whether there is a union placed at this memory
location is irrelevant. I read the standard as if the above is
equivalent to
*(new (p) int) = 42;
*(new (q) double) = 3.12;
which as long as we cannot prove that p does not point to the
same memory location as q means that we cannot reorder the stores.
Richard.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
--- Comment #154 from rguenther at suse dot de 2007-05-24 10:07 --- Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should On Wed, 23 May 2007, mark at codesourcery dot com wrote: Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should rguenther at suse dot de wrote: Whatever conservative assumptions we want to make about *p = 3 we could make about new (p) int instead. True. I say making them about *p = 3 is way easier as we are changing semantics of memory operations and *p = 3 is one, but placement new is not. I think I understand what you're saying here too; again, I'll restate to make sure: (a) In the model where *p = 3 changes the dynamic type of memory, we don't need to do anything special to handle placement new. (b) It's relatively easy to implement support for *p = 3 changing the dynamic type of memory. (c) Therefore, it's relatively easy to fix our placement new problem. I agree with those statements too. However, I don't like this approach because I believe it will result in inferior code. I think that you're looking at the proposed placement new patches, then looking at what they do to a particular codebase, which happens to use placement-new in an inner loop, and becoming unhappy with the patches. I suspect that the changes required to support the *p = 3 model, while perhaps better for that case, will be worse for many others. I can't prove that. But, I did implement TBAA after looking at what other compilers did, specifically to improve performance of (ironically) POOMA. So, I'm afraid that you're going to find that if we allow memory writes to change the type of memory, that we will get worse performance. So I did some benchmarking with my two proposed patches (which I believe will fix all current issues - that I know of) on IA64 which should be sensitive to the more restrictive scheduling. [You can look yourself at the results starting from http://www.suse.de/~gcctest/, the run without the patches is from late May23th the run with the patch from early May24th] I'll try to summarize only here. - SPECfpu2000 shows both winners and loosers, the net change is slightly positive for -O3 and slightly negative for -O3 -funroll-loops (slightly means +3 points vs. -4 points) - SPECint2000 shows more variance in single tests, crafty winning for peak, parser loosing for base, eon winning overall, likewise bzip. Overall we get a drop in SPECint of about 3 points (0.3%) - Polyhedron is mostly the same, aermod regressing 1.5%, induct improving 1%. - The set of C++ benchmarks (including TraMP-3d, DLV, Boost wave and others) show no changes. Of course this doesn't prove anything - it only hints that it might be not as bad as you thought. And no, I don't have a Power6 machine to test on yet. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
--- Comment #155 from rguenther at suse dot de 2007-05-24 10:11 --- Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should On Thu, 24 May 2007, rguenther at suse dot de wrote: So I did some benchmarking with my two proposed patches (which I believe will fix all current issues - that I know of) on IA64 which should be sensitive to the more restrictive scheduling. [You can look yourself at the results starting from http://www.suse.de/~gcctest/, the run without the patches is from late May23th the run with the patch from early May24th] I'll try to summarize only here. - SPECfpu2000 shows both winners and loosers, the net change is slightly positive for -O3 and slightly negative for -O3 -funroll-loops (slightly means +3 points vs. -4 points) - SPECint2000 shows more variance in single tests, crafty winning for peak, parser loosing for base, eon winning overall, likewise bzip. Overall we get a drop in SPECint of about 3 points (0.3%) - Polyhedron is mostly the same, aermod regressing 1.5%, induct improving 1%. - The set of C++ benchmarks (including TraMP-3d, DLV, Boost wave and others) show no changes. Of course this doesn't prove anything - it only hints that it might be not as bad as you thought. And no, I don't have a Power6 machine to test on yet. Btw, in case you are curious - on http://www.suse.de/~gcctest/c++bench/tramp3d/split-run.html you can see the effects of the asm() memory barrier as proposed by one of Ians patches and the effect of forcing -fno-strict-aliasing on (the two spikes in runtime, the later one is -fno-strict-aliasing, the earlier one is the asm()). Both approaches disable moving loop invariant loads which is one thing you retain with my proposed slightly changed TBAA rules. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
--- Comment #156 from gdr at cs dot tamu dot edu 2007-05-24 10:29 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the
dynamic type as it should
rguenther at suse dot de [EMAIL PROTECTED] writes:
[...]
| I brought in the union example to point of a fundamental problem with
| this issue. I have been following the discussion without saying much,
| until I realized that the interpretation Mark was offering is a
| redefinition of the C++ object model that conflicts with the current
| standard text. That was the point of the union example. In the
| example
|
| void f(int* p, double* q) {
| *p = 42;
| *q = 3.12;
| }
|
| All we know is that after the store to *p, the object there will have
| type int (if it did not already have one). Similarly, for the store
| to *q, the object there will have type double. Can the stores be
| rearranged? Under the current C++ rules (which were inherited from
| C90, and not C99) yes if we know that the objects are distinct.
| Can we infer the disjoinctness from the types? Not always under
| current C++ rules for union, and in this specific case, the answer is
| no.
|
| Right, current C++ rules forbid exchanging the stores. But I read it
| as it is because the stores may start lifetime of a different
| dynamically typed object on the same memory location which p and q
| may point to.
Which is equivalent to having the union, in all aspects.
Now, if I understand your argument below correctly, you are saying
that even if we fixed the union rules for C++, we may still be facing
the same problem because assignment to POD objects does not just mean
that the object was there before, but that we are actually starting a
new one. Do I understand your argument correctly?
| Whether there is a union placed at this memory
| location is irrelevant. I read the standard as if the above is
| equivalent to
|
| *(new (p) int) = 42;
| *(new (q) double) = 3.12;
|
| which as long as we cannot prove that p does not point to the
| same memory location as q means that we cannot reorder the stores.
-- Gaby
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
--- Comment #157 from rguenther at suse dot de 2007-05-24 10:33 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement
new does not change the dynamic type as it should
On Thu, 24 May 2007, gdr at cs dot tamu dot edu wrote:
--- Comment #156 from gdr at cs dot tamu dot edu 2007-05-24 10:29 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the
dynamic type as it should
rguenther at suse dot de [EMAIL PROTECTED] writes:
[...]
| I brought in the union example to point of a fundamental problem with
| this issue. I have been following the discussion without saying much,
| until I realized that the interpretation Mark was offering is a
| redefinition of the C++ object model that conflicts with the current
| standard text. That was the point of the union example. In the
| example
|
| void f(int* p, double* q) {
| *p = 42;
| *q = 3.12;
| }
|
| All we know is that after the store to *p, the object there will have
| type int (if it did not already have one). Similarly, for the store
| to *q, the object there will have type double. Can the stores be
| rearranged? Under the current C++ rules (which were inherited from
| C90, and not C99) yes if we know that the objects are distinct.
| Can we infer the disjoinctness from the types? Not always under
| current C++ rules for union, and in this specific case, the answer is
| no.
|
| Right, current C++ rules forbid exchanging the stores. But I read it
| as it is because the stores may start lifetime of a different
| dynamically typed object on the same memory location which p and q
| may point to.
Which is equivalent to having the union, in all aspects.
Now, if I understand your argument below correctly, you are saying
that even if we fixed the union rules for C++, we may still be facing
the same problem because assignment to POD objects does not just mean
that the object was there before, but that we are actually starting a
new one. Do I understand your argument correctly?
Yes. For non-PODs I'm not sure if it is allowed to start object
lifetime via assignment rather than only by placement new.
Richard.
| Whether there is a union placed at this memory
| location is irrelevant. I read the standard as if the above is
| equivalent to
|
| *(new (p) int) = 42;
| *(new (q) double) = 3.12;
|
| which as long as we cannot prove that p does not point to the
| same memory location as q means that we cannot reorder the stores.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
--- Comment #158 from gdr at cs dot tamu dot edu 2007-05-24 10:47 --- Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should rguenther at suse dot de [EMAIL PROTECTED] writes: [...] | Now, if I understand your argument below correctly, you are saying | that even if we fixed the union rules for C++, we may still be facing | the same problem because assignment to POD objects does not just mean | that the object was there before, but that we are actually starting a | new one. Do I understand your argument correctly? | | Yes. Then, I'm not sure I agree with that. I'll raise it as part of the union problem. | For non-PODs I'm not sure if it is allowed to start object | lifetime via assignment rather than only by placement new. Assignment for non-POD is equivalent to calling a member function for an object, which means that the object already existed. So, no you cannot start lifetime for object of non-POD type by assignment. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug tree-optimization/31981] Missed forw prop with indirect ref and addr.
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-05-24 10:54 --- is this fixed on pointer_plus branch? Confirmed on the mainline. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-05-24 10:54:13 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31981
[Bug testsuite/32038] gfortran.dg/pr25603.f is invalid code
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-05-24 10:57 --- Subject: Bug 32038 Author: fxcoudert Date: Thu May 24 09:56:50 2007 New Revision: 125019 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125019 Log: PR fortran/32038 * gfortran.dg/pr25603.f: Initialize integer variables. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/pr25603.f -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32038
[Bug testsuite/32038] gfortran.dg/pr25603.f is invalid code
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-05-24 10:57 --- Fixed -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32038
[Bug tree-optimization/31981] Missed forw prop with indirect ref and addr.
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-05-24 11:09 --- Actually this is just a tree-combining issue. CCP already transforms this to c_1 = b.t[0]; D.2000_3 = i_2(D) * 4; D.2001_4 = (int *) D.2000_3; D.2002_5 = D.2001_4 + b.t[0]; *D.2002_5 = 1; not combining D.2001_4 + b.t[0]. There is nothing forwprop can do about this with the existing framework, but of course it can be extended to propagate OFFSET + OBJ. Easier to do this after the pointer_plus merge. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31981
[Bug tree-optimization/31982] Missed forw prop with indirect ref and addr. (and char types or sizeof(type) == 1)
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-05-24 11:11 --- Confirmed. Of course it needs to read char *c = b-t; -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-05-24 11:11:24 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31982
[Bug target/27067] Compile errors with multiple inheritance where the stdcall attribute is applied to virtual functions.
--- Comment #16 from dannysmith at gcc dot gnu dot org 2007-05-24 11:12 --- Subject: Bug 27067 Author: dannysmith Date: Thu May 24 10:11:49 2007 New Revision: 125020 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125020 Log: ChangeLog PR target/27067 * doc/tm.texi (TARGET_MANGLE_DECL_ASSEMBLER_NAME): Document. * targhooks.h (default_mangle_decl_assembler_name): Declare default hook. * targhooks.c (default_mangle_decl_assembler_name): Define default hook. * target-def.h (TARGET_MANGLE_DECL_ASSEMBLER_NAME) New. Set to default hook. * target.h (struct gcc_target): Add mangle_decl_assembler_name field. * langhooks.c (lhd_set_decl_assembler_name): Call targetm.mangle_decl_assembler_name for names with global scope. * config/i386/cygming.h (TARGET_MANGLE_DECL_ASSEMBLER_NAME) Override default. (ASM_OUTPUT_DEF_FROM_DECLS): Simplify to use DECL_ASSEMBLER_NAME. * config/i386/i386-protos.h (i386_pe_mangle_decl_assembler_name): Declare. * config/i386/winnt.c (i386_pe_maybe_mangle_decl_assembler_name): New. Factored out of i386_pe_encode_section_info. (gen_stdcall_or_fastcall_suffix): Get name identifier as argument. Move check for prior decoration of stdcall symbols to i386_pe_encode_section_info. (i386_pe_encode_section_info): Adjust call to gen_stdcall_or_fastcall_suffix. Use i386_pe_maybe_mangle_decl_assembler_name, if needed. (i386_pe_mangle_decl_assembler_name): New. Wrap i386_pe_maybe_mangle_decl_assembler_name. cp/ChangeLog * mangle.c (mangle_decl): Call targetm.mangle_decl_assembler_name. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/cygming.h trunk/gcc/config/i386/i386-protos.h trunk/gcc/config/i386/winnt.c trunk/gcc/cp/ChangeLog trunk/gcc/cp/mangle.c trunk/gcc/doc/tm.texi trunk/gcc/langhooks.c trunk/gcc/target-def.h trunk/gcc/target.h trunk/gcc/targhooks.c trunk/gcc/targhooks.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27067
[Bug target/27067] Compile errors with multiple inheritance where the stdcall attribute is applied to virtual functions.
--- Comment #17 from dannysmith at users dot sourceforge dot net 2007-05-24 11:18 --- Fixed on trunk -- dannysmith at users dot sourceforge dot net changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27067
[Bug tree-optimization/31982] Missed forw prop with indirect ref and addr. (and char types or sizeof(type) == 1)
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-05-24 11:22 --- I have a patch for this one. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-05-24 11:11:24 |2007-05-24 11:22:40 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31982
[Bug c++/32066] New: member/type lookup doesn't work properly with templates
The following is adapted from the example from the C++ standard, clause 14.6/4
(actually it's the updated version from DR345):
1 struct A {
2 struct X { };
3 static int X;
4 } ;
5 templateclass T void f(T t) {
6 typename T::X x; // invalid
7 T::X y; // invalid
8 int z = T::X; // OK
9 }
10 void foo() {
11 A a;
12 f(a); // error: T::X refers to the data member A::X not
13 // the struct A::X.
14 }
I've removed the `B' class from the example, made A::X static (so that T::X may
be used to reference it), and added lines 7 and 8. According to the standard,
clause 14.6/4, all the `T::X' should find the data member X, *not* the type
member X, regardless of the `typename' keyword.
In this case, however, GCC 4.1.1 has not done this, and gives the following
diagnostics:
t.cxx: In function void f(T):
t.cxx:7: error: expected `;' before y
Line 6 has been compiled OK; `T::X' has found the type.
Line 7 has been rejected correctly; `T::X' has not found a type, which means
the `typename' keyword in line 6 was significant.
Line 8 has been compiled correctly; `T::X' has found the data member.
--
Summary: member/type lookup doesn't work properly with templates
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: andrew dot stubbs at st dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32066
[Bug libgcj/24403] --enable-java-awt=qt fails to build
--- Comment #11 from bero at arklinux dot org 2007-05-24 11:53 --- ping... This is known and will not be fixed until 4.2. Now that 4.2 is released and it still doesn't work, can we get this working in 4.3? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24403
[Bug c++/32067] New: templateclass T XOR-Swap(T a, T b); error with -O0 option
It gives an unexpected result while doing xor operation on a templated class.
For sample, here is my simple code:
--
#include iostream
using namespace std;
template
class T
inline void XOR-Swap(T a, T b)
{
if (a != b)
a ^= b ^= a ^= b;
};
int main()
{
int a = 10;
int b = -3;
XOR-Swap(a, b);
cout a endl;
cout b endl;
return 0;
}
-
Results:
1. with -O0: Incorrect
---
0
10
---
2. with -O1: Correct
---
-3
10
---
Any comment?
--
Summary: templateclass T XOR-Swap(T a, T b); error with -O0
option
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: nanericwang at hotmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32067
[Bug c++/32068] New: vector push_back()/resize() causes assignment to deleted memory
The codes below basically builds a binary tree. It runs well on Intel
compiler. However, when I use gcc 4.2.0, the assignment to b[i].right
causes segmentation fault. Tracing with valgrind reveals that the
particular memory address was deleted during push_back().
If I change the assignments to
int x = build_recursive(n-1);
int y = build_recursive(n-1);
b[i].left = x;
b[i].right = y;
there is no segmentation fault anymore. It seems to me the original
code has the b[i] value cached, hence, during the assignment to
b[i].right, it uses old b[i] which may be invalidated after
push_back() due to resize.
Any ideas? Compiler problems? or non-trivial bugs? Thanks.
#include vector
using std::vector;
class A {
public:
int left;
int right;
};
class B {
public:
void build(int n) {
b.clear();
next_index = 0;
int root = build_recursive(n);
}
int build_recursive(int n) {
int i = get_next_index();
if (n 0) {
b[i].left = build_recursive(n-1);
b[i].right = build_recursive(n-1);
}
return i;
}
int get_next_index(void) {
A a;
b.push_back(a);
int index = next_index++;
return index;
}
int next_index;
vectorA b;
};
int main(int argc, char* argv[])
{
B tree;
tree.build(14);
return 0 ;
}
--
Summary: vector push_back()/resize() causes assignment to deleted
memory
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: cshinyee at gmail dot com
GCC host triplet: Linux
GCC target triplet: x86_64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32068
[Bug c++/32067] templateclass T XOR-Swap(T a, T b); error with -O0 option
--- Comment #1 from pluto at agmk dot net 2007-05-24 12:31 --- (In reply to comment #0) Any comment? this is an example of undefined behaviour. http://blogs.msdn.com/rick_schaut/archive/2004/03/06/85357.aspx -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32067
[Bug middle-end/32006] [4.3 Regression] ICE (segv) in tree-vrp (use of uninitialised values)
--- Comment #3 from burnus at gcc dot gnu dot org 2007-05-24 12:47 --- *** This bug has been marked as a duplicate of 32018 *** -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32006
[Bug middle-end/32018] [4.3 Regression] ICE on optimization
--- Comment #3 from burnus at gcc dot gnu dot org 2007-05-24 12:47 --- *** Bug 32006 has been marked as a duplicate of this bug. *** -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||tobias dot burnus at physik ||dot fu-berlin dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32018
[Bug rtl-optimization/32069] New: segfault in regclass() with -O0 -fsplit-wide-types
-bash-3.2$ /usr/local/gcc/bin/gcc -O0 -fsplit-wide-types /tmp/segfault.c -S -o /dev/null /tmp/segfault.c: In function 'segfault': /tmp/segfault.c:4: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. The lower subreg pass sets regno_reg_rtx[i] to NULL_RTX when splitting register i. regclass() uses PSEUDO_REGNO_MODE(i) which expands to GET_MODE (regno_reg_rtx[i)) and gives the segfault. -- Summary: segfault in regclass() with -O0 -fsplit-wide-types Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rask at sygehus dot dk GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32069
[Bug rtl-optimization/32069] segfault in regclass() with -O0 -fsplit-wide-types
--- Comment #1 from rask at sygehus dot dk 2007-05-24 13:28 --- Created an attachment (id=13608) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13608action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32069
[Bug bootstrap/32070] New: ICE during the build phase of the compiler
Configured as ../configure --prefix=/mnt/home3/piotrw/tower/tools/gcc-4.1.2 --enable-threads=posix --with-dwarf2 --enable-languages=c,c++ When trying to build 4.1.2 using GCC3.4.4 on a PA-RISC-based HPUX machine, the following error is reported: make[3]: Entering directory `/export/home3/piotrw/tower/build/gcc-4.1.2/objdir/gcc' /export/home3/piotrw/tower/build/gcc-4.1.2/objdir/./gcc/xgcc -B/export/home3/piotrw/tower/build/gcc-4.1.2/objdir/./gcc/ -B/mnt/home3/piotrw/tower/tools/gcc-4.1.2/hppa2.0w-hp-hpux11.11/bin/ -B/mnt/home3/piotrw/tower/tools/gcc-4.1.2/hppa2.0w-hp-hpux11.11/lib/ -isystem /mnt/home3/piotrw/tower/tools/gcc-4.1.2/hppa2.0w-hp-hpux11.11/include -isystem /mnt/home3/piotrw/tower/tools/gcc-4.1.2/hppa2.0w-hp-hpux11.11/sys-include -O2 -O2 -g -O2 -DIN_GCC-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I. -I../../gcc -I../../gcc/. -I../../gcc/../include -I../../gcc/../libcpp/include -DL_muldi3 -c ../../gcc/libgcc2.c -o libgcc/./_muldi3.o ../../gcc/libgcc2.c:1: internal compiler error: in default_no_named_section, at varasm.c:5144 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. make[3]: *** [libgcc/./_muldi3.o] Error 1 make[3]: Leaving directory `/export/home3/piotrw/tower/build/gcc-4.1.2/objdir/gcc' make[2]: *** [libgcc.a] Error 2 make[2]: Leaving directory `/export/home3/piotrw/tower/build/gcc-4.1.2/objdir/gcc' make[1]: *** [all-gcc] Error 2 make[1]: Leaving directory `/export/home3/piotrw/tower/build/gcc-4.1.2/objdir' make: *** [all] Error 2 -- Summary: ICE during the build phase of the compiler Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: wyderski at ii dot uni dot wroc dot pl GCC build triplet: HP-UX B.11.11 U 9000/800 (PA-RISC) GCC host triplet: HP-UX B.11.11 U 9000/800 (PA-RISC) GCC target triplet: HP-UX B.11.11 U 9000/800 (PA-RISC) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32070
[Bug middle-end/32044] udivdi3 counterproductive, unwarranted use
--- Comment #13 from malitzke at metronets dot com 2007-05-24 14:08 --- Mr Guenther! Thank you (herzlichen Dank) for the information about the hopefully disabling flag. If that information would have been posted after my initial intervention we could have saved a lot of bandwidth and storage space. I realize libgcc is one of the areas you are responsible for and libgcc definitely fills a need for a hosted implementation. Also, (at least for me) the optimization is strictly an internal matter for the gcc community and I have nothing to contribute in this regard. To sum up; as a user, and, in the UNIX spirit (I started with the 7th edition), I just want freedom in choosing the facilities and features gcc has to offer. I hope that this or similar flags provide me with the capability to banish libgcc and similar facilities from my programs under the C free-standing specification. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32044
[Bug fortran/29786] [4.1/4.2/4.3 Regression] Initialization of overlapping variables: Not implemented
--- Comment #12 from patchapp at dberlin dot org 2007-05-24 13:57 --- Subject: Bug number PR29786 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-05/msg01609.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29786
[Bug c++/32068] vector push_back()/resize() causes assignment to deleted memory
--- Comment #1 from pcarlini at suse dot de 2007-05-24 14:01 --- (In reply to comment #0) If I change the assignments to int x = build_recursive(n-1); int y = build_recursive(n-1); b[i].left = x; b[i].right = y; there is no segmentation fault anymore. It seems to me the original code has the b[i] value cached, hence, during the assignment to b[i].right, it uses old b[i] which may be invalidated after push_back() due to resize. Right, the problem is that build_recursive does a push_back, which reallocates the vector, and when it returns the original b[i] is not pointing to vector memory anymore. This kind of code is clearly invalid, may work by chance on an implementation which pre-allocates at start some capacity, but will fail at some large size anyway. -- pcarlini at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32068
[Bug testsuite/31883] [testsuite, gfortran] typos in the dg directives of the gfortran testsuite
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2007-05-24 14:39 --- Closing -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31883
[Bug c++/32071] New: Partial explicit specialization template parameters not checked
The following C++ code should not compile:
templateclass T1
class C
{
templateclass T2
class C2 { };
};
template templateclass X, class Y
class Cint::C2 { };
template templateint
class Cfloat::C2 { };
The first specialization has too many parameters.
the second specialization has the wrong type of parameters.
The C++ standard clause 14.7.3/18 says they parameters must have the same
types. I would assume that includes whether they exist, or not.
--
Summary: Partial explicit specialization template parameters not
checked
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: andrew dot stubbs at st dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32071
[Bug middle-end/32018] [4.3 Regression] ICE on optimization
--- Comment #4 from rakdver at gcc dot gnu dot org 2007-05-24 15:02 --- Subject: Bug 32018 Author: rakdver Date: Thu May 24 14:02:12 2007 New Revision: 125024 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125024 Log: PR middle-end/32018 * tree-ssa-threadupdate.c (thread_through_loop_header): Use set_loop_copy. (thread_through_all_blocks): Call initialize_original_copy_tables and free_original_copy_tables. * cfgloopmanip.c (duplicate_loop, duplicate_loop_to_header_edge): Use set_loop_copy. * tree-cfg.c (tree_duplicate_sese_region): Ditto. * cfghooks.c (duplicate_block): Use get_loop_copy. * cfg.c: Include cfgloop.h. (loop_copy): New hash table. (initialize_original_copy_tables): Initialize loop_copy table. (free_original_copy_tables): Free loop_copy table. (copy_original_table_clear, copy_original_table_set, set_loop_copy, get_loop_copy): New functions. (set_bb_original, set_bb_copy): Use copy_original_table_set. * cfgloop.h (struct loop): Remove copy field. * Makefile.in (cfg.o): Add CFGLOOP_H dependency. * basic-block.h (set_loop_copy, get_loop_copy): Declare. Modified: trunk/gcc/ChangeLog trunk/gcc/Makefile.in trunk/gcc/basic-block.h trunk/gcc/cfg.c trunk/gcc/cfghooks.c trunk/gcc/cfgloop.h trunk/gcc/cfgloopmanip.c trunk/gcc/tree-cfg.c trunk/gcc/tree-ssa-threadupdate.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32018
[Bug testsuite/32062] gcc revision 20070523 - Non-existant sse4 test (with wrong path) causes UNSUPPORTED for working tests
--- Comment #7 from hjl at gcc dot gnu dot org 2007-05-24 15:12 --- Subject: Bug 32062 Author: hjl Date: Thu May 24 14:12:18 2007 New Revision: 125025 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125025 Log: 2007-05-24 H.J. Lu [EMAIL PROTECTED] PR testsuite/32062 * gcc.target/i386/sse4_1-check.h (MASK): New. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/i386/sse4_1-check.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32062
[Bug testsuite/32062] gcc revision 20070523 - Non-existant sse4 test (with wrong path) causes UNSUPPORTED for working tests
--- Comment #8 from hjl at lucon dot org 2007-05-24 15:13 --- All SSE4.1 testcases should fail now if assembler dosn't support SSE4.1. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32062
[Bug c++/24664] Template instantiation generating an array of voids doesn't fail
--- Comment #2 from andrew dot stubbs at st dot com 2007-05-24 15:27 --- You can create an array of functions. Also prohibited by clause 14.8.2/2. template class T int f(T[5]); typedef void (fn)(); int K = ffn(0); At least it doesn't seem to accept reference types ... -- andrew dot stubbs at st dot com changed: What|Removed |Added CC||andrew dot stubbs at st dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24664
[Bug bootstrap/32009] [4.3 Regression] building gcc4-4.3.0-20070518 failed on OSX 10.3.9
--- Comment #14 from dominiq at lps dot ens dot fr 2007-05-24 15:31 --- I have run what I can of the testsuite (gcc, g++, gfortran, and objc) without regression. I have also run my version of the polyhedron tests and got: with Makefile.*'s from revision 124627 1891.060u 84.040s 33:15.89 98.9% with original revision + all the patches 1933.980u 88.770s 34:23.23 98.0%0+0k 14+429io 0pf+0w so an average solwdown of ~2.4%. slightly below the estimate from the comment: This fix speeds compiles by 3-5%. This seems evenly distibuted between compile and execution times and between the different cases, though this is only a visual impression and not a careful check (I can do it if there is any interest). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32009
[Bug c++/32067] templateclass T XOR-Swap(T a, T b); error with -O0 option
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-05-24 16:21 --- http://gcc.gnu.org/bugs.html#nonbugs_c *** This bug has been marked as a duplicate of 11751 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32067
[Bug c/11751] wrong evaluation order of an expression
--- Comment #75 from pinskia at gcc dot gnu dot org 2007-05-24 16:21 --- *** Bug 32067 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||nanericwang at hotmail dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11751
[Bug libgcj/32034] Use of deprecated classes in gcc-4_2-build/i686-pc-linux-gnu/libjava/classpath/tools
--- Comment #1 from tromey at gcc dot gnu dot org 2007-05-24 16:33 --- I think the proper fix here is to disable this warning in tools. -- tromey at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-05-24 16:33:19 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32034
[Bug middle-end/32044] udivdi3 counterproductive, unwarranted use
--- Comment #15 from manu at gcc dot gnu dot org 2007-05-24 16:37 --- (In reply to comment #14) The flag just disables an optimisation. If you want to disable optimisations just use -O0. On the other hand, shouldn't -ffreestanding prevent udivdi3 ? What about -fno-builtin-udivdi3 ? OK. I found the answer myself: PR16470. So if you want a freestanding environment, use static libgcc. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32044
[Bug middle-end/32044] udivdi3 counterproductive, unwarranted use
--- Comment #14 from manu at gcc dot gnu dot org 2007-05-24 16:27 --- (In reply to comment #13) To sum up; as a user, and, in the UNIX spirit (I started with the 7th edition), I just want freedom in choosing the facilities and features gcc has to offer. I hope that this or similar flags provide me with the capability to banish libgcc and similar facilities from my programs under the C free-standing specification. The flag just disables an optimisation. If you want to disable optimisations just use -O0. On the other hand, shouldn't -ffreestanding prevent udivdi3 ? What about -fno-builtin-udivdi3 ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32044
[Bug target/31109] gcc 3.3 not functioning under Interix 3.5
--- Comment #2 from markus dot duft at salomon dot at 2007-05-24 17:18 --- Have you disabled DEP? A description of how to do this can be found here: www.interopsystems.com -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31109
[Bug libgcj/32028] Make fails at gjdoc - gnu.classpath.tools.gjdoc.ParseException: unmatched input in line 1: @Retention(SOURCE) @Target(METHOD)
--- Comment #1 from tromey at gcc dot gnu dot org 2007-05-24 17:18 --- I think gjdoc only recently got support for generics and annotations. So an older gjdoc is expected to fail. I haven't been keeping track of gjdoc version numbers but I expect if you install a newer version this will work. Can you try that? -- tromey at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32028
[Bug regression/32072] New: g++ -O3 fails on code that compiles with -O2
The bug is present in the 4.2.0 release and still in the 20070523 snapshot.
It was not present in 4.2-20070405-1 (from Debian experimental).
The error occured in a program using stxxl (http://stxxl.sourceforge.net) with
mcstl (http://algo2.iti.uni-karlsruhe.de/singler/mcstl/). Since mcstl requires
openmp, this can't be tested with g++ earlier than 4.2, although the problem
does not look openmp related and it should be possible to produce a test case
without mcstl/openmp dependency.
I minimized the testcase to the following:
#include sstream
void f () {
std::ostringstream str_;
str_ x;
throw std::ios_base::failure(str_.str());
}
and compiled it with
/data/gcc/snapshot-4.2/bin/g++ -W -Wall -I /home/andreas/work/mpi/mcstl/c++ -I
/home/andreas/work/mpi/mcstl/originals/_data_gcc_snapshot-4.2_include_c++_4.2.1
-c -O[23] t.cpp
(.../mcstl/originals/_data_gcc_snapshot-4.2_include_c++_4.2.1/original is a
symlink to /data/gcc/snapshot-4.2/include/c++/4.2.1 and required by mcstl to
find the original STL headers, since mcstl wraps the STL headers in order to
provide parallelism)
Compiling with -O2 succeeds, while -O3 fails with
/data/gcc/snapshot-4.2/lib/gcc/i686-pc-linux-gnu/4.2.1/../../../../include/c++/4.2.1/bits/ostream_insert.h:
In function void std::__ostream_fill(std::basic_ostream_CharT, _Traits,
std::streamsize) [with _CharT = char, _Traits = std::char_traitschar]:
/data/gcc/snapshot-4.2/lib/gcc/i686-pc-linux-gnu/4.2.1/../../../../include/c++/4.2.1/bits/ostream_insert.h:96:
instantiated from std::basic_ostream_CharT, _Traits
std::__ostream_insert(std::basic_ostream_CharT, _Traits, const _CharT*,
std::streamsize) [with _CharT = char, _Traits = std::char_traitschar]
/home/andreas/work/mpi/mcstl/originals/_data_gcc_snapshot-4.2_include_c++_4.2.1/original/ostream:517:
instantiated from std::basic_ostreamchar, _Traits
std::operator(std::basic_ostreamchar, _Traits, const char*) [with _Traits
= std::char_traitschar]
t.cpp:7: instantiated from here
/data/gcc/snapshot-4.2/lib/gcc/i686-pc-linux-gnu/4.2.1/../../../../include/c++/4.2.1/bits/ostream_insert.h:64:
error: struct std::basic_ostreamchar, std::char_traitschar has no member
named fill
--
Summary: g++ -O3 fails on code that compiles with -O2
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: regression
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcc at abeckmann dot de
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32072
[Bug regression/32072] g++ -O3 fails on code that compiles with -O2
--- Comment #1 from gcc at abeckmann dot de 2007-05-24 17:26 --- Created an attachment (id=13609) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13609action=view) preprocessed source code of the test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32072
[Bug java/31853] ICE in bootstrap compiling gnu.CORBA.ObjectCreator
--- Comment #1 from tromey at gcc dot gnu dot org 2007-05-24 17:31 --- Could you get a stack trace at the point of the ICE? That might help. If that doesn't help, though, all that remains is debugging jc1 to see what goes wrong. If you have the time another thing to try is building a later version, for instance svn trunk. Maybe you've stumbled across a bug that got fixed later on. -- tromey at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-05-24 17:31:11 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31853
[Bug java/31853] ICE in bootstrap compiling gnu.CORBA.ObjectCreator
--- Comment #2 from deknuydt at esat dot kuleuven dot be 2007-05-24 17:51 --- (In reply to comment #1) If you have the time another thing to try is building a later version, for instance svn trunk. Maybe you've stumbled across a bug that got fixed later on. I tried 4.2.0 which was released since. And there the problem is gone; everything build well. So in a practical sense the bug disappeared. If you want, I can try the latest 4.1-branch ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31853
[Bug libgcj/24403] --enable-java-awt=qt fails to build
--- Comment #12 from tromey at gcc dot gnu dot org 2007-05-24 17:59 --- Do you have a copyright assignment? If so I will review the proposed patch. I think the bigger problem is that the Qt peers are not really maintained. ISTR that they still have some pretty serious bugs, though that is just hearsay, as I have not tried them myself. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24403
[Bug java/31853] ICE in bootstrap compiling gnu.CORBA.ObjectCreator
--- Comment #3 from tromey at gcc dot gnu dot org 2007-05-24 18:02 --- Unless you need 4.1 and plan to work on this bug, I would like to close it. What do you think? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31853
[Bug regression/32072] g++ -O3 fails on code that compiles with -O2
--- Comment #2 from pcarlini at suse dot de 2007-05-24 18:36 --- This is an mcstl issue, of which we are not responsible: if look inside PR32072.ii you will discover that somehow, in basic_ios.h, the fill method has been replaced by an __mcstl_hidden_fill and the fill method is not available anymore, whereas it should, definitely. Most likely mcstl is confusing it with std::fill algorithm... -- pcarlini at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32072
[Bug c++/32073] New: Loop unrolling does not exploit VRP for loop bound
Loops with a bounded, small number of iterations unroll too much. They should
be peeled away instead. For example, if I compile the following function with
``-O3 -funroll-loops'':
void short_loop(int* dest, int* src, int count) {
// same happens for assert(count = 4) and if(count 4) exit(-1)
if(count 4)
count = 4;
for(int i=0; i count; i++)
dest[i] = src[i];
}
The assembly output (for i686-pc-cygwin) is an 8x duff's device, of which 75%
of the code will never execute (translated back to C++ here for readability):
void short_loop(int* dest, int* src, int count) {
// same happens for assert(count = 4) and if(count 4) exit(-1)
if(count 4)
count = 4;
int mod = count % 8;
switch(mod) {
case 7:
// loop body
count--;
case 6:
// loop body
count--;
case 5:
// loop body
count--;
case 4:
// loop body
count--;
case 3:
// loop body
count--;
case 2:
// loop body
count--;
case 1:
// loop body
count--;
default:
for(int i=0; i count; i+=8)
// 8x unrolled loop body
}
}
We need 25% of that code:
void short_loop(int* dest, int* src, int count) {
// same happens for assert(count = 4) and if(count 4) exit(-1)
if(count 4)
count = 4;
switch(count) {
case 4:
// loop body
case 3:
// loop body
case 2:
// loop body
case 1:
// loop body
default:
break;
}
}
--
Summary: Loop unrolling does not exploit VRP for loop bound
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: scovich at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32073
[Bug regression/32072] g++ -O3 fails on code that compiles with -O2
--- Comment #3 from gcc at abeckmann dot de 2007-05-24 19:04 --- But why does g++ behave differently if called with different optimization levels? I was looking for a mcstl bug first, but since g++ accepted this code with -O2 I went for g++. On the other hand, if this is actually a bug in mcstl (and the generated code is invalid/incomplete/broken/whatever), shouldn't g++ reject the code regardless of the optimization level? -- gcc at abeckmann dot de changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32072
[Bug regression/32072] g++ -O3 fails on code that compiles with -O2
--- Comment #4 from pcarlini at suse dot de 2007-05-24 19:07 --- Please, stop fiddling with Bugzilla. I pointed you to the real reason of the bug, and you should simply report it to mcstl. And of course, GCC is allowed to behave differently at different optimization levels, because at low optimization level fill is not inlined and can be resolved from the *.so because it's exported. -- pcarlini at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32072
[Bug c/32074] New: Optimizer does not exploit assertions
It would be nice if the optimizer took advantage of assertions. I realize that
assertions may not be enabled for production code, but even when disabled they
are still explicit statements of the programmer's assumptions; the compiler
should be able to exploit those assumptions if it yields better code (or avoids
annoying warnings).
To me, ``assert(!bad_thing)'' indicates that ``bad_thing'' should not be
allowed to happen; compiling with assertions disabled means that ''bad_thing''
is assumed not to happen. Therefore, code that breaks when ``bad_thing ==
true'' is my bug, not the compiler's, and not necessarily worse than the bug(s)
caused by return values or side effects of ``correct'' code after an enabled
assertion would have terminated the program.
For example, -funroll_loops on the following code results in an 8x duff's
device, even though no acceptable input will run more than twice. In this
particular case, ``if(bad thing) exit(-1)'' does the same thing.
void short_loop(int* dest, int* src, int count) {
// same happens for if(count 2) exit(-1)
assert(count = 2);
for(int i=0; i count; i++)
dest[i] = src[i];
}
As another example, compiling the following switch statement with -Wall causes
complaints about control reaching the end of a non-void function:
int limited_switch(int a, int b, int what) {
switch(what) {
case 0:
return a+b;
case 1:
return a;
case 2:
return b;
case 3:
return a-b;
default:
// unreachable
assert(false);
}
}
The following variant of the previous switch statement, which also has an
undefined return value for (what 0 || what = 4), doesn't cause any warnings
at all, though it's arguably less correct -- at least with the first variant
the programmer indicated that she thought the matter through.
int limited_switch(int a, int b, int what) {
int result;
switch(what) {
case 0:
result = a+b;
break;
case 1:
result = a;
break;
case 2:
result = b;
break;
case 3:
result = a-b;
break;
default:
break;
}
return result;
}
--
Summary: Optimizer does not exploit assertions
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: scovich at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32074
[Bug regression/32072] g++ -O3 fails on code that compiles with -O2
--- Comment #5 from pcarlini at suse dot de 2007-05-24 19:43 --- Something we *can* do is more strictly inhibiting implicit instantiation of __ostream_insert (already ok in mainline). But really, mcstl should never touch the basic_ios::fill function, has nothing to do with std::fill. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32072
[Bug libgcj/32028] Make fails at gjdoc - gnu.classpath.tools.gjdoc.ParseException: unmatched input in line 1: @Retention(SOURCE) @Target(METHOD)
--- Comment #2 from rob1weld at aol dot com 2007-05-24 19:48 --- The configure script ought to check for gjdoc version - I _do_ have the newest version from using apt-get update apt-get upgrade - how are people supposed to use the --with-gjdoc if it is not better documaented? The gcc SVN needs to include the neccesary version of gjdoc source to compile the Java documentation that is in the SVN. Here is some info from Classpath (not gcc) that might help in future so I will put this here for reference: How to generate API Documentation with gjdoc/libxmlj: http://www.gnu.org/software/classpath/faq/faq/faq.html#faq5_1 Here is some info on building NEWER gjdoc: http://gcc.gnu.org/ml/java/2004-11/msg00169.html I'll try this and get back in a while ... Thanks for your help. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32028
[Bug libstdc++/32068] vector push_back()/resize() causes assignment to deleted memory
--- Comment #2 from fang at csl dot cornell dot edu 2007-05-24 19:55 --- Suggestion: determine some lower bound of the size (or exact) N prior to a sequence of push_back()s, and call vector::reserve(N) in advance. Then as long as the capacity isn't exceeded, you avoid any reallocation. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32068
[Bug testsuite/32062] Some MASKs aren't sufficient in certain sse4_1 testsA MASK is non-efficient in certain sse4_1 testsSome MASKs aren't sufficient in certain sse4_1 tests
--- Comment #9 from rob1weld at aol dot com 2007-05-24 20:03 --- Thank you for looking into this, everyone. I do appreciate it working correctly. Here is the extreme steps I took to fix my problem. It is not reasonable that the average person would be assumed to know this (something is broken and it's not my fault ;) ), but here it is for the sake of documentaion ... --- # wget http://ftp.debian.org/debian/pool/main/b/binutils/binutils_2.17cvs20070426-7_i386.deb # dpkg -i binutils_2.17cvs20070426-7_i386.deb Preparing to replace binutils 2.17-3 (using binutils_2.17cvs20070426-7_i386.deb) ... Unpacking replacement binutils ... dpkg: dependency problems prevent configuration of binutils: binutils depends on libc6 (= 2.5-5); however: Version of libc6 on system is 2.3.6.ds1-13. dpkg: error processing binutils (--install): dependency problems - leaving unconfigured Errors were encountered while processing: binutils # apt-get install libc6 Reading package lists... Done Building dependency tree... Done libc6 is already the newest version. You might want to run `apt-get -f install' to correct these: The following packages have unmet dependencies: binutils: Depends: libc6 (= 2.5-5) but 2.3.6.ds1-13 is to be installed --- NFG ! --- So instead do this. # dpkg-deb -x binutils_2.17cvs20070426-7_i386.deb tmp # cp tmp/usr/lib/libopcodes-2.17.50.20070426.so /usr/lib # cp tmp/usr/lib/libbfd-2.17.50.20070426.so /usr/lib # mv /usr/bin/as /usr/bin/as-Origonal # cp tmp/usr/bin/as /usr/bin # as --version GNU assembler (GNU Binutils for Debian) 2.17.50.20070426 # diff -u gcc/testsuite/gcc/gcc-try2-log.txt gcc/testsuite/gcc/gcc-try3-log.txt | tail -n 20 === gcc Summary === -# of expected passes 45242 +# of expected passes 45374 # of unexpected failures 90 # of unexpected successes 2 # of expected failures 134 # of unresolved testcases 38 # of untested testcases28 -# of unsupported tests 372 +# of unsupported tests 306 Target: i686-pc-linux-gnu gcc version 4.3.0 20070523 (experimental) # grep -n Assembler\ messages gcc/testsuite/gcc/gcc-try*-log.txt gcc/testsuite/gcc/gcc-try1-log.txt:114819:/tmp/cceBAOxd.s: Assembler messages: gcc/testsuite/gcc/gcc-try1-log.txt:114823:/tmp/cceBAOxd.s: Assembler messages: gcc/testsuite/gcc/gcc-try1-log.txt:114891:/tmp/ccV6VpRr.s: Assembler messages: gcc/testsuite/gcc/gcc-try1-log.txt:114895:/tmp/ccV6VpRr.s: Assembler messages: gcc/testsuite/gcc/gcc-try2-log.txt:114850:/tmp/ccKqTs3N.s: Assembler messages: gcc/testsuite/gcc/gcc-try2-log.txt:114854:/tmp/ccKqTs3N.s: Assembler messages: gcc/testsuite/gcc/gcc-try2-log.txt:114922:/tmp/ccMwoETb.s: Assembler messages: gcc/testsuite/gcc/gcc-try2-log.txt:114926:/tmp/ccMwoETb.s: Assembler messages: gcc/testsuite/gcc/gcc-try3-log.txt: (NOTHING) That is as fixed as it gets. _Unless_ you have some advice to offer. -- rob1weld at aol dot com changed: What|Removed |Added Status|RESOLVED|VERIFIED Summary|Some MASKs aren't sufficient|Some MASKs aren't sufficient |in certain sse4_1 tests |in certain sse4_1 testsA |A MASK is non-efficient in |MASK is non-efficient in |certain sse4_1 tests|certain sse4_1 testsSome |Some MASKs aren't sufficient|MASKs aren't sufficient in |in certain sse4_1 tests |certain sse4_1 tests http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32062
[Bug bootstrap/31746] Broken ./configure sed scripting affecting *gcc/configargs.h construction.
--- Comment #7 from rob1weld at aol dot com 2007-05-24 20:05 --- Thanks, works OK. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31746
[Bug c/32074] Optimizer does not exploit assertions
--- Comment #1 from fang at csl dot cornell dot edu 2007-05-24 20:07 --- It would be nice to unify (run-time) assertions with compile-time directives as a fine-grain mechanism for telling the compiler what it can or cannot assume. 'restrict' is one example where the non-aliasing constraint could be expressed as some form of assertion on pointer ranges and equality. Does VRP (or any other value-flow analysis) support not values? Maybe __builtin_expect could provide some hints somewhere... -- fang at csl dot cornell dot edu changed: What|Removed |Added CC||fang at csl dot cornell dot ||edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32074
[Bug target/9468] [HP-UX] 3.2.1 ICE building libgcc muldi3.o when dwarf2 is enabled
--- Comment #15 from sje at cup dot hp dot com 2007-05-24 20:50 --- *** Bug 32070 has been marked as a duplicate of this bug. *** -- sje at cup dot hp dot com changed: What|Removed |Added CC||wyderski at ii dot uni dot ||wroc dot pl http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9468
[Bug bootstrap/32070] ICE during the build phase of the compiler
--- Comment #1 from sje at cup dot hp dot com 2007-05-24 20:50 --- HPPA HP-UX platforms do not support the dwarf debugging format. *** This bug has been marked as a duplicate of 9468 *** -- sje at cup dot hp dot com changed: What|Removed |Added CC||sje at cup dot hp dot com Status|UNCONFIRMED |RESOLVED GCC build triplet|HP-UX B.11.11 U 9000/800|hppa*-*-hpux* |(PA-RISC) | GCC host triplet|HP-UX B.11.11 U 9000/800|hppa*-*-hpux* |(PA-RISC) | GCC target triplet|HP-UX B.11.11 U 9000/800|hppa*-*-hpux* |(PA-RISC) | Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32070
[Bug tree-optimization/32073] Loop unrolling does not exploit VRP for loop bound
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-05-24 22:48 --- VRP information is not preserved over optimization passes, so loop unrolling does not know about it. But VRP recognizes that count is = 4. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org, rakdver at gcc dot gnu ||dot org Status|UNCONFIRMED |NEW Component|c++ |tree-optimization Ever Confirmed|0 |1 Keywords||missed-optimization Last reconfirmed|-00-00 00:00:00 |2007-05-24 22:48:10 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32073
[Bug middle-end/32074] Optimizer does not exploit assertions
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-05-24 22:54 --- __builtin_expect should not be overloaded, but __builtin_assert/assume/whatever could be invented for this. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Component|c |middle-end Ever Confirmed|0 |1 Keywords||missed-optimization Last reconfirmed|-00-00 00:00:00 |2007-05-24 22:54:10 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32074
[Bug tree-optimization/32075] New: can't determine dependence between p-a[x+i] and p-a[x+i+1] where x is invariant but defined in the function
While looking into some failures on the pointer plus branch after fixing up
forwprop, I noticed that we would get a failure in the vectorizer testsuite and
the reason is because we no longer could determine dependence for the two data
accesses.
Here is the testcase which is a modified version of vect-102.c which gets us
the same IR as what the pointer plus branch gives:
/* { dg-require-effective-target vect_int } */
#include stdlib.h
#include stdarg.h
#include tree-vect.h
#define N 9
struct extraction
{
int a[N];
int b[N];
};
static int a[N] = {1,2,3,4,5,6,7,8,9};
static int b[N] = {2,3,4,5,6,7,8,9,9};
int main1 (int x, int y) {
int i;
unsigned x1 = x;
struct extraction *p;
p = (struct extraction *) malloc (sizeof (struct extraction));
for (i = 0; i N; i++)
{
p-a[i] = a[i];
if (x == 135)
abort (); /* to avoid vectorization */
}
/* Not vectorizable: distance 1. */
for (i = 0; i N - 1; i++)
{
p-a[x1 + i] = p-a[x1 + i + 1];
}
/* check results: */
for (i = 0; i N; i++)
{
if (p-a[i] != b[i])
abort();
}
return 0;
}
int main (void)
{
check_vect ();
return main1 (0, N);
}
/* { dg-final { scan-tree-dump-times vectorized 1 loops 0 vect } } */
/* { dg-final { scan-tree-dump-times possible dependence between data-refs 1
vect } } */
/* { dg-final { cleanup-tree-dump vect } } */
-- cut ---
if you change the 1 to 8, we should be able to vectorize that loop too.
Note I was wrong in PR 31995, that we got the same IR for that testcase as we
got for this bug, I had missed the cast in the IR. Anyways this is
represenative of what the IR looks like for the testcase on the pointer plus
branch.
--
Summary: can't determine dependence between p-a[x+i] and p-
a[x+i+1] where x is invariant but defined in the
function
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32075
[Bug middle-end/32074] Optimizer does not exploit assertions
--- Comment #3 from fang at csl dot cornell dot edu 2007-05-24 22:57 --- Subject: Re: Optimizer does not exploit assertions --- Comment #2 from rguenth at gcc dot gnu dot org 2007-05-24 22:54 --- __builtin_expect should not be overloaded, but __builtin_assert/assume/whatever could be invented for this. My bad, I misspoke, I meant assert, of course. :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32074
[Bug rtl-optimization/32069] segfault in regclass() with -O0 -fsplit-wide-types
--- Comment #2 from ian at gcc dot gnu dot org 2007-05-24 23:12 --- Subject: Bug 32069 Author: ian Date: Thu May 24 22:12:31 2007 New Revision: 125043 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125043 Log: PR rtl-optimization/32069 * regclass.c (regclass): Don't crash if the entry in regno_reg_rtx is NULL. Added: trunk/gcc/testsuite/gcc.dg/pr32069.c Modified: trunk/gcc/ChangeLog trunk/gcc/regclass.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32069
[Bug rtl-optimization/32069] segfault in regclass() with -O0 -fsplit-wide-types
--- Comment #3 from ian at airs dot com 2007-05-24 23:14 --- Fixed. -- ian at airs dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32069
[Bug tree-optimization/32075] can't determine dependence between p-a[x+i] and p-a[x+i+1] where x is invariant but defined in the function
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-25 02:05 --- Ok, I have a patch for this issue, I am going to test it with -ftree-vectorize -msse2 while bootstrapping too to make sure that we don't have really any regression due to data reference going wrong (the previous patch I should have done the same too). -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pinskia at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-05-25 02:05:50 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32075
[Bug target/32055] reload failure building libgfortran
--- Comment #1 from dj at redhat dot com 2007-05-25 03:02 --- Indeed the SI is suspicious, since the m32c family doesn't have those types of pointers (it has HI or PSI pointers, but not SI). I've never tried to build FORTRAN for the m32c family though, so if there's a FORTRAN developer out there who could point me at a suitable starting point in the gcc/f95 code... -- dj at redhat dot com changed: What|Removed |Added CC||dj at redhat dot com Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-05-25 03:02:48 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32055
[Bug c++/3187] gcc lays down two copies of constructors
--- Comment #27 from maddox at google dot com 2007-05-25 04:57 --- (In reply to comment #20) Ian proposed handling the simple case in which the two constructors (clones) are identical by emitting the code only once, but labelling it with the symbols for both constructors. This scheme fails in the case that the constructors must go in a comdat group. What do we name the group? If we invent a new name, this will have ABI impact, as other implementations must not step on it. If we use the name of one of the constructors, we may find that the section is discarded in favor of a like-named section produced by another compiler, but which need not define both symbols, resulting in link-incompatibility. It appears, then, that a distinct group name must be used for the combined constructor. As I understand it, this was the principal issue that kept Stuart's patch (referenced in comment #23) from being adopted, so I don't see how this more limited optimization sidesteps the objections to that patch. I spoke with Ian this afternoon, and he agreed with this analysis. It was suggested in the discussion of Stuart's patch that it would be sufficient to provide for a vendor namespace. This seems like a simple, general facility that could be leveraged in multiple contexts, e.g., to support a more general subroutinization optimization. How difficult would it be to get such a provision into the ABI? With a suitably chosen mangling convention, I don't think that name collisions with other ABI-conformant implementations would actually be a problem in practice, so it seems to be more of a matter of agreeing on a convention for the sake of the ABI standard rather than actually managing the transition. Comments? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3187
[Bug fortran/31821] character pointer = target(range) should detect if lengths don't match
--- Comment #3 from pault at gcc dot gnu dot org 2007-05-25 05:38 --- There seems to be a consensus on this - confirmed. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-05-25 05:38:53 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31821
[Bug testsuite/32076] New: gcc.dg/tree-ssa/pr17141-1.c scan-tree-dump locp.*-i = is the same name twice
When looking at fixing one bug and using compare_tests, I noticed that in some
cases the test names can be the same even though it is testing two different
dump files.
gcc.dg/tree-ssa/pr17141-1.c is one example.
It does:
/* { dg-final { scan-tree-dump locp.*-i = forwprop1 { xfail *-*-* } } } */
/* { dg-final { scan-tree-dump locp.*-i = forwprop2 } } */
Though the .log file has:
PASS: gcc.dg/tree-ssa/pr17141-1.c (test for excess errors)
XFAIL: gcc.dg/tree-ssa/pr17141-1.c scan-tree-dump locp.*-i =
PASS: gcc.dg/tree-ssa/pr17141-1.c scan-tree-dump locp.*-i =
That is we don't record the dump file name in the testname which we should.
The problem is in lib/scandump.exp.
--
Summary: gcc.dg/tree-ssa/pr17141-1.c scan-tree-dump locp.*-i =
is the same name twice
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: testsuite
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32076
