[Bug middle-end/18424] [3.4/4.0 Regression] ~6x+ performance regression, constant trees not being computed.
--- Additional Comments From schlie at comcast dot net 2004-12-21 08:02
---
Problems, with 4.0 avr test results (some good, some bad, some odd);
00c6 main:
int main (void){
c6: c8 ef ldi r28, 0xF8 ; 248
c8: d0 e1 ldi r29, 0x10 ; 16
ca: de bf out 0x3e, r29 ; 62
cc: cd bf out 0x3d, r28 ; 61
volatile char c;
volatile int i;
volatile long l;
/* char tests */
c = (c (1 4));
ce: 89 81 ldd r24, Y+1; 0x01
d0: 80 71 andir24, 0x10 ; 16
; good.
d2: 89 83 std Y+1, r24; 0x01
if (c (1 4))
d4: 89 81 ldd r24, Y+1; 0x01
d6: 84 ff sbrsr24, 4
; good single bit test branch
d8: 03 c0 rjmp.+6 ; 0xe0 main+0x1a
c = 1;
da: 81 e0 ldi r24, 0x01 ; 1
dc: 89 83 std Y+1, r24; 0x01
de: 01 c0 rjmp.+2 ; 0xe2 main+0x1c
else
c = 0;
e0: 19 82 std Y+1, r1 ; 0x01
c = (c (1 4)) ? 1 : 0;
e2: 89 81 ldd r24, Y+1; 0x01
e4: 99 27 eor r25, r25
e6: 44 e0 ldi r20, 0x04 ; 4 ;
bad, using shift loop. although same as above.
e8: 96 95 lsr r25
ea: 87 95 ror r24
ec: 4a 95 dec r20
ee: e1 f7 brne.-8 ; 0xe8 main+0x22
f0: 81 70 andir24, 0x01 ; 1
f2: 89 83 std Y+1, r24; 0x01
c = sizeof(char);
f4: 81 e0 ldi r24, 0x01 ; 1
f6: 89 83 std Y+1, r24; 0x01
/* int tests */
i = i (1 10);
f8: 8a 81 ldd r24, Y+2; 0x02
fa: 9b 81 ldd r25, Y+3; 0x03
fc: 80 70 andir24, 0x00 ; 0 ; ok, but
nicer if recognized only highest byte significant.
fe: 94 70 andir25, 0x04 ; 4
100: 8a 83 std Y+2, r24; 0x02
102: 9b 83 std Y+3, r25; 0x03
if (i (1 10))
104: 8a 81 ldd r24, Y+2; 0x02
106: 9b 81 ldd r25, Y+3; 0x03
108: 9c 01 movwr18, r24 ; shouldn't
be moving the operand? rest as above.
10a: 20 70 andir18, 0x00 ; 0
10c: 34 70 andir19, 0x04 ; 4
10e: 92 ff sbrsr25, 2
110: 05 c0 rjmp.+10; 0x11c main+0x56
i = 1;
112: 81 e0 ldi r24, 0x01 ; 1
114: 90 e0 ldi r25, 0x00 ; 0; r1
= 0 already?,
116: 8a 83 std Y+2, r24; 0x02
118: 9b 83 std Y+3, r25; 0x03
11a: 02 c0 rjmp.+4 ; 0x120 main+0x5a
else
i = 0;
11c: 2a 83 std Y+2, r18; 0x02
11e: 3b 83 std Y+3, r19; 0x03; wrong,
r19 = andi r19, 0x04 ?
i = (i (1 10)) ? 1 : 0;
120: 8a 81 ldd r24, Y+2; 0x02
122: 9b 81 ldd r25, Y+3; 0x03
124: 89 2f mov r24, r25 ; nice, shifts by
8 first.
126: 99 27 eor r25, r25
128: 86 95 lsr r24
12a: 86 95 lsr r24
12c: 81 70 andir24, 0x01 ; 1
12e: 90 70 andir25, 0x00 ; 0 ; but then
fogets it already set r25 to 0?
130: 8a 83 std Y+2, r24; 0x02
132: 9b 83 std Y+3, r25; 0x03
i = sizeof(int);
134: 82 e0 ldi r24, 0x02 ; 2
136: 90 e0 ldi r25, 0x00 ; 0
138: 8a 83 std Y+2, r24; 0x02
13a: 9b 83 std Y+3, r25; 0x03
/* long tests */
l = (l ((long)1 26));
13c: 8c 81 ldd r24, Y+4; 0x04
13e: 9d 81 ldd r25, Y+5; 0x05
140: ae 81 ldd r26, Y+6; 0x06
142: bf 81 ldd r27, Y+7; 0x07
144: 80 70 andir24, 0x00 ; 0; ok.
146: 90 70 andir25, 0x00 ; 0
148: a0 70 andir26, 0x00 ; 0
14a: b4 70 andir27, 0x04 ; 4
14c: 8c 83 std Y+4, r24; 0x04
14e: 9d 83 std Y+5, r25; 0x05
150: ae 83 std Y+6, r26; 0x06
152: bf 83 std Y+7, r27; 0x07
if (l ((long)1 26))
154: 8c 81 ldd r24, Y+4; 0x04
156: 9d 81 ldd r25, Y+5; 0x05
158: ae 81 ldd r26, Y+6;
[Bug tree-optimization/19098] tree-ssa-dom.c has an if statement whose condition is probably wrong
--- Additional Comments From kazu at cs dot umass dot edu 2004-12-21 08:07 --- Can we do something like the following? Avoid creating multiple entries to into a loop before the loop optimizations run. Try to thread every edge after the loop optimizations run. The loop optimizers probably don't like irreducible loops, but I guess the real CPU doesn't care about them, and if we can skip some conditional jumps, that might be good. I don't know if this idea is any good, but just a thought. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19098
[Bug tree-optimization/19096] Wrong code with -ftree-vectorize
--- Additional Comments From belyshev at lubercy dot com 2004-12-21 08:30 --- My bad, I used wrong tree... The problem is in these patches: http://gcc.gnu.org/ml/gcc-patches/2004-12/msg01381.html and not in mainline. -- What|Removed |Added CC||rakdver at gcc dot gnu dot ||org Version|4.0.0 |unknown http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19096
[Bug tree-optimization/19096] Wrong code with -ftree-vectorize
--- Additional Comments From rakdver at gcc dot gnu dot org 2004-12-21 08:36 --- Which one of them? And what is the problem? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19096
[Bug rtl-optimization/19097] Lots of else ifs take forever to compile
--- Additional Comments From steven at gcc dot gnu dot org 2004-12-21
08:38 ---
This is what I get (with checking enabled) for an C5 with two C4s with
GNU C version 4.0.0 20041220 (experimental) (x86_64-unknown-linux-gnu):
$ ./cc1 t.c -O2
a
{GC 14385k - 11467k}
Analyzing compilation unit
Performing intraprocedural optimizations
Assembling functions:
a
{GC 68010k - 54166k} {GC 74855k - 56923k} {GC 91181k - 71784k} {GC 99265k
- 71726k}
Execution times (seconds)
garbage collection: 0.77 ( 0%) usr 0.01 ( 0%) sys 0.77 ( 0%) wall
callgraph construction: 3.03 ( 2%) usr 0.06 ( 2%) sys 3.09 ( 2%) wall
cfg construction : 0.08 ( 0%) usr 0.00 ( 0%) sys 0.08 ( 0%) wall
cfg cleanup : 1.55 ( 1%) usr 0.00 ( 0%) sys 1.52 ( 1%) wall
CFG verifier : 3.63 ( 2%) usr 0.04 ( 2%) sys 3.65 ( 2%) wall
trivially dead code : 0.23 ( 0%) usr 0.00 ( 0%) sys 0.23 ( 0%) wall
life analysis : 0.84 ( 0%) usr 0.00 ( 0%) sys 0.84 ( 0%) wall
life info update : 0.29 ( 0%) usr 0.00 ( 0%) sys 0.29 ( 0%) wall
alias analysis: 0.22 ( 0%) usr 0.00 ( 0%) sys 0.24 ( 0%) wall
register scan : 0.15 ( 0%) usr 0.00 ( 0%) sys 0.17 ( 0%) wall
rebuild jump labels : 0.04 ( 0%) usr 0.00 ( 0%) sys 0.06 ( 0%) wall
preprocessing : 0.17 ( 0%) usr 0.07 ( 3%) sys 0.34 ( 0%) wall
lexical analysis : 0.09 ( 0%) usr 0.19 ( 8%) sys 0.26 ( 0%) wall
parser: 0.35 ( 0%) usr 0.10 ( 4%) sys 0.44 ( 0%) wall
tree gimplify : 0.10 ( 0%) usr 0.01 ( 0%) sys 0.11 ( 0%) wall
tree eh : 0.05 ( 0%) usr 0.01 ( 0%) sys 0.05 ( 0%) wall
tree CFG construction : 0.17 ( 0%) usr 0.03 ( 1%) sys 0.20 ( 0%) wall
tree CFG cleanup : 0.85 ( 0%) usr 0.00 ( 0%) sys 0.89 ( 1%) wall
tree find referenced vars: 0.02 ( 0%) usr 0.00 ( 0%) sys 0.03 ( 0%)
wall
tree PTA : 0.19 ( 0%) usr 0.01 ( 0%) sys 0.19 ( 0%) wall
tree alias analysis : 0.05 ( 0%) usr 0.00 ( 0%) sys 0.04 ( 0%) wall
tree PHI insertion: 0.08 ( 0%) usr 0.01 ( 0%) sys 0.08 ( 0%) wall
tree SSA rewrite : 0.35 ( 0%) usr 0.00 ( 0%) sys 0.37 ( 0%) wall
tree SSA other: 0.58 ( 0%) usr 0.17 ( 7%) sys 0.65 ( 0%) wall
tree operand scan : 0.19 ( 0%) usr 0.10 ( 4%) sys 0.38 ( 0%) wall
dominator optimization: 2.12 ( 1%) usr 0.03 ( 1%) sys 2.16 ( 1%) wall
tree CCP : 0.17 ( 0%) usr 0.00 ( 0%) sys 0.17 ( 0%) wall
tree split crit edges : 0.00 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall
tree PRE : 0.20 ( 0%) usr 0.01 ( 0%) sys 0.21 ( 0%) wall
tree remove redundant PHIs: 0.23 ( 0%) usr 0.00 ( 0%) sys 0.24 ( 0%)
wall
tree linearize phis : 0.01 ( 0%) usr 0.00 ( 0%) sys 0.02 ( 0%) wall
tree forward propagate: 0.03 ( 0%) usr 0.00 ( 0%) sys 0.03 ( 0%) wall
tree conservative DCE : 0.19 ( 0%) usr 0.00 ( 0%) sys 0.21 ( 0%) wall
tree aggressive DCE : 0.15 ( 0%) usr 0.00 ( 0%) sys 0.15 ( 0%) wall
tree DSE : 0.32 ( 0%) usr 0.00 ( 0%) sys 0.32 ( 0%) wall
tree loop init: 0.10 ( 0%) usr 0.00 ( 0%) sys 0.08 ( 0%) wall
tree copy headers : 0.09 ( 0%) usr 0.00 ( 0%) sys 0.11 ( 0%) wall
tree SSA to normal: 0.20 ( 0%) usr 0.00 ( 0%) sys 0.20 ( 0%) wall
tree rename SSA copies: 0.02 ( 0%) usr 0.00 ( 0%) sys 0.03 ( 0%) wall
tree SSA verifier : 1.99 ( 1%) usr 0.00 ( 0%) sys 1.95 ( 1%) wall
tree STMT verifier: 0.43 ( 0%) usr 0.02 ( 1%) sys 0.44 ( 0%) wall
callgraph verifier: 8.76 ( 5%) usr 0.05 ( 2%) sys 8.81 ( 5%) wall
dominance frontiers : 0.10 ( 0%) usr 0.00 ( 0%) sys 0.12 ( 0%) wall
control dependences : 0.06 ( 0%) usr 0.00 ( 0%) sys 0.06 ( 0%) wall
expand: 1.09 ( 1%) usr 0.03 ( 1%) sys 1.20 ( 1%) wall
jump : 0.20 ( 0%) usr 0.00 ( 0%) sys 0.22 ( 0%) wall
CSE : 9.12 ( 5%) usr 0.00 ( 0%) sys 9.12 ( 5%) wall
loop analysis : 0.30 ( 0%) usr 0.00 ( 0%) sys 0.28 ( 0%) wall
global CSE: 0.03 ( 0%) usr 0.00 ( 0%) sys 0.02 ( 0%) wall
CPROP 1 : 55.78 (33%) usr 0.57 (23%) sys 56.38 (32%) wall
PRE : 0.07 ( 0%) usr 0.00 ( 0%) sys 0.07 ( 0%) wall
CPROP 2 : 28.46 (17%) usr 0.41 (17%) sys 28.91 (17%) wall
bypass jumps : 28.96 (17%) usr 0.40 (16%) sys 29.39 (17%) wall
CSE 2 : 8.25 ( 5%) usr 0.00 ( 0%) sys 8.25 ( 5%) wall
branch prediction : 0.95 ( 1%) usr 0.01 ( 0%) sys 0.95 ( 1%) wall
flow analysis : 0.05 ( 0%) usr 0.00 ( 0%) sys 0.10 ( 0%) wall
combiner : 0.36 ( 0%) usr 0.01 ( 0%) sys 0.38 ( 0%) wall
if-conversion : 0.45 ( 0%) usr 0.00 (
[Bug rtl-optimization/19097] Lots of else ifs take forever to compile
--- Additional Comments From steven at gcc dot gnu dot org 2004-12-21 08:47 --- Hmm no, it's not compute_transp: CPU: P4 / Xeon with 2 hyper-threads, speed 3194.18 MHz (estimated) Counted GLOBAL_POWER_EVENTS events (time during which processor is not stopped) with a unit mask of 0x01 (mandatory) count 10 samples %symbol name 343490 22.3269 exp_equiv_p 298238 19.3856 next_set 63817 4.1481 find_avail_set 62787 4.0812 insert_set_in_table 55981 3.6388 cgraph_edge 35531 2.3095 cse_insn 18770 1.2201 cgraph_create_edge 17784 1.1560 for_each_rtx 15956 1.0371 fold_rtx 15164 0.9857 expr_equiv_p 15081 0.9803 hash_rtx 12551 0.8158 validate_value_data 12380 0.8047 get_cse_reg_info -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19097
[Bug middle-end/19100] New: Wrong code for ?-operator with casted ?-operator predicat
The function test returns 17 not 18 as required.
#include stdio.h
signed char test(long v[]){
return ( ( ((signed char) (v[1] ? 0x100 : 0 ))) ? 17 : 18);
}
int main(void){
static long v[3];
v[1]=2;
printf(test : %d\n,test(v));
return 0;
}
--
Summary: Wrong code for ?-operator with casted ?-operator
predicat
Product: gcc
Version: 3.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: heinrich dot brand at fujitsu-siemens dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19100
[Bug tree-optimization/19067] ICE in tree-if-conv
--- Additional Comments From belyshev at lubercy dot com 2004-12-21 09:28 --- *** Bug 19096 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||belyshev at lubercy dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19067
[Bug fortran/19101] New: missing in character continuation not caught
The following code is erroneous because there's a missing in the continuation line: $ cat char-cont-wrong.f90 program main character (len=40) c c = Hello, world! print *,c end program main $ gfortran char-cont-wrong.f90 $ ./a.out Hello,world! I think a diagnostic is needed for this case. -- Summary: missing in character continuation not caught Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: Thomas dot Koenig at online dot de CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19101
[Bug middle-end/19100] Wrong code for ?-operator with casted ?-operator predicat
--- Additional Comments From falk at debian dot org 2004-12-21 09:53 --- Confirmed on alphaev68-linux. Not a regression. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||wrong-code Known to fail||2.95.4 3.3.5 3.4.4 4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19100
[Bug fortran/18918] Eventually support the co-array f95 extension in gfortran
--- Additional Comments From mg_gentoo at yahoo dot com 2004-12-21 09:56 --- I agree, but figured it was worth filing away for the future. Here's another doc from cray, the link to which I couldn't find earlier: http://www.cray.com/cgi-bin/swpubs/craydoc30/craydoc.cgi?frames=1html=toc_viewpub=S-3694-53 (Chapter 9 of the third volume of their Fortran Language Reference Manual describes Cray co-arrays.) NB: It's not Numrich and Reid, but I figure I'll note it here for future reference just in case (in case, for example, there were an implementation divergence in the future) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18918
[Bug c/19102] New: -march=pentium3 breaks linux kernel compiles w/ gcc-3_4-branch as of 2004/12/20
gcc -Wp,-MD,init/.main.o.d -nostdinc -iwithprefix include -D__KERNEL__
-Iinclude -Wall -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing
-fno-common -ffreestanding -std=gnu89 -O2 -fomit-frame-pointer -pipe
-msoft-float -mpreferred-stack-boundary=2 -march=pentium3
-Iinclude/asm-i386/mach-default -Wdeclaration-after-statement
-DKBUILD_BASENAME=main -DKBUILD_MODNAME=main -c -o init/.tmp_main.o
init/main.c
init/main.c: In function `unknown_bootoption':
include/asm/string.h:190: error: `asm' operand requires impossible reload
include/asm/string.h:190: error: `asm' operand requires impossible reload
include/asm/string.h:129: error: `asm' operand requires impossible reload
init/main.c:197: error: insn does not satisfy its constraints:
(insn 611 481 200 5 (set (reg:SI 1 dx)
(reg/v/f:SI 22 xmm1 [orig:89 s ] [89])) 36 {*movsi_1} (nil)
(nil))
init/main.c:197: confused by earlier errors, bailing out
make[1]: *** [init/main.o] Error 1
make: *** [init] Error 2
Works with any of -march=i386, -march=i586, -march=i686, -march=pentium4,
-march=athlon
--
Summary: -march=pentium3 breaks linux kernel compiles w/ gcc-3_4-
branch as of 2004/12/20
Product: gcc
Version: 3.4.4
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bero at arklinux dot org
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i686-ark-linux
GCC host triplet: i686-ark-linux
GCC target triplet: i686-ark-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19102
[Bug c/19102] -march=pentium3 breaks linux kernel compiles w/ gcc-3_4-branch as of 2004/12/20
--- Additional Comments From bero at arklinux dot org 2004-12-21 10:18 --- Created an attachment (id=7789) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7789action=view) Preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19102
[Bug c/19102] -march=pentium3 breaks linux kernel compiles w/ gcc-3_4-branch as of 2004/12/20
-- What|Removed |Added Known to fail||3.4.4 Known to work||3.4.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19102
[Bug target/18788] -pthreads option with -shared does not cause libpthread.so to be linked in.
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2004-12-21
11:04 ---
Confirmed, the SPEC string in config/sol2.h is very explicit:
#define LIB_SPEC \
%{compat-bsd:-lucb -lsocket -lnsl -lelf -laio} \
%{!shared:\
%{!symbolic:\
%{pthreads:-lpthread} \
%{!pthreads:%{threads:-lthread}} \
%{p|pg:-ldl} -lc}}
I wonder why it was written that way...
--
What|Removed |Added
CC||ebotcazou at gcc dot gnu dot
||org
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Last reconfirmed|-00-00 00:00:00 |2004-12-21 11:04:10
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18788
[Bug target/18473] unrecognizable insn compiling various sources
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2004-12-21 11:12 --- Are you sure this target is supported by the FSF compiler at all? *** Configuration hppa--netbsd not supported Configure in /home/eric/build/gcc-3_3-branch/hppa--netbsd/gcc failed, exiting. -- What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18473
[Bug c/18740] Execution-time sizeof drops side effects
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2004-12-21 11:15 --- Reproducible on x86 and x86-64. -- What|Removed |Added GCC build triplet|sparc-sun-solaris2.8|*-*-* GCC host triplet|sparc-sun-solaris2.8|*-*-* GCC target triplet|sparc-sun-solaris2.8|*-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18740
[Bug c++/19018] [3.3 Regression] virtual memory exhausted
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2004-12-21 11:17 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2004-12-21 11:17:48 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19018
[Bug bootstrap/19103] New: Current CVS (2004/12/21) doesn't compile
Trying to bootstrap current CVS results in: ./xgcc -B./ -B/usr/i586-ark-linux/bin/ -isystem /usr/i586-ark-linux/include -isystem /usr/i586-ark-linux/sys-include -L/usr/src/ark/BUILD/gcc4/build/gcc/../ld -O2 -DIN_GCC-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -I. -I. -I../../gcc -I../../gcc/. -I../../gcc/../include -I../../gcc/../libcpp/include -g0 -finhibit-size-directive -fno-inline-functions -fno-exceptions -fno-zero-initialized-in-bss -fno-unit-at-a-time -fno-omit-frame-pointer \ -c ../../gcc/crtstuff.c -DCRT_BEGIN \ -o crtbegin.o ../../gcc/crtstuff.c: In function '__do_global_dtors_aux': ../../gcc/crtstuff.c:290: internal compiler error: virtual array prologue[3]: element 1 out of bounds in contains, at function.c:4629 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. -- Summary: Current CVS (2004/12/21) doesn't compile Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bero at arklinux dot org CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: i586-ark-linux GCC host triplet: i586-ark-linux GCC target triplet: i586-ark-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19103
[Bug bootstrap/19103] Current CVS (2004/12/21) doesn't compile
--- Additional Comments From bero at arklinux dot org 2004-12-21 11:23 --- Created an attachment (id=7790) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7790action=view) preprocessed source I compiled gcc 4.0.0-20041221 with gcc 3.4.4-20041220, in case this is an error in the bootstrap compiler. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19103
[Bug tree-optimization/19104] New: in range test not noticed
The attached test case contains two equivalent functions. The second one produces better code, because it has been manually CSE'd. The problem is that fold-const is doing the conversion of 'a ==V1 || a == V2' (V2 == V1 + 1) into '(a - V1) = (V2 - V1)', but that can't be done until we spot that both RHS of the are identical. Death to fold-const! -- Summary: in range test not noticed Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: nathan at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19104
[Bug tree-optimization/19104] in range test not noticed
--- Additional Comments From nathan at gcc dot gnu dot org 2004-12-21 11:43 --- Created an attachment (id=7791) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7791action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19104
[Bug tree-optimization/19104] in range test not noticed
--- Additional Comments From nathan at gcc dot gnu dot org 2004-12-21 11:43 --- Created an attachment (id=7792) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7792action=view) assembly at -O2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19104
[Bug tree-optimization/19105] New: fold does not spot anti-range test
The attached test case shows two equivalent functions, unfortunately the first is not optimized as best as the second. Notice the only different is the placement of some superfluous parentheses. Death to fold-const! -- Summary: fold does not spot anti-range test Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: nathan at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19105
[Bug tree-optimization/19105] fold does not spot anti-range test
--- Additional Comments From nathan at gcc dot gnu dot org 2004-12-21 12:22 --- Created an attachment (id=7793) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7793action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19105
[Bug target/19102] [3.4 Regression] -march=pentium3 breaks linux kernel compiles w/ gcc-3_4-branch as of 2004/12/20
--- Additional Comments From belyshev at lubercy dot com 2004-12-21 12:22
---
/* reduced testcase, use -O1 -march=pentium3 */
int unknown_bootoption (void)
{
int i, j, k, l;
for (i = 0; i 2; i++)
asm volatile(
:=a (j), =S (k), =c (l)
:1 (0), 2 (0));
return 0;
}
--
What|Removed |Added
CC||rth at gcc dot gnu dot org
Severity|normal |critical
Status|UNCONFIRMED |NEW
Component|c |target
Ever Confirmed||1
GCC build triplet|i686-ark-linux |
GCC host triplet|i686-ark-linux |
GCC target triplet|i686-ark-linux |i686-*-*
Keywords||ice-on-valid-code
Last reconfirmed|-00-00 00:00:00 |2004-12-21 12:22:41
date||
Summary|-march=pentium3 breaks linux|[3.4 Regression] -
|kernel compiles w/ gcc-3_4- |march=pentium3 breaks linux
|branch as of 2004/12/20 |kernel compiles w/ gcc-3_4-
||branch as of 2004/12/20
Target Milestone|--- |3.4.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19102
[Bug tree-optimization/19105] fold does not spot anti-range test
--- Additional Comments From nathan at gcc dot gnu dot org 2004-12-21 12:23 --- Created an attachment (id=7794) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7794action=view) assembly produced at -O2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19105
[Bug c++/9126] g++ incorrectly prefers non-template user-defined conversion operator
--- Additional Comments From nathan at gcc dot gnu dot org 2004-12-21 12:28 --- EDG have confirmed a bug in their implementation. G++ is correct. -- What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9126
[Bug target/10395] [x86] vector types are incorrectly aligned causing crash in multi-threaded apps or when using in main, plus other times
--- Additional Comments From uros at kss-loka dot si 2004-12-21 12:50 --- Fixed pthread library should be installed to solve this bug: http://gcc.gnu.org/ml/gcc/2004-12/msg00918.html -- What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10395
[Bug target/18473] unrecognizable insn compiling various sources
--- Additional Comments From martin at duskware dot de 2004-12-21 13:04 --- Subject: Re: unrecognizable insn compiling various sources Are you sure this target is supported by the FSF compiler at all? Ooops, sorry, no it isn't. The changes are not yet fed back. Sorry I overlooked that. Martin -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18473
[Bug c++/17365] Should Koenig lookup find non-functions?
--- Additional Comments From redi at gcc dot gnu dot org 2004-12-21 13:14 --- Bug 17045 looks like the same issue. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17365
[Bug c++/17045] conflict between function template and class with same name
--- Additional Comments From redi at gcc dot gnu dot org 2004-12-21 13:15 --- Dup of bug 17365 ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17045
[Bug libfortran/19106] New: segfault in executable for print *,sum(a,dim=2,mask=a0)
$ cat sum.f90 program main real, dimension(2,2) :: a a = reshape((/1.0, -1.0, -2.0, 2.0/),shape(a)) print *,sum(a,dim=2,mask=a0) end $ gfortran sum.f90 $ ./a.out Segmentation fault $ gfortran -v Using built-in specs. Configured with: ../gcc/configure --prefix=/home/ig25 --enable-languages=c,c++,f95 : (reconfigured) ../gcc/configure --prefix=/home/ig25 --enable-languages=c,c++,f95 Thread model: posix gcc version 4.0.0 20041221 (experimental) -- Summary: segfault in executable for print *,sum(a,dim=2,mask=a0) Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: Thomas dot Koenig at online dot de CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19106
[Bug c/18740] Execution-time sizeof drops side effects
--- Additional Comments From rth at gcc dot gnu dot org 2004-12-21 13:39 --- Not a bug. Sizeof *never* has side effects. -- What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18740
[Bug c/16989] [meta-bug] C99 conformance bugs
-- Bug 16989 depends on bug 18740, which changed state. Bug 18740 Summary: Execution-time sizeof drops side effects http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18740 What|Old Value |New Value Status|NEW |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16989
[Bug c/18740] Execution-time sizeof drops side effects
--- Additional Comments From rth at gcc dot gnu dot org 2004-12-21 13:43 --- I'm wrong. What a stupid thing to do to the C language. Someone should be smacked. -- What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18740
[Bug c/16989] [meta-bug] C99 conformance bugs
-- Bug 16989 depends on bug 18740, which changed state. Bug 18740 Summary: Execution-time sizeof drops side effects http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18740 What|Old Value |New Value Status|RESOLVED|REOPENED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16989
[Bug target/17767] [4.0 Regression] MMX intrinsics cause internal compiler error
--- Additional Comments From uros at kss-loka dot si 2004-12-21 13:47 --- The problem here is that case RTX_COMPARE:/case RTX_COMM_COMPARE: in fold_rtx() in cse.c is not 'vector safe'. The testcase from comment #3 will trigger these parts of RTX_COMPARE case: /* See if the two operands are the same. */ if (folded_arg0 == folded_arg1 ... Operands are the same, (reg:V4HI 62 [ D.1293 ]) and (reg:V4HI 62 [ D.1293 ]). /* Sadly two equal NaNs are not equivalent. */ if (!HONOR_NANS (mode_arg0)) return ((code == EQ || code == LE || code == GE || code == LEU || code == GEU || code == UNEQ || code == UNLE || code == UNGE || code == ORDERED) ? true_rtx : false_rtx); V4HI mode obviously does not HONOR_NANS and (code == EQ). A 'true_rtx' is returned, but a _vector_ of trues would be more appropriate in this case. I guess the RTX_COMPARE case should be recoded for vector support, or patch from comment #7 should be used to prevent VECTOR_MODES from entering this code. Uros. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17767
[Bug tree-optimization/19107] New: regclass.c miscompiled by -ftree-vectorize
Hope I didn't mess anything with my gcc tree :) Steps to reproduce: 1. apply the patch to regclass.c 2. compile record_operand_costs.i with -O1 -ftree-vectorize and link into cc1 3. use testcase bug.i to see segmentation fault -- Summary: regclass.c miscompiled by -ftree-vectorize Product: gcc Version: 4.0.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P2 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: belyshev at lubercy dot com CC: gcc-bugs at gcc dot gnu dot org GCC target triplet: i686-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19107
[Bug tree-optimization/19107] regclass.c miscompiled by -ftree-vectorize
--- Additional Comments From belyshev at lubercy dot com 2004-12-21 14:10 --- Created an attachment (id=7795) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7795action=view) patch to regclass.c (1840 bytes) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19107
[Bug tree-optimization/19107] regclass.c miscompiled by -ftree-vectorize
--- Additional Comments From belyshev at lubercy dot com 2004-12-21 14:11 --- Created an attachment (id=7796) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7796action=view) failing function (5644 bytes) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19107
[Bug tree-optimization/19107] regclass.c miscompiled by -ftree-vectorize
--- Additional Comments From belyshev at lubercy dot com 2004-12-21 14:12 --- Created an attachment (id=7797) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7797action=view) testcase (349 bytes) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19107
[Bug c++/19108] New: [4.0 regression] ICE initializing arrays
The following valid code snippet causes an ICE on mainline when
compiled with -O:
==
struct A
{
int i[6];
A () : i() {}
};
struct B
{
A a;
B(const A x) : a(x) {}
};
B b=A();
==
bug.cc: In function 'void __static_initialization_and_destruction_0(int,
int)':
bug.cc:13: internal compiler error: in sra_hash_tree, at tree-sra.c:383
Please submit a full bug report, [etc.]
This seems to be a recent regression (within the last week).
The problem might be related to PR 18793.
--
Summary: [4.0 regression] ICE initializing arrays
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code, monitored
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org,mark at codesourcery dot
com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19108
[Bug libgcj/19109] New: Creating archives with java.util.zip
The below code produces a zip file that can be opened in WinZip 8.1 when
compiled with Sun JRE 1.4.1_01. When compiled with GCJ 3.4.0 the zip file is
produced but WinZip says it's corrupt.
Is this a bug in GCJ or am I misunderstanding how java.util.zip works in libgcj?
Thanks.
Usage: Pass in two arguments to class. First arg is name of archive and second
is the name of the file you want to add to the archive.
import java.io.BufferedInputStream;
import java.io.File;
import java.io.FileInputStream;
import java.io.FileOutputStream;
import java.util.zip.Deflater;
import java.util.zip.ZipEntry;
import java.util.zip.ZipOutputStream;
public class ZipMain {
/**
*
*/
public ZipMain() {
super();
}
public static void main(String[] args) {
String sArchive = args[0];
String sFile = args[1];
if (sArchive==null || sFile==null ||
sArchive.length()==0 || sFile.length()==0){
return;
}
File f = new File(sFile);
if (!f.exists()){
return;
}
ZipOutputStream oArchive = null;
File fArchive = new File(sArchive);
try {
//open archive
oArchive = new ZipOutputStream(new
FileOutputStream(fArchive));
oArchive.setLevel(Deflater.DEFAULT_COMPRESSION);
//add file
ZipEntry zipEntry = new ZipEntry(f.toString());
FileInputStream fin = new FileInputStream(f);
BufferedInputStream in = new BufferedInputStream(fin);
oArchive.putNextEntry(zipEntry);
byte[] buf = new byte[1024];
int len;
while ((len = in.read(buf)) = 0) {
oArchive.write(buf, 0, len);
}
//clean up
in.close();
oArchive.closeEntry();
oArchive.close();
} catch (Exception e){
e.printStackTrace();
}
}
}
--
Summary: Creating archives with java.util.zip
Product: gcc
Version: 3.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: libgcj
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: wayne dot gray at coynetextileservices dot com
CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu
dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19109
[Bug libgcj/19109] Creating archives with java.util.zip
--- Additional Comments From belyshev at lubercy dot com 2004-12-21 14:48 --- It works for me with mainline. -- What|Removed |Added Keywords||wrong-code Known to work||4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19109
[Bug middle-end/19100] Wrong code for ?-operator with casted ?-operator predicat
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |roger at eyesopen dot com |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19100
[Bug c/19099] No warning for uninitialized local variable use
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-21 15:20 --- Use -Winit-self and -Wuninitialized (and -O1). See http://gcc.gnu.org/onlinedocs/gcc-3.4.3/gcc/Warning-Options.html#Warning-Options where this is documented. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19099
[Bug target/16111] generates invalid SSE movdqa instruction (instead of movaps)
--- Additional Comments From uros at kss-loka dot si 2004-12-21 15:25
---
Does life analysis eat RTLs with -O2?
This part is from pr16111_.cpp.15.cse2:
...
(note 8 7 13 0 NOTE_INSN_FUNCTION_BEG)
(insn 13 8 16 0 (set (mem/i:SI (plus:SI (reg/f:SI 20 frame)
(const_int -4 [0xfffc])) [5 MASK+0 S4 A32])
(const_int -2147483648 [0x8000])) 35 {*movsi_1} (nil)
(nil))
(insn 16 13 17 0 (set (reg:SF 73)
(mem:SF (plus:SI (reg/f:SI 20 frame)
(const_int -4 [0xfffc])) [7 S4 A32])) 60 {*movsf_1} (nil)
(nil))
(insn 17 16 21 0 (set (mem/i:SF (plus:SI (reg/f:SI 20 frame)
(const_int -8 [0xfff8])) [7 __F+0 S4 A32])
(reg:SF 73)) 60 {*movsf_1} (nil)
(nil))
...
And in pr16111_.cpp.16.life, (insn 13) is just missing. There is no
NOTE_INSN_DELETED, just plain nothing:
...
(note 8 7 16 0 NOTE_INSN_FUNCTION_BEG)
(insn 16 8 17 0 (set (reg:SF 73)
(mem:SF (plus:SI (reg/f:SI 20 frame)
(const_int -4 [0xfffc])) [7 S4 A32])) 60 {*movsf_1} (nil)
(nil))
(insn 17 16 21 0 (set (mem/i:SF (plus:SI (reg/f:SI 20 frame)
(const_int -8 [0xfff8])) [7 __F+0 S4 A32])
(reg:SF 73)) 60 {*movsf_1} (insn_list:REG_DEP_TRUE 16 (nil))
(expr_list:REG_DEAD (reg:SF 73)
(nil)))
...
Uros.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Last reconfirmed|-00-00 00:00:00 |2004-12-21 15:25:19
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16111
[Bug tree-optimization/19098] tree-ssa-dom.c has an if statement whose condition is probably wrong
--- Additional Comments From law at redhat dot com 2004-12-21 15:26 --- Subject: Re: tree-ssa-dom.c has an if statement whose condition is probably wrong On Tue, 2004-12-21 at 08:07 +, kazu at cs dot umass dot edu wrote: --- Additional Comments From kazu at cs dot umass dot edu 2004-12-21 08:07 --- Can we do something like the following? Avoid creating multiple entries to into a loop before the loop optimizations run. Try to thread every edge after the loop optimizations run. Possibly. I don't know if it's worth the headache and cost though. Jeff -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19098
[Bug target/18473] unrecognizable insn compiling various sources
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-21 15:28 --- So closing as will not fix. -- What|Removed |Added Status|WAITING |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18473
[Bug tree-optimization/19108] [4.0 regression] ICE initializing arrays
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-21 15:30 --- This is more likely related to a bug which I filed. -- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Component|c++ |tree-optimization Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2004-12-21 15:30:54 date|| Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19108
[Bug libgcj/19109] Creating archives with java.util.zip
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-21 15:48 --- Fixed on the mainline. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19109
[Bug c++/18681] [3.3/3.4/4.0 Regression] template friend declaration not recognized
--- Additional Comments From lerdsuwa at gcc dot gnu dot org 2004-12-21 15:50 --- Revised patch for 4.0 posted: http://gcc.gnu.org/ml/gcc-patches/2004-12/msg01634.html -- What|Removed |Added Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18681
[Bug tree-optimization/19105] fold does not spot anti-range test
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-21 15:52 --- Fold unlike simplify_rtx does not do as re-association (or really as much as re-association). -- What|Removed |Added Severity|normal |enhancement Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||missed-optimization Last reconfirmed|-00-00 00:00:00 |2004-12-21 15:52:02 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19105
[Bug tree-optimization/19104] in range test not noticed
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-21 15:54 --- Again (this is really the same problem as 19105): Fold unlike simplify_rtx does not do as re-association (or really as much as re-association). Oh, forgot to say why, because we call fold a lot more than simplify_rtx. -- What|Removed |Added Severity|normal |enhancement Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||missed-optimization Last reconfirmed|-00-00 00:00:00 |2004-12-21 15:54:55 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19104
[Bug middle-end/18424] [3.4/4.0 Regression] ~6x+ performance regression, constant trees not being computed.
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-21 16:02 --- No the orginal problem was fixed, please open a new bug about the new problem, I would not doubt that the new problem is not a regression. -- What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18424
[Bug tree-optimization/19108] [4.0 regression] ICE initializing arrays
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-21 16:10 --- sra_hash_tree does not handle RANGE_EXPRs. This implements them but it might not be the correct approach though: Index: tree-sra.c === RCS file: /cvs/gcc/gcc/gcc/tree-sra.c,v retrieving revision 2.47 diff -u -p -r2.47 tree-sra.c --- tree-sra.c 10 Dec 2004 21:54:42 - 2.47 +++ tree-sra.c 21 Dec 2004 16:09:09 - @@ -378,6 +378,11 @@ sra_hash_tree (tree t) h = iterative_hash_expr (DECL_FIELD_OFFSET (t), 0); h = iterative_hash_expr (DECL_FIELD_BIT_OFFSET (t), h); break; + +case RANGE_EXPR: + h = sra_hash_tree (TREE_OPERAND (t, 0)); + h ^= sra_hash_tree (TREE_OPERAND (t, 1)); + break; default: gcc_unreachable (); -- What|Removed |Added CC||rth at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19108
[Bug java/19110] New: Simple java program does not work properly
[EMAIL PROTECTED]:/tmp$ cat Hello.java
public class Hello{
public static void main(String[] args) {
System.out.println(hello);
}
}
[EMAIL PROTECTED]:/tmp$ gcj-3.4 -o hello --main=Hello Hello.java
[EMAIL PROTECTED]:/tmp$ ./hello
?
[EMAIL PROTECTED]:/tmp$ gcj-3.3 -o hello --main=Hello Hello.java
[EMAIL PROTECTED]:/tmp$ ./hello
hello
[EMAIL PROTECTED]:/tmp$
--
Summary: Simple java program does not work properly
Product: gcc
Version: 3.4.4
Status: UNCONFIRMED
Severity: critical
Priority: P2
Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: avdyk at debian dot org
CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu
dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19110
[Bug java/19110] Simple java program does not work properly
--- Additional Comments From avdyk at debian dot org 2004-12-21 16:31 --- I'm working on Debian Sid on a powerpc. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19110
[Bug inline-asm/19111] New: Alignment ignored if optimizing for size
Hello,
Please correct me if this is just invalid code, but it compiles and runs
perfectly when compiled with -O0, -O1, -O2 or when build with intelC...
I've reduced it to this:
int main()
{
float __attribute__((aligned(16))) aligned_field[4];
asm
(
leal%0, %%edx\n // load pointer to this-data[0]
movaps (%%edx), %%xmm0\n // use aligned instruction
:
:m(aligned_field[0])
:edx,xmm0
);
return 0;
}
GDB tells the application crashes in movaps. If I use movups it works with
-Os. If I do something __productive__ with the data in the field, the -O3
binary doesn't crash, but I get false results, while -O2 and less work well.
gcc -v says:
Reading specs from /usr/lib/gcc/i686-pc-linux-gnu/3.4.3/specs
Configured with: /var/tmp/portage/gcc-3.4.3-r1/work/gcc-3.4.3/configure
--enable-version-specific-runtime-libs --prefix=/usr
--bindir=/usr/i686-pc-linux-gnu/gcc-bin/3.4.3
--includedir=/usr/lib/gcc/i686-pc-linux-gnu/3.4.3/include
--datadir=/usr/share/gcc-data/i686-pc-linux-gnu/3.4.3
--mandir=/usr/share/gcc-data/i686-pc-linux-gnu/3.4.3/man
--infodir=/usr/share/gcc-data/i686-pc-linux-gnu/3.4.3/info
--with-gxx-include-dir=/usr/lib/gcc/i686-pc-linux-gnu/3.4.3/include/g++-v3
--host=i686-pc-linux-gnu --disable-altivec --enable-nls
--without-included-gettext --enable-__cxa_atexit --enable-clocale=gnu
--with-system-zlib --disable-checking --disable-werror
--disable-libunwind-exceptions --enable-shared --enable-threads=posix
--disable-multilib --enable-java-awt=gtk
--enable-languages=c,c++,f77,objc,java
Thread model: posix
gcc version 3.4.3 20041125 (Gentoo Linux 3.4.3-r1, ssp-3.4.3-0, pie-8.7.7)
--
Summary: Alignment ignored if optimizing for size
Product: gcc
Version: 3.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: inline-asm
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: alonsoschaich at gmx dot de
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19111
[Bug inline-asm/19111] Alignment ignored if optimizing for size
--- Additional Comments From alonsoschaich at gmx dot de 2004-12-21 16:33 --- Created an attachment (id=7798) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7798action=view) .ii file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19111
[Bug inline-asm/19111] Alignment ignored if optimizing for size
-- What|Removed |Added Known to fail||3.3.4 3.4.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19111
[Bug c++/19112] New: assignment from function to template fails
I try to assign a template to another template. Direct assignment works,
but when I try to assign the result of a function call, gcc fails. Under
the given canditates the expected one is listed.
following code fails using gcc:
// template test for gcc
//
templateclass TEST
class Pointer
{
public:
Pointer(TEST initValue): m_data(initValue) {}
Pointer(PointerTEST other): m_data(other.m_data) {}
virtual ~Pointer() {}
//PointerTEST operator = (PointerTEST other) { m_data =
other.m_data; return *this; }
private:
TEST m_data;
};
templateclass TEST
class UsePointer
{
public:
UsePointer(PointerTEST point)
: m_localCopy(point)
{}
UsePointer(PointerTEST point)
: m_localCopy(point)
{
}
private:
PointerTEST m_localCopy;
};
Pointerint getSomething()
{
Pointerint result(4);
return result;
}
int main(int argc, char* argv[])
{
UsePointerint user(getSomething());
return 0;
}
with following output
[EMAIL PROTECTED]:~/Entwicklung/eigenes$ gcc -v -save-temps -c templates.cpp -o
templtest
Reading specs from /usr/lib/gcc-lib/i486-linux/3.3.5/specs
Configured with: ../src/configure -v
--enable-languages=c,c++,java,f77,pascal,objc,ada,treelang --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--with-gxx-include-dir=/usr/include/c++/3.3 --enable-shared --with-system-zlib
--enable-nls --without-included-gettext --enable-__cxa_atexit
--enable-clocale=gnu --enable-debug --enable-java-gc=boehm
--enable-java-awt=xlib --enable-objc-gc i486-linux
Thread model: posix
gcc version 3.3.5 (Debian 1:3.3.5-2)
/usr/lib/gcc-lib/i486-linux/3.3.5/cc1plus -E -D__GNUG__=3 -quiet -v
-D__GNUC__=3 -D__GNUC_MINOR__=3 -D__GNUC_PATCHLEVEL__=5 -D_GNU_SOURCE
templates.cpp templates.ii
ignoring nonexistent directory /usr/i486-linux/include
#include ... search starts here:
#include ... search starts here:
/usr/include/c++/3.3
/usr/include/c++/3.3/i486-linux
/usr/include/c++/3.3/backward
/usr/local/include
/usr/lib/gcc-lib/i486-linux/3.3.5/include
/usr/include
End of search list.
/usr/lib/gcc-lib/i486-linux/3.3.5/cc1plus -fpreprocessed templates.ii -quiet
-dumpbase templates.cpp -auxbase-strip templtest -version -o templates.s
GNU C++ version 3.3.5 (Debian 1:3.3.5-2) (i486-linux)
compiled by GNU C version 3.3.5 (Debian 1:3.3.5-2).
GGC heuristics: --param ggc-min-expand=99 --param ggc-min-heapsize=129567
templates.cpp: In function `int main(int, char**)':
templates.cpp:45: error: no matching function for call to `Pointerint::
Pointer(Pointerint)'
templates.cpp:9: error: candidates are: PointerTEST::Pointer(PointerTEST)
[with TEST = int]
templates.cpp:8: error: PointerTEST::Pointer(TEST) [with
TEST
= int]
templates.cpp:45: error: initializing argument 1 of `
UsePointerTEST::UsePointer(PointerTEST) [with TEST = int]'
--
Summary: assignment from function to template fails
Product: gcc
Version: 3.3.5
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: d dot hentrich at gmx dot de
CC: gcc-bugs at gcc dot gnu dot org
GCC host triplet: linux
GCC target triplet: linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19112
[Bug target/19102] [3.4 Regression] -march=pentium3 breaks linux kernel compiles w/ gcc-3_4-branch as of 2004/12/20
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-21 16:44 --- Hmm, it worked with 2004-12-11. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19102
[Bug c/18963] [4.0 Regression] static and nested declarations cause an ice
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-12-21 17:07 --- Subject: Bug 18963 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2004-12-21 17:07:06 Modified files: gcc: c-decl.c ChangeLog gcc/testsuite : ChangeLog Added files: gcc/testsuite/gcc.dg: pr18963-1.c Log message: 2004-12-21 James A. Morrison [EMAIL PROTECTED] PR c/18963 * c-decl.c (pushdecl): Remove block trying to merge static function declarations at block scope to file scope declarations. testsuite: PR c/18963 * gcc.dg/pr18963-1.c: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-decl.c.diff?cvsroot=gccr1=1.618r2=1.619 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.6911r2=2.6912 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.4789r2=1.4790 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/pr18963-1.c.diff?cvsroot=gccr1=NONEr2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18963
[Bug c/18596] [4.0 regression] ICE in make_decl_rtl
--- Additional Comments From phython at gcc dot gnu dot org 2004-12-21 17:09 --- Lets see if I did it right this time. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18596
[Bug c/18963] [4.0 Regression] static and nested declarations cause an ice
--- Additional Comments From phython at gcc dot gnu dot org 2004-12-21 17:11 --- Removed some code and fixed a bug. That looks like a good thing. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18963
[Bug inline-asm/19111] Alignment ignored if optimizing for size
--- Additional Comments From rth at gcc dot gnu dot org 2004-12-21 17:25
---
If movaps crashes in main, it means your libc is broken and isn't aligning
the stack before main. GCC does add some code to main to realign the end
of the stack, but that doesn't help main itself. You'd have to move your
code to a new function like so:
static int __attribute__((noinline)) main1 (int ac, char **av)
{
/* whatever */
}
int main(int ac, char **av)
{
return main1(ac, av);
}
In either case, gcc has done all it can do.
--
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19111
[Bug c++/18975] [4.0 regression] Copying objects with mutable non-static data members
--- Additional Comments From nathan at gcc dot gnu dot org 2004-12-21 17:27 --- 2004-12-21 Nathan Sidwell [EMAIL PROTECTED] PR c++/18975 * method.c (do_build_copy_constructor): Refactor. Don't const qualify a mutable field. (do_build_assign_ref): Likewise. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18975
[Bug c++/18975] [4.0 regression] Copying objects with mutable non-static data members
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-12-21 17:28 --- Subject: Bug 18975 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2004-12-21 17:28:35 Modified files: gcc/cp : ChangeLog method.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/g++.dg/other: synth1.C Log message: cp: PR c++/18975 * method.c (do_build_copy_constructor): Refactor. Don't const qualify a mutable field. (do_build_assign_ref): Likewise. testsuite: PR c++/18975 * g++.dg/other/synth1.C: New. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gccr1=1.4544r2=1.4545 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/method.c.diff?cvsroot=gccr1=1.317r2=1.318 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.4790r2=1.4791 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/other/synth1.C.diff?cvsroot=gccr1=1.1r2=1.2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18975
[Bug c++/19112] assignment from function to template fails
--- Additional Comments From bangerth at dealii dot org 2004-12-21 17:36
---
gcc is correct: the result of getSomething is a temporary. Temporaries can
only be bound to const references, not to non-const ones. Thus, the
constructor
UsePointer(PointerTEST point)
: m_localCopy(point)
{}
is not a candidate. In order to use the constructor
UsePointer(PointerTEST point)
: m_localCopy(point)
{
}
you need to be able to copy objects of type Pointerint, but then you
run into the same problem of not having an appropriate copy constructor
of Pointer that takes a constant reference.
W.
--
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19112
[Bug tree-optimization/17617] Micro-optimize INTEGRAL_TYPE_P (or tree.def rather)
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |nathan at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17617
[Bug tree-optimization/17617] Micro-optimize INTEGRAL_TYPE_P (or tree.def rather)
--- Additional Comments From nathan at gcc dot gnu dot org 2004-12-21 17:43 --- 2004-12-21 Nathan Sidwell [EMAIL PROTECTED] * system.c (IN_RANGE): Use plain unsigned, not unsigned HOST_WIDE_INT. * tree.def (VOID_TYPE, INTEGER_TYPE, REAL_TYPE, COMPLEX_TYPE, VECTOR_TYPE, OFFSET_TYPE, ENUMERAL_TYPE, BOOLEAN_TYPE, CHAR_TYPE, POINTER_TYPE, REFERENCE_TYPE, METHOD_TYPE, FUNCTION_TYPE, FILE_TYPE, ARRAY_TYPE, RECORD_TYPE, UNION_TYPE, QUAL_UNION_TYPE): Reorder for better code efficiency. (CONST_DECL, TYPE_DECL, VAR_DECL, FIELD_DECL, PARM_DECL): Likewise. (INDIRECT_REF, ALIGN_INDIRECT_REF, MISALIGNED_INDIRECT_REF): Likewise. * tree.h (INDIRECT_REF_P): Reorder checks for better optimization. (IS_EXPR_CODE_CLASS): Use IN_RANGE. (INTEGRAL_TYPE_P, FLOAT_TYPE_P): Reorder checks for better optimization. * cp/cp-tree.def (TEMPLATE_TYPE_PARM, BOUND_TEMPLATE_TEMPLATE_PARM, TYPE_OF_TYPE, TYPENAME_TYPE): Reorder for better code efficiency. * cp/cp-tree.h (CLASS_TYPE_P): Short circuit IS_AGGR_TYPE check. (CAN_HAVE_FULL_LANG_DECL_P): Reorder for better optimization. (INTEGRAL_CODE_P, CP_INTEGRAL_TYPE_P, INTEGRAL_OR_ENUMERATION_TYPE_P, SCALAR_TYPE_P, CP_AGGREGATE_TYPE_P, TYPE_PTROB_P, TYPE_REF_OBJ_P, TYPE_PTROBV_P): Likewise. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17617
[Bug c/19113] New: Assigning to va_list var is valid for va_arg calls but not other cases
With gcc 3.4.3, I got
[EMAIL PROTECTED] tmp]$ cat a.c
#include stdarg.h
void
foo(int l, ...)
{
va_list p,q,r;
va_start(p,l);
#if WORK
q = va_arg(p,va_list);
#else
/* The following code fails */
q = r;
#endif
}
[EMAIL PROTECTED] tmp]$ gcc -S a.c
a.c: In function `foo':
a.c:11: incompatible types in assignment
[EMAIL PROTECTED] tmp]$ gcc -S a.c -DWORK
It used to work in gcc 2.96:
[EMAIL PROTECTED] tmp]$ gcc -S a.c
[EMAIL PROTECTED] tmp]$ gcc -v
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs
gcc version 2.96 2731 (Red Hat Linux 7.2 2.96-128.7.2)
Is that a bug or a feature?
--
Summary: Assigning to va_list var is valid for va_arg calls but
not other cases
Product: gcc
Version: 3.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl at lucon dot org
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19113
[Bug c++/14075] (foo) accepted as char[] initializer
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-12-21 17:54 --- Subject: Bug 14075 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2004-12-21 17:54:27 Modified files: gcc/cp : ChangeLog cp-tree.h decl.c error.c semantics.c gcc/testsuite : ChangeLog Log message: cp: PR c++/14075 * decl.c (check_initializer): Check string initializer of array is not parenthesized. * cp-tree.h (PAREN_STRING_LITERAL_P): New. * semantics.c (finish_parenthesized_expr): Mark a STRING_CST. * error.c (dump_expr): STRING_CST case Add parens, if needed. testsuite: PR c++/14075 * g++.dg/init/string1.C: New. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gccr1=1.4546r2=1.4547 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/cp-tree.h.diff?cvsroot=gccr1=1.1084r2=1.1085 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/decl.c.diff?cvsroot=gccr1=1.1343r2=1.1344 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/error.c.diff?cvsroot=gccr1=1.274r2=1.275 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/semantics.c.diff?cvsroot=gccr1=1.453r2=1.454 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.4791r2=1.4792 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14075
[Bug target/19102] [3.4 Regression] -march=pentium3 breaks linux kernel compiles w/ gcc-3_4-branch as of 2004/12/20
--- Additional Comments From bero at arklinux dot org 2004-12-21 17:55 --- Worked in 2004-12-17 too, broken in 2004-12-20 and 2004-12-21 (I don't have -18 and -19) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19102
[Bug target/19102] [3.4 Regression] -march=pentium3 breaks linux kernel compiles w/ gcc-3_4-branch as of 2004/12/20
--- Additional Comments From bero at arklinux dot org 2004-12-21 18:00 --- Must be a cc1 issue - 2004-12-21 with 2004-12-17's /usr/libexec/gcc/*/3.4.4/cc1 works -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19102
[Bug target/18027] undocumented ia64-hpux options
--- Additional Comments From sje at cup dot hp dot com 2004-12-21 18:00 --- This has been fixed on the 3.4 branch and ToT with the patch at http://gcc.gnu.org/ml/gcc-patches/2004-12/msg00985.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18027
[Bug libfortran/19114] New: runtime error when reading complex*16 using formatted I/O
gfortran (snapshot as of 12/17/04) compiled code gives a runtime error when reading formatted complex*16 values using the following program: program testIO implicit none integer i complex*16 values(5) open(7,file='test1.dat',status='old') read ( 7, '(5E15.8)' ) ( values (i), i = 1, 5 ) print *, ( values (i), i = 1, 5 ) end The text file test1.dat contains: 2.E+00 0.E+00 2.52505826E-01 0.E+00 1.44380768E-04 -1.11464849E-18 1.01002561E-01 0.E+00-2.52507036E-02 0.E+00 The code was compiled and executed with gfortran bug.f; a.out, and produced the following error message: At line 8 of file bug2.f Fortran runtime error: End of file The code works correctly when compiled with g77 and ifort (Intel Fortran), and produces the output (g77): (2.,0.) (0.252505826,0.) (0.000144380768,-1.11464849E-18) (0.101002561,0.) (-0.0252507036,0.) The code and data was extracted from the Harwell-Boeing collection of sparse matrices, which is a commonly used format for sparse matrix computations. See http://math.nist.gov/MatrixMarket/collections/hb.html. Additional information: gfortran -v gives: Reading specs from /auto/home0/rmunk/temp_gfortran/irun/bin/../lib/gcc/i686-pc-linux-gnu/4.0.0/specs Configured with: ../gcc/configure --enable-languages=c,f95 --prefix=/usr/work/2004352/irun Thread model: posix gcc version 4.0.0 20041217 (experimental) Best regards, Rasmus Munk Larsen, Stanford University -- Summary: runtime error when reading complex*16 using formatted I/O Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rmunk at quake dot stanford dot edu CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19114
[Bug c++/14075] (foo) accepted as char[] initializer
--- Additional Comments From nathan at gcc dot gnu dot org 2004-12-21 18:28 --- 2004-12-16 Nathan Sidwell [EMAIL PROTECTED] PR c++/14075 * decl.c (check_initializer): Check string initializer of array is not parenthesized. * cp-tree.h (PAREN_STRING_LITERAL_P): New. * semantics.c (finish_parenthesized_expr): Mark a STRING_CST. * error.c (dump_expr): STRING_CST case Add parens, if needed. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14075
[Bug c/19113] Assigning to va_list var is valid for va_arg calls but not other cases
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-21 18:43 --- Use va_copy as this is invalid c. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19113
[Bug target/18027] undocumented ia64-hpux options
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-21 18:44 --- Fixed. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |3.4.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18027
[Bug target/5362] Undocumented target options
-- Bug 5362 depends on bug 18027, which changed state. Bug 18027 Summary: undocumented ia64-hpux options http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18027 What|Old Value |New Value Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5362
[Bug java/19110] Simple java program does not work properly
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-21 18:47 --- Hmm, this works on the mainline (I know because one of the gcj developers use powerpc-linux, I think debian or fordora core). -- What|Removed |Added Severity|critical|normal GCC target triplet||powerpc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19110
[Bug fortran/19101] missing in character continuation not caught
-- What|Removed |Added Keywords||accepts-invalid, diagnostic http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19101
[Bug libfortran/19114] runtime error when reading complex*16 using formatted I/O
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-21 18:51 --- Hmm, did you accidently reload the commit page? *** This bug has been marked as a duplicate of 19064 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19114
[Bug libfortran/19064] runtime error when reading complex*16 using formatted I/O
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-21 18:51 --- *** Bug 19114 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19064
[Bug libfortran/19106] segfault in executable for print *,sum(a,dim=2,mask=a0)
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-21 18:53 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2004-12-21 18:53:17 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19106
[Bug rtl-optimization/19103] [4.0 Regression] Current CVS (2004/12/21) doesn't compile
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-21 19:00 --- Hmm, this works with a cross compiler, how did you configure gcc? Also what stage is this? -- What|Removed |Added Status|UNCONFIRMED |WAITING Component|bootstrap |rtl-optimization Keywords||build, ice-on-valid-code Summary|Current CVS (2004/12/21)|[4.0 Regression] Current CVS |doesn't compile |(2004/12/21) doesn't compile Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19103
[Bug libstdc++/17140] Floating point output is slow
--- Additional Comments From jlquinn at gcc dot gnu dot org 2004-12-21 19:19 --- The power4 segfault occurs in frexpl() in libc, which is a result of calling __builtin_frexpl() inside std::frexp(long double). I was wondering if it might be a problem in long double representation. I think ppc uses 64 bit long double, which made me think that it should be calling frexp under the covers rather than frexpl. I also created a simple test program for frexp that sems to work for double and not for long double. This is making me think the problem isn't in this patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17140
[Bug rtl-optimization/19103] [4.0 Regression] Current CVS (2004/12/21) doesn't compile
--- Additional Comments From bero at arklinux dot org 2004-12-21 19:21 --- I did: configure --prefix=/usr --libdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --enable-static --enable-shared --enable-fast-install --enable-libstdcxx-pch --enable-__cxa_atexit --enable-tls --target=i586-ark-linux --host=i586-ark-linux --build=i586-ark-linux --enable-cxx-flags=-O2 -march=i586 -mcpu=i686 --with-system-zlib --enable-threads --enable-libada --enable-libgcj --enable-interpreter --enable-hash-synchronization make profiledbootstrap Currently trying to see if it's reproducable with make bootstrap instead of make profiledbootstrap. -- What|Removed |Added Status|WAITING |NEW Ever Confirmed||1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19103
[Bug c/19113] Assigning to va_list var is valid for va_arg calls but not other cases
--- Additional Comments From joseph at codesourcery dot com 2004-12-21 19:27 --- Subject: Re: Assigning to va_list var is valid for va_arg calls but not other cases On Tue, 21 Dec 2004, pinskia at gcc dot gnu dot org wrote: Use va_copy as this is invalid c. The compile-time validity depends on whether va_list is an array type (in which case it should be rejected at compile-time) or some other object type (in which case it shouldn't). Copying other than with va_copy is merely undefined behavior at runtime. However, I can't reproduce the original bug report on x86 which would appear to be the target to which it was referring (from the compiler used for comparison). x86-64 does use an array type so the reported behavior would be correct on that target. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19113
[Bug c++/14075] (foo) accepted as char[] initializer
--- Additional Comments From gdr at integrable-solutions dot net 2004-12-21 19:27 --- Subject: Re: (foo) accepted as char[] initializer nathan at gcc dot gnu dot org [EMAIL PROTECTED] writes: | 2004-12-16 Nathan Sidwell [EMAIL PROTECTED] | | PR c++/14075 | * decl.c (check_initializer): Check string initializer of array is | not parenthesized. | * cp-tree.h (PAREN_STRING_LITERAL_P): New. | * semantics.c (finish_parenthesized_expr): Mark a STRING_CST. | * error.c (dump_expr): STRING_CST case Add parens, if needed. The change for error.c is wrong. It should have been in gccp/c-pretty-print.c. And the flag should have been common to both C and C++ too. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14075
[Bug c++/19115] New: __builtin_frexpl and std::frexp(long double) broken
The attached test generates the following output: i=-803365344 i=1 Both __builtin_frexpl and std::frexp(long double) give the above incorrect output. However, ::frexpl works as expected. -- Summary: __builtin_frexpl and std::frexp(long double) broken Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jlquinn at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org GCC host triplet: powerpc-ibm-aix5.2.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19115
[Bug c++/19115] __builtin_frexpl and std::frexp(long double) broken
--- Additional Comments From jlquinn at gcc dot gnu dot org 2004-12-21 19:37 --- Created an attachment (id=7799) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7799action=view) frexp testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19115
[Bug target/19115] __builtin_frexpl and std::frexp(long double) broken
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-21 19:40 --- I should note that long double support for aix needs a little tweak to work. (at least that is what I remembered hearing from David). -- What|Removed |Added Component|c++ |target GCC host triplet|powerpc-ibm-aix5.2.0.0 | GCC target triplet||powerpc-ibm-aix5.2.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19115
[Bug libstdc++/17140] Floating point output is slow
--- Additional Comments From jlquinn at gcc dot gnu dot org 2004-12-21 19:40 --- The AIX problem is PR19115. Paolo, could you see if the same issue happens on ia64 and x86-64? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17140
[Bug libstdc++/17140] Floating point output is slow
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-21 19:42 --- (In reply to comment #31) The power4 segfault occurs in frexpl() in libc, which is a result of calling __builtin_frexpl() inside std::frexp(long double). I was wondering if it might be a problem in long double representation. I think ppc uses 64 bit long double, which made me think that it should be calling frexp under the covers rather than frexpl. PPC AIX uses 128bit long doubles. There are a couple of different issues for 128bit long double support in gcc for PPC, see PR 19019 for one of them, in fact that might be the problem here but I don't know. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17140
[Bug c++/17799] [4.0 Regression] Non-optimizing compile loses 'this'
--- Additional Comments From mmitchel at gcc dot gnu dot org 2004-12-21 19:43 --- Richard, do you consider this a C++ front-end bug? It does not seem to be a front-end bug to me; the this parameter is in fact compiler-generated. It's been marked DECL_ARTIFICIAL since time immemorila. Maybe the middle end should be performing this optimization at -O0 only if DECL_IGNORED_P is set. If you agree, we should recategorize this defect. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17799
[Bug libstdc++/17140] Floating point output is slow
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-21 19:45 --- Also I should note use of long double functions on tagets where it does not does it will cause a link error so be care full with that. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17140
