--- Comment #12 from uros at gcc dot gnu dot org 2007-07-03 06:35 ---
Subject: Bug 32176
Author: uros
Date: Tue Jul 3 06:35:05 2007
New Revision: 126245
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126245
Log:
PR middle-end/32176
* gcc.dg/pr32176.c: New test.
--- Comment #13 from ubizjak at gmail dot com 2007-07-03 06:40 ---
Closed as magically fixed (testcase was committed to SVN mainline).
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #130 from ubizjak at gmail dot com 2007-07-03 07:11 ---
(In reply to comment #129)
current gfortran trunk seems to miscompile CP2K at -O2. The affected test is
regtest-ot/C2H4.inp, and the file that is being miscompiled is mulliken.F.
This
is a regression wrt to
--- Comment #6 from spop at gcc dot gnu dot org 2007-07-03 07:14 ---
(In reply to comment #5)
I am not sure about that. I tried the following cases and got distance 1 (and
direction positive) in all of them for load and store to ia pair.
What am I missing?
Distance vectors are
as mentioned in the CP2K PR 29975, current trunk miscompiles CP2K at -O2. the
following illustrates the issue:
MODULE TEST
IMPLICIT NONE
INTEGER, PARAMETER :: dp=KIND(0.0D0)
TYPE mulliken_restraint_type
INTEGER :: ref_count
REAL(KIND = dp) ::
--- Comment #131 from jv244 at cam dot ac dot uk 2007-07-03 07:22 ---
(In reply to comment #130)
(In reply to comment #129)
Could you use bisection to isolate the patch that introduced regression?
unfortunately, I don't have the setup to do so. However, I've filed a simple
testcase
--- Comment #3 from burnus at gcc dot gnu dot org 2007-07-03 08:02 ---
Subject: Bug 20888
Author: burnus
Date: Tue Jul 3 08:02:08 2007
New Revision: 126247
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126247
Log:
2007-07-03 Tobias Burnus [EMAIL PROTECTED]
PR
--- Comment #1 from ubizjak at gmail dot com 2007-07-03 08:31 ---
Confirmed, introduced by revision 129146:
Author: dberlin
Date: Sat Jun 30 14:15:26 2007
New Revision: 126149
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126149
Log:
2007-06-30 Daniel Berlin [EMAIL PROTECTED]
#include algorithm
#include iterator
template typename T
void reverse( T t )
{
unsigned char* bytes = reinterpret_cast unsigned char* ( t );
std::swap_ranges( bytes, bytes + sizeof( T ) / 2,
std::reverse_iterator unsigned char* ( bytes + sizeof( T ) ) );
}
template void reverse(
--- Comment #13 from manu at gcc dot gnu dot org 2007-07-03 09:03 ---
(In reply to comment #12)
[Here's what I sent to gcc-patches as a review of this patch:]
Doing this will certainly break many tools which parse the output of GCC,
In the same way that adding any other output
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-07-03 09:12 ---
I don't see anything obvious in the diff between before FRE and after, likewise
for PRE.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pault at gcc dot gnu dot org 2007-07-03 09:38 ---
Adding Paul as CC.
I'll try to gt to it this afternoon.
Thanks
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32526
Hello,
there seems to be a problem compiling the attached source file with
i686-pc-linux-gnu-gcc:
gcc -m32 -Wp,-MD,drivers/scsi/.atp870u.o.d -nostdinc -isystem
/home/mstein/host-gcc/trunk-2007-07-03/bin/../lib/gcc/i686-pc-linux-gnu/4.3.0/include
-D__KERNEL__ -Iinclude -include
--- Comment #1 from mstein at phenix dot rootshell dot be 2007-07-03 10:03
---
Created an attachment (id=13832)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13832action=view)
preprocessed source file from linux-2.6.20, delta-reduced
--
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
Status|UNCONFIRMED |NEW
--
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
Severity|normal |enhancement
Status|UNCONFIRMED |NEW
--- Comment #3 from ubizjak at gmail dot com 2007-07-03 10:26 ---
(In reply to comment #2)
I don't see anything obvious in the diff between before FRE and after,
likewise
for PRE.
gfortran -O1 -fno-tree-fre pr32604.f90
./a.out
1.00
gfortran -O2 pr32604.f90
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2007-07-03 10:36
---
(In reply to comment #4)
I don't know how one should properly handle these in the front end (without
unneeded initialization of variables), but I reopened the bug and moved it to
the Fortran front end.
They
--
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
--
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 #14 from rguenther at suse dot de 2007-07-03 10:55 ---
Subject: Re: [4.3 Regression] 416.gamess ICEs (in
aff_combination_add_elt, tree-affine.c)
On Tue, 2 Jul 2007, pinskia at gcc dot gnu dot org wrote:
--- Comment #12 from pinskia at gcc dot gnu dot org 2007-07-02
--- Comment #3 from nickc at redhat dot com 2007-07-03 10:59 ---
Subject: Re: [4.3 Regression] gcc -v --help returns no options
for C, C++
Hi Mark,
Nick, would you be able to look into this?
Certainly - I'll get on it today.
Cheers
Nick
--
--- Comment #3 from renard at nospam dot dk 2007-07-03 10:59 ---
I get what I think is the exact same problem:
mm/slab.c:2243: error: expected an SSA_NAME object
mm/slab.c:2243: error: in statement
# VUSE SFT.956 { SFT.956 }
D.17707_131 = node_online_map.bits[0];
mm/slab.c:2243:
$ gcc -mno-cygwin -O2 -c -o libavcodec_static_a-ffv1.o ffv1.i
ffv1.c: In function 'encode_rgb_frame':
ffv1.c:480: warning: assignment makes pointer from integer without a cast
ffv1.c: In function 'decode_plane':
ffv1.c:784: warning: initialization makes pointer from integer without a cast
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-07-03 12:00 ---
Mine.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from jojelino at gmail dot com 2007-07-03 12:01 ---
Created an attachment (id=13833)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13833action=view)
preprocessed file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32607
--- Comment #2 from jojelino at gmail dot com 2007-07-03 12:02 ---
svn revision 126249
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32607
--- Comment #4 from jv244 at cam dot ac dot uk 2007-07-03 12:09 ---
possibly related to
http://gcc.gnu.org/ml/gcc/2007-07/msg00037.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32604
--- Comment #7 from irar at il dot ibm dot com 2007-07-03 12:57 ---
(In reply to comment #6)
Distance vectors are lexicographically positive vectors, that is why you get
the 1
in all these cases. If you want to know which one comes first, you have to
look
at the DR_IS_READ for
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2007-07-03 13:10
---
Reduced testcase:
package P is
Name_Buffer : String (1 .. 100);
Name_Len : Natural;
procedure Proc (S : String);
end P;
package body P is
procedure Proc (S : String) is
N : constant
$ cat iss.cpp
#include iostream
#include sstream
#include cassert
int main()
{
std::istringstream is;
std::string s;
is.str( std::string( 1 ) );
std::cout is.str() std::endl;
is s;
std::cout s std::endl;
assert( s == 1 );
--- Comment #1 from pluto at agmk dot net 2007-07-03 13:15 ---
the testcase needs fix: s/assert( s == 2 );/assert( s == 2);/
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32608
This is a regression from 4.2.0 which happens on both the branch and the trunk.
#2 0x0100363f in htab_clear_slot (htab=0x1649410, slot=0x168c1c0)
at /space/rguenther/src/svn/trunk/libiberty/hashtab.c:722
#3 0x0052c797 in fixed_type_or_null (instance=0x2ae177ead4d0,
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-07-03 13:21 ---
And before finishing reduction, this one at least looks possibly related:
2007-06-15 Mark Mitchell [EMAIL PROTECTED]
* cp-tree.h (DECL_VAR_MARKED_P): Remove.
(DECL_ANON_UNION_VAR_P): New macro.
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-07-03 13:29 ---
Confirmed. Fails at -O. There are lots of similar ACATS failures on the trunk
as well.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-07-03 13:32 ---
Seems to be fixed.
*** This bug has been marked as a duplicate of 32571 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-07-03 13:32 ---
*** Bug 32576 has been marked as a duplicate of this bug. ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from ro at gcc dot gnu dot org 2007-07-03 13:36 ---
Patch here:
http://gcc.gnu.org/ml/gcc-patches/2006-07/msg00533.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28307
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-07-03 13:37 ---
Created an attachment (id=13834)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13834action=view)
testcase (unincluded, unreduced)
Unreduced testcase. A reduced one only fails one out of 5 compiles - it looks
--- Comment #7 from ro at gcc dot gnu dot org 2007-07-03 13:41 ---
Subject: Bug 28307
Author: ro
Date: Tue Jul 3 13:41:00 2007
New Revision: 126253
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126253
Log:
PR target/28307
* gthr-posix.h [SUPPORTS_WEAK
--- Comment #8 from ro at gcc dot gnu dot org 2007-07-03 13:43 ---
Subject: Bug 28307
Author: ro
Date: Tue Jul 3 13:43:01 2007
New Revision: 126254
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126254
Log:
PR target/28307
* gthr-posix.h [SUPPORTS_WEAK
--- Comment #9 from ro at gcc dot gnu dot org 2007-07-03 13:45 ---
Subject: Bug 28307
Author: ro
Date: Tue Jul 3 13:45:21 2007
New Revision: 126255
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126255
Log:
PR target/28307
* gthr-posix.h [SUPPORTS_WEAK
--- Comment #10 from ro at gcc dot gnu dot org 2007-07-03 13:46 ---
Fixed for 4.1.3, 4.2.1, 4.3.
--
ro at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-07-03 13:47 ---
I guess what may happen is that we recurse twice, entering the same instance
into
the htab twice and at the second htab_clear_slot after returning from the first
recursion we hit the assert. At least it looks
--
ro at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |ro at gcc dot gnu dot org
|dot org
seen with current gcc-4_2-branch and trunk, works with current gcc-4_1-branch.
$ gcc-4.2 -Wall -O3 -g -s mycompute_ml-gccbug.c
mycompute_ml-gccbug.c: In function 'matmat':
mycompute_ml-gccbug.c:23: internal compiler error: in
gen_tagged_type_instantiation_die, at dwarf2out.c:12762
Please submit a
--- Comment #2 from ro at gcc dot gnu dot org 2007-07-03 13:48 ---
Fixed by fix for PR target/28307.
--
ro at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from doko at ubuntu dot com 2007-07-03 13:48 ---
Created an attachment (id=13835)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13835action=view)
source code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32610
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-07-03 13:52 ---
Or we just re-alloc the hashtab somewhere inbetween. Anyway, the following
fixes
the problem:
Index: cp/class.c
===
--- cp/class.c (revision 126252)
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-07-03 13:55 ---
I'm testing the fix.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from sebpop at gmail dot com 2007-07-03 13:57 ---
Subject: Re: can't determine dependence (source/destination overlap without
more than size)
On 3 Jul 2007 12:57:33 -, irar at il dot ibm dot com
[EMAIL PROTECTED] wrote:
for (i = 0; i N; i++){
ia[i+1] =
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-07-03 14:07 ---
Created an attachment (id=13836)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13836action=view)
testcase (unreduced)
-O -fno-tree-fre is fine, anything above is borked and eats (slowly) all mem.
--
a F2003 / QOI issue :
REAL :: x,y
character(len=16) :: s1,s2
x=-0.0
y= 0.0
IF (sign(1.0,x).NE.sign(1.0,y)) THEN
write(s1,'(E16.8)') x
write(s2,'(A16)') -0.E+00
IF (s1.NE.s2) CALL ABORT()
ENDIF
END
--
Summary: signed zero
Product: gcc
Version:
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-07-03 14:15 ---
Fixed with r126252.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from jakub at gcc dot gnu dot org 2007-07-03 14:18 ---
The *.pre dump is clearly wrong:
pretmp.53_53 = *order_p_25(D);
bb 7:
# prephitmp.45_125 = PHI storetmp.41_94(20), storetmp.41_92(21)
...
D.1445_69 = pretmp.53_53;
storetmp.41_92 = D.1445_69;
*order_p_25(D)
--- Comment #6 from Ralf dot Wildenhues at gmx dot de 2007-07-03 14:23
---
This and 32595 are probably dupes (32595 is from a slightly patched cln).
--
Ralf dot Wildenhues at gmx dot de changed:
What|Removed |Added
gfortran now incorrectly flags and error on this reduced module -
[dranta:~/tests/gfortran-D] dir% g95 -c files.f90
[dranta:~/tests/gfortran-D] dir% f90 -c files.f90
[dranta:~/tests/gfortran-D] dir% gfortran -c files.f90
files.f90:30.40:
subroutine my_sio_file_read_common(data_lengths,
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-07-03 14:30 ---
*** This bug has been marked as a duplicate of 32609 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from rguenth at gcc dot gnu dot org 2007-07-03 14:30 ---
*** Bug 32595 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32609
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-07-03 14:33 ---
Subject: Bug 30113
Author: rguenth
Date: Tue Jul 3 14:33:16 2007
New Revision: 126259
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126259
Log:
2007-07-03 Richard Guenther [EMAIL PROTECTED]
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-07-03 14:35 ---
This is a regression from 4.0.4. Fixed on the 4.2 branch.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pcarlini at suse dot de 2007-07-03 14:43 ---
You want, e.g., an is.clear() after the first extraction, which leaves the is
stream on eof state.
--
pcarlini at suse dot de changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Component|regression |debug
Keywords|
program main
call something
end
subroutine something
! integer i !correct results from gfortran depend on this statement
character lit*1,line*100
lit(i)=line(i:i)
i=1; n=5; line='PZ0R1'
if (internal(4)) stop
write(*,*) i
contains
logical function internal(j)
--- Comment #6 from dberlin at gcc dot gnu dot org 2007-07-03 15:02 ---
Subject: Re: [4.3 regression] miscompilation at -O2
D.1445_69 = pretmp.53_53;
storetmp.41_92 = D.1445_69;
*order_p_25(D) = D.1445_69;
i_71 = i_2 + 1;
if (i_2 == D.1401_27)
goto bb 11;
else
--- Comment #8 from rguenth at gcc dot gnu dot org 2007-07-03 15:27 ---
Subject: Bug 32609
Author: rguenth
Date: Tue Jul 3 15:26:59 2007
New Revision: 126261
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126261
Log:
2007-07-03 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #9 from rguenth at gcc dot gnu dot org 2007-07-03 15:29 ---
Subject: Bug 32609
Author: rguenth
Date: Tue Jul 3 15:29:19 2007
New Revision: 126262
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126262
Log:
2007-07-03 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #10 from rguenth at gcc dot gnu dot org 2007-07-03 15:29
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from kargl at gcc dot gnu dot org 2007-07-03 16:24 ---
This a regression with respect to 4.2.
The problem is caused by the implicitly typed 'i'
in the statement function 'lit(i) = line(i:i)'
--
kargl at gcc dot gnu dot org changed:
What|Removed
--- Comment #4 from nickc at redhat dot com 2007-07-03 16:26 ---
Hi Brooks,
I do not think that this is a bug, but rather a feature. The command line
options are all still in the --help -v otuput, they are just in different
locations. For example the -Wall option is now listed in
--- Comment #9 from irar at il dot ibm dot com 2007-07-03 16:43 ---
(In reply to comment #8)
I can submit a patch for merging that part of code in trunk if you need
this flag to test if you are in one or the other case.
I guess we can't vectorize the loop in this PR without it,
--- Comment #3 from ro at gcc dot gnu dot org 2007-07-03 17:55 ---
Created an attachment (id=13837)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13837action=view)
process-Posix.s built with gcj 4.2.1 20070611
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32462
--- Comment #4 from ro at gcc dot gnu dot org 2007-07-03 17:56 ---
Created an attachment (id=13838)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13838action=view)
process-Posix.s built with gcj 4.3.0 20070618
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32462
--- Comment #5 from ro at techfak dot uni-bielefeld dot de 2007-07-03
17:57 ---
Subject: Re: [4.3 regression] Linking libgcj.so fails on Solaris 10/x86
I compared the assembler files corresponding to java/.libs/process-Posix.o
and built with both gcj 4.2.1 20070611 and 4.3.0 20070618
doc/invoke.texi says:
Try to format error messages so that they fit on lines of about @var{n}
characters. The default is 72 characters for @command{g++} and 0 for the rest
of
the front ends supported by [EMAIL PROTECTED]
However, cp/cxx-pretty-print.c seems to set the default to 0:
--
dgregor at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dgregor at gcc dot gnu dot
|dot org
--- Comment #4 from burnus at gcc dot gnu dot org 2007-07-03 18:07 ---
FIXED for 4.3/trunk. Not a regression - no backporting to 4.2.x.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #15 from jv244 at cam dot ac dot uk 2007-07-03 18:09 ---
current gfortran trunk is still about a factor of 8 slower than ifort:
gfortran -O3 -ffast-math -ftree-vectorize -march=native test.f90
./a.out
12.98081100010.23998
ifort -xT -O2 test.f90
--- Comment #4 from ro at gcc dot gnu dot org 2007-07-03 18:10 ---
Created an attachment (id=13839)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13839action=view)
runtime.s built with gcj 4.2.1 20070611
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32465
--- Comment #5 from ro at gcc dot gnu dot org 2007-07-03 18:11 ---
Created an attachment (id=13840)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13840action=view)
runtime.s built with gcj 4.3.0 20070618
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32465
--- Comment #6 from ro at gcc dot gnu dot org 2007-07-03 18:11 ---
This is a regression from 4.2.1.
I'm uploading the assembler files corresponding to gnu/gcj/.libs/runtime.o and
built with gcj 4.2.1 20070611 and 4.3.0 20070618 for comparison.
--
ro at gcc dot gnu dot org changed:
--- Comment #13 from jv244 at cam dot ac dot uk 2007-07-03 18:15 ---
looks like current mainline is much slower than ifort (300%) on this testcase
(on core2).
ifort -xT -O2 test.f90
./a.out
0.000E+000
0.2280140 0.2280140
gfortran -O3 -ffast-math
--- Comment #5 from jv244 at cam dot ac dot uk 2007-07-03 18:21 ---
The optimization asked for in this PR is now being performed:
gfortran -O3 -funroll-loops -S test.f90
yields
globl lxy_
.type lxy_, @function
lxy_:
.LFB2:
movl$3, %eax
ret
.LFE2:
--- Comment #3 from jv244 at cam dot ac dot uk 2007-07-03 18:23 ---
this has become an ICE in the meanwhile
test.f90:6: internal compiler error: in gfc_conv_expr_descriptor, at
fortran/trans-array.c:4492
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30871
--- Comment #5 from jv244 at cam dot ac dot uk 2007-07-03 18:26 ---
patch ping ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31198
--- Comment #7 from jv244 at cam dot ac dot uk 2007-07-03 18:27 ---
this has become:
Error: 'd' at (1) already is initialized at (2)
test.f90:0: internal compiler error: Segmentation fault
Please submit a full bug report,
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25057
Output of the gcc command:
Using built-in specs.
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/u
sr/share/info --enable-shared --enable-threads=posix --enable-checking=release
-
-with-system-zlib --enable-__cxa_atexit
--- Comment #8 from jv244 at cam dot ac dot uk 2007-07-03 18:29 ---
change the keyword, as the error is now generated for std=f95 but the code is
rejected for std=f2003
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2007-07-03 18:30
---
(In reply to comment #5)
patch ping ?
I was initially waiting for Lee's patch to be committed, if I have no news from
him I'll modify the patch and submit it again.
--
--- Comment #13 from jv244 at cam dot ac dot uk 2007-07-03 18:33 ---
(In reply to comment #12)
I have a fix that I will submit tonight or tomorrow morning. It also fixes
PR31258 and PR31897.
Paul
is this still correct ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31197
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-07-03 18:33 ---
extern inline is not what you think it is. The extern inline GNU C90
implementes (except for 4.3 with -std=c99/-std=gnu99 which is the standard C99
extern inline) means the function is extern but don't create a
--- Comment #14 from tobi at gcc dot gnu dot org 2007-07-03 18:36 ---
(In reply to comment #13)
(In reply to comment #12)
I have a fix that I will submit tonight or tomorrow morning. It also fixes
PR31258 and PR31897.
Paul
is this still correct ?
Adding Paul, so he can
--- Comment #2 from kris dot van dot hees at oracle dot com 2007-07-03
18:40 ---
Thanks for the explanation - that does explain why -O0 causes an error (since
there is no inlining being done as far as I understand), whereas any other
optimization setting results in success due to
--- Comment #6 from burnus at gcc dot gnu dot org 2007-07-03 19:16 ---
Subject: Bug 30940
Author: burnus
Date: Tue Jul 3 19:16:42 2007
New Revision: 126271
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126271
Log:
2007-07-03 Tobias Burnus [EMAIL PROTECTED]
PR
--- Comment #4 from jv244 at cam dot ac dot uk 2007-07-03 19:30 ---
Now, I get the same timings for the hand-optimised loop and compiled loop if I
use the option:
gfortran -O3 -ffast-math -ftree-vectorize -march=native -funroll-loops
-fvariable-expansion-in-unroller test.f90
whereas
--- Comment #23 from spark at gcc dot gnu dot org 2007-07-03 19:41 ---
This patch:
diff -r 29a7055e69fc gcc/df-scan.c
--- a/gcc/df-scan.c Sun Jun 24 00:16:55 2007 +
+++ b/gcc/df-scan.c Tue Jul 03 12:38:41 2007 -0700
@@ -2763,6 +2763,12 @@ df_def_record_1 (struct
1 - 100 of 187 matches
Mail list logo
