--- Comment #11 from tbm at cyrius dot com 2007-03-18 09:16 ---
This bug hasn't seen any activity in several months. Any idea who should work
on resolving it?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29478
--- Comment #11 from fxcoudert at gcc dot gnu dot org 2007-03-18 09:36
---
(In reply to comment #10)
Looking at your patch, I have identified one
compile-time hog in complex_pow_ui:
$ time gfortran complex.f90
I identified the same after some more thinking. The fast
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-03-18 09:49 ---
The only reason why cexp is slow on PPC darwin is because the ABI is stupid.
Complex float arguments are passed via the GPR and returned also the same way
instead of via the FPRs. So you will get a transfer of
I just tried to compile recent Linux kernel 2.6.20.3
with GNU C compiler 4.3 snapshot 20070316.
The compiler said
fs/afs/inode.c: In function 'afs_inode_map_status':
fs/afs/inode.c:286: error: type mismatch between an SSA_NAME and its symbol
fs/afs/inode.c:286: error: in statement
--- Comment #1 from dcb314 at hotmail dot com 2007-03-18 10:02 ---
Created an attachment (id=13224)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13224action=view)
C source code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31254
--- Comment #2 from dominiq at lps dot ens dot fr 2007-03-18 10:20 ---
Andrew,
Thanks for the answer. Additional timings for AMD Opteron(tm) Processor 250,
2.4Ghz:
Target: x86_64-unknown-linux-gnu
...
gcc version 4.3.0 20061231 (experimental)
[tocata] test/fortran gfc -O3 sincos.f90
--- Comment #9 from matt at galloway dot me dot uk 2007-03-18 11:01 ---
(In reply to comment #8)
The work around is doing:
get_a().template func2 int();
Which tells the compiler for sure func2 is a template.
Thanks, yeh I figured that out just now. Should it happen
--- Comment #5 from mikael dot morin at tele2 dot fr 2007-03-18 11:58
---
Created an attachment (id=13225)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13225action=view)
a test program that does not fail
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31253
--- Comment #2 from tbm at cyrius dot com 2007-03-18 12:46 ---
Reduced testcase (fails at -O):
struct timespec
{
long tv_sec;
long tv_nsec;
};
struct inode
{
struct timespec i_atime;
struct timespec i_mtime;
};
struct afs_vnode
{
struct inode vfs_inode;
};
static inline
--- Comment #3 from tbm at gcc dot gnu dot org 2007-03-18 12:47 ---
Confirmed.
20070303 works.
20070318 fails.
--
tbm at gcc dot gnu dot org changed:
What|Removed |Added
gcc -c -g -O2 -DDEFAULT_INLINE=PSIM_INLINE_LOCALS
-DWITH_HOST_BYTE_ORDER=LITTLE_ENDIAN -DWITH_SMP=5
-DHAVE_TERMIOS_STRUCTURE -DHAVE_TERMIOS_CLINE -DHAVE_DEVZERO -I.
-I/n/07/mstein/combined-trunk/sim/ppc
-I/n/07/mstein/combined-trunk/sim/ppc/../../include -I../../bfd
--- Comment #1 from mstein at phenix dot rootshell dot be 2007-03-18 13:34
---
Created an attachment (id=13226)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13226action=view)
from src/sim/ppc
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31255
--- Comment #2 from tbm at cyrius dot com 2007-03-18 14:12 ---
I get the following, which would make this the same as PR31254
/n/07/mstein/combined-trunk/sim/ppc/hw_ide.c: In function
âhw_ide_attach_addressâ:
/n/07/mstein/combined-trunk/sim/ppc/hw_ide.c:867: error: type mismatch
--- Comment #3 from tbm at cyrius dot com 2007-03-18 14:16 ---
(In reply to comment #0)
This host gcc was build from SVN revision 123001.
Can you try with the latest revision?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31255
--- Comment #12 from fxcoudert at gcc dot gnu dot org 2007-03-18 14:29
---
Created an attachment (id=13227)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13227action=view)
New patch
New patch, without the compile-time hog for complex.
--
fxcoudert at gcc dot gnu dot org
--- Comment #4 from pault at gcc dot gnu dot org 2007-03-18 15:01 ---
Subject: Bug 31086
Author: pault
Date: Sun Mar 18 15:00:55 2007
New Revision: 123037
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123037
Log:
2007-03-18 Paul Thomas [EMAIL PROTECTED]
PR
--- Comment #11 from pault at gcc dot gnu dot org 2007-03-18 15:01 ---
Subject: Bug 30531
Author: pault
Date: Sun Mar 18 15:00:55 2007
New Revision: 123037
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123037
Log:
2007-03-18 Paul Thomas [EMAIL PROTECTED]
PR
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-03-18 15:04 ---
For some reason, maybe a local patch, I cannot reproduce this on
powerpc-darwin.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31254
--- Comment #11 from hp at gcc dot gnu dot org 2007-03-18 15:43 ---
I see this error for cris-axis-elf with trunk, as late as r123034:
gcc.dg/large-size-array-2.c:6: internal compiler error: in tree_low_cst, at
tree.c:4867
I think the proper action is to re-open the PR, right?
--
hp
--- Comment #4 from prakash at punnoor dot de 2007-03-18 15:58 ---
When specifying -fno-strict-aliasing code works fine with -O3, as well.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31245
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-03-18 16:31 ---
Looks like spill slots are not aligned and has nothing to do with strict
aliasing, if I am reading the assembly correctly.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31245
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-03-18 17:06 ---
Ok, with a cross to spu-elf, I can reproduce the failure.
(gdb) p *pass
$1 = {
name = 0xa5ae00 forwprop,
gate = 0x73fd80 gate_forwprop,
--
pinskia at gcc dot gnu dot org changed:
What
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-03-18 17:08 ---
ssa_name 0x42cedbd0 nothrow var var_decl 0x42c163c0 inode
version 3 in-free-list
(gdb) p debug_generic_expr (stmt)
vnode_1(D)-vfs_inode.i_atime = inode_3-i_mtime
We freed inode_3 for some reason even though
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-03-18 17:14 ---
We had:
inode_4 = vnode_1(D)-vfs_inode;
inode_5 = inode_4;
inode_2 = inode_5;
inode_3 = inode_2;
vnode_1(D)-vfs_inode.i_atime = inode_3-i_mtime;
Now we just get:
vnode_1(D)-vfs_inode.i_atime = inode_3-i_mtime;
--- Comment #8 from pinskia at gcc dot gnu dot org 2007-03-18 17:16 ---
Oh, we prop one side but forget about the other use. GR.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31254
--- Comment #9 from pinskia at gcc dot gnu dot org 2007-03-18 17:18 ---
/* The only case we did not replace all uses this way is if the
use statement is of the form *name = name. */
return rhs != name;
This is not true.
--
--- Comment #10 from pinskia at gcc dot gnu dot org 2007-03-18 17:21
---
An improvement to the loop in the function:
/* Strip away any outer COMPONENT_REF/ARRAY_REF nodes from the LHS.
ADDR_EXPR will not appear on the LHS. */
lhs = GIMPLE_STMT_OPERAND (use_stmt, 0);
while
--- Comment #11 from pinskia at gcc dot gnu dot org 2007-03-18 17:25
---
This is not true.
Because you can have struct = struct and still be valid gimple.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31254
--- Comment #12 from pinskia at gcc dot gnu dot org 2007-03-18 17:36
---
This patch works for me for this testcase, I have not tested it. basicially
the The only case we did not replace all uses is false and if we always
return false there, we don't prop on the right hand side until
--- Comment #12 from pinskia at gcc dot gnu dot org 2007-03-18 17:38
---
Ok, I can reproduce this ICE on a cross to cris-axis-elf, why it works for
powerpc-darwin and spu-elf, I don't know. Does cris normally have
HOST_WIDE_INT as being 32bits?
--
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-03-18 17:49
---
*** Bug 31148 has been marked as a duplicate of this bug. ***
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-03-18 17:49
---
Summary of what other compilers do:
- gfortran-compiled code runs OK without -fbounds-check, issue runtime error
with -fbounds-check
- intel-compiled code runs OK, but segfaults with -check all
-
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-03-18 18:01
---
I'd say the current behaviour is OK. People who want to check their source for
correctness can use either -pedantic or -std=f95/f2003, and they will get the
warning/error. We'd best assume that people who just
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-03-18 18:02
---
I take that back. We're working on a more global change for these things, so
closing this as INVALID.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-03-18 18:07
---
Related to -fbounds-check, isn't it?
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #18 from jvdelisle at gcc dot gnu dot org 2007-03-18 18:14
---
Subject: Bug 31052
Author: jvdelisle
Date: Sun Mar 18 18:13:50 2007
New Revision: 123038
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123038
Log:
2007-03-18 Jerry DeLisle [EMAIL PROTECTED]
PR
--- Comment #19 from jvdelisle at gcc dot gnu dot org 2007-03-18 18:17
---
Subject: Bug 31052
Author: jvdelisle
Date: Sun Mar 18 18:17:24 2007
New Revision: 123039
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123039
Log:
2007-03-18 Jerry DeLisle [EMAIL PROTECTED]
PR
With the following test program gfortran hangs, so also g77, and ifort gives a
severe error, out of memory.
$ cat dev_zero.f
character*20 foo
integer i
open(10,file=/dev/zero)
read(10, '(A)') foo
write(10,'(A)') Hello
rewind(10)
read(10, '(A)') foo
100
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #2 from danglin at gcc dot gnu dot org 2007-03-18 19:13 ---
Subject: Bug 30395
Author: danglin
Date: Sun Mar 18 19:13:17 2007
New Revision: 123040
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123040
Log:
PR testsuite/30395
* gcc.dg/pr16194.c: Provide
--- Comment #3 from danglin at gcc dot gnu dot org 2007-03-18 19:20 ---
Fixed.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #13 from tkoenig at gcc dot gnu dot org 2007-03-18 19:46
---
(In reply to comment #12)
Created an attachment (id=13227)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13227action=view) [edit]
New patch
New patch, without the compile-time hog for complex.
This is
The code comes from http://www.star.le.ac.uk/~cgp/fortran.html
(by Clive Page):
$ cat fcn.f90
Character (len=20) Function Up (string)
Character(len=*) string
Up =
transfer(merge(achar(iachar(transfer(string,x,len(string)))-
In trying to reduce PR 31197, I stumbled across a segfault:
$ cat bar.f90
CHARACTER(LEN=3), DIMENSION(10) :: Z
CHARACTER(LEN=10) :: res
Z(:)=123
write(*,'(10A1)') TRANSPOSE(RESHAPE(Z(:)(2:2),(/5,2/)))
END
...
(gdb) r bar.f90
Starting program: /home/ig25/libexec/gcc/i686-pc-linux-gnu/4.3.0/f951
--- Comment #2 from tkoenig at gcc dot gnu dot org 2007-03-18 22:46 ---
(In reply to comment #1)
Expected result:
1 3 2 4
Gfortran:
1 3 1 3
This is correctly calculated with g95, NAG f95 and sunf95.
gfortran compiles and gives the wrong result and ifort gives an ICE.
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2007-03-18 23:03
---
When creating a testcase for this one, I found we have a similar problem with
character functions:
$ cat a.f90
program test
print *, len(bar(-1))
contains
function bar(i)
integer, intent(in) :: i
--- Comment #13 from hp at gcc dot gnu dot org 2007-03-18 23:04 ---
I'm not sure I understand comment #12, because HOST_WIDE_INT is decided by the
host, not the target, unless need_64bit_hwint=yes but that's *not* set for
cris-*-*; it's a fairly regular 32-bit:er. I saw this with a
--- Comment #24 from dave at hiauly1 dot hia dot nrc dot ca 2007-03-19
00:08 ---
Subject: Re: Bootstrap comparison error at revision 122821
L11:;
D.1641_16 = D.1589_4 + -1;
D.1642_15 = regexp_3(D)-regexp.oneof.regexps[D.1641_16];
ivtmp___31_21 = (long unsigned int)
gfortran ICEs on the following invalid code:
print *, len(bar([2,3,4,5]))
contains
elemental function bar(i)
integer, intent(in) :: i
character(len=i) :: bar
bar =
end function bar
end
We should simply reject i being used in an initialization expr.
--
Summary:
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-03-19 01:50
---
Created an attachment (id=13228)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13228action=view)
Patch for this bug
This is a patch following exactly the very good explanation done in the
mailing-list post
--- Comment #2 from ramana dot radhakrishnan at codito dot com 2007-03-19
02:52 ---
A similar problem also exists on the dataflow branch. Adding Kenneth Zadeck to
the CC.
However fno-tree-lrs has no impact in the df branch as on revision 122955 .
--
ramana dot radhakrishnan at
--- Comment #2 from kkojima at gcc dot gnu dot org 2007-03-19 04:15 ---
Subject: Bug 31022
Author: kkojima
Date: Mon Mar 19 04:14:59 2007
New Revision: 123049
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123049
Log:
PR target/31022
* config/sh/sh.c
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2007-03-19 05:49
---
Found it. In the case of advance=no we are not saving the maximum position
reached to be used by the following write statement. This one is subtle.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31199
61 matches
Mail list logo
