I think this one's a bit bizarre. (But then again, which bugs aren't? ;-)
$ cat is
isotope* isotope.f90
[EMAIL PROTECTED] Bug9]$ cat isotope.f90
program fred
implicit none
integer,parameter::NoJmax=6000
integer,parameter::MaxTotalJ=100
integer,parameter::ER=14513
real,parameter::Energy
--- Comment #6 from dfranke at gcc dot gnu dot org 2007-12-21 09:47 ---
I can not reproduce the valgrind error, but ...
> module blk1_mod
> implicit none
> integer :: numclusters = 2
> end module blk1_mod
... the ICE goes away if 'numclusters' is defined as a parameter.
Further redu
--- Comment #1 from dfranke at gcc dot gnu dot org 2007-12-21 10:10 ---
Confirmed.
Reduced testcase:
$> cat pr34546.f90
program fred
implicit none
real :: JTEJ(0:100,0:6000,6) = 1.0
real :: pT(1:2, 6) = 2.0
write(*,*) JTEJ(0,1000,:) * pT(1000,:)
end
$> fortran-svn -g -Wall
The following gives an ICE:
print *, NULL()
The program is invalid as the MOLD of NULL([MOLD]) is required in this context
(see F2003, 13.7.88): "If MOLD is absent, the characteristics of the result are
determined by the entity with which the reference is associated. See Table
13.1. MOLD shall
--- Comment #6 from rsandifo at gcc dot gnu dot org 2007-12-21 11:06
---
FWIW, this also fails on mips-linux-gnu (or at least mips64-linux-gnu -mabi=32,
which should be the same thing). The problem is that cshift0's
target-independent function type says that the SHIFT and DIM arguments
--- Comment #5 from dfranke at gcc dot gnu dot org 2007-12-21 11:09 ---
Added a default warning and errors on -std=f*.
Currently regtesting.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from dfranke at gcc dot gnu dot org 2007-12-21 13:01 ---
Index: gfortran.texi
===
--- gfortran.texi (revision 131109)
+++ gfortran.texi (working copy)
@@ -1165,12 +1165,17 @@ zero, and @code{.TRUE.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #10 from dje at watson dot ibm dot com 2007-12-21 14:58 ---
Subject: Re: AIX g++ -D_LARGE_FILES fails to compile #include
> Why is this? -D_LARGE_FILES simply enables LFS. xlC works with and without
> -D_LARGE_FILES. Shouldn't G++ work as effectively as xlC?
You
--- Comment #3 from dfranke at gcc dot gnu dot org 2007-12-21 14:06 ---
Patch looks good to me. Adding DATA-statements to the mashup leads to ICEs
(PR24978), so this is taken care of ;)
Assigned PR to Tobias and added patch URL.
--
dfranke at gcc dot gnu dot org changed:
--- Comment #2 from howarth at nitro dot med dot uc dot edu 2007-12-21
15:11 ---
I just noticed that passing -D__powerpc64__ on the compile line for this test
at -m64 for powerpc-apple-darwin9 allows the missed clobbers seem to be
detected. Shouldn't...
# ifndef __powerpc64__
# define
--- Comment #1 from burnus at gcc dot gnu dot org 2007-12-21 14:12 ---
Patch:
http://gcc.gnu.org/ml/fortran/2007-12/msg00238.html
(I really miss the patch tracker!)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34421
--- Comment #2 from burnus at gcc dot gnu dot org 2007-12-21 14:00 ---
One-week-old, unreviewed patch:
http://gcc.gnu.org/ml/gcc-patches/2007-12/msg00821.html
Error messages for your example:
dimension :: n(3)
1
Error: Dimensions specified for n at (1) after its initialisa
--- Comment #1 from dfranke at gcc dot gnu dot org 2007-12-21 13:45 ---
This seems to be a more general problem:
$> cat pr34514.f90
integer :: n = 4
dimension :: n(3)
parameter (n = 42)
print *, n(2)
end
$> gfortran-svn -g -Wall pr34514.f90 && ./a.out
42
--
dfranke at gcc
--- Comment #4 from dominiq at lps dot ens dot fr 2007-12-21 15:04 ---
With the patch in http://gcc.gnu.org/ml/fortran/2007-12/msg00221.html, the test
case #1 gives:
pr34514.f90:2.14:
dimension :: n(3)
1
Error: Dimensions specified for n at (1) after its initialisation
pr3
--- Comment #3 from howarth at nitro dot med dot uc dot edu 2007-12-21
15:46 ---
Wouldn't something like...
--- 20020919-1.c.org2007-12-21 10:28:40.0 -0500
+++ 20020919-1.c2007-12-21 10:44:27.0 -0500
@@ -41,7 +41,9 @@
|| defined (__POWERPC__) || defi
--- Comment #7 from dje at gcc dot gnu dot org 2007-12-21 14:36 ---
When reload converts the offset address to an indexed address, it re-uses the
same register to which the global variable symbol was assigned.
--
dje at gcc dot gnu dot org changed:
What|Removed
WRT http://gbenson.livejournal.com/2007/12/21/
GCC is being overzealous because of a default that was local to one file was
made global on 2003-10-07, and this changed the behavior of the #if statement
in explow.c's allocate_dynamic_stack_space():
#if defined (STACK_DYNAMIC_OFFSET) || defined (ST
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|dfranke at gcc dot gnu dot |unassigned at gcc dot gnu
|org
--- Comment #13 from dfranke at gcc dot gnu dot org 2007-12-21 17:41
---
Created an attachment (id=14804)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14804&action=view)
set of valid testcases
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24978
--- Comment #12 from dfranke at gcc dot gnu dot org 2007-12-21 17:40
---
Getting rid of the ICEs does not seem to be too difficult. Unfortunately,
internal reworking seems to be necessary to actually solve every aspect of this
PR.
I will attach two sets of testcases; a list of valid D
--- Comment #14 from dfranke at gcc dot gnu dot org 2007-12-21 17:41
---
Created an attachment (id=14805)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14805&action=view)
set of invalid testcases
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24978
--- Comment #8 from ubizjak at gmail dot com 2007-12-21 18:57 ---
Confirmed on K8 at http://gcc.gnu.org/ml/gcc-patches/2007-12/msg01042.html
--
ubizjak at gmail dot com changed:
What|Removed |Added
--
--- Comment #6 from ubizjak at gmail dot com 2007-12-21 19:26 ---
*** Bug 31625 has been marked as a duplicate of this bug. ***
--
ubizjak at gmail dot com changed:
What|Removed |Added
---
--- Comment #1 from ubizjak at gmail dot com 2007-12-21 19:26 ---
*** This bug has been marked as a duplicate of 33082 ***
--
ubizjak at gmail dot com changed:
What|Removed |Added
--
--- Comment #11 from bugzilla-gcc at thewrittenword dot com 2007-12-21
19:14 ---
(In reply to comment #10)
> Subject: Re: AIX g++ -D_LARGE_FILES fails to compile #include
>
> xlC has its own system header files. G++ needs to use the AIX
> system header files with changes fr
--- Comment #2 from tkoenig at gcc dot gnu dot org 2007-12-21 19:49 ---
The problem is with dim.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34540
--- Comment #3 from tkoenig at gcc dot gnu dot org 2007-12-21 20:56 ---
The problem is with the lines
if (dim->expr_type != EXPR_CONSTANT)
{
/* Mark this for later setting the type in gfc_conv_missing_dummy.
*/
dim->representation.length = shift->ts.ki
--- Comment #13 from howarth at nitro dot med dot uc dot edu 2007-12-21
20:45 ---
Reversing the change...
http://gcc.gnu.org/viewcvs/trunk/gcc/builtins.c?r1=108629&r2=108854&pathrev=108854
reduces the failures at -m64 on powerpc-apple-darwin9 from...
Running
/sw/src/fink.build/gcc43-
This is quite amusing (and also, presumably, easy to fix :-)
$ cat cshift-real.f90
program main
implicit none
real, dimension(2,2) :: r
data r /1.0, 2.0, 3.0, 4.0/
print *,cshift(r,shift=2.3,dim=1)
end program main
$ gfortran cshift-real.f90
$
We get the expected error message for eoshi
--- Comment #9 from pault at gcc dot gnu dot org 2007-12-21 21:20 ---
Subject: Bug 34438
Author: pault
Date: Fri Dec 21 21:20:38 2007
New Revision: 131124
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131124
Log:
2007-12-21 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #20 from rask at gcc dot gnu dot org 2007-12-21 21:56 ---
Fixed as of revision 131125 on mainline and not a 4.1/4.2 regression.
--
rask at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2007-12-21 21:07
---
Yes, this is my doing in fixing PR33317. I will look at it tonight.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
---
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |tkoenig at gcc dot gnu dot
|dot org
--- Comment #1 from dfranke at gcc dot gnu dot org 2007-12-21 21:39 ---
> (and also, presumably, easy to fix :-)
check.c (gfc_check_cshift):
/* TODO: more requirements on shift parameter. */
Who knows? :)
--
dfranke at gcc dot gnu dot org changed:
What|Removed
--- Comment #19 from rask at gcc dot gnu dot org 2007-12-21 21:53 ---
Subject: Bug 8835
Author: rask
Date: Fri Dec 21 21:53:23 2007
New Revision: 131125
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131125
Log:
2007-12-13 Andrew Pinski <[EMAIL PROTECTED]>
Rask Ingeman
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-12-21 22:27 ---
You forgot "const" in the second template.
Changing that to:
template < class T, const int & R >
Cat < T, R > :: Cat ( int )
{
}
Allows for this to work.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34550
--- Comment #3 from rask at gcc dot gnu dot org 2007-12-21 22:20 ---
You want something like this in libgcc/config/avr/t-avr to get the 16-bit
versions:
# Extra 16-bit integer functions.
intfuncs16 = _absvXX2 _addvXX3 _subvXX3 _mulvXX3 _negvXX2 _ffsXX2 _clzXX2 \
_ctzXX2 _po
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-12-21 22:57 ---
Should have been fixed by:
http://gcc.gnu.org/ml/gcc-cvs/2007-12/msg00567.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34551
Executing on host: /test/gnu/gcc/objdir/gcc/testsuite/g++/../../g++
-B/test/gnu/
gcc/objdir/gcc/testsuite/g++/../../
/test/gnu/gcc/gcc/gcc/testsuite/g++.dg/overl
oad/arg1.C -nostdinc++
-I/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/
include/hppa64-hp-hpux11.11
-I/test/gnu/gcc/objdir/hppa6
Code below builds w/o issues using earlier gcc and other compilers -
thought you might want to know about the issue.
Thanks in adv, and happy holidays.
template < class T, const int & R >
class Cat {
public:
Cat ( int );
};
template < class T, int & R >
Cat < T, R > :: Cat ( int )
{
}
--- Comment #7 from dfranke at gcc dot gnu dot org 2007-12-21 22:17 ---
*** Bug 24759 has been marked as a duplicate of this bug. ***
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #3 from dfranke at gcc dot gnu dot org 2007-12-21 22:17 ---
Fixed by Jerry. Closing as dupe.
*** This bug has been marked as a duplicate of 34325 ***
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2007-12-21 22:18
---
Patch is testing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34540
--- Comment #12 from dje at gcc dot gnu dot org 2007-12-21 23:23 ---
If AIX G++ users are focussing on 64-bit apps and large files, I'm willing to
switch the default to _LARGE_FILES. The changes would be in
gcc/config/rs6000/aix*.h CPP_SPEC and libstdc++/config/os/aix/os_defines.h,
plus
--- Comment #13 from bugzilla-gcc at thewrittenword dot com 2007-12-21
23:25 ---
(In reply to comment #12)
> If AIX G++ users are focussing on 64-bit apps and large files, I'm willing to
> switch the default to _LARGE_FILES. The changes would be in
> gcc/config/rs6000/aix*.h CPP_SPEC a
--- Comment #6 from danglin at gcc dot gnu dot org 2007-12-21 23:37 ---
Subject: Bug 34525
Author: danglin
Date: Fri Dec 21 23:37:07 2007
New Revision: 131126
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131126
Log:
PR target/34525
* pa.c (legitimize_pic_addres
--- Comment #7 from danglin at gcc dot gnu dot org 2007-12-21 23:58 ---
This problem should now be fixed. I had modified the testcase and
this led me to think I'd killed the ICE ;)
I have to say that the code in the original testcase is probably very
wrong for hppa. Like ia64, functio
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2007-12-22 01:57
---
Subject: Bug 34540
Author: jvdelisle
Date: Sat Dec 22 01:57:07 2007
New Revision: 131133
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131133
Log:
2007-12-21 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2007-12-22 02:00
---
Subject: Bug 34540
Author: jvdelisle
Date: Sat Dec 22 01:59:56 2007
New Revision: 131134
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131134
Log:
2007-12-21 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2007-12-22 02:00
---
Fixed on trunk.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
St
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-12-22 02:38 ---
can you try not building in the source directory and use an building directory?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
The example below copies a float from one location to the next. When compiling
with -O1 or less using 4.1.2, z equals *baz, and the program displays "ok, no
bug." When compiling with -O2 or greater, z doesn't equal *baz, and the
program prints "whoah: 23423.234375 should equal
8523244312281203485
--- Comment #1 from blake dot tregre at gmail dot com 2007-12-22 03:43
---
Created an attachment (id=14806)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14806&action=view)
test code shown in bug report
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34552
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-12-22 05:38 ---
uint32_t* foo = (uint32_t*)&z;
zbuf[3] = ((*foo) & 0x00ffL);
It is obvious you are violating C/C++ aliasing rules which leads to undefined
behavior.
Use either -fno-strict-aliasing, an union, or memcpy.
--- Comment #126 from pinskia at gcc dot gnu dot org 2007-12-22 05:38
---
*** Bug 34552 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2007-12-22 07:37
---
nint_2.f90 is also broken on Cygwin. Should we make that a separate PR?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33595
57 matches
Mail list logo
