[Bug libstdc++/22203] std::numeric_limitsint::traps is wrong on PPC
--- Comment #1 from paolo at gcc dot gnu dot org 2005-11-05 09:42 --- Subject: Bug 22203 Author: paolo Date: Sat Nov 5 09:42:01 2005 New Revision: 106524 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=106524 Log: 2005-11-05 Paolo Carlini [EMAIL PROTECTED] PR libstdc++/22203 * include/bits/c++config: Include cpu_defines.h. * include/Makefile.am: Add cpu_defines.h to host_headers. * configure.host: Add cpu_defines_dir. * configure.ac: Use it. * config/cpu/powerpc/cpu_defines.h: New. * config/cpu/generic/cpu_defines.h: Likewise. * configure: Regenerate. * Makefile.in: Likewise. * include/Makefile.in: Likewise. * libmath/Makefile.in: Likewise. * libsupc++/Makefile.in: Likewise. * po/Makefile.in: Likewise. * src/Makefile.in: Likewise. * testsuite/Makefile.in: Likewise. Added: trunk/libstdc++-v3/config/cpu/generic/cpu_defines.h trunk/libstdc++-v3/config/cpu/powerpc/cpu_defines.h Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/Makefile.in trunk/libstdc++-v3/configure trunk/libstdc++-v3/configure.ac trunk/libstdc++-v3/configure.host trunk/libstdc++-v3/include/Makefile.am trunk/libstdc++-v3/include/Makefile.in trunk/libstdc++-v3/include/bits/c++config trunk/libstdc++-v3/libmath/Makefile.in trunk/libstdc++-v3/libsupc++/Makefile.in trunk/libstdc++-v3/po/Makefile.in trunk/libstdc++-v3/src/Makefile.in trunk/libstdc++-v3/testsuite/Makefile.in -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22203
[Bug libstdc++/22203] std::numeric_limitsint::traps is wrong on PPC
--- Comment #2 from pcarlini at suse dot de 2005-11-05 09:43 --- Fixed for 4.1.0. -- pcarlini at suse dot de changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22203
[Bug rtl-optimization/23392] [4.1 Regression] foward-1.m fails with -funroll-loops -O3 -fgnu-runtime
--- Comment #11 from steven at gcc dot gnu dot org 2005-11-05 10:31 --- This is probably a dup of Bug 22509, which has a patch. Can someone check if this bug is fixed by the patch from Bug 22509? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23392
[Bug rtl-optimization/23453] [4.0/4.1 regression] miscompilation of PARI/GP on x86 with gcse after reload
--- Comment #10 from steven at gcc dot gnu dot org 2005-11-05 10:48 --- This doesn't fail for me with the test case from comment #6... :-( -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23453
[Bug fortran/24534] [4.0/4.1 Regression] PUBLIC derived types with private components
--- Comment #6 from paulthomas2 at wanadoo dot fr 2005-11-05 10:51 --- Subject: Re: [4.0/4.1 Regression] PUBLIC derived types with private components tobi at gcc dot gnu dot org wrote: --- Comment #5 from tobi at gcc dot gnu dot org 2005-11-01 19:22 --- CCing pault, as he introduced that error. Looks like you've been to strict, Paul I'll have a look at it tomorrow. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24534
[Bug fortran/24534] [4.0/4.1 Regression] PUBLIC derived types with private components
--- Comment #7 from pault at gcc dot gnu dot org 2005-11-05 11:06 --- Yes, I have been too strict. The private derived type must be accessible inside the module where it is defined (4.4.1). I'll have a patch ready before the weekend is out. Thanks Harald! Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24534
[Bug libgomp/24682] New: Sample program at OpenMP web site fails with ICE
There are two sample programs at www.openmp.org . One of them - md - fails with ICE. svn update was done on Nov. 5, i.e. r106450 of the gomp-branch. gfortran-gomp -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc/configure --prefix=/usr/local/gomp --program-suffix=-gomp --enable-threads=posix --enable-languages=c,c++,fortran Thread model: posix gcc version 4.1.0-gomp-20050608-branch 20051031 (experimental) (merged 20051031) gfortran-gomp -fopenmp -g -lgomp -o md md.for md.for: In function compute_.omp_fn.0: md.for:96: internal compiler error: tree check: expected class type, have exceptional (error_mark) in tree_ssa_useless_type_conversion_1, at tree-ssa.c:884 Please submit a full bug report, The program at the web site is provided follows here: !!! ! This program implements a simple molecular dynamics simulation, ! using the velocity Verlet time integration scheme. The particles ! interact with a central pair potential. ! ! Author: Bill Magro, Kuck and Associates, Inc. (KAI), 1998 ! ! Parallelism is implemented via OpenMP directives. ! THIS PROGRAM USES THE FORTRAN90 RANDOM_NUMBER FUNCTION AND ARRAY ! SYNTAX !!! program md implicit none ! simulation parameters integer ndim ! dimensionality of the physical space integer nparts ! number of particles integer nsteps ! number of time steps in the simulation parameter(ndim=3,nparts=500,nsteps=1000) real*8 mass! mass of the particles real*8 dt ! time step real*8 box(ndim) ! dimensions of the simulation box parameter(mass=1.0,dt=1.0e-4) ! simulation variables real*8 position(ndim,nparts) real*8 velocity(ndim,nparts) real*8 force(ndim,nparts) real*8 accel(ndim,nparts) real*8 potential, kinetic, E0 integer i box(1:ndim) = 10. ! set initial positions, velocities, and accelerations call initialize(nparts,ndim,box,position,velocity,accel) ! compute the forces and energies call compute(nparts,ndim,box,position,velocity,mass, . force,potential,kinetic) E0 = potential + kinetic ! This is the main time stepping loop do i=1,nsteps call compute(nparts,ndim,box,position,velocity,mass, . force,potential,kinetic) write(*,*) potential, kinetic,(potential + kinetic - E0)/E0 call update(nparts,ndim,position,velocity,force,accel,mass,dt) enddo end !!! ! Compute the forces and energies, given positions, masses, ! and velocities !!! subroutine compute(np,nd,box,pos,vel,mass,f,pot,kin) implicit none integer np integer nd real*8 box(nd) real*8 pos(nd,np) real*8 vel(nd,np) real*8 f(nd,np) real*8 mass real*8 pot real*8 kin real*8 dotr8 external dotr8 real*8 v, dv, x integer i, j, k real*8 rij(nd) real*8 d real*8 PI2 parameter(PI2=3.14159265d0/2.0d0) ! statement function for the pair potential and its derivative ! This potential is a harmonic well which smoothly saturates to a ! maximum value at PI/2. v(x) = sin(min(x,PI2))**2. dv(x) = 2.*sin(min(x,PI2))*cos(min(x,PI2)) pot = 0.0 kin = 0.0 ! The computation of forces and energies is fully parallel. !$omp parallel do !$omp default(shared) !$omp private(i,j,k,rij,d) !$omp reduction(+ : pot, kin) do i=1,np ! compute potential energy and forces f(1:nd,i) = 0.0 do j=1,np if (i .ne. j) then call dist(nd,box,pos(1,i),pos(1,j),rij,d) ! attribute half of the potential energy to particle 'j' pot = pot + 0.5*v(d) do k=1,nd f(k,i) = f(k,i) - rij(k)*dv(d)/d enddo endif enddo ! compute kinetic energy kin = kin + dotr8(nd,vel(1,i),vel(1,i)) enddo !$omp end parallel do kin = kin*0.5*mass return end !!! ! Initialize the positions, velocities, and accelerations. ! The Fortran90 random_number function is used to choose positions. !!! subroutine initialize(np,nd,box,pos,vel,acc) implicit none integer np integer nd real*8 box(nd) real*8 pos(nd,np) real*8 vel(nd,np) real*8 acc(nd,np) integer i, j real*8 x do i=1,np do j=1,nd call
[Bug libgomp/24682] Sample program at OpenMP web site fails with ICE
--- Comment #1 from magnus_os at yahoo dot se 2005-11-05 11:17 --- I just found out that I made a small misstake in the copy paste of the example. One line the initialize subroutine has two variable declarations like this: integer i, j real*8 x Please press Return to separate these two statements. Sorry about this. -- magnus_os at yahoo dot se changed: What|Removed |Added CC||magnus_os at yahoo dot se Keywords||openmp http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24682
[Bug fortran/24643] Unclassifiable statement on implicitly typed character substring
--- Comment #7 from toon at moene dot indiv dot nluug dot nl 2005-11-05 11:51 --- I got some preliminary results from debugging. By -fdump-parse-tree, YLOCAL does have the correct (implicitly determined) type of CHARACTER*8 at statement YLOCAL='A'. However, by the time we reach gfc_match_rvalue for the next statement YBTABLE=YLOCAL(1:2) its type is BT_UNKNOWN. So something has to squash the correctly determined type. How does one find out ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24643
[Bug target/24683] New: [4.1 Regression] ICE in in extract_insn, at recog.c:2084
Compiling kdenetwork3 we get /abuild/buildsystem.f198.rguenther/usr/lib64/gcc/x86_64-suse-linux/4.1.0/cc1plus -fpreprocessed hash.3.1.ii -quiet -dumpbase hash.cpp -mtune=k8 -ansi -auxbase-strip .libs/libiris_xmpp_core_la-hash.o -O2 -O2 -Wno-long-long -Wundef -Wcast-align -Wconversion -Wchar-subscripts -Wall -W -Wpointer-arith -Wall -Wformat-security -Wmissing-format-attribute -Wno-non-virtual-dtor -ansi -version -fmessage-length=0 -fno-exceptions -fno-check-new -fno-common -fvisibility=hidden -fPIC -o hash.s hash.3.1.ii:38: error: unrecognizable insn: (insn:HI 58 57 53 0 (set (reg/f:DI 69) (plus:DI (reg/f:DI 70) (const_int 4294967233 [0xffc1]))) -1 (insn_list:REG_DEP_TRUE 57 (nil)) (expr_list:REG_DEAD (reg/f:DI 70) (expr_list:REG_EQUAL (const:DI (plus:DI (symbol_ref/f:DI (*.LC0) [flags 0x2] string_cst 0x2a95abefc0) (const_int 4294967233 [0xffc1]))) (nil hash.3.1.ii:38: internal compiler error: in extract_insn, at recog.c:2084 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://www.suse.de/feedback for instructions. -- Summary: [4.1 Regression] ICE in in extract_insn, at recog.c:2084 Product: gcc Version: 4.1.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: critical Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rguenth at gcc dot gnu dot org GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24683
[Bug c/24599] [4.0/4.1 regression] Overflow for true value
-- bonzini at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |bonzini at gcc dot gnu dot |dot org |org URL||http://gcc.gnu.org/ml/gcc- ||patches/2005- ||11/msg00340.html Status|NEW |ASSIGNED Last reconfirmed|2005-10-31 20:09:11 |2005-11-05 12:13:01 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24599
[Bug target/24683] [4.1 Regression] ICE in in extract_insn, at recog.c:2084
--- Comment #1 from rguenth at gcc dot gnu dot org 2005-11-05 12:13 --- Created an attachment (id=10152) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10152action=view) reduced testcase testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24683
[Bug target/19672] [3.4] Performance regression in simple loop code
--- Comment #18 from bonzini at gcc dot gnu dot org 2005-11-05 12:15 --- Patch had to be reverted on 3.4 -- bonzini at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Known to fail|3.3.3 3.4.0 4.0.0 4.1.0 |3.3.3 3.4.5 4.0.2 Known to work|2.95.3 3.2.3|2.95.3 3.2.3 4.0.3 4.1.0 Resolution|FIXED | Summary|[3.4/4.0/4.1 Regression]|[3.4] Performance regression |Performance regression in |in simple loop code |simple loop code| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19672
[Bug rtl-optimization/23392] [4.1 Regression] foward-1.m fails with -funroll-loops -O3 -fgnu-runtime
--- Comment #12 from pinskia at gcc dot gnu dot org 2005-11-05 14:14 --- (In reply to comment #11) This is probably a dup of Bug 22509, which has a patch. Can someone check if this bug is fixed by the patch from Bug 22509? I doubt this is related at all to PR 22509 because this has to do with checking of register number to another register (after reload) without updating the eh info. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23392
[Bug target/24683] [4.1 Regression] ICE in in extract_insn, at recog.c:2084
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-05 14:17 --- Isn't this a dup of bug 20928. (I will try with a GCC after that patch to double check). -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24683
[Bug target/24683] [4.1 Regression] ICE in in extract_insn, at recog.c:2084
--- Comment #3 from rguenth at gcc dot gnu dot org 2005-11-05 14:25 --- I doubt, the compiler is from Nov 4, while the patch looks like comitted at latest Oct 31. But I haven't re-checked against mainline HEAD. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.1.0 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24683
[Bug libgcj/24616] linking BC-compiled classes: NoClassDefFoundErrors should be deferred
--- Comment #4 from thebohemian at gmx dot net 2005-11-05 14:57 --- By further inspecting the problem I got the impression that gcj's approach of linking is flawed. As I understand it gcj does linking-on-initialization but for the java language, being built-around the idea of late binding, it would be better if gcj does the linking step when a particular entity (field, method) is used for the first time. That could mean that we should fill in the atables with the address to a certain linkMe() function which then replaces itself if this succeeds or throws an Error (NoClassDefFoundError, NoSuchMethodError or NoSuchFieldError). Comments? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24616
[Bug target/24683] [4.1 Regression] ICE in in extract_insn, at recog.c:2084
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-11-05 15:07 --- Fails also with 4.1.0 20051026 and with last night's compiler. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24683
[Bug rtl-optimization/24683] [4.1 Regression] ICE in in extract_insn, at recog.c:2084
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-11-05 15:13 --- This is another loop.c bug. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Component|target |rtl-optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24683
[Bug driver/24684] New: No flag documentation for gomp (openmp)
Using --help flag, there is no description of how to use OpenMP, which flag (which is -fopenmp), etc. Without documentation, it is impossible for ordinary users to use the Gomp OpenMP implementation. -- Summary: No flag documentation for gomp (openmp) Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: driver AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: laksono at cs dot uh dot edu GCC build triplet: SMP Itanium64 GCC host triplet: SMP Itanium64 GCC target triplet: SMP Itanium64 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24684
[Bug driver/24684] No flag documentation for gomp (openmp)
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-05 15:29 --- try --help -v. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24684
[Bug rtl-optimization/24683] [4.1 Regression] ICE in in extract_insn, at recog.c:2084
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-11-05 15:50 ---
Confirmed (reduced C or C++ testcase):
int* block;
void final(){
unsigned int i, j;
unsigned char* data = (unsigned char *)\0;
for (i = 0; i 8;i++)
for ( ;j + 63 1;j += 64)
block = (int*) data[j];
}
--
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 |2005-11-05 15:50:10
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24683
[Bug rtl-optimization/24683] [4.1 Regression] ICE in in extract_insn, at recog.c:2084
--- Comment #7 from pinskia at gcc dot gnu dot org 2005-11-05 15:56 ---
Here is a reduced testcase without an uninitialized variable:
int* block;
void final(unsigned int j){
unsigned int i;
unsigned char* data = (unsigned char *)\0;
for (i = 0; i 8;i++)
for (;j + 63 1;j += 64)
block = (int*) data[j];
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24683
[Bug libgcj/24616] linking BC-compiled classes: NoClassDefFoundErrors should be deferred
--- Comment #5 from thebohemian at gmx dot net 2005-11-05 15:59 --- Created an attachment (id=10153) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10153action=view) preliminary patch - just for review Here is a first start for a patch that makes access to static methods lazy. The idea is to find out when the target class is missing and put a pointer to a generic method which throws a NoClassDefFoundError on execution into the atable slot. I post this in the hope to receive comments about the approach. Please ignore debugging stuff in link.cc - this is not the final patch. :) One thing however remains to be solved: The function throwing the NoClassDefFoundError cannot provide the information which class definition is missing. Is there a function from which I can get the class name the method belongs to? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24616
[Bug rtl-optimization/24683] [4.1 Regression] ICE in in extract_insn, at recog.c:2084
--- Comment #8 from rguenth at gcc dot gnu dot org 2005-11-05 16:00 --- Honza, can you look at this? Thanks. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||hubicka at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24683
[Bug rtl-optimization/24683] [4.0/4.1 Regression] ICE in in extract_insn, at recog.c:2084
--- Comment #9 from pinskia at gcc dot gnu dot org 2005-11-05 16:01 --- The reduced testcase in comment #7 fails also in 4.0.3 and 4.0.2. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Known to fail|4.1.0 |4.1.0 4.0.3 4.0.2 Known to work|4.0.3 |3.4.0 Summary|[4.1 Regression] ICE in in |[4.0/4.1 Regression] ICE in |extract_insn, at|in extract_insn, at |recog.c:2084|recog.c:2084 Target Milestone|4.1.0 |4.0.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24683
[Bug rtl-optimization/24683] [3.4/4.0/4.1 Regression] ICE in in extract_insn, at recog.c:2084
--- Comment #10 from pinskia at gcc dot gnu dot org 2005-11-05 16:10
---
And here is a testcase which fails in 3.4.5 and above:
int* block;
void final(unsigned int j){
int * lsm_tmp1;
unsigned char * data;
unsigned int i;
data = (unsigned char *) ;
lsm_tmp1 = block;
i = 0;
do {
if (j == 4294967233)
{
lsm_tmp1 = (int *) (data + 4294967233);
j = 1;
}
i = i + 1;
} while (i != 8);
block = lsm_tmp1;
}
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Known to fail|4.1.0 4.0.3 4.0.2 |4.1.0 4.0.3 4.0.2 3.4.5
Known to work|3.4.0 |3.3.6
Summary|[4.0/4.1 Regression] ICE in |[3.4/4.0/4.1 Regression] ICE
|in extract_insn, at |in in extract_insn, at
|recog.c:2084|recog.c:2084
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24683
[Bug rtl-optimization/24683] [3.4/4.0/4.1 Regression] ICE in in extract_insn, at recog.c:2084
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|critical|normal GCC target triplet|x86_64-unknown-linux-gnu|x86_64-*-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24683
[Bug rtl-optimization/24683] [3.4/4.0/4.1 Regression] ICE in in extract_insn, at recog.c:2084
--- Comment #11 from steven at gcc dot gnu dot org 2005-11-05 16:34 --- Comment #5 is not helpful. Why is this a loop.c bug, you think? In my backtrace we bail out from regmove. It would be far more helpful if you'd add some explanation for why you think this is a loop.c bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24683
[Bug rtl-optimization/24683] [3.4/4.0/4.1 Regression] ICE in in extract_insn, at recog.c:2084
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |critical http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24683
[Bug rtl-optimization/24683] [3.4/4.0/4.1 Regression] ICE in in extract_insn, at recog.c:2084
--- Comment #12 from steven at gcc dot gnu dot org 2005-11-05 16:55 --- Breakpoint 4, emit_move_insn (x=0x2a95a69320, y=0x2a9594c820) at expr.c:3140 3140 enum machine_mode mode = GET_MODE (x); (gdb) p debug_rtx(x) (reg:DI 68) $10 = void (gdb) p debug_rtx(y) (const:DI (plus:DI (symbol_ref/f:DI (*.LC0) [flags 0x2] string_cst 0x2a95a62510) (const_int 4294967233 [0xffc1]))) $11 = void (gdb) bt #0 emit_move_insn (x=0x2a95a69320, y=0x2a9594c820) at expr.c:3140 #1 0x00a6e5a9 in move_movables (loop=0xe72f80, movables=0xe766d8, threshold=93, insn_count=9) at loop.c:2365 #2 0x00a6c59a in scan_loop (loop=0xe72f80, flags=0) at loop.c:1522 #3 0x00a6a1a1 in loop_optimize (f=0x2a9589b940, dumpfile=0x0, flags=0) at loop.c:909 #4 0x00a81e30 in rest_of_handle_loop_optimize () at loop.c:11784 #5 0x00946f77 in execute_one_pass (pass=0xd9ae80) at passes.c:827 A bit further down: 3185 last_insn = emit_move_insn_1 (x, y); (gdb) disab 4 (gdb) next 3187 if (y_cst REG_P (x) (gdb) p debug_rtx(last_insn) (insn 60 59 0 (set (reg:DI 68) (plus:DI (reg/f:DI 69) (const_int 4294967233 [0xffc1]))) -1 (nil) (nil)) $12 = void (gdb) p recog_memoized (last_insn) $13 = -1 (gdb) next 3191set_unique_reg_note (last_insn, REG_EQUAL, y_cst); (gdb) 3193 return last_insn; (gdb) 3194} So there's your wrong instruction, produced by emit_move_insn itself... :-( -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24683
[Bug rtl-optimization/24683] [3.4/4.0/4.1 Regression] ICE in in extract_insn, at recog.c:2084
--- Comment #13 from steven at gcc dot gnu dot org 2005-11-05 16:59 --- ICE on a primary platform, in a popular package. -- steven at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24683
[Bug fortran/24534] [4.0/4.1 Regression] PUBLIC derived types with private components
--- Comment #8 from pault at gcc dot gnu dot org 2005-11-05 17:22 --- This is clearly nonsense. Although the type my_t is PUBLIC, its components are not. No, this is not nonsense, just incorrect. See PR16404 and the discussion about test #6. I have incompletely applied the constraint. . standard have a peculiar order, but the first constraint after R427 says: If a component of a derived type is of a ttype declared to be private, either the derived type definition must contain the PRIVATE stement, or the derived type must be private. Therefore, the addition of sym-component_access != ACCESS_PRIVATE to the if statement that produces the error and the addition of your testcase to the testsuite fixes the problem (It's just now regtesting). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24534
[Bug rtl-optimization/24683] [3.4/4.0/4.1 Regression] ICE in in extract_insn, at recog.c:2084
--- Comment #14 from pinskia at gcc dot gnu dot org 2005-11-05 17:26 --- (In reply to comment #13) ICE on a primary platform, in a popular package. As I mentioned in another bug, I think Mark should be the only one which changes the Priority. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24683
[Bug rtl-optimization/24683] [3.4/4.0/4.1 Regression] ICE in in extract_insn, at recog.c:2084
--- Comment #15 from pinskia at gcc dot gnu dot org 2005-11-05 17:31 --- (In reply to comment #14) (In reply to comment #13) ICE on a primary platform, in a popular package. As I mentioned in another bug, I think Mark should be the only one which changes the Priority. I should note that Mark agreed with me (though it was via a private email). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24683
[Bug rtl-optimization/24683] [3.4/4.0/4.1 Regression] ICE in in extract_insn, at recog.c:2084
--- Comment #16 from pinskia at gcc dot gnu dot org 2005-11-05 17:47
---
And here is one which also fails in 3.3.6:
int final(int j){
unsigned int i = 0;
do {
if (j)
j = (__SIZE_TYPE__)[4294967233];
i = i + 1;
} while (i != 8);
return j;
}
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Known to fail|4.1.0 4.0.3 4.0.2 3.4.5 |4.1.0 4.0.3 4.0.2 3.4.5
||3.3.6
Known to work|3.3.6 |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24683
[Bug rtl-optimization/24683] [3.4/4.0/4.1 Regression] ICE in in extract_insn, at recog.c:2084
--- Comment #17 from pinskia at gcc dot gnu dot org 2005-11-05 17:48 --- (In reply to comment #16) And here is one which also fails in 3.3.6: Hmm but passes in 4.0.3. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24683
[Bug rtl-optimization/24683] [3.4/4.0/4.1 Regression] ICE in in extract_insn, at recog.c:2084
--- Comment #18 from rguenth at gcc dot gnu dot org 2005-11-05 17:50 --- Note that the original problem, ICE in kdenetwork3 only happens with mainline. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24683
[Bug libfortran/24174] real(10) array output broken
--- Comment #10 from jblomqvi at cc dot hut dot fi 2005-11-05 18:07 --- Updated**2 patch here: http://gcc.gnu.org/ml/gcc-patches/2005-11/msg00348.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24174
[Bug libfortran/24305] Complex(10) formatted IO is broken.
--- Comment #2 from jblomqvi at cc dot hut dot fi 2005-11-05 18:08 --- Patch (that also fixes PR 24174) here: http://gcc.gnu.org/ml/gcc-patches/2005-11/msg00348.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24305
[Bug fortran/22519] Memory and binary disk layout disagree for real*10
--- Comment #6 from jblomqvi at cc dot hut dot fi 2005-11-05 18:12 --- (In reply to comment #5) (In reply to comment #4) We need to settle what kind of disk image we want for real(kind=10) before resolving this for complex. I am strongly in favour of real(kind=10) being written as 12 bytes on disk. This will make life much easier for all of us, and might speed things up. The patch I have posted for PR 24174 and PR 24305 writes the padded size (i.e. 12 bytes on x86, and AFAIK 16 bytes on x86-64 and IA-64). Now that we have gotten rid of mmap and support bulk transfers of arrays, this stuff actually makes a difference. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22519
[Bug c++/24605] [4.0/4.1 Regression] internal compiler error: Segmentation fault while compiling c++ file
--- Comment #7 from ron_hylton at hotmail dot com 2005-11-05 18:49 ---
(In reply to comment #5)
I tried out a few cross compilers for i686-pc-cygwin over the last few
months. The code compiled cleanly on 20040607. Sometime between then
and 20040709 it started failing with a different ICE from what it gets now.
For awhile (at least from 20040921-20051127) it got only:
C:/rah/Vc/CppLib/RefCntUtil.h:119: error: declaration of
`RefCntUtil::ucPtrT::operator T*() const'
C:/rah/Vc/CppLib/RefCntUtil.h:101: error: conflicts with previous declaration
`RefCntUtil::ucPtrT::operator X*() const'
That error went away. The current ICE and several of the other errors started
sometime between 20050227-20050404. Here's a testcase for one of them:
class CloneableObject
{
friend class CloneWalker;
public:
virtual void WalkClone(CloneWalker) const = 0;
};
class CloneWalker
{
CloneWalker(int) {}
CloneWalker(void) {}
};
It fails on powerpc-linux with error: CloneWalker has not been declared,
the first error that the large testcase gets, not the one that leads to
the ICE.
There is a missing forward declaration for class CloneWalker in the supplied
test case (although I believe older versions of gcc did not require this). I
have posted a revised test case where I added the declaration and fixed another
problem. With this test case and gcc 4.1.0,
gcc -c compiles
gcc -c -O2 gives a segmentation fault
If the forward declaration of class CloneWalker at line 50437 is commented out,
gcc -c (4.1.0) gives a number of error messages before
C:/rah/Vc/CppLib/ADI2FwdStartSolver.h:148: internal compiler error: in
adjust_re
sult_of_qualified_name_lookup, at cp/search.c:1488
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24605
[Bug c++/24605] [4.0/4.1 Regression] internal compiler error: Segmentation fault while compiling c++ file
--- Comment #8 from ron_hylton at hotmail dot com 2005-11-05 18:51 --- Created an attachment (id=10154) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10154action=view) modified test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24605
[Bug fortran/24682] [GOMP] Sample program at OpenMP web site fails with ICE
--- Comment #2 from jakub at gcc dot gnu dot org 2005-11-05 19:25 --- This works with the 5 extra patches I have in my tree for VLA support (same problem as on libgomp/testsuite/libgomp.fortran/vla1.f90). -- 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 |2005-11-05 19:25:07 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24682
[Bug libfortran/24685] New: real(10) formatted input is broken for huge values
Seems that the parsing routines cannot deal with big values:
! { dg-do run }
! { dg-require-effective-target fortran_large_real }
program huge_real10_formatted
! This should be kind=10 on systems that support it
integer, parameter :: k = selected_real_kind (precision (0.0_8) + 1)
real(kind=k) :: a,b(2), c
character(len=180) :: tmp
! Test real(k) scalar and array formatted IO with big value
b(:) = huge (1.0_k)/2
print *, 'real(10) big value: ', b(1)
write (tmp, *) b
read (tmp, *) a, c
print *, 'same value read again: ', a
print *, 'difference: ', a-b(1)
! Test with really big value
b(:) = huge (1.0_k)
print *, 'huge value: ', b(1)
write (tmp, *) b
read (tmp, *) a, c ! This is line 19
print *, We don't get this far!
if (a /= b(1)) call abort ()
if (c /= b(2)) call abort ()
end program huge_real10_formatted
Running this produces:
real(10) big value: 5.948657476786159E+4931
same value read again: 5.948657476786159E+4931
difference: 1.751052108159553E+4915
huge value: 1.189731495357232E+4932
At line 19 of file huge_real10_formatted.f90
Fortran runtime error: Range error during floating point read
Looking at the difference, there also seems to be some problem with
arithmetic..
--
Summary: real(10) formatted input is broken for huge values
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libfortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jblomqvi at cc dot hut dot fi
GCC host triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24685
[Bug middle-end/24279] SEGV at reload.c:2400 with -O2
--- Comment #6 from shap at eros-os dot org 2005-11-05 19:44 --- I know you folks have many other things to do, but any further ideas on this one? If not, what can I do to help get the test case confirmed and into the regression suite? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24279
[Bug middle-end/22275] [3.4/4.0/4.1 Regression] bitfield layout change (regression?)
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |critical http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22275
[Bug tree-optimization/24665] [4.0/4.1 Regression] internal compiler error: get_indirect_ref_operands
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-11-05 20:30 --- Something is not gimplifing an expression: *(struct RegisterLayoutD.2065 *) (charD.3 *) SimulatedRegistersD.2082 -- # SimulatedRegistersD.2082_6 = V_MAY_DEF SimulatedRegistersD.2082_5; ((struct RegisterLayoutD.2065 *) (charD.3 *) SimulatedRegistersD.2082)-intmaskD.2067 = 0 CCP it looks like. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24665
[Bug c/24644] [4.1 Regression] gcc-4.1 compiled ppc64 kernels do not boot
--- Comment #23 from olh at suse dot de 2005-11-05 20:31 --- this patch works, tested with r106530 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24644
[Bug tree-optimization/24665] [4.0/4.1 Regression] internal compiler error: get_indirect_ref_operands
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-11-05 20:34 --- Lattice value changed to CONSTANT ((struct RegisterLayout *) (char *) SimulatedRegisters)-intmask. Adding SSA edges to worklist. Substituing values and folding statements Folded statement: mpMaskRegister.0_4 = mpMaskRegister; into: mpMaskRegister.0_4 = ((struct RegisterLayout *) (char *) SimulatedRegisters)-intmask; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24665
[Bug fortran/15502] [meta-bug] bugs needed for SPEC CPU 2K and 2K5/6 and 95
--- Comment #3 from tkoenig at gcc dot gnu dot org 2005-11-05 21:53 --- (In reply to comment #2) Note there are still some more 2k5/6 SPEC blocking bugs which just had not been filed yet. Well, can anybody file them? I don't have access to the SPEC suite. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added CC||tkoenig at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15502
[Bug fortran/22495] Different ideas about .true. and .false.
--- Comment #5 from tkoenig at gcc dot gnu dot org 2005-11-05 22:05 --- Hmm... in this case, I think we should document that only 0 and 1 are valid for logical types, and if the user stuffs anything else into one of our logicals, he is on his own. After we have documented this, we can close this bug as WONTFIX. Agreed? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22495
[Bug fortran/23815] Add -byteswapio flag
--- Comment #11 from tkoenig at gcc dot gnu dot org 2005-11-05 22:21 --- OK, for the interface... My suggestion would be to have three levels of supplying this value (ifort has five or six :-) First, an option to supply to the compiler. This could be -fconvert=big_endian -fconvert=little_endian -fconvert=native (the default) and maybe, at a later date, -fconvert=vax_d -fconvert=ibm_360. This would be valid for all the units. With this option alone, it would not be possible to write a conversion program, so we need something else. This could be overridden by a CONVERT=BIG_ENDIAN etc. in the OPEN statement. This, in turn, could be overridden by environment variables in the format GFORTRAN_CONVERT_BIG_ENDIAN=10,20,30,40 GFORTRAN_CONVERT_LITTLE_ENDIAN=11,21,31,41 Agreed? It would probably best to implement the compiler swith as selecting a library at runtime. I'll leave that to a later date :-) If anybody knows how to set an environment variable in a dejagnu testcase, please tell :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23815
[Bug c++/24686] New: ICE when building a variation of NMSTL
We have a customized version of the NMSTL library, and get an ICE when we build it. (Sorry, I couldn't find directions on how to fill out Host triplet, Target triplet, and Build triplet.) I'm using Ubuntu Linux 5.10. -- Summary: ICE when building a variation of NMSTL Product: gcc Version: 4.0.2 Status: UNCONFIRMED Severity: critical Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: christian dot convey at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24686
[Bug c++/24686] ICE when building a variation of NMSTL
--- Comment #1 from christian dot convey at gmail dot com 2005-11-05 22:35 --- Created an attachment (id=10155) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10155action=view) stdout/stderr from the build process that cause the ICE -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24686
[Bug c++/24686] ICE when building a variation of NMSTL
--- Comment #2 from christian dot convey at gmail dot com 2005-11-05 22:37 --- Created an attachment (id=10156) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10156action=view) Preprocessed output file 1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24686
[Bug c++/24686] ICE when building a variation of NMSTL
--- Comment #3 from christian dot convey at gmail dot com 2005-11-05 22:40 --- Created an attachment (id=10157) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10157action=view) Preprocessed output file 2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24686
[Bug c++/24686] [4.0/4.1 Regression] ICE when building a variation of NMSTL
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-11-05 22:42 --- Reducing. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Summary|ICE when building a |[4.0/4.1 Regression] ICE |variation of NMSTL |when building a variation of ||NMSTL Target Milestone|--- |4.0.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24686
[Bug c++/24687] New: [4.1 Regression] ICE after error
testcase:
typedef struct {
}
extern C++ {
}
extern C {
templatetypename _Tp struct __is_pod { enum {
__value = (sizeof(__gnu_internal::__test_type_Tp(0))!=
sizeof(__gnu_internal::__one)) }; };
--
Summary: [4.1 Regression] ICE after error
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, error-recovery
Severity: normal
Priority: P3
Component: c++
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=24687
[Bug c++/24687] [4.1 Regression] ICE after error
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-05 22:55 --- Note I found this while reducing PR 24686 -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24687
[Bug fortran/22495] Different ideas about .true. and .false.
--- Comment #6 from tobi at gcc dot gnu dot org 2005-11-05 23:06 ---
I did some further research, and while g77 didn't seem to have documented any
of the details of how LOGICALs are implemented, we have the following in
gfortran.texi:755:
@node Implicitly interconvert LOGICAL and INTEGER
@section Implicitly interconvert LOGICAL and INTEGER
@cindex Implicitly interconvert LOGICAL and INTEGER
As a GNU extension for backwards compatibility with other compilers,
@command{gfortran} allows the implicit conversion of LOGICALs to INTEGERs
and vice versa. When converting from a LOGICAL to an INTEGER, the numeric
value of @code{.FALSE.} is zero, and that of @code{.TRUE.} is one. When
converting from INTEGER to LOGICAL, the value zero is interpreted as
@code{.FALSE.} and any nonzero value is interpreted as @code{.TRUE.}.
And this is indeed true and consistent with what g77 does:
[EMAIL PROTECTED]:~/src/tests cat ugly.f
LOGICAL L
DO i=0,5
L = i
PRINT *, l
END DO
END
[EMAIL PROTECTED]:~/src/tests gfortran ugly.f
In file ugly.f:3
L = i
1
Warning: Extension: Conversion from INTEGER(4) to LOGICAL(4) at (1)
[EMAIL PROTECTED]:~/src/tests LD_LIBRARY_PATH=~/usr/lib ./a.out
F
T
T
T
T
T
[EMAIL PROTECTED]:~/src/tests g77 ugly.f -fugly-logint
[EMAIL PROTECTED]:~/src/tests ./a.out
F
T
T
T
T
T
[EMAIL PROTECTED]:~/src/tests
(The INTEGER - LOGICAL conversion is implemented as i = l != 0 as verified
by looking in the tree dumps.)
I think we should be consistent.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22495
[Bug fortran/22495] Different ideas about .true. and .false.
--- Comment #7 from tkoenig at gcc dot gnu dot org 2005-11-05 23:20 ---
(In reply to comment #6)
I think we should be consistent.
g77 also gives inconsistent results with the test program:
$ cat logic.f
program main
implicit none
logical :: lo1, lo2
integer :: in, i
equivalence(lo1, in)
do i=0,4
in = i
call settrue(lo2)
print *,i, lo1 , lo1 .eqv. lo2, lo1 .eqv. .true.
end do
end
subroutine settrue(lo)
logical :: lo
lo = .true.
end subroutine
$ g77 logic.f
$ ./a.out
0 F F F
1 T T T
2 T F F
3 T F F
4 T F F
The test program shows that we don't currently implement the part
When
converting from INTEGER to LOGICAL, the value zero is interpreted as
@code{.FALSE.} and any nonzero value is interpreted as @code{.TRUE.}.
and g77 does something else from what we do.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22495
[Bug target/23435] [4.1 Regression] Unrecognizable insn (in extract_insn, at recog.c)
--- Comment #6 from kazu at gcc dot gnu dot org 2005-11-05 23:23 ---
Reduced down to:
void
foo (unsigned long *a, unsigned long long *p)
{
if (*p == 0)
*p = *a;
}
--
kazu at gcc dot gnu dot org changed:
What|Removed |Added
CC||kazu at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23435
[Bug libfortran/24685] real(10) formatted input is broken for huge values
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2005-11-05 23:24 --- Looking at the difference, there also seems to be some problem with arithmetic.. No, it's only that the default format is not wide enough :) Compared to other compilers, we could probably do something like: Index: io/write.c === --- io/write.c (revision 106521) +++ io/write.c (working copy) @@ -1375,8 +1375,8 @@ f.u.real.e = 3; break; case 10: - f.u.real.w = 24; - f.u.real.d = 15; + f.u.real.w = 40; + f.u.real.d = 31; f.u.real.e = 4; break; case 16: And, accidentaly, the above patch fixes your testcase completely, although I don't know why. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC host triplet|i686-pc-linux-gnu | GCC target triplet||i686-pc-linux-gnu Last reconfirmed|-00-00 00:00:00 |2005-11-05 23:24:13 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24685
[Bug target/23435] [4.1 Regression] Unrecognizable insn (in extract_insn, at recog.c)
--- Comment #7 from kazu at gcc dot gnu dot org 2005-11-05 23:32 ---
Reduced down to:
void
foo (unsigned long *a, unsigned long long *p)
{
*p = *a;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23435
[Bug middle-end/24612] [gomp] Bogus is used uninitialized warning
-- rth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2005-11-03 02:18:10 |2005-11-05 23:33:15 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24612
[Bug c++/24686] [4.0/4.1 Regression] ICE when building a variation of NMSTL
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-11-05 23:46 --- As far as I can see this is valid code (the machine which was doing the reduction crashed or something because I cannot connect to it). -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Keywords||ice-on-valid-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24686
[Bug c++/24687] [4.1 Regression] ICE after error
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-05 23:47 --- Backtrace: #0 0x0813611e in decl_linkage (decl=0xb7ce1870) at /home/peshtigo/pinskia/src/gnu/gcc/src/gcc/cp/tree.c:2171 #1 0x080dc7f2 in retrofit_lang_decl (t=0xb7ce1870) at /home/peshtigo/pinskia/src/gnu/gcc/src/gcc/cp/lex.c:702 #2 0x080dc951 in build_lang_decl (code=CONST_DECL, name=0xb7d7eea0, type=0x0) at /home/peshtigo/pinskia/src/gnu/gcc/src/gcc/cp/lex.c:669 #3 0x0805db46 in build_enumerator (name=0xb7d7eea0, value=0x0, enumtype=0xb7d7db24) at /home/peshtigo/pinskia/src/gnu/gcc/src/gcc/cp/decl.c:9992 #4 0x080ea4d3 in cp_parser_type_specifier (parser=0xb7d7ef70, flags=Variable flags is not available. ) at /home/peshtigo/pinskia/src/gnu/gcc/src/gcc/cp/parser.c:10223 #5 0x080ebac2 in cp_parser_decl_specifier_seq (parser=0xb7d7ef70, flags=CP_PARSER_FLAGS_OPTIONAL, decl_specs=0xbfec9750, declares_class_or_enum=0xbfec97a4) at /home/peshtigo/pinskia/src/gnu/gcc/src/gcc/cp/parser.c:7404 #6 0x080e8f95 in cp_parser_member_declaration (parser=0xb7d7ef70) at /home/peshtigo/pinskia/src/gnu/gcc/src/gcc/cp/parser.c:13275 #7 0x080ea3e4 in cp_parser_type_specifier (parser=0xb7d7ef70, flags=Variable flags is not available. ) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24687
[Bug c++/24687] [4.1 Regression] ICE after error
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-11-05 23:51 ---
Reduced as far as I can get it:
extern C {
templatetypename _Tp struct __is_pod {
enum {
__value = (sizeof(__gnu_internal::__test_type_Tp(0)))};
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24687
[Bug fortran/24682] [GOMP] Sample program at OpenMP web site fails with ICE
--- Comment #3 from jakub at gcc dot gnu dot org 2005-11-05 23:53 --- Fixed in current CVS. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24682
[Bug fortran/22495] Different ideas about .true. and .false.
--- Comment #8 from kargl at gcc dot gnu dot org 2005-11-06 00:02 --- The code is illegal, so every compiler has produced a correct result. -- kargl at gcc dot gnu dot org changed: What|Removed |Added CC||kargl at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22495
[Bug target/23435] [4.1 Regression] Unrecognizable insn (in extract_insn, at recog.c)
-- kazu at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |kazu at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23435
[Bug c++/24686] [4.0/4.1 Regression] ICE when building a variation of NMSTL
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-11-06 00:18 ---
Confirmed, reduced testcase:
struct string {
struct _Alloc_hider {
~_Alloc_hider();
};
mutable _Alloc_hider _M_dataplus;
};
templateclass T string to_string(const T t);
struct debug_msg {
debug_msg(int);
templateclass T debug_msg operator (const T t);
};
struct debug {
static debug get() {
}
bool operator ^ (const debug_msg msg);
};
int f();
int i;
void set_handler(int fd) {
(i = 1) debug::get() ^ debug_msg(({
static int l = f();
l;
}
)) to_string(1);
}
--
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 |2005-11-06 00:18:05
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24686
[Bug c++/24686] [4.0/4.1 Regression] ICE when building a variation of NMSTL
--- Comment #7 from pinskia at gcc dot gnu dot org 2005-11-06 00:22 --- Note -fno-threadsafe-statics makes this works. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24686
[Bug fortran/22495] Different ideas about .true. and .false.
--- Comment #9 from tobi at gcc dot gnu dot org 2005-11-06 00:22 ---
One can get quite interesting results out of g77, e.g.
[EMAIL PROTECTED]:~/src/tests cat ugly.f
LOGICAL L, M
equivalence (i,l)
DO i=0,5
M = i
PRINT (5l2), l, m, l.neqv..true., m.neqv..true., m.neqv.l
END DO
END
[EMAIL PROTECTED]:~/src/tests g77 ugly.f -fugly-logint
[EMAIL PROTECTED]:~/src/tests ./a.out
F F T T F
T T F F F
T T T T F
T T T T F
T T T T F
T T T T F
[EMAIL PROTECTED]:~/src/tests
replacing .neqv. with .eqv. on the other hand gives the correct result.
The test program shows that we don't currently implement the part
When
converting from INTEGER to LOGICAL, the value zero is interpreted as
@code{.FALSE.} and any nonzero value is interpreted as @code{.TRUE.}.
Note that the equivalence doesn't imply conversion, so we don't contradict our
documentation.
Overall, given the inconsistencies in g77, and also between different other
compilers, I think we shouldn't bother fixing this. I agree that adding a
warning to the documentation is a good idea.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22495
[Bug fortran/22495] Different ideas about .true. and .false.
-- tobi at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Keywords||documentation http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22495
[Bug bootstrap/24688] New: sco_math fixincl breaks math.h
I'm trying to bootstrap gcc-3.4.3 on HP-UX 11.23/IA-64. I'm bootstrapping with
the HP C compiler. The system has patch PHSS_33351 installed. The tail of
/usr/include/math.h:
inline int sqr(int __x) {return(__x*__x);}
inline double sqr(double __x) {return(__x*__x);}
# ifndef _STDLIB_INCLUDED
inline int abs(int __d) { return (__d0)?__d:-__d; }
# endif /* _STDLIB_INCLUDED */
inline double abs(double __d) { return fabs(__d); }
inline double pow(double __d,int __expon) { return pow(__d,(double)__expon);
}
#endif
#endif /* _MATH_INCLUDED */
The tail of math.h after fixinc:
inline double sqr(double __x) {return(__x*__x);}
# ifndef _STDLIB_INCLUDED
inline int abs(int __d) { return (__d0)?__d:-__d; }
# endif /* _STDLIB_INCLUDED */
#ifndef __GNUC__
inline double abs(double __d) { return fabs(__d); }
inline double pow(double __d,int __expon) { return pow(__d,(double)__expon);
}
#endif
#endif /* _MATH_INCLUDED */
Looking at inclhack.def, sco_math seems to be the cause of this. I replaced
'inline double abs' in select of sco_math with 'inline double _abs' and the
#ifndef __GNUC__ wasn't included in the new math.h.
--
Summary: sco_math fixincl breaks math.h
Product: gcc
Version: 3.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bugzilla-gcc at thewrittenword dot com
GCC build triplet: ia64-hp-hpux11.23
GCC host triplet: ia64-hp-hpux11.23
GCC target triplet: ia64-hp-hpux11.23
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24688
[Bug bootstrap/24688] sco_math fixincl breaks math.h
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-06 00:24 --- I thought this was fixed in 3.4.4. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24688
[Bug fortran/22495] Different ideas about .true. and .false.
--- Comment #10 from kargl at gcc dot gnu dot org 2005-11-06 00:32 --- Do we care? Equivalencing integer and logical is prohibited (although we don't warn about this with --std=f95; maybe that is the error). Thomas, can you point to the text in the standard that prohibits the equivalence of integer and logical. AFAICT, the 4th constraint in 5.5.1, contradicts your assertation. -- kargl at gcc dot gnu dot org changed: What|Removed |Added Severity|enhancement |normal Last reconfirmed|2005-09-24 05:30:15 |2005-11-06 00:32:32 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22495
[Bug bootstrap/24688] sco_math fixincl breaks math.h
--- Comment #2 from bugzilla-gcc at thewrittenword dot com 2005-11-06 00:45 --- I'm using the version of inclhack.def from gcc-3_4-branch. I looked at the changes in http://gcc.gnu.org/viewcvs/branches/gcc-3_4-branch/gcc/fixinc/inclhack.def?rev=100333view=log and don't see anything relating to this. Looking at the latest inclhack.def from gcc-3_4-branch, this sed line in sco_math is causing the problem: sed = /extern \C\\+\\+\/N; /inline double abs/i\\\n #ifndef __GNUC__\n; I have no idea what math.h looks like on SCO so I have no idea how to fix. Why don't we restrict sco_math to some mach=*sco*? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24688
[Bug c++/21308] [3.4/4.0/4.1 Regression] Very high compile time
--- Comment #11 from mmitchel at gcc dot gnu dot org 2005-11-06 00:55
---
I thought that a key observation is that we only need to know (a) what empty
subobjects are at offset zero, and (b) what empty subobjects occur before the
location where we will next place a non-empty field or base. Therefore, we can
avoid recording the offsets for any of the empty objects in the array other
than those at offset zero.
However, I forgot that empty classes do not necessarily have size one:
class A {};
class B : public A {};
class C : public A, public B {}; // C empty, sizeof (C) == 2
So, the observation above has to be modified -- instead of just offset zero we
must care about empty objects at offsets N, where N is the sizeof the largest
empty class we have thus far encountered in the translation unit.
That should still permit very considerable improvement. I plan to work on
implementing this improvement soon.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21308
[Bug middle-end/24612] [gomp] Bogus is used uninitialized warning
--- Comment #3 from rth at gcc dot gnu dot org 2005-11-06 00:55 --- Subject: Bug 24612 Author: rth Date: Sun Nov 6 00:55:43 2005 New Revision: 106551 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=106551 Log: PR middle-end/24612 * omp-low.c (expand_rec_input_clauses): Set TREE_NO_WARNING for pass-by-value shared variables. Added: branches/gomp-20050608-branch/gcc/testsuite/gcc.dg/gomp/uninit-1.c Modified: branches/gomp-20050608-branch/gcc/ChangeLog.gomp branches/gomp-20050608-branch/gcc/omp-low.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24612
[Bug middle-end/24612] [gomp] Bogus is used uninitialized warning
--- Comment #4 from rth at gcc dot gnu dot org 2005-11-06 00:56 --- Fixed. -- rth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24612
[Bug libstdc++/23953] using stringstreams causes crashes with some locales
--- Comment #7 from paolo at gcc dot gnu dot org 2005-11-06 01:12 --- Subject: Bug 23953 Author: paolo Date: Sun Nov 6 01:12:23 2005 New Revision: 106553 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=106553 Log: 2005-11-05 Paolo Carlini [EMAIL PROTECTED] PR libstdc++/23953 * include/bits/locale_facets.tcc (__numpunct_cache::_M_cache, __moneypunct_cache::_M_cache): Check that grouping()[0] 0. (__verify_grouping): Do the last check only if __grouping[__min] 0. (__add_grouping): End recursion if *__gbeg = 0. * testsuite/22_locale/num_get/get/char/23953.cc: New. * testsuite/22_locale/num_get/get/wchar_t/23953.cc: Likewise. * testsuite/22_locale/num_put/put/char/23953.cc: Likewise. * testsuite/22_locale/num_put/put/wchar_t/23953.cc: Likewise. Added: branches/gcc-4_0-branch/libstdc++-v3/testsuite/22_locale/num_get/get/char/23953.cc branches/gcc-4_0-branch/libstdc++-v3/testsuite/22_locale/num_get/get/wchar_t/23953.cc branches/gcc-4_0-branch/libstdc++-v3/testsuite/22_locale/num_put/put/char/23953.cc branches/gcc-4_0-branch/libstdc++-v3/testsuite/22_locale/num_put/put/wchar_t/23953.cc Modified: branches/gcc-4_0-branch/libstdc++-v3/ChangeLog branches/gcc-4_0-branch/libstdc++-v3/include/bits/locale_facets.tcc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23953
[Bug libstdc++/23953] using stringstreams causes crashes with some locales
--- Comment #8 from pcarlini at suse dot de 2005-11-06 01:13 --- Fixed for 4.0.3. -- pcarlini at suse dot de changed: What|Removed |Added AssignedTo|pcarlini at suse dot de |unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23953
[Bug libstdc++/23953] using stringstreams causes crashes with some locales
--- Comment #9 from pcarlini at suse dot de 2005-11-06 01:13 --- Oops... -- pcarlini at suse dot de changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23953
[Bug target/24265] [4.1 Regression] ICE: in extract_insn, at recog.c:2084 with -O -fgcse -fmove-loop-invariants -mtune=pentiumpro
--- Comment #6 from steven at gcc dot gnu dot org 2005-11-06 01:20 --- Oh well, I'll try and fix this... -- steven at gcc dot gnu dot org changed: What|Removed |Added CC||steven at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24265
[Bug target/20583] [4.0/4.1 regression] ICE in output_operand: invalid expression as operand
--- Comment #7 from kazu at gcc dot gnu dot org 2005-11-06 02:10 ---
Reduced down to:
void bar (unsigned int);
void
foo (void)
{
char buf[1] = { 3 };
const char *p = buf;
const char **q = p;
unsigned int ch;
switch (**q)
{
case 1: ch = 5; break;
case 2: ch = 4; break;
case 3: ch = 3; break;
case 4: ch = 2; break;
case 5: ch = 1; break;
default: ch = 0; break;
}
bar (ch);
}
This is one of those rare cases where CSE1 folds a switch statement.
--
kazu at gcc dot gnu dot org changed:
What|Removed |Added
CC||kazu at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20583
[Bug tree-optimization/24689] New: store_ccp is missing an opportunity!?
Consider:
extern void bar (unsigned int);
int
foo (void)
{
char buf[1] = { 3 };
const char *p = buf;
const char **q = p;
unsigned int ch;
switch (**q)
{
case 1: ch = 5; break;
default: ch = 0; break;
}
#if 1
bar (ch);
#endif
return ch;
}
This function should be optimized to return 0;, but it isn't.
Interestingly, if you change #if 1 to #if 0, you are going to get
this optimized.
The testcase is derived from PR 20583.
--
Summary: store_ccp is missing an opportunity!?
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kazu at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24689
[Bug c++/24690] New: error using TinyVector temporary as default constructor value
Using TinyVector from the Blitz++ C++ library (http://www.oonumerics.org/b as a
temporary to initialize a default constructor values gives errors. The actual
code follows. Preprocessed code attached.
#include blitz/tinyvec-et.h
class Foo
{
blitz::TinyVectordouble, 3 x;
Foo(blitz::TinyVectordouble, 3 _x =
blitz::TinyVectordouble, 3(0.0))
: x(_x){}
};
int main()
{
return 0;
}
--
Summary: error using TinyVector temporary as default constructor
value
Product: gcc
Version: 3.3.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: faheem at email dot unc dot edu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24690
[Bug c++/24690] error using TinyVector temporary as default constructor value
--- Comment #1 from faheem at email dot unc dot edu 2005-11-06 03:05 --- Created an attachment (id=10158) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10158action=view) Preprocessed file showing the error Error is: foo.cc:15: error: type specifier omitted for parameter foo.cc:15: error: parse error before numeric constant foo.cc:16: error: missing ';' before right brace -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24690
[Bug target/20583] [4.0/4.1 regression] ICE in output_operand: invalid expression as operand
-- kazu at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |kazu at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20583
[Bug rtl-optimization/24497] [3.4/4.0/4.1 Regression] internal compiler error: in apply_opt_in_copies, at loop-unroll.c:2122
--- Comment #3 from kazu at gcc dot gnu dot org 2005-11-06 04:25 --- Not reproducible using x86_64-pc-linux-gnu X m68k-none-elf. Paul, is this still reproducible? I also tried, gcc.c-torture/execute/920501-6.c, but I didn't get any ICE. -- kazu at gcc dot gnu dot org changed: What|Removed |Added CC||kazu at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24497
[Bug target/19421] [4.0/4.1 regression] ICE with soft-float on m68k
--- Comment #15 from kazu at gcc dot gnu dot org 2005-11-06 04:28 --- Not reproducible using x86_64-pc-linux-gnu X m68k-none-elf. I'm using mainline for the cross compiler. -- kazu at gcc dot gnu dot org changed: What|Removed |Added CC||kazu at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19421
[Bug tree-optimization/24689] store_ccp is missing an opportunity because of call clobber/alias load?
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-06 04:34 ---
Looks like another one of the call clobbered bugs:
Variable: buf, UID 1612, char[1], is an alias tag, is addressable, call
clobbered, default def: buf_2
Though that should not matter.
Here is a testcase where call clobberness is correct but it should not matter
as there is no way for the change to happen:
extern void bar (unsigned int);
extern void bar1 (const char **);
int
foo (void)
{
char buf[1] = { 3 };
const char *p = buf;
const char **q = p;
unsigned int ch;
switch (**q)
{
case 1: ch = 5; break;
default: ch = 0; break;
}
bar (ch);
bar1 (q);
return ch;
}
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Keywords||alias
Last reconfirmed|-00-00 00:00:00 |2005-11-06 04:34:23
date||
Summary|store_ccp is missing an |store_ccp is missing an
|opportunity!? |opportunity because of call
||clobber/alias load?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24689
[Bug c++/24690] error using TinyVector temporary as default constructor value
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-06 04:37 --- This is a dup of bug 57. There is still an open question in the C++ standards committee if this is valid or invalid code. So right now GCC is correct. *** This bug has been marked as a duplicate of 57 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24690
[Bug c++/57] [DR 325] GCC can't parse a non-parenthesized comma in a template-id within a default argument
--- Comment #29 from pinskia at gcc dot gnu dot org 2005-11-06 04:37 --- *** Bug 24690 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||faheem at email dot unc dot ||edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57
[Bug tree-optimization/24689] store_ccp is missing an opportunity because of call clobber/alias load?
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-06 04:47 ---
Note switch statements here have nothing to do with the real issue:
extern void bar (unsigned int);
extern void bar1 (const char **);
int
foo (void)
{
char buf[1] = { 3 };
const char *p = buf;
const char **q = p;
unsigned int ch;
if(**q)
{
ch = 1;
}
else ch =2;
bar (ch);
bar1 (q);
return ch;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24689
[Bug tree-optimization/24689] store_ccp does nothing for array references
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-11-06 04:50 --- (In reply to comment #0) This function should be optimized to return 0;, but it isn't. Interestingly, if you change #if 1 to #if 0, you are going to get this optimized. Not really because SRA works then, using -fno-tree-sra will show the same issue. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Summary|store_ccp is missing an |store_ccp does nothing for |opportunity because of call |array references |clobber/alias load? | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24689
[Bug tree-optimization/24689] store_ccp does nothing for array references
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-11-06 04:52 ---
Here is another testcase:
extern void bar (unsigned int);
extern void bar1 (const char **);
char buf[1];
int
foo (void)
{
const char *p = buf;
const char **q = p;
buf[0] = 3;
unsigned int ch;
if(**q)
{
ch = 1;
}
else ch =2;
return ch;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24689
