--- Comment #5 from shinwell at gcc dot gnu dot org 2007-01-08 08:33
---
Subject: Bug 29877
Author: shinwell
Date: Mon Jan 8 08:33:42 2007
New Revision: 120571
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=120571
Log:
PR tree-optimization/29877
gcc/
*
On OSX 10.3 PPC with gfortran version 4.3.0 20070105, the following code:
! tests FORALL statements with a mask
program forall_8
real, dimension (5, 5, 5, 5) :: a, b, c, d
a (:, :, :, :) = 4
forall (i = 1:5)
a (i, i, 6 - i, i) = 7
end forall
forall (i = 1:5)
a (i, 6 - i, i, i)
--- Comment #2 from maslowski73 at wp dot pl 2007-01-08 09:48 ---
Oops, the behavior described was caused by the ccache rather than by gcc. I
should go and ask for help there.
--
maslowski73 at wp dot pl changed:
What|Removed |Added
--- Comment #11 from rguenth at gcc dot gnu dot org 2007-01-08 11:20
---
Subject: Bug 23603
Author: rguenth
Date: Mon Jan 8 11:20:00 2007
New Revision: 120578
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=120578
Log:
2007-01-08 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #12 from rguenth at gcc dot gnu dot org 2007-01-08 11:21
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pault at gcc dot gnu dot org 2007-01-08 11:23 ---
There appears to be a double problem here; the segfault, which I can reproduce
by adding more statements in the forall block that sets a, and the incorrect
rendering of the mask logic, according to where the masking
--- Comment #2 from pault at gcc dot gnu dot org 2007-01-08 12:23 ---
logical :: l1(2,2) = reshape ((/.false.,.true.,.true.,.false./), (/2,2/))
integer :: it(2,2) = reshape ((/1,2,3,4/), (/2,2/))
forall (i = 1:2, i 3)
forall (j = 1:2, l1(i,j))
it(i, j) = 0
end
(GCC) 4.3.0 20070108 (experimental)
Copyright (C) 2006 Free Software Foundation, Inc.
GNU Fortran comes with NO WARRANTY, to the extent permitted by law.
You may redistribute copies of GNU Fortran
under the terms of the GNU General Public License.
For more information about these matters, see
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-01-08 12:41
---
The backtrace (on i686-linux) is:
(gdb) where
#0 0x080959b0 in resolve_code (code=0x9f95a68, ns=0x9f93fc8)
at /home/fxcoudert/gfortran_nightbuild/trunk/gcc/fortran/resolve.c:5093
#1 0x0809731d in
The following code:
function f(l)
logical(8) :: f
logical(8) :: l
f = .not.l
end function f
gives:
logic_sim.f90: In function 'f':
logic_sim.f90:1: internal compiler error: in emit_move_insn, at expr.c:3276
Please submit a full bug report,
with preprocessed source if appropriate.
See
When compiled with gfortran (latest 4.3 snapshot), the following code
!==
MODULE kind_mod
IMPLICIT NONE
PRIVATE
INTEGER, PUBLIC, PARAMETER :: I4=SELECTED_INT_KIND(9)
INTEGER, PUBLIC, PARAMETER ::
20070108 (experimental)
/afs/mpa/data/martin/ugcc/libexec/gcc/i686-pc-linux-gnu/4.3.0/cc1 -E
-lang-fortran -traditional-cpp -D_LANGUAGE_FORTRAN -quiet -v linebufmod.F90
-mtune=generic -Wall -o /tmp/ccEpYWVk.f95
ignoring nonexistent directory
/afs/mpa/data/martin/ugcc/lib/gcc/i686-pc-linux-gnu/4.3.0
--- Comment #1 from burnus at gcc dot gnu dot org 2007-01-08 13:23 ---
A look into resolve.c's resolve_where, shows that only EXEC_ASSIGN and not
EXEC_ASSIGN_CALL exists in switch (cnext-op).
Expected: As elemental procedures are also allowed, a case EXEC_ASSIGN_CALL:
has to be added.
--- Comment #1 from burnus at gcc dot gnu dot org 2007-01-08 13:26 ---
0x0044fe6e in resolve_code (code=0xe2f690, ns=0xe2eb60) at
fortran/resolve.c:5097
5097 if (sym-ts.cl-length-expr_type == EXPR_CONSTANT)
(gdb) bt
#1 0x0045042d in resolve_codes
--- Comment #4 from bonzini at gnu dot org 2007-01-08 13:32 ---
This code is undefined as the address of a label will never be 128bytes, it
will either be 4 or 8 bytes.
No, that would be
void *p = dummy;
memcpy (foo, p, sizeof (p));
Here, it's copying code from the address of the
--- Comment #1 from burnus at gcc dot gnu dot org 2007-01-08 13:33 ---
Which version of gfortran did you use and which options?
I cannot reproduce it with 4.3.0 20070108 on x86_64-unknown-linux-gnu.
(Thus it is either platform specific or a newer or older bug than my version
--- Comment #2 from dominiq at lps dot ens dot fr 2007-01-08 13:42 ---
Subject: Re: ICE in LOGICAL(8) functions
Which version of gfortran did you use and which options?
PPC OSX 10.3, version 4.3.0 20070105
Note that I did not see the ICE on x86_64-unknown-linux-gnu
version 4.3.0
--- Comment #2 from marc dot glisse at normalesup dot org 2007-01-08 14:27
---
Created an attachment (id=12870)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12870action=view)
patch to call the renaming function in any namespace
--
--- Comment #3 from patchapp at dberlin dot org 2007-01-08 15:30 ---
Subject: Bug number PR preprocessor/15185
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-01/msg00532.html
--
--- Comment #1 from brett dot albertson at stratech dot com 2007-01-08
16:13 ---
This is now fixed on trunk.
--
brett dot albertson at stratech dot com changed:
What|Removed |Added
--- Comment #3 from kargl at gcc dot gnu dot org 2007-01-08 17:38 ---
Dominique, can you post the output file created with -fdump-tree-originial.
Like Tobias, I can compile this without a problem. Here's my dump
f (l)
{
logical8 __result_f;
__result_f = *l == 0;
return
--- Comment #2 from kargl at gcc dot gnu dot org 2007-01-08 17:42 ---
This compiles with
laptop:kargl[218] gfc4x --version
GNU Fortran 95 (GCC) 4.3.0 20061228 (experimental)
Copyright (C) 2006 Free Software Foundation, Inc.
--
kargl at gcc dot gnu dot org changed:
What
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-01-08 17:43 ---
(In reply to comment #3)
Dominique, can you post the output file created with -fdump-tree-originial.
Like Tobias, I can compile this without a problem. Here's my dump
If yours is the same, we have a target
--- Comment #3 from kargl at gcc dot gnu dot org 2007-01-08 18:55 ---
This is related to an undocumented warning flag. In options.c, gfortran sets
several warnings to on. One of these is
gfc_option.warn_character_truncation = 1;
If I change this to 0, then your code with -Wall
--- Comment #5 from dominiq at lps dot ens dot fr 2007-01-08 19:05 ---
Subject: Re: ICE in LOGICAL(8) functions
Dominique, can you post the output file created with -fdump-tree-originial.
Unfotunately I also got an ICE with -fdump-tree-original.
The crash trace gives:
0 f951
--- Comment #4 from tromey at gcc dot gnu dot org 2007-01-08 19:53 ---
What's the status of this?
The Google assignment situation has been resolved, so I think
the patch submission can move forward...
--
tromey at gcc dot gnu dot org changed:
What|Removed
--- Comment #5 from mbland at google dot com 2007-01-08 19:58 ---
Subject: Re: Warning for absolute or dotted header paths
On 8 Jan 2007 19:53:06 -, tromey at gcc dot gnu dot org
[EMAIL PROTECTED] wrote:
--- Comment #4 from tromey at gcc dot gnu dot org 2007-01-08 19:53
--- Comment #6 from dominiq at lps dot ens dot fr 2007-01-08 20:19 ---
Subject: Re: ICE in LOGICAL(8) functions
I got the same error with OSX 10.4, gcc version 4.2.0 20060617.
I was wrong in my previous mail, -fdump-tree-original gives:
f (l)
{
logical8 __result_f;
__result_f =
--- Comment #7 from sgk at troutmask dot apl dot washington dot edu
2007-01-08 20:34 ---
Subject: Re: ICE in LOGICAL(8) functions
On Mon, Jan 08, 2007 at 08:19:10PM -, dominiq at lps dot ens dot fr wrote:
I got the same error with OSX 10.4, gcc version 4.2.0 20060617.
I was
--- Comment #8 from dominiq at lps dot ens dot fr 2007-01-08 20:49 ---
Subject: Re: ICE in LOGICAL(8) functions
Can you verify that OSX on PPC has logical(8)?
I have tested:
logical(8) :: l1, l2
l1 = .true.
l2 = .false.
print *, l1.neqv.l2, kind(l1.neqv.l2)
end
it returns
T
--- Comment #20 from patchapp at dberlin dot org 2007-01-08 21:25 ---
Subject: Bug number PR7651
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-01/msg00608.html
--
The attached code demonstrates a missed optimization opportunity that
can have a severe impact on code. Here are the timings for the 2 loops
on 2 GHz pentium4-m processor.
laptop:kargl[208] gfc4x -o z -O2 a.f90
laptop:kargl[209] ./z
time 1: 5.0741002E-02
time 2:31.28215
For a pure
--- Comment #1 from kargl at gcc dot gnu dot org 2007-01-08 21:32 ---
Created an attachment (id=12871)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12871action=view)
missed optimization
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30409
--- Comment #2 from kargl at gcc dot gnu dot org 2007-01-08 21:36 ---
Sorry about the long URL, but the code comes from this comp.lang.fortran
thread.
http://groups-beta.google.com/group/comp.lang.fortran/browse_thread/thread/9f9bf1c116dc4b69/712366ef4318e84d#712366ef4318e84d
--
The attached code demostrates a host association bug
with a declaration of an external function in a module.
The incorrect reference can be verified by looking at
the assembler or object files generated.
% gfc gfcbug53.f90
/tmp/ccDZrLiD.o(.text+0x37): In function `__mod2__foo':
: undefined
--- Comment #1 from anlauf at gmx dot de 2007-01-08 22:04 ---
Created an attachment (id=12872)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12872action=view)
Demo code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30410
--- Comment #1 from anlauf at gmx dot de 2007-01-08 22:06 ---
(In reply to comment #0)
It appears that the fix to PR 29624 also fixed this one
properly.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30352
--- Comment #2 from burnus at gcc dot gnu dot org 2007-01-08 22:25 ---
It appears that the fix to PR 29624 also fixed this one properly.
So far I had only managed to cause collateral damage not collateral fixes :-)
--
burnus at gcc dot gnu dot org changed:
What
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
CC||burnus at gcc dot gnu dot
|
--- Comment #3 from janis at gcc dot gnu dot org 2007-01-08 22:41 ---
A regression hunt on powerpc-linux identified the following patch:
http://gcc.gnu.org/viewcvs?view=revrev=99840
r99840 | hubicka | 2005-05-17 16:56:32 + (Tue, 17 May 2005)
--
janis at gcc dot gnu dot
c THIS GFORTRAN PROGRAM IS COMPILED FINE WITH
c real*8 r
c L=Distance(r)
c OR WHITHOUT MODULE Subroutines
C BAT NOT WITH THIS DATA TYPE STRUCTURE.
c
c GCC 4.0 AND 4.1 UBUNTU LINUX 6.10
c
c type Coord
c Real*8 X
c Real*8 Y
c Real*8
Hi,
this code causes an ICE with -O and higher:
% cat cat gfcbug54.f90
module mod_foo
integer :: param
end module mod_foo
program gfcbug54
use mod_foo, only : param
integer, parameter :: n = 5
integer:: j2a (-1-n:n+1), j2i (-1-n:n+1)
if (param 0) j2a = j2i
end program
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-01-08 23:00 ---
*** This bug has been marked as a duplicate of 30391 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-01-08 23:00 ---
*** Bug 30412 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from kargl at gcc dot gnu dot org 2007-01-09 01:26 ---
If you move the module unit above the main program, so that the
module has been compiled by the time the main USEs it, then with
gfortran 4.3.0 I get
laptop:kargl[211] gfc4x -c n.f
n.f: In function 'distance':
--- Comment #2 from mmitchel at gcc dot gnu dot org 2007-01-09 02:47
---
Of course, in C++, A would have a default constructor, since no constructor was
explicitly declared. But, is a Java type not supposed to have a constructor in
this case? If not, why not? That seems
--- Comment #13 from mark at codesourcery dot com 2007-01-09 02:49 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] Bogus ambiguity
with templates + friend
pcarlini at suse dot de wrote:
--- Comment #12 from pcarlini at suse dot de 2007-01-06 15:54 ---
Mark, I'm looking a bit
Shell log:
$ cat t14.c
int main() {
char a,b;
asm volatile (mov%z0 %1, %0 : =r(a) : m(b));
}
$ gcc -o t14 t14.c
t14.c: In function `main':
t14.c:4: internal compiler error: in print_operand, at config/i386/i386.c:7392
Please submit a full bug report,
with preprocessed source if
--- Comment #6 from ghazi at gcc dot gnu dot org 2007-01-09 03:19 ---
(In reply to comment #5)
Kaveh,
As the culprit for both patches, I'll take a look. I had no idea that there
was and 4.1 regressions associated with them. I'll come back to you.
Paul
Paul - I wouldn't say you're
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com
|dot org
--- Comment #1 from dave at hiauly1 dot hia dot nrc dot ca 2007-01-09
03:53 ---
Subject: Re: New: libssp/ssp.c:177: ICE: in cgraph_expand_function, at
cgraphunit.c:973
This bug was seen in revision 120529M. The source contains a modification
to notice_global_symbol:
This bug was
--- Comment #8 from jbuck at gcc dot gnu dot org 2007-01-09 05:18 ---
OK, I'm going to artificially flag this one as known to work for 4.1.1 and
4.1.2 because I'm using that field to do bug status reports for the steering
committee, and we agree that 4.1 documents that HP as isn't
--- Comment #9 from gdr at integrable-solutions dot net 2007-01-09 05:28
---
Subject: Re: [hppa64-hp-hpux11.11] libstdc++-v3 fails to build with HP
assembler
jbuck at gcc dot gnu dot org [EMAIL PROTECTED] writes:
| We might just document that it doesn't work for 4.0.4 assuming we do
--- Comment #8 from jbuck at gcc dot gnu dot org 2007-01-09 05:42 ---
If it is latent but not reproducible it shouldn't be a P1. Downgrading.
--
jbuck at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2007-01-09 06:09
---
The patch for pr30408 appears to fix this. (no ICE)
]$ gfc -Wall -c pr30405.f90
pr30405.f90:2.44:
Integer_1, Integer_2, Integer_3, Integer_List,
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2007-01-09 06:10
---
Marking as duplicate
*** This bug has been marked as a duplicate of 30408 ***
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2007-01-09 06:10
---
*** Bug 30405 has been marked as a duplicate of this bug. ***
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
Configuring and building with
#!/bin/tcsh
/bin/rm -rf *; env CC=/pkgs/gcc-4.2.0-64/bin/gcc ../configure
--build=powerpc64-apple-darwin8.8.0 --host=powerpc64-apple-darwin8.8.0
--target=powerpc64-apple-darwin8.8.0 --with-gmp=/pkgs/gmp-4.2.1-64/
--with-mpfr=/pkgs/gmp-4.2.1-64/
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2007-01-09 06:25
---
Are there a lot of warnings emitted when compiled with -Wall ? or None?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30367
--- Comment #30 from fxcoudert at gcc dot gnu dot org 2007-01-09 07:56
---
(In reply to comment #29)
I think that the configure script should simply check that the Fortran
compiler works and abort if it doesn't.
Tentative patch to do just that is available at
60 matches
Mail list logo
