--- 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=gcc&view=rev&rev=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=gcc&view=rev&rev=127689
Log:
2007-08-22 Richard Guenther <[EMAIL PROTECTED]>
--- 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
Status|ASSIGNE
--- 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.
--
http://gcc.
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 buil
--- 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=gcc&view=rev&rev=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=gcc&view=rev&rev=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=gcc&view=rev&rev=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)
unit size
align 32 symtab 0 alias set -1 canonical type 0x2afca7be9820 fields
context
pointer_to_this >
--
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 a
--- 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.
--
http://gcc.gnu.org/bugzil
--- 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|R
--- 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 fronten
--- 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)
> ! || chrec_contains_
--- 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|R
--- 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
--- 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=gcc&view=rev&rev=127701
Log:
2007-08-22 Richard Guenther <[EMAIL PROTECTED]>
--- 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 to
--- 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-
--- 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=gcc&view=rev&rev=127703
Log:
PR rtl-optimization/32557
* df-problems.c (df_note_
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 st
--- 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=14094&action=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[1
--
hjl at lucon dot org changed:
What|Removed |Added
CC||hjl at lucon dot org
Status|UNCONFIRMED |NEW
E
--- 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 on
--- 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:
http://gcc.gnu.org/bugzilla/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=4.1&target_milestone=4.1.3&target_milestone=4.1.4&k
--- 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
o
--- 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 useless_type_converison
--- 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.
:
# s_13 = VDEF
s = 0B;
goto ;
:
# p_1 = PHI <&s(2), p_5(3)>
# VUSE
D.2019_3 = *p_1;
is wrong alias info (from trunk salias dump). The load from *p_1 misses
a use of s_13 - or the assignme
--
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=13789&action=view) [edit]
> preprocessed testcase
>
:-( I cannot compile this testcase
[EMAIL PROTECTED]
--- 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
Sta
--- 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 (ipa_type_esca
--- 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=13789&action=view) [edit]
> > preprocessed testcase
> >
>
> :-( I cannot compile t
--- 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
AssignedTo|unass
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:
../lib.f/bom
--- 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=13789&action=view) [edit]
> > > preprocessed te
--- 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 shee
--- 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
--
http://gcc.gnu.org/bugzilla/show_bu
--- 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
> exp
--- 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=gcc&view=rev&rev=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 (this
--- 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 bef
--- 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 versi
--- 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 cha
--- 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=14095&action=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 'foo2':
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:
te
--- 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 chang
--- 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 ya
--- 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|R
--- 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 cgraph
--- 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
S
--- Comment #18 from rguenth at gcc dot gnu dot org 2007-08-22 20:23
---
Note alias info is correct:
# signInfo_2 = VDEF
signInfo = {};
# signInfo_3 = VDEF
signInfo.a = 16;
# signInfo_4 = VDEF
signInfo.b = 1;
# signInfo_5 = VDEF
signInfo.c = 0;
but somehow DSE figu
--- 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;
:
shellparam.0_1 = &shellparam;
ap_2 ={v} shellparam.0_1->p;
goto
--- 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=gcc&view=rev&rev=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=14096&action=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=gcc&view=rev&rev=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
10-days-ol
--- 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
Statu
--- 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 12
--- 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=gcc&view=rev&rev=127720
Log:
2007-08-22 Zdenek Dvorak <[EMAIL PROTECTED]>
PR tr
--
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 a
--- 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:
fo
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-08-23 00:06 ---
This should have been fixed by:
2007-08-22 Richard Guenther <[EMAIL PROTECTED]>
* tree-inline.c (inlinable_function_p): Restore disregarding
inline limits for GNU extern inline functions.
--
h
1 - 100 of 104 matches
Mail list logo
