--- Comment #3 from pinskia at gcc dot gnu dot org 2007-03-25 09:26 ---
Here is a patch which fixes the problem:
Index: ../../gcc/config/rs6000/rs6000.c
===
--- ../../gcc/config/rs6000/rs6000.c(revision 123180)
+++ ../..
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-03-25 09:11 ---
Here is a reduced testcase which shows the same issue:
#define vector __attribute__((__vector_size__(16) ))
vector int f()
{
int t = 4;
return (vector int){t,t,t,t};
}
vector int f1()
{
return (vector int){4,4,
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-03-25 08:46 ---
This is a front-end issue:
<>>
) >>>
We have a cleanup_point expression which causes an extra variable to be created
but since the type is addressable, we abort.
--
pinskia at gcc dot gnu dot org changed:
--- 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 |Added
--- 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
---
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
C
gcc.dg/vect/pr31041 attempts to redefine int32_t while is in scope,
so test reports FAIL. Is this the intent of the test?
--
Summary: testsuite pr31041.c fails conflicting with
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: nor
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 with Open
--
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
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) i
--
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 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#' to 'bool'
bug.cc:1: error: in argument to unary !
The C front-end accepts compl
: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 tre
--- 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=13280&action=view)
proposed patch
This one also fixes the last case.
It does so by reading size bytes instead of the kind number wh
--
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
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 create_
--- 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=13279&action=view)
patch for the test cases
All but one of these were errors in the test cases, which are
corrected with this patch.
--- 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) p
--- 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
: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]>
* intrinsic/reshape
--- 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=13278&action=view)
proposed patch
This should fix it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31196
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 expect
--- 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 functio
--- 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 #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=gcc&view=rev&rev=123187
Log:
PR fortran/30655
* expr.c (check_dimens
--- 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 address
--- 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
ha
--- 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 onl
--- 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 #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=13262&action=view) [edit]
> EABI can't implement _Unwind_Backtrace
>
> This patch is from this bu
--- 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
--
http://gcc.gnu.org/bugzilla/sh
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
URL||http://gcc.gnu.org/ml/gcc-
|
--- 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=gcc&view=rev&rev=123184
Log:
2007-03-24 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- 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=gcc&view=rev&rev=123184
Log:
2007-03-24 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- 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=gcc&view=rev&rev=123184
Log:
2007-03-24 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- 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 #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 #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
Status
--- 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
Status
--- 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
Status
--- 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 = vect_cst_.
--- 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=gcc&view=rev&rev=123183
Log:
2007-03-24 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- 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=gcc&view=rev&rev=123183
Log:
2007-03-24 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- 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=gcc&view=rev&rev=123183
Log:
2007-03-24 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- 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 #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).
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last recon
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 on
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} vector
--- 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
>
--- 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
t
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
o
--- 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
--- 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
--
http://gcc.gnu.org/bugzilla/sh
--- 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
55 matches
Mail list logo
