[Bug testsuite/31589] gcc.dg/vect failures due to missing target specifiers
--- Comment #7 from dorit at gcc dot gnu dot org 2007-05-01 07:59 --- Subject: Bug 31589 Author: dorit Date: Tue May 1 07:58:59 2007 New Revision: 124315 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124315 Log: PR testsuite/31589 * gcc.dg/vect/vect-iv-9.c: Added vect_int_mult target keyword to dg-final test. * gcc.dg/vect/vect-reduc-dot-u16b.c: Added vect_pack_trunc target keyword to dg-final test. * gcc.dg/vect/vect-iv-4.c: Likewise. * gcc.dg/vect/vect-widen-mult-u16.c: Likewise. * gcc.dg/vect/pr30771.c: Added vect_unapck target keyword to dg-final test. * gcc.dg/vect/vect-reduc-dot-u16a.c: Change variable type to avoid a cast. * gcc.dg/vect/no-section-anchors-vect-69.c: xfail on is64. * lib/target-supports.exp (check_effective_target_vect_widen_sum_hi_to_si): Added ia64. (check_effective_target_vect_widen_sum_qi_to_hi): Added ia64. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/vect/no-section-anchors-vect-69.c trunk/gcc/testsuite/gcc.dg/vect/pr30771.c trunk/gcc/testsuite/gcc.dg/vect/vect-iv-4.c trunk/gcc/testsuite/gcc.dg/vect/vect-iv-9.c trunk/gcc/testsuite/gcc.dg/vect/vect-reduc-dot-u16a.c trunk/gcc/testsuite/gcc.dg/vect/vect-reduc-dot-u16b.c trunk/gcc/testsuite/gcc.dg/vect/vect-widen-mult-u16.c trunk/gcc/testsuite/lib/target-supports.exp -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31589
[Bug tree-optimization/30252] [4.2 regression] miscompilation of sigc++-2.0 based code with -fstrict-aliasing
--- Comment #15 from pluto at agmk dot net 2007-05-01 08:58 --- (In reply to comment #14) typed_rep points to: N4sigc8internal14typed_slot_repINS_12bind_functorILin1ENS_16pointer_functor1IPvS4_EEPl -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30252
[Bug libgcj/30570] Word DEBUG used as a variable in VMAccessController.java breaks build
--- Comment #5 from rob1weld at aol dot com 2007-05-01 09:16 --- This make -i check report shows Java compiled with ZERO errors: http://gcc.gnu.org/ml/gcc-testresults/2007-04/msg01490.html gcc version 4.2.0 20070427 (prerelease) --- === libjava tests === Running target unix === libjava Summary === # of expected passes 7006 # of expected failures 12 # of untested testcases 8 --- Unfortunatly there are problems with the other tests but this is an instance of the SVN (in combination with the correctness of the tests) giving a supposed perfect result for Java (in compination with the many configure flags). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30570
[Bug c/31741] dfp tests failing - internal compiler error
--- Comment #2 from rob1weld at aol dot com 2007-05-01 10:19 --- Successfully _forced_ the compile on Cygwin platform and posted a seperate report about the segmentation fault issue at: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31761 After running make -i check on Cygwin compile I also got many dfp errors. Due to the use of the _exact_ same options for Cygwin as I used for Linux and _forcing_ the compile to complete I got an enormous number of error messages in other parts (not dfp) of the compile which made the make check report HUGE - so it was not posted. Suffice to say that the dfp errors occur on both platforms (when compiled with these ./configure options). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31741
[Bug fortran/22359] fseek intrinsic appears to be unimplemented
-- 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 URL|http://gcc.gnu.org/ml/fortra|http://gcc.gnu.org/ml/gcc- |n/2007-04/msg00562.html |patches/2007- ||05/msg00010.html Status|NEW |ASSIGNED Last reconfirmed|2005-12-30 19:36:48 |2007-05-01 10:55:49 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22359
[Bug rtl-optimization/31771] New: [4.3 Regression] g++.dg/gomp/pr26913.C ICEs
/home/richard/src/trunk2/gcc/testsuite/g++.dg/gomp/pr26913.C: In function 'void _Z3bazv.omp_fn.0(void*)':^M /home/richard/src/trunk2/gcc/testsuite/g++.dg/gomp/pr26913.C:14: error: unnecessary EH edge 5-6^M /home/richard/src/trunk2/gcc/testsuite/g++.dg/gomp/pr26913.C:14: internal compiler error: verify_flow_info failed^M Please submit a full bug report,^M with preprocessed source if appropriate.^M See URL:http://gcc.gnu.org/bugs.html for instructions.^M FAIL: g++.dg/gomp/pr26913.C (internal compiler error) FAIL: g++.dg/gomp/pr26913.C (test for excess errors) -- Summary: [4.3 Regression] g++.dg/gomp/pr26913.C ICEs Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rguenth at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31771
[Bug rtl-optimization/31771] [4.3 Regression] g++.dg/gomp/pr26913.C ICEs
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-05-01 11:17 --- Zdenek, this may be yours. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rakdver at gcc dot gnu dot ||org GCC target triplet||x86_64-*-*, i?86-*-* Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31771
[Bug c++/31724] [4.3 Regression] More same canonical type node fun
--- Comment #9 from dgregor at gcc dot gnu dot org 2007-05-01 13:32 --- The easy fix is to SET_TYPE_STRUCTURAL_EQUALITY (fulltype), which will force structural equality checks rather than use canonical types. I usually don't like this solution, but it's better than duplicating all of the build_array_type/build_cplus_array_type machinery. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31724
[Bug tree-optimization/30252] [4.2 regression] miscompilation of sigc++-2.0 based code with -fstrict-aliasing
--- Comment #16 from rguenth at gcc dot gnu dot org 2007-05-01 13:35
---
Created an attachment (id=13468)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13468action=view)
slightly simplified testcase
I don't see anything wrong with the testcase. I changed it to not take the
address of dummy, but pass zero instead. This reduces the diff of initial
aliasing to
- # _A_b1_61 = V_MAY_DEF _A_b1_54;
- # SFT.70_62 = V_MAY_DEF SFT.70_55;
- # SFT.71_63 = V_MAY_DEF SFT.71_56;
- # SFT.72_64 = V_MAY_DEF SFT.72_57;
- # SFT.73_65 = V_MAY_DEF SFT.73_58;
- # NONLOCAL.79_66 = V_MAY_DEF NONLOCAL.79_60;
+ # SFT.79_61 = V_MAY_DEF SFT.79_57;
this_41-rep_ = rep_42;
but before DCE (which makes a mess out of this testcase) we have practically
indentical dumps for A::bar() - Note that A::bar() is the offending function
that gets mis-optimized. We DCE the initialization of the function pointer so
we segfault at the indirect call to it.
@@ -78,21 +78,21 @@
sigc::slot0 A::bar() (this)
{
...
@@ -129,7 +129,7 @@
_A_func_2 = foo;
this_3 = (struct functor_base *) D.2378;
this_4 = this_3;
- # SFT.73_6 = V_MUST_DEF SFT.73_5;
+ # SFT.80_6 = V_MUST_DEF SFT.80_5;
D.2378.func_ptr_ = foo;
_A_functor_7 = D.2378;
# _A_b1_9 = V_MUST_DEF _A_b1_8;
@@ -151,33 +151,33 @@
this_24 = (struct functor_base *) this_23;
this_25 = this_24;
# D.2951_27 = V_MUST_DEF D.2951_26;
- # VUSE SFT.73_6;
+ # VUSE SFT.80_6;
D.2951 = D.2378;
- # SFT.70_50 = V_MAY_DEF SFT.70_49;
+ # SFT.77_50 = V_MAY_DEF SFT.77_49;
# VUSE D.2951_27;
this_20-functor_ = D.2951;
this_28 = D.2514.bound1_;
this_29 = D.2514.bound1_;
_A_argument_30 = _A_b1;
D.2953_31 = 0B;
- # SFT.70_68 = V_MUST_DEF SFT.70_50;
+ # SFT.77_63 = V_MUST_DEF SFT.77_50;
D.2514.bound1_.visited_ = D.2953_31;
functor_32 = D.2514;
# _A_b1_54 = V_MAY_DEF _A_b1_9;
- # SFT.70_55 = V_MAY_DEF SFT.70_68;
- # SFT.71_56 = V_MAY_DEF SFT.71_52;
- # SFT.72_57 = V_MAY_DEF SFT.72_45;
- # SFT.73_58 = V_MAY_DEF SFT.73_6;
- # NONLOCAL.79_59 = V_MAY_DEF NONLOCAL.79_53;
- D.3052_33 = operator new (20);
- this_34 = (struct typed_slot_repsigc::bind_functor-0x1,
sigc::pointer_functor1void*, void*, void* *) D.3052_33;
+ # SFT.77_55 = V_MAY_DEF SFT.77_63;
+ # SFT.78_56 = V_MAY_DEF SFT.78_52;
+ # SFT.79_57 = V_MAY_DEF SFT.79_45;
+ # SFT.80_58 = V_MAY_DEF SFT.80_6;
+ # NONLOCAL.86_59 = V_MAY_DEF NONLOCAL.86_53;
+ D.3059_33 = operator new (20);
+ this_34 = (struct typed_slot_repsigc::bind_functor-0x1,
sigc::pointer_functor1void*, void*, void* *) D.3059_33;
this_35 = this_34;
functor_36 = D.2514;
this_37 = this_35-D.2649;
this_38 = this_37;
- # NONLOCAL.79_60 = V_MAY_DEF NONLOCAL.79_59;
- # VUSE SFT.70_55;
- # VUSE SFT.71_56;
+ # NONLOCAL.86_60 = V_MAY_DEF NONLOCAL.86_59;
+ # VUSE SFT.77_55;
+ # VUSE SFT.78_56;
this_35-functor_ = D.2514;
rep_39 = (struct slot_rep *) this_34;
this_40 = retval.D.2330;
@@ -185,14 +185,14 @@
rep_42 = rep_39;
this_43 = (struct functor_base *) retval.D.2330;
this_44 = this_43;
- # SFT.72_69 = V_MUST_DEF SFT.72_57;
+ # SFT.79_64 = V_MUST_DEF SFT.79_57;
retval.D.2330.rep_ = rep_42;
- D.3058_46 = rep_39;
- D.3060_47 = call_it;
- D.3060_48 = call_it;
- # NONLOCAL.79_67 = V_MAY_DEF NONLOCAL.79_60;
- D.3058_46-call_ = call_it;
- # VUSE SFT.72_69;
+ D.3065_46 = rep_39;
+ D.3067_47 = call_it;
+ D.3067_48 = call_it;
+ # NONLOCAL.86_62 = V_MAY_DEF NONLOCAL.86_60;
+ D.3065_46-call_ = call_it;
+ # VUSE SFT.79_64;
return retval;
}
Still the DCE diff contains
bb 2:
- # SFT.73_6 = V_MUST_DEF SFT.73_5;
+ # SFT.80_6 = V_MUST_DEF SFT.80_5;
D.2378.func_ptr_ = foo;
# _A_b1_9 = V_MUST_DEF _A_b1_8;
_A_b1 = 0B;
- this_19 = D.2514.D.2511.functor_;
- this_20 = this_19;
- # D.2951_27 = V_MUST_DEF D.2951_26;
- # VUSE SFT.73_6;
- D.2951 = D.2378;
- # SFT.70_50 = V_MAY_DEF SFT.70_49;
- # VUSE D.2951_27;
- this_20-functor_ = D.2951;
D.2953_31 = 0B;
- # SFT.70_68 = V_MUST_DEF SFT.70_50;
+ # SFT.77_63 = V_MUST_DEF SFT.77_49;
D.2514.bound1_.visited_ = D.2953_31;
where we removed the assignment
D.2951 = D.2378;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30252
[Bug tree-optimization/30252] [4.2 regression] miscompilation of sigc++-2.0 based code with -fstrict-aliasing
--- Comment #17 from rguenth at gcc dot gnu dot org 2007-05-01 14:00 --- Without -fstrict-aliasing we mark this_20-functor_ = D.2946; obviously necessary because it is is_hidden_global_store (): ;; Function sigc::slot0 A::bar() (_ZN1A3barEv) -Marking useful stmt: this_20-functor_ = D.2946; - -Marking useful stmt: D.3047_33 = operator new (20); +Marking useful stmt: D.3054_33 = operator new (20); Marking useful stmt: this_35-functor_ = D.2514; -Marking useful stmt: D.3053_46-call_ = call_it; +Marking useful stmt: D.3060_46-call_ = call_it; Marking useful stmt: return retval; without that we DCE too much as # SFT.80_6 = V_MUST_DEF SFT.80_5; D.2378.func_ptr_ = foo; ... # D.2951_27 = V_MUST_DEF D.2951_26; # VUSE SFT.80_6; D.2951 = D.2378; # SFT.77_50 = V_MAY_DEF SFT.77_49; # VUSE D.2951_27; this_20-functor_ = D.2951; # SFT.77_63 = V_MUST_DEF SFT.77_50; D.2514.bound1_.visited_ = D.2953_31; the last store kills the assignment to this_20-functor_. Note that while we have uses for D.2951_27 and SFT.80_6 the structure assignment to this_20-functor_ for some reason shares the SFT with the assignment to D.2514.bound1_.visited_. So this may be as well a frontend bug. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |NEW Ever Confirmed|0 |1 Keywords||alias Last reconfirmed|-00-00 00:00:00 |2007-05-01 14:00:47 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30252
[Bug c++/30252] [4.2 regression] miscompilation of sigc++-2.0 based code with -fstrict-aliasing
--- Comment #18 from rguenth at gcc dot gnu dot org 2007-05-01 14:05 --- So my guess is this is related to PR22488 which is rotting since some time... -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||jason at redhat dot com BugsThisDependsOn||22488 Component|tree-optimization |c++ http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30252
[Bug c++/31748] [4.2/4.3 regression] bad diagnostic for invalid private clause
-- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-05-01 14:08:23 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31748
[Bug c++/31759] [4.3 regression] ICE with OpenMP and exceptions
--- Comment #1 from jakub at gcc dot gnu dot org 2007-05-01 14:10 --- Zdenek, this seems to be also related to your cfg cleanup changes. -- jakub 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=31759
[Bug fortran/31732] [4.3 regression] Assignment to array slice affects whole array
--- Comment #8 from tkoenig at gcc dot gnu dot org 2007-05-01 14:11 --- Subject: Bug 31732 Author: tkoenig Date: Tue May 1 14:11:36 2007 New Revision: 124326 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124326 Log: 2007-05-01 Thomas Koenig [EMAIL PROTECTED] PR fortran/31732 * dependency.c (gfc_full_array_ref_p): If the reference is to a single element, check that the array has a single element and that the correct element is referenced. 2007-05-01 Thomas Koenig [EMAIL PROTECTED] PR fortran/31732 * gfortran.dg/array_memset_2: New test case. Added: trunk/gcc/testsuite/gfortran.dg/array_memset_2.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/dependency.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31732
[Bug fortran/31732] [4.3 regression] Assignment to array slice affects whole array
--- Comment #9 from tkoenig at gcc dot gnu dot org 2007-05-01 14:13 --- Fixed. Closing. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31732
[Bug fortran/31716] segfault with real array bounds
--- Comment #2 from tkoenig at gcc dot gnu dot org 2007-05-01 14:18 --- Closely related to PR 31251. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||31251 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31716
[Bug fortran/31251] Non-integer character length leads to segfault
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2007-05-01 14:47 --- With IMPLICIT NONE the double code path goes away and we get just one correct error message. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31251
[Bug fortran/31716] segfault with real array bounds
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2007-05-01 14:55 --- As with pr31251, I do not see the segfault here. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31716
[Bug c/31772] New: Program compilation problem
When I try compile a small program I get an error.
[EMAIL PROTECTED]:~ gcc -Wall prog.c -O2 -S
prog.c: In function main:
prog.c:21: error: Attempt to delete prologue/epilogue insn:
(insn/f 92 91 93 0 (set (mem:SI (plus:SI (reg/f:SI 6 bp)
(const_int -16 [0xfff0])) [0 S4 A8])
(reg:SI 2 cx)) -1 (nil)
(nil))
prog.c:21: internal compiler error: in propagate_one_insn, at flow.c:1699
file contents (prog.c)
#include stdio.h
int main()
{
int x[4];
int y[4];
int n;
for(n=0;n5;n++)
x[n]=10;
for(n=0;n5;n++)
y[n]=20;
printf(n: %d\n,n);
for(n=0;n4;n++)
printf(%d | %d\n,x[n],y[n]);
return 0;
}
--
Summary: Program compilation problem
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rui dot c dot a dot g at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31772
[Bug middle-end/31772] Program compilation problem
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-01 15:36 --- When I try compile a small program I get an error. small undefined code at that :). -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31772
[Bug middle-end/31772] Program compilation problem
--- Comment #2 from bangerth at dealii dot org 2007-05-01 17:01 --- int x[4]; for(n=0;n5;n++) x[n]=10; You're asking for trouble here. That said, we shouldn't produce a compiler error. I can't seem to reproduce this, what platform is this on? W. -- bangerth at dealii dot org changed: What|Removed |Added CC||bangerth at dealii dot org Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31772
[Bug c/31773] New: i suffix on a number always renders up 0.
I had a typo in my code, id = + 1i that baffled me as to why it compiled.
Once I realized that it was legal, I noticed that it was producing the wrong
result (aside from the obvious typo).
It appears that numberi always becomes 0 inside gcc. The cut-and-paste
below is from my computer at my desk at work, but I also tried it on gcc
version 4.1.1 20060525 (Red Hat 4.1.1-1) on a Fedora Core 5 machine, and
gcc version 3.4.6 [FreeBSD] 20060305 on a FreeBSD 6.2-STABLE machine.
[EMAIL PROTECTED]/tmp$ cat gccbug.c
int main( int argc, char **argv, char **envp )
{
printf( 0x%x\n, 1i );
printf( 0x%x\n, (int)1i );
printf( 0x%x\n, (long)1i );
printf( 0x%x\n, 99i );
printf( 0x%x\n, 838475i );
printf( 0x%x\n, 238485854i );
}
[EMAIL PROTECTED]/tmp$ gcc -v gccbug.c
Reading specs from /usr/lib/gcc/i386-redhat-linux/3.4.3/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--disable-checking --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-java-awt=gtk --host=i386-redhat-linux
Thread model: posix
gcc version 3.4.3 20041212 (Red Hat 3.4.3-9.EL4)
/usr/libexec/gcc/i386-redhat-linux/3.4.3/cc1 -quiet -v gccbug.c -quiet
-dumpbase gccbug.c -auxbase gccbug -version -o /tmp/wcolburn/ccTwJrT3.s
ignoring nonexistent directory
/usr/lib/gcc/i386-redhat-linux/3.4.3/../../../../i386-redhat-linux/include
#include ... search starts here:
#include ... search starts here:
/usr/local/include
/usr/lib/gcc/i386-redhat-linux/3.4.3/include
/usr/include
End of search list.
GNU C version 3.4.3 20041212 (Red Hat 3.4.3-9.EL4) (i386-redhat-linux)
compiled by GNU C version 3.4.3 20041212 (Red Hat 3.4.3-9.EL4).
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
as -V -Qy -o /tmp/wcolburn/ccmJTanZ.o /tmp/wcolburn/ccTwJrT3.s
GNU assembler version 2.15.92.0.2 (i386-redhat-linux) using BFD version
2.15.92.0.2 20040927
/usr/libexec/gcc/i386-redhat-linux/3.4.3/collect2 --eh-frame-hdr -m elf_i386
-dynamic-linker /lib/ld-linux.so.2
/usr/lib/gcc/i386-redhat-linux/3.4.3/../../../crt1.o
/usr/lib/gcc/i386-redhat-linux/3.4.3/../../../crti.o
/usr/lib/gcc/i386-redhat-linux/3.4.3/crtbegin.o
-L/usr/lib/gcc/i386-redhat-linux/3.4.3 -L/usr/lib/gcc/i386-redhat-linux/3.4.3
-L/usr/lib/gcc/i386-redhat-linux/3.4.3/../../.. /tmp/wcolburn/ccmJTanZ.o -lgcc
--as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed
/usr/lib/gcc/i386-redhat-linux/3.4.3/crtend.o
/usr/lib/gcc/i386-redhat-linux/3.4.3/../../../crtn.o
[EMAIL PROTECTED]/tmp$ ./a.out
0x0
0x0
0x0
0x0
0x0
0x0
[EMAIL PROTECTED]/tmp$ uname -a
Linux anotherpanda.pmc.com 2.6.9-5.ELsmp #1 SMP Wed Jan 5 19:30:39 EST 2005
i686 i686 i386 GNU/Linux
[EMAIL PROTECTED]/tmp$
I looked for this as a known bug, but I didn't find it. If it is known, I'm
just an idiot. :)
--
Summary: i suffix on a number always renders up 0.
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: schlake+gccbug at nmt dot edu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31773
[Bug c/31773] i suffix on a number always renders up 0.
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-01 17:58 --- 1i is complex integer where the imangary part is 1 and the real part is 0. See http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Complex.html This is a gcc extension. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31773
[Bug middle-end/31710] [4.2/4.3 Regression] ICE in in set_value_range, at tree-vrp.c:278
--- Comment #9 from mstein at phenix dot rootshell dot be 2007-05-01 17:59 --- Created an attachment (id=13469) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13469action=view) from src/sim/frv This attachment triggers a ICE in set_value_range, at tree-vrp.c:278 with a host gcc from today (trunk). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31710
[Bug c/31773] i suffix on a number always renders up 0.
--- Comment #2 from schlake+gccbug at nmt dot edu 2007-05-01 18:05 --- Ok, thanks. The other compiler we use here at work uses the i suffix to mean integer, just like l/L for long. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31773
[Bug target/31740] [4.3 Regression] Problem while compiling gcc for mips-elf
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-05-01 18:14 --- Reopening this one as it is not a dup. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|DUPLICATE | Summary|Problem while compiling gcc |[4.3 Regression] Problem |for mips-elf|while compiling gcc for ||mips-elf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31740
[Bug middle-end/31740] [4.3 Regression] Problem while compiling gcc for mips-elf
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |blocker Component|target |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31740
[Bug tree-optimization/31739] [4.3 Regression] ICE at tree.c:902 compiling g-regexp.adb
--- Comment #3 from ian at gcc dot gnu dot org 2007-05-01 18:52 ---
Subject: Bug 31739
Author: ian
Date: Tue May 1 18:51:56 2007
New Revision: 124334
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124334
Log:
PR tree-optimization/31739
* tree-vrp.c (vrp_val_is_max): New static function.
(vrp_val_is_min): New static function.
(set_value_range_to_value): Use TYPE_{MAX,MIN}_VALUE rather than
copying the node.
(set_value_range): Use vrp_val_is_{max,min}.
(extract_range_from_assert): Likewise.
(extract_range_from_binary_expr): Likewise.
(extract_range_from_unary_expr): Likewise.
(dump_value_range, vrp_meet): Likewise.
(vrp_visit_phi_node): Likewise.
* tree.c (build_distinct_type_copy): Revert change of 2007-04-27.
Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-vrp.c
trunk/gcc/tree.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31739
[Bug middle-end/31710] [4.2/4.3 Regression] ICE in in set_value_range, at tree-vrp.c:278
--- Comment #10 from ian at airs dot com 2007-05-01 18:58 --- Please let me know if this is still a problem after revision 124334. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31710
[Bug tree-optimization/31739] [4.3 Regression] ICE at tree.c:902 compiling g-regexp.adb
--- Comment #4 from ian at airs dot com 2007-05-01 18:59 --- Fixed on mainline. -- ian at airs dot com changed: What|Removed |Added CC|ian at gcc dot gnu dot org |ian at airs dot com Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31739
[Bug middle-end/31740] [4.3 Regression] Problem while compiling gcc for mips-elf
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-05-01 19:15 ---
Reduced testcase:
typedef signed int signed16 __attribute__ ((__mode__ (__HI__)));
typedef unsigned int unsigned16 __attribute__ ((__mode__ (__HI__)));
typedef signed16 HI;
typedef unsigned16 UHI;
unsigned short f(int y)
{
HI tmp_b4;
tmp_b4 = y;
UHI opval;
if (tmp_b4 == -32768)
opval = 32767;
else
opval = -tmp_b4;
return opval;
}
--
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-05-01 19:15:24
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31740
[Bug c/31773] i suffix on a number always renders up 0.
--- Comment #3 from bangerth at dealii dot org 2007-05-01 19:16 --- (In reply to comment #2) Ok, thanks. The other compiler we use here at work uses the i suffix to mean integer, just like l/L for long. This is definitely non-standard. The 'i' suffix is for the imaginary part of complex numbers and, as far as I understand, is going to be in the next C standard. -- bangerth at dealii dot org changed: What|Removed |Added CC||bangerth at dealii dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31773
[Bug middle-end/31740] [4.3 Regression] Problem while compiling gcc for mips-elf
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-05-01 19:26 ---
Yes this was fixed after:
2007-05-01 Ian Lance Taylor [EMAIL PROTECTED]
PR tree-optimization/31739
* tree-vrp.c (vrp_val_is_max): New static function.
(vrp_val_is_min): New static function.
(set_value_range_to_value): Use TYPE_{MAX,MIN}_VALUE rather than
copying the node.
(set_value_range): Use vrp_val_is_{max,min}.
(extract_range_from_assert): Likewise.
(extract_range_from_binary_expr): Likewise.
(extract_range_from_unary_expr): Likewise.
(dump_value_range, vrp_meet): Likewise.
(vrp_visit_phi_node): Likewise.
* tree.c (build_distinct_type_copy): Revert change of 2007-04-27.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution||FIXED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31740
[Bug middle-end/31740] [4.3 Regression] Problem while compiling gcc for mips-elf
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-05-01 19:34 --- Subject: Bug 31740 Author: pinskia Date: Tue May 1 19:34:32 2007 New Revision: 124337 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124337 Log: 2007-05-01 Andrew Pinski [EMAIL PROTECTED] PR middle-end/31740 * gcc.c-torture/compile/20070501-1.c: New testcase. Added: trunk/gcc/testsuite/gcc.c-torture/compile/20070501-1.c Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31740
[Bug c++/31774] New: inconsitency between gcc and g++ when linking with --as-needed
I have problems linking executable with C++ library with --as-needed ld flag while linking with gcc succeeds. During investigation I found inconsistency in gcc and g++ calls concerning --as-needed. First I will show you what I do next I'll summarize what is this bug about: * What I do: First I compile/link objects which will be included in library: libtool --mode=compile i686-pc-linux-gnu-g++ -c -g -O2 -pthread sync.cpp i686-pc-linux-gnu-g++ -c -g -O2 -pthread sync.cpp -fPIC -DPIC -o .libs/sync.o i686-pc-linux-gnu-g++ -c -g -O2 -pthread sync.cpp -o sync.o /dev/null 21 All objects I linked in the same way. Next library is linked itself (I've edited output to simplify reading so there could be some typos): libtool --mode=link i686-pc-linux-gnu-g++ -o libgigabase_r.la class.lo compiler.lo database.lo replicator.lo hashtab.lo file.lo symtab.lo btree.lo rtree.lo cursor.lo query.lo pagepool.lo wwwapi.lo unisock.lo blob.lo container.lo exception.lo localcli.lo sync.lo -pthread -rpath /usr/lib -version-info 2 i686-pc-linux-gnu-g++ -shared -nostdlib /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/../../../crti.o /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/crtbeginS.o .libs/class.o .libs/compiler.o .libs/database.o .libs/replicator.o .libs/hashtab.o .libs/file.o .libs/symtab.o .libs/btree.o .libs/rtree.o .libs/cursor.o .libs/query.o .libs/pagepool.o .libs/wwwapi.o .libs/unisock.o .libs/blob.o .libs/container.o .libs/exception.o .libs/localcli.o .libs/sync.o -L/usr/lib/gcc/i686-pc-linux-gnu/4.1.2 -L/usr/lib/gcc/i686-pc-linux-gnu/4.1.2/../../../../i686-pc-linux-gnu/lib -L/usr/lib/gcc/i686-pc-linux-gnu/4.1.2/../../.. -lstdc++ -lm -lc -lgcc_s /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/crtendS.o /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/../../../crtn.o -pthread -Wl,-soname -Wl,libgigabase_r.so.2 -o .libs/libgigabase_r.so.2.0.0 (cd .libs rm -f libgigabase_r.so.2 ln -s libgigabase_r.so.2.0.0 libgigabase_r.so.2) (cd .libs rm -f libgigabase_r.so ln -s libgigabase_r.so.2.0.0 libgigabase_r.so) i686-pc-linux-gnu-ar cru .libs/libgigabase_r.a class.o compiler.o database.o replicator.o hashtab.o file.o symtab.o btree.o rtree.o cursor.o query.o pagepool.o wwwapi.o unisock.o blob.o container.o exception.o localcli.o sync.o i686-pc-linux-gnu-ranlib .libs/libgigabase_r.a creating libgigabase_r.la (cd .libs rm -f libgigabase_r.la ln -s ../libgigabase_r.la libgigabase_r.la) Now I link two programs (subsql and guess) against libgigabase_r.so. While subsql builds successfully: i686-pc-linux-gnu-g++ -c -g -O2 -pthread subsql.cpp i686-pc-linux-gnu-g++ -c -g -O2 -pthread server.cpp libtool --mode=link i686-pc-linux-gnu-g++ -Wl,--as-needed -pthread -o subsql subsql.o server.o libgigabase_r.la i686-pc-linux-gnu-g++ -Wl,--as-needed -pthread -o .libs/subsql subsql.o server.o ./.libs/libgigabase_r.so creating subsql guess programm do not: i686-pc-linux-gnu-g++ -c -g -O2 -pthread guess.cpp libtool --mode=link i686-pc-linux-gnu-g++ -Wl,--as-needed -pthread -o guess guess.o libgigabase_r.la i686-pc-linux-gnu-g++ -Wl,--as-needed -pthread -o .libs/guess guess.o ./.libs/libgigabase_r.so ./.libs/libgigabase_r.so: undefined reference to `pthread_key_create' ./.libs/libgigabase_r.so: undefined reference to `pthread_getspecific' ./.libs/libgigabase_r.so: undefined reference to `pthread_create' ./.libs/libgigabase_r.so: undefined reference to `pthread_key_delete' ./.libs/libgigabase_r.so: undefined reference to `pthread_detach' ./.libs/libgigabase_r.so: undefined reference to `pthread_setspecific' ./.libs/libgigabase_r.so: undefined reference to `pthread_join' collect2: ld returned 1 exit status make: *** [guess] Error 1 * What is this bug about: As you noticed libtool links library with -nostdlib and this dependency on libpthread is missed in .libs/libgigabase_r.so. On pthreads mailing list I was assured that it's Ok to avoid this dependency and even sometimes this is useful. Why the first linkage succeeds while second not. I've looked at object files which are used to build final executables and found the differences between them. The object sever.o (which is used to build subsql) has pthread_* functions in elf Symbol table (part of output of readelf -W -a): 2899 6602 R_386_PC32 pthread_create and in .symtab: 102: 0 NOTYPE GLOBAL DEFAULT UND pthread_create while the only object file guess.o (which is used to build guess) do not have any references to pthread_*(). Why I think this bug is in g++. I found that substitution of g++ to gcc during last linkage fixes compilation problem. While it seems to be wrong to link C++ program with gcc I've compared verbose output of gcc calls and found that difference in the output. g++ as well as gcc call collect2 but with a bit different options. g++ call of collect2 misses this part completely (which follows after other objects): --no-as-needed -lpthread -lc -lgcc --as-needed
[Bug c++/31775] New: static object mangling conflicts with extern object
In [basic.link] paragraph 6, there's an example that shows that (unlike in C)
it is permissible to define an object 'static' in a namespace scope and then
have another object which is 'extern', and reference both in the same
translation unit.
The compiler optimises that example so that there's no way to see the incorrect
behaviour, but a slightly modified version is:
extern C void abort();
static int i;
int *p = i;
int main()
{
int i;
{
extern int i;
i = 1;
*p = 2;
if (i == 2)
abort ();
}
return 0;
}
I believe this should fail to compile with a link error, because the extern
version of 'i' is never defined. On Darwin, what this does (apparently) is
crash with a bus error trying to write to the first instruction of main, which
is probably a linker bug; I expect that on other OSs it will call abort().
The basic problem is that 'static int i' needs to be a different name in the
assembly than 'extern int i'.
--
Summary: static object mangling conflicts with extern object
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: c++
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=31775
[Bug c++/31775] static object mangling conflicts with extern object
--- Comment #1 from geoffk at gcc dot gnu dot org 2007-05-01 19:56 ---
This testcase is the same principle, but might use a different code path in the
compiler:
extern C void abort();
extern int *p;
int main()
{
extern int i;
i = 1;
*p = 2;
if (i == 2)
abort ();
return 0;
}
static int i;
int *p = i;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31775
[Bug tree-optimization/31739] [4.3 Regression] ICE at tree.c:902 compiling g-regexp.adb
--- Comment #5 from ian at gcc dot gnu dot org 2007-05-01 20:23 ---
Subject: Bug 31739
Author: ian
Date: Tue May 1 20:23:47 2007
New Revision: 124338
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124338
Log:
PR tree-optimization/31739
* tree-vrp.c (vrp_val_is_max): New static function.
(vrp_val_is_min): New static function.
(set_value_range_to_value): Use TYPE_{MAX,MIN}_VALUE rather than
copying the node.
(set_value_range): Use vrp_val_is_{max,min}.
(extract_range_from_assert): Likewise.
(extract_range_from_binary_expr): Likewise.
(extract_range_from_unary_expr): Likewise.
(dump_value_range, vrp_meet): Likewise.
(vrp_visit_phi_node): Likewise.
* tree.c (build_distinct_type_copy): Revert change of 2007-04-27.
Modified:
branches/gcc-4_2-branch/gcc/ChangeLog
branches/gcc-4_2-branch/gcc/tree-vrp.c
branches/gcc-4_2-branch/gcc/tree.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31739
[Bug c++/31775] static object mangling conflicts with extern object
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-05-01 20:44 --- How do you define main::i? That is, how'd you make the testcase work from a second translation unit if it would fail now? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31775
[Bug driver/31774] inconsitency between gcc and g++ when linking with --as-needed
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-01 21:03 --- I think this is really a libtool bug passing -nostdlib to g++, there is no reason why it should be doing that anyways. Also --as-needed is a binutils option, since the pthreads library is not needed by the main program, it is needed by the shared library libgigabase_r.so, ld is not adding it to the link line which is the correct thing so libgigabase_r.so needs to link against libpthreads.so to be correctly done. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c++ |driver http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31774
[Bug libf2c/31425] gcc 3.4.6 and gcc 4.1.2 on HP 11.23 Itinium (ia64)URGENT
--- Comment #1 from sje at cup dot hp dot com 2007-05-01 21:22 --- This does not look like a GCC bug, you just need to link in the YACC library on the link line. The lex library (-ll) has calls to the yacc library (-ly) and so that library needs to be linked in. -- sje at cup dot hp dot com changed: What|Removed |Added CC||sje at cup dot hp dot com Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31425
[Bug bootstrap/31776] New: Bootstrap fails with error: conflicting types for strsignal
The current svn repository does not bootstrap on my machine. $ svn info Path: . URL: svn://gcc.gnu.org/svn/gcc/trunk Repository Root: svn://gcc.gnu.org/svn/gcc Repository UUID: 138bc75d-0d04-0410-961f-82ee72b054a4 Revision: 124341 Node Kind: directory Schedule: normal Last Changed Author: dwarak Last Changed Rev: 124341 Last Changed Date: 2007-05-01 14:53:40 -0500 (Tue, 01 May 2007) make fails with In file included from /usr/include/sys/wait.h:111, from /usr/include/stdlib.h:64, from /Users/eschnett/src/gcc/gcc/system.h:208, from /Users/eschnett/src/gcc/gcc/genmodes.c:23: /usr/include/sys/resource.h:90: error: two or more data types in declaration specifiers In file included from /Users/eschnett/src/gcc/gcc/genmodes.c:23: /Users/eschnett/src/gcc/gcc/system.h:418: error: conflicting types for strsignal /usr/include/string.h:130: error: previous declaration of strsignal was here make[3]: *** [build/genmodes.o] Error 1 make[2]: *** [all-stage1-gcc] Error 2 make[1]: *** [stage1-bubble] Error 2 make: *** [bootstrap] Error 2 Line 130 of /usr/include/string.h reads char*strsignal(int sig); -- Summary: Bootstrap fails with error: conflicting types for strsignal Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: schnetter at aei dot mpg dot de GCC build triplet: i386-apple-darwin8.9.1 GCC host triplet: i386-apple-darwin8.9.1 GCC target triplet: i386-apple-darwin8.9.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31776
[Bug bootstrap/31776] Bootstrap fails with error: conflicting types for strsignal
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-01 22:03 --- How did you configure? This is most likely the same as reported in http://gcc.gnu.org/ml/gcc-patches/2007-05/msg00033.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31776
[Bug tree-optimization/31762] ICE in tree-dfa.c:791 with -ftree-loop-linear (and -O1 -ffast-math)
--- Comment #3 from rakdver at gcc dot gnu dot org 2007-05-01 22:24 --- I am checking this; so far it looks like some memory corruption. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31762
[Bug libstdc++/31777] New: GLIBCXX_FORCE_NEW doesn't always work in pool_allocator
in revision 83355 of libstdc++-v3/include/ext/pool_allocator.h the efficient thread support code for GLIBCXX_FORCE_NEW was broken by changing the test (_S_force_new0) to (_S_force_new==1). now there is a race condition. -- Summary: GLIBCXX_FORCE_NEW doesn't always work in pool_allocator Product: gcc Version: 3.4.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: gcc at severeweblint dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31777
[Bug bootstrap/31776] Bootstrap fails with error: conflicting types for strsignal
--- Comment #2 from schnetter at aei dot mpg dot de 2007-05-01 22:37 --- I configured with the options ~/src/gcc/configure --prefix=$HOME/gcc --with-gmp=/opt/local --with-mpfr=/opt/local (outside the source tree). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31776
[Bug bootstrap/31776] Bootstrap fails with error: conflicting types for strsignal
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-05-01 22:57 --- It looks like the same cause but different symptom. The configure check for strsignal for darwin doesn't seem to work. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31776
[Bug tree-optimization/31762] ICE in tree-dfa.c:791 with -ftree-loop-linear (and -O1 -ffast-math)
--- Comment #4 from rakdver at gcc dot gnu dot org 2007-05-01 23:02 ---
To tree-data-ref.c:add_multivariate_self_dist, we get with
c_2 = {{0, +, 30}_1, +, 1}_2
but
ddr-loop_nest contains only loops 2 and 3.
x_1 is then set to 2, which is outside of the bounds of the dist_v
array.
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
CC||sebastian dot pop at cri dot
||ensmp dot fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31762
[Bug bootstrap/31778] New: genattrtab.c doesn't record filename
genattrtab.c has
struct insn_def
{
struct insn_def *next;/* Next insn in chain. */
rtx def; /* The DEFINE_... */
int insn_code;/* Instruction number. */
int insn_index; /* Expression numer in file, for errors. */
int lineno; /* Line number. */
int num_alternatives; /* Number of alternatives. */
int vec_idx; /* Index of attribute vector in `def'. */
};
It doesn't record filename. Most of machine descriptions have more than one
input file. As the result, when genattrtab prints an error message
with message_with_line, it dpesn't have filename and it is hard to see
where the problem is.
--
Summary: genattrtab.c doesn't record filename
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl at lucon dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31778
[Bug libstdc++/31779] New: GLIBCXX_3.4.9 undefined in libstdc++.so.6 (link time)
One more potential conspiracy item against gcc-4.2.0. The following three items were obtained on three different machines sporting late gcc-4.2.0 versions. (less than one week old) cmake: relocation error: cmake: symbol _ZNSo9_M_insertEPKci, version GLIBCXX_3.4.9 not defined in file libstdc++.so.6 with link time reference ./cmake: /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/libstdc++.so.6: no version information available (required by ./cmake) ./cmake: /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/libstdc++.so.6: no version information available (required by ./cmake) ./cmake: /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/libstdc++.so.6: no version information available (required by ./cmake) ./cmake: relocation error: ./cmake: symbol _ZSt16__ostream_insertIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_PKS3_i, version GLIBCXX_3.4.9 not defined in file libstdc++.so.6 with link time reference cmake: /usr/lib/gcc/powerpc-unknown-linux-gnu/4.1.2/libstdc++.so.6: version `GLIBCXX_3.4.9' not found (required by cmake) The first two come from pentium3's the last from a powerpc I did a search agains GLIBCXX and turned up four items seemingly unrelated like GLIBCXX-DEBUG. Besides cmake there were similar messages relating tho wxGTK re2c and others. These messages went away when doing a bootstrap to gcc-4.3.0 and recompiling the offending programs. Doing a grep -r -e '3\.4\.9' * in gcc-4.2.0 libstdc++-v3 did nor help me; while in gcc-4.3.0 did not help me in identifying with gcc-4.3.0 things seem to work. I certainly would not know how to produce a relevant preprocessed xxx.i. Willing to help but require instructions. -- Summary: GLIBCXX_3.4.9 undefined in libstdc++.so.6 (link time) Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: malitzke at metronets dot com GCC build triplet: same GCC host triplet: i868-pc-linux-gnu: powerpc-unknown-linux-gnu GCC target triplet: same http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31779
[Bug libstdc++/31779] GLIBCXX_3.4.9 undefined in libstdc++.so.6 (link time)
--- Comment #1 from pcarlini at suse dot de 2007-05-01 23:36 --- Obviously, you are linking a binary compiled with 4.2.0 to a 4.1.2 library. That kind of backward compatibility is not provided and never was in the past. -- pcarlini at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31779
[Bug libstdc++/31779] GLIBCXX_3.4.9 undefined in libstdc++.so.6 (link time)
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-05-01 23:39 --- (In reply to comment #1) Obviously, you are linking a binary compiled with 4.2.0 to a 4.1.2 library. That kind of backward compatibility is not provided and never was in the past. That is called forwards compatibility which is hard to do in general as it means you cannot add any new functions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31779
[Bug libstdc++/31779] GLIBCXX_3.4.9 undefined in libstdc++.so.6 (link time)
--- Comment #3 from pcarlini at suse dot de 2007-05-01 23:41 --- (In reply to comment #2) That is called forwards compatibility... The name depends on the point of view ;) No, seriusly, thanks about the name, I always get this one wrong. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31779
[Bug libstdc++/31777] GLIBCXX_FORCE_NEW doesn't always work in pool_allocator
--- Comment #1 from pcarlini at suse dot de 2007-05-01 23:57 --- Gosh you are right, will fix it asap. Thanks. -- pcarlini at suse dot de changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-05-01 23:57:05 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31777
[Bug libstdc++/31777] GLIBCXX_FORCE_NEW doesn't always work in pool_allocator
-- pcarlini at suse dot de changed: What|Removed |Added Target Milestone|--- |4.2.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31777
[Bug libstdc++/31779] GLIBCXX_3.4.9 undefined in libstdc++.so.6 (link time)
--- Comment #4 from malitzke at metronets dot com 2007-05-02 00:20 --- I accept that there is something wrong on my side. Be it forward or backward. However, there are some things that I still do not understand. Cmake was compiled several times with different bootstrapped gcc-4.2.0 and it should have picked the appropriate libstdc++.so.6. More to the point is the situation with glibc (cvs) which for some time was only compilable with gcc-3.4.6 and only recently turned compilable (with some trickery) with gcc-4.1.1(2). Glibc fails abysmally with gcc-4.3.0 but the older glibc compilations do work with with gcc-4.3.0. compiled programs. It seems that some programs have a mechanism to discriminate on library versions while others do not. Also some makefiles seem to require libraries in /usr/lib while other are quite happy with the libraries in /usr/lib/gcc/ It seems to be a case of user beware and I will have to do more compilations and carefully erase what is not strictly appropriate. Anyhow, thanks for the info. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31779
[Bug c++/31780] New: [4.3 regression] ICE with incompatible types for ?:
The following invalid code snippet triggers an ICE on mainline:
===
bool foo();
void bar()
{
__builtin_expect(foo(), 1) ? 0i : 0;
}
===
bug.cc: In function 'void bar()':
bug.cc:5: error: could not convert '0' to 'int __complex__'
bug.cc:5: internal compiler error: tree check: expected class 'type', have
'exceptional' (error_mark) in tree_ssa_useless_type_conversion_1, at
tree-ssa.c:900
Please submit a full bug report, [etc.]
--
Summary: [4.3 regression] ICE with incompatible types for ?:
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, error-recovery, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31780
[Bug c++/31780] [4.3 regression] ICE with incompatible types for ?:
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31780
[Bug c++/31775] static object mangling conflicts with extern object
--- Comment #3 from geoffk at gcc dot gnu dot org 2007-05-02 00:54 --- You would add a translation unit that says int i; or similar. It's not main::i, it's ::i, because of [basic.link] paragraph 7: When a block scope declaration of an entity with linkage is not found to refer to some other declaration, then that entity is a member of the innermost enclosing namespace. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31775
[Bug c++/31775] static object mangling conflicts with extern object
--- Comment #4 from geoffk at gcc dot gnu dot org 2007-05-02 01:46 --- I just happen to have a patch which fixes this. -- geoffk at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |geoffk at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-05-02 01:46:13 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31775
[Bug c++/31780] [4.3 regression] ICE with incompatible types for ?: with complex type conversion
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-02 01:46 --- bug.cc:5: error: could not convert '0' to 'int __complex__' Actually it should be able to convert that and I think this is the same reason why we are rejecting PR 30209. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Keywords|error-recovery, ice-on- |ice-on-valid-code |invalid-code| Summary|[4.3 regression] ICE with |[4.3 regression] ICE with |incompatible types for ?: |incompatible types for ?: ||with complex type ||conversion http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31780
[Bug c++/31780] [4.3 regression] ICE with incompatible types for ?: with complex type conversion
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-05-02 01:47 --- Also I think this was caused by PR 31338. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||30209 OtherBugsDependingO||31338 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31780
[Bug c++/27177] [4.0/4.1/4.2/4.3 Regression] ICE in build_simple_base_path, at cp/class.c:474
--- Comment #12 from crowl at google dot com 2007-05-02 02:24 ---
(In reply to comment #10)
I am not convinced that the code in Comment #8 is valid.
Although the operand of sizeof is not in fact evaluated, it seems odd to
permit an operand which cannot, even in principle, be evaluated. This is
not even a case in which evaluating the operand would lead to undefined
behavior; there is simply no way to evaluate the operand at all. If there
is an implicit conversion from B* to Z* at this point, then we must know
how to perform the conversion, but we cannot, since B is not complete.
While that view has merit, I find no requirement in the standard that
requires a complete class. Setting that aside s possibly unreasonable,
I think 4.10 paragraph 3 The null pointer value is converted to the null
pointer value of the destination type. enables conversion of null pointers
when the pointer type has known bases but is not yet complete.
Are you arguing that in:
struct B {};
struct D : public B {
static const int i = sizeof((B*)(D*)0);
};
the conversion from D* to B* is a static_cast?
I think (B*)(D*)0 is a conversion under 4.10.
Has anyone asked about this case on the core reflector?
Would you like me to?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27177
[Bug fortran/31781] New: fortran regressions on trunk if you --disable-checking
if you --disable-checking when you build, you get additional fortran regressions. This is true on the current trunk and has most likely been true for at least two weeks. FAIL: gfortran.dg/repeat_2.f90 -O0 execution test FAIL: gfortran.dg/repeat_2.f90 -O1 execution test FAIL: gfortran.dg/repeat_2.f90 -O2 execution test FAIL: gfortran.dg/repeat_2.f90 -O3 -fomit-frame-pointer execution test FAIL: gfortran.dg/repeat_2.f90 -O3 -fomit-frame-pointer -funroll-loops execution test FAIL: gfortran.dg/repeat_2.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions execution test FAIL: gfortran.dg/repeat_2.f90 -O3 -g execution test FAIL: gfortran.dg/repeat_2.f90 -Os execution test -- Summary: fortran regressions on trunk if you --disable-checking Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: zadeck at naturalbridge dot com GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31781
[Bug c/31782] New: Invalid assembly code on initial dollar signs
Hi,
This code compiles fine with gcc:
void a$() {}
int main() { a$(); }
This generates invalid assembly code:
void $() {}
int main() { $(); }
To gas, an initial $ is not allowed in an identifier, but to gcc, it is, so gcc
can't simply copy the function name to the assembly output, unless $ also
becomes an invalid identifier in C.
The code can, of course, compile successfully with -fleading-underscore.
--
Summary: Invalid assembly code on initial dollar signs
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: truedfx at gentoo dot org
GCC host triplet: x86_64-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31782
[Bug c/31782] Invalid assembly code on initial dollar signs
--- Comment #1 from truedfx at gentoo dot org 2007-05-02 03:21 --- Sorry, forgot to mention, I'm using gcc 4.1.2 with binutils 2.17, and I also tried gcc 3.3.6 with binutils 2.16.1, which behaves the same for me. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31782
[Bug target/31782] Invalid assembly code on initial dollar signs
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-05-02 03:33 --- unless $ also becomes an invalid identifier in C. Well read: http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Dollar-Signs.html it is can be but does not have to be. This works for me targetting spu-elf and powerpc64-linux-gnu (with -m32 and -m64) so this is a target issue. Really I think this is a bug in binutils for i386/x86_64 (I can reproduce it there). -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c |target GCC host triplet|x86_64-pc-linux-gnu | GCC target triplet||x86_64-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31782
[Bug fortran/31781] fortran regressions on trunk if you --disable-checking
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-02 03:34 --- Most likely someone has a gcc_assert which has side effects. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added GCC build triplet| x86_64-unknown-linux-gnu |x86_64-unknown-linux-gnu GCC host triplet| x86_64-unknown-linux-gnu |x86_64-unknown-linux-gnu GCC target triplet| x86_64-unknown-linux-gnu |x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31781
[Bug c++/31783] New: [4.1.2, 4.1.1] bogus control reaches end of non-void function warning
gcc 4.1.2 and gcc 4.1.1 shows the following bogus warning message.
[EMAIL PROTECTED] ~/tests] arm-rtems-gcc -Os -Wall -S test.cpp
test.cpp: In member function 'int attr::create(int)':
test.cpp:17: warning: control reaches end of non-void function
the minimal testcase:
class attr
{
attr() {}
~attr() {}
int create(int);
};
int attr::create(int c)
{
attr p;
switch(c)
{
default:
return 123;
break;
}
}
--
Summary: [4.1.2, 4.1.1] bogus control reaches end of non-void
function warning
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: wad at infinet dot ru
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31783
[Bug fortran/31251] Non-integer character length leads to segfault
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2007-05-02 04:13 --- Created an attachment (id=13470) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13470action=view) Possible patch for this problem The double error comes from trying to match_type_spec for a variable declaration and then later for the prefix for a function declaration. It does this even though there has clearly been a syntax error. I am not able to reproduce a segfault. However, this patch eliminates the double error message. Could someone verify that they still get a segfault without this patch and then try with the patch to see what happens. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31251
[Bug fortran/31716] segfault with real array bounds
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2007-05-02 04:19 --- I attached a patch to pr31251, can someone try that and see what effect it has on this one. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31716
[Bug fortran/31467] internal compiler error when compiling with gfortran
-- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31467
[Bug fortran/31306] ICE with implicit character variables
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2007-05-02 04:57 --- backtrace is uggly, repeats the following for a long long time #3554 0x0043c63e in mio_expr (ep=value optimized out) at ../../gcc43/gcc/fortran/module.c:2133 #3555 0x0043c779 in mio_expr (ep=0xef2f60) at ../../gcc43/gcc/fortran/module.c:2685 #3556 0x0043c8dd in mio_charlen (clp=0xf31728) at ../../gcc43/gcc/fortran/module.c:1769 #3557 0x0043c979 in mio_typespec (ts=0xf31718) at ../../gcc43/gcc/fortran/module.c:1831 #3558 0x0043c393 in mio_expr (ep=0xef2a38) at ../../gcc43/gcc/fortran/module.c:2649 #3559 0x0043c9ad in mio_actual_arg (a=value optimized out) at ../../gcc43/gcc/fortran/module.c:2118 #3560 0x0043c63e in mio_expr (ep=value optimized out) at ../../gcc43/gcc/fortran/module.c:2133 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31306
[Bug bootstrap/31746] Broken ./configure sed scripting affecting *gcc/configargs.h construction.
--- Comment #5 from rob1weld at aol dot com 2007-05-02 05:08 --- Thanks Andreas, The annoying un-quoted second occurance of the languages is now fixed. Somehow AutoConf decided that it was going to rebuild ./configure . I renamed my current configure and then did a new SVN to get the official one. They are very different. Mine says: Generated by GNU Autoconf 2.61. SVN says: Generated automatically using autoconf version 2.13 There are _many_ other differences. My SVN was able to merge what I had with it's comparison of the origonal SVN version and not complaint. I'm not going to concern myself with _why_ the regenerated file from the SVN's configure.in file produced a configure file that was broken. I'll just eye the two up and re-enable gomp and mudflaps for the Cygwin target (yes, they work) and leave the rest alone. This means that the configure.in file needs a once over. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31746
[Bug target/31782] Invalid assembly code on initial dollar signs
--- Comment #3 from truedfx at gentoo dot org 2007-05-02 05:58 --- Thanks for the link. I don't see how GAS could be fixed, though. How would the assembler tell the difference between $0 the constant and $0 the identifier? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31782
[Bug driver/31774] inconsitency between gcc and g++ when linking with --as-needed
--- Comment #2 from pva at gentoo dot org 2007-05-02 06:56 --- libtool bug was discussed earlier: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25460 But this bug is not about libtool. Libtool just expose problem, although it should hide but that is another bug. I may wish to have library not dependent on -pthread not linking with libpthread. Then further linking with this library for gcc succeeds, while for g++ not and this is what this bug is about. May be this should be fixed in gcc, but as gcc works and even it does some specific actions it seems to me that more natural fix will be to add same magic to g++. But proper solution is up to gcc maintainers. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31774
