[Bug libfortran/31052] Bad IOSTAT values when readings NAMELISTs past EOF
--- Comment #15 from anlauf at gmx dot de 2007-03-08 08:24 --- (In reply to comment #14) Jerry, I don't have the ressources for a (re)build, so I will wait until it shows up in FX's daily binaries. Anyway, many thanks, and feel free to adjust the PR summary appropriately. From your patch it appears that the real culprit was the REWIND rather than the NAMELIST read. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31052
[Bug tree-optimization/30604] Unable to coalesce ssa_names and which are marked as MUST COALESCE
--- Comment #4 from tbm at cyrius dot com 2007-03-08 09:03 --- I have a fairly small C++ testcase for what appears to be the same issue: (sid)3604:[EMAIL PROTECTED]: ~] g++ -c firebird2-nav.cc (sid)3605:[EMAIL PROTECTED]: ~] g++ -c -O firebird2-nav.cc Unable to coalesce ssa_names 27 and 10 which are marked as MUST COALESCE. result_27(ab) and result_10(ab) firebird2-nav.cc: In function 'BOOLEAN NAV_get_record(Rsb*, mfb*, RPB*, RSE_GET_MODE)': firebird2-nav.cc:235: internal compiler error: SSA corruption Please submit a full bug report, -- tbm at cyrius dot com changed: What|Removed |Added CC||tbm at cyrius dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30604
[Bug rtl-optimization/30643] [4.1/4.2/4.3 regression] CSE pessimization
--- Comment #5 from aoliva at gcc dot gnu dot org 2007-03-08 09:05 --- I have a patch for the 4.1 branch that I'm bootstrap-testing now. It doesn't look like reverting the mentioned patch will fix the problem in mainline, though, at least for an x86_64-linux-gnu native. -- aoliva at gcc dot gnu dot org changed: What|Removed |Added CC||aoliva at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30643
[Bug tree-optimization/30604] Unable to coalesce ssa_names and which are marked as MUST COALESCE
--- Comment #5 from tbm at cyrius dot com 2007-03-08 09:05 --- Created an attachment (id=13167) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13167&action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30604
[Bug fortran/31011] Incorrect error: parameter array sections
--- Comment #3 from pault at gcc dot gnu dot org 2007-03-08 09:09 --- Subject: Bug 31011 Author: pault Date: Thu Mar 8 09:09:38 2007 New Revision: 122689 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122689 Log: 2007-03-08 Paul Thomas <[EMAIL PROTECTED]> PR fortran/31011 * expr.c (find_array_section): Correct arithmetic for section size. 2007-03-08 Paul Thomas <[EMAIL PROTECTED]> PR fortran/31011 * gfortran.dg/parameter_array_section_2.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/parameter_array_section_2.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/expr.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31011
[Bug c/31077] New: C handling of always_inline attribute error and a solution
gcc will segment fault when compiling following code (copied from linux kernel)
when no optimize option is given (I need to debug linux kernel without
optimizing interfere my investigation):
gcc -S -i hello1.i
//hello1.i
1
2 struct genapic {
3
4 int (*check_phys_apicid_present)(int boot_cpu_physical_apicid);
5
6 unsigned (*get_apic_id)(unsigned long x);
7
8 };
9
10 static inline __attribute__((always_inline)) unsigned
get_apic_id(unsigned long x)
11 {
12 return 1;
13 }
14
15
16
17 static inline int check_phys_apicid_present(int cpu_physical_apicid)
18 {
19
20 return get_apic_id(2);
21
22 }
23
24
25 struct genapic apic_es7000 = { .check_phys_apicid_present =
check_phys_apicid_present,.get_apic_id = get_apic_id, };
A solution is change gcc-4.1.0's function cgraph_preserve_function_body_p:
1201 bool
1202 cgraph_preserve_function_body_p (tree decl)
1203 {
1204 struct cgraph_node *node;
1205 /* Keep the body; we're going to dump it. */
1206 if (dump_enabled_p (TDI_tree_all))
1207 return true;
1208 if (!cgraph_global_info_ready)
1209 return (DECL_INLINE (decl) && !flag_really_no_inline);
1210 /* Look if there is any clone around. */
1211 for (node = cgraph_node (decl); node; node = node->next_clone)
1212 if (node->global.inlined_to)
1213 return true;
1214 return false;
1215 }
into
bool
cgraph_preserve_function_body_p (tree decl)
{
struct cgraph_node *node;
/* Keep the body; we're going to dump it. */
if (dump_enabled_p (TDI_tree_all))
return true;
if (!cgraph_global_info_ready && !((DECL_INLINE (decl) &&
!flag_really_no_inline))){
for (node = cgraph_node (decl); node; node = node->next_clone)
if (node->global.local.disregard_inline_limits)
return true;
return false;
}
/* Look if there is any clone around. */
for (node = cgraph_node (decl); node; node = node->next_clone)
if (node->global.inlined_to)
return true;
return false;
}
best regards
Zhouyi Zhou
--
Summary: C handling of always_inline attribute error and a
solution
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: zhouyi04 at ios dot cn
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31077
[Bug c++/31078] New: [4.3 Regression] warning: same canonical type node for different types
I'm not quite sure what to make of this. It's not an ICE, but it still looks like a compiler bug. GCC 4.2 doesn't show this, only current 4.3 does: (cross)1591:[EMAIL PROTECTED]: ~] /usr/lib/gcc-snapshot/bin/g++ -c firebird2-jrn.cc firebird2-jrn.cc: In function 'void error(ISC_STATUS*, jrn*, int, TEXT*)': firebird2-jrn.cc:29: warning: same canonical type node for different types TEXT [1] and const char [1] unit size align 8 symtab 0 alias set -1 canonical type 0x2ba3879df300 precision 8 min max pointer_to_this > QI size unit size align 8 symtab 0 alias set -1 canonical type 0x2ba387b70600 domain unit size align 64 symtab 0 alias set -1 canonical type 0x2ba3879dfd80 precision 64 min max > DI size unit size align 64 symtab 0 alias set -1 canonical type 0x2ba3879f5780 precision 64 min max >> unit size align 8 symtab 0 alias set -1 canonical type 0x2ba3879f5e40 precision 8 min max pointer_to_this > QI size unit size align 8 symtab 0 alias set -1 canonical type 0x2ba387b70600 domain unit size align 64 symtab 0 alias set -1 canonical type 0x2ba3879dfd80 precision 64 min max > DI size unit size align 64 symtab 0 alias set -1 canonical type 0x2ba3879f5780 precision 64 min max >> firebird2-jrn.cc:29: warning: same canonical type node for different types TEXT [1] and const char [1] unit size align 8 symtab 0 alias set -1 canonical type 0x2ba3879df300 precision 8 min max pointer_to_this > QI size unit size align 8 symtab 0 alias set -1 canonical type 0x2ba387b70600 domain unit size align 64 symtab 0 alias set -1 canonical type 0x2ba3879dfd80 precision 64 min max > DI size unit size align 64 symtab 0 alias set -1 canonical type 0x2ba3879f5780 precision 64 min max >> unit size align 8 symtab 0 alias set -1 canonical type 0x2ba3879f5e40 precision 8 min max pointer_to_this > QI size unit size align 8 symtab 0 alias set -1 canonical type 0x2ba387b70600 domain unit size align 64 symtab 0 alias set -1 canonical type 0x2ba3879dfd80 precision 64 min max > DI size unit size align 64 symtab 0 alias set -1 canonical type 0x2ba3879f5780 precision 64 min max >> firebird2-jrn.cc:29: warning: same canonical type node for different types TEXT [1] and const char [1] unit size align 8 symtab 0 alias set -1 canonical type 0x2ba3879df300 precision 8 min max pointer_to_this > QI size unit size align 8 symtab 0 alias set -1 canonical type 0x2ba387b70600 domain unit size align 64 symtab 0 alias set -1 canonical type 0x2ba3879dfd80 precision 64 min max > DI size unit size align 64 symtab 0 alias set -1 canonical type 0x2ba3879f5780 precision 64 min max >> unit size align 8 symtab 0 alias set -1 canonical type 0x2ba3879f5e40 precision 8 min max pointer_to_this > QI size unit size align 8 symtab 0 alias set -1 canonical type 0x2ba387b70600 domain unit size align 64 symtab 0 alias set -1 canonical type 0x2ba3879dfd80 precision 64 min max > DI size unit size align 64 symtab 0 alias set -1 canonical type 0x2ba3879f5780 precision 64 min max >> -- Summary: [4.3 Regression] warning: same canonical type node for different types Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tbm at cyrius dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31078
[Bug c++/31078] [4.3 Regression] warning: same canonical type node for different types
--- Comment #1 from tbm at cyrius dot com 2007-03-08 09:45 --- Created an attachment (id=13169) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13169&action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31078
[Bug tree-optimization/31079] New: 300% difference between ifort/gfortran
I'm still trying to find a reduced testcase (or better source) for PR 31021, but I'm not sure the code below is really the same issue. However, it illustrates a rather small program with a very significant slowdown in gfortran relative to ifort. [EMAIL PROTECTED]:/data/vondele/extracted_collocate/test> ifort -O2 -xT test.f90 test.f90(17) : (col. 7) remark: LOOP WAS VECTORIZED. test.f90(20) : (col. 7) remark: LOOP WAS VECTORIZED. test.f90(24) : (col. 4) remark: BLOCK WAS VECTORIZED. [EMAIL PROTECTED]:/data/vondele/extracted_collocate/test> ./a.out 3.544221 [EMAIL PROTECTED]:/data/vondele/extracted_collocate/test> gfortran -O3 -march=native -ftree-vectorize -ffast-math test.f90 [EMAIL PROTECTED]:/data/vondele/extracted_collocate/test> ./a.out 11.84874 [EMAIL PROTECTED]:/data/vondele/extracted_collocate/test> gfortran -O2 -march=native -ftree-vectorize -ffast-math test.f90 [EMAIL PROTECTED]:/data/vondele/extracted_collocate/test> ./a.out 11.84474 [EMAIL PROTECTED]:/data/vondele/extracted_collocate/test> cat test.f90 SUBROUTINE collocate_core_2_2_0_0(jg,cmax) IMPLICIT NONE integer, INTENT(IN) :: jg,cmax INTEGER, PARAMETER :: wp = SELECTED_REAL_KIND ( 14, 200 ) INTEGER, PARAMETER :: N=1000 TYPE vec real(wp) :: a(2) END TYPE vec TYPE(vec) :: dpy(1000) TYPE(vec) :: pxy(1000) real(wp) s(04) integer :: i CALL USE(dpy,pxy,s) DO i=1,N pxy(i)%a=0.0_wp ENDDO DO i=1,N dpy(i)%a=0.0_wp ENDDO s(01)=0.0_wp s(02)=0.0_wp s(03)=0.0_wp s(04)=0.0_wp DO i=1,N s(01)=s(01)+pxy(i)%a(1)*dpy(i)%a(1) s(02)=s(02)+pxy(i)%a(2)*dpy(i)%a(1) s(03)=s(03)+pxy(i)%a(1)*dpy(i)%a(2) s(04)=s(04)+pxy(i)%a(2)*dpy(i)%a(2) ENDDO CALL USE(dpy,pxy,s) END SUBROUTINE SUBROUTINE USE(a,b,c) INTEGER, PARAMETER :: wp = SELECTED_REAL_KIND ( 14, 200 ) REAL(kind=wp) :: a(*),b(*),c(*) END SUBROUTINE USE PROGRAM TEST integer, parameter :: cmax=5 integer*8 :: t1,t2,tbest real :: time1,time2 jg=0 CALL cpu_time(time1) tbest=huge(tbest) DO i=1,100 ! t1=nanotime_ia32() CALL collocate_core_2_2_0_0(0,cmax) ! t2=nanotime_ia32() ! if(t2-t1>0 .AND. t2-t1http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31079
[Bug ada/26797] [4.3 regression] ACATS cxh1001 fails
--- Comment #25 from baldrick at gcc dot gnu dot org 2007-03-08 09:56 --- I can't help feeling that VIEW_CONVERT_EXPR is not the right tool for implementing 'Valid. I think an intrinsic would be better, eg "int __builtin_nop(int)" which is defined to return its argument unchanged. Then 'Valid can be implemented as something like: x'Valid -> y = __builtin_nop(x); valid = (y>=lower_bound && y <=upper_bound); The point is that the intrinsic would be opaque to the optimizers, and would only be lowered to the identity function *after* the tree optimizers have run. One annoyance is that presumably intrinsics would be needed for all integer and float precisions, eg __builtin_nop8, __builtin_nop16, etc. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26797
[Bug rtl-optimization/30643] [4.1/4.2/4.3 regression] CSE pessimization
--- Comment #6 from aoliva at gcc dot gnu dot org 2007-03-08 10:23 --- It was the fwprop merge that further disabled the optimization in the trunk. http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118475 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30643
[Bug c/31077] C handling of always_inline attribute error and a solution
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-03-08 10:54 --- *** This bug has been marked as a duplicate of 29241 *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31077
[Bug middle-end/29241] [4.0 Regression] [non unit-at-a-time] ICE with always inline
--- Comment #10 from rguenth at gcc dot gnu dot org 2007-03-08 10:54 --- *** Bug 31077 has been marked as a duplicate of this bug. *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||zhouyi04 at ios dot cn http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29241
[Bug target/31076] ICE with double and unsigned long long with -march=prescott
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-03-08 10:57 --- Works for me with 20070305 and 20070308. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31076
[Bug tree-optimization/31079] 300% difference between ifort/gfortran
--- Comment #1 from jv244 at cam dot ac dot uk 2007-03-08 11:11 --- The following is (for me) an even more interesting example, as it times only the loop that thus the actual multiply / add but also tricks my version of ifort into generating the expected asm. Ifort is about twice as fast as gfortran on it. SUBROUTINE collocate_core_2_2_0_0(jg,cmax) IMPLICIT NONE integer, INTENT(IN) :: jg,cmax INTEGER, PARAMETER :: wp = SELECTED_REAL_KIND ( 14, 200 ) INTEGER, PARAMETER :: N=10,Nit=1 TYPE vec real(wp) :: a(2) END TYPE vec TYPE(vec) :: dpy(1000) TYPE(vec) :: pxy(1000) TYPE(vec) :: s(02) integer :: i,j DO i=1,N pxy(i)%a=0.0_wp ENDDO DO i=1,N dpy(i)%a=0.0_wp ENDDO s(01)%a(1)=0.0_wp s(01)%a(2)=0.0_wp s(02)%a(1)=0.0_wp s(02)%a(2)=0.0_wp CALL USE(dpy,pxy,s) DO j=1,Nit DO i=1,N s(01)%a(:)=s(01)%a(:)+pxy(i)%a(:)*dpy(i)%a(1) s(02)%a(:)=s(02)%a(:)+pxy(i)%a(:)*dpy(i)%a(2) ENDDO ENDDO CALL USE(dpy,pxy,s) END SUBROUTINE [EMAIL PROTECTED]:/data/vondele/extracted_collocate/test> gfortran -O2 -march=native -ftree-vectorize -ffast-math test.f90 [EMAIL PROTECTED]:/data/vondele/extracted_collocate/test> ./a.out 4.288268 [EMAIL PROTECTED]:/data/vondele/extracted_collocate/test> ifort -O2 -xT test.f90 test.f90(16) : (col. 8) remark: LOOP WAS VECTORIZED. test.f90(19) : (col. 8) remark: LOOP WAS VECTORIZED. test.f90(31) : (col. 6) remark: LOOP WAS VECTORIZED. test.f90(31) : (col. 6) remark: LOOP WAS VECTORIZED. test.f90(32) : (col. 6) remark: LOOP WAS VECTORIZED. test.f90(32) : (col. 6) remark: LOOP WAS VECTORIZED. [EMAIL PROTECTED]:/data/vondele/extracted_collocate/test> ./a.out 1.944121 The inner loop asm looks, with ifort, also the way I was hoping it to look like: .B2.7: # Preds ..B2.7 ..B2.6 movddup -16+collocate_core_2_2_0_0_$DPY.0.0(%rcx), %xmm2 #31.41 movddup -8+collocate_core_2_2_0_0_$DPY.0.0(%rcx), %xmm3 #32.41 addq $16, %rdx #33.4 movapdcollocate_core_2_2_0_0_$PXY.0.0(%rdx), %xmm4 #31.6 mulpd %xmm4, %xmm2 #31.39 mulpd %xmm3, %xmm4 #32.39 addpd %xmm2, %xmm1 #31.7 addpd %xmm4, %xmm0 #32.7 addq $16, %rcx #33.5 cmpq $160, %rcx#33.4 jle ..B2.7# Prob 90% #33.4 # LOE rdx rcx rbx rbp r12 r13 r14 r15 eax xmm0 xmm1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31079
[Bug c++/31078] [4.3 Regression] warning: same canonical type node for different types
--- Comment #2 from manu at gcc dot gnu dot org 2007-03-08 11:39 --- It is indeed. It is related to this patch: http://gcc.gnu.org/ml/gcc/2006-11/msg00192.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31078
[Bug rtl-optimization/30643] [4.1/4.2/4.3 regression] CSE pessimization
--- Comment #7 from ebotcazou at gcc dot gnu dot org 2007-03-08 11:39 --- > I have a patch for the 4.1 branch that I'm bootstrap-testing now. OK, reassigning to you, thanks. > It doesn't look like reverting the mentioned patch will fix the problem in > mainline, though, at least for an x86_64-linux-gnu native. I presume it works on the 4.2 branch though? -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC|aoliva at gcc dot gnu dot |ebotcazou at gcc dot gnu dot |org |org AssignedTo|ebotcazou at gcc dot gnu dot|aoliva at gcc dot gnu dot |org |org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30643
[Bug c++/31078] [4.3 Regression] warning: same canonical type node for different types
--- Comment #3 from manu at gcc dot gnu dot org 2007-03-08 11:40 --- I think the warning message should be more explicit. It should say: this is a compiler bug, please report it, or something similar. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31078
[Bug libstdc++/30675] [4.2/4.3 Regression] libstdc++ testsuite hardcodes "ar" and "ranlib"
--- Comment #5 from jsm28 at gcc dot gnu dot org 2007-03-08 11:50 --- Fixed for 4.2.0. -- jsm28 at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30675
[Bug c++/31080] New: ice for legal code with -O2
I just tried to compile Suse Linux package opensp-1.5.1-120 with the GNU C++ compiler version 4.3 snapshot 20070302. The compiler said URLStorage.cxx: In member function 'OpenSP::HTTP_RESPONSE_TYPE OpenSP::HttpSocketStorageObject::readHeader(OpenSP::Messenger&, char*)': URLStorage.cxx:601: error: definition in block 74 does not dominate use in block 77 for SSA_NAME: NMT.1285_487 in statement: NMT.1285_354 = PHI PHI argument NMT.1285_487 for PHI node NMT.1285_354 = PHI URLStorage.cxx:601: internal compiler error: verify_ssa failed Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. Preprocessed source code attached. Flag -O2 required. -- Summary: ice for legal code with -O2 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dcb314 at hotmail dot com GCC host triplet: x86_64-suse-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31080
[Bug c++/31080] ice for legal code with -O2
--- Comment #1 from dcb314 at hotmail dot com 2007-03-08 12:11 --- Created an attachment (id=13170) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13170&action=view) C++ source code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31080
[Bug fortran/30973] undetected name conflict: variables may be named like modules
--- Comment #6 from burnus at gcc dot gnu dot org 2007-03-08 12:31 --- Subject: Bug 30973 Author: burnus Date: Thu Mar 8 12:30:58 2007 New Revision: 122696 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122696 Log: 2007-03-08 Tobias Burnus <[EMAIL PROTECTED]> PR fortran/30973 * module.c (read_module): Always import module name as symbol. (gfc_match_use): Disallow module name in the only clause of a use statement. 2007-03-08 Tobias Burnus <[EMAIL PROTECTED]> PR fortran/30973 * gfortran.dg/use_4.f90: New test. * gfortran.dg/used_dummy_types_7.f90: Correct ambiguous symbol. Added: trunk/gcc/testsuite/gfortran.dg/use_4.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/module.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/used_dummy_types_7.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30973
[Bug middle-end/31081] New: [4.3 Regression] Inliner messes up SSA for abnormals
Testcase:
static int get_record (void);
void f(void);
int g(void);
static int get_record (void)
{
int result;
try
{
result = g();
f();
}
catch (const int &) { }
return result;
}
int NAV_get_record ( )
{
int result;
for (;;)
if (get_record ())
return 1;
}
-
Unable to coalesce ssa_names 9 and 5 which are marked as MUST COALESCE.
result_9(ab) and result_5(ab)
t.cc: In function 'int NAV_get_record()':
t.cc:5: internal compiler error: SSA corruption
--
Summary: [4.3 Regression] Inliner messes up SSA for abnormals
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: middle-end
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=31081
[Bug middle-end/31081] [4.3 Regression] Inliner messes up SSA for abnormals
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-03-08 12:33 --- Confirmed, this was just a splitting of PR 30604 into this one (with reducing). -- pinskia 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-03-08 12:33:00 date|| Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31081
[Bug tree-optimization/30604] Unable to coalesce ssa_names and which are marked as MUST COALESCE
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-03-08 12:34 --- > I have a fairly small C++ testcase for what appears to be the same issue: I think that issue is actually different as the SSA inliner came in after this bug was filed so I filed this with a reduced testcase as PR 31081. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30604
[Bug libfortran/31001] [4.1/4.2 only] PACK crashes on zero-sized arrays
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-03-08 12:35 --- Subject: Bug 31001 Author: fxcoudert Date: Thu Mar 8 12:34:59 2007 New Revision: 122697 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122697 Log: PR target/30406 * config/rs6000/rs6000.c (rs6000_function_value): Look at bit size instead of precision. * gfortran.dg/logical_3.f90: New test. PR libfortran/31001 * intrinsics/pack_generic.c (pack_internal): Add special checks for zero-sized arrays. * gfortran.dg/zero_sized_3.f90: New test. Added: branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/logical_3.f90 - copied unchanged from r122523, trunk/gcc/testsuite/gfortran.dg/logical_3.f90 branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/zero_sized_3.f90 - copied unchanged from r122507, trunk/gcc/testsuite/gfortran.dg/zero_sized_3.f90 Modified: branches/gcc-4_2-branch/gcc/ChangeLog branches/gcc-4_2-branch/gcc/config/rs6000/rs6000.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog branches/gcc-4_2-branch/libgfortran/ChangeLog branches/gcc-4_2-branch/libgfortran/intrinsics/pack_generic.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31001
[Bug target/30406] [4.1/4.2 only] ICE in LOGICAL(8) functions
--- Comment #36 from fxcoudert at gcc dot gnu dot org 2007-03-08 12:35 --- Subject: Bug 30406 Author: fxcoudert Date: Thu Mar 8 12:34:59 2007 New Revision: 122697 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122697 Log: PR target/30406 * config/rs6000/rs6000.c (rs6000_function_value): Look at bit size instead of precision. * gfortran.dg/logical_3.f90: New test. PR libfortran/31001 * intrinsics/pack_generic.c (pack_internal): Add special checks for zero-sized arrays. * gfortran.dg/zero_sized_3.f90: New test. Added: branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/logical_3.f90 - copied unchanged from r122523, trunk/gcc/testsuite/gfortran.dg/logical_3.f90 branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/zero_sized_3.f90 - copied unchanged from r122507, trunk/gcc/testsuite/gfortran.dg/zero_sized_3.f90 Modified: branches/gcc-4_2-branch/gcc/ChangeLog branches/gcc-4_2-branch/gcc/config/rs6000/rs6000.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog branches/gcc-4_2-branch/libgfortran/ChangeLog branches/gcc-4_2-branch/libgfortran/intrinsics/pack_generic.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30406
[Bug middle-end/31081] [4.3 Regression] Inliner messes up SSA for abnormals
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-03-08 12:37 --- Note if I manually inline NAV_get_record, I get an extra PHI: # result_1(ab) = PHI Where result_5 would be the same as result_1 here. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.3.0 Known to work||4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31081
[Bug ada/26797] [4.3 regression] ACATS cxh1001 fails
--- Comment #26 from kenner at vlsi1 dot ultra dot nyu dot edu 2007-03-08 12:54 --- Subject: Re: [4.3 regression] ACATS cxh1001 fails > y = __builtin_nop(x); valid = (y>=lower_bound && y <=upper_bound); > The point is that the intrinsic would be opaque to the optimizers, > and would only be lowered to the identity function *after* the tree > optimizers have run. One annoyance is that presumably intrinsics > would be needed for all integer and float precisions, eg > __builtin_nop8, __builtin_nop16, etc. More than each precision. The VIEW_CONVERT_EXPR is to the base type and there can be an unlimited number of them for each precision. Because it has to work with arbitrary types, a builtin won't do it. We could certainly add a new tree expression that says "don't look through this for VRP purposes", but we already have V_C_E. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26797
[Bug c++/31078] [4.3 Regression] warning: same canonical type node for different types with const strings
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Summary|[4.3 Regression] warning: |[4.3 Regression] warning: |same canonical type node for|same canonical type node for |different types |different types with const ||strings Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31078
[Bug c++/31078] [4.3 Regression] warning: same canonical type node for different types with const strings
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-03-08 13:10 ---
Reduced testcase:
char a[1];
void
error (int journal )
{
const char *b = journal?a: "";
}
--
pinskia 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-03-08 13:10:49
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31078
[Bug c++/31078] [4.3 Regression] warning: same canonical type node for different types with const strings
--- Comment #5 from gdr at cs dot tamu dot edu 2007-03-08 13:20 --- Subject: Re: [4.3 Regression] warning: same canonical type node for different types "manu at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes: | --- Comment #3 from manu at gcc dot gnu dot org 2007-03-08 11:40 --- | I think the warning message should be more explicit. It should say: this is a | compiler bug, please report it, or something similar. I thought we eventually agreed that it should be a plain internal_error. Warning is for constructs in user codes, nont compiler internals. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31078
[Bug target/30406] [4.1 only] ICE in LOGICAL(8) functions
--- Comment #37 from burnus at gcc dot gnu dot org 2007-03-08 13:24 --- Can this be closed or do you intent to backport it to 4.1? -- burnus at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.1/4.2 only] ICE in |[4.1 only] ICE in LOGICAL(8) |LOGICAL(8) functions|functions http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30406
[Bug target/30406] [4.1 only] ICE in LOGICAL(8) functions
--- Comment #38 from fxcoudert at gcc dot gnu dot org 2007-03-08 13:33 --- No backport to 4.1, said the maintainer. Closing accordingly. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to fail|4.2.0 4.1.2 |4.1.2 Known to work|4.3.0 |4.3.0 4.2.0 Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30406
[Bug c/31082] New: for (int i = 1; i != 0; i++); hangs for 32-bit ints with -O2 or above. Should wrap quickly.
The following code hangs for -O2 or -O3. I am running on a 32-bit machine, and with -O1 it terminates after a few seconds: for (int i = 1; i != 0; i++); You can replace 'i = 1' with 'i = (1<<30)' for faster testing. I am running Gentoo Linux 64-bit. 'gcc --version' says: gcc (GCC) 4.1.1 (Gentoo 4.1.1). -- Summary: for (int i = 1; i != 0; i++); hangs for 32-bit ints with -O2 or above. Should wrap quickly. Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: major Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: niklas at cadence dot com GCC build triplet: What is this? How about an explanation in "bug writing guideline GCC host triplet: What is this? How about an explanation in "bug writing guideline GCC target triplet: What is this? How about an explanation in "bug writing guideline http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31082
[Bug c/31083] New: for (int i = 1; i != 0; i++); hangs for 32-bit ints with -O2 or above. Should wrap quickly.
The following code hangs for -O2 or -O3. I am running on a 32-bit machine, and with -O1 it terminates after a few seconds: for (int i = 1; i != 0; i++); You can replace 'i = 1' with 'i = (1<<30)' for faster testing. I am running Gentoo Linux 64-bit. 'gcc --version' says: gcc (GCC) 4.1.1 (Gentoo 4.1.1). -- Summary: for (int i = 1; i != 0; i++); hangs for 32-bit ints with -O2 or above. Should wrap quickly. Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: major Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: niklas at cadence dot com GCC build triplet: What is this? How about an explanation in "bug writing guideline GCC host triplet: What is this? How about an explanation in "bug writing guideline GCC target triplet: What is this? How about an explanation in "bug writing guideline http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31083
[Bug c/31083] for (int i = 1; i != 0; i++); hangs for 32-bit ints with -O2 or above. Should wrap quickly.
--- Comment #1 from niklas at cadence dot com 2007-03-08 14:17 --- I am running on a 64-bit machine, not 32-bit as stated in the first line. Typo, sorry. -- niklas at cadence dot com changed: What|Removed |Added CC||niklas at cadence dot com Keywords||wrong-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31083
[Bug fortran/30880] Derived types with default value -- function with ENTRY: rejected at compile time
--- Comment #2 from pault at gcc dot gnu dot org 2007-03-08 14:23 --- Created an attachment (id=13171) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13171&action=view) A fix for the PR The attached regtests on Cygwin_NT/PIV. I will submit it to the list tonight. Paul -- 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 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30880
[Bug libgcj/31084] New: TRUE or FALSE defined
/test/gnu/gcc/objdir/./gcc/xgcc -shared-libgcc -B/test/gnu/gcc/objdir/./gcc -nos tdinc++ -L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/src -L/test/gn u/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/src/.libs -B/opt/gnu/gcc/gcc-4.3 .0/hppa2.0w-hp-hpux11.11/bin/ -B/opt/gnu/gcc/gcc-4.3.0/hppa2.0w-hp-hpux11.11/lib / -isystem /opt/gnu/gcc/gcc-4.3.0/hppa2.0w-hp-hpux11.11/include -isystem /opt/gn u/gcc/gcc-4.3.0/hppa2.0w-hp-hpux11.11/sys-include -DHAVE_CONFIG_H -I. -I../../.. /gcc/libjava -I./include -I./gcj -I../../../gcc/libjava -Iinclude -I../../../gcc /libjava/include -I../../../gcc/libjava/classpath/include -Iclasspath/include -I ../../../gcc/libjava/classpath/native/fdlibm -I../../../gcc/libjava/../boehm-gc/ include -I../boehm-gc/include -I../../../gcc/libjava/libltdl -I../../../gcc/libj ava/libltdl -I../../../gcc/libjava/.././libjava/../gcc -I../../../gcc/libjava/.. /zlib -I../../../gcc/libjava/../libffi/include -I../libffi/include -fno-rtti -fn on-call-exceptions -pthread -fdollars-in-identifiers -Wswitch-enum -D_FILE_OFFSE T_BITS=64 -Wextra -Wall -D_GNU_SOURCE -DPREFIX=\"/opt/gnu/gcc/gcc-4.3.0\" -DTOOL EXECLIBDIR=\"/opt/gnu/gcc/gcc-4.3.0/lib\" -DJAVA_HOME=\"/opt/gnu/gcc/gcc-4.3.0\" -DBOOT_CLASS_PATH=\"/opt/gnu/gcc/gcc-4.3.0/share/java/libgcj-4.3.0.jar\" -DJAVA _EXT_DIRS=\"/opt/gnu/gcc/gcc-4.3.0/share/java/ext\" -DGCJ_ENDORSED_DIRS=\"/opt/g nu/gcc/gcc-4.3.0/share/java/gcj-endorsed\" -DGCJ_VERSIONED_LIBDIR=\"/opt/gnu/gcc /gcc-4.3.0/lib/gcj-4.3.0\" -DPATH_SEPARATOR=\":\" -DLIBGCJ_DEFAULT_DATABASE=\"/o pt/gnu/gcc/gcc-4.3.0/lib/gcj-4.3.0/classmap.db\" -DLIBGCJ_DEFAULT_DATABASE_PATH_ TAIL=\"gcj-4.3.0/classmap.db\" -g -O2 -MT java/lang/natVMProcess.lo -MD -MP -MF java/lang/.deps/natVMProcess.Tpo -c ../../../gcc/libjava/java/lang/natVMProcess. cc -fPIC -DPIC -o java/lang/.libs/natVMProcess.o In file included from ./include/platform.h:43, from ../../../gcc/libjava/java/lang/natVMProcess.cc:16: /usr/include/sys/rw_lock.h:169: error: 'This' does not name a type In file included from ./include/platform.h:47, from ../../../gcc/libjava/java/lang/natVMProcess.cc:16: ../../../gcc/libjava/java/util/Properties.h:7: error: expected declaration befor e end of line make[3]: *** [java/lang/natVMProcess.lo] Error 1 make[3]: *** Waiting for unfinished jobs make[3]: Leaving directory `/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libjava' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libjava' make[1]: *** [all-target-libjava] Error 2 make[1]: Leaving directory `/test/gnu/gcc/objdir' make: *** [bootstrap] Error 2 Thu Mar 8 06:09:42 EST 2007 /* * For source compatibility, need to continue defining TRUE and FALSE for * user-level applications. Although this file defines a kernel only service, * some user-level applications are indirectly including this file and * depending on the defines for TRUE and FALSE. These defines need to * remain until all the user-level issues have been handled. */ #ifndef _KERNEL #ifndef TRUE #define TRUE1 #define FALSE 0 #else #if ((TRUE != 1) || (FALSE != 0)) This is probably not a good thing #endif #endif /* !TRUE */ #endif /* !_KERNEL */ -- Summary: TRUE or FALSE defined Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcj AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org GCC build triplet: hppa2.0w-hp-hpux11.11 GCC host triplet: hppa2.0w-hp-hpux11.11 GCC target triplet: hppa2.0w-hp-hpux11.11 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31084
[Bug c/31085] New: internal compiler error: in create_mem_ref, at tree-ssa-address.c:606
My compilation resulted in an internal compiler error and a request to submit a bug report. Here's the command used and it's output: the input will be attached. mamie:$gcc -v -DLNX -fPIC -w -m32 -fwrapv -O3 -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -c utilcomp.i Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../configure --enable-languages=c,c++,fortran Thread model: posix gcc version 4.3.0 20070305 (experimental) /usr/local/libexec/gcc/i686-pc-linux-gnu/4.3.0/cc1 -fpreprocessed utilcomp.i -quiet -dumpbase utilcomp.i -m32 -mtune=generic -auxbase utilcomp -O3 -w -version -fPIC -fwrapv -o /tmp/ccokSDVr.s GNU C version 4.3.0 20070305 (experimental) (i686-pc-linux-gnu) compiled by GNU C version 4.3.0 20070305 (experimental). GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: af9ea66eb7bed348134eeea0b2925c17 utilcomp.c: In function 'filecheck': utilcomp.c:5124: internal compiler error: in create_mem_ref, at tree-ssa-address.c:606 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. -- Summary: internal compiler error: in create_mem_ref, at tree-ssa- address.c:606 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sdirkse at gams dot com GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31085
[Bug c/31083] for (int i = 1; i != 0; i++); hangs for 32-bit ints with -O2 or above. Should wrap quickly.
--- Comment #2 from manu at gcc dot gnu dot org 2007-03-08 14:38 --- I think you are relying on the fact that signed overflow wraps, when in standard C it is actually undefined (it may wrap, it may not). To make integers wrap on overflow you use unsigned or -fwrapv. Thus, I think this is a duplicate of PR 30475. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31083
[Bug c/31085] internal compiler error: in create_mem_ref, at tree-ssa-address.c:606
--- Comment #1 from sdirkse at gams dot com 2007-03-08 14:39 --- Created an attachment (id=13172) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13172&action=view) result of "gcc-save-temps" run on .c file To reproduce the bug with this file, do: mamie$gcc -v -DLNX -fPIC -w -m32 -fwrapv -O3 -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -c utilcomp.i Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../configure --enable-languages=c,c++,fortran Thread model: posix gcc version 4.3.0 20070305 (experimental) /usr/local/libexec/gcc/i686-pc-linux-gnu/4.3.0/cc1 -fpreprocessed utilcomp.i -quiet -dumpbase utilcomp.i -m32 -mtune=generic -auxbase utilcomp -O3 -w -version -fPIC -fwrapv -o /tmp/ccokSDVr.s GNU C version 4.3.0 20070305 (experimental) (i686-pc-linux-gnu) compiled by GNU C version 4.3.0 20070305 (experimental). GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: af9ea66eb7bed348134eeea0b2925c17 utilcomp.c: In function 'filecheck': utilcomp.c:5124: internal compiler error: in create_mem_ref, at tree-ssa-address.c:606 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31085
[Bug c/31082] for (int i = 1; i != 0; i++); hangs for 32-bit ints with -O2 or above. Should wrap quickly.
--- Comment #1 from manu at gcc dot gnu dot org 2007-03-08 14:41 --- *** This bug has been marked as a duplicate of 31083 *** -- manu at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31082
[Bug c/31083] for (int i = 1; i != 0; i++); hangs for 32-bit ints with -O2 or above. Should wrap quickly.
--- Comment #3 from manu at gcc dot gnu dot org 2007-03-08 14:41 --- *** Bug 31082 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31083
[Bug ada/30501] GNAT BUG BOX: 16-bit target & Standard.Integer
--- Comment #1 from rolf dot ebert dot gcc at gmx dot de 2007-03-08 15:15 --- This is probably the same problem as mentioned in PR-10768 (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10768). See comments #9 - #11. Bernd Trog developed a workaround available at http://svn.sourceforge.net/viewvc/avr-ada/trunk/patches/gcc-4.1-integer-bug-workaround.patch?view=log Also see the discussion that started here http://gcc.gnu.org/ml/gcc/2006-04/msg00512.html -- rolf dot ebert dot gcc at gmx dot de changed: What|Removed |Added CC||rolf dot ebert dot gcc at ||gmx dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30501
[Bug c++/31080] ice for legal code with -O2
--- Comment #2 from tbm at cyrius dot com 2007-03-08 15:17 --- Maybe the same as PR31037 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31080
[Bug middle-end/31058] overflow warnings should not be enabled with -Wall
--- Comment #20 from manu at gcc dot gnu dot org 2007-03-08 15:28 --- I think the description doesn't match the real bug, as explained in comment #14 and #18. And comment #6 may have a wink but I think it summarises why the testcase in comment #3 deserves a warning. I have my own opinion about whether "out-of-bounds array access warnings should not be enabled by -Wall" but I don't think this bug report is about that, so those advocating the former should open a new bug report with testcases to support their position and the description of this bug should be something similar to "fprefetch-loop-arrays generates code known unreachable at compile time". -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31058
[Bug c/31083] for (int i = 1; i != 0; i++); hangs for 32-bit ints with -O2 or above. Should wrap quickly.
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-03-08 15:33 --- Integer overflow is undefined. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31083
[Bug c/31085] internal compiler error: in create_mem_ref, at tree-ssa-address.c:606
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-03-08 15:41 --- Reducing. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rakdver at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31085
[Bug middle-end/31058] overflow warnings should not be enabled with -Wall
--- Comment #21 from rakdver at atrey dot karlin dot mff dot cuni dot cz 2007-03-08 15:43 --- Subject: Re: overflow warnings should not be enabled with -Wall > I think the description doesn't match the real bug, as explained in comment > #14 > and #18. > > And comment #6 may have a wink but I think it summarises why the testcase in > comment #3 deserves a warning. > > I have my own opinion about whether "out-of-bounds array access warnings > should > not be enabled by -Wall" but I don't think this bug report is about that, so > those advocating the former should open a new bug report with testcases to > support their position and the description of this bug should be something > similar to "fprefetch-loop-arrays generates code known unreachable at compile > time". "suspected to be unreachable at compile time". It would be valid for the array to extend beyond the structure, hence the compiler cannot prove that the unrolled loop body is really unreachable. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31058
[Bug c/31085] internal compiler error: in create_mem_ref, at tree-ssa-address.c:606
--- Comment #3 from rakdver at gcc dot gnu dot org 2007-03-08 15:46 --- Caused by my recent patch. -- rakdver at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rakdver at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-03-08 15:46:36 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31085
[Bug c/28368] -std=c89 doesn't warn about gcc's "?:" extension
--- Comment #6 from manu at gcc dot gnu dot org 2007-03-08 15:52 --- (In reply to comment #5) > Subject: Re: -std=c89 doesn't warn about gcc's "?:" extension > > On Wed, 7 Mar 2007, manu at gcc dot gnu dot org wrote: > > > Sorry, I still don't understand what is the difference between -std=c89 and > > -std=gnu89. > > -std=c89 accepts C89 programs that conflict with the GNU C89 language. > For example, ones using "inline" or "asm" as an identifier, or using any > non-reserved identifier predefined as a macro in GNU C (such as "linux" or > "i386") or using trigraphs. > That clarifies all perfectly. I think it is not as clear in the manual but perhaps I am a bit slow. Maybe in -std= it should say: gnu89 - Default, ISO C90 plus GNU extensions (including some C99 fea‐ - tures). + Default, subset of ISO C90 that doesn't conflict + with GNU extensions (including some C99 features + that conflict with C90) In any case, this bug seems invalid to me. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28368
[Bug ada/26797] [4.3 regression] ACATS cxh1001 fails
--- Comment #27 from baldrick at free dot fr 2007-03-08 16:06 --- Subject: Re: [4.3 regression] ACATS cxh1001 fails > > y = __builtin_nop(x); valid = (y>=lower_bound && y <=upper_bound); > > The point is that the intrinsic would be opaque to the optimizers, > > and would only be lowered to the identity function *after* the tree > > optimizers have run. One annoyance is that presumably intrinsics > > would be needed for all integer and float precisions, eg > > __builtin_nop8, __builtin_nop16, etc. > > More than each precision. The VIEW_CONVERT_EXPR is to the base type > and there can be an unlimited number of them for each precision. I don't see what the problem is - you don't have to convert to the base type, you can always convert to some standard type of that precision, eg int32, before calling the builtin. > Because it has to work with arbitrary types, a builtin won't do it. See above. > We could certainly add a new tree expression that says "don't look through > this for VRP purposes", but we already have V_C_E. Sure, it's just that overloading V_C_E like this feels somehow wrong to me. However I haven't been able to put my finger on any technical obstacle to this use of V_C_E. Ciao, D. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26797
[Bug fortran/31073] symbol names are not created with stdcall syntax
--- Comment #2 from wt at simpack dot de 2007-03-08 16:17 --- the docs say: gfortran --target-help ... --add-stdcall-aliasExport symbols with and without @nn --disable-stdcall-fixupDon't link _sym to [EMAIL PROTECTED] --enable-stdcall-fixup Link _sym to [EMAIL PROTECTED] without warnings ... -mrtd Alternate calling convention None of the first three options is accepted by gfortran, e.g.: gfortran -c --add-stdcall-alias simple.f f951.exe: error: unrecognized command line option "-fadd-stdcall-alias" Other source in the web (e.g.: http://04.code-hosting.com/Fortran/1509485-g95---how-to-build-a-DLL ) point out the -mrtd would be the option to do the trick. None of that works. So I want to suggest that this really is a bug if a document command line options causes the compiler to not compile. Additionally this disables the generation of symbol names in stdcall syntax. -- wt at simpack dot de changed: What|Removed |Added Severity|normal |blocker http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31073
[Bug fortran/31086] New: ICE in fold_convert, at fold-const.c:2331
The code below causes an ICE with r122699 (20070308). An older version I happened to have around, gfortran-20070220, crashed as well. $> cat ice.f90 MODULE class_dummy_atom_types TYPE :: dummy_atom_list TYPE(dummy_atom), DIMENSION(:), POINTER :: table END TYPE TYPE :: dummy_atom TYPE(dummy_atom_private), POINTER :: p END TYPE TYPE :: dummy_atom_private TYPE(dummy_atom_list) :: neighbours END TYPE END MODULE MODULE class_dummy_atom_model_type USE class_dummy_atom_types, ONLY: dummy_atom_list TYPE :: dummy_atom_model TYPE(dummy_atom_list) :: atoms END TYPE END MODULE MODULE test_class_intensity_private CONTAINS SUBROUTINE change_phase(atom) USE class_dummy_atom_types TYPE(dummy_atom), INTENT(inout) :: atom END SUBROUTINE SUBROUTINE simulate_cube() USE class_dummy_atom_types USE class_dummy_atom_model_type TYPE(dummy_atom) :: atom TYPE(dummy_atom_model) :: dam atom = dam%atoms%table(1) END SUBROUTINE END MODULE $> gfortran-svn -g -Wall ice.f90 ice.f90: In function 'simulate_cube': ice.f90:25: internal compiler error: in fold_convert, at fold-const.c:2331 Please submit a full bug report, $> gfortran-svn -v gcc version 4.3.0 20070308 (experimental) -- Summary: ICE in fold_convert, at fold-const.c:2331 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dfranke at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31086
[Bug c/30475] assert(int+100 > int) optimized away
--- Comment #55 from js at linuxtv dot org 2007-03-08 16:22 --- Point taken. I was misled by the mentioning of C99 6.3.1.3 in comment #18, that this would apply to integer conversion. Funnily enough, C99 3.4.3 even says "An example of undefined behavior is the behavior on integer overflow." I should've read that one more thoroughly. C99 Annex H (Informative) says: "Cs unsigned integer types are modulo in the LIA−1 sense in that overflows or out-of-bounds results silently wrap. An implementation that defines signed integer types as also being modulo need not detect integer overflow, in which case, only integer divide-by-zero need be detected." Which suggests that implmentations define signed integer overflow semantics, but maybe it's just bad wording, and anyway it's not part of the standard proper. Sorry for the noise and thanks for the C lesson. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30475
[Bug fortran/31086] ICE in fold_convert, at fold-const.c:2331
--- Comment #1 from dfranke at gcc dot gnu dot org 2007-03-08 16:27 --- I could reduce the testcase slightly. New version: $> cat ice.f90 MODULE class_dummy_atom_types TYPE :: dummy_atom_list TYPE(dummy_atom), DIMENSION(:), POINTER :: table END TYPE TYPE :: dummy_atom TYPE(dummy_atom_list) :: neighbours END TYPE TYPE :: dummy_atom_model TYPE(dummy_atom_list) :: atoms END TYPE END MODULE MODULE test_class_intensity_private CONTAINS SUBROUTINE change_phase(atom) USE class_dummy_atom_types TYPE(dummy_atom), INTENT(inout) :: atom END SUBROUTINE SUBROUTINE simulate_cube() USE class_dummy_atom_types TYPE(dummy_atom) :: atom TYPE(dummy_atom_model) :: dam atom = dam%atoms%table(1) END SUBROUTINE END MODULE $> gfortran-svn -g -Wall ice.f90 ice.f90: In function 'simulate_cube': ice.f90:17: internal compiler error: in fold_convert, at fold-const.c:2331 Please submit a full bug report, -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31086
[Bug fortran/30531] allocatable component and intent(out) yield ICE in fold_convert
--- Comment #8 from dfranke at gcc dot gnu dot org 2007-03-08 16:36 --- Paul, could you have a look at PR31086? I just filed it before I had a look here. It may be a dupe, but if so, with a different testcase ... -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30531
[Bug middle-end/31058] overflow warnings should not be enabled with -Wall
--- Comment #22 from rguenth at gcc dot gnu dot org 2007-03-08 16:38
---
Note that one reason we do not optimize the dead code is the stupidity of VRP
dealing with the IL in the second pass. While in the first pass VRP figures
out a range of [0,5] for w_6 in
:
uexp.1_1 = uexp;
if (uexp.1_1 <= 159) goto ; else goto ;
:;
D.1770_3 = 160 - uexp.1_1;
D.1778_5 = D.1770_3 >> 5;
w_6 = (int) D.1778_5;
in the second VRP pass we get w_6 as varying... Appearantly the difference
starts with the
D.1778_5 = D.1770_3 >> 5;
statement where the first pass gets [0, 5] and the second [0, +INF]. It
looks like this is because the first pass sees
D.1778_5 = D.1770_3 / 32;
instead. It seems to be the VRP pass itself calling fold_stmt on the
division and producing the (unhandled) division. Fixing that makes the
warning (and the dead code) go away.
Index: gcc/tree-vrp.c
===
*** gcc/tree-vrp.c (revision 122691)
--- gcc/tree-vrp.c (working copy)
*** extract_range_from_binary_expr (value_ra
*** 1568,1573
--- 1568,1574
&& code != CEIL_DIV_EXPR
&& code != EXACT_DIV_EXPR
&& code != ROUND_DIV_EXPR
+ && code != RSHIFT_EXPR
&& code != MIN_EXPR
&& code != MAX_EXPR
&& code != BIT_AND_EXPR
*** extract_range_from_binary_expr (value_ra
*** 1735,1741
|| code == FLOOR_DIV_EXPR
|| code == CEIL_DIV_EXPR
|| code == EXACT_DIV_EXPR
! || code == ROUND_DIV_EXPR)
{
tree val[4];
size_t i;
--- 1736,1743
|| code == FLOOR_DIV_EXPR
|| code == CEIL_DIV_EXPR
|| code == EXACT_DIV_EXPR
! || code == ROUND_DIV_EXPR
! || code == RSHIFT_EXPR)
{
tree val[4];
size_t i;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31058
[Bug ada/26797] [4.3 regression] ACATS cxh1001 fails
--- Comment #28 from kenner at vlsi1 dot ultra dot nyu dot edu 2007-03-08 16:52 --- Subject: Re: [4.3 regression] ACATS cxh1001 fails > I don't see what the problem is - you don't have to convert to the base > type, you can always convert to some standard type of that precision, > eg int32, before calling the builtin. Sure, but it's extra tree nodes and more to do. See below. > Sure, it's just that overloading V_C_E like this feels somehow wrong to me. Why? It's not "overloading". V_C_E of an expression E of type X to type Y means "interpret the bits of E as if it were type Y and not type X". If Y is X'Base, then interpreting E as being Y means that it can now have all the values of Y. In other words, we could only change a V_C_E to a NOP_EXPR if we can prove that the value of E is in range of *both* X and Y. Of course, we still have a bit of a mess here in that the real point is a confusion between what in Ada is called a Bounded Error and C's notion of "undefined" (Ada's "erroneous"). But I think we can do better in this area: we just haven't gotten to take a really good look at it. > However I haven't been able to put my finger on any technical obstacle to > this use of V_C_E. Nor can I ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26797
[Bug c/31087] New: gcc 323 reports "output filename specified twice error" for simple x.c compilation
Following an applied update, our gcc attempts for all c source files report: "output filename specified twice error". As best I can tell, the applied update was to move from 3.2.3-34 to gcc-3.2.3-56, however the reported version information seems to indicate the update was not entirely successful. I could find no information regarding anyone else with this issue. If this is not a gcc bug, please let me know where else I can look. As well, if more information is required, I am happy to oblige. thx, dr Produced output: >> gcc -v hello.c Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.2.3/specs Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/u sr/share/info --enable-shared --enable-threads=posix --disable-checking --with-s ystem-zlib --enable-__cxa_atexit --host=i386-redhat-linux Thread model: posix gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-34) /usr/lib/gcc-lib/i386-redhat-linux/3.2.3/cc1 -lang-c -v -iprefix /usr/bin/gcc_3 23/../lib/gcc-lib/i386-redhat-linux/3.2.3/ -D__GNUC__=3 -D__GNUC_MINOR__=2 -D__G NUC_PATCHLEVEL__=3 2 -D__GXX_ABI_VERSION=102 -D__ELF__ -Dunix -D__gnu_linux__ -D linux -D__ELF__ -D__unix__ -D__gnu_linux__ -D__linux__ -D__unix -D__linux -Asyst em=posix -D__NO_INLINE__ -D__STDC_HOSTED__=1 -Acpu=i386 -Amachine=i386 -Di386 -D __i386 -D__i386__ -D__tune_i386__ hello.c -quiet -dumpbase hello.c -version -o / tmp/ccg34n5a.s cc1: output filename specified twice GNU CPP version 3.2.3 20030502 (Red Hat Linux 3.2.3-56) (cpplib) (i386 Linux/ELF ) -- Summary: gcc 323 reports "output filename specified twice error" for simple x.c compilation Product: gcc Version: 3.2.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: droessle at us dot ibm dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31087
[Bug target/31073] symbol names are not created with stdcall syntax
--- Comment #3 from burnus at gcc dot gnu dot org 2007-03-08 17:06 --- > gfortran --target-help > --add-stdcall-aliasExport symbols with and without @nn > --disable-stdcall-fixupDon't link _sym to [EMAIL PROTECTED] > --enable-stdcall-fixup Link _sym to [EMAIL PROTECTED] without > warnings I couldn't find anything about this in the .texi documentation, but anyway this is target specific and has nothing to do with the Fortran frontend. It seems as if --add-stdcall-alias is indeed what you want, but reading the manpage -mrtd seems to do something different and -mrtd seems to work. => component: Target -- burnus at gcc dot gnu dot org changed: What|Removed |Added Component|fortran |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31073
[Bug tree-optimization/31085] [4.3 Regression] internal compiler error: in create_mem_ref, at tree-ssa-address.c:606
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c |tree-optimization Summary|internal compiler error: in |[4.3 Regression] internal |create_mem_ref, at tree-ssa-|compiler error: in |address.c:606 |create_mem_ref, at tree-ssa- ||address.c:606 Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31085
[Bug driver/31087] gcc 323 reports "output filename specified twice error" for simple x.c compilation
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-03-08 17:37 --- "3.2.3-34 to gcc-3.2.3-56", well we don't have multiple releases of 3.2.3. This should be reported to redhat first. Also 3.2.x is no longer being updated and has not been for a while now. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c |driver http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31087
[Bug c++/31078] [4.3 Regression] warning: same canonical type node for different types with const strings
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-03-08 17:40 --- > I thought we eventually agreed that it should be a plain internal_error. Not until right before the release: http://gcc.gnu.org/ml/gcc-patches/2007-01/msg01850.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31078
[Bug c++/31078] [4.3 Regression] warning: same canonical type node for different types with const strings
--- Comment #7 from manu at gcc dot gnu dot org 2007-03-08 17:46 --- (In reply to comment #6) > > I thought we eventually agreed that it should be a plain internal_error. > > Not until right before the release: > http://gcc.gnu.org/ml/gcc-patches/2007-01/msg01850.html > Nevertheless, I think we should mention that "this is a bug, please report it", so early testers would know what is going on. -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31078
[Bug target/31073] symbol names are not created with stdcall syntax
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-03-08 17:54 --- >gfortran --target-help > ... > --add-stdcall-aliasExport symbols with and without @nn > --disable-stdcall-fixupDon't link _sym to [EMAIL PROTECTED] > --enable-stdcall-fixup Link _sym to [EMAIL PROTECTED] without > warnings Those are most likely assembler or linker options, which you can supply using -Wa,--option or -Wl,--option depending on if they are an assembler or linker option. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|blocker |normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31073
[Bug target/31073] symbol names are not created with stdcall syntax
--- Comment #5 from kargl at gcc dot gnu dot org 2007-03-08 17:58 --- > Other source in the web (e.g.: > http://04.code-hosting.com/Fortran/1509485-g95---how-to-build-a-DLL ) > point out the -mrtd would be the option to do the trick. > None of that works. What g95 does is on absolutely no relevance. It is a different compiler. -- kargl at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31073
[Bug fortran/30531] allocatable component and intent(out) yield ICE in fold_convert
--- Comment #9 from paulthomas2 at wanadoo dot fr 2007-03-08 18:12 --- Subject: Re: allocatable component and intent(out) yield ICE in fold_convert Daniel, > --- Comment #8 from dfranke at gcc dot gnu dot org 2007-03-08 16:36 > --- > Paul, could you have a look at PR31086? I just filed it before I had a look > here. It may be a dupe, but if so, with a different testcase ... > I suspect that it is indeed a duplicate - of pr30531. I'll take a look at both this weekend. Thanks for bringing it to my attention. As it happens, one of my Bugzilla searches includes your name as reporter - I find that you are one of those that consistently provide humdingers:) Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30531
[Bug c/31088] New: Building cross-compiler with newlib-1.15.0 and binutils-2.17 fails in libssp
The symptom is that compilation aborts as follows gcc-4.1.2/libssp/ssp.c: In function '__guard_setup': ../../../gcc-4.1.2/libssp/ssp.c:70: warning: implicit declaration of function 'open' ../../../gcc-4.1.2/libssp/ssp.c:70: error: 'O_RDONLY' undeclared (first use in this function) BACKGROUND I am compiling a cross compiler for an ARM processor and newlib. WORKFLOW tar xvfz ../src/rlx_dist/newlib-1.15.0.tar.gz tar xvfj ../src/rlx_dist/gcc-4.1.2.tar.bz2 tar xvfj ../src/rlx_dist/binutils-2.17.tar.bz2 ... cd gcc-4.1.2-arm-elf ../gcc-4.1.2/configure --srcdir=../gcc-4.1.2 --target=arm-elf \ --with-cpu=arm9 --with-newlib --disable-threads --disable-multilib \ --disable-nls --enable-languages=c \ --prefix=/rlxb2/arm-elf PROBLEM At this point gcc-4.1.2-arm-elf/arm-elf/libssp/config.h does not define HAVE_FCNTL_H and neither many others. Copying manuslly the header files from newlib-1.15.0/newlib/libc/include/ to $prefix/arm-elf/include AND manually editing gcc-4.1.2-arm-elf/arm-elf/libssp/config.h does the trick. Then make and make install complete without complaining. In any case, configure produces a disfunctional cc-4.1.2-arm-elf/arm-elf/libssp/config.h. For your information. -- Summary: Building cross-compiler with newlib-1.15.0 and binutils- 2.17 fails in libssp Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rlemieu at cooptel dot qc dot ca http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31088
[Bug fortran/30880] Derived types with default value -- function with ENTRY: rejected at compile time
--- Comment #3 from patchapp at dberlin dot org 2007-03-08 18:50 --- Subject: Bug number PR30880 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-03/msg00497.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30880
[Bug c/31072] [4.2/4.3 Rgression] Wrong code for volatile var with initalization and optimization
--- Comment #8 from pinskia at gcc dot gnu dot org 2007-03-08 19:15 ---
Here is the patch which I am testing:
Index: c-decl.c
===
--- c-decl.c(revision 1532)
+++ c-decl.c(working copy)
@@ -1650,11 +1650,7 @@ merge_decls (tree newdecl, tree olddecl,
TREE_READONLY (olddecl) = 1;
if (TREE_THIS_VOLATILE (newdecl))
-{
- TREE_THIS_VOLATILE (olddecl) = 1;
- if (TREE_CODE (newdecl) == VAR_DECL)
- make_var_volatile (newdecl);
-}
+TREE_THIS_VOLATILE (olddecl) = 1;
/* Merge deprecatedness. */
if (TREE_DEPRECATED (newdecl))
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31072
[Bug fortran/30981] [4.2, 4.1 only] a ** exp fails for integer exponents if exp is "-huge()-1" (endless loop)
--- Comment #16 from tkoenig at gcc dot gnu dot org 2007-03-08 19:27 --- Subject: Bug 30981 Author: tkoenig Date: Thu Mar 8 19:26:55 2007 New Revision: 122708 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122708 Log: 2007-03-08 Thomas Koenig <[EMAIL PROTECTED]> PR libfortran/30981 Backport from trunk. * m4/pow_m4: Use appropriate unsigned int type for u. * generated/pow_c10_i16.c: Regenerated. * generated/pow_c10_i4.c: Regenerated. * generated/pow_c10_i8.c: Regenerated. * generated/pow_c16_i16.c: Regenerated. * generated/pow_c16_i4.c: Regenerated. * generated/pow_c16_i8.c: Regenerated. * generated/pow_c4_i16.c: Regenerated. * generated/pow_c4_i4.c: Regenerated. * generated/pow_c4_i8.c: Regenerated. * generated/pow_c8_i16.c: Regenerated. * generated/pow_c8_i4.c: Regenerated. * generated/pow_c8_i8.c: Regenerated. * generated/pow_i16_i16.c: Regenerated. * generated/pow_i16_i4.c: Regenerated. * generated/pow_i16_i8.c: Regenerated. * generated/pow_i4_i16.c: Regenerated. * generated/pow_i4_i4.c: Regenerated. * generated/pow_i4_i8.c: Regenerated. * generated/pow_i8_i16.c: Regenerated. * generated/pow_i8_i4.c: Regenerated. * generated/pow_i8_i8.c: Regenerated. * generated/pow_r10_i16.c: Regenerated. * generated/pow_r10_i4.c: Regenerated. * generated/pow_r10_i8.c: Regenerated. * generated/pow_r16_i16.c: Regenerated. * generated/pow_r16_i4.c: Regenerated. * generated/pow_r16_i8.c: Regenerated. * generated/pow_r4_i16.c: Regenerated. * generated/pow_r4_i4.c: Regenerated. * generated/pow_r4_i8.c: Regenerated. * generated/pow_r8_i16.c: Regenerated. * generated/pow_r8_i4.c: Regenerated. * generated/pow_r8_i8.c: Regenerated. 2007-03-08 Thomas Koenig <[EMAIL PROTECTED]> PR libfortran/30981 Backport from trunk. * gfortran.dg/integer_exponentiation_1.f90: New test. Added: branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/integer_exponentiation_1.f90 Modified: branches/gcc-4_2-branch/gcc/testsuite/ChangeLog branches/gcc-4_2-branch/libgfortran/ChangeLog branches/gcc-4_2-branch/libgfortran/generated/pow_c10_i16.c branches/gcc-4_2-branch/libgfortran/generated/pow_c10_i4.c branches/gcc-4_2-branch/libgfortran/generated/pow_c10_i8.c branches/gcc-4_2-branch/libgfortran/generated/pow_c16_i16.c branches/gcc-4_2-branch/libgfortran/generated/pow_c16_i4.c branches/gcc-4_2-branch/libgfortran/generated/pow_c16_i8.c branches/gcc-4_2-branch/libgfortran/generated/pow_c4_i16.c branches/gcc-4_2-branch/libgfortran/generated/pow_c4_i4.c branches/gcc-4_2-branch/libgfortran/generated/pow_c4_i8.c branches/gcc-4_2-branch/libgfortran/generated/pow_c8_i16.c branches/gcc-4_2-branch/libgfortran/generated/pow_c8_i4.c branches/gcc-4_2-branch/libgfortran/generated/pow_c8_i8.c branches/gcc-4_2-branch/libgfortran/generated/pow_i16_i16.c branches/gcc-4_2-branch/libgfortran/generated/pow_i16_i4.c branches/gcc-4_2-branch/libgfortran/generated/pow_i16_i8.c branches/gcc-4_2-branch/libgfortran/generated/pow_i4_i16.c branches/gcc-4_2-branch/libgfortran/generated/pow_i4_i4.c branches/gcc-4_2-branch/libgfortran/generated/pow_i4_i8.c branches/gcc-4_2-branch/libgfortran/generated/pow_i8_i16.c branches/gcc-4_2-branch/libgfortran/generated/pow_i8_i4.c branches/gcc-4_2-branch/libgfortran/generated/pow_i8_i8.c branches/gcc-4_2-branch/libgfortran/generated/pow_r10_i16.c branches/gcc-4_2-branch/libgfortran/generated/pow_r10_i4.c branches/gcc-4_2-branch/libgfortran/generated/pow_r10_i8.c branches/gcc-4_2-branch/libgfortran/generated/pow_r16_i16.c branches/gcc-4_2-branch/libgfortran/generated/pow_r16_i4.c branches/gcc-4_2-branch/libgfortran/generated/pow_r16_i8.c branches/gcc-4_2-branch/libgfortran/generated/pow_r4_i16.c branches/gcc-4_2-branch/libgfortran/generated/pow_r4_i4.c branches/gcc-4_2-branch/libgfortran/generated/pow_r4_i8.c branches/gcc-4_2-branch/libgfortran/generated/pow_r8_i16.c branches/gcc-4_2-branch/libgfortran/generated/pow_r8_i4.c branches/gcc-4_2-branch/libgfortran/generated/pow_r8_i8.c branches/gcc-4_2-branch/libgfortran/m4/pow.m4 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30981
[Bug driver/31089] New: gccspec.c doesn't handle -x options
gccspec.c assumes that it can detect Objective-C files because they have a .m extension, but a user can pass '-ObjC' or '-x objective-c' or '-x c' to override the extension. -- Summary: gccspec.c doesn't handle -x options Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: geoffk at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31089
[Bug objc/31013] [4.3 Regression] objc PCH is broken on powerpc-darwin again
--- Comment #4 from geoffk at gcc dot gnu dot org 2007-03-08 19:56 --- Subject: Bug 31013 Author: geoffk Date: Thu Mar 8 19:56:37 2007 New Revision: 122709 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122709 Log: PR 31013 * gccspec.c (lang_specific_driver): Do nothing when NEXT_OBJC_RUNTIME is declared. * config/darwin.h (REAL_LIBGCC_SPEC): When -fgnu-runtime is passed, use shared libgcc. Modified: trunk/gcc/ChangeLog trunk/gcc/config/darwin.h trunk/gcc/gccspec.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31013
[Bug tree-optimization/31090] New: Revision 121302 causes 30% performance regression
Revision 121302 causes 30% performance regression on Core 2 Duo. -- Summary: Revision 121302 causes 30% performance regression Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl at lucon dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31090
[Bug tree-optimization/31090] Revision 121302 causes 30% performance regression
--- Comment #1 from hjl at lucon dot org 2007-03-08 20:04 --- Created an attachment (id=13173) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13173&action=view) A testcase /usr/gcc-next/bin/gfortran -c -O2 -o 301.o test597.f90 /usr/gcc-next/bin/gfortran -o 301 301.o -Wl,-rpath,/usr/gcc-4.3/lib64 /usr/gcc-last/bin/gfortran -c -O2 -o 302.o test597.f90 /usr/gcc-next/bin/gfortran -o 302 302.o -Wl,-rpath,/usr/gcc-4.3/lib64 time ./301 0.92user 0.00system 0:00.93elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+2325minor)pagefaults 0swaps time ./302 1.24user 0.00system 0:01.24elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+2325minor)pagefaults 0swaps [EMAIL PROTECTED] 597]$ /usr/gcc-next/bin/gfortran -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: /net/gnu-13/export/gnu/src/gcc-next/gcc/configure --enable-clocale=gnu --with-system-zlib --enable-decimal-float=yes --with-demangler-in-ld --enable-languages=c,fortran --enable-shared --enable-threads=posix --enable-haifa --enable-checking=assert --prefix=/usr/gcc-next --with-local-prefix=/usr/local Thread model: posix gcc version 4.3.0 20070129 (experimental) [trunk revision 121301] [EMAIL PROTECTED] 597]$ /usr/gcc-last/bin/gfortran -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: /net/gnu-13/export/gnu/src/gcc-last/gcc/configure --enable-clocale=gnu --with-system-zlib --enable-decimal-float=yes --with-demangler-in-ld --enable-languages=c,fortran --enable-shared --enable-threads=posix --enable-haifa --enable-checking=assert --prefix=/usr/gcc-last --with-local-prefix=/usr/local Thread model: posix gcc version 4.3.0 20070129 (experimental) [trunk revision 121302] -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31090
[Bug tree-optimization/30604] Unable to coalesce ssa_names and which are marked as MUST COALESCE
--- Comment #7 from amacleod at redhat dot com 2007-03-08 20:12 --- Looking at the original testcase, the complaint is that _t_8232 and _t_3 are both used in the PHI definition of _t_7. (using mainline from march 5th) ie, _t_7(ab) = PHI <, _t_8232, ... , _t_3, ...> That definition occurs in BB2509. Because its an abnormal edge, all three must be coalescable. _t_8232 is defined in BB 2315, but _t_3 is live on entry and through this block, meaning they have different values and are live at the same time, so they cannot be coalesced The listing looks OK after ccp2, but in the listing after the FRE pass _t_3 becomes live on entry to this block, and it wasn't before. I can't really read the detailed output from FRE, but it does seem to have replaced a bunch of expressions with _t_3, so that would appear to be the culprit. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30604
[Bug tree-optimization/30604] Unable to coalesce ssa_names and which are marked as MUST COALESCE
--- Comment #8 from amacleod at redhat dot com 2007-03-08 20:20 --- -fno-tree-fre makes the test case compile, which is further indication FRE is the problem. -- amacleod at redhat dot com changed: What|Removed |Added CC||dnovillo at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30604
[Bug objc/31013] [4.3 Regression] objc PCH is broken on powerpc-darwin again
--- Comment #5 from geoffk at gcc dot gnu dot org 2007-03-08 20:31 --- This should be fixed now. -- geoffk at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31013
[Bug fortran/30981] [4.1 only] a ** exp fails for integer exponents if exp is "-huge()-1" (endless loop)
--- Comment #17 from tkoenig at gcc dot gnu dot org 2007-03-08 20:38 --- Fixed on trunk and 4.2. Closing. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Summary|[4.2, 4.1 only] a ** exp|[4.1 only] a ** exp fails |fails for integer exponents |for integer exponents if exp |if exp is "-huge()-1" |is "-huge()-1" (endless |(endless loop) |loop) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30981
[Bug c++/31092] New: variable-size array confused by exceptions
On the arm platform, it seems that throwing and catching an exception clobbers
variable-size arrays. The following example exposes the bug:
#include
class exception{};
int main(int argc,char *argv[]) {
/*const*/ int size(32);
int test[size];
test[0] = 1234;
try {
throw exception();
}
catch (exception) {
}
assert(test[0] == 1234 && "array");
return(0);
}
Compiler specifics:
arm-unknown-linux-gnu-g++ -v
Using built-in specs.
Target: arm-unknown-linux-gnu
Configured with:
/var/tmp/cross/arm-unknown-linux-gnu/portage/gcc-4.1.1-r3/work/gcc-4.1.1/configure
--prefix=/usr --bindir=/usr/i686-pc-linux-gnu/arm-unknownu
Thread model: posix
gcc version 4.1.1 (Gentoo 4.1.1-r3)
$ arm-unknown-linux-gnu-g++ -static -o test_exception test_exception.cpp
$ ./test_exception
test_exception: test_exception.cpp:18: int main(int, char**): Assertion
`test[0] == 1234 && "array"' failed.
Aborted
It seems this problem was already present in the 3.3 series.
I would like to point out the following:
- in a real-world program, code paths with exceptions thrown are rarely
executed, so bugs caused by this may be very hard to debug
- it is quite easy to us evariable-size arrays unintentionally by leaving out
the const keyword
- fortunately, using the -pedantic option will find all occurances of variable
size arrays.
Rupert
PS: the only thing done by the preprocessor is the expansion of the assert
macro, but I can also provide the preprocessed program if needed.
--
Summary: variable-size array confused by exceptions
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rks at mur dot at
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: arm-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31092
[Bug libgcj/31093] New: Multicast PromiscuousTraffic
See the explanation and test jar at http://wiki.jboss.org/wiki/Wiki.jsp?page=PromiscuousTraffic There are 2 problems. $ gij -jar promiscuoustraffic.jar java.lang.IllegalArgumentException: Invalid ttl: 0 at java.net.MulticastSocket.setTimeToLive(libgcj.so.8rh) at org.jboss.test.cluster.test.PromiscuousTrafficTester.setUpSockets(PromiscuousTrafficTester.java:134) at org.jboss.test.cluster.test.PromiscuousTrafficTester.(PromiscuousTrafficTester.java:64) at org.jboss.test.cluster.test.PromiscuousTrafficTester.main(PromiscuousTrafficTester.java:182) 0 is a valid value for ttl however. When giving it 1 the test runs. But does result in: Bad news. Detected the Promiscuous Traffic problem. Received Hello on undesired address /231.2.2.2 -- Summary: Multicast PromiscuousTraffic Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcj AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mark at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31093
[Bug fortran/30873] [4.1 and 4.2 only] ENTRY without explict RESULT does not work for recursive functions
--- Comment #6 from burnus at gcc dot gnu dot org 2007-03-08 21:06 --- Subject: Bug 30873 Author: burnus Date: Thu Mar 8 21:06:37 2007 New Revision: 122711 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122711 Log: 2007-03-08 Paul Thomas <[EMAIL PROTECTED]> Tobias Burnus <[EMAIL PROTECTED]> PR fortran/30873 * decl.c (gfc_match_entry): Remove erroneous entry result check. 2007-03-08 Paul Thomas <[EMAIL PROTECTED]> Tobias Burnus <[EMAIL PROTECTED]> PR fortran/30873 * gfortran.dg/entry_9.f90: New test. Added: branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/entry_9.f90 Modified: branches/gcc-4_2-branch/gcc/fortran/ChangeLog branches/gcc-4_2-branch/gcc/fortran/decl.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30873
[Bug fortran/30873] [4.1 only] ENTRY without explict RESULT does not work for recursive functions
--- Comment #7 from burnus at gcc dot gnu dot org 2007-03-08 21:07 --- Fixed in 4.2 (and 4.3), not a wrong-code bug => Won't fix for 4.1. Close. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Summary|[4.1 and 4.2 only] ENTRY|[4.1 only] ENTRY without |without explict RESULT does |explict RESULT does not work |not work for recursive |for recursive functions |functions | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30873
[Bug middle-end/31058] overflow warnings should not be enabled with -Wall
--- Comment #23 from mueller at gcc dot gnu dot org 2007-03-08 21:32 --- Great, this patch makes a -fprefetch-loop-arrays bootstrap succeed. I think LSHIFT_EXPR should be handled similar. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31058
[Bug libstdc++/31061] error with '-D_GLIBCXX_DEBUG'
--- Comment #4 from ulf at linuxmail dot org 2007-03-08 21:33 --- Yes, I guess you're right. Sorry for the noice, I should have checked it more closely before posting. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31061
[Bug fortran/30947] intrinsic: ALARM
--- Comment #1 from dfranke at gcc dot gnu dot org 2007-03-08 21:45 --- Subject: Bug 30947 Author: dfranke Date: Thu Mar 8 21:45:22 2007 New Revision: 122715 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122715 Log: 2007-03-08 Daniel Franke <[EMAIL PROTECTED]> PR fortran/30947 * check.c (gfc_check_alarm_sub): Added check for default integer kind of status argument. * iresolve.c (gfc_resolve_alarm_sub): Removed conversion of status argument. * intrinsic.texi (ALARM): Extended documentation. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/check.c trunk/gcc/fortran/intrinsic.texi trunk/gcc/fortran/iresolve.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30947
[Bug fortran/30947] intrinsic: ALARM
--- Comment #2 from dfranke at gcc dot gnu dot org 2007-03-08 21:46 --- Subject: Bug 30947 Author: dfranke Date: Thu Mar 8 21:46:16 2007 New Revision: 122716 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122716 Log: 2007-03-08 Daniel Franke <[EMAIL PROTECTED]> PR fortran/30947 * intrinsics/signal.c (alarm_sub_int): Avoid SEGFAULT with integer arguments. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/intrinsics/signal.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30947
[Bug c++/29164] Overloaded operator delete[] doesn't get called
--- Comment #5 from fang at csl dot cornell dot edu 2007-03-08 21:49 --- Ouch, this one seems particularly nasty to me... seeings as this isn't a regression (at least from 2.95), I don't expect this to be fixed for 4.2. Is there any chance of this getting attention on the (4.3) mainline? I'm having trouble finding an elegant workaround to this -- I'm expecting a smart pointer-to-array class to 'do the right thing' during destruction (call the right operator delete []), but I can't just force it to call Class::operator delete [], if the Class doesn't override it. I just might have to "use the force" (SFINAE)... Incidentally, also known to fail 3.4.6, 4.0.1, 4.1.0. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29164
[Bug fortran/30947] intrinsic: ALARM
--- Comment #3 from dfranke at gcc dot gnu dot org 2007-03-08 21:50 --- Subject: Bug 30947 Author: dfranke Date: Thu Mar 8 21:49:59 2007 New Revision: 122717 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122717 Log: 2007-03-08 Daniel Franke <[EMAIL PROTECTED]> Backport from trunk: PR fortran/30947 * check.c (gfc_check_alarm_sub): Added check for default integer kind of status argument. * iresolve.c (gfc_resolve_alarm_sub): Removed conversion of status argument. * intrinsic.texi (ALARM): Extended documentation. Modified: branches/gcc-4_2-branch/gcc/fortran/ChangeLog branches/gcc-4_2-branch/gcc/fortran/check.c branches/gcc-4_2-branch/gcc/fortran/intrinsic.texi branches/gcc-4_2-branch/gcc/fortran/iresolve.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30947
[Bug fortran/30947] intrinsic: ALARM
--- Comment #4 from dfranke at gcc dot gnu dot org 2007-03-08 21:53 --- Subject: Bug 30947 Author: dfranke Date: Thu Mar 8 21:53:02 2007 New Revision: 122719 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122719 Log: 2007-03-08 Daniel Franke <[EMAIL PROTECTED]> Backport from trunk: PR fortran/30947 * intrinsics/signal.c (alarm_sub_int): Avoid SEGFAULT with integer arguments. Modified: branches/gcc-4_2-branch/libgfortran/ChangeLog branches/gcc-4_2-branch/libgfortran/intrinsics/signal.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30947
[Bug fortran/30947] intrinsic: ALARM
--- Comment #5 from dfranke at gcc dot gnu dot org 2007-03-08 21:56 --- With commits #1 to #4, the problem is only partially solved. As Brooks Moses [1] points out: "Thus, to make this work right, you'll still need to implement alarm_sub4 and alarm_sub8 library functions (along with alarm_sub_int4 and alarm_sub_int8), and have gfc_resolve_alarm_sub call the appropriate one depending on the kind of the STATUS argument. This is what the other intrinsics that use default-integer-only arguments do." [1] http://gcc.gnu.org/ml/fortran/2007-03/msg00146.html -- dfranke at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dfranke at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-03-03 10:23:07 |2007-03-08 21:56:56 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30947
[Bug libgcj/31093] Multicast PromiscuousTraffic
--- Comment #1 from cvs-commit at developer dot classpath dot org 2007-03-08 22:14 --- Subject: Bug 31093 CVSROOT:/cvsroot/classpath Module name:classpath Changes by: Tom Tromey 07/03/08 22:13:32 Modified files: . : ChangeLog java/net : MulticastSocket.java Log message: PR libgcj/31093: * java/net/MulticastSocket.java (setTimeToLive): Allow ttl==0. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/classpath/ChangeLog?cvsroot=classpath&r1=1.9148&r2=1.9149 http://cvs.savannah.gnu.org/viewcvs/classpath/java/net/MulticastSocket.java?cvsroot=classpath&r1=1.28&r2=1.29 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31093
[Bug tree-optimization/31085] [4.3 Regression] internal compiler error: in create_mem_ref, at tree-ssa-address.c:606
--- Comment #4 from rakdver at gcc dot gnu dot org 2007-03-08 22:36 --- Subject: Bug 31085 Author: rakdver Date: Thu Mar 8 22:36:47 2007 New Revision: 122724 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122724 Log: PR tree-optimization/31085 * tree-ssa-address.c (create_mem_ref): Fix test of type of base. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-address.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31085
[Bug tree-optimization/31085] [4.3 Regression] internal compiler error: in create_mem_ref, at tree-ssa-address.c:606
--- Comment #5 from rakdver at gcc dot gnu dot org 2007-03-08 22:37 --- Fixed. -- rakdver at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31085
[Bug c++/29164] Overloaded operator delete[] doesn't get called
--- Comment #6 from fang at csl dot cornell dot edu 2007-03-08 22:58
---
Subject: Re: Overloaded operator delete[] doesn't get called
This following test case is 'interesting':
>8 snip 8<-
#include
using std::cout;
class one_array_only {
private:
static one_array_only pool[256];
public:
static void * operator new[] (std::size_t size) throw() {
cout << "class new[] operator\n";
#if WTF
return pool;
#else
return NULL;
#endif
}
static void operator delete[] (void *p) throw() {
cout << "class delete[] operator\n";
}
};
one_array_only
one_array_only::pool[256];
int
main(int argc, char* argv[]) {
one_array_only* p = new one_array_only[12];
delete [] p;
return 0;
}
>8 snip 8<-
Above, in operator new[], If WTF is false, returning NULL, I reproduce the
same error (missing call to class operator delete []). If WTF is true
(returning pool), the right operator delete [] is called.
// output with WTF false
class new[] operator
// output with WTF true
class new[] operator
class delete[] operator
Tested on: powerpc-apple-darwin8-g++-4.0.1
Why on earth would the definition inside operator new[] influence whether
or not operator delete[] is called?
Fang
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29164
[Bug libgcj/31093] Multicast PromiscuousTraffic
--- Comment #2 from tromey at gcc dot gnu dot org 2007-03-08 22:59 --- With svn trunk and also the fc6 libgcj I get: opsy. gij PromiscuousTrafficTester Listening on address /229.10.11.12 Listening on address /229.10.11.13 Sending 'Hello' on /229.10.11.12:64000 java.lang.IllegalStateException: Did not receive 'Hello' as expected; got null at PromiscuousTrafficTester.test(PromiscuousTrafficTester.java:85) at PromiscuousTrafficTester.main(PromiscuousTrafficTester.java:182) I see a few FIXME comments in natPlainDatagramSocketImplPosix.cc relating to multicast. Maybe our implementation does not work properly at all. -- tromey at gcc dot gnu dot org changed: What|Removed |Added CC||tromey at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-03-08 22:59:08 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31093
[Bug other/28002] decNumber sources need GPL+exception for use in libgcc
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-03-08 23:38 --- http://gcc.gnu.org/ml/gcc-patches/2007-03/msg00481.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28002
[Bug c++/29164] Overloaded operator delete[] doesn't get called
--- Comment #7 from fang at csl dot cornell dot edu 2007-03-08 23:41
---
Subject: Re: Overloaded operator delete[] doesn't get called
> Above, in operator new[], If WTF is false, returning NULL, I reproduce the
> same error (missing call to class operator delete []). If WTF is true
> (returning pool), the right operator delete [] is called.
>
> // output with WTF false
> class new[] operator
>
> // output with WTF true
> class new[] operator
> class delete[] operator
>
> Tested on: powerpc-apple-darwin8-g++-4.0.1
The same result ALSO happens if I de-inline the class operator new/delete
[], and compile their definitions in a different translation unit:
->8 snip 8<---
// de-inlined class definitions
#include
#include "one_array_only.h"
using std::cout;
bool
one_array_only::allocated = false;
one_array_only
one_array_only::pool[256];
void*
one_array_only::operator new[] (std::size_t size) throw() {
cout << "class new[] operator\n";
#if WTF
return pool;// does not trigger bug
#else
return NULL;// triggers bug: no operator delete[] called
#endif
}
void
one_array_only::operator delete[] (void *p) throw() {
cout << "class delete[] operator\n";
}
->8 snip 8<---
The main translation unit is still calling one_array_only::operator
delete[](void*) (from an asm dump).
This suggests that one_array_only::operator delete[] is somehow being
mis-compiled.
Fang
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29164
