--- Comment #7 from dorit at il dot ibm dot com 2007-03-24 08:00 ---
patch: http://gcc.gnu.org/ml/gcc/2007-03/msg00918.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30784
--- Comment #5 from patchapp at dberlin dot org 2007-03-24 08:10 ---
Subject: Bug number PR31200
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-03/msg01595.html
--
--- Comment #1 from pault at gcc dot gnu dot org 2007-03-24 08:16 ---
(In reply to comment #0)
Is this example (PR 20541) really valid?
Lahey does not complain.
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31320
The testcase gcc.dg/vect/no-tree-dom-vect-bug.c ICEs on i386-linux when
compiled as follows:
gcc no-tree-dom-vect-bug.c -O2 -fno-tree-dominator-opts -ftree-vectorize -msse
no-tree-dom-vect-bug.c: In function âmain1â:
no-tree-dom-vect-bug.c:15: internal compiler error: in expand_simple_binop, at
--- Comment #4 from schwab at suse dot de 2007-03-24 08:26 ---
(In reply to comment #2)
Note that the newly built bootstrap compiler fails the configure tests which
have a trailing -V on the command line.
This is harmless, it's only for informational purpose (various tries to make
--- Comment #3 from tprince at computer dot org 2007-03-24 01:22
(In reply to comment #3)
The code thus commented out apparently requires some cygwin
extensions in the library which have disappeared since 20070224 (quoted
by submitter as last working build). I concur, having built
Turns out the code we are generating for vectorized induction ppc is quite
terrible - the vector induction variable is advanced by a constant step in the
loop (e.g., {4,4,4,4} as in the testcase below). This is the sequence gcc
currently creates for altivec in order to generate the {4,4,4,4}
In libgfortran/intrinsics/stat.c, we unconditionally issue calls to stat(),
fstat() and lstat(). This is wrong, and these calls should be protected by
HAVE_{,F,L}STAT macros, themselves defined by autoconf.
This bug is annoying especially for lstat(), because it's non-POSIX and it's
not present
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #40 from manu at gcc dot gnu dot org 2007-03-24 11:10 ---
In the current version of the patch janis-try2, this is more correct
-set expmsg $msgprefix\[^\n]*$expmsg
+set expmsg $msgprefix\[^\n\]*$expmsg
But it doesn't make any real difference (or so it seems).
--
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-03-24 12:13
---
We already have that, if you compile with both -fbounds-check and -fbacktrace.
(Same thing is true for coredump, with -fdump-core.) Do you want fries with
that?
$ cat bbb.f90
subroutine f
integer :: x(2), u
--- Comment #3 from pault at gcc dot gnu dot org 2007-03-24 12:31 ---
Subject: Bug 31219
Author: pault
Date: Sat Mar 24 12:30:58 2007
New Revision: 123183
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123183
Log:
2007-03-24 Paul Thomas [EMAIL PROTECTED]
PR
--- Comment #6 from pault at gcc dot gnu dot org 2007-03-24 12:31 ---
Subject: Bug 31200
Author: pault
Date: Sat Mar 24 12:30:58 2007
New Revision: 123183
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123183
Log:
2007-03-24 Paul Thomas [EMAIL PROTECTED]
PR
--- Comment #4 from pault at gcc dot gnu dot org 2007-03-24 12:31 ---
Subject: Bug 31215
Author: pault
Date: Sat Mar 24 12:30:58 2007
New Revision: 123183
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123183
Log:
2007-03-24 Paul Thomas [EMAIL PROTECTED]
PR
--- Comment #1 from dje at gcc dot gnu dot org 2007-03-24 13:30 ---
Loading the constant through memory appears to be related to the vector plus
expander.
118t.final_cleanup shows:
vect_vec_iv_.32 = vect_cst_.30 + {4, 4, 4, 4};
and 120r.expand shows:
;; vect_vec_iv_.32 =
--- Comment #4 from pault at gcc dot gnu dot org 2007-03-24 13:56 ---
Fixed on trunk
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from pault at gcc dot gnu dot org 2007-03-24 13:57 ---
Fixed on trunk
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from pault at gcc dot gnu dot org 2007-03-24 13:58 ---
Fixed on trunk
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pault at gcc dot gnu dot org 2007-03-24 13:59 ---
Fixed on trunk but wrongly numbered in ChangeLog
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from pault at gcc dot gnu dot org 2007-03-24 14:00 ---
Sorry, this was not fixed - it was PR31209 that was fixed.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from pault at gcc dot gnu dot org 2007-03-24 14:17 ---
Subject: Bug 31200
Author: pault
Date: Sat Mar 24 14:17:34 2007
New Revision: 123184
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123184
Log:
2007-03-24 Paul Thomas [EMAIL PROTECTED]
PR
--- Comment #6 from pault at gcc dot gnu dot org 2007-03-24 14:17 ---
Subject: Bug 31215
Author: pault
Date: Sat Mar 24 14:17:34 2007
New Revision: 123184
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123184
Log:
2007-03-24 Paul Thomas [EMAIL PROTECTED]
PR
--- Comment #6 from pault at gcc dot gnu dot org 2007-03-24 14:17 ---
Subject: Bug 31219
Author: pault
Date: Sat Mar 24 14:17:34 2007
New Revision: 123184
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123184
Log:
2007-03-24 Paul Thomas [EMAIL PROTECTED]
PR
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
URL||http://gcc.gnu.org/ml/gcc-
|
--- Comment #8 from patchapp at dberlin dot org 2007-03-24 17:10 ---
Subject: Bug number PR30784
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-03/msg01607.html
--
--- Comment #10 from s_j_newbury at yahoo dot co dot uk 2007-03-24 17:30
---
(In reply to comment #3)
Created an attachment (id=13262)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13262action=view) [edit]
EABI can't implement _Unwind_Backtrace
This patch is from this bug:
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-03-24 17:30 ---
The backtrace shows rtl invariant motion.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #41 from manu at gcc dot gnu dot org 2007-03-24 17:55 ---
(In reply to comment #38)
For comment #32 I get the failure but don't understand the problem; the regexp
matches the message, doesn't it? This doesn't seem any different from other
Fortran tests but it's the only
--- Comment #30 from jvdelisle at verizon dot net 2007-03-24 19:02 ---
Subject: Re: Bad IOSTAT values when readings NAMELISTs
past EOF
I will keep at it on this. It seems we have a conflict between the SPEC
test that was failing and the namelist testcases. Unfortunately I don't
--- Comment #11 from s_j_newbury at yahoo dot co dot uk 2007-03-24 19:58
---
I have everything built except for libjava/exception.cc which fails as seen
below.
This I believe is due to the lack of an implementation of _Unwind_Backtrace in
the ARM EABI. What needs to be done to
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-03-24 20:20
---
Subject: Bug 30655
Author: fxcoudert
Date: Sat Mar 24 20:19:51 2007
New Revision: 123187
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123187
Log:
PR fortran/30655
* expr.c
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-03-24 20:21
---
Fixed on 4.3, will not backport.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-03-24 20:53
---
Reduced testcase:
function tricky(ugly)
interface yoagly
pure function ugly()
complex ugly(2)
end function ugly
end interface yoagly
logical la(size(yoagly()))
print *, size(la)
end
Koenig lookup doesn't seem to work properly when dealing with template friends
defined within a class. Friends defined within the definition of a class
shouldn't be visible to the enclosing namespace, and should only be able to be
found via Koenig lookup. I see that this appears to work as
--- Comment #3 from tkoenig at alice-dsl dot net 2007-03-24 21:35 ---
Created an attachment (id=13278)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13278action=view)
proposed patch
This should fix it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31196
:ADDPATCH fortran:
Hello world,
this one-liner fixes PR 31196, where reshape of a
transposed array led to silent wrong results.
Currently regtesting on i686-pc-linux-gnu. OK for 4.3
if this passes? OK for 4.2?
Thomas
2007-03-24 Thomas Koenig [EMAIL PROTECTED]
*
--- Comment #1 from tkoenig at alice-dsl dot net 2007-03-24 22:17 ---
This is a bug in the test case.
I'll commit a correct version.
Thomas
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31297
--- Comment #1 from dominiq at lps dot ens dot fr 2007-03-24 22:28 ---
xlf yields a bus error without optimization and -O, and abort with -O3.
g95 gives the following errors:
In file pointer_intent_1.f90:39
nullify(t%point)
1
Error: Cannot NULLIFY the INTENT(IN)
--- Comment #2 from tkoenig at alice-dsl dot net 2007-03-24 22:44 ---
Created an attachment (id=13279)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13279action=view)
patch for the test cases
All but one of these were errors in the test cases, which are
corrected with this patch.
The following valid code snippet triggers an ICE on mainline and 4.2 branch:
===
struct A
{
int i[0];
A();
A(const A);
};
void foo()
{
A a = ({ A(); });
}
===
bug.cc: In function 'void foo()':
bug.cc:10: internal compiler error: in
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.2.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31337
--- Comment #3 from tkoenig at alice-dsl dot net 2007-03-24 23:07 ---
Created an attachment (id=13280)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13280action=view)
proposed patch
This one also fixes the last case.
It does so by reading size bytes instead of the kind number
:REVIEWMAIL:
this one-liner fixes PR 31196, where reshape of a
transposed array led to silent wrong results.
Yes, this brings the code in intrinsics/reshape_generic.c in line
with m4/reshape.m4. What's amusing is that this difference appears to
go back to the initial merge of code from
The following IMHO valid code snippet is rejected since GCC 3.4.0:
===
bool b = !0i;
===
bug.cc:1: error: could not convert '#'complex_cst' not supported by
dump_expr#expression error' to 'bool'
bug.cc:1: error: in argument to unary !
The C
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31338
The following invalid code snippet triggers an ICE on mainline:
===
bool b = --0i == 0;
===
bug.cc:1: error: lvalue required as decrement operand
bug.cc:1: internal compiler error: tree check: expected class 'type', have
'exceptional' (error_mark)
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31339
signal.h is in scope when gcc.dg/setjmp-3.c and setjmp-4.c are compiled. The
attempt to redefine raise() causes the tests to fail. Either this should be an
XFAIL, or the test should be changed so as to remove the conflict with
pre-existing definition. The definition in the testsuite conflicts
gcc.dg/vect/pr31041 attempts to redefine int32_t while stdint.h is in scope,
so test reports FAIL. Is this the intent of the test?
--
Summary: testsuite pr31041.c fails conflicting with stdint.h
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
This case issues the warning -fPIC ignored and is FAILed on account of it.
--
Summary: testsuite i386/pic-1.c FAILed for warning -fPIC ignored
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-03-25 08:11 ---
The name of the function should be changed, it is just a local function name
anyways.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-03-25 08:21 ---
if (TYPE_OVERFLOW_UNDEFINED (TREE_TYPE (arg0))
I think we are just checking TYPE_OVERFLOW_UNDEFINED too early.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-03-25 08:46 ---
This is a front-end issue:
cleanup_point Unknown tree: expr_stmt
(void) (a = TARGET_EXPR D.2077, cleanup_point TARGET_EXPR D.2076,
Unknown tree: aggr_init_expr
4
__comp_ctor
D.2076
0B
)
We have a
53 matches
Mail list logo
