[Bug libfortran/31256] Reading from /dev/zero hangs
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2007-04-13 07:52 --- I thought I would get around to this some day. Its noy high priority. More of an oddity. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31256
Re: [Bug libfortran/31052] [4.2 only] Bad IOSTAT values when readings NAMELISTs past EOF
pinskia at gcc dot gnu dot org wrote: --- Comment #45 from pinskia at gcc dot gnu dot org 2007-04-13 05:32 --- (In reply to comment #44) sixtrack in SPEC CPU 2K started to fail on Mar. 19: And then start passing and then again started to fail again on/around April 1st. HJL when will you please get your dates correct. Now I am confused because I reverted and re-patched and it was tested by spark and sixtrack was then fine. I specifically had this tested before committing the last fix.
[Bug libfortran/31052] [4.2 only] Bad IOSTAT values when readings NAMELISTs past EOF
--- Comment #46 from jvdelisle at verizon dot net 2007-04-13 08:05 --- Subject: Re: [4.2 only] Bad IOSTAT values when readings NAMELISTs past EOF pinskia at gcc dot gnu dot org wrote: --- Comment #45 from pinskia at gcc dot gnu dot org 2007-04-13 05:32 --- (In reply to comment #44) sixtrack in SPEC CPU 2K started to fail on Mar. 19: And then start passing and then again started to fail again on/around April 1st. HJL when will you please get your dates correct. Now I am confused because I reverted and re-patched and it was tested by spark and sixtrack was then fine. I specifically had this tested before committing the last fix. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31052
[Bug fortran/31559] Assigning to an EXTERNAL leads to ICE
-- burnus at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |burnus at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-04-13 08:45:45 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31559
[Bug c++/31545] No warning on missing return in if construct
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-04-13 08:47 --- This was already fixed: [pinskia-laptop:gcc/objdir-noboot/gcc] pinskia% ./cc1plus t5.ii -quiet -fdump-tree-all -W -Wall -O2 t5.cc: In member function 'std::string Test::faultyReturn()': t5.cc:16: warning: control reaches end of non-void function I forgot when it was fixed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31545
[Bug fortran/31551] ice in fold_convert, at fold-const.c:2330
--- Comment #3 from dfranke at gcc dot gnu dot org 2007-04-13 08:48 --- Yes, I observed both crashes (PR31550, PR31331) after the update from 20070308 to 20070412. I can try intermediate versions if this would help? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31551
[Bug fortran/31559] Assigning to an EXTERNAL leads to ICE
--- Comment #1 from patchapp at dberlin dot org 2007-04-13 09:00 --- Subject: Bug number PR31559 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-04/msg00753.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31559
[Bug fortran/31560] New: Array size declaration depended on order of declaration of variable containing size
GNU Fortran (GCC) 4.3.0 20070412 (experimental) Linux 2.4.20-20030701 #2 SMP use ped_class type (ped_data) :: dataset integer, dimension(dataset%maxsiz) :: nobs works but use ped_class integer, dimension(dataset%maxsiz) :: nobs type (ped_data) :: dataset doesn't. ped_data is defined in module ped_class and has an integer slot %maxsiz -- Summary: Array size declaration depended on order of declaration of variable containing size Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: David dot Duffy at qimr dot edu dot au GCC host triplet: linux GCC target triplet: i386 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31560
[Bug tree-optimization/31526] [4.3 regression] ICE in alloc_aux_for_block()
--- Comment #8 from martin at mpa-garching dot mpg dot de 2007-04-13 09:46 --- works for me again, thanks! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31526
[Bug tree-optimization/31526] [4.3 regression] ICE in alloc_aux_for_block()
--- Comment #9 from rguenth at gcc dot gnu dot org 2007-04-13 09:47 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31526
[Bug tree-optimization/31526] [4.3 regression] ICE in alloc_aux_for_block()
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31526
[Bug fortran/31561] New: FAIL: gfortran.dg/vect/vect-4.f90
FAIL: gfortran.dg/vect/vect-4.f90 -O scan-tree-dump-times Alignment of access forced using peeling 1 FAIL: gfortran.dg/vect/vect-4.f90 -O scan-tree-dump-times Vectorizing an unaligned access 1 -- Summary: FAIL: gfortran.dg/vect/vect-4.f90 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: schwab at suse dot de GCC target triplet: ia64-suse-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31561
[Bug fortran/31561] FAIL: gfortran.dg/vect/vect-4.f90
--- Comment #1 from schwab at suse dot de 2007-04-13 10:14 --- Created an attachment (id=13361) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13361action=view) vect-4.f90.097t.vect -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31561
[Bug tree-optimization/21258] Teach VRP to pick up a constant from case label.
--- Comment #9 from rguenth at gcc dot gnu dot org 2007-04-13 10:21 --- Subject: Bug 21258 Author: rguenth Date: Fri Apr 13 10:21:22 2007 New Revision: 123778 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123778 Log: 2007-04-13 Richard Guenther [EMAIL PROTECTED] PR tree-optimization/21258 * tree-vrp.c (compare_case_labels): New helper. (find_switch_asserts): New function. (find_assert_locations): Call it for SWITCH_EXPRs. * gcc.dg/tree-ssa/vrp34.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/vrp34.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vrp.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21258
[Bug tree-optimization/21258] Teach VRP to pick up a constant from case label.
--- Comment #10 from rguenth at gcc dot gnu dot org 2007-04-13 10:23 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21258
[Bug fortran/31562] New: FAIL: gfortran.dg/value_4.f90 -O0 execution test
$ LD_LIBRARY_PATH=../../../powerpc64-suse-linux/libgfortran/.libs gdb
./value_4.exe
GNU gdb 6.6
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as ppc-suse-linux...
Using host libthread_db library /lib/power4/libthread_db.so.1.
(gdb) r
Starting program:
/tmp/cvs/gcc-20070408/Build/gcc/testsuite/gfortran/value_4.exe
Program received signal SIGSEGV, Segmentation fault.
0x10001e94 in c_to_c__ (retval=0xffb8a5c0, c1={r = 4.16185644e-43, i = 1},
c2=0xbf80)
at /tmp/cvs/gcc-20070408/gcc/testsuite/gfortran.dg/value_4.c:40
40if ( c1.r != c2-r ) abort();
(gdb) bt
#0 0x10001e94 in c_to_c__ (retval=0xffb8a5c0, c1={r = 4.16185644e-43, i = 1},
c2=0xbf80)
at /tmp/cvs/gcc-20070408/gcc/testsuite/gfortran.dg/value_4.c:40
#1 0x10001cf4 in MAIN__ ()
at /tmp/cvs/gcc-20070408/gcc/testsuite/gfortran.dg/value_4.f90:81
#2 0x10001f64 in main (argc=1, argv=0xffb8a884)
at ../../../libgfortran/fmain.c:22
(gdb) p c1
$1 = {r = 4.16185644e-43, i = 1}
(gdb) p c2
$2 = (complex *) 0xbf80
(gdb) p *c2
Cannot access memory at address 0xbf80
(gdb) l
35 }
36
37 void
38 c_to_c__(complex *retval, complex c1, complex *c2)
39 {
40if ( c1.r != c2-r ) abort();
41if ( c1.i != c2-i ) abort();
42c1.r = 0.0;
43c1.i = 0.0;
44retval-r = c2-r * 4.0;
(gdb) p $r3
$3 = 4290291136
(gdb) set output-radix 16
Output radix now set to decimal 16, hex 10, octal 20.
(gdb) p $r3
$4 = 0xffb8a5c0
(gdb) p $r4
$5 = 0xffb8a5a4
(gdb) p $r5
$6 = 0xbf80
(gdb) p $r6
$7 = 0x4000
(gdb) p $r7
$8 = 0xffb8a5b0
(gdb) p {complex}$r7
$9 = {r = -1, i = 2}
--
Summary: FAIL: gfortran.dg/value_4.f90 -O0 execution test
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: schwab at suse dot de
GCC target triplet: powerpc-suse-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31562
[Bug tree-optimization/14495] [tree-ssa] Propagate range info into a switch statement
--- Comment #6 from rguenth at gcc dot gnu dot org 2007-04-13 10:31 --- I have a patch to handle the ONE edge case. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-03-05 17:19:18 |2007-04-13 10:31:07 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14495
[Bug fortran/31562] FAIL: gfortran.dg/value_4.f90 -O0 execution test
--- Comment #1 from burnus at gcc dot gnu dot org 2007-04-13 10:52 --- Created an attachment (id=13362) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13362action=view) change struct complex into complex float in gfortran.dg/value_4.c Does the attached test-case patch work? As I know my luck, it won't but it is at least a step into the right direction. (cf. gfortran.dg/c_by_val.c) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31562
[Bug fortran/31562] FAIL: gfortran.dg/value_4.f90 -O0 execution test
--- Comment #2 from schwab at suse dot de 2007-04-13 11:01 --- The modified test works at least with -O0, both 32bit and 64bit. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31562
[Bug fortran/31560] Array size declaration depended on order of declaration of variable containing size
--- Comment #1 from burnus at gcc dot gnu dot org 2007-04-13 11:05 --- Could you post a complete example? I have problems to create one with type (ped_data) :: dataset integer, dimension(dataset%maxsiz) :: nobs as parameter is not allowed in a type specification and using a simple type ped_data integer :: maxsiz = 5 end type ped_data does also not work: integer, dimension(dataset%maxsiz) :: nobs 1 Error: Variable 'dataset' cannot appear in the expression at (1) or in words of NAG f95: DATASET is not permitted in a specification expression -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31560
[Bug fortran/31562] FAIL: gfortran.dg/value_4.f90 -O0 execution test
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-04-13 11:10 --- (In reply to comment #2) The modified test works at least with -O0, both 32bit and 64bit. Thanks for reporting and testing, Andreas! Tobias, your patch is OK, you can go ahead and commit it. PS: a grep indicates that gfortran.dg/f2c_4.c is the only other test that might have the same problem, but I've never seen it fail. I wonder if complex should be passed as struct with f2c calling conventions, or if the f2c calling convention simply hides the bug. Tobias Schlüter probably knows that, adding him to CC list... -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||tobi at gcc dot gnu dot org, ||burnus at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords|wrong-code |patch Last reconfirmed|-00-00 00:00:00 |2007-04-13 11:10:56 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31562
[Bug c++/31545] No warning on missing return in if construct
--- Comment #3 from schreppers at gmail dot com 2007-04-13 11:32 --- Subject: Re: No warning on missing return in if construct Ah ok, great! Hope the fixes arrive soon in darwin too :D On 13 Apr 2007 07:47:05 -, pinskia at gcc dot gnu dot org [EMAIL PROTECTED] wrote: --- Comment #2 from pinskia at gcc dot gnu dot org 2007-04-13 08:47 --- This was already fixed: [pinskia-laptop:gcc/objdir-noboot/gcc] pinskia% ./cc1plus t5.ii -quiet -fdump-tree-all -W -Wall -O2 t5.cc: In member function 'std::string Test::faultyReturn()': t5.cc:16: warning: control reaches end of non-void function I forgot when it was fixed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31545 --- You are receiving this mail because: --- You reported the bug, or are watching the reporter. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31545
[Bug fortran/31551] ice in fold_convert, at fold-const.c:2330
--- Comment #4 from dfranke at gcc dot gnu dot org 2007-04-13 11:34 --- On a different host, 20070316 works as well. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31551
[Bug c++/31545] No warning on missing return in if construct
--- Comment #4 from walter at schreppers dot com 2007-04-13 11:36 --- Apparantly this has been fixed in some newer version of g++. Keep up the good work! -- walter at schreppers dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31545
[Bug fortran/31562] FAIL: gfortran.dg/value_4.f90 -O0 execution test
--- Comment #4 from tobi at gcc dot gnu dot org 2007-04-13 11:43 --- (In reply to comment #3) PS: a grep indicates that gfortran.dg/f2c_4.c is the only other test that might have the same problem, but I've never seen it fail. I wonder if complex should be passed as struct with f2c calling conventions, or if the f2c calling convention simply hides the bug. Tobias Schlüter probably knows that, adding him to CC list... f2c conventions use whatever the system uses as a complex type. How that should be represented in C, I have no idea. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31562
[Bug fortran/31562] FAIL: gfortran.dg/value_4.f90 -O0 execution test
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2007-04-13 11:46 --- (In reply to comment #4) f2c conventions use whatever the system uses as a complex type. How that should be represented in C, I have no idea. OK, so that means gfortran.dg/f2c_4.c should be fixed in the same way gfortran.dg/value_4.c was fixed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31562
[Bug fortran/31562] FAIL: gfortran.dg/value_4.f90 -O0 execution test
--- Comment #6 from burnus at gcc dot gnu dot org 2007-04-13 11:59 --- Subject: Bug 31562 Author: burnus Date: Fri Apr 13 11:59:19 2007 New Revision: 123780 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123780 Log: 2007-04-12 Tobias Burnus [EMAIL PROTECTED] PR fortran/31562 * gfortran.dg/value_4.c: Use GNU extensions for complex instead of a struct. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/value_4.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31562
[Bug libstdc++/31554] stable_partition assumes iterator difference type is always ptrdiff_t
--- Comment #4 from paolo at gcc dot gnu dot org 2007-04-13 12:17 --- Subject: Bug 31554 Author: paolo Date: Fri Apr 13 12:17:21 2007 New Revision: 123783 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123783 Log: 2007-04-13 Paolo Carlini [EMAIL PROTECTED] PR libstdc++/31554 * include/bits/stl_algo.h (stable_partition): Convert __buf.size() to _DistanceType. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/stl_algo.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31554
[Bug libstdc++/31554] stable_partition assumes iterator difference type is always ptrdiff_t
--- Comment #5 from pcarlini at suse dot de 2007-04-13 12:18 --- Fixed. -- pcarlini at suse dot de changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31554
[Bug fortran/31562] FAIL: gfortran.dg/value_4.f90 -O0 execution test
--- Comment #7 from burnus at gcc dot gnu dot org 2007-04-13 12:26 --- Subject: Bug 31562 Author: burnus Date: Fri Apr 13 12:26:09 2007 New Revision: 123784 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123784 Log: 2007-04-13 Tobias Burnus [EMAIL PROTECTED] PR fortran/31562 * gfortran.dg/f2c_4.c: Use GNU extensions for complex instead of a struct. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/f2c_4.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31562
[Bug fortran/31562] FAIL: gfortran.dg/value_4.f90 -O0 execution test
--- Comment #8 from burnus at gcc dot gnu dot org 2007-04-13 12:37 --- Close as FIXED, if it reappears, please reopen it. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31562
[Bug fortran/31561] FAIL: gfortran.dg/vect/vect-4.f90
--- Comment #2 from burnus at gcc dot gnu dot org 2007-04-13 12:51 ---
The procedure does:
vector Y = vector Y + scalar A * vector X
Source code (compiled with the default testsuite options -O2 -ftree-vectorize
-ftree-vectorizer-verbose -fdump-tree-vect-stats):
SUBROUTINE SAXPY(X, Y, A)
DIMENSION X(64), Y(64)
Y = Y + A * X
END
And the following items are checked:
! { dg-final { scan-tree-dump-times vectorized 1 loops 1 vect } }
! { dg-final { scan-tree-dump-times Alignment of access forced using peeling
1 vect } }
! { dg-final { scan-tree-dump-times Vectorizing an unaligned access 1 vect
} }
! { dg-final { scan-tree-dump-times accesses have the same alignment. 1
vect } }
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31561
[Bug fortran/31561] FAIL: gfortran.dg/vect/vect-4.f90
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-04-13 13:13
---
(In reply to comment #2)
! { dg-final { scan-tree-dump-times vectorized 1 loops 1 vect } }
! { dg-final { scan-tree-dump-times Alignment of access forced using peeling
1 vect } }
! { dg-final { scan-tree-dump-times Vectorizing an unaligned access 1 vect
} }
! { dg-final { scan-tree-dump-times accesses have the same alignment. 1
vect } }
I think the only thing that really matters is that the loop is vectorized. I
don't think the alignment details are important checking, even on platforms
where they are relevant. So we should remove all scan-tree-dump-times except
the first one, I guess.
I'm adding Ira and Dorit to the CC list, as they wrote and modified the
original test. Ira, Dorit, I'm not sure how to proceed here, do you agree with
the paragraph above about what is the right thing to do?
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
CC||irar at il dot ibm dot com,
||dorit at il dot ibm dot com
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2007-04-13 13:13:33
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31561
[Bug fortran/31550] [regression] f951: segfault in fold-const.c:1963
--- Comment #5 from pault at gcc dot gnu dot org 2007-04-13 13:32 --- Daniel, This turns out to be a problem of carts and horses. I very rapidly found that I could fix this problem and break everything else by reversing the order of the gfc_derived_types list. After much head scratching, I found that derived types were picking up component derived types from contained procedures or, still worse, interfaces. The patch below fixes this by copying derived type declarations in the same namespace first, followed by other namespaces afterwards. I am not entirely convinced that this is the whole story. It fixes the problem and regtests fine but. just give me 24 hours to dwell on it:) If you are in a position to check that this fixes 31551, I would be grateful that you try. Paul Index: gcc/fortran/trans-types.c === *** gcc/fortran/trans-types.c (révision 123693) --- gcc/fortran/trans-types.c (copie de travail) *** gfc_get_derived_type (gfc_symbol * deriv *** 1563,1569 /* Add this backend_decl to all the other, equal derived types. */ for (dt = gfc_derived_types; dt; dt = dt-next) ! copy_dt_decls_ifequal (derived, dt-derived); return derived-backend_decl; } --- 1563,1574 /* Add this backend_decl to all the other, equal derived types. */ for (dt = gfc_derived_types; dt; dt = dt-next) ! if (derived-ns == dt-derived-ns) ! copy_dt_decls_ifequal (derived, dt-derived); ! ! for (dt = gfc_derived_types; dt; dt = dt-next) ! if (derived-ns != dt-derived-ns) ! copy_dt_decls_ifequal (derived, dt-derived); return derived-backend_decl; } -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2007-04-12 18:52:04 |2007-04-13 13:32:31 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31550
[Bug fortran/31563] New: An Error is incorrectly generated for hex and octal data
When trying to build a program with gfortran, these errors were generated. Absoft f90 and g95 are happy with the program - [dranta:~/junk] dir% gfortran -o mask mask.f90 mask.f90:3.30: data msk4/o'377'/ 1 Error: Arithmetic overflow converting INTEGER(8) to INTEGER(4) at (1) mask.f90:2.27: data msk1/x'8000'/ 1 Error: Arithmetic overflow converting INTEGER(8) to INTEGER(4) at (1) mask.f90:4.11: msk1=x'8000' 1 Error: Arithmetic overflow converting INTEGER(8) to INTEGER(4) at (1) mask.f90:5.11: msk4=o'377' 1 Error: Arithmetic overflow converting INTEGER(8) to INTEGER(4) at (1) [dranta:~/junk] dir% g95 -o mask mask.f90 [dranta:~/junk] dir% f90 -o mask mask.f90 [dranta:~/junk] dir% gfortran --v Using built-in specs. Target: powerpc-apple-darwin8.9.0 Configured with: ../gcc/configure --disable-multilib --prefix=/usr/local/gfortran --enable-languages=c,fortran Thread model: posix gcc version 4.3.0 20070412 (experimental) [dranta:~/junk] dir% cat mask.f90 INTEGER *4 msk1, msk4 data msk1/x'8000'/ data msk4/o'377'/ msk1=x'8000' msk4=o'377' end -- Summary: An Error is incorrectly generated for hex and octal data Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dir at lanl dot gov GCC host triplet: Darwin 8.9.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31563
[Bug fortran/31550] [regression] f951: segfault in fold-const.c:1963
--- Comment #6 from patchapp at dberlin dot org 2007-04-13 14:21 --- Subject: Bug number PR31550 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-04/msg00788.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31550
[Bug target/30222] [4.2 Regression] gcc.target/i386/vectorize1.c ICEs
--- Comment #5 from jsm28 at gcc dot gnu dot org 2007-04-13 14:24 --- Confirmed, a regression in 4.2. -- jsm28 at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-04-13 14:24:55 date|| Summary|gcc.target/i386/vectorize1.c|[4.2 Regression] |ICEs|gcc.target/i386/vectorize1.c ||ICEs Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30222
[Bug c/31537] duplicate weakref emitted with IMA
--- Comment #1 from aldot at gcc dot gnu dot org 2007-04-13 14:32 --- Created an attachment (id=13363) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13363action=view) inaccurate bypass Not a patch. By marking ultimate target's asm_written_flag and bailing if it was already set, one could bypass this, perhaps.. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31537
[Bug fortran/18937] quadratic behaviour with many label spaghetti code
--- Comment #15 from tobi at gcc dot gnu dot org 2007-04-13 14:48 --- Subject: Bug 18937 Author: tobi Date: Fri Apr 13 14:48:08 2007 New Revision: 123789 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123789 Log: PR fortran/18937 fortran/ * resolve.c: Include obstack.h and bitmap.h. New variable labels_obstack. (code_stack): Add tail and reachable_labels fields. (reachable_labels): New function. (resolve_branch): Rework to use new fields in code_stack. (resolve_code): Call reachable_labels. (resolve_codes): Allocate and free labels_obstack. testsuite/ * gfortran.dg/goto_2.f90: New. * gfortran.dg/goto_3.f90: New. * gfortran.dg/pr17708.f90: Rename to ... * gfortran.dg/goto_4.f90: ... this, add comment pointing to PR. Added: trunk/gcc/testsuite/gfortran.dg/goto_2.f90 trunk/gcc/testsuite/gfortran.dg/goto_3.f90 trunk/gcc/testsuite/gfortran.dg/goto_4.f90 - copied, changed from r123784, trunk/gcc/testsuite/gfortran.dg/pr17708.f90 Removed: trunk/gcc/testsuite/gfortran.dg/pr17708.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18937
[Bug fortran/31266] Spurious(?) warning about character truncation
--- Comment #5 from tobi at gcc dot gnu dot org 2007-04-13 14:50 --- Fixed. -- tobi at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31266
[Bug fortran/31250] Initialization expr as constant character length rejected
--- Comment #4 from tobi at gcc dot gnu dot org 2007-04-13 14:51 --- Fixed. -- tobi at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31250
[Bug fortran/31471] gfortran does not detect a labeled FORALL with an unlabeled END FORALL
--- Comment #5 from tobi at gcc dot gnu dot org 2007-04-13 14:54 --- Fixed. The commit message is here: http://gcc.gnu.org/ml/gcc-cvs/2007-04/msg00370.html -- tobi at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31471
[Bug fortran/31563] Arithmetic overflow and BOZ
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-04-13 15:02 --- The code you report is invalid, and gfortran is right to throw an error. If you really want it to compile, please use -fno-range-check. (see http://gcc.gnu.org/ml/fortran/2007-04/msg00123.html for details and a proposed patch to mention -fno-range-check in that error message) -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Alias||bozoverflow Status|UNCONFIRMED |RESOLVED GCC host triplet|Darwin 8.9.0| Resolution||INVALID Summary|An Error is incorrectly |Arithmetic overflow and BOZ |generated for hex and octal | |data| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31563
[Bug fortran/31553] incorrect processing of formatted character output
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2007-04-13 15:04 --- Closing according to comments. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31553
[Bug fortran/29899] [Segfault] Fortran entry point caught from C function
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-04-13 15:06 --- Closing as we have no way to reproduce the bug. Please reopen the PR with more information when you can. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29899
[Bug fortran/31563] Arithmetic overflow and BOZ
--- Comment #2 from burnus at gcc dot gnu dot org 2007-04-13 15:08 --- Well, gfortran is right: x'8000' = 2147483648 2147483647 = huge(msk1) and o'377' = 4278190080 2147483647 = huge(msk4) Thus the BOZ numbers are too big for the 4-byte variables. The other compilers simply allow the variable to overflow, which gfortran does if one uses the option -fno-range-check. With that option the variables get initialized to: msk1 = -2147483648 msk4 = -16777216 Therefore, - If you don't want the overflows, check your program and use, e.g., 8-byte variables - If the overflows are on purpose, use the option -fno-range-check PS: I have a patch awaiting review which mentions the -fno-range-check option in the error message. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31563
[Bug fortran/31515] internal compiler segmentation fault
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31515
[Bug fortran/31546] add --enable-intermodule
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-04-13 15:12 --- (In reply to comment #0) This creates a smaller binary and may also create a faster binary. The former is the main motivation from my POV. Do you have figures to justify these two claims? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31546
[Bug fortran/18937] quadratic behaviour with many label spaghetti code
--- Comment #16 from tobi at gcc dot gnu dot org 2007-04-13 15:16 --- Fixed. -- tobi at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18937
[Bug fortran/31250] Initialization expr as constant character length rejected
-- tobi at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31250
[Bug fortran/31266] Spurious(?) warning about character truncation
-- tobi at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31266
[Bug fortran/31471] gfortran does not detect a labeled FORALL with an unlabeled END FORALL
-- tobi at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31471
[Bug fortran/31519] spurious ICE messages when module does not compile
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-04-13 15:19 --- (In reply to comment #3) It appears that spurious ICE messages are a general problem with GCC. Well, it's true that an ICE on invalid code *and* after a sensible error message has been emitted does not have too large an impact for users. I can reproduce the ICE on minw32, but when I run f951 directly (instead of letting the driver calling it) it doesn't ICE (even with the same options as the driver passes to it). So, I can post a backtrace nor investigate :( -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-04-13 15:19:32 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31519
[Bug fortran/31519] spurious ICE messages when module does not compile
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |minor GCC host triplet||i386-pc-mingw32 Keywords||error-recovery, ice-on- ||invalid-code Last reconfirmed|2007-04-13 15:19:32 |2007-04-13 15:20:21 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31519
[Bug fortran/31560] Array size declaration depended on order of declaration of variable containing size
--- Comment #2 from tobi at gcc dot gnu dot org 2007-04-13 15:22 --- (In reply to comment #0) GNU Fortran (GCC) 4.3.0 20070412 (experimental) Linux 2.4.20-20030701 #2 SMP use ped_class type (ped_data) :: dataset integer, dimension(dataset%maxsiz) :: nobs works but use ped_class integer, dimension(dataset%maxsiz) :: nobs type (ped_data) :: dataset doesn't. If I understand you correctly, what you're trying to do is invalid. You may only reference previously declared objects in data object declarations. In your second example dataset is referenced before it is declared. Please provide a complete testcase, and if the problem is indeed the order of declarations please tell us where you think I'm wrong. -- tobi at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31560
[Bug libfortran/31532] INQUIRE(...,POSITION=...) not standard conforming
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-04-13 15:24 --- (In reply to comment #0) If the file has been repositioned since the connection, the scalar-default-char-variable is assigned a processor-dependent value, which shall not be REWIND unless the file is positioned at its initial point and shall not be APPEND unless the file is positioned so that its endfile record is the next record or at its terminal point if it has no endfile record. I'm not too skilled at reading normative language, but I guess it only says that if we're not at endfile, if can't be APPEND. It doesn't say that when we're at enfile, it shall be APPEND. Of course, there also is the quality of implementation issue to consider. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31532
[Bug fortran/31563] Arithmetic overflow and BOZ
--- Comment #3 from dir at lanl dot gov 2007-04-13 15:28 --- I do not see why you say the numbers over flow - g95 gives exactly the correct answer when I print them out [dranta:~/junk] dir% g95 -o mask mask.f90 [dranta:~/junk] dir% mask 8000 FF00 [dranta:~/junk] dir% cat mask.f90 INTEGER *4 msk1, msk4 data msk1/x'8000'/ data msk4/o'377'/ msk1=x'8000' msk4=o'377' PRINT '(Z8)', msk1 PRINT '(Z8)', msk4 end -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31563
[Bug fortran/31563] Arithmetic overflow and BOZ
--- Comment #4 from dir at lanl dot gov 2007-04-13 15:52 --- With Hex and octal numbers - there is no overflow as long as there are enough bits - that is why g95 and Absoft do not complain. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31563
[Bug tree-optimization/30398] memmove for string operations
--- Comment #3 from tobi at gcc dot gnu dot org 2007-04-13 16:27 ---
With FX' patch to inline REPEAT (see PR31304), we are left with this as final
dump after a -O compilation:
;; Function MAIN__ (MAIN__)
MAIN__ ()
{
char[1:] * pstr.1;
char s[1:1];
char c[1:2];
void * D.1004;
bb 2:
_gfortran_set_std (68, 127, 0, 0, 0);
s[1]{lb: 1 sz: 1} = 97;
D.1004 = _gfortran_internal_malloc (2);
pstr.1 = (char[1:] *) D.1004;
__builtin_memcpy ((char *) pstr.1, s, 1);
__builtin_memcpy (pstr.1 + 1B, s, 1);
__builtin_memmove (c, pstr.1, 2);
_gfortran_internal_free (pstr.1);
return;
}
The call to memmove makes it way into the assembly, even though pstr and c
can't alias. This is now an optimizer issue, moving to component
tree-optimization, as the tree-ssa optimizers should be able to eliminate the
memmove in favor of a memcpy. Or even better, get rid of the whole copying
business and predict the correct results. If that's possible it would be great
to have a way to get rid of the then unnecessary temporary allocation.
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
CC||tobi at gcc dot gnu dot org,
||fxcoudert at gcc dot gnu dot
||org
Component|fortran |tree-optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30398
[Bug c++/31027] [4.1/4.2/4.3 regression] Compiler segfaults in simple virtual inheritance situation
--- Comment #6 from v dot lesk at ic dot ac dot uk 2007-04-13 16:51 --- I have verified that this bug also occurs on g++ 4.0.3. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31027
[Bug fortran/31550] [regression] f951: segfault in fold-const.c:1963
--- Comment #7 from pault at gcc dot gnu dot org 2007-04-13 17:02 --- Subject: Bug 31550 Author: pault Date: Fri Apr 13 17:01:36 2007 New Revision: 123791 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123791 Log: 2007-04-13 Paul Thomas [EMAIL PROTECTED] PR fortran/31550 * trans-types.c (copy_dt_decls_ifequal): Do not get pointer derived type components. 2007-04-13 Paul Thomas [EMAIL PROTECTED] PR fortran/31550 * gfortran.dg/used_types_16.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/used_types_16.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-types.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31550
[Bug fortran/31550] [regression] f951: segfault in fold-const.c:1963
--- Comment #8 from pault at gcc dot gnu dot org 2007-04-13 17:03 --- Fixed. Phew! Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31550
[Bug fortran/31551] ice in fold_convert, at fold-const.c:2330
--- Comment #5 from pault at gcc dot gnu dot org 2007-04-13 17:05 --- Daniel reports that the patch for PR31550 has fixed this one too. Thanks for the reports , Daniel. As usual, they were testing. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31551
[Bug fortran/31550] [regression] f951: segfault in fold-const.c:1963
--- Comment #9 from dfranke at gcc dot gnu dot org 2007-04-13 17:07 --- *** Bug 31551 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31550
[Bug fortran/31551] ice in fold_convert, at fold-const.c:2330
--- Comment #6 from dfranke at gcc dot gnu dot org 2007-04-13 17:07 --- This fix commited for PR31550 fixes this ICE as well. Closing as dupe. *** This bug has been marked as a duplicate of 31550 *** *** This bug has been marked as a duplicate of 31550 *** -- dfranke at gcc dot gnu dot org changed: What|Removed |Added Resolution|FIXED |DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31551
[Bug libfortran/31052] [4.2 only] Bad IOSTAT values when readings NAMELISTs past EOF
--- Comment #47 from hjl at lucon dot org 2007-04-13 17:16 --- (In reply to comment #46) Subject: Re: [4.2 only] Bad IOSTAT values when readings NAMELISTs past EOF Now I am confused because I reverted and re-patched and it was tested by spark and sixtrack was then fine. I specifically had this tested before committing the last fix. I have verfied that this patch http://gcc.gnu.org/viewcvs?view=revrevision=123403 caused sixtrack regression. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31052
[Bug c++/13740] ICE when mangling template which uses typeof
--- Comment #11 from kruus at nec-labs dot com 2007-04-13 18:15 ---
A possibly shorter testcase for this bug.
template class T void func( T x ) {
struct foo { static void bar( typeof(x) a ) { ; } };
foo::bar(x);
}
int main(int,char**) { int i=2; func(i); }
Also bugs with `typeof typedef' outside foo.
But OK with `bar( T a )'
(I wanted something like this while using macros to generate
__attribute__((noinline)) `bar' calls so that debug stuff in headers
wouldn't kill gcc inlining --- unexecuted if(0) code counts to inlining
limits and moving it to and inner foo::bar can greatly help inlining.
It worked great as long as typeof has no relation to any template type
parameter)
This was with gcc (GCC) 4.0.2 20051125 (Red Hat 4.0.2-8)
g++ -c bug0.cc -o bug0.o
// /usr/libexec/gcc/i686-redhat-linux/4.0.2/cc1plus -quiet -D_GNU_SOURCE
bug0.cc -quiet -dumpbase bug0.cc -mtune=pentiumpro -auxbase-strip bug0.o -o -
-frandom-seed=0
--
kruus at nec-labs dot com changed:
What|Removed |Added
CC||kruus at nec-labs dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13740
[Bug fortran/31563] Arithmetic overflow and BOZ
--- Comment #5 from kargl at gcc dot gnu dot org 2007-04-13 18:38 --- (In reply to comment #4) With Hex and octal numbers - there is no overflow as long as there are enough bits - that is why g95 and Absoft do not complain. g95 and absoft do not complain because these compilers either do not correctly implement the F2003 behavior of BOZ literal constants in a data statement and do not check for overflow or these compilers silently assume twos compliment wrap around semantics. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31563
[Bug fortran/31564] New: Error: Type/rank mismatch in argument
When I compile the module listed below I get the message: c3.f90:15.23: USE cdf_aux_mod 1 Error: Type/rank mismatch in argument 'arg_name' at (1) g95 and Lahey do not produce error messages. Is it legal? MODULE cdf_aux_mod TYPE :: the_distribution INTEGER :: parameters(1) END TYPE the_distribution TYPE (the_distribution), PARAMETER :: the_beta = the_distribution((/0/)) CONTAINS SUBROUTINE set_bound(arg_name) INTEGER, INTENT (IN) :: arg_name END SUBROUTINE set_bound END MODULE cdf_aux_mod MODULE cdf_beta_mod CONTAINS SUBROUTINE cdf_beta() USE cdf_aux_mod INTEGER :: which CALL set_bound(the_beta%parameters(which)) END SUBROUTINE cdf_beta END MODULE cdf_beta_mod -- Summary: Error: Type/rank mismatch in argument Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: michael dot a dot richmond at nasa dot gov http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31564
[Bug fortran/31564] Error: Type/rank mismatch in argument
--- Comment #1 from kargl at gcc dot gnu dot org 2007-04-13 19:05 --- The code is illegal, but in accordance with the error message. You need to set WHICH to 1 via either INTEGER :: which = 1 or which = 1 This however doesn't fix the problem. If you change the call to CALL set_bound(the_beta%parameters(1)) then it compiles. So, it looks as if gfortran isn't properly evaluating the derived type arguments. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31564
[Bug fortran/31559] Assigning to an EXTERNAL leads to ICE
--- Comment #2 from burnus at gcc dot gnu dot org 2007-04-13 19:34 --- Subject: Bug 31559 Author: burnus Date: Fri Apr 13 19:34:36 2007 New Revision: 123793 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123793 Log: 2007-04-13 Tobias Burnus [EMAIL PROTECTED] PR fortran/31559 * primary.c (match_variable): External functions are no variables. 2007-04-13 Tobias Burnus [EMAIL PROTECTED] PR fortran/31559 * gfortran.dg/func_assign.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/func_assign.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/primary.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31559
[Bug fortran/31564] Error: Type/rank mismatch in argument
-- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||rejects-valid Last reconfirmed|-00-00 00:00:00 |2007-04-13 19:39:56 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31564
[Bug fortran/31051] [4.2 Only] gfortran bug with x and t format descriptors.
--- Comment #5 from burnus at gcc dot gnu dot org 2007-04-13 19:43 --- What's the plan regarding backporting the patch to GCC 4.2? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31051
[Bug fortran/30285] gfortran excessive memory usage with large modules
--- Comment #10 from tobi at gcc dot gnu dot org 2007-04-13 19:44 --- Bud, I tried your patch, but it doesn't seem to make a difference. Is it the right patch? -- tobi at gcc dot gnu dot org changed: What|Removed |Added CC||tobi at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30285
[Bug fortran/31196] [4.2/4.1 only] wrong code generated with RESHAPE/TRANSPOSE
--- Comment #8 from burnus at gcc dot gnu dot org 2007-04-13 19:44 --- What's the plan regarding backporting the patch to GCC 4.2? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31196
[Bug fortran/31207] [4.2 only] advance=no and tabs
--- Comment #7 from burnus at gcc dot gnu dot org 2007-04-13 19:45 --- What's the plan regarding backporting the patch to GCC 4.2? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31207
[Bug other/28145] C++ (throw() and catch(...) {/* fall through */ } ) and pthread cancellation are incompatible (at least with NPTL)
--- Comment #15 from jason at redhat dot com 2007-04-13 20:13 ---
Subject: Re: C++ (throw() and catch(...) {/* fall through
*/ } ) and pthread cancellation are incompatible (at least with NPTL)
Howard's example seems to me like an argument for not necessarily using
thread cancellation to abort a task, but not for discarding the cancel
request entirely. A cancellation request is asking for a thread to go
away; if you want to send a different message use a different mechanism.
Jason
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28145
[Bug fortran/31563] Arithmetic overflow and BOZ
--- Comment #6 from dir at lanl dot gov 2007-04-13 20:32 --- Sorry, I cannot find another compiler that agrees with gfortran - [EMAIL PROTECTED] ~/tests]$ ifort -o mask mask.f90 [EMAIL PROTECTED] ~/tests]$ mask 8000 FF00 qsc10:~/tests [6] f90 -o mask mask.f90 qsc10:~/tests [7] mask 8000 FF00 [EMAIL PROTECTED] ~/tests]$ pgf90 -o mask mask.f90 [EMAIL PROTECTED] ~/tests]$ mask 8000 FF00 [dranta:~/junk] dir% g95 -o mask mask.f90 [dranta:~/junk] dir% mask 8000 FF00 [dranta:~/junk] dir% f90 -o mask mask.f90 [dranta:~/junk] dir% mask 8000 ff00 [dranta:~/junk] dir% xlf95 -qsuffix=f=f90 -o mask mask.f90 -L/usr/lib/gcc/powerpc-apple-darwin8/4.0.1 ** _main === End of Compilation 1 === 1501-510 Compilation successful for file mask.f90. [dranta:~/junk] dir% mask 8000 FF00 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31563
[Bug fortran/31563] Arithmetic overflow and BOZ
--- Comment #7 from kargl at gcc dot gnu dot org 2007-04-13 20:44 --- (In reply to comment #6) Sorry, I cannot find another compiler that agrees with gfortran - Then, I suggest you submit a bug report. The standard explicitly says If a data-stmt-constant is a boz-literal-constant, the corresponding variable shall be of type integer. The boz-literal-constant is treated as if it were an int-literal-constant with a kind-param that specifies the representation method with the largest decimal exponent range supported by the processor. Either integer(8) or integer(16) is the largest on your platform, and the BOZ is converted as required by the standard. If you want to compile your code and ignore the integer overflow, then use -fno-range-check as others have already told you. laptop:kargl[208] gfc4x -o z -fno-range-check h.f90 laptop:kargl[209] ./z 8000 FF00 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31563
[Bug java/15474] libgcj jar file should always be in classpath at runtime
--- Comment #10 from mark at gcc dot gnu dot org 2007-04-13 20:44 --- Does this recent patch help? 2007-04-13 Andrew Haley [EMAIL PROTECTED] * gnu/gcj/runtime/BootClassLoader.java (getBootURLLoader): New method. (bootGetResource): Use getBootURLLoader() to load resources. (bootGetResources): Likewise. And does it prevent the feared slowdown? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15474
[Bug tree-optimization/29598] FAIL: gcc.dg/tree-ssa/loadpre1.c and loadpre1[45].c scan-tree-dump-times Eliminated: 1 1
--- Comment #2 from jsm28 at gcc dot gnu dot org 2007-04-13 20:46 --- Subject: Bug 29598 Author: jsm28 Date: Fri Apr 13 20:46:37 2007 New Revision: 123794 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123794 Log: PR tree-optimization/29598 * gcc.dg/tree-ssa/loadpre1.c: XFAIL. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/tree-ssa/loadpre1.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29598
[Bug tree-optimization/29598] FAIL: gcc.dg/tree-ssa/loadpre1.c and loadpre1[45].c scan-tree-dump-times Eliminated: 1 1
--- Comment #3 from jsm28 at gcc dot gnu dot org 2007-04-13 20:47 --- Subject: Bug 29598 Author: jsm28 Date: Fri Apr 13 20:47:39 2007 New Revision: 123795 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123795 Log: PR tree-optimization/29598 * gcc.dg/tree-ssa/loadpre1.c, gcc.dg/tree-ssa/loadpre14.c, gcc.dg/tree-ssa/loadpre15.c: XFAIL. Modified: branches/gcc-4_2-branch/gcc/testsuite/ChangeLog branches/gcc-4_2-branch/gcc/testsuite/gcc.dg/tree-ssa/loadpre1.c branches/gcc-4_2-branch/gcc/testsuite/gcc.dg/tree-ssa/loadpre14.c branches/gcc-4_2-branch/gcc/testsuite/gcc.dg/tree-ssa/loadpre15.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29598
[Bug libfortran/31335] Calls lstat(), stat() and fstat() in libgfortran should be protected by autoconf HAVE_{L,,F}STAT macros
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2007-04-13 20:56 --- Subject: Bug 31335 Author: fxcoudert Date: Fri Apr 13 20:56:19 2007 New Revision: 123796 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123796 Log: PR libfortran/31335 * intrinsics/stat.c: Only provide STAT and FSTAT library routines if stat() and fstat() library functions are available. When lstat() is not available, use stat() instead. * configure.ac: Add checks for stat, fstat and lstat. * configure: Regenerate. * config.h.in: Regenerate. Modified: branches/gcc-4_2-branch/libgfortran/ChangeLog branches/gcc-4_2-branch/libgfortran/config.h.in branches/gcc-4_2-branch/libgfortran/configure branches/gcc-4_2-branch/libgfortran/configure.ac branches/gcc-4_2-branch/libgfortran/intrinsics/stat.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31335
[Bug fortran/29397] Constant logical expression with parameter array
--- Comment #5 from pault at gcc dot gnu dot org 2007-04-13 22:26 --- INTEGER :: K(3)=1 INTEGER, PARAMETER :: J(3)=(/1,2,0/) write(6,*) MAXLOC(K,J1) END works just fine. I would say that the problem is that the initializtion expression is never getting turned into an EXPR_ARRAY. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29397
[Bug bootstrap/31565] New: bootstrap xgcc internal compiler error (using -O3)
Bootstrap of gcc-4.1.2 failed with an internal compiler error
(Please submit a full bug report) from ./gcc/xgcc when compiling
libstdc++-v3/libsupc++/del_op.cc, using gcc-3.4.3 as the bootstrap
compiler on sparc-sun-solaris2.6 with following configure options
and bootstrap flags (below), producing the follwing output (further
below), with the follwing -save-temps generated .ii file (furthest
below):
setenv CONFIG_SHELL /bin/ksh
configure --prefix=/usr/local/gcc/$GCC_V \
--disable-shared \
--with-gnu-as --with-as=/usr/local/bin/gas \
--with-gnu-ld --with-ld=/usr/local/bin/gld \
--with-cpu=supersparc \
--enable-version-specific-runtime-libs \
--enable-languages=c,ada,c++,objc,obj-c++,treelang \
--disable-nls
gmake CFLAGS='-O3 -mcpu=supersparc -mno-app-regs' \
CXXFLAGS='-O3 -mcpu=supersparc -mno-app-regs' \
LIBCFLAGS='-O3 -mcpu=supersparc -mno-app-regs' \
LIBCXXFLAGS='-O3 -mcpu=supersparc -mno-app-regs -fno-implicit-templates' \
BOOT_CFLAGS='-O3 -mcpu=supersparc -mno-app-regs' \
bootstrap
produced this output:
/package/gcc/gcc-4.1.2_obj0/./gcc/xgcc -shared-libgcc
-B/package/gcc/gcc-4.1.2_obj0/./gcc -nostdinc++
-L/package/gcc/gcc-4.1.2_obj0/sparc-sun-solaris2.6/libstdc++-v3/src
-L/package/gcc/gcc-4.1.2_obj0/sparc-sun-solaris2.6/libstdc++-v3/src/.libs
-B/usr/local/gcc/gcc-4.1.2/sparc-sun-solaris2.6/bin/
-B/usr/local/gcc/gcc-4.1.2/sparc-sun-solaris2.6/lib/ -isystem
/usr/local/gcc/gcc-4.1.2/sparc-sun-solaris2.6/include -isystem
/usr/local/gcc/gcc-4.1.2/sparc-sun-solaris2.6/sys-include
-I/package/gcc/gcc-4.1.2/libstdc++-v3/../gcc
-I/package/gcc/gcc-4.1.2_obj0/sparc-sun-solaris2.6/libstdc++-v3/include/sparc-sun-solaris2.6
-I/package/gcc/gcc-4.1.2_obj0/sparc-sun-solaris2.6/libstdc++-v3/include
-I/package/gcc/gcc-4.1.2/libstdc++-v3/libsupc++ -O3 -mcpu=supersparc
-mno-app-regs -fno-implicit-templates -Wall -Wextra -Wwrite-strings
-Wcast-qual -fdiagnostics-show-location=once -ffunction-sections
-fdata-sections -c -o del_op.lo
/package/gcc/gcc-4.1.2/libstdc++-v3/libsupc++/del_op.cc
/package/gcc/gcc-4.1.2_obj0/./gcc/xgcc -shared-libgcc
-B/package/gcc/gcc-4.1.2_obj0/./gcc -nostdinc++
-L/package/gcc/gcc-4.1.2_obj0/sparc-sun-solaris2.6/libstdc++-v3/src
-L/package/gcc/gcc-4.1.2_obj0/sparc-sun-solaris2.6/libstdc++-v3/src/.libs
-B/usr/local/gcc/gcc-4.1.2/sparc-sun-solaris2.6/bin/
-B/usr/local/gcc/gcc-4.1.2/sparc-sun-solaris2.6/lib/ -isystem
/usr/local/gcc/gcc-4.1.2/sparc-sun-solaris2.6/include -isystem
/usr/local/gcc/gcc-4.1.2/sparc-sun-solaris2.6/sys-include
-I/package/gcc/gcc-4.1.2/libstdc++-v3/../gcc
-I/package/gcc/gcc-4.1.2_obj0/sparc-sun-solaris2.6/libstdc++-v3/include/sparc-sun-solaris2.6
-I/package/gcc/gcc-4.1.2_obj0/sparc-sun-solaris2.6/libstdc++-v3/include
-I/package/gcc/gcc-4.1.2/libstdc++-v3/libsupc++ -O3 -mcpu=supersparc
-mno-app-regs -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual
-fdiagnostics-show-location=once -ffunction-sections -fdata-sections -c
/package/gcc/gcc-4.1.2/libstdc++-v3/libsupc++/del_op.cc -o del_op.o
/package/gcc/gcc-4.1.2_obj0/./gcc/include/sys/types.h:171: internal compiler
error: in maybe_process_template_type_declaration, at cp/name-lookup.c:4748
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
gmake[5]: *** [del_op.lo] Error 1
gmake[5]: Leaving directory
`/package/gcc/gcc-4.1.2_obj0/sparc-sun-solaris2.6/libstdc++-v3/libsupc++'
gmake[4]: *** [all-recursive] Error 1
gmake[4]: Leaving directory
`/package/gcc/gcc-4.1.2_obj0/sparc-sun-solaris2.6/libstdc++-v3'
gmake[3]: *** [all] Error 2
gmake[3]: Leaving directory
`/package/gcc/gcc-4.1.2_obj0/sparc-sun-solaris2.6/libstdc++-v3'
gmake[2]: *** [all-target-libstdc++-v3] Error 2
gmake[2]: Leaving directory `/package/gcc/gcc-4.1.2_obj0'
gmake[1]: *** [all] Error 2
gmake[1]: Leaving directory `/package/gcc/gcc-4.1.2_obj0'
gmake: *** [bootstrap] Error 2
The .ii file produced by the last xgcc command with -save-temps is:
# 1 /package/gcc/gcc-4.1.2/libstdc++-v3/libsupc++/del_op.cc
# 1 built-in
# 1 command line
# 1 /package/gcc/gcc-4.1.2/libstdc++-v3/libsupc++/del_op.cc
# 31 /package/gcc/gcc-4.1.2/libstdc++-v3/libsupc++/del_op.cc
# 1 /package/gcc/gcc-4.1.2/libstdc++-v3/libsupc++/new 1
# 41 /package/gcc/gcc-4.1.2/libstdc++-v3/libsupc++/new
# 1
/package/gcc/gcc-4.1.2_obj0/sparc-sun-solaris2.6/libstdc++-v3/include/cstddef
1
# 48
/package/gcc/gcc-4.1.2_obj0/sparc-sun-solaris2.6/libstdc++-v3/include/cstddef
# 49
/package/gcc/gcc-4.1.2_obj0/sparc-sun-solaris2.6/libstdc++-v3/include/cstddef
3
# 1 /package/gcc/gcc-4.1.2_obj0/./gcc/include/stddef.h 1 3 4
# 152 /package/gcc/gcc-4.1.2_obj0/./gcc/include/stddef.h 3 4
typedef int ptrdiff_t;
# 214 /package/gcc/gcc-4.1.2_obj0/./gcc/include/stddef.h 3 4
typedef unsigned int size_t;
# 51
/package/gcc/gcc-4.1.2_obj0/sparc-sun-solaris2.6/libstdc++-v3/include/cstddef
2 3
namespace std
{
using ::ptrdiff_t;
using ::size_t;
}
# 42
[Bug c/4076] -Wunused doesn't warn about static function only called by itself.
--- Comment #17 from steven at gcc dot gnu dot org 2007-04-13 22:39 --- Manuel has a good patch for this. I don't know what's holding it up. -- steven at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|steven at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4076
[Bug rtl-optimization/26493] -freorder-blocks-and-partition is a dud without generated profiling data
--- Comment #3 from steven at gcc dot gnu dot org 2007-04-13 22:41 --- I've tried a couple of different ways to use branch predictions for partitioning, but it never leads to meaningful results. Either everything is hot or everything is cold. I don't know what else to do about this. I'm actually tempted to claim this is a WONTFIX because hot and cold are not meaningful without profile information. Thoughts, anyone? -- steven at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|steven at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26493
[Bug rtl-optimization/31102] ICE with -O2 -ftracer
--- Comment #5 from steven at gcc dot gnu dot org 2007-04-13 22:43 --- Transient bug? I can't reproduce it with any of the mentioned revisions. -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31102
[Bug bootstrap/31565] bootstrap xgcc internal compiler error (using -O3)
--- Comment #1 from anirkko at insel dot ch 2007-04-13 22:46 --- *** This bug has been marked as a duplicate of 31523 *** -- anirkko at insel dot ch changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31565
[Bug bootstrap/31523] bootstrap xgcc internal compiler error (using -O3)
--- Comment #1 from anirkko at insel dot ch 2007-04-13 22:46 --- *** Bug 31565 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31523
[Bug bootstrap/31523] bootstrap xgcc internal compiler error (using -O3)
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-04-13 22:47 --- Can you try without setting the CFLAGS, etc. because what might be happening is the base compiler miscompiling the new compiler? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31523
[Bug other/31566] New: @missing_file gives bad error message
Doing gcc @missing_file gives a bad error message: gcc: @t: No such file or directory gcc: no input files @t is not what is missing but t is missing. -- Summary: @missing_file gives bad error message Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pinskia at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31566
[Bug other/31567] New: cc1, cc1plus, etc. don't support @file mechanism
After seeing http://gcc.gnu.org/ml/gcc-patches/2007-04/msg00829.html, I noticed that the actual compilers don't support the @file mechanism at all, so when people do -combine @file, we might overflow the argument list so we should support @file inside the compilers themselves besides just inside the driver. The easy fix is to this before calling toplevel_main. -- Summary: cc1, cc1plus, etc. don't support @file mechanism Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pinskia at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31567
[Bug c/4076] -Wunused doesn't warn about static function only called by itself.
--- Comment #18 from manu at gcc dot gnu dot org 2007-04-13 22:54 --- (In reply to comment #17) Manuel has a good patch for this. I don't know what's holding it up. Some issues were raised, in particular, my patch doesn't warn about functions in anonymous namespaces: http://gcc.gnu.org/ml/gcc-patches/2007-03/msg01103.html I don't think that is solvable at the present moment. I am going to submit just the C bits, since that seems ok. We could open a PR for C++, since anyway the code is not shared at all. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4076
[Bug target/31568] New: ICE with invalid %y operand (inline-asm)
Testcase:
int f(int *a)
{
asm(%y0 : =m(a[2]) );
}
This should instead produce an error with recommending the Z constraint.
--
Summary: ICE with invalid %y operand (inline-asm)
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
GCC target triplet: powerpc*-*-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31568
[Bug libstdc++/31556] find_if uses operator! instead of conversion to bool
--- Comment #6 from paolo at gcc dot gnu dot org 2007-04-13 23:23 --- Subject: Bug 31556 Author: paolo Date: Fri Apr 13 23:22:56 2007 New Revision: 123800 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123800 Log: 2007-04-13 Paolo Carlini [EMAIL PROTECTED] PR libstdc++/31556 * include/bits/stl_algobase.h (equal(_InputIterator1, _InputIterator1, _InputIterator2, _BinaryPredicate), mismatch(_InputIterator1, _InputIterator1, _InputIterator2, _BinaryPredicate)): Convert predicate return to bool. * include/bits/stl_algo.h (__find_if(_InputIterator, _InputIterator, _Predicate, input_iterator_tag), search(_ForwardIterator1, _ForwardIterator1, _ForwardIterator2, _ForwardIterator2, _BinaryPredicate), __search_n(_ForwardIterator, _ForwardIterator, _Integer, const _Tp, _BinaryPredicate, std::forward_iterator_tag), __search_n(_RandomAccessIter, _RandomAccessIter, _Integer, const _Tp, _BinaryPredicate, std::random_access_iterator_tag), search_n(_ForwardIterator, _ForwardIterator, _Integer, const _Tp, _BinaryPredicate), remove_copy_if(_InputIterator, _InputIterator, _OutputIterator, _Predicate), __unique_copy(_ForwardIterator, _ForwardIterator, _OutputIterator, _BinaryPredicate, forward_iterator_tag, output_iterator_tag), __unique_copy(_InputIterator, _InputIterator, _OutputIterator, _BinaryPredicate, input_iterator_tag, output_iterator_tag), __unique_copy(_InputIterator, _InputIterator, _OutputIterator, _BinaryPredicate, input_iterator_tag, output_iterator_tag), __unique_copy(_InputIterator, _InputIterator, _ForwardIterator, _BinaryPredicate, input_iterator_tag, forward_iterator_tag), unique(_ForwardIterator, _ForwardIterator, _BinaryPredicate), __partition(_BidirectionalIterator, _BidirectionalIterator, _Predicate, bidirectional_iterator_tag), binary_search(_ForwardIterator, _ForwardIterator, const _Tp, _Compare), next_permutation(_BidirectionalIterator, _BidirectionalIterator, _Compare), prev_permutation(_BidirectionalIterator, _BidirectionalIterator, _Compare)): Likewise. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/stl_algo.h trunk/libstdc++-v3/include/bits/stl_algobase.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31556
[Bug libstdc++/31556] find_if uses operator! instead of conversion to bool
--- Comment #7 from pcarlini at suse dot de 2007-04-13 23:24 --- Fixed. -- pcarlini at suse dot de changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31556
[Bug fortran/29397] Constant logical expression with parameter array
--- Comment #6 from pault at gcc dot gnu dot org 2007-04-13 23:24 ---
This cures the problem but is otherwise untested.
Paul
Index: gcc/fortran/decl.c
===
*** gcc/fortran/decl.c (revision 123793)
--- gcc/fortran/decl.c (working copy)
*** add_init_expr_to_sym (const char *name,
*** 972,978
/* Add initializer. Make sure we keep the ranks sane. */
if (sym-attr.dimension init-rank == 0)
! init-rank = sym-as-rank;
sym-value = init;
*initp = NULL;
--- 972,1001
/* Add initializer. Make sure we keep the ranks sane. */
if (sym-attr.dimension init-rank == 0)
! {
! mpz_t size;
! gfc_constructor *ctor, *tail;
! int n;
! if (sym-attr.flavor == FL_PARAMETER
!init-expr_type == EXPR_CONSTANT)
! {
! spec_size (sym-as, size);
! ctor = tail = gfc_get_constructor ();
! ctor-expr = init;
! for (n = 1; n (int)mpz_get_si (size); n++)
! {
! tail-next = gfc_get_constructor ();
! tail = tail-next;
! tail-expr = gfc_copy_expr (init);
! }
! init = gfc_get_expr ();
! init-expr_type = EXPR_ARRAY;
! init-ts = ctor-expr-ts;
! init-value.constructor = ctor;
! mpz_clear (size);
! }
! init-rank = sym-as-rank;
! }
sym-value = init;
*initp = NULL;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29397
[Bug testsuite/31451] FAIL: g++.dg/eh/ctor3.C (test for excess errors)
--- Comment #1 from danglin at gcc dot gnu dot org 2007-04-14 00:01 --- Fixed, probably by 2007-04-10 Mike Stump [EMAIL PROTECTED] * class.c (dfs_accumulate_vtbl_inits): Slam the vtbl type back to vtbl_ptr_type_node to ensure the mode is correct. -- danglin at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31451
[Bug testsuite/31452] FAIL: g++.dg/tree-ssa/pr29585.C (test for excess errors)
--- Comment #1 from danglin at gcc dot gnu dot org 2007-04-14 00:03 --- Fixed, probably by 2007-04-10 Mike Stump [EMAIL PROTECTED] * class.c (dfs_accumulate_vtbl_inits): Slam the vtbl type back to vtbl_ptr_type_node to ensure the mode is correct. -- danglin at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31452
