--- Comment #7 from jakub at gcc dot gnu dot org 2010-03-06 09:36 ---
Created an attachment (id=20035)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20035&action=view)
gcc45-pr43176.patch
Updated patch.
--
jakub at gcc dot gnu dot org changed:
What|Removed
--- Comment #10 from burnus at gcc dot gnu dot org 2010-03-06 09:49 ---
In terms of the standard, probably everything is OK for I/O: "The set of
input/output error conditions is processor dependent." (See "9.11.1 General"
for a non-definition when EOF occurs.)
Looking at other compilers
--- Comment #11 from manu at gcc dot gnu dot org 2010-03-06 12:18 ---
(In reply to comment #10)
> However, with so many lines of legacy code out there using bit-filed that have
> been proven to work, it doesn't make sense to revisit/modify them. Would it
> be
> possible for gcc to prov
such code cause ICE or template instantiation depth exceeds maximum error,
if uncomment (1) and comment (2) all compiles successfully.
#include
#include
template
struct ConstDependOnType;
template <>
struct ConstDependOnType {
enum { val1 = 4 };
};
template
struct Foo {
//1
//enum {
--- Comment #4 from n-takeda at kwansei dot ac dot jp 2010-03-06 13:10
---
(In reply to comment #3)
> What is the size of long on h8300-elf?
>
The size of long is 32bit.
LONG_MAX is 2,147,483,647.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43264
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-03-06 14:05 ---
Yeah. Mine.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|una
--- Comment #13 from rguenth at gcc dot gnu dot org 2010-03-06 14:27
---
Err - it's just because the code is broken:
tree low_bound, up_bound = array_ref_up_bound (ref);
low_sub = up_sub = TREE_OPERAND (ref, 1);
if (!up_bound || TREE_NO_WARNING (ref)
|| TREE_CODE (up_boun
--- Comment #14 from rguenth at gcc dot gnu dot org 2010-03-06 14:28
---
Created an attachment (id=20036)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20036&action=view)
untested patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43270
On Linux/x86, revision 157244:
http://gcc.gnu.org/ml/gcc-cvs/2010-03/msg00116.html
caused:
FAIL: libgomp.graphite/force-parallel-2.c scan-tree-dump-times graphite "2
loops carried no dependency" 2
--
Summary: [4.5 regression] Revision 157244 failed
libgomp.graph
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43274
This error message:
error: type 'type1' is not derived from 'type2'
is rather unclear. The first reaction is to look at the source, see that
indeed, type1 is not derived from type2, and say "... and why does that
matter?!"
Source:
template < typename A > struct B {
typedef int C;
};
template
/test/gnu/gcc/objdir/./prev-gcc/xgcc -B/test/gnu/gcc/objdir/./prev-gcc/
-B/opt/g
nu64/gcc/gcc-4.5.0/hppa64-hp-hpux11.11/bin/
-B/opt/gnu64/gcc/gcc-4.5.0/hppa64-hp
-hpux11.11/bin/ -B/opt/gnu64/gcc/gcc-4.5.0/hppa64-hp-hpux11.11/lib/ -isystem
/op
t/gnu64/gcc/gcc-4.5.0/hppa64-hp-hpux11.11/include -isyst
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2010-03-06 15:58
---
It is defined in /usr/include/libelf/elf_repl.h for libelf 0.8.12 so you'll
need to find out what's going on here.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from danglin at gcc dot gnu dot org 2010-03-06 16:08 ---
libelf uses the system's , not libelf/elf_repl.h. The system
headers don't provide the SPARC defines.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43276
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2010-03-06 16:19
---
> libelf uses the system's , not libelf/elf_repl.h. The system
> headers don't provide the SPARC defines.
I see, one of those "severely broken" systems libelf/sys_elf.h talks about. We
can probably put a kludge
--- Comment #7 from dominiq at lps dot ens dot fr 2010-03-06 17:09 ---
With the following patch the test in comment #6 is hopefully valid (it compiles
with '-O2 -fwhole-file', but gives an ICE with '-O3 -fwhole-file'):
--- pr41056.f90 2010-02-24 17:38:27.0 +0100
+++ pr41056_db.f
A very simple exception test case results in an abort trap:
host% cat exctest.cpp
struct StackThing {
~StackThing() { }
};
struct Thrower {
static void Throw() {
StackThing obj;
throw -1;
}
};
int main() {
try {
Thrower::Throw();
} catch (...) { }
}
hos
uname -a
Linux jericho.southkc.net 2.6.17-1.2187_FC5.6axp #1 Tue Feb 27 02:55:25 MSK
2007 alpha alpha alpha GNU/Linux
[r...@jericho libjava]# cat /proc/cpuinfo
cpu : Alpha
cpu model : EV68AL
cpu variation : 7
cpu revision: 0
cpu serial number :
system
--- Comment #1 from howarth at nitro dot med dot uc dot edu 2010-03-06
19:09 ---
This doesn't occur with gcc trunk on x86_64-apple-darwin10 but does for gcc
4.4.3. Perhaps backporting r151960 to avoid compact unwind code on gcc 4.4
branch for darwin10 would solve this.
--
http://gc
--- Comment #8 from burnus at gcc dot gnu dot org 2010-03-06 19:42 ---
Created an attachment (id=20037)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20037&action=view)
Another reduced test case; 34 lines, shows no warning with NAG f95 and gfortran
And another test case. Just 34 l
--- Comment #2 from howarth at nitro dot med dot uc dot edu 2010-03-06
20:22 ---
r151960 doesn't eliminate the problem in gcc 4.4 branch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43277
--- Comment #18 from aoliva at gcc dot gnu dot org 2010-03-06 20:26 ---
Subject: Bug 41371
Author: aoliva
Date: Sat Mar 6 20:26:15 2010
New Revision: 157257
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157257
Log:
* var-tracking.c (dataflow_set_merge): Swap src and src2.
Reve
--- Comment #5 from aoliva at gcc dot gnu dot org 2010-03-06 20:28 ---
Subject: Bug 42897
Author: aoliva
Date: Sat Mar 6 20:28:04 2010
New Revision: 157258
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157258
Log:
PR debug/42897
* tree-vect-loop.c (vect_transform_loop): Kill o
--- Comment #6 from aoliva at gcc dot gnu dot org 2010-03-06 20:30 ---
Subject: Bug 42897
Author: aoliva
Date: Sat Mar 6 20:30:10 2010
New Revision: 157259
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157259
Log:
PR debug/42897
* gimple-iterator.c (gsi_remove): Propagate only
--- Comment #7 from aoliva at gcc dot gnu dot org 2010-03-06 21:08 ---
Fixed
--
aoliva at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #2 from erh+gcc at nimenees dot com 2010-03-06 21:34 ---
So does this mean bug #13687 is going to be reopened? Or is there some
workaround that hasn't been mentioned?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43272
--- Comment #9 from burnus at gcc dot gnu dot org 2010-03-06 22:58 ---
(In reply to comment #8)
> Created an attachment (id=20037)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20037&action=view) --
reduced test case
/dev/shm/test/domi14.f90:7:0: error: type mismatch between an S
--- Comment #3 from howarth at nitro dot med dot uc dot edu 2010-03-07
00:00 ---
This bug occurs in both gcc 4.4.3 and 4.4.2 on x86_64-apple-darwin10, however
it doesn't occur under x86_64-apple-darwin9. This may be a compatibility issue
with the FSF gcc unwinder code executed on the li
--- Comment #4 from pinskia at gcc dot gnu dot org 2010-03-07 00:02 ---
This is most likely related to PR 43099.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43277
--- Comment #5 from howarth at nitro dot med dot uc dot edu 2010-03-07
02:01 ---
I wonder if the remaining failure on *86*-apple-darwin9 for PR41991 could also
be due to PR43099?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43277
--- Comment #21 from jason at gcc dot gnu dot org 2010-03-07 05:36 ---
Hmm, that's odd. Why would Darwin satisfy dg-require-alias when it doesn't
have ASM_OUTPUT_DEF?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12909
--- Comment #3 from bangerth at gmail dot com 2010-03-07 05:49 ---
(In reply to comment #2)
> So does this mean bug #13687 is going to be reopened? Or is there some
> workaround that hasn't been mentioned?
No. I think the issue has been discussed at length there.
W.
--
bangerth at
32 matches
Mail list logo
