--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P4
Summary|Empty function with CONTAINS|[4.4 Regression] Em
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2008-11-25 06:23
---
Fixed on trunk
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
Sta
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2008-11-25 05:57
---
Subject: Bug 37803
Author: jvdelisle
Date: Tue Nov 25 05:55:55 2008
New Revision: 142187
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142187
Log:
2008-11-24 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #13 from jvdelisle at gcc dot gnu dot org 2008-11-25 02:35
---
I will regression test on x86-64-gnu-linux and approve if it passes.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37319
--- Comment #10 from jvdelisle at gcc dot gnu dot org 2008-11-25 02:18
---
We did at one time talk about innoculating libgfortran or some such so that the
alignments would be maintained. IIRC We decided not too when it was realized
that we would have to manually adjust every time we ma
--- Comment #3 from howarth at nitro dot med dot uc dot edu 2008-11-25
01:08 ---
Created an attachment (id=16765)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16765&action=view)
inline file for iinline-1.C on powerpc-apple-darwin9
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?
--- Comment #2 from ubizjak at gmail dot com 2008-11-25 00:17 ---
(In reply to comment #1)
> Subject: Bug 38256
Oops, wrong PR number in ChangeLog.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38256
--- Comment #3 from ubizjak at gmail dot com 2008-11-25 00:16 ---
Fixed.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #2 from ubizjak at gmail dot com 2008-11-25 00:16 ---
Subject: Bug 38256
Author: uros
Date: Tue Nov 25 00:12:15 2008
New Revision: 142177
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142177
Log:
PR target/38254
* config/i386/sync.md (memory_barrier_
--- Comment #1 from uros at gcc dot gnu dot org 2008-11-25 00:13 ---
Subject: Bug 38256
Author: uros
Date: Tue Nov 25 00:12:15 2008
New Revision: 142177
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142177
Log:
PR target/38256
* config/i386/sync.md (memory_barri
--- Comment #2 from mikael at gcc dot gnu dot org 2008-11-24 23:12 ---
(In reply to comment #1)
> I'm probably missing something
>
Indeed I was. :'(
FAIL: gfortran.dg/actual_array_result_1.f90
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38252
--- Comment #2 from ubizjak at gmail dot com 2008-11-24 23:07 ---
(In reply to comment #1)
> Created an attachment (id=16763)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16763&action=view) [edit]
> assembly file for g++.dg/ipa/iinline-1.C on powerpc-apple-darwin9
Please attach
--- Comment #1 from mikael at gcc dot gnu dot org 2008-11-24 22:52 ---
confirm
quickfix:
Index: parse.c
===
--- parse.c (révision 142172)
+++ parse.c (copie de travail)
@@ -2323,7 +2323,7 @@ parse_spec (gfc_statemen
--- Comment #1 from ubizjak at gmail dot com 2008-11-24 22:35 ---
OK, we need a full memory clobber, as in sse2_mfence case.
I'm testing this patch:
Index: sync.md
===
--- sync.md (revision 142160)
+++ sync.md (wor
--- Comment #25 from janis at gcc dot gnu dot org 2008-11-24 22:31 ---
I'm still tweaking this, to support dg-timeout and dg-timeout-factor plus
tool-specific default timeouts for gcc, libstdc++-v3, libgomp, and libmudflap.
As for picking up gcc,timeout for the target board I discovered
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
--- Comment #2 from pthaugen at gcc dot gnu dot org 2008-11-24 22:28
---
Working fine after updating my source. Must have been fixed within the past
week.
--
pthaugen at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from vmakarov at redhat dot com 2008-11-24 22:26 ---
This is a latent bug in reload inheritance which IRA triggered. Here
is the important info. r434 was assigned to hard register 2 and r551
was assigned to memory. After insn #1164, r434 and r551 are
synchronized and as
--- Comment #11 from etienne_lorrain at yahoo dot fr 2008-11-24 22:01
---
> URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142157
> Modified: trunk/gcc/dse.c
I am using gcc-core-4.4-20081121.tar.bz2 with ia32-linux (Fedora9) and
applying your patch gives a better assembly, but
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #5 from mikael at gcc dot gnu dot org 2008-11-24 22:00 ---
Fixed on trunk, closing.
--
mikael at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from pault at gcc dot gnu dot org 2008-11-24 21:52 ---
Fixed on trunk and 4.3.
Thanks for the report.
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38119
--- Comment #1 from dje at gcc dot gnu dot org 2008-11-24 21:57 ---
Yep. confirmed.
--
dje at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFI
--- Comment #7 from pault at gcc dot gnu dot org 2008-11-24 21:51 ---
Subject: Bug 38119
Author: pault
Date: Mon Nov 24 21:50:06 2008
New Revision: 142175
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142175
Log:
2008-11-24 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
Noticed the following in 200.sixtrack benchmark from CPU2000.
SUBROUTINE DFACT(N,A,IDIN,IR,IFAIL,DET,JFAIL)
IMPLICIT REAL*8 (A-H,O-Z)
INTEGER IR(9),IPAIRF
REAL*8A(IDIN,9),DET, ZERO, ONE,X,Y,TF
DO 144J = 1, N
--- Comment #10 from pault at gcc dot gnu dot org 2008-11-24 21:38 ---
Fixed on trunk and 4.3.
Thanks for the report.
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38033
--- Comment #9 from pault at gcc dot gnu dot org 2008-11-24 21:37 ---
Subject: Bug 38033
Author: pault
Date: Mon Nov 24 21:36:05 2008
New Revision: 142174
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142174
Log:
2008-11-24 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-11-24 21:03 ---
I think this is expected behavior because you said only that one instantiation
is not hidden and but not in all translational units. You should most likely
use extern template to get the behavior you want.
--
h
--- Comment #12 from ebotcazou at gcc dot gnu dot org 2008-11-24 20:55
---
> OK, I've found the code location in parse.c. Yes, I think the
> above is probably correct. Note, I'm no longer a gfortran
> maintainer, so I can't approve the patch and I haven't tested
> it.
Understood, I'
--- Comment #7 from cgd at google dot com 2008-11-24 20:55 ---
Would it make sense to add a this test code as a test case?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38244
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38257
The following (IMHO valid) code snippet triggers an ICE on mainline when
compiled with "-fopenmp":
==
template void foo()
{
#pragma omp parallel for
for (auto i=0; i<4; ++i) ;
}
==
bug.cc: In function 'void foo()':
--- Comment #10 from pinskia at gcc dot gnu dot org 2008-11-24 20:46
---
*** Bug 38255 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 2008-11-24 20:46 ---
A defect to the C++ standard changed the C++ standard here to be what GCC does.
See http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#45 .
*** This bug has been marked as a duplicate of 359 ***
--
pi
--- Comment #11 from kargl at gcc dot gnu dot org 2008-11-24 20:46 ---
(In reply to comment #10)
> > This should probably be
> >
> > m = gfc_match ("function% %n", name);
> >
> > > if (m == MATCH_YES && strcmp (name, gfc_current_block ()->name) == 0)
> >
> > Otherwise, the 'm ==
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38256
The following invalid code snippet triggers an ICE on mainline:
==
template struct A
{
template operator T();
};
void foo()
{
A<0>().operator auto();
}
==
bug.cc: In function 'void foo()':
bug.cc:8: internal comp
Tested with g++ versions 4.1.2 and 4.3.2, they both fail to reject the
following invalid code:
class E {
int x;
class B { };
class I {
B b;// error: E::B is private
int y;
void f(E* p, int i)
{
p->x = i; // error: E::x is priva
--- Comment #10 from ebotcazou at gcc dot gnu dot org 2008-11-24 20:33
---
> This should probably be
>
> m = gfc_match ("function% %n", name);
>
> > if (m == MATCH_YES && strcmp (name, gfc_current_block ()->name) == 0)
>
> Otherwise, the 'm == MATCH_YES' is using an old value.
--- Comment #9 from kargl at gcc dot gnu dot org 2008-11-24 20:24 ---
(In reply to comment #8)
> > This looks like a missing or wrong initialisation.
>
> Confirmed, it's 'name' in match_deferred_characteristics:
>
> char name[GFC_MAX_SYMBOL_LEN + 1];
> [...]
> /* Set the function l
--- Comment #1 from jan dot kratochvil at redhat dot com 2008-11-24 20:08
---
The excessive item <53> is really still present in Fedora
gcc-c++-4.3.2-7.x86_64 but not in HEAD - 4.4.0 20081124:
<1><2d>: Abbrev Number: 2 (DW_TAG_namespace)
<2e> DW_AT
--- Comment #8 from ebotcazou at gcc dot gnu dot org 2008-11-24 19:59
---
> This looks like a missing or wrong initialisation.
Confirmed, it's 'name' in match_deferred_characteristics:
char name[GFC_MAX_SYMBOL_LEN + 1];
[...]
/* Set the function locus correctly. If we have not fo
--- Comment #9 from kargl at gcc dot gnu dot org 2008-11-24 19:52 ---
(In reply to comment #8)
> I don't mean to be combative, but if EVERYTHING (glibc etc) needs to be build
> with -malign-double, not just fortran programs, then IMHO the flag is useless
> and should be removed. I've
--- Comment #8 from ronis at ronispc dot chem dot mcgill dot ca 2008-11-24
19:36 ---
I don't mean to be combative, but if EVERYTHING (glibc etc) needs to be build
with -malign-double, not just fortran programs, then IMHO the flag is useless
and should be removed. I've been using this
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Known to fail||4.2.4
Known to work||4.4.0 4.3.0
--- Comment #7 from ebotcazou at gcc dot gnu dot org 2008-11-24 19:32
---
Investigating.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
Assigne
--- Comment #7 from pinskia at gcc dot gnu dot org 2008-11-24 19:32 ---
Not just all your modules but libgfortran also and all of glibc etc.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from ebotcazou at gcc dot gnu dot org 2008-11-24 19:32
---
The problem still reproduces on the SPARC as of today. When the compiler is
rebuilt at -O0, it goes away; when decl.c and parser.c are rebuilt at -O2, it
comes back.
--
ebotcazou at gcc dot gnu dot org change
On Linux/ia32 SMP, revision 142160
http://gcc.gnu.org/ml/gcc-patches/2008-11/msg01194.html
causes
FAIL: PR27908 -O3 execution - source compiled test
FAIL: PR27908 -O3 -findirect-dispatch execution - source compiled test
--
Summary: [4.4 Regression] Revision 142160 causes PR27908 -
--- Comment #6 from ronis at ronispc dot chem dot mcgill dot ca 2008-11-24
19:29 ---
It works without -malign-double, but has worked with it for years. I
understand that all modules (even thouse in MY libraries) have to be compiled
with the same flags, but nothing seems to imply that t
--- Comment #5 from kargl at gcc dot gnu dot org 2008-11-24 19:22 ---
(In reply to comment #3)
>
> Now for the more difficult part.
>
> I'll attach a tar file containing a sample program and a makefile. It turns
> out that the problem isn't with the read at all, rather it arises whe
--- Comment #4 from pault at gcc dot gnu dot org 2008-11-24 19:21 ---
Fixed on trunk and 4.3
Thanks for the report
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #3 from pault at gcc dot gnu dot org 2008-11-24 19:14 ---
Subject: Bug 37792
Author: pault
Date: Mon Nov 24 19:13:12 2008
New Revision: 142169
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142169
Log:
2008-11-24 Steven G. Kargl <[EMAIL PROTECTED]>
PR fort
--- Comment #9 from pault at gcc dot gnu dot org 2008-11-24 19:20 ---
Fixed on trunk and 4.3.
Thanks for the report.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #8 from pault at gcc dot gnu dot org 2008-11-24 19:20 ---
Subject: Bug 37926
Author: pault
Date: Mon Nov 24 19:18:39 2008
New Revision: 142171
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142171
Log:
2008-11-24 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #26 from pault at gcc dot gnu dot org 2008-11-24 19:14 ---
Subject: Bug 35681
Author: pault
Date: Mon Nov 24 19:13:12 2008
New Revision: 142169
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142169
Log:
2008-11-24 Steven G. Kargl <[EMAIL PROTECTED]>
PR for
--- Comment #4 from ronis at ronispc dot chem dot mcgill dot ca 2008-11-24
19:08 ---
Created an attachment (id=16764)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16764&action=view)
sample source and makefile
Running make or make DEBUG=x will generate the program. When you run
--- Comment #3 from ronis at ronispc dot chem dot mcgill dot ca 2008-11-24
19:07 ---
OK, here's the information you requested:
gfortran -v:
Target: i686-pc-linux-gnu
Configured with: ../gcc/configure --host=i686-pc-linux-gnu --prefix=/usr
--with-gnu-as --enable-shared --with-gnu-ld --
--- Comment #4 from mikael at gcc dot gnu dot org 2008-11-24 19:06 ---
Subject: Bug 38184
Author: mikael
Date: Mon Nov 24 19:04:34 2008
New Revision: 142168
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142168
Log:
2008-11-24 Mikael Morin <[EMAIL PROTECTED]>
PR fortr
--- Comment #7 from clerman at fuse dot net 2008-11-24 18:54 ---
Subject: Re: problem with contained subprocedure.
Hello,
This appears to be the problem. In any case, I just submitted a new archive
file. I hope this one's correct.
Thanks for your help. Let me know when the fix has be
--- Comment #6 from aph at gcc dot gnu dot org 2008-11-24 18:52 ---
I suggest
jar cf ... to create it, and
zip u ... to add to it
that way you'll get the correct META-INF directory.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38251
--- Comment #1 from howarth at nitro dot med dot uc dot edu 2008-11-24
18:52 ---
Created an attachment (id=16763)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16763&action=view)
assembly file for g++.dg/ipa/iinline-1.C on powerpc-apple-darwin9
--
http://gcc.gnu.org/bugzilla
The test case for g++.dg/ipa/iinline-1.C scan-ipa-dump inline fails on
powerpc-apple-darwin9 as follows in current gcc trunk...
Executing on host:
/sw/src/fink.build/gcc44-4.3.999-20081120/darwin_objdir/gcc/testsuite/g++/../../g++
-B/sw/src/fink.build/gcc44-4.3.999-20081120/darwin_objdir/gcc/tests
--- Comment #6 from clerman at fuse dot net 2008-11-24 18:50 ---
Created an attachment (id=16762)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16762&action=view)
updated, and corrected (I hope) archive
hello,
Sorry for the mixup on the archive. I've attached a new one, bug32_1a.
--- Comment #5 from aph at gcc dot gnu dot org 2008-11-24 18:48 ---
Sure, if you can use zip instead, do that.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38251
--- Comment #4 from ro at techfak dot uni-bielefeld dot de 2008-11-24
18:37 ---
Subject: Re: [4.4 Regression] tools.zip doesn't build on systems with short
command lines
aph at gcc dot gnu dot org writes:
> jar has an update mode that adds files, so I can use that. How long may an
>
--- Comment #17 from edwintorok at gmail dot com 2008-11-24 18:33 ---
Created an attachment (id=16761)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16761&action=view)
drivers/scsi/sd.c
Similar problem with drivers/scsi/sd.c
I can compile the attached preprocessed on x86_64 linux
--- Comment #3 from aph at gcc dot gnu dot org 2008-11-24 18:29 ---
Yes, of course.
jar has an update mode that adds files, so I can use that. How long may an
arglist be?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38251
--- Comment #7 from aleksi dot nurmi at helsinki dot fi 2008-11-24 18:17
---
(In reply to comment #6)
> This is most likely one of the aliasing bugs. Does -fno-strict-aliasing fix
> the issue?
Nope. I did a little research and it seems that -fno-tree-vrp fixes it.
--
http://gcc.g
--- Comment #3 from janis at gcc dot gnu dot org 2008-11-24 18:12 ---
Subject: Bug 38241
Author: janis
Date: Mon Nov 24 18:11:12 2008
New Revision: 142164
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142164
Log:
2008-11-24 Jack Howarth <[EMAIL PROTECTED]>
PR testsui
--- Comment #2 from janis at gcc dot gnu dot org 2008-11-24 18:07 ---
Subject: Bug 38076
Author: janis
Date: Mon Nov 24 18:05:50 2008
New Revision: 142163
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142163
Log:
2008-11-24 Jack Howarth <[EMAIL PROTECTED]>
PR testsui
--- Comment #2 from ro at techfak dot uni-bielefeld dot de 2008-11-24
18:04 ---
Subject: Re: [4.4 Regression] tools.zip doesn't build on systems with short
command lines
aph at gcc dot gnu dot org writes:
> Please try
>
> jar cf ../tools.zip `find . -name .svn -prune -o -type d -pri
This program gives an "Internal Error" pointing at the CONTAINS:
INTEGER FUNCTION test ()
CONTAINS
END FUNCTION test
It works with gfortran 4.3.1. Replacing the FUNCTION by a SUBROUTINE gets rid
of the error. Additionally, this program also works:
FUNCTION test ()
INTEGER :: test
CONTAINS
EN
--- Comment #5 from mkuvyrkov at gcc dot gnu dot org 2008-11-24 17:56
---
Subject: Bug 35018
Author: mkuvyrkov
Date: Mon Nov 24 17:55:35 2008
New Revision: 142161
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142161
Log:
PR target/35018
* config/m68k/m68k.md (
--- Comment #1 from aph at gcc dot gnu dot org 2008-11-24 17:56 ---
Please try
jar cf ../tools.zip `find . -name .svn -prune -o -type d -print`
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38251
As of trunk revision 142086, libgcj doesn't build any longer on Tru64 UNIX
V5.1B:
(cd classes; \
jar cf ../tools.zip `find . -name .svn -prune -o -type f -print`; \
cd ..)
/usr/local/bin/bash: /vol/gnu/bin/jar: Arg list too long
I think such systems still need to be taken into acc
--- Comment #6 from pinskia at gcc dot gnu dot org 2008-11-24 17:46 ---
This is most likely one of the aliasing bugs. Does -fno-strict-aliasing fix
the issue?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #2 from burnus at gcc dot gnu dot org 2008-11-24 17:07 ---
Regarding : Standard Fortran does not allow tabs, as extension gfortran
does. Thus you do not need to change the code (though it does not harm to be
standard compliant - that is what the warning tells you). But one ne
--- Comment #4 from sebpop at gmail dot com 2008-11-24 17:27 ---
Subject: Re: ICE with -O2 -ftree-loop-distribution
The patch looks good. Please test and ask for approval to
commit to trunk on [EMAIL PROTECTED]
Thanks,
Sebastian
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=382
The patch looks good. Please test and ask for approval to
commit to trunk on [EMAIL PROTECTED]
Thanks,
Sebastian
--- Comment #1 from kargl at gcc dot gnu dot org 2008-11-24 17:00 ---
(In reply to comment #0)
> I have some legacy code that I just tried compiling with gfortan (on a
> i686-linux-slackware-12.1 box). There were a large number of warnings of the
> type:
>
> Warning: Nonconforming tab
--- Comment #10 from ubizjak at gmail dot com 2008-11-24 16:59 ---
Fixed.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #9 from uros at gcc dot gnu dot org 2008-11-24 16:57 ---
Subject: Bug 36793
Author: uros
Date: Mon Nov 24 16:55:49 2008
New Revision: 142160
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142160
Log:
* config/i386/i386.md (UNSPECV_CMPXCHG): Rename from
--- Comment #3 from tomby at gcc dot gnu dot org 2008-11-24 16:42 ---
Created an attachment (id=16760)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16760&action=view)
This patch fixes problems
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38250
--- Comment #3 from jan dot kratochvil at redhat dot com 2008-11-24 16:40
---
Created an attachment (id=16759)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16759&action=view)
Check the file manipulations errors.
Thanks Tobias B.,
unlink("mmm.mod") = -1 EPERM (Ope
--- Comment #2 from tomby at gcc dot gnu dot org 2008-11-24 16:39 ---
In tree-loop-distribution.c (generate_memset_zero) can be DR_STEP(dr) NULL. But
it is passed into fold_build2 that expect two non null expressions.
If program flow goes to end: due to goto then temporary variables cr
--
jan dot kratochvil at redhat dot com changed:
What|Removed |Added
Severity|blocker |normal
Summary|Fatal Error: Reading module |Ignored
--- Comment #4 from kargl at gcc dot gnu dot org 2008-11-24 15:32 ---
After removing all of your full path names, I get
REMOVE:kargl[215] gfc4x WinModI.f90 -c -Wall -O3 -ffast-math -funroll-loops
-std=f2003 -fno-backslash -owinmod.o >winmod.xyz
WinModI.f90:68: Error: Can't open include
--- Comment #1 from tomby at gcc dot gnu dot org 2008-11-24 16:31 ---
Created an attachment (id=16758)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16758&action=view)
gcc ICEs on this file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38250
GCC ICEs on folowing code with options -O2 -ftree-loop-distribution
typedef long unsigned int size_t;
typedef struct {
long dat[2];
} gsl_complex_long_double;
typedef struct {
size_t size;
size_t stride;
long *data;
} gsl_vector_complex_long_double;
void gsl_vector_complex_long
I have some legacy code that I just tried compiling with gfortan (on a
i686-linux-slackware-12.1 box). There were a large number of warnings of the
type:
Warning: Nonconforming tab character in column 1 of line 69
(These where lines which started with a single tab instead of 7 spaces).
In addit
--- Comment #5 from burnus at gcc dot gnu dot org 2008-11-24 16:22 ---
To add: There is currently a build problem for the linux 32bit version of the
gfortran nightlies; thus there has been no newer build since about one month.
--
burnus at gcc dot gnu dot org changed:
Wha
--- Comment #2 from burnus at gcc dot gnu dot org 2008-11-24 16:20 ---
The error message looks as if you are mixing a gfortran 4.3 compiled .mod file
with a gfortran 4.4 compiler (or vice versa). While the gfortran 4.3 compiled
*.o/*.so/*.a files are supposed to be compatible with 4.4's
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
OtherBugsDependingO||16989
nThis||
Sta
--- Comment #7 from ubizjak at gmail dot com 2008-11-24 16:00 ---
(In reply to comment #6)
> I've already spoken to one of the GCC maintainers for gentoo - he advised me
> to
> report the issue directly upstream if I could reproduce it without
> gentoo-specific patches (which I have); t
--- Comment #1 from mikael at gcc dot gnu dot org 2008-11-24 15:37 ---
Works for me.
$ /usr/local/bin/gfortran -v
Utilisation des specs internes.
Target: x86_64-unknown-linux-gnu
Configuré avec: ../src/configure --enable-languages=fortran
--enable-maintainer-mode --disable-multilib : (
--- Comment #6 from special at dereferenced dot net 2008-11-24 15:36
---
I've already spoken to one of the GCC maintainers for gentoo - he advised me to
report the issue directly upstream if I could reproduce it without
gentoo-specific patches (which I have); this could be an issue with
--- Comment #3 from mikael at gcc dot gnu dot org 2008-11-24 15:29 ---
(In reply to comment #2)
> This is probably too old:
> GNU Fortran (GCC) 4.4.0 20081021 (experimental) [trunk revision 141258]
>
Definitely, the bug is PR37445, which was fixed on 3rd November.
--
http://gcc.gnu
--- Comment #5 from ubizjak at gmail dot com 2008-11-24 15:29 ---
BTW: You should report this bug to:
with-bugurl=http://bugs.gentoo.org/
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #2 from kargl at gcc dot gnu dot org 2008-11-24 15:19 ---
Your shell script contains items of the form
/home/norm/design/numrec/nrTypeM.f90
which of course doesn't exist so the shell script
aborts when executed.
BTW, if it is fixed on amd64, then it is mostlikely
fixed on
1 - 100 of 127 matches
Mail list logo
