--- Comment #1 from burnus at gcc dot gnu dot org 2007-08-22 06:36 ---
Minimal example:
implicit none
real, TARGET :: a(0:100)
real, pointer :: p(:)
p = a
print *, lbound(a), ubound(a)
print *, lbound(p), ubound(p)
end
Prints:
0 100
1
--- Comment #9 from rguenth at gcc dot gnu dot org 2007-08-22 08:01 ---
Subject: Bug 32563
Author: rguenth
Date: Wed Aug 22 08:00:55 2007
New Revision: 127688
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127688
Log:
2007-08-22 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #10 from rguenth at gcc dot gnu dot org 2007-08-22 08:07
---
Subject: Bug 32563
Author: rguenth
Date: Wed Aug 22 08:07:11 2007
New Revision: 127689
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127689
Log:
2007-08-22 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #11 from rguenth at gcc dot gnu dot org 2007-08-22 08:08
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from cato at df dot lth dot se 2007-08-22 08:28 ---
Subject: Re: [4.3 regression] error: definition
in block 11 does not dominate use in block 12
This seems to work now. I have successfully bootstrapped revision 127624
on i386-unknown-netbsdelf3.1.
--
long
foo (int i)
{
float x;
x = i;
return __builtin_lroundf (x);
}
and
long
foo (int i)
{
return __builtin_lroundf ((float)i);
}
should generate the same code. The former is before expansion
return __builtin_lroundf ((float) i);
which is unfolded while the latter is
return (long
I get the following ICE with current trunk. This was introduced between
20070616 (works) and 20070720 (ICE).
(sid)25899:[EMAIL PROTECTED]: ~] /usr/lib/gcc-snapshot/bin/gcc -c -O -Wall
jasper-jpc_t1enc.c
jasper-jpc_t1enc.c: In function 'foo':
jasper-jpc_t1enc.c:10: internal compiler error: in
--- Comment #1 from tbm at cyrius dot com 2007-08-22 08:34 ---
Maybe caused by:
2007-06-19 Sebastian Pop [EMAIL PROTECTED]
PR tree-optimization/32367
* tree-chrec.h (build_polynomial_chrec): Verify that the left hand side
--
tbm at cyrius dot com changed:
--- Comment #2 from tbm at cyrius dot com 2007-08-22 08:34 ---
/* Testcase by Martin Michlmayr [EMAIL PROTECTED] */
typedef struct
{
int end;
int term;
}
jpc_enc_pass_t;
void foo(int numpasses, jpc_enc_pass_t *p)
{
jpc_enc_pass_t *pass;
jpc_enc_pass_t *termpass;
for (pass =
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-08-22 08:44 ---
Subject: Bug 33142
Author: rguenth
Date: Wed Aug 22 08:43:53 2007
New Revision: 127691
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127691
Log:
2007-08-22 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-08-22 08:46 ---
Subject: Bug 33142
Author: rguenth
Date: Wed Aug 22 08:45:58 2007
New Revision: 127692
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127692
Log:
2007-08-22 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-08-22 08:47 ---
Subject: Bug 33142
Author: rguenth
Date: Wed Aug 22 08:47:26 2007
New Revision: 127693
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127693
Log:
2007-08-22 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #6 from rguenth at gcc dot gnu dot org 2007-08-22 08:49 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-08-22 09:05 ---
We indeed have a strange chrec here:
(gdb) call debug_tree (left)
negate_expr 0x2afca7c12240
type pointer_type 0x2afca7be9b60
type record_type 0x2afca7be9a90 jpc_enc_pass_t type_0 DI
size
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33137
--- Comment #15 from fxcoudert at gcc dot gnu dot org 2007-08-22 10:00
---
Good news: mingw now includes a standard-conforming implementation of the
printf functions. To quote Brian Dessent:
there is a replacement snprintf named __mingw_snprintf (and similarly for
vsnprintf) to work
--- Comment #6 from rguenth at gcc dot gnu dot org 2007-08-22 10:02 ---
The patch doesn't address the problem it seems. Instead I'll let the
middle-end
decide which arrays are compatible instead of differing to the frontend in
useless_type_conversion_p.
--
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-08-22 10:03 ---
*** Bug 33144 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-08-22 10:03 ---
I just fixed this for 4.3.0 (this is not a regression so it will not be fixed
in 4.2.0).
*** This bug has been marked as a duplicate of 33115 ***
--
pinskia at gcc dot gnu dot org changed:
What
--- Comment #7 from rguenth at gcc dot gnu dot org 2007-08-22 10:07 ---
Is the following valid?
typedef int IA[];
typedef int A5[5];
typedef int A10[10];
A5 array5;
A10 *ap;
void
f (void)
{
int ap;
{
extern IA *ap;
ap = array5;
}
}
The real problem is that the
--- Comment #2 from amonakov at gmail dot com 2007-08-22 10:13 ---
*** scev_probably_wraps_p (tree base, tree s
*** 2969,2977
2032, 2040, 0, 8, ..., but the code is still legal. */
if (chrec_contains_undetermined (base)
! ||
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-08-22 10:29 ---
So we have a NEGATIVE_EXPR of a pointer type that is just wrong. I am going to
look into this further (plus I guess I need to add more checking).
--
pinskia at gcc dot gnu dot org changed:
What
--- Comment #5 from jakub at gcc dot gnu dot org 2007-08-22 10:53 ---
*** Bug 33137 has been marked as a duplicate of this bug. ***
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from jakub at gcc dot gnu dot org 2007-08-22 10:53 ---
*** This bug has been marked as a duplicate of 32573 ***
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-08-22 11:23
---
real, TARGET :: a(0:100)
real, pointer :: p(:)
p = a
print *, lbound(a), ubound(a)
print *, lbound(p), ubound(p)
end
This generates the following code:
struct array1_real4 p;
real4 a[101];
--- Comment #11 from rguenth at gcc dot gnu dot org 2007-08-22 11:43
---
Subject: Bug 33007
Author: rguenth
Date: Wed Aug 22 11:43:32 2007
New Revision: 127701
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127701
Log:
2007-08-22 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #12 from rguenth at gcc dot gnu dot org 2007-08-22 11:44
---
Fixed on the trunk.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Known
--- Comment #13 from rguenth at gcc dot gnu dot org 2007-08-22 11:45
---
Nevermind - only fails on suse-4_2 branch.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot
|dot org
This file:
void t(double foo)
{
puts(foo = 1.0 ? foo : bar);
}
provokes ICE segfault when compiled with
gcc -O -mfpu=maverick -mcpu=ep9312 -mhard-float -c t.c
Confirmed same behaviour in:
- native Debian armel gcc-4.1.3 arm-linux-gnueabi
- native Debian arm gcc-4.1.2 on arm-linux-gnu
-
--- Comment #9 from rask at gcc dot gnu dot org 2007-08-22 12:56 ---
Subject: Bug 32557
Author: rask
Date: Wed Aug 22 12:56:35 2007
New Revision: 127703
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127703
Log:
PR rtl-optimization/32557
* df-problems.c
typedef struct _IO_FILE FILE;
typedef unsigned long potrace_word;
struct potrace_bitmap_s {
int dy;
potrace_word *map;
};
typedef struct potrace_bitmap_s potrace_bitmap_t;
struct bmp_info_s {
unsigned int w;
unsigned int h;
unsigned int bits;
unsigned int comp;
};
typedef
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-08-22 13:07 ---
Created an attachment (id=14094)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14094action=view)
unreduced testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33148
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-08-22 13:07 ---
trunk also fails (but only with the unreduced testcase).
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from joseph at codesourcery dot com 2007-08-22 13:12 ---
Subject: Re: C front-end produces mis-match types in MODIFY_EXPR
On Wed, 22 Aug 2007, rguenth at gcc dot gnu dot org wrote:
Is the following valid?
typedef int IA[];
typedef int A5[5];
typedef int A10[10];
--
hjl at lucon dot org changed:
What|Removed |Added
CC||hjl at lucon dot org
Status|UNCONFIRMED |NEW
--- Comment #7 from jakub at gcc dot gnu dot org 2007-08-22 13:27 ---
Actually, to me this doesn't look like missed-optimization at all.
And you should be happy for 4.2.1 generated bigger code, 4.1.1 optimized out
something it shouldn't.
Below is an stripped down testcase, which works
--- Comment #9 from rguenther at suse dot de 2007-08-22 13:45 ---
Subject: Re: C front-end produces mis-match types in MODIFY_EXPR
On Wed, 22 Aug 2007, joseph at codesourcery dot com wrote:
--- Comment #8 from joseph at codesourcery dot com 2007-08-22 13:12
---
Subject:
--- Comment #8 from jakub at gcc dot gnu dot org 2007-08-22 13:54 ---
Even shorter testcase:
/* { dg-do run } */
/* { dg-options -O2 } */
extern void abort (void);
struct S
{
struct S *a;
int b;
};
#ifdef VAR
struct S t;
#endif
int
main (void)
{
struct S *s = (struct S *) 0,
--- Comment #9 from jakub at gcc dot gnu dot org 2007-08-22 13:56 ---
When struct S is not defined at global scope, but within main, then no matter
if
struct S t; is present or not 4.1/4.2/trunk aborts with -O2.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33136
--- Comment #10 from rguenth at gcc dot gnu dot org 2007-08-22 14:19
---
Probably related to some of the open alias issues of 4.1:
--- Comment #11 from jakub at gcc dot gnu dot org 2007-08-22 14:29 ---
Yeah, PR30708 seems to be stripped down from the same source.
But the stripped down testcase here in c#8 is 4.1/4.2/4.3 regression, not
just 4.1 regression.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33136
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot
|dot org
--- Comment #3 from burnus at gcc dot gnu dot org 2007-08-22 14:41 ---
Note: for a(:) and thus also for p=a(:) the lbound starts at 1 (this is
somewhere hidden in 6.2.2.3 Array sections) - this part works.
Partial patch. Note: This patch is incomplete as one also needs to set the
--- Comment #10 from joseph at codesourcery dot com 2007-08-22 14:52
---
Subject: Re: C front-end produces mis-match types in MODIFY_EXPR
On Wed, 22 Aug 2007, rguenther at suse dot de wrote:
As far as I see we still need to re-instantiate transitiveness
of
--- Comment #11 from rguenther at suse dot de 2007-08-22 15:03 ---
Subject: Re: C front-end produces mis-match types in MODIFY_EXPR
On Wed, 22 Aug 2007, joseph at codesourcery dot com wrote:
Subject: Re: C front-end produces mis-match types in MODIFY_EXPR
On Wed, 22 Aug 2007,
--- Comment #12 from rguenth at gcc dot gnu dot org 2007-08-22 15:15
---
Indeed.
bb 2:
# s_13 = VDEF s_12(D)
s = 0B;
goto bb 4;
bb 4:
# p_1 = PHI s(2), p_5(3)
# VUSE HEAP.5_14(D), SMT.7_15(D)
D.2019_3 = *p_1;
is wrong alias info (from trunk salias dump). The load from
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #6 from manu at gcc dot gnu dot org 2007-08-22 15:44 ---
(In reply to comment #5)
Created an attachment (id=13789)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13789action=view) [edit]
preprocessed testcase
:-( I cannot compile this testcase
[EMAIL
--- Comment #23 from rguenth at gcc dot gnu dot org 2007-08-22 15:52
---
But not with 4.2.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #13 from dberlin at gcc dot gnu dot org 2007-08-22 15:52
---
At least for 4.3, ipa-type-escape is not looking into phi_nodes for address
taking, so we end up returning false for may_alias_p (p, s) because we believe
nobody ever takes the address of s.
IE if
--- Comment #7 from pluto at agmk dot net 2007-08-22 15:54 ---
(In reply to comment #6)
(In reply to comment #5)
Created an attachment (id=13789)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13789action=view) [edit]
preprocessed testcase
:-( I cannot compile this
--- Comment #2 from jakub at gcc dot gnu dot org 2007-08-22 16:20 ---
Testing a fix.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
GCC Version:
gcc (GCC) 4.1.2 20061115 (prerelease) (SUSE Linux)
OS:
Linux s24n160 2.6.18.2-34-default #1 SMP Mon Nov 27 11:46:27 UTC 2006 i686 i686
i386 GNU/Linux
Command-line
gfortran -c -Wall -Wsurprising -I../lib.f/ ../lib.f/bomec_func.f95 -o
../lib.f/bomec_func.o
Error message:
--- Comment #1 from hirmic at web dot de 2007-08-22 16:46 ---
The error is caused by this line of subroutine get_cand:
integer :: i,j,k,ndim=size(cl)
if it is replaced by
integer :: i,j,k,ndim
ndim=size(cl)
then the error doesn't occur.
--
hirmic at web dot de changed:
--- Comment #8 from manu at gcc dot gnu dot org 2007-08-22 16:47 ---
(In reply to comment #7)
(In reply to comment #6)
(In reply to comment #5)
Created an attachment (id=13789)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13789action=view) [edit]
preprocessed testcase
--- Comment #4 from manu at gcc dot gnu dot org 2007-08-22 16:49 ---
Basically, when we reach diff = xlimit; we don't know that xlimit must be
initialized. This may end up in different scenarios depending on the SSA tree
finally generated. In any of those scenarios, not warning is sheer
--- Comment #3 from eweddington at cso dot atmel dot com 2007-08-22 16:57
---
Wouter, please attach the assembly output that you are getting for your test.c
file using 4.1.2. That way we can compare it to other compiler versions.
Thanks,
Eric
--
--- Comment #2 from eweddington at cso dot atmel dot com 2007-08-22 17:09
---
4.3.0 20070817 snapshot generates this for the testcase:
test2:
push r16
push r17
/* prologue: function */
/* frame size = 0 */
mov r16,r24
ldi r24,lo8(10)
call foo
--- Comment #5 from manu at gcc dot gnu dot org 2007-08-22 17:14 ---
(In reply to comment #4)
Just an interesting tidbit.
This testcase exposes a much more difficult/interesting long term problem.
Namely, how should we handle uninitialized warnings for variables which are
exposed
--- Comment #5 from eweddington at cso dot atmel dot com 2007-08-22 17:16
---
Confirmed on the AVR target for 4.3.0 20070817 snapshot.
--
eweddington at cso dot atmel dot com changed:
What|Removed |Added
--- Comment #31 from jason at gcc dot gnu dot org 2007-08-22 17:23 ---
Subject: Bug 29365
Author: jason
Date: Wed Aug 22 17:23:37 2007
New Revision: 127711
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127711
Log:
PR c++/29365
* pt.c (outermost_tinst_level): New
--- Comment #14 from jakub at gcc dot gnu dot org 2007-08-22 17:24 ---
--- ipa-type-escape.c.jj13 2007-08-13 15:11:18.0 +0200
+++ ipa-type-escape.c 2007-08-22 19:21:07.0 +0200
@@ -1704,6 +1704,21 @@ analyze_function (struct cgraph_node *fn
FOR_EACH_BB_FN
--- Comment #2 from burnus at gcc dot gnu dot org 2007-08-22 17:35 ---
I think the problem has been fixed meanwhile; I can reproduce it with 4.1.3
20070521 and 4.2.1 20070705, but not with 4.3.0 20070822.
Using gfortran 4.3 gives the following error message:
integer :: i,j,k,ndim
--- Comment #8 from manu at gcc dot gnu dot org 2007-08-22 17:38 ---
(In reply to comment #6)
(In reply to comment #5)
gcc version 4.1.0 20051106 (experimental)
../t6.c: In function foo:
../t6.c:13: warning: j is used uninitialized in this function
Despite what I said before,
--- Comment #3 from burnus at gcc dot gnu dot org 2007-08-22 17:46 ---
The error is caused by this line of subroutine get_cand:
integer :: i,j,k,ndim=size(cl)
if it is replaced by
integer :: i,j,k,ndim
ndim=size(cl)
then the error doesn't occur.
Note: The first version
--- Comment #17 from manu at gcc dot gnu dot org 2007-08-22 17:48 ---
The warning is not emitted any more in GCC 4.1.2 and I am fairly sure that this
case is covered by gcc.dg/uninit-5.c and gcc.dg/uninit-9.c, so I am tempted to
close this as fixed.
--
manu at gcc dot gnu dot org
--- Comment #3 from eweddington at cso dot atmel dot com 2007-08-22 17:48
---
Bug fixed in 4.3.0 20070817 snapshot.
--
eweddington at cso dot atmel dot com changed:
What|Removed |Added
--- Comment #18 from burnus at gcc dot gnu dot org 2007-08-22 18:07 ---
so I am tempted to close this as fixed.
At least PR 27289 and PR 29479 (marked as duplicate of this PR) seem still to
show the bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5035
--- Comment #9 from pluto at agmk dot net 2007-08-22 18:36 ---
Created an attachment (id=14095)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14095action=view)
preprocessed testcase for 32-bits targets.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32395
--- Comment #19 from manu at gcc dot gnu dot org 2007-08-22 18:47 ---
(In reply to comment #18)
so I am tempted to close this as fixed.
At least PR 27289 and PR 29479 (marked as duplicate of this PR) seem still to
show the bug.
They shouldn't be duplicates then. Here, the
The following code received no diagnostic in 4.0.1, but on 4.2.1 gets:
~/ootbc/personal/ivan$ g++ foo.cc
foo.cc: In instantiation of 'foo2int':
foo.cc:16: instantiated from here
foo.cc:12: error: redefinition of 'void bar(int)'
foo.cc:5: error: 'void bar(int)' previously defined here
Test case:
--- Comment #15 from pinskia at gcc dot gnu dot org 2007-08-22 19:06
---
*** Bug 33150 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-08-22 19:06 ---
Yes and 3.3.x used to produce an error message so this was a regression in
4.0.1 but fixed in 4.0.4, see PR 19809.
*** This bug has been marked as a duplicate of 19809 ***
--
pinskia at gcc dot gnu dot org
--- Comment #1 from martinwguy at yahoo dot it 2007-08-22 19:25 ---
Also present in gcc version 4.2.1 (Debian 4.2.1-4) native compiler on
arm-linux-gnueabi
This bug was originally shown up by three files in lame-3.97; this is the
smallest code that reproduces it.
--
martinwguy at
--- Comment #4 from aldot at gcc dot gnu dot org 2007-08-22 20:07 ---
I'll try to find the time to thing about VN / PRE. Thanks, stevenb, for your
comment.
Please feel free to ping or take this if i time out (as usual)..
--
aldot at gcc dot gnu dot org changed:
What
--- Comment #15 from dberlin at gcc dot gnu dot org 2007-08-22 20:10
---
(In reply to comment #14)
--- ipa-type-escape.c.jj13 2007-08-13 15:11:18.0 +0200
+++ ipa-type-escape.c 2007-08-22 19:21:07.0 +0200
@@ -1704,6 +1704,21 @@ analyze_function (struct
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-08-22 20:17 ---
works again, closing.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #18 from rguenth at gcc dot gnu dot org 2007-08-22 20:23
---
Note alias info is correct:
# signInfo_2 = VDEF signInfo_1(D)
signInfo = {};
# signInfo_3 = VDEF signInfo_2
signInfo.a = 16;
# signInfo_4 = VDEF signInfo_3
signInfo.b = 1;
# signInfo_5 = VDEF
--- Comment #19 from rguenth at gcc dot gnu dot org 2007-08-22 20:25
---
Or more like, the use on the call is missed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30375
--- Comment #6 from rguenth at gcc dot gnu dot org 2007-08-22 20:37 ---
Looks ok on current trunk - after einline:
setparam ()
{
char * * D.2024;
char * D.2025;
char * * ap;
struct shparam * shellparam.0;
bb 2:
shellparam.0_1 = shellparam;
ap_2 ={v} shellparam.0_1-p;
--- Comment #32 from jason at gcc dot gnu dot org 2007-08-22 20:40 ---
Subject: Bug 29365
Author: jason
Date: Wed Aug 22 20:40:30 2007
New Revision: 127716
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127716
Log:
PR c++/29365
* pt.c (outermost_tinst_level): New
--- Comment #5 from aldot at gcc dot gnu dot org 2007-08-22 20:53 ---
Created an attachment (id=14096)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14096action=view)
add enable-intermodule for libgfortran against r127717
Updated patch to allow for configuring libgfortran with
--- Comment #3 from burnus at gcc dot gnu dot org 2007-08-22 21:28 ---
Subject: Bug 33020
Author: burnus
Date: Wed Aug 22 21:28:08 2007
New Revision: 127719
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127719
Log:
2007-08-22 Christopher D. Rickett [EMAIL PROTECTED]
--- Comment #3 from amonakov at gmail dot com 2007-08-22 21:29 ---
With first hunk modified not to delete 'return true', this patch passes
bootstrap with all default languages on ia64 and x86_64 with
--disable-multilib, and passes regtest with no new regressions (all said with
--- Comment #4 from burnus at gcc dot gnu dot org 2007-08-22 21:29 ---
FIXED on the trunk.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #33 from jason at gcc dot gnu dot org 2007-08-22 21:50 ---
Fixed.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
I'm hitting the following on 6 SPEC CPU2006 benchmarks, some with pre_inc
others with pre_modify.
run/build_base_gcc411-base.0001 cat junk.c
extern double cos (double x);
extern double sin (double x);
double
pre_inc_ice (int n)
{
int i;
double sc, ss, arg;
sc = ss = 0.0;
for (i = 0; i
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-08-22 22:32 ---
The splitting of:
(insn 22 80 24 4 t.c:11 (parallel [
(set (reg:DF 123 [ pretmp.23 ])
(float:DF (reg/v:SI 128 [ n ])))
(use (reg:SI 132))
(use (reg:DF 133))
The following four variants of declarations have been tried in a block
data statement with gfortran 4.1.3 and partly also with 4.3.0:
Var. 1:
character(len=3) :: emname(nmin)=(/'bar','baz'/)
common/nmstr/emname
gives this error:
In file test.f90:16
common/nmstr/emname
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-08-22 22:39 ---
What the auto pre-increment pass is doing looks ok from the point of view of
correct RTL.
Before:
(insn 22 21 70 4 t.c:11 (parallel [
(set (reg:DF 123 [ pretmp.23 ])
(float:DF (reg/v:SI
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-08-22 22:41 ---
I think we need a new predicate for this rtl instruction, currently we just
have:
(clobber (match_operand:DF 4 memory_operand =o))
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33151
--- Comment #4 from rakdver at gcc dot gnu dot org 2007-08-22 23:05 ---
Subject: Bug 32949
Author: rakdver
Date: Wed Aug 22 23:05:05 2007
New Revision: 127720
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127720
Log:
2007-08-22 Zdenek Dvorak [EMAIL PROTECTED]
PR
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32643
Executing on host: /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pr32912-1.c -O2 -fno-show-column -lm
-o ./pr32912-1.exe(timeout = 300)
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pr32912-1.c:44: warning: alignment (16)
f
or a exceeds maximum
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-08-22 23:38 ---
The warning comes from:
typedef int __m128i __attribute__ ((__vector_size__ (16)));
__m128i a, b, c, d, e, f;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33153
--- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca 2007-08-22
23:39 ---
Subject: Re: FAIL: gcc.dg/pr32912-[12].c (test for excess errors)
The warning comes from:
typedef int __m128i __attribute__ ((__vector_size__ (16)));
__m128i a, b, c, d, e, f;
Right. Would it be ok
On 22 Aug 2007 23:39:50 -, dave at hiauly1 dot hia dot nrc dot ca
[EMAIL PROTECTED] wrote:
Right. Would it be ok to make this declaration static? That
will avoid the warning.
I think in this case, yes.
Thanks,
Andrew Pinski
--- Comment #3 from pinskia at gmail dot com 2007-08-22 23:42 ---
Subject: Re: FAIL: gcc.dg/pr32912-[12].c (test for excess errors)
On 22 Aug 2007 23:39:50 -, dave at hiauly1 dot hia dot nrc dot ca
[EMAIL PROTECTED] wrote:
Right. Would it be ok to make this declaration static?
Executing on host: /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/
/te
st/gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/execute/20010119-1.c -w -Os
-fno-s
how-column -lm -o /test/gnu/gcc/objdir/gcc/testsuite/gcc/20010119-1.x7
(ti
meout = 300)
/usr/ccs/bin/ld: Unsatisfied symbols:
1 - 100 of 105 matches
Mail list logo
