[Bug c++/24996] [4.0/4.1/4.2 Regression] ICE on throw code
--- Comment #23 from jason at redhat dot com 2006-02-12 07:58 --- Subject: Re: [4.0/4.1/4.2 Regression] ICE on throw code I think I have a better patch that I'll check in soon. Jason -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24996
[Bug libfortran/26136] List directed input with underfilled (logicals) array read incorrectly
--- Comment #13 from jvdelisle at gcc dot gnu dot org 2006-02-12 06:36 --- Yes, I am working on a scheme that will provide deeper ungets when needed. Half way there now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26136
[Bug target/25765] gfortran.dg/assign_2.f90 -O0 fails
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-02-12 04:13 --- A patch like the rs6000 one: http://gcc.gnu.org/ml/gcc-patches/2003-07/msg02517.html Should work. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25765
[Bug middle-end/22275] [3.4/4.0/4.1/4.2 Regression] bitfield layout change
--- Comment #47 from matz at suse dot de 2006-02-12 03:59 --- What do you mean with 6 (as making more sense)? The size of the struct? Anyway, even ignoring that we talk about structs which are packed in various ways (as you rightly noticed) even the old (IMHO more sensible behaviour) fullfills the C standard you quoted. By aligning it to it automatically makes a following bitfield not come to lie in the same unit (a byte usually), though that's obviously not the most strict interpretation of this rule. So it's not that the old behabiour would violate C99. What strengenths the case to go back actually are programs relieing on that behaviour, _and_ that it's more expressive. With the new behaviour there's no difference between char :0; short :0; int :0; If the user really only want to close the current unit he can write 'char :0'. But if he wants more alignment in a otherwise packed struct he has to play games currently, whereas with the pre-3.4 sematic he could have written 'int:0' (if "int" was his desired alignment for the next field). So, I still stand by my opinion that we should want to go back. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22275
[Bug libfortran/26136] List directed input with underfilled (logicals) array read incorrectly
--- Comment #12 from hjl at lucon dot org 2006-02-12 01:31 --- It looks like that unget_char needs to modified to increase the supported number of unget. The current number is 1. We can't do unget_char (dtp, c); unget_char (dtp, c); unget_char (dtp, c); We can have an unget buffer in st_parameter_dt and change last_char to a pointer which indexes to the unget buffer. The unget buffer only needs big enough to hold the longest logical string we want to support. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26136
[Bug tree-optimization/8361] [4.1/4.2 regression] C++ compile-time performance regression
--- Comment #64 from steven at gcc dot gnu dot org 2006-02-12 01:17 --- DONT_PROPAGATE_WITH_ANYTHING only exists on the trunk. With that flag, the timings are: Flags: -O2 GCC 4.2 (trunk today): real0m31.704s user0m31.094s sys 0m0.584s Flags: -O3 GCC 4.2 (trunk today): real0m36.206s user0m35.718s sys 0m0.484s So, no it doesn't help. Again, the problem seems to be more that we just run so many passes, not that one or two specific passes are to blame for most of the compile time. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8361
make[3]: *** [java/awt/color.lo] Error 1
While building the latest 4.2 snapshot I got the following error: mkdir java/awt/.libs /sw/src/fink.build/gcc4-4.2.0-20060212/gcc-4.2-20060212/darwin/gcc/gcj -B/sw/src/fink.build/gcc4-4.2.0-20060212/gcc-4.2-20060212/darwin/powerpc-apple-darwin7/libjava/ -B/sw/src/fink.build/gcc4-4.2.0-20060212/gcc-4.2-20060212/darwin/gcc/ -fclasspath= -fbootclasspath=/sw/src/fink.build/gcc4-4.2.0-20060212/gcc-4.2-20060212/darwin/powerpc-apple-darwin7/libjava/classpath/lib --encoding=UTF-8 -Wno-deprecated -fbootstrap-classes -g -O2 -c -MT java/awt/color.lo -MD -MP -MF java/awt/color.deps @java/awt/color.list -fno-common -o java/awt/.libs/color.o ../../../libjava/classpath/java/awt/color/ICC_Profile.java: In class 'java.awt.color.ICC_Profile': ../../../libjava/classpath/java/awt/color/ICC_Profile.java: In method 'java.awt.color.ICC_Profile.makeIdentityClut()': ../../../libjava/classpath/java/awt/color/ICC_Profile.java:1075: error: unrecognizable insn: (insn 624 247 548 10 (set (reg:SI 366) (fix:SI (reg:DF 122 [ pretmp.2585 ]))) -1 (insn_list:REG_DEP_TRUE 242 (nil)) (nil)) ../../../libjava/classpath/java/awt/color/ICC_Profile.java:1075: internal compiler error: in extract_insn, at recog.c:2075 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. make[3]: *** [java/awt/color.lo] Error 1 make[2]: *** [all-recursive] Error 1 make[1]: *** [all-target-libjava] Error 2 make: *** [all] Error 2 ### execution of /var/tmp/tmp.2.piaA0t failed, exit code 2 Removing build lock... /sw/bin/dpkg-lockwait -r fink-buildlock-gcc4-4.2.0-20060212 (Reading database ... 401719 files and directories currently installed.) Removing fink-buildlock-gcc4-4.2.0-20060212 ... Failed: phase compiling: gcc4-4.2.0-20060212 failed TIA Dominique
[Bug fortran/23092] scalar mask for minval/maxval/sum/product
--- Comment #3 from tkoenig at gcc dot gnu dot org 2006-02-11 21:36 --- Created an attachment (id=10824) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10824&action=view) patch for product Here's a patch for the product/sum case. minval/maxval could be fixed along the same lines, but the code path is differnent, but I still have to figure out what to do for the mask=.false. case. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23092
[Bug fortran/26227] New: accepts invalid fortran, different dummy types/number
This is just a reminder bug to make sure that I and/or Paul T. don't lose it as it will cause an ICE once I fix the double decl issue as we will be start to inline this function and fail Testcase: function a(b) REAL ::b b = 2.0 a = 1.0 end function program gg real :: h h = a(); end program gg -- Summary: accepts invalid fortran, different dummy types/number Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: accepts-invalid Severity: normal Priority: P3 Component: fortran 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=26227
[Bug fortran/25685] Accepts invalid code for Fortran 90
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-02-11 21:20 --- Actually this is still a dup of bug 22571. *** This bug has been marked as a duplicate of 22571 *** -- 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=25685
[Bug fortran/22571] Reject derived types for dummy arguments declared in the subroutine unless they are SEQUENCE
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-02-11 21:20 --- *** Bug 25685 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22571
[Bug tree-optimization/26209] [4.1/4.2 Regression] Specific code causes g++ 4.1.0 dominance ICE when compiled with -O3
-- rakdver at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rakdver at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-02-10 12:03:49 |2006-02-11 20:43:45 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26209
[Bug rtl-optimization/23523] peephole2 causes code size on i686
--- Comment #15 from hjl at lucon dot org 2006-02-11 20:17 --- FYI, -march=i686 turns on -mtune=generic32 in 4.2, while it turns on -mtune=pentiumpro in gcc 4.0 and 4.1. I backported the patch to 4.1: http://gcc.gnu.org/ml/gcc-patches/2006-01/msg01436.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23523
[Bug target/26226] New: FAIL: gcc.c-torture/execute/ieee/20010226-1.c execution
PASS: gcc.c-torture/execute/ieee/20010114-2.c execution, -Os Executing on host: /home/gnu/gcc-3.4/objdir/gcc/xgcc -B/home/gnu/gcc-3.4/objdir/ gcc/ /xxx/gnu/gcc-3.4/gcc/gcc/testsuite/gcc.c-torture/execute/ieee/20010226-1.c -w -O0 -fno-show-column -lm -o /xxx/gnu/gcc-3.4/objdir/gcc/testsuite/20010 226-1.x0(timeout = 300) PASS: gcc.c-torture/execute/ieee/20010226-1.c compilation, -O0 Setting LD_LIBRARY_PATH to :/xxx/gnu/gcc-3.4/objdir/gcc::/xxx/gnu/gcc-3.4/objdir /gcc FAIL: gcc.c-torture/execute/ieee/20010226-1.c execution, -O0 # gdb 20010226-1.x0 GNU gdb 2004-01-09-cvs Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "hppa64-hp-hpux11.00"... (gdb) r Starting program: /home/gnu/gcc-3.4/objdir/gcc/testsuite/20010226-1.x0 Program received signal SIGSEGV, Segmentation fault. 0x40002c04 in _U_Qfcnvfxt_quad_to_udbl (a=Unhandled dwarf expression opcode ) at quadlib.c:210 210 u = _U_Qfcnvfxt_quad_to_quad(a); (gdb) disass 0x40002bf4 0x40002c14 Dump of assembler code from 0x40002bf4 to 0x40002c14: 0x40002bf4 <_U_Qfcnvfxt_quad_to_udbl+28>: std r4,-80(sp) 0x40002bf8 <_U_Qfcnvfxt_quad_to_udbl+32>: addil 0,dp,%r1 0x40002bfc <_U_Qfcnvfxt_quad_to_udbl+36>: ldd 68(r1),r1 0x40002c00 <_U_Qfcnvfxt_quad_to_udbl+40>: ldd 0(,r1),r1 0x40002c04 <_U_Qfcnvfxt_quad_to_udbl+44>: ldd 10(r1),rp 0x40002c08 <_U_Qfcnvfxt_quad_to_udbl+48>: bve,l (rp),%r2 0x40002c0c <_U_Qfcnvfxt_quad_to_udbl+52>: ldd 18(r1),dp 0x40002c10 <_U_Qfcnvfxt_quad_to_udbl+56>: ldd -e0(sp),rp End of assembler dump. (gdb) p/x $r1 $1 = 0x0 (gdb) break *0x40002c00 Breakpoint 1 at 0x40002c00: file quadlib.c, line 210. (gdb) r The program being debugged has been started already. Start it from the beginning? (y or n) y Starting program: /home/gnu/gcc-3.4/objdir/gcc/testsuite/20010226-1.x0 Breakpoint 1, 0x40002c00 in _U_Qfcnvfxt_quad_to_udbl (a=Unhandled dwarf expression opcode ) at quadlib.c:210 210 u = _U_Qfcnvfxt_quad_to_quad(a); (gdb) p/x $r1 $1 = 0x800100a0 # objdump -R 20010226-1.x0 20010226-1.x0: file format elf64-hppa DYNAMIC RELOCATION RECORDS OFFSET TYPE VALUE 80010338 R_PARISC_DIR64_SYSTEM_ID 80010378 R_PARISC_FPTR64 _start 80010380 R_PARISC_DIR64__argc 80010388 R_PARISC_DIR64__argv 80010390 R_PARISC_DIR64_CPU_REVISION 80010398 R_PARISC_DIR64_FPU_MODEL 800103a0 R_PARISC_DIR64_FPU_REVISION 800103a8 R_PARISC_DIR64_CPU_KEYBITS_1 800103b0 R_PARISC_DIR64_environ 800103b8 R_PARISC_DIR64__envp 800103c0 R_PARISC_DIR64__load_info 800103c8 R_PARISC_DIR64__sysvec 800103d0 R_PARISC_DIR64__scall_entry_table_addr 800103d8 R_PARISC_DIR64__tls_size 80010370 R_PARISC_FPTR64 __text_seg+0x1830 80010100 R_PARISC_FPTR64 __text_seg+0x1840 80010108 R_PARISC_FPTR64 __text_seg+0x1850 80010110 R_PARISC_FPTR64 __text_seg+0x1840 80010118 R_PARISC_FPTR64 __text_seg+0x1850 80010120 R_PARISC_FPTR64 __text_seg+0x1860 80010128 R_PARISC_FPTR64 __text_seg+0x1860 80010298 R_PARISC_FPTR64 __text_seg+0x18b0 800102a0 R_PARISC_FPTR64 __text_seg+0x18d0 800102a8 R_PARISC_FPTR64 _Jv_RegisterClasses 800102b0 R_PARISC_FPTR64 __text_seg+0x1870 800102b8 R_PARISC_FPTR64 __text_seg+0x1880 800102c0 R_PARISC_FPTR64 __text_seg+0x1890 800100b0 R_PARISC_FPTR64 _U_Qfcnvfxt_quad_to_sgl 800100b8 R_PARISC_FPTR64 _U_Qfcmp 800100c0 R_PARISC_FPTR64 abort 800100c8 R_PARISC_FPTR64 strlen 800100d0 R_PARISC_FPTR64 malloc 800100d8 R_PARISC_FPTR64 free 800102d0 R_PARISC_IPLT __sys_atexit 800102e0 R_PARISC_IPLT _write_sys 800102f0 R_PARISC_IPLT exit 80010300 R_PARISC_IPLT abort 80010310 R_PARISC_IPLT _U_Qfdiv 80010320 R_PARISC_IPLT _U_Qfmpy _U_Qfcnvfxt_quad_to_quad isn't in the list of dynamic relocations. We have in quadlib.o: RELOCATION RECORDS FOR [.data]: OFFSET TYPE VALUE R_PARISC_FPTR64 _U_Qfcnvfxt_quad_to_quad 0008 R_PARISC_FPTR64 _U_Qfcnvfxt_quad_to_dbl 0010 R_PARISC_FPTR64 _U_Qfcnvfxt_quad_to_sgl 0018 R_PARISC_FPTR64 _U_Qfcmp I'm fairly certa
[Bug rtl-optimization/26225] [4.2 Regression] GCC error: in emit_move_multi_word, at expr.c:3053
--- Comment #3 from dave at hiauly1 dot hia dot nrc dot ca 2006-02-11 18:42 --- Subject: Re: [4.2 Regression] GCC error: in emit_move_multi_word, at expr.c:3053 > Could you please check whether the following patch fixes the problem? Started test. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26225
[Bug rtl-optimization/26225] [4.2 Regression] GCC error: in emit_move_multi_word, at expr.c:3053
--- Comment #2 from rakdver at gcc dot gnu dot org 2006-02-11 18:23 ---
Could you please check whether the following patch fixes the problem?
I am not sure whether I would be able to build ada crosscompiler.
Index: loop-invariant.c
===
*** loop-invariant.c(revision 110850)
--- loop-invariant.c(working copy)
*** static bool
*** 583,588
--- 583,589
may_assign_reg_p (rtx x)
{
return (can_copy_p (GET_MODE (x))
+ && GET_MODE (x) != BLKmode
&& (!REG_P (x)
|| !HARD_REGISTER_P (x)
|| REGNO_REG_CLASS (REGNO (x)) != NO_REGS));
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26225
[Bug rtl-optimization/26222] [4.2 Regression] build failuring in libjava
--- Comment #7 from rakdver at gcc dot gnu dot org 2006-02-11 18:16 --- Created an attachment (id=10823) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10823&action=view) Possible fix I am testing the attached patch that seems to fix the problem (although I am not really sure whether it is the propper way or not). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26222
[Bug rtl-optimization/26222] [4.2 Regression] build failuring in libjava
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-02-11 17:56 ---
The C testcase (compile with -O2 -fno-tree-pre -fno-tree-loop-im):
void putShort (int, int);
int t2;
void f(int t1)
{
int clutOffset = 52 + 256 * 3 * 2;
for (int x = 0; x < 16; x++)
for (int y = 0; y < 16; y++)
for (int z = 0; z < 16; z++)
{
int offset = clutOffset + z * 6 + y * 16 * 6 + x * 16 * 16 * 6;
double xf = ((double) x) / ((double) 16 - 1.0);
double tt = xf;
putShort(offset, tt);
}
}
--
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 |2006-02-11 17:56:13
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26222
[Bug rtl-optimization/26222] [4.2 Regression] build failuring in libjava
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-02-11 17:45 --- The reason why this fails on powerpc-darwin and not powerpc-linux but also on powerpc64-linux is because the gfxopt option instructions are enabled by default on powerpc-darwin and on powerpc64-linux. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added GCC target triplet|powerpc-*-* |powerpc*-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26222
[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations
--- Comment #89 from pinskia at gcc dot gnu dot org 2006-02-11 17:14 --- *** Bug 26217 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||gcc at dave dot dribin dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
[Bug libstdc++/26217] The header is not setting default visibility
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-02-11 17:14 --- *** This bug has been marked as a duplicate of 19664 *** -- 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=26217
[Bug rtl-optimization/26222] [4.2 Regression] build failuring in libjava
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-02-11 17:01 --- Also happens on PPC-linux-gnu. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |blocker GCC target triplet|powerpc-darwin |powerpc-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26222
[Bug rtl-optimization/26225] [4.2 Regression] GCC error: in emit_move_multi_word, at expr.c:3053
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||rakdver at gcc dot gnu dot ||org Severity|normal |blocker Keywords||build, ice-on-valid-code Summary|GCC error: in |[4.2 Regression] GCC error: |emit_move_multi_word, at|in emit_move_multi_word, at |expr.c:3053 |expr.c:3053 Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26225
[Bug rtl-optimization/26225] GCC error: in emit_move_multi_word, at expr.c:3053
--- Comment #1 from danglin at gcc dot gnu dot org 2006-02-11 16:59 --- Breakpoint 1, emit_move_multi_word (mode=BLKmode, x=0x42461170, y=0x423a81c0) at ../../gcc/gcc/expr.c:3053 3053 gcc_assert (GET_MODE_SIZE (mode) >= UNITS_PER_WORD); (gdb) bt #0 emit_move_multi_word (mode=BLKmode, x=0x42461170, y=0x423a81c0) at ../../gcc/gcc/expr.c:3053 #1 0x004dc78c in gen_move_insn (x=0x42461170, y=0x423a81c0) at ../../gcc/gcc/optabs.c:4398 #2 0x00686240 in move_invariant_reg (loop=0x42461170, invno=) at ../../gcc/gcc/loop-invariant.c:1099 #3 0x00687128 in move_loop_invariants (loops=0xf10070) at ../../gcc/gcc/loop-invariant.c:1146 #4 0x0058a688 in execute_one_pass (pass=0x8200e4) at ../../gcc/gcc/passes.c:853 #5 0x0058a814 in execute_pass_list (pass=0x8200e4) at ../../gcc/gcc/passes.c:897 #6 0x0058a828 in execute_pass_list (pass=0x820048) at ../../gcc/gcc/passes.c:898 #7 0x0058a828 in execute_pass_list (pass=0x81ee60) at ../../gcc/gcc/passes.c:898 #8 0x0031c408 in tree_rest_of_compilation (fndecl=0x40073200) at ../../gcc/gcc/tree-optimize.c:412 #9 0x0003559c in gnat_expand_body (gnu_decl=0x1) at ../../gcc/gcc/ada/misc.c:649 #10 0x005d0bcc in cgraph_expand_function (node=0x40034280) at ../../gcc/gcc/cgraphunit.c:1101 #11 0x005d3870 in cgraph_optimize () at ../../gcc/gcc/cgraphunit.c:1166 ---Type to continue, or q to quit--- #12 0x0003601c in gnat_parse_file (set_yydebug=) at ../../gcc/gcc/ada/misc.c:245 #13 0x0055505c in toplev_main (argc=, argv=) at ../../gcc/gcc/toplev.c:999 #14 0x403365c4 in __libc_start_main () from /lib/libc.so.6 #15 0x0001bca8 in _start () at ../sysdeps/hppa/elf/start.S:84 (gdb) p debug_rtx (x) (mem/s/c:BLK (reg/f:SI 1592) [45 data.languages+0 S5 A8]) $1 = void (gdb) p debug_rtx (y) (reg:BLK 1593) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26225
[Bug rtl-optimization/26222] [4.2 Regression] build failuring in libjava
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-02-11 16:59 --- The problem is that we are splitting up the following RTL: (insn 94 93 95 12 (parallel [ (set (mem/c/i:SI (plus:SI (reg/f:SI 113 sfp) (const_int 64 [0x40])) [9 S4 A32]) (fix:SI (reg:DF 127 [ pretmp.31 ]))) (clobber (reg:DI 165)) ]) -1 (nil) (nil)) into the two components: (insn 207 93 95 12 (set (mem/c/i:SI (plus:SI (reg/f:SI 113 sfp) (const_int 64 [0x40])) [9 S4 A32]) (reg:SI 194)) -1 (nil) (nil)) and (insn 208 164 52 5 (set (reg:SI 194) (fix:SI (reg:DF 127 [ pretmp.31 ]))) -1 (nil) (nil)) The later is not valid without some clobbers. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26222
[Bug bootstrap/16787] NAN constant "(0.0/0.0)" cannot be compiled by Tru64 cc
--- Comment #10 from sayle at gcc dot gnu dot org 2006-02-11 16:50 --- Subject: Bug 16787 Author: sayle Date: Sat Feb 11 16:50:41 2006 New Revision: 110873 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110873 Log: 2006-02-11 Roger Sayle <[EMAIL PROTECTED]> R. Scott Bailey <[EMAIL PROTECTED]> Bill Northcott <[EMAIL PROTECTED]> PR bootstrap/16787 * floatformat.c: Include where available. (NAN): Use value of DBL_QNAN if defined, and NAN isn't. Modified: trunk/libiberty/ChangeLog trunk/libiberty/floatformat.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16787
[Bug rtl-optimization/26225] New: GCC error: in emit_move_multi_word, at expr.c:3053
../../xgcc -B../../ -c -O2 -g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -fno-common -gnatpg -gnata -I- -I../rts -I. -I/home/da ve/gcc-4.2/gcc/gcc/ada /home/dave/gcc-4.2/gcc/gcc/ada/make.adb -o make.o +===GNAT BUG DETECTED==+ | 4.2.0 20060210 (experimental) (hppa-unknown-linux-gnu) GCC error:| | in emit_move_multi_word, at expr.c:3053 | | Error detected at make.adb:7541:23 | | Please submit a bug report; see http://gcc.gnu.org/bugs.html.| | Use a subject line meaningful to you and us to track the bug.| | Include the entire contents of this bug box in the report. | | Include the exact gcc or gnatmake command that you entered. | | Also include sources listed below in gnatchop format | | (concatenated together with no headers between files). | +==+ Please include these source files with error report Note that list may not be accurate in some cases, so please double check that the problem can still be reproduced with the set of files listed. /home/dave/gcc-4.2/gcc/gcc/ada/make.adb /home/dave/gcc-4.2/gcc/gcc/ada/make.ads /home/dave/gcc-4.2/gcc/gcc/ada/table.ads /home/dave/gcc-4.2/gcc/gcc/ada/types.ads /home/dave/gcc-4.2/gcc/gcc/ada/ali.ads /home/dave/gcc-4.2/gcc/gcc/ada/casing.ads /home/dave/gcc-4.2/gcc/gcc/ada/gnatvsn.ads /home/dave/gcc-4.2/gcc/gcc/ada/rident.ads /home/dave/gcc-4.2/gcc/gcc/ada/ali-util.ads /home/dave/gcc-4.2/gcc/gcc/ada/csets.ads /home/dave/gcc-4.2/gcc/gcc/ada/debug.ads /home/dave/gcc-4.2/gcc/gcc/ada/fmap.ads /home/dave/gcc-4.2/gcc/gcc/ada/fname.ads /home/dave/gcc-4.2/gcc/gcc/ada/fname-sf.ads /home/dave/gcc-4.2/gcc/gcc/ada/fname-uf.ads /home/dave/gcc-4.2/gcc/gcc/ada/hostparm.ads /home/dave/gcc-4.2/gcc/gcc/ada/makeusg.ads /home/dave/gcc-4.2/gcc/gcc/ada/makeutl.ads /home/dave/gcc-4.2/gcc/gcc/ada/osint.ads /home/dave/gcc-4.2/gcc/gcc/ada/prj.ads /home/dave/gcc-4.2/gcc/gcc/ada/scans.ads /home/dave/gcc-4.2/gcc/gcc/ada/uintp.ads /home/dave/gcc-4.2/gcc/gcc/ada/alloc.ads /home/dave/gcc-4.2/gcc/gcc/ada/urealp.ads /home/dave/gcc-4.2/gcc/gcc/ada/mlib.ads /home/dave/gcc-4.2/gcc/gcc/ada/mlib-prj.ads /home/dave/gcc-4.2/gcc/gcc/ada/mlib-tgt.ads /home/dave/gcc-4.2/gcc/gcc/ada/mlib-utl.ads /home/dave/gcc-4.2/gcc/gcc/ada/namet.ads /home/dave/gcc-4.2/gcc/gcc/ada/opt.ads /home/dave/gcc-4.2/gcc/gcc/ada/osint-m.ads /home/dave/gcc-4.2/gcc/gcc/ada/output.ads /home/dave/gcc-4.2/gcc/gcc/ada/prj-com.ads /home/dave/gcc-4.2/gcc/gcc/ada/prj-env.ads /home/dave/gcc-4.2/gcc/gcc/ada/prj-pars.ads /home/dave/gcc-4.2/gcc/gcc/ada/prj-util.ads /home/dave/gcc-4.2/gcc/gcc/ada/sfn_scan.ads /home/dave/gcc-4.2/gcc/gcc/ada/sinput.ads /home/dave/gcc-4.2/gcc/gcc/ada/sinput-p.ads /home/dave/gcc-4.2/gcc/gcc/ada/snames.ads /home/dave/gcc-4.2/gcc/gcc/ada/switch.ads /home/dave/gcc-4.2/gcc/gcc/ada/switch-m.ads /home/dave/gcc-4.2/gcc/gcc/ada/targparm.ads /home/dave/gcc-4.2/gcc/gcc/ada/tempdir.ads /home/dave/gcc-4.2/gcc/gcc/ada/table.adb /home/dave/gcc-4.2/gcc/gcc/ada/tree_io.ads /home/dave/gcc-4.2/gcc/gcc/ada/prj-env.adb raised TYPES.UNRECOVERABLE_ERROR : comperr.adb:380 make[3]: *** [make.o] Error 1 make[3]: Leaving directory `/home/dave/gcc-4.2/objdir/gcc/ada/tools' make[2]: *** [gnattools-native] Error 2 make[2]: Leaving directory `/home/dave/gcc-4.2/objdir/gnattools' make[1]: *** [all-gnattools] Error 2 The same failure occurs both on linux and hpux11.11 (32-bit). -- Summary: GCC error: in emit_move_multi_word, at expr.c:3053 Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org GCC build triplet: hppa*-*-* GCC host triplet: hppa*-*-* GCC target triplet: hppa*-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26225
[Bug rtl-optimization/26222] [4.2 Regression] build failuring in libjava
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-02-11 16:43 ---
Reduced Java source:
class A
{
{
int clutOffset = 52 + 256 * 3 * 2;
for (int x = 0; x < 16; x++)
for (int y = 0; y < 16; y++)
for (int z = 0; z < 16; z++)
{
int offset = clutOffset + z * 6 + y * 16 * 6 + x * 16 * 16 * 6;
double xf = ((double) x) / ((double) 16 - 1.0);
putShort(offset, (short) (xf * 65535.0));
}
}
public final native void putShort(int a, short b);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26222
[Bug target/26223] ICE on complex with -mno-80387
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-11 16:07 --- IIRC long double on x86 and x86_64 is done with x87 and not the SSE unit so this is bug is semi invalid. -- 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=26223
[Bug tree-optimization/8361] [4.1/4.2 regression] C++ compile-time performance regression
--- Comment #63 from dberlin at gcc dot gnu dot org 2006-02-11 16:02 --- Subject: Re: [4.1/4.2 regression] C++ compile-time performance regression > Flags: -O3 > > GCC 4.0 (release branch today): > real0m24.412s 0m25.000s 0m24.771s > user0m23.921s 0m24.430s 0m24.210s > sys 0m0.368s0m0.408s0m0.420s > > GCC 4.1 (release branch today): > real0m33.260s 0m33.140s 0m33.188s > user0m32.602s 0m32.522s 0m32.554s > sys 0m0.556s0m0.544s0m0.600s > > GCC 4.2 (trunk today): > real0m36.544s 0m36.614s 0m36.492s > user0m35.950s 0m35.942s 0m35.994s > sys 0m0.544s0m0.600s0m0.464s > > > Significant compile time sinks in GCC 4.1 that don't appear in GCC 4.0: > tree PTA : 2.31 ( 7%) usr > tree SSA incremental : 2.14 ( 6%) usr > expand: 1.71 ( 5%) usr > So, could you do me a favor if you get a chance, and change the macro DONT_PROPAGATE_WITH_ANYTHING to 1 in tree-ssa-structalias.c, and see if it speeds it up at all? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8361
Re: [Bug tree-optimization/8361] [4.1/4.2 regression] C++ compile-time performance regression
> Flags: -O3 > > GCC 4.0 (release branch today): > real0m24.412s 0m25.000s 0m24.771s > user0m23.921s 0m24.430s 0m24.210s > sys 0m0.368s0m0.408s0m0.420s > > GCC 4.1 (release branch today): > real0m33.260s 0m33.140s 0m33.188s > user0m32.602s 0m32.522s 0m32.554s > sys 0m0.556s0m0.544s0m0.600s > > GCC 4.2 (trunk today): > real0m36.544s 0m36.614s 0m36.492s > user0m35.950s 0m35.942s 0m35.994s > sys 0m0.544s0m0.600s0m0.464s > > > Significant compile time sinks in GCC 4.1 that don't appear in GCC 4.0: > tree PTA : 2.31 ( 7%) usr > tree SSA incremental : 2.14 ( 6%) usr > expand: 1.71 ( 5%) usr > So, could you do me a favor if you get a chance, and change the macro DONT_PROPAGATE_WITH_ANYTHING to 1 in tree-ssa-structalias.c, and see if it speeds it up at all?
[Bug tree-optimization/8361] [4.1/4.2 regression] C++ compile-time performance regression
--- Comment #62 from steven at gcc dot gnu dot org 2006-02-11 15:46 --- Compile times for generate-3.4.ii All compilers bootstrapped, with checking disabled. Flags: -O2 GCC 4.0 (release branch today): real0m22.795s 0m22.727s 0m22.760s user0m22.481s 0m22.297s 0m22.357s sys 0m0.316s0m0.412s0m0.404s GCC 4.1 (release branch today): real0m29.888s 0m28.450s 0m28.420s user0m28.154s 0m27.906s 0m27.894s sys 0m0.496s0m0.544s0m0.524s GCC 4.2 (trunk today): real0m33.715s 0m31.524s 0m31.483s user0m31.466s 0m31.034s 0m31.022s sys 0m0.424s0m0.492s0m0.460s Flags: -O3 GCC 4.0 (release branch today): real0m24.412s 0m25.000s 0m24.771s user0m23.921s 0m24.430s 0m24.210s sys 0m0.368s0m0.408s0m0.420s GCC 4.1 (release branch today): real0m33.260s 0m33.140s 0m33.188s user0m32.602s 0m32.522s 0m32.554s sys 0m0.556s0m0.544s0m0.600s GCC 4.2 (trunk today): real0m36.544s 0m36.614s 0m36.492s user0m35.950s 0m35.942s 0m35.994s sys 0m0.544s0m0.600s0m0.464s Significant compile time sinks in GCC 4.1 that don't appear in GCC 4.0: tree PTA : 2.31 ( 7%) usr tree SSA incremental : 2.14 ( 6%) usr expand: 1.71 ( 5%) usr The same passes cost the most time in GCC 4.2. The expand cost has increades. The other two are not new, they just run very often or didn't have their own time vars before. The overall problem seems to be that we just run too many passes too often, nothing really stands out. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8361
[Bug target/12395] Suboptimal code with global variables
--- Comment #11 from michaelni at gmx dot at 2006-02-11 13:54 --- (In reply to comment #9) > Re. comment #8: > "exponential decaying performance which it has so accurately followed since > 2.95" > > Can you back this up with numbers, or are you just trolling? If the latter, > please don't do that, you are insulting the work of a dedicated few. Maybe > you > should help out instead of trolling, if you think you're so good. If you > continue to make this kind of unhelpful comments, I will ask to have you > blocked from our bugzilla. the benchmark was unhelpfull? anyway, compiling dsputil.c from libavcodec takes gcc 2.950m26.530s gcc 3.4 0m46.839s gcc 4.0 1m 1.515s (time /usr/bin/gcc-4.0 -O3 -g -DHAVE_AV_CONFIG_H -I.. -I'/home/michael/ffmpeg-write2/ffmpeg'/libavutil -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_GNU_SOURCE -c -o dsputil.o dsputil.c) and runtime performance, just try the recommanded way of writing asm/mmx code for gcc 2.95 vs gcc 3/4.*, handwritten asm code is quite a bit faster then what gcc creates from these intrinsics sometimes sure saying gcc gets exponentially slower in general isnt true but in some specific and common cases there is a big speedloss ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12395
[Bug target/26219] longjmp dosn't work
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-02-11 13:33 --- You need to provide a more sensible test or a description of what "works" and "does not work" for this testcase is supposed to be. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26219
[Bug fortran/26054] Gratuitous warning about Fortran 2003 features w/o -std=...
--- Comment #4 from toon at moene dot indiv dot nluug dot nl 2006-02-11 13:27 --- Subject: Re: Gratuitous warning about Fortran 2003 features w/o -std=... > We don't warn for other Fortran 2003 features we support without a -std=f95, > so > I'll look into it and fix it. Well, that's not true, we do. So I'll propose a fix for the whole, to [EMAIL PROTECTED] and [EMAIL PROTECTED] Cheers, Toon -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26054
[Bug target/12395] Suboptimal code with global variables
--- Comment #10 from steven at gcc dot gnu dot org 2006-02-11 13:14 --- This is, in fact, a rare case where RTL store motion does something useful. With "-O2 -fomit-frame-pointer -march=pentium4" we produce: movla, %eax addl$1, %eax movl%eax, a testl %eax, %eax je .L4 addl$1, %eax movl%eax, a .L4: ret but with "-O2 -fomit-frame-pointer -march=pentium4 -fgcse-sm" we get: foo: movla, %eax addl$1, %eax je .L5 addl$1, %eax movl%eax, a ret .L5: movl$0, a ret which is much closer to what we want to get to eventually. Looking at the first snippet, we shouldn't really need GCSE store-motion for this, because the store to a is not partially redundant. It is fully redundant and could be sunk if we had a generic hoisting pass that can lift and sink code. The current implementation of code hoisting in GCSE can only lift code, not sink it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12395
[Bug libgomp/26224] New: ICE in C$OMP SINGLE / END SINGLE COPYPRIVATE( ) block
This can perhaps be treated as a suggestion for improvement. There are also some similarities with the 25952 report (which is also for OpenMP SINGLE). On this code the GOMP branch sometimes reports ICE without any useful information, sometimes ICE with something helpful to the programmer. gfortran-gomp-new -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc/configure --prefix=/usr/local/gomp-new --program-suffix=-gomp-new --enable-threads=posix --enable-languages=c,c++,fortran Thread model: posix gcc version 4.2.0-gomp-20050608-branch 20060206 (experimental) (merged 20060206) In the code below, KLIST is not declared, which is probably the cause of the ICE. However, if KLIST is entered last in the COPYPRIVATE statement, the compiler will more correctly report an error in the code and be more helpful to the programmer (but still report an ICE). gfortran-gomp-new -fopenmp -g -O0 -fautomatic -Wunused -c abcdef.for abcdef.for:0: internal compiler error: Segmentation fault Please submit a full bug report, SUBROUTINE ABCDEF IMPLICIT DOUBLE PRECISION ( A - H, O - Z ), INTEGER ( I - N ) C COMMON /ZZOOPP/ MVBS1, JNBNP2, JNWBS C$OMP THREADPRIVATE(/ZZOOPP/) C COMMON /ACLST/ IOUTP( 100 ), KBSTYP( 15000 ), NBK C COMMON /POIUYT_P/ IBSFFD, NTSP, IIJJKK(15000), IBKR(1000) C$OMP THREADPRIVATE(/POIUYT_P/) C C$OMP SINGLE DO 15 IBK = 1, NBK IBS = IBLK( IBK ) JBS = IBKR( IBK ) IBKR( IBK ) = IBS KBSTYP( IBS ) = IIJJKK( IBS ) 15 CONTINUE C$OMP END SINGLE COPYPRIVATE( IBKR ) C C$OMP SINGLE KOUT = 0 JNWBS = 1 MVBS1 = 2 C JNBNP2 = 0 NTSP = 0 C$OMP END SINGLE COPYPRIVATE( JNWBS, MVBS1, JNBNP2, KLIST, NTSP ) C IF ( IOUTP( 3 ) .GT. IOUTP( 1 ) ) THEN CALL Z4( KOUT ) C$OMP BARRIER END IF C RETURN END Change the code to: C$OMP END SINGLE COPYPRIVATE( JNWBS, MVBS1, JNBNP2, NTSP, KLIST ) ^ | | and the compilation will report this: gfortran-gomp-new -fopenmp -g -O0 -fautomatic -Wunused -c abcdef.for In file abcdef.for:22 *$OMP SINGLE 1 abcdef.for:0: internal compiler error: Segmentation fault Please submit a full bug report -- Summary: ICE in C$OMP SINGLE / END SINGLE COPYPRIVATE( ) block Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgomp AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: magnus_os at yahoo dot se http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26224
[Bug target/12395] Suboptimal code with global variables
--- Comment #9 from steven at gcc dot gnu dot org 2006-02-11 13:02 --- Re. comment #8: "exponential decaying performance which it has so accurately followed since 2.95" Can you back this up with numbers, or are you just trolling? If the latter, please don't do that, you are insulting the work of a dedicated few. Maybe you should help out instead of trolling, if you think you're so good. If you continue to make this kind of unhelpful comments, I will ask to have you blocked from our bugzilla. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12395
[Bug target/12395] Suboptimal code with global variables
--- Comment #8 from michaelni at gmx dot at 2006-02-11 11:40 --- I really think this should be fixed, otherwise gcc wont be able to follow its exponential decaying performance which it has so accurately followed since 2.95 at least, to show clearer how much speed we could loose by fixing this i was nice and benchmarked the code (a simple for loop running 100 times with the code inside, rdtsc based timing outside with a 1000 times executed loop surounding it benchmarink was done on a 800mhz duron and a 500mhz pentium3, the first number is the number of cpu cycles for the duron, second one for p3 first let me show you the optimal code by steven boscher? "addl$1,a\n" " je .L1\n" "addl$1,a\n" ".L1:\n" 11.557 / 12.514 now what gcc 3.4/3.2 generated: "movla, %%eax\n" "incl%%eax\n" "testl %%eax, %%eax\n" "movl%%eax, a\n" "je .L1\n" "incl%%eax\n" "movl%%eax, a\n" ".L1:\n" //6.220 / 6.159 the code generated by mainline had 2 ret so it didnt fit in my benchmark loop the even better code by segher AT d12relay01 DOT megacenter.de.ibm.com "addl$1,a\n" "sbbl $-1,a\n" //11.755 / 15.111 one case which you must be carefull not to generate as its almost twice as fast as the on above while still being just 2 instructions is: "cmpl $-1,a\n" "adcl$1,a\n" //7.827 / 7.422 another 2 slightly faster variants are: "movla, %%eax\n" "cmpl $-1,%%eax\n" "adcl$1,%%eax\n" "movl %%eax,a\n" //6.567 / 8.811 "movla, %%eax\n" "addl$1,%%eax\n" "sbbl $-1,%%eax\n" "movl %%eax,a\n" //6.564 / 8.813 what a 14year old script kid would write and what gcc would generate if it where local variables: "movla, %%eax\n" "incl%%eax\n" "je .L1\n" "incl%%eax\n" ".L1:\n" "movl%%eax, a\n" //6.162 / 5.426 what i would write (as the variable isnt used in my testcase): "\n" //2.155 / 2.410 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12395
[Bug rtl-optimization/24408] [4.1 Regression] Invariant code no longer removed from loop when doing FDO.
--- Comment #8 from steven at gcc dot gnu dot org 2006-02-11 11:40 --- Fixed in GCC 4.2 now that -fmove-loop-invariants is enabled by default. Closing as WONTFIX because this is really not fixable for GCC 4.1. without major surgery or ugly and unsafe hacks. -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to fail||4.1.0 Known to work||4.2.0 Resolution||WONTFIX Summary|[4.1/4.2 Regression]|[4.1 Regression] Invariant |Invariant code no longer|code no longer removed from |removed from loop when doing|loop when doing FDO. |FDO.| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24408
[Bug rtl-optimization/23523] peephole2 causes code size on i686
--- Comment #14 from steven at gcc dot gnu dot org 2006-02-11 11:36 --- And so does GCC 4.1. -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23523
[Bug rtl-optimization/23523] peephole2 causes code size on i686
--- Comment #13 from steven at gcc dot gnu dot org 2006-02-11 11:27 --- GCC 4.2 gives me the code with eax again. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23523
[Bug target/23153] [meta-bug] code size regression from 4.0 on x86
--- Comment #12 from steven at gcc dot gnu dot org 2006-02-11 11:22 --- This is a meta-bug, which should never have a target milestone or a regression marker. A meta-bug is just a bug-bundler. The individual bugs can be regressions but a meta-bug can't. So, removing the regression marker. BTW. note that only one of the remaining bugs hung from this meta-bug is still a regression. -- steven at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.1/4.2 Regression] [meta- |[meta-bug] code size |bug] code size regression |regression from 4.0 on x86 |from 4.0 on x86 | Target Milestone|4.1.0 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23153
[Bug target/26223] New: ICE on complex with -mno-80387
#include
using namespace std;
template
complex add(complex a, complex b) { return a + b; }
template complex add(complex, complex);
$ g++ -Wall tmp.cpp -mno-80387 -O2
tmp.cpp: In function ‘std::complex<_Tp> add(std::complex<_Tp>,
std::complex<_Tp>) [with T = long double]’:
tmp.cpp:5: error: insn does not satisfy its constraints:
(insn 48 18 49 0 (set (mem/c:XF (plus:DI (reg/f:DI 7 sp)
(const_int 32 [0x20])) [0 S16 A8])
(reg:XF 8 )) 99 {*movxf_integer} (nil)
(nil))
tmp.cpp:5: internal compiler error: in reload_cse_simplify_operands,
at postreload.c:394
$ gcc -v
Reading specs from /usr/lib64/gcc/x86_64-pld-linux/4.1.0/specs
Target: x86_64-pld-linux
Configured with: ../configure --prefix=/usr --libdir=/usr/lib64
--libexecdir=/usr/lib64 --infodir=/usr/share/info --mandir=/usr/share/man
--x-libraries=/usr/X11R6/lib64 --enable-shared --enable-threads=posix
--enable-__cxa_atexit --enable-languages=c,c++,fortran,objc,obj-c++,ada,java
--enable-c99 --enable-long-long --disable-multilib --enable-nls
--disable-werror --with-gnu-as --with-gnu-ld --with-demangler-in-ld
--with-system-zlib --with-slibdir=/lib64 --enable-cmath --enable-libgcj
--enable-libgcj-multifile --enable-libgcj-database --enable-gtk-cairo
--enable-java-awt=gtk,xlib --enable-jni --enable-xmlj --enable-alsa
--enable-dssi x86_64-pld-linux
Thread model: posix
gcc version 4.1.0 20060210 (prerelease)
revision 110831
--
Summary: ICE on complex with -mno-80387
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pluto at agmk dot net
GCC build triplet: x86-64
GCC host triplet: x86-64
GCC target triplet: x86-64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26223
[Bug rtl-optimization/26222] [4.2 Regression] build failuring in libjava
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-11 11:06 --- This was caused by: 2006-02-10 Zdenek Dvorak <[EMAIL PROTECTED]> * doc/invoke.texi (-floop-optimize2): Removed. * toplev.c (process_options): Remove handling of flag_loop_optimize2. * loop-init.c (gate_handle_loop2): Do not test flag_loop_optimize2. Test flag_branch_on_count_reg only if HAVE_doloop_end. * common.opt (floop-optimize2): Removed. (fmove-loop-invariants): Enabled by default. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||rakdver at gcc dot gnu dot ||org Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26222
[Bug rtl-optimization/26222] New: [4.2 Regression] build failuring in libjava
No testcase so far but here is the ICE: /Users/regress/tbox/native/build/gcc/gcj -B/Users/regress/tbox/native/build/powerpc-apple-darwin8.3.0/ppc64/libjava/ -B/Users/regress/tbox/native/build/gcc/ -fclasspath= -fbootclasspath=/Users/regress/tbox/native/build/powerpc-apple-darwin8.3.0/ppc64/libjava/classpath/lib --encoding=UTF-8 -Wno-deprecated -fbootstrap-classes -g -O2 -m64 -c -MT java/awt/color.lo -MD -MP -MF java/awt/color.deps @java/awt/color.list -fno-common -o java/awt/.libs/color.o /Users/regress/tbox/svn-gcc/libjava/classpath/java/awt/color/ICC_Profile.java: In class 'java.awt.color.ICC_Profile': /Users/regress/tbox/svn-gcc/libjava/classpath/java/awt/color/ICC_Profile.java: In method 'java.awt.color.ICC_Profile.makeIdentityClut()': /Users/regress/tbox/svn-gcc/libjava/classpath/java/awt/color/ICC_Profile.java:1075: error: unrecognizable insn: (insn 608 564 610 10 (set (reg:SI 371) (fix:SI (reg:DF 132 [ pretmp.2587 ]))) -1 (insn_list:REG_DEP_TRUE 243 (nil)) (nil)) /Users/regress/tbox/svn-gcc/libjava/classpath/java/awt/color/ICC_Profile.java:1075: internal compiler error: in get_attr_type, at config/rs6000/rs6000.md:12269 -- Summary: [4.2 Regression] build failuring in libjava Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: ice-on-valid-code, build Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pinskia at gcc dot gnu dot org GCC target triplet: powerpc-darwin http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26222
[Bug c/26219] New: longjmp dosn't work
gcc version 4.1. 20060120
Configured with: ../configure --target=h8300-elf --prefix=/usr/local
--enable-languages=c,c++ --with-newlib
--with-headers=/usr/src/newlib-1.14.0/newlib/libc/include
/
#include
jmp_buf jb_error;
void jump(void){
longjmp(jb_error,1);
}
void func1(void){
return;
}
int main(void){
setjmp(jb_error);
func1();
jump();
}
/
This program compiled by h8300-elf-gcc(4.1) doesn't work.
The program compiled by h8300-elf-gcc(3.4.3) with same library works.
--
Summary: longjmp dosn't work
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mugita at jsdkk dot com
GCC host triplet: Cygwin1.5.19(0.150/4/2)
GCC target triplet: h8300-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26219
[Bug libstdc++/26217] The header is not setting default visibility
--- Comment #3 from pcarlini at suse dot de 2006-02-11 09:27 --- This is a known issue: http://gcc.gnu.org/ml/libstdc++/2005-12/msg00181.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26217
[Bug target/25864] Enable IBM long double format in 32-bit PowerPC Linux
--- Comment #14 from jakub at gcc dot gnu dot org 2006-02-11 08:49 --- Created an attachment (id=10822) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10822&action=view) gcc41-ldbl-default.patch And this patch to enable long double by default when configured with --with-long-double-128 or against glibc 2.4+. Parts of this patch are already on the trunk, parts are just approved, but waiting for approval of the configure bits. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25864
[Bug target/25864] Enable IBM long double format in 32-bit PowerPC Linux
--- Comment #13 from jakub at gcc dot gnu dot org 2006-02-11 08:47 --- Created an attachment (id=10821) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10821&action=view) gcc41-ldbl-default-libstdc++.patch Just for completeness, I'm attaching backport of the libstdc++-v3 changes that are on the trunk. This will be eventually on redhat/gcc-4_1-branch and if there is sufficient interest, we could try a separate branch of gcc-4_1-branch that would contain just the long double changes. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25864
[Bug target/25864] Enable IBM long double format in 32-bit PowerPC Linux
--- Comment #12 from jakub at gcc dot gnu dot org 2006-02-11 08:44 --- I think the agreement is that the currently committed patches to gcc-4_1-branch is all we want on that branch. GCC 4.1 will be able to build GLIBC 2.4 on all architectures, for code not using libstdc++-v3 at all will support the optional -mlong-double-128 compilation, but will never default to -mlong-double-128. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.1.0 |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25864
[Bug target/25864] Enable IBM long double format in 32-bit PowerPC Linux
--- Comment #11 from jakub at gcc dot gnu dot org 2006-02-11 08:38 --- Subject: Bug 25864 Author: jakub Date: Sat Feb 11 08:38:51 2006 New Revision: 110872 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110872 Log: PR target/25864 Backport from mainline 2006-02-06 Aldy Hernandez <[EMAIL PROTECTED]> * config/s390/s390.c (TARGET_MANGLE_FUNDAMENTAL_TYPE): Define. (s390_mangle_fundamental_type): New. * config/s390/linux.h (TARGET_ALTERNATE_LONG_DOUBLE_MANGLING): Define. * config/alpha/alpha.c (TARGET_MANGLE_FUNDAMENTAL_TYPE): Define. (alpha_mangle_fundamental_type): New. * config/alpha/linux.h (TARGET_ALTERNATE_LONG_DOUBLE_MANGLING): Define. * config/sparc/linux.h (TARGET_ALTERNATE_LONG_DOUBLE_MANGLING): Define. * config/sparc/linux64.h (TARGET_ALTERNATE_LONG_DOUBLE_MANGLING): Define. * config/sparc/sparc.c (TARGET_MANGLE_FUNDAMENTAL_TYPE): Define. (sparc_mangle_fundamental_type): New. Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/config/alpha/alpha.c branches/gcc-4_1-branch/gcc/config/alpha/linux.h branches/gcc-4_1-branch/gcc/config/s390/linux.h branches/gcc-4_1-branch/gcc/config/s390/s390.c branches/gcc-4_1-branch/gcc/config/sparc/linux.h branches/gcc-4_1-branch/gcc/config/sparc/linux64.h branches/gcc-4_1-branch/gcc/config/sparc/sparc.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25864
