[Bug libstdc++/25896] hash_map::erase, unordered_map::erase fail if key is inside the table
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-01-21 07:21 --- "Erases all elements with key equivalent to k. Returns the number of elements erased." and then: size_type erase(const key_type& k); So from that it might not be a bug in libstdc++ as far as I can see. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25896
[Bug libfortran/25697] libfortran - Segmentation fault/ Bad Address on unformatted read
--- Comment #16 from jvdelisle at gcc dot gnu dot org 2006-01-21 07:21 --- Subject: Bug 25697 Author: jvdelisle Date: Sat Jan 21 07:21:11 2006 New Revision: 110062 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110062 Log: 2006-01-20 Jerry DeLisle <[EMAIL PROTECTED]> PR fortran/25697 * gfortran.dg/read_eof.f90: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/read_eof.f90 Modified: branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25697
[Bug libfortran/25697] libfortran - Segmentation fault/ Bad Address on unformatted read
--- Comment #15 from jvdelisle at gcc dot gnu dot org 2006-01-21 07:19 --- Subject: Bug 25697 Author: jvdelisle Date: Sat Jan 21 07:19:39 2006 New Revision: 110061 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110061 Log: 2006-01-20 Jerry DeLisle <[EMAIL PROTECTED]> PR libgfortran/25697 * io/transfer.c (us_read): Detect end of file condition from previous operations and bail out (no need to pre-position). Modified: branches/gcc-4_1-branch/libgfortran/ChangeLog branches/gcc-4_1-branch/libgfortran/io/transfer.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25697
[Bug c/25897] GCC rejects the following strictly conforming code with -ansi -pedantic errors
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-21 07:19 ---
Subject: Re: New: GCC rejects the following strictly conforming code with
-ansi -pedantic errors
>
> void foo (const int (*h)[2], int (*i)[2])
> {
> 1 ? h: i;
> }
>
> Also rejected in C99 mode.
ICC warns:
t.c(3): warning #42: operand types are incompatible ("const int (*)[2]" and
"int (*)[2]")
So maybe this is not valid C, I don't know.
-- Pinski
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25897
Re: [Bug c/25897] New: GCC rejects the following strictly conforming code with -ansi -pedantic errors
>
> void foo (const int (*h)[2], int (*i)[2])
> {
> 1 ? h: i;
> }
>
> Also rejected in C99 mode.
ICC warns:
t.c(3): warning #42: operand types are incompatible ("const int (*)[2]" and
"int (*)[2]")
So maybe this is not valid C, I don't know.
-- Pinski
[Bug c/25897] New: GCC rejects the following strictly conforming code with -ansi -pedantic errors
void foo (const int (*h)[2], int (*i)[2])
{
1 ? h: i;
}
Also rejected in C99 mode.
--
Summary: GCC rejects the following strictly conforming code with
-ansi -pedantic errors
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: neil at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25897
[Bug libstdc++/25896] hash_map::erase, unordered_map::erase fail if key is inside the table
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-01-21 06:59 --- I should note that TR1 says erase does take the key by reference. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25896
[Bug libstdc++/25896] hash_map::erase, unordered_map::erase fail if key is inside the table
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-21 06:47 --- I should note that TR1 is a written document. I am wondering what it says about this case. If it says libstdc++ is right, then maybe you should try to get it fixed (hard because I hear it is close to approval but I could be wrong). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25896
[Bug libstdc++/25896] New: hash_map::erase, unordered_map::erase fail if key is inside the table
This happens with both hash_map and unordered_map and their related classes. I
know that hash_map is not standard, and unordered_map is in TR1 so not
considered standard yet.
Here is a kernel of the problem:
hash_map c;
c.insert(...);
hash_map::iterator it = c.find("...");
c.erase(it->first);
This is deleting by key value, not by iterator.
it->first is a key value which belongs to the collection object.
hash_map::erase(const key&) takes the key by reference. It delegates to its
rep object, which is a hashtable. hashtable::ref looks like this in gcc 4.0.2:
if (__first)
{
...
while (__next)
{
if (_M_equals(_M_get_key(__next->_M_val), __key))
{
...
_M_delete_node(__next);
...
}
...
}
...
}
The actual key object is in a node of the hash table. After deleting that
node, the while() loop keeps using the deleted __key value with every other
node in the same bucket.
The following gcc versions have this problem with the following classes:
gcc 3.4.5
hash_map, hash_multimap, hash_set, hash_multiset
gcc 4.0.2
gcc 4.1-20060106
gcc 4.2-20060114
hash_map, hash_multimap, hash_set, hash_multiset
unordered_map, unordered_multimap, unordered_set, unordered_multiset
You could punt on hash_map and friends because they are non-standard, but it is
nasty to have a case where code compiles and links and runs and then a library
function reads a destroyed object. unordered_map and friends will eventually
(probably) be standardized so they are more serious.
--
Summary: hash_map::erase, unordered_map::erase fail if key is
inside the table
Product: gcc
Version: 4.0.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mec at google 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=25896
[Bug tree-optimization/25857] [4.2 Regression] ICE in coalesce_abnormal_edges at -O2
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-01-21 05:19 --- Mine. -- 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|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25857
[Bug c++/25868] [3.4/4.0/4.1/4.2 Regression] Multiple templates and typedefs cause function prototype not to match
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25868
[Bug rtl-optimization/25890] [4.2 regression] testsuite failure: gcc.c-torture/compile/20051228-1.c
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-21 04:15 --- Confirmed, this also fails on x86_64-linux-gnu which means this is a semi generic problem. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC target triplet|mmix-knuth-mmixware |mmix-knuth-mmixware, x86_64- ||linux-gnu Last reconfirmed|-00-00 00:00:00 |2006-01-21 04:15:30 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25890
[Bug c++/25858] [4.0/4.1/4.2 regression] ICE on forgotten ":" in definition of derived class
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25858
[Bug c++/25856] [4.0/4.1/4.2 regression] ICE defining destructor for incomplete class
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25856
[Bug bootstrap/23801] GCC_VERSION tests in ansidecl.h result in integer overflow
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-01-21 03:11 --- No feedback in 3 months. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23801
[Bug tree-optimization/21417] Missed jump threading opportunity on trees
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-01-21 03:03 --- Oh, we still not load PRE this one because we don't handle (*a).b yet. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Last reconfirmed|2005-10-24 00:23:37 |2006-01-21 03:03:17 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21417
[Bug bootstrap/23927] --enable-intermodule is broken on targets with mutlilibs even with --disable-multilib
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-01-21 02:54 --- This is fixed with the toplevel bootstrap but I am waiting for the regressions associated with the toplevel bootstrap to close this bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23927
[Bug c++/25895] [4.0/4.1/4.2 Regression] wrong code with ?: and derived class pointers
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.0.4 |4.0.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25895
[Bug c++/25894] [3.4/4.0/4.1/4.2 Regression] conditional operator operating on derived / base pointers appears incorrect
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-01-21 02:35 --- (In reply to comment #1) > I am starting to think the wrong code is a different regression than the > rejects valid. I filed that as PR 25895. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||25895 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25894
[Bug c++/25895] [4.0/4.1/4.2 Regression] wrong code with ?: and derived class pointers
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.0.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25895
[Bug c++/25895] New: [4.0/4.1/4.2 Regression] wrong code with ?: and derived class pointers
Testcase:
#include
class base {
public:
base() {}
private:
int val_;
};
class derived : public base {
public:
derived() {}
};
bool x = true ? (derived*)0 : (base*)0;
int main ()
{
if (x)
abort();
}
--
Summary: [4.0/4.1/4.2 Regression] wrong code with ?: and derived
class pointers
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: c++
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=25895
[Bug c++/25894] [3.4/4.0/4.1/4.2 Regression] conditional operator operating on derived / base pointers appears incorrect
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-21 02:32 ---
3.3.3 both accepted the code and did not produce the wrong code.
3.4.0 did produce the correct code but rejected the example in comment #0.
The following code is for the wrong code regression which is produceable in
4.0.0 and above:
#include
class base {
public:
base() {}
private:
int val_;
};
class derived : public base {
public:
derived() {}
};
bool x = true ? (derived*)0 : (base*)0;
int main ()
{
if (x)
abort();
}
I am starting to think the wrong code is a different regression than the
rejects valid.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||wrong-code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25894
[Bug c++/25894] [3.4/4.0/4.1/4.2 Regression] conditional operator operating on derived / base pointers appears incorrect
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org, mmitchel at gcc dot gnu ||dot org Keywords||rejects-valid Known to fail||3.4.0 4.0.0 4.1.0 4.2.0 Known to work||3.3.3 Summary|conditional operator|[3.4/4.0/4.1/4.2 Regression] |operating on derived / base |conditional operator |pointers appears incorrect |operating on derived / base ||pointers appears incorrect Target Milestone|--- |4.0.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25894
[Bug target/23602] [4.1 regression] 1081 test failures in libjava, when configured for i486-linux
--- Comment #16 from aoliva at gcc dot gnu dot org 2006-01-21 02:11 --- Created an attachment (id=10694) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10694&action=view) Reduced testcase This reduced testcase triggers the same bug before Richard's patch if compiled with -fasynchronous-unwind-tables, generating very similar code to what broke the unwinder in the libjava.lang ArrayTest on i486. With current trunk, even after reverting the patch, both the reduced testcase and the Java tests all pass on an i486-pc-linux-gnu native toolchain. Even though the generated code is not significantly different, the EH tables are. I can't tell immediately whether the problem is actually fixed, and we could thus remove the patch that hid the problem before, or if it's just more difficult to trigger now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23602
[Bug c++/25894] New: conditional operator operating on derived / base pointers appears incorrect
Consider this program:
class base {
public:
base() {}
private:
int val_;
};
class derived : public base {
public:
derived() {}
};
template struct static_assert;
template <> struct static_assert {};
int main ()
{
static const bool x = true ? (derived*)0 : (base*)0;
static_assert test;
}
I'm expecting it to compile (EDG compiles it). The current error I get is:
error: 'x' cannot appear in a constant-expression
If I allow run time evaluation of x, and print it out, I get 1 instead of 0 as
I expect.
--
Summary: conditional operator operating on derived / base
pointers appears incorrect
Product: gcc
Version: 4.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hhinnant at apple dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25894
[Bug target/25893] cris-linux: various libgomp tests fail
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-01-21 02:05:25 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25893
[Bug target/25893] New: cris-linux: various libgomp tests fail
Some of the new libgomp tests fail initially for this target when tested with a simulator, for various reasons. This PR tracks them. Running /home/hp/combined/combined/libgomp/testsuite/libgomp.c/c.exp ... FAIL: libgomp.c/appendix-a/a.15.1.c execution test WARNING: program timed out. FAIL: libgomp.c/appendix-a/a.18.1.c execution test WARNING: program timed out. FAIL: libgomp.c/appendix-a/a.2.1.c execution test WARNING: program timed out. FAIL: libgomp.c/appendix-a/a.39.1.c execution test FAIL: libgomp.c/barrier-1.c execution test WARNING: libgomp.c/critical-1.c compilation failed to produce executable WARNING: libgomp.c/lib-1.c compilation failed to produce executable WARNING: libgomp.c/loop-1.c compilation failed to produce executable FAIL: libgomp.c/loop-2.c (test for excess errors) WARNING: libgomp.c/loop-2.c compilation failed to produce executable FAIL: libgomp.c/omp-loop03.c execution test FAIL: libgomp.c/omp_hello.c execution test FAIL: libgomp.c/omp_orphan.c execution test FAIL: libgomp.c/omp_workshare1.c execution test FAIL: libgomp.c/omp_workshare2.c execution test FAIL: libgomp.c/omp_workshare4.c execution test WARNING: libgomp.c/ordered-1.c compilation failed to produce executable WARNING: libgomp.c/ordered-2.c compilation failed to produce executable WARNING: libgomp.c/sections-1.c compilation failed to produce executable WARNING: libgomp.c/single-1.c compilation failed to produce executable Some tests fail due to an invalid access: libgomp.c/appendix-a/a.15.1.c libgomp.c/omp_hello.c libgomp.c/omp_orphan.c libgomp.c/omp_workshare1.c libgomp.c/omp_workshare2.c libgomp.c/omp_workshare4.c where the .log entry looks like this: core: 1 byte write to unmapped address 0x3d80 at 0xa797e^M program stopped with signal 11.^M FAIL: libgomp.c/appendix-a/a.15.1.c execution test Some tests just time out. This may or may not be due to incorrect or limited thread support (yes, there is *some* support) in the simulator. libgomp.c/appendix-a/a.18.1.c libgomp.c/appendix-a/a.2.1.c libgomp.c/appendix-a/a.39.1.c One test fails due to an unimplemented syscall in the simulator: libgomp.c/barrier-1.c The .log: Unimplemented syscall: 162 (0x3dfffdb4, 0x0, 0xddd84, 0xf4240, 0x0, 0x98d52)^M program stopped with signal 4.^M FAIL: libgomp.c/barrier-1.c execution test Some test fail due to a missing sync library function or missing open-code implementation of __sync_lock_test_and_set_4: libgomp.c/loop-1.c libgomp.c/loop-2.c libgomp.c/ordered-1.c libgomp.c/ordered-2.c libgomp.c/sections-1.c libgomp.c/single-1.c libgomp.c/critical-1.c Curiously enough *some* of these pass the "excess errors" test. The .log entry looks like this: /tmp/ccMhq34N.o: In function `function':critical-1.c:(.text+0x20): undefined reference to `__sync_lock_test_and_set_4'^M collect2: ld returned 1 exit status^M compiler exited with status 1 One fail for some other reason, possibly simulator-thread-implementation-related: PASS: libgomp.c/omp-loop03.c (test for excess errors) ^M libgomp: Thread creation failed: Resource temporarily unavailable^M Thread 105 exited with status 1^M program stopped with signal 4.^M FAIL: libgomp.c/omp-loop03.c execution test I assign this PR to myself so nobody is tempted to act on it. -- Summary: cris-linux: various libgomp tests fail Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: hp at gcc dot gnu dot org ReportedBy: hp at gcc dot gnu dot org GCC host triplet: i686-pc-linux-gnu GCC target triplet: cris-axis-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25893
[Bug tree-optimization/25857] [4.2 Regression] ICE in coalesce_abnormal_edges at -O2
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-01-21 02:00 --- I have an even simplier patch which I got from Daniel Berlin instead of "in_ab = true;" just doing a return will fix this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25857
[Bug tree-optimization/25857] [4.2 Regression] ICE in coalesce_abnormal_edges at -O2
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-01-21 01:48 ---
Patch which I am going to test:
Index: tree-ssa-pre.c
===
--- tree-ssa-pre.c (revision 110030)
+++ tree-ssa-pre.c (working copy)
@@ -2741,10 +2741,13 @@ insert_extra_phis (basic_block block, ba
edge e;
edge_iterator ei;
bool first = true;
+ bool in_ab = false;
bitmap_set_t tempset = bitmap_set_new ();
FOR_EACH_EDGE (e, ei, block->preds)
{
+ if ((e->flags & EDGE_ABNORMAL) != 0)
+ in_ab = true;
if (first)
{
bitmap_set_copy (tempset, AVAIL_OUT (e->src));
@@ -2768,7 +2771,7 @@ insert_extra_phis (basic_block block, ba
tree val = get_value_handle (name);
tree temp;
- if (SSA_NAME_OCCURS_IN_ABNORMAL_PHI (name))
+ if (in_ab)
continue;
if (!mergephitemp
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25857
[Bug c/25892] -Wpointer-sign creates problems for Emacs
-- jbuck at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-01-21 01:43:36 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25892
[Bug c/25892] -Wpointer-sign creates problems for Emacs
-- jbuck at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25892
[Bug c/25892] -Wpointer-sign creates problems for Emacs
--- Comment #1 from jbuck at gcc dot gnu dot org 2006-01-21 01:41 --- Created an attachment (id=10693) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10693&action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25892
[Bug c/25892] New: -Wpointer-sign creates problems for Emacs
The original report from RMS stated: "GCC 4 when compiling Emacs gives annoying warnings about mismatched signs of pointer target types. To turn this off is not trivial, since the -Wno-pointer-sign option itself causes a diagnostic from older GCC versions. It makes compilation fail." Evidently changing Emacs is not an acceptable option. After discussion with the SC and the original contributor of the -Wpointer-sign patch, the SC agreed that the best solution would be for -Wpointer-sign not to be enabled by default, but only if -Wall or --pedantic is present. Since the SC promised this fix to RMS, it needs to be considered a release blocker for 4.1. (I don't know about 4.0.3, probably best to do it there too). -- Summary: -Wpointer-sign creates problems for Emacs Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jbuck at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25892
[Bug c++/25855] template specialisation not always found (partial ordering)
--- Comment #12 from janis at gcc dot gnu dot org 2006-01-21 01:24 --- A regression hunt of the trunk on powerpc-linux using the testcase in comment #4 (modified to abort if the result is not 4) identified the following patch to fix several C++ bugs: http://gcc.gnu.org/viewcvs?view=rev&rev=105365 r105365 | mmitchel | 2005-10-13 08:38:40 + (Thu, 13 Oct 2005) The same fixes were added to the 4.0-branch, again as a single patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25855
[Bug tree-optimization/25315] [4.2 regression] testsuite failure:27_io/basic_ostream/inserters_character/char/9555-oc.cc wchar_t/9555-oc.cc exec
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25315
[Bug testsuite/25891] New: gomp tests run on non-libgomp (non-thread) ports, failing all
Errors in the log look like (for mmix-knuth-mmixware): Running /home/hp/combined/combined/gcc/testsuite/gcc.dg/gomp/gomp.exp ... Executing on host: /home/hp/combined/mmixware-sim/gcc/xgcc -B/home/hp/combined/mmixware-sim/gcc/ /home/hp/combined/combined/gcc/t\ estsuite/gcc.dg/gomp/appendix-a/a.1.1.c -fopenmp -fno-show-column -S -isystem /home/hp/combined/mmixware-sim/mmix-knuth-mmixwa\ re/./newlib/targ-include -isystem /home/hp/combined/combined/newlib/libc/include -o a.1.1.s(timeout = 300) xgcc: unrecognized option '-pthread'^M There was some IRC discussion which misattributed the errors to libgomp wrongly being built, but libgomp isn't built for targets where this was noticed: mmix-knuth-mmixware, cris-axis-elf. A simple gating test in gomp.exp, testing error-free compilation of trivial code with -fopenmp should do it. -- Summary: gomp tests run on non-libgomp (non-thread) ports, failing all Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hp at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25891
[Bug rtl-optimization/25890] [4.2 regression] testsuite failure: gcc.c-torture/compile/20051228-1.c
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Component|middle-end |rtl-optimization Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25890
[Bug middle-end/25890] New: [4.2 regression] testsuite failure: gcc.c-torture/compile/20051228-1.c
Last known to work with: "Tue Jan 17 02:44:03 UTC 2006 (revision 109801M)". Known to fail with: "Fri Jan 20 05:17:46 UTC 2006 (revision 110008M)". Running /home/hp/combined/combined/gcc/testsuite/gcc.c-torture/compile/compile.exp ... FAIL: gcc.c-torture/compile/20051228-1.c -O1 (test for excess errors) FAIL: gcc.c-torture/compile/20051228-1.c -O2 (test for excess errors) FAIL: gcc.c-torture/compile/20051228-1.c -O3 -fomit-frame-pointer (test for excess errors) FAIL: gcc.c-torture/compile/20051228-1.c -O3 -g (test for excess errors) FAIL: gcc.c-torture/compile/20051228-1.c -Os (test for excess errors) With the message in the .log being for all: x/combined/gcc/testsuite/gcc.c-torture/compile/20051228-1.c: In function 'foo':^M x/combined/gcc/testsuite/gcc.c-torture/compile/20051228-1.c:10: internal compiler error: in expand_compound_opera\ tion, at combine.c:5644^M -- Summary: [4.2 regression] testsuite failure: gcc.c- torture/compile/20051228-1.c Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hp at gcc dot gnu dot org GCC host triplet: i686-pc-linux-gnu GCC target triplet: mmix-knuth-mmixware http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25890
[Bug tree-optimization/25315] [4.2 regression] testsuite failure:27_io/basic_ostream/inserters_character/char/9555-oc.cc wchar_t/9555-oc.cc exec
--- Comment #6 from amodra at bigpond dot net dot au 2006-01-21 00:31 --- Fails powerpc64-linux, where I was poking at this bug. -- amodra at bigpond dot net dot au changed: What|Removed |Added CC||amodra at bigpond dot net ||dot au Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-01-21 00:31:12 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25315
[Bug tree-optimization/25315] [4.2 regression] testsuite failure:27_io/basic_ostream/inserters_character/char/9555-oc.cc wchar_t/9555-oc.cc exec
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-01-21 00:27 --- This also fails on powerpc-darwin. >From Alan M.: [19:14] < alanm> bje, use of an uninitialised pseudo in catch blocks [19:14] < pinskia> alanm: I had that problem before (int a = a; was my issue) [19:15] < alanm> i see the following in 00.expand [19:15] < alanm> (insn 154 153 155 17 (set (reg:DI 150 [ D.31560 ]) [19:15] < alanm> (plus:DI (reg:DI 129 [ mergephitmp.3472 ]) [19:15] < alanm> (reg:DI 201))) -1 (nil) [19:15] < alanm> (nil)) [19:16] < alanm> reg 129 isn't set anywhere. [19:16] < pinskia> hmm, you must be using 4.2 because mergephitmp IIRC is not in 4.1 [19:16] < alanm> must be a tree problem somewhere, but i'm not familiar with reading tree dumps [19:16] < alanm> yes [19:16] < alanm> this is mainline [19:17] < pinskia> alanm: tree dumps is like reading C except for some cases like eh [19:17] * bje ([EMAIL PROTECTED]) has quit IRC (Quit: big blue room) [19:17] < pinskia> alanm: do you have a simple example where this is a problem, I can look at it [19:18] < pinskia> alanm: this is only at -O2 or also at -O1? [19:19] < alanm> no, i haven't simplified. the failing function was ostream-inst.cc:_ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_c [19:20] < pinskia> ok, I will try to take a look later [19:21] < alanm> a quick look at generated code at -O1 says it is OK. so bug is at -O2 before rtl generation [19:22] < pinskia> I want to say it is related to PRE only because of it is mergephitmp there (but don't quote me on that because DannyB will get on my back) [19:26] < pinskia> alanm: is this from the test 9555-oc.cc? [19:26] < alanm> yes, it causes that failure Looking more into, once my build gets to building libstdc++. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Component|middle-end |tree-optimization GCC host triplet|i686-pc-linux-gnu, x86_64- | |unknown-linux-gnu | GCC target triplet|cris-axis-linux-gnu | Keywords||EH http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25315
[Bug tree-optimization/23855] loop header should also be pulled out of the inner loop too
--- Comment #9 from rakdver at gcc dot gnu dot org 2006-01-20 23:56 --- Patch: http://gcc.gnu.org/ml/gcc-patches/2006-01/msg01424.html -- rakdver at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2006- ||01/msg01424.html Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23855
[Bug target/25758] gcc.c-torture/compile/20030921-1.c fails at -O0
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-01-20 23:49 --- I am testing the patch that RTH suggested on x86_64-linux-gnu to make sure that it works there. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25758
[Bug target/25668] libgcc2.c __floattisf code quality regression
--- Comment #1 from amodra at bigpond dot net dot au 2006-01-20 22:51 --- Author: amodra Date: Fri Jan 20 00:42:29 2006 New Revision: 110004 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110004 Log: * libgcc2.c (__floatdisf, __floatdidf): Don't use IBM Extended Double TFmode. (__floatundisf, __floatundidf): Likewise. * libgcc2.h (IS_IBM_EXTENDED): Define. Modified: trunk/gcc/ChangeLog trunk/gcc/libgcc2.c trunk/gcc/libgcc2.h -- amodra at bigpond dot net dot au changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25668
[Bug rtl-optimization/25654] [4.0/4.1/4.2 Regression] RTL alias analysis unprepared to handle stack slot sharing
--- Comment #13 from mmitchel at gcc dot gnu dot org 2006-01-20 22:37 --- RTH's comments are here: http://gcc.gnu.org/ml/gcc-patches/2006-01/msg01390.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25654
[Bug fortran/25092] Result lengths different at different entries
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-20 21:51 --- Confirmed, related to PR 25091. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||25091 Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||accepts-invalid Last reconfirmed|-00-00 00:00:00 |2006-01-20 21:51:58 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25092
[Bug fortran/25091] Results do not conform at different entries
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-20 21:51 --- Confirmed, this is obviously wrong as there is no way for different entries to have different return types. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||accepts-invalid Last reconfirmed|-00-00 00:00:00 |2006-01-20 21:51:14 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25091
[Bug bootstrap/25888] make[2]: *** No rule to make target `../../gcc/gcc/gthr-gnat.c'
--- Comment #1 from danglin at gcc dot gnu dot org 2006-01-20 21:44 --- I accidently deleted the file. -- danglin at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25888
[Bug bootstrap/25888] New: make[2]: *** No rule to make target `../../gcc/gcc/gthr-gnat.c'
mkinstalldirs='/usr/local/bin/bash ../../gcc/gcc/../mkinstalldirs' \ /usr/local/bin/bash mklibgcc > tmp-libgcc.mk mv tmp-libgcc.mk libgcc.mk TARGET_CPU_DEFAULT="" \ HEADERS="auto-host.h ansidecl.h" DEFINES="USED_FOR_TARGET USE_COLLECT2" \ /usr/local/bin/bash ../../gcc/gcc/mkconfig.sh tconfig.h make[2]: *** No rule to make target `../../gcc/gcc/gthr-gnat.c', needed by `stmp-multilib'. Stop. make[2]: Leaving directory `/users/bin/gcc/gcc-4.1/objdir/gcc' make[1]: *** [stage1_build] Error 2 make[1]: Leaving directory `/users/bin/gcc/gcc-4.1/objdir/gcc' make: *** [bootstrap] Error 2 Fri Jan 20 15:52:00 EST 2006 -- Summary: make[2]: *** No rule to make target `../../gcc/gcc/gthr- gnat.c' Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org GCC build triplet: hppa1.1-hp-hp10.20 GCC host triplet: hppa1.1-hp-hp10.20 GCC target triplet: hppa1.1-hp-hp10.20 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25888
[Bug libstdc++/25524] libstdc++ headers should go in multilib directories
--- Comment #9 from jsm28 at gcc dot gnu dot org 2006-01-20 21:00 --- Subject: Bug 25524 Author: jsm28 Date: Fri Jan 20 21:00:52 2006 New Revision: 110038 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110038 Log: PR libstdc++/25524 * gcc/cppdefault.h (struct default_include): Add multilib flag. * gcc/cppdefault.c (cpp_include_defaults): Set it. * gcc/c.opt (-imultilib): New option. * gcc/c-opts.c (imultilib): New. (c_common_handle_option): Handle -imultilib. (c_common_post_options): Likewise. * gcc/c-incpath.c (add_standard_paths, register_include_chains): Likewise. * gcc/c-incpath.h (register_include_chains): Add extra parameter. * gcc/gcc.c (do_spec_1): Generate -imultilib option. (The Specs Language): Update %I description. (process_command): Update copyright notice. * gcc/doc/cppopts.texi (-imultilib): Document. * gcc/doc/invoke.texi (-imultilib): Include in option summary. (%I): Update specs documentation. * libstdc++-v3/include/Makefile.am: Install host-specific headers in multilib subdirectory. * libstdc++-v3/include/Makefile.in: Regenerate. Modified: branches/csl/sourcerygxx-4_1/ChangeLog.csl branches/csl/sourcerygxx-4_1/gcc/c-incpath.c branches/csl/sourcerygxx-4_1/gcc/c-incpath.h branches/csl/sourcerygxx-4_1/gcc/c-opts.c branches/csl/sourcerygxx-4_1/gcc/c.opt branches/csl/sourcerygxx-4_1/gcc/cppdefault.c branches/csl/sourcerygxx-4_1/gcc/cppdefault.h branches/csl/sourcerygxx-4_1/gcc/doc/cppopts.texi branches/csl/sourcerygxx-4_1/gcc/doc/invoke.texi branches/csl/sourcerygxx-4_1/gcc/gcc.c branches/csl/sourcerygxx-4_1/libstdc++-v3/include/Makefile.am branches/csl/sourcerygxx-4_1/libstdc++-v3/include/Makefile.in -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25524
[Bug libstdc++/25524] libstdc++ headers should go in multilib directories
--- Comment #8 from jsm28 at gcc dot gnu dot org 2006-01-20 21:00 --- Subject: Bug 25524 Author: jsm28 Date: Fri Jan 20 21:00:03 2006 New Revision: 110037 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110037 Log: PR libstdc++/25524 * cppdefault.h (struct default_include): Add multilib flag. * cppdefault.c (cpp_include_defaults): Set it. * c.opt (-imultilib): New option. * c-opts.c (imultilib): New. (c_common_handle_option): Handle -imultilib. (c_common_post_options): Likewise. * c-incpath.c (add_standard_paths, register_include_chains): Likewise. * c-incpath.h (register_include_chains): Add extra parameter. * gcc.c (do_spec_1): Generate -imultilib option. (The Specs Language): Update %I description. (process_command): Update copyright notice. * doc/cppopts.texi (-imultilib): Document. * doc/invoke.texi (-imultilib): Include in option summary. (%I): Update specs documentation. libstdc++-v3: * include/Makefile.am: Install host-specific headers in multilib subdirectory. * include/Makefile.in: Regenerate. Modified: trunk/gcc/ChangeLog trunk/gcc/c-incpath.c trunk/gcc/c-incpath.h trunk/gcc/c-opts.c trunk/gcc/c.opt trunk/gcc/cppdefault.c trunk/gcc/cppdefault.h trunk/gcc/doc/cppopts.texi trunk/gcc/doc/invoke.texi trunk/gcc/gcc.c trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/Makefile.am trunk/libstdc++-v3/include/Makefile.in -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25524
[Bug fortran/24875] [gfortran, 4.1.0 regression] Arithmetic overflow during compilation
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-01-20 20:56 --- I am going to declare this is GMP bug as I can reproduce it on two out of three of my machines. The one with the newest GMP, it works. These three machines are all different targets, powerpc, x86 and x86-64. So closing as worksforme. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24875
[Bug middle-end/23477] [4.1 Regression] default-initializing array new expression uses makes stack usage go way up
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-01-20 20:51 --- *** Bug 23631 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23477
[Bug middle-end/23631] construct to memory and memcpy instead of memset
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-01-20 20:51 --- PR 23477 was fixed in 4.1.0 and not 4.0.3. This is still a dup of that bug. *** This bug has been marked as a duplicate of 23477 *** -- 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=23631
[Bug middle-end/25869] [4.2 regression] MMIX broken: ICE compiling __divti3
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-01-20 20:46 --- Worked around so closing as fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25869
[Bug middle-end/25869] [4.2 regression] MMIX broken: ICE compiling __divti3
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-01-20 20:45 --- *** Bug 25887 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25869
[Bug bootstrap/25887] segfault on mingw32
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-20 20:45 --- *** This bug has been marked as a duplicate of 25869 *** -- 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=25887
[Bug bootstrap/25887] New: segfault on mingw32
I can't get GCC trunk to compile on mingw32. The build dies with the following segfault: /home/coudert/ibin/./gcc/xgcc -B/home/coudert/ibin/./gcc/ -B/mingw/i686-pc-mingw32/bin/ -B/mingw/i686-pc-mingw32/lib/ -isystem /mingw/i686-pc-mingw32/include -isystem /mingw/i686-pc-mingw32/sys-include -O2 -I../../gcc/gcc/../winsup/w32api/include -O2 -g -O2 -DIN_GCC-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I. -I../../gcc/gcc -I../../gcc/gcc/. -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include -I/home/coudert/local/include -I../../gcc/gcc/../libdecnumber -I../libdecnumber -DL__main -c ../../gcc/gcc/libgcc2.c -o libgcc/./__main.o ../../gcc/gcc/libgcc2.c: In function '__do_global_ctors': ../../gcc/gcc/libgcc2.c:2109: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. make[4]: *** [libgcc/./__main.o] Error 1 make[4]: Leaving directory `/home/coudert/ibin/gcc' make[3]: *** [libgcc.a] Error 2 make[3]: Leaving directory `/home/coudert/ibin/gcc' make[2]: *** [all-stage1-gcc] Error 2 make[2]: Leaving directory `/home/coudert/ibin' make[1]: *** [stage1-bubble] Error 2 make[1]: Leaving directory `/home/coudert/ibin' make: *** [all] Error 2 The gdb backtrace of the segfault is Program received signal SIGSEGV, Segmentation fault. 0x00a7068f in df_chain_unlink (dflow=0x1857c38, ref=0x184d4d8, link=0x184e1f8) at ../../gcc/gcc/df-problems.c:110 110 chain = chain->next; (gdb) where #0 0x00a7068f in df_chain_unlink (dflow=0x1857c38, ref=0x184d4d8, link=0x184e1f8) at ../../gcc/gcc/df-problems.c:110 #1 0x00a706d8 in df_chain_unlink (dflow=0x1857c38, ref=0x184d418, link=0x0) at ../../gcc/gcc/df-problems.c:125 #2 0x00ab9cd4 in df_reg_chain_unlink (dflow=0x189d700, ref=0x184d418) at ../../gcc/gcc/df-scan.c:635 #3 0x00ab9fdd in df_insn_refs_delete (dflow=0x189d700, insn=0x18c5348) at ../../gcc/gcc/df-scan.c:743 #4 0x00aba0b7 in df_bb_refs_delete (dflow=0x189d700, bb_index=5) at ../../gcc/gcc/df-scan.c:768 #5 0x00ab903b in df_scan_free_bb_info (dflow=0x189d700, bb=0x18ab7d0, vbb_info=0x164fae0) at ../../gcc/gcc/df-scan.c:189 #6 0x00a6e3f9 in df_set_blocks (df=0x176a118, blocks=0x164f83c) at ../../gcc/gcc/df-core.c:373 During symbol reading, struct/union type gets multiply defined: union tree_node. During symbol reading, struct/union type gets multiply defined: struct basic_block_def. During symbol reading, struct/union type gets multiply defined: union tree_node. During symbol reading, struct/union type gets multiply defined: union tree_node. During symbol reading, struct/union type gets multiply defined: struct rtx_def. #7 0x008991d6 in iv_analysis_loop_init (loop=) at ../../gcc/gcc/loop-iv.c:267 #8 0x0087e321 in predict_loops (loops_info=0x22fd40, rtlsimpleloops=1 '\001') at ../../gcc/gcc/predict.c:618 #9 0x0087ebb6 in estimate_probability (loops_info=0x22fd40) at ../../gcc/gcc/predict.c:842 #10 0x007b1f12 in rest_of_handle_branch_prob () at ../../gcc/gcc/profile.c:1363 #11 0x006d4e23 in execute_one_pass (pass=0xafc6b0) at ../../gcc/gcc/passes.c:849 #12 0x006d4ede in execute_pass_list (pass=0xafc6b0) at ../../gcc/gcc/passes.c:881 #13 0x006d4ef9 in execute_pass_list (pass=0xafb370) at ../../gcc/gcc/passes.c:882 #14 0x006d27ce in tree_rest_of_compilation (fndecl=0x1897a00) at ../../gcc/gcc/tree-optimize.c:412 #15 0x0041f8fd in c_expand_body (fndecl=0x1897a00) at ../../gcc/gcc/c-decl.c:6689 #16 0x006cb06c in cgraph_expand_function (node=0x1897c80) at ../../gcc/gcc/cgraphunit.c:1098 #17 0x006cb2ef in cgraph_expand_all_functions () at ../../gcc/gcc/cgraphunit.c:1164 #18 0x006cbd27 in cgraph_optimize () at ../../gcc/gcc/cgraphunit.c:1431 #19 0x00422621 in c_write_global_declarations () at ../../gcc/gcc/c-decl.c:7804 #20 0x0065b9cb in compile_file () at ../../gcc/gcc/toplev.c:1003 #21 0x0065d125 in do_compile () at ../../gcc/gcc/toplev.c:1948 #22 0x0065d188 in toplev_main (argc=49, argv=0x3d48c0) at ../../gcc/gcc/toplev.c:1980 #23 0x004a53ec in main (argc=49, argv=0x3d48c0) at ../../gcc/gcc/main.c:35 -- Summary: segfault on mingw32 Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: build Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: fxcoudert at gcc dot gnu dot org GCC build triplet: i686-pc-mingw32 GCC host triplet: i686-pc-mingw32 GCC target triplet: i686-pc-mingw32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25887
[Bug tree-optimization/25881] unsigned int loop indices don't optimize as good as int or __SIZE_TYPE__ for 64bit targets
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-20 20:43 ---
Confirmed, I thought I had saw another bug about this but no luck, anyways
confirmed.
Hmm, using unsigned short on 32bit targets cause the same issue:
void vector_add(unsigned short n,
double * __restrict__ r,
double * __restrict__ a,
double * __restrict__ b) {
unsigned short i;
for(i=0; ihttp://gcc.gnu.org/bugzilla/show_bug.cgi?id=25881
[Bug fortran/25716] FAIL: gfortran.dg/char_result_11.f90 -O (test for excess errors)
--- Comment #16 from pinskia at gcc dot gnu dot org 2006-01-20 20:37 --- (In reply to comment #15) > Any chance of getting the fix into 4.1? Yes if someone approves the patch. Which was posted: http://gcc.gnu.org/ml/gcc-patches/2006-01/msg00785.html I don't know enough of this code to approve it though. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |eedelman at gcc dot gnu dot |dot org |org URL||http://gcc.gnu.org/ml/gcc- ||patches/2006- ||01/msg00785.html Status|NEW |ASSIGNED Keywords||ice-on-valid-code, patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25716
[Bug ada/25885] [4.0/4.1/4.2 Regression] Tree checking failure on ASIS
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Target Milestone|--- |4.0.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25885
[Bug ada/25885] [4.0/4.1/4.2 Regression] Tree checking failure on ASIS
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2006-01-20 20:14 --- > Confirmed on 4.0.2, also present in 4.1 and 4.2 > > $ gcc -c -O2 gnatpp-comments.adb > +===GNAT BUG DETECTED==+ > | 4.1.0 20060112 (prerelease) (x86_64-unknown-linux-gnu) GCC error:| > | tree check: expected integer_cst, have nop_expr in int_const_binop, | > |at fold-const.c:1330 | > | Error detected at gnatpp-comments.adb:944:17 | > > $ gcc -c -O2 gnatpp-comments.adb > +===GNAT BUG DETECTED==+ > | 4.2.0 20060115 (experimental) (x86_64-unknown-linux-gnu) GCC error: | > | tree check: expected integer_cst, have nop_expr in int_const_binop, | > |at fold-const.c:1369 | > | Error detected at gnatpp-comments.adb:944:17 | Yes, an annoying problem, regression from 3.x. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ebotcazou at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED GCC build triplet|x86_64-suse-linux-gnu |*-*-* GCC host triplet|x86_64-suse-linux-gnu |*-*-* GCC target triplet|x86_64-suse-linux-gnu |*-*-* Last reconfirmed|2006-01-20 20:01:27 |2006-01-20 20:14:09 date|| Summary|Ada ICE have nop_expr in|[4.0/4.1/4.2 Regression] |int_const_binop on x86_64- |Tree checking failure on |linux |ASIS http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25885
[Bug ada/25885] Ada ICE have nop_expr in int_const_binop on x86_64-linux
--- Comment #3 from laurent at guerby dot net 2006-01-20 20:01 --- Note this works on i686 with 4.0.2. Confirmed on 4.0.2, also present in 4.1 and 4.2 $ gcc -c -O2 gnatpp-comments.adb +===GNAT BUG DETECTED==+ | 4.1.0 20060112 (prerelease) (x86_64-unknown-linux-gnu) GCC error:| | tree check: expected integer_cst, have nop_expr in int_const_binop, | |at fold-const.c:1330 | | Error detected at gnatpp-comments.adb:944:17 | $ gcc -c -O2 gnatpp-comments.adb +===GNAT BUG DETECTED==+ | 4.2.0 20060115 (experimental) (x86_64-unknown-linux-gnu) GCC error: | | tree check: expected integer_cst, have nop_expr in int_const_binop, | |at fold-const.c:1369 | | Error detected at gnatpp-comments.adb:944:17 | -- laurent at guerby dot net changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||ice-on-valid-code Last reconfirmed|-00-00 00:00:00 |2006-01-20 20:01:27 date|| Summary|gnatpp won't compile|Ada ICE have nop_expr in ||int_const_binop on x86_64- ||linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25885
[Bug libgomp/25259] [4.2 Regression] bootstrap failures on non-C99 platforms
-- bonzini at gnu dot org changed: What|Removed |Added AssignedTo|bonzini at gnu dot org |unassigned at gcc dot gnu ||dot org Status|REOPENED|NEW Component|bootstrap |libgomp http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25259
[Bug bootstrap/25259] [4.2 Regression] bootstrap failures on non-C99 platforms
--- Comment #15 from bonzini at gnu dot org 2006-01-20 19:58 --- libgomp should use GCC_HEADER_STDINT too. See the patch for PR25884 which does so. -- bonzini at gnu dot org changed: What|Removed |Added BugsThisDependsOn||25884 Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25259
[Bug libgomp/25884] libgomp should not require perl to compile
--- Comment #1 from bonzini at gnu dot org 2006-01-20 19:56 --- Created an attachment (id=10692) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10692&action=view) prototype patch This is a prototype patch to fix the bug using autoconf to compute the necessary sizes/alignments Note that I'm *not* going to test and submit this patch any further. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25884
[Bug middle-end/25886] [4.2 Regression] up to 256 tree codes for Objective-C++
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-20 19:26 --- Caused by: 2006-01-19 Diego Novillo <[EMAIL PROTECTED]> * tree.def (BLOCK): Remove documentation about BLOCK_TYPE_TAGS. (OMP_PARALLEL): Add 3 operands. (OMP_SECTIONS): Add 1 operand. (OMP_RETURN_EXPR): Define. That last define caused this regression. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||dnovillo at gcc dot gnu dot ||org Keywords||build Summary|almost to 256 tree codes for|[4.2 Regression] up to 256 |Objective-C++ |tree codes for Objective-C++ Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25886
[Bug c++/25874] [gomp branch] ICE in calc_dfs_tree()
--- Comment #2 from martin at mpa-garching dot mpg dot de 2006-01-20 19:17
---
Reduced testcase:
int foo();
struct wigner_d
{
void recurse () {
int dd;
for (int j=0; j<=1; ++j) {
#pragma omp parallel
dd=5;
}
}
};
template void rotate_alm(T arg)
{
wigner_d rec;
rec.recurse();
#pragma omp parallel
foo();
}
template void rotate_alm(float arg);
template void rotate_alm(double arg);
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25874
[Bug middle-end/25886] New: almost to 256 tree codes for Objective-C++
Objective-C++ uses 256 tree codes and yes it uses all of them. So Objective-C++ fails. -- Summary: almost to 256 tree codes for Objective-C++ Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end 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=25886
[Bug ada/25885] gnatpp won't compile
--- Comment #2 from krischik at users dot sourceforge dot net 2006-01-20 19:07 --- Almost forgot, you want a gcc -v >gcc -v Es werden eingebaute Spezifikationen verwendet. Ziel: x86_64-suse-linux Konfiguriert mit: ../gcc-4.0.2/configure --with-gcc --with-gnu-ld --with-gnu-as --enable-alloca=yes --enable-mpfr --enable-libada --enable-libgcj --enable-multilib --enable-java-gc=boehm --enable-c99 --enable-threads=yes --enable-interpreter --enable-hash-synchronization --enable-shared --prefix=/opt/gnat/gcc --enable-languages=c,ada,c++,f95,java,objc x86_64-suse-linux Thread-Modell: posix gcc-Version 4.0.2 --- Martin -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25885
[Bug ada/25885] gnatpp won't compile
--- Comment #1 from krischik at users dot sourceforge dot net 2006-01-20 19:04 --- Created an attachment (id=10691) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10691&action=view) The GNAT chop as whiched -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25885
[Bug ada/25885] New: gnatpp won't compile
Hello Trying to compile gnatpp I get the a "GNAT BUG DETECTED" box which I like to share with you all: gnatmake "-Ptools/gnatpp/gnatpp" "-XBLD=prod" "-XOPSYS=default_Unix" gcc -c -gnatf -gnatwu -gnaty -O2 -I- -gnatA /work/martin/asis/tools/gnatpp/gnatpp-comments.adb +===GNAT BUG DETECTED==+ | 4.0.2 (x86_64-suse-linux-gnu) in create_tmp_var, bei gimplify.c:368 | | Error detected at gnatpp-comments.adb:950:8 | | Please submit a bug report; see http://gcc.gnu.org/bugs.html.| | Include the entire contents of this bug box in the report. | | Include the exact gcc or gnatmake command that you entered. | | Also include sources listed below in gnatchop format | | (concatenated together with no headers between files). | +==+ Please include these source files with error report Note that list may not be accurate in some cases, so please double check that the problem can still be reproduced with the set of files listed. /work/martin/asis/tools/gnatpp/gnatpp-comments.adb ./gnatpp-comments.ads ./gnatpp.ads ../../asis/asis.ads ../../asis/a4g.ads ../../asis/a4g-a_types.ads ../../asis/a4g-int_knds.ads /work/martin/asis/gnat/types.ads ../../asis/asis-text.ads ./gnatpp-common.ads /work/martin/asis/gnat/table.ads ./gnatpp-source_line_buffer.ads ./gnatpp-state.ads ../../asis/asis-extensions.ads ../../asis/asis-extensions-flat_kinds.ads ./gnatpp-general_traversal_stacks.ads ./gnatpp-stacs.ads ./gnatpp-layout.ads ./gnatpp-options.ads ./gnatpp-pp_output.ads ./gnatpp-output.ads ./gnatpp-source_table.ads ./gnatpp-paragraphs.ads compilation abandoned gnatmake: "/work/martin/asis/tools/gnatpp/gnatpp-comments.adb" compilation error Martin -- Summary: gnatpp won't compile Product: gcc Version: 4.0.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: krischik at users dot sourceforge dot net GCC build triplet: x86_64-suse-linux-gnu GCC host triplet: x86_64-suse-linux-gnu GCC target triplet: x86_64-suse-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25885
[Bug ada/18819] [4.1/4.2 Regression] ACATS cdd2a01 cdd2a02 fail at runtime
--- Comment #14 from uweigand at gcc dot gnu dot org 2006-01-20 18:39 --- Some additional details about the s390x failure. This is caused by a miscompile of the fdd2a00__write__2 support routine: lg %r4,168(%r15) # 35*movdi_64/8 [length = 6] lg %r3,160(%r15) # 36*movdi_64/8 [length = 6] cgr %r4,%r3 # 37*cmpdi_ccs/1[length = 4] stg %r2,168(%r15) # 33*movdi_64/9 [length = 6] Note how insn 35 reads a stack slot that is uninitialized because insn 33 has been scheduled later. This is apparently caused by an alias set issue. The code at the .t97.final_cleanup level reads: A.63 = system__arith_64__add_with_ovflo_check (D.1421, D.1426); R38b = (ada__streams__Tstream_element_offsetB *) &A.63; where the data type of A.63 is system__arith_64__int64. This gets expanded into (insn 32 31 33 3 (set (reg:DI 60) (reg:DI 2 %r2)) -1 (nil) (nil)) (insn 33 32 34 3 (set (mem/c/i:DI (plus:DI (reg/f:DI 39 virtual-stack-vars) (const_int -8 [0xfff8])) [26 A.63+0 S8 A64]) (reg:DI 60)) -1 (nil) (nil)) (insn 34 33 35 3 (parallel [ (set (reg:DI 43 [ R38b ]) (plus:DI (reg/f:DI 39 virtual-stack-vars) (const_int -8 [0xfff8]))) (clobber (reg:CC 33 %cc)) ]) -1 (nil) (nil)) (insn 35 34 36 3 (set (reg:DI 48 [ D.1430 ]) (mem:DI (reg:DI 43 [ R38b ]) [27 S8 A64])) -1 (nil) (nil)) Note alias set 26 in insn 33 vs. alias set 27 in insn 35. Any ideas why this would be the case? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18819
[Bug tree-optimization/25860] [4.2 Regression] ice with -g -O2 -fPIC
--- Comment #9 from dberlin at gcc dot gnu dot org 2006-01-20 18:30 --- Subject: Re: [4.2 Regression] ice with -g -O2 -fPIC On Fri, 2006-01-20 at 17:03 +, pinskia at gcc dot gnu dot org wrote: > > --- Comment #8 from pinskia at gcc dot gnu dot org 2006-01-20 17:03 > --- > This patch worked though: > Index: tree-ssa-pre.c > === > --- tree-ssa-pre.c (revision 110017) > +++ tree-ssa-pre.c (working copy) > @@ -1159,7 +1159,7 @@ phi_translate (tree expr, value_set_t se > VEC (tree, gc) * oldvuses = NULL; > VEC (tree, gc) * newvuses = NULL; > > - if (TREE_CODE (expr) != INDIRECT_REF) > + if (TREE_CODE (expr) != INDIRECT_REF && !AGGREGATE_TYPE_P (TREE_TYPE > (expr))) > return NULL; > Changing this to "|| AGGREGATE_TYPE_P " should also be enough to fix this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25860
[Bug testsuite/24962] gcc.target/ia64/20030811-1.c (test for excess errors) fails with -milp32
--- Comment #1 from sje at gcc dot gnu dot org 2006-01-20 18:29 --- Subject: Bug 24962 Author: sje Date: Fri Jan 20 18:29:44 2006 New Revision: 110034 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110034 Log: PR testsuite/24962 * gcc.target/ia64/20030811-1.c: Change 'long' to 'long long'. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/ia64/20030811-1.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24962
[Bug middle-end/25882] libgcov.c:577: ICE: Segmentation fault
--- Comment #2 from danglin at gcc dot gnu dot org 2006-01-20 18:19 --- This appears fixed by r110130. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25882
[Bug libgomp/25877] [4.2 Regression] team.c:269: warning: implicit declaration of function 'alloca'
--- Comment #2 from sje at gcc dot gnu dot org 2006-01-20 18:17 --- Subject: Bug 25877 Author: sje Date: Fri Jan 20 18:17:28 2006 New Revision: 110031 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110031 Log: PR libgomp/25877 * team.c: Add include of alloca.h. * configure.ac: Add check for alloca.h. * configure: Regenerate. * config.h.in: Regenerate. Modified: trunk/libgomp/ChangeLog trunk/libgomp/config.h.in trunk/libgomp/configure trunk/libgomp/configure.ac trunk/libgomp/team.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25877
[Bug libgomp/25884] New: libgomp should not require perl to compile
Like all other target libraries, libgomp should not require perl to compile. This is either a documention failure as the docs say perl is not required or this is a bug in libgomp for requiring perl. -- Summary: libgomp should not require perl to compile Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: build Severity: normal Priority: P3 Component: libgomp 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=25884
[Bug libgomp/25883] New: libgomp call pthread functions directly
libgomp (like all other target libraries in GCC) should not be calling pthread functions directly but instead using the gthr-* files in gcc. This makes libgomp more portable. -- Summary: libgomp call pthread functions directly Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgomp 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=25883
[Bug middle-end/22275] [3.4/4.0/4.1/4.2 Regression] bitfield layout change (regression?)
--- Comment #38 from mark at codesourcery dot com 2006-01-20 18:02 ---
Subject: Re: [3.4/4.0/4.1/4.2 Regression] bitfield
layout change (regression?)
matz at suse dot de wrote:
> --- Comment #37 from matz at suse dot de 2006-01-20 16:36 ---
> Hmpf. One more difficulty. x86 uses the ADJUST_FIELD_ALIGN macro
> to further fiddle with alignments of fields. On x86 this is used to
> adjust the alignment of long long to 4 (instead of the natural 8).
> This is used only when the field is not DECL_PACKED (makes sense).
> This has the funny side-effect that a struct containing a long long zero-width
> bitfield aligns to 4 for unpacked and to 8 for packed structs
Ugh. I think we can all agree that these issues had not been well
thought through previously. :-)
> if (! DECL_USER_ALIGN (decl) && ! DECL_PACKED (decl))
> {
> #ifdef ADJUST_FIELD_ALIGN
> DECL_ALIGN (decl) = ADJUST_FIELD_ALIGN (decl, DECL_ALIGN (decl));
> #endif
> }
>
> Now, I could just ignore DECL_PACKED for zero-width bitfields, then the
> adjustment would be done for both cases and we had a size of 12 with
> attribute or pragma, i.e. not the same as pre 3.4 in both.
I don't think a zero-width bitfield should ever be DECL_PACKED. (In
this case, it's DECL_PACKED because the structure is in the scope of
#pragma pack(1).)
In other words, I think a zero-width bitfield should always be subject
to ADJUST_FIELD_ALIGN; the meaning of a zero-width bitfield of type T
(for PCC_BITFIELD_TYPE_MATTERS) should be "align the next field as you
would a field of type T".
> I'm leaning towards not doing field adjustments for zero-width bitfields
> at all, having the effect that a zero-width bitfield has a user-alignment
> set explicitely (of it's base type).
Careful! That would be an ABI change even in the non-packed case, which
we don't want to do.
I think the best change would be just not to mark zero-width bitfields
as DECL_PACKED in the first place; a second choice, if easier, would be
to disregard the DECL_PACKED setting in stor-layout.c. Please add a
test case for this new oddity you discovered, if you would.
Thanks,
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22275
[Bug libfortran/25835] Segfault or Bad Address error on unformatted sequential READ
--- Comment #2 from jb at gcc dot gnu dot org 2006-01-20 17:57 --- Confirmed. -- jb at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-01-20 17:57:32 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25835
[Bug middle-end/25869] [4.2 regression] MMIX broken: ICE compiling __divti3
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-01-20 17:38 --- *** Bug 25882 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||danglin at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25869
[Bug middle-end/25882] libgcov.c:577: ICE: Segmentation fault
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-20 17:38 --- *** This bug has been marked as a duplicate of 25869 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Component|c |middle-end Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25882
[Bug c/25882] New: libgcov.c:577: ICE: Segmentation fault
/home/dave/gnu/gcc-4.2/objdir/./gcc/xgcc -B/home/dave/gnu/gcc-4.2/objdir/./gcc/ -B/home/dave/opt/gnu/gcc/gcc-4.2.0/hppa-linux/bin/ -B/home/dave/opt/gnu/gcc/gcc- 4.2.0/hppa-linux/lib/ -isystem /home/dave/opt/gnu/gcc/gcc-4.2.0/hppa-linux/include -isystem /home/dave/opt/gnu/gcc/gcc-4.2.0/hppa-linux/sys-include -O2 -O2 -g -O2 -DIN_GCC-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -DELF=1 -DLINUX=1 -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I. -I../../gcc/gcc -I. ./../gcc/gcc/. -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include -I../../gcc/gcc/../libdecnumber -I../libdecnumber -DL_gcov -c ../../gcc/gcc/libgcov.c -o libgcc/./_gcov.o ../../gcc/gcc/libgcov.c: In function '__gcov_init': ../../gcc/gcc/libgcov.c:577: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. make[4]: *** [libgcc/./_gcov.o] Error 1 -- Summary: libgcov.c:577: ICE: Segmentation fault Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org GCC build triplet: hppa-unknown-linux-gnu GCC host triplet: hppa-unknown-linux-gnu GCC target triplet: hppa-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25882
[Bug tree-optimization/25881] unsigned int loop indices are not accepted by the vectorizer
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement GCC build triplet|x86_64-unknown-linux-gnu| GCC host triplet|x86_64-unknown-linux-gnu| GCC target triplet|x86_64-unknown-linux-gnu|64bits targets http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25881
[Bug bootstrap/25790] make clean fails
--- Comment #3 from paolo dot bonzini at lu dot unisi dot ch 2006-01-20 17:21 --- Subject: Re: make clean fails aoliva at gcc dot gnu dot org wrote: >--- Comment #2 from aoliva at gcc dot gnu dot org 2006-01-20 17:16 --- >If you mean make -k for sub-makes, yes. But `make clean && make && make check' >ought to work, and not stop after make clean because it looks like it failed. > > Yes. In this case, anyway, the problem is that for a pasto I left out a "; \" in r104978. Paolo -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25790
[Bug c++/25878] Excessive memory and compile-time with std::map init sequence
-- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-01-20 17:19:33 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25878
[Bug bootstrap/25790] make clean fails
--- Comment #2 from aoliva at gcc dot gnu dot org 2006-01-20 17:16 --- If you mean make -k for sub-makes, yes. But `make clean && make && make check' ought to work, and not stop after make clean because it looks like it failed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25790
[Bug tree-optimization/25881] New: unsigned int loop indices are not accepted by the vectorizer
void vector_add(int n,
double * __restrict__ r,
double * __restrict__ a,
double * __restrict__ b) {
int i;
for(i=0; ihttp://gcc.gnu.org/bugzilla/show_bug.cgi?id=25881
[Bug tree-optimization/25860] [4.2 Regression] ice with -g -O2 -fPIC
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-01-20 17:03 ---
This patch worked though:
Index: tree-ssa-pre.c
===
--- tree-ssa-pre.c (revision 110017)
+++ tree-ssa-pre.c (working copy)
@@ -1159,7 +1159,7 @@ phi_translate (tree expr, value_set_t se
VEC (tree, gc) * oldvuses = NULL;
VEC (tree, gc) * newvuses = NULL;
- if (TREE_CODE (expr) != INDIRECT_REF)
+ if (TREE_CODE (expr) != INDIRECT_REF && !AGGREGATE_TYPE_P (TREE_TYPE
(expr)))
return NULL;
newop1 = phi_translate (find_leader (set, oldop1),
@@ -1989,7 +1989,7 @@ can_PRE_operation (tree op)
return UNARY_CLASS_P (op)
|| BINARY_CLASS_P (op)
|| COMPARISON_CLASS_P (op)
-|| TREE_CODE (op) == INDIRECT_REF
+|| (TREE_CODE (op) == INDIRECT_REF)
|| TREE_CODE (op) == CALL_EXPR;
}
@@ -2650,7 +2650,7 @@ create_value_expr_from (tree expr, basic
/* Recursively value-numberize reference ops. */
- if (REFERENCE_CLASS_P (TREE_VALUE (vexpr)))
+ if (REFERENCE_CLASS_P (TREE_VALUE (vexpr)) && !AGGREGATE_TYPE_P
(TREE_TYPE (TREE_VALUE (vexpr
{
tree tempop;
op = TREE_VALUE (vexpr);
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25860
[Bug middle-end/23488] [4.1/4.2 Regression] GCSE load PRE does not work with non sets
--- Comment #14 from pinskia at gcc dot gnu dot org 2006-01-20 16:42 --- Changing GVN PRE for adding decl as references is harder than I thought. :(. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23488
[Bug middle-end/22275] [3.4/4.0/4.1/4.2 Regression] bitfield layout change (regression?)
--- Comment #37 from matz at suse dot de 2006-01-20 16:36 ---
Hmpf. One more difficulty. x86 uses the ADJUST_FIELD_ALIGN macro
to further fiddle with alignments of fields. On x86 this is used to
adjust the alignment of long long to 4 (instead of the natural 8).
This is used only when the field is not DECL_PACKED (makes sense).
This has the funny side-effect that a struct containing a long long zero-width
bitfield aligns to 4 for unpacked and to 8 for packed structs, i.e. the
packed struct actually is _larger_ than the unpacked struct. E.g. the
running example with UINT being long long:
typedef int BOOL;
typedef unsigned long long UINT;
#pragma pack(1)
typedef struct {
BOOL fFullPathTitle:1;
BOOL fSaveLocalView:1;
BOOL fNotShell:1;
BOOL fSimpleDefault:1;
BOOL fDontShowDescBar:1;
BOOL fNewWindowMode:1;
BOOL fShowCompColor:1;
BOOL fDontPrettyNames:1;
BOOL fAdminsCreateCommonGroups:1;
UINT fUnusedFlags:7;
UINT :0;
UINT fMenuEnumFilter;
} CABINETSTATE;
This struct being unpacked (only influenced by #pragma) has size 12 after
my patch on i686, and size 16 (!) when being packed via attribute.
What's even more ugly is that pre-3.4 GCC had a size of 16 for both
cases (pragma or attribute packed) on i686 :-(
So, how would we like to handle this? Doing as pre 3.4 did is probably
possible but not trivially done. Basically the code doing this is:
if (! DECL_USER_ALIGN (decl) && ! DECL_PACKED (decl))
{
#ifdef ADJUST_FIELD_ALIGN
DECL_ALIGN (decl) = ADJUST_FIELD_ALIGN (decl, DECL_ALIGN (decl));
#endif
}
Now, I could just ignore DECL_PACKED for zero-width bitfields, then the
adjustment would be done for both cases and we had a size of 12 with
attribute or pragma, i.e. not the same as pre 3.4 in both. I also
could never adjust zero-width bitfields, so that they would get their
natural alignment even when the target wanted something else. Then both
cases would have size 16, being the same as pre 3.4.
I'm leaning towards not doing field adjustments for zero-width bitfields
at all, having the effect that a zero-width bitfield has a user-alignment
set explicitely (of it's base type). I think if one understands zero-width
bitfields purely as alignment constraints than this implicit DECL_USER_ALIGN
behaviour seems sensible.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22275
[Bug tree-optimization/25860] [4.2 Regression] ice with -g -O2 -fPIC
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-01-20 16:14 --- (In reply to comment #6) > This one is actually not a trivial problem to fix ATM (in this case, > eliminate would need to be changed as well), so it would be best to just > change the can_PRE_operation to have something like: > > || (TREE_CODE (op) == INDIRECT_REF && !AGGREGATE_TYPE_P (TREE_TYPE > (op > > > If someone wants to bootstrap and test that fix before i get to it in > the next week or so, that's fine. That did not work, we get a different ICE: t.cc: In function 'savewav': t.cc:11: internal compiler error: in find_or_generate_expression, at tree-ssa-pre.c:2029 Please submit a full bug report, with preprocessed source if appropriate. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25860
[Bug c++/25878] Excessive memory and compile-time with std::map init sequence
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-01-20 15:57 --- Patch which might help: http://gcc.gnu.org/ml/gcc-patches/2005-09/msg00881.html It is not a complete patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25878
[Bug c/25880] suggestion: a special warning for discarding the ``const'' qualifier
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-01-20 16:04 --- Patches should go to [EMAIL PROTECTED] The correct quoting style is "%" as %< and %> gets translated to the corect quote for the person. You might just say all the Quals which are discarded, there are only 3, restrict, const and volatile. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||diagnostic Last reconfirmed|-00-00 00:00:00 |2006-01-20 16:04:23 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25880
[Bug c/25880] suggestion: a special warning for discarding the ``const'' qualifier
--- Comment #1 from roland dot illig at gmx dot de 2006-01-20 15:59 --- Created an attachment (id=10690) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10690&action=view) Special warning for ``const''. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25880
[Bug c/25880] New: suggestion: a special warning for discarding the ``const'' qualifier
The current gcc warning for discarded qualifiers cannot be easily understood by
beginners:
$ cat const.c
int main(void)
{
const char *pcc;
char *pc;
pcc = "hello, world";
pc = pcc;
return 0;
}
$ gcc -Wall -W const.c
const.c: In function `main':
const.c:7: warning: assignment discards qualifiers from pointer target type
This warning doesn't give any hint to a programmer not familiar with the ISO
standard's wording. Therefore I suggest to make a special case warning if the
only qualifier that's discarded is ``const''. It would then show up like this:
$ ~/pkg/gcc3/bin/gcc -Wall -W const.c
const.c: In function `main':
const.c:7: warning: assignment discards ``const'' qualifier from pointer target
type
--
Summary: suggestion: a special warning for discarding the
``const'' qualifier
Product: gcc
Version: 3.3.5
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: roland dot illig at gmx dot de
GCC build triplet: *-*-*
GCC host triplet: *-*-*
GCC target triplet: *-*-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25880
[Bug c++/25878] Excessive memory and compile-time with std::map init sequence
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-01-20 15:55 --- The other thing which might help here is trying to find more functions which can have nothrow on them which should help compile time. I had a patch which did this at the tree level but never finished it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25878
[Bug c++/25878] Excessive memory and compile-time with std::map init sequence
--- Comment #6 from rguenth at gcc dot gnu dot org 2006-01-20 15:53 --- And we can hope that the SSA inliner will do better on the temporaries, but I guess the resulting CFG will be unchanged. Penaltizing try/finally in estimate_num_insn_1 instead of declaring them "/* Containers have no cost. */" will maybe make inlining sane here again (possibly conditional on -fexceptions). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25878
[Bug rtl-optimization/15792] missed subreg optimization
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-01-20 15:52 --- (In reply to comment #4) > I'm going to experiment with moving where the subreg lowering code occurs and > moving up the splitting into subregs and see if I can get the desired > results. > I'm pretty new to GCC, so if any of the above seems like I'm off in the weeds > then please let me know. This seems right but the other issue is that register allocator allocates DI as two consecutive register as one (that might be only part of the cause). -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||tony dot linthicum at amd ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15792
[Bug c++/25878] Excessive memory and compile-time with std::map init sequence
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-01-20 15:50 --- At .ssa we have for the posted fragment the following loads of basic blocks and exception objects: : D.68636_176 = &this_1->iso639_1; D.68641_177 = operator[] (D.68636_176, &D.68639); : this_230 = (struct basic_string,std::allocator > * const) D.68641_177; __s_231 = &"Abkhazian"[0]; this_232 = this_230; __s_233 = __s_231; __s_234 = __s_233; D.76438_235 = strlen (__s_234); D.76432_236 = D.76438_235; D.76433_237 = assign (this_232, __s_233, D.76432_236); : D.76434_238 = D.76433_237; D.76435_239 = D.76434_238; D.76436_240 = D.76435_239; D.68642_241 = D.76436_240; this.146_242 = (struct new_allocator *) &D.68644; this_243 = (struct new_allocator * const) this.146_242; __comp_ctor (&D.68643, &"abk"[0], &D.68644); : D.68637_248 = &this_1->iso639_2; D.68645_249 = operator[] (D.68637_248, &D.68643); : this_302 = (struct basic_string,std::allocator > * const) D.68645_249; __str_303 = (struct basic_string,std::allocator > &) D.68642_241; D.76444_304 = assign (this_302, __str_303); : D.76445_305 = D.76444_304; D.76443_306 = D.76445_305; this_307 = (struct basic_string,std::allocator > * const) &D.68643; this_308 = (struct basic_string,std::allocator > * const) this_307; D.76520_309 = &D.76510; D.76521_310 = &this_308->_M_dataplus; D.76522_311 = (struct allocator *) D.76521_310; this_312 = (struct allocator * const) D.76520_309; __a_313 = (struct allocator &) D.76522_311; __a.148_314 = (struct new_allocator *) __a_313; this.149_315 = (struct new_allocator *) this_312; this_316 = (struct new_allocator * const) this.149_315; D.76525_317 = (struct new_allocator &) __a.148_314; this_318 = (struct basic_string,std::allocator > * const) this_307; this_319 = this_318; D.76534_320 = this_319->_M_dataplus._M_p; D.76530_321 = D.76534_320; D.76531_322 = (struct _Rep *) D.76530_321; D.76532_323 = D.76531_322 + -24B; D.76511_324 = D.76532_323; this_325 = (struct _Rep * const) D.76511_324; __a_326 = (struct allocator &) &D.76510; __p_327 = &_S_empty_rep_storage; D.76549_328 = (struct _Rep *) __p_327; D.76537_329 = D.76549_328; D.76538_330 = D.76537_329 != this_325; D.76539_331 = __builtin_expect (D.76538_330, 0); retval.156_332 = D.76539_331 != 0; if (retval.156_332) goto ; else goto ; :; save_filt.202_250 = <<>>; save_eptr.201_251 = <<>>; this_252 = (struct basic_string,std::allocator > * const) &D.68643; this_253 = (struct basic_string,std::allocator > * const) this_252; D.76459_254 = &D.76449; D.76460_255 = &this_253->_M_dataplus; D.76461_256 = (struct allocator *) D.76460_255; this_257 = (struct allocator * const) D.76459_254; __a_258 = (struct allocator &) D.76461_256; __a.148_259 = (struct new_allocator *) __a_258; this.149_260 = (struct new_allocator *) this_257; this_261 = (struct new_allocator * const) this.149_260; D.76464_262 = (struct new_allocator &) __a.148_259; this_263 = (struct basic_string,std::allocator > * const) this_252; this_264 = this_263; D.76473_265 = this_264->_M_dataplus._M_p; D.76469_266 = D.76473_265; D.76470_267 = (struct _Rep *) D.76469_266; D.76471_268 = D.76470_267 + -24B; D.76450_269 = D.76471_268; this_270 = (struct _Rep * const) D.76450_269; __a_271 = (struct allocator &) &D.76449; __p_272 = &_S_empty_rep_storage; D.76488_273 = (struct _Rep *) __p_272; D.76476_274 = D.76488_273; D.76477_275 = D.76476_274 != this_270; D.76478_276 = __builtin_expect (D.76477_275, 0); retval.156_277 = D.76478_276 != 0; if (retval.156_277) goto ; else goto ; :; D.76482_286 = &this_270->D.16095._M_refcount; D.76483_287 = (volatile _Atomic_word *) D.76482_286; D.76484_288 = __exchange_and_add (D.76483_287, -1); : retval.157_301 = D.76484_288 <= 0; if (retval.157_301) goto ; else goto ; :; _M_destroy (this_270, __a_271); goto (); :; save_filt.198_289 = <<>>; save_eptr.197_290 = <<>>; this.147_291 = (struct new_allocator *) &D.76449; this_292 = (struct new_allocator * const) this.147_291; <<>> = save_eptr.197_290; <<>> = save_filt.198_289; resx; :; this.147_278 = (struct new_allocator *) &D.76449; this_279 = (struct new_allocator * const) this.147_278; D.76454_280 = &this_252->_M_dataplus; this_281 = (struct _Alloc_hider * const) D.76454_280; this.150_282 = (struct allocator *) this_281; this_283 = (struct allocator * const) this.150_282; this.147_284 = (struct new_allocator *) this_283; this_285 = (struct new_allocator * const) this.147_284; <<>> = save_eptr.201_251; <<>> = save_filt.202_250; resx; :; save_filt.200_293 = <<>>; save_eptr.199_294 = <<>>; D.76454_295 = &this_252->_M_dataplus; this_296 = (struct _Alloc_hider * const) D.76454_295; this.150_297 = (struct allocator *) this_296; this_298 = (struct allocator * const) this.150_297; this.147_299 = (struct new_allocator *) this_298; this_300 =
