[Bug java/28149] New: Fail to test GCC on simulation due to libjava build errors.
While testing GCC on a simulator[1], there are some build errors causing the process failed. The files are involving in: (1) libjava/java/util/natVMTimeZone.cc (2) libjava/classpath/native/fdlibm/mprec.c Attachment attempts to fix the issue and drive testing GCC on simulation continue. [1] Reference: http://gcc.gnu.org/simtest-howto.html -- Summary: Fail to test GCC on simulation due to libjava build errors. Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jserv at kaffe dot org GCC build triplet: i486-linux-gnu GCC host triplet: i486-linux-gnu GCC target triplet: arm-elf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28149
[Bug java/28149] Fail to test GCC on simulation due to libjava build errors.
--- Comment #1 from jserv at kaffe dot org 2006-06-24 07:52 --- Created an attachment (id=11739) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11739action=view) Fix build errors in libjava when target = arm-elf simulation -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28149
[Bug fortran/28094] Modulo of real(kind=10) variables doesn't work
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2006-06-24 08:27 --- Subject: Bug 28094 Author: fxcoudert Date: Sat Jun 24 08:27:32 2006 New Revision: 114961 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114961 Log: PR fortran/28094 * trans-intrinsic.c (gfc_conv_intrinsic_mod): Support cases where there is no integer kind equal to the resulting real kind. * intrinsic.c (add_functions): MODULO is not allowed as an actual argument. * Makefile.am: Add _mod_r10.F90 and _mod_r16.F90. * Makefile.in: Regenerate. * generated/_mod_r10.F90: New file. * generated/_mod_r16.F90: New file. Added: trunk/libgfortran/generated/_mod_r10.F90 trunk/libgfortran/generated/_mod_r16.F90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/intrinsic.c trunk/gcc/fortran/trans-intrinsic.c trunk/libgfortran/ChangeLog trunk/libgfortran/Makefile.am trunk/libgfortran/Makefile.in -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28094
[Bug fortran/28094] [4.1 only] Modulo of real(kind=10) variables doesn't work
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Known to fail|4.2.0 4.1.2 |4.1.2 Known to work||4.2.0 Summary|Modulo of real(kind=10) |[4.1 only] Modulo of |variables doesn't work |real(kind=10) variables ||doesn't work Target Milestone|--- |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28094
[Bug target/28150] New: ICE in reload_cse_simplify_operands, at postreload.c:394
$ gcc lib_delegate.i -c -Wall -O
lib_delegate.c: In function 'PackDelegateInvokeParams':
lib_delegate.c:273: error: insn does not satisfy its constraints:
(insn 205 104 105 9 (set (mem/c/i:TF (pre_inc:SI (reg/v/f:SI 29 29 [orig:119
ptr ] [119])) [0 nativeFloat+0 S16 A64])
(reg:TF 45 13)) 242 {*movtf_internal} (nil)
(expr_list:REG_INC (reg/v/f:SI 29 29 [orig:119 ptr ] [119])
(nil)))
lib_delegate.c:273: internal compiler error: in reload_cse_simplify_operands,
at postreload.c:394
--
Summary: ICE in reload_cse_simplify_operands, at postreload.c:394
Product: gcc
Version: 4.1.2
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: ppc-linux
GCC host triplet: ppc-linux
GCC target triplet: ppc-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28150
[Bug target/28150] ICE in reload_cse_simplify_operands, at postreload.c:394
--- Comment #1 from pluto at agmk dot net 2006-06-24 09:23 --- Created an attachment (id=11740) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11740action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28150
[Bug middle-end/28151] New: ICE on complex
The following Fortran source cause an ICE in fold-const.c (indirectly called
from within tree-ssa-propagate.c) when compiling at -O1 or higher. We have
reasons to believe it's not front-end dependent (same problem happens with g95,
which is significantly different from gfortran), but I can't make a C testcase.
complex :: z
z = (1.9E19,0.0)
z = 1/z
end
the dump is the following:
MAIN__ ()
{
complex4 z;
_gfortran_set_std (70, 127, 0);
z = __complex__ (9.996802856924650656260769173209088e+37,
9.996802856924650656260769173209088e+37);
z = __complex__ (1.0e+0, 0.0) / z;
}
but I can't make a C testcase out of that. I can't isolate a single options
among the ones implied by -O1 that is responsible for the ICE. Here is the
backtrace:
Program received signal SIGSEGV, Segmentation fault.
const_binop (code=PLUS_EXPR, arg1=0x0, arg2=0xb7c8c7e0, notrunc=0)
at ../../../trunk/gcc/fold-const.c:1551
1551 STRIP_NOPS (arg1);
(gdb) where
#0 const_binop (code=PLUS_EXPR, arg1=0x0, arg2=0xb7c8c7e0, notrunc=0)
at ../../../trunk/gcc/fold-const.c:1551
#1 0x081fc38c in const_binop (code=RDIV_EXPR, arg1=0xb7c8c7e0, arg2=Variable
a
rg2 is not available.
)
at ../../../trunk/gcc/fold-const.c:1688
#2 0x08209e22 in fold_binary (code=Variable code is not available.
) at ../../../trunk/gcc/fold-const.c:8282
#3 0x0846da13 in evaluate_stmt (stmt=0xb7c32168)
at ../../../trunk/gcc/tree-ssa-ccp.c:924
#4 0x0846e1f1 in ccp_visit_stmt (stmt=0xb7c32168, taken_edge_p=0xbfac1b4c,
output_p=0xbfac1b48) at ../../../trunk/gcc/tree-ssa-ccp.c:1203
#5 0x0813573d in simulate_stmt (stmt=0xb7c32168)
at ../../../trunk/gcc/tree-ssa-propagate.c:306
#6 0x08135f9a in ssa_propagate (visit_stmt=0x846e020 ccp_visit_stmt,
visit_phi=0x846cea0 ccp_visit_phi_node)
at ../../../trunk/gcc/tree-ssa-propagate.c:429
#7 0x0846ea6e in execute_ssa_ccp (store_ccp=Variable store_ccp is not
availab
le.
)
at ../../../trunk/gcc/tree-ssa-ccp.c:1391
#8 0x0846ed2a in do_ssa_ccp () at ../../../trunk/gcc/tree-ssa-ccp.c:1399
#9 0x083ce7bb in execute_one_pass (pass=0x865c560)
at ../../../trunk/gcc/passes.c:864
#10 0x083ce95f in execute_pass_list (pass=0x865c560)
at ../../../trunk/gcc/passes.c:911
#11 0x083ce972 in execute_pass_list (pass=0x8659be0)
at ../../../trunk/gcc/passes.c:912
#12 0x080df2d6 in tree_rest_of_compilation (fndecl=0xb7c89c80)
at ../../../trunk/gcc/tree-optimize.c:418
#13 0x08426492 in cgraph_expand_function (node=0xb7c429c0)
at ../../../trunk/gcc/cgraphunit.c:1112
#14 0x08428ffd in cgraph_optimize () at ../../../trunk/gcc/cgraphunit.c:1177
#15 0x080a76fc in gfc_be_parse_file (set_yydebug=0)
at ../../../trunk/gcc/fortran/f95-lang.c:307
#16 0x0839ac3a in toplev_main (argc=14, argv=0xbfac1dc4)
at ../../../trunk/gcc/toplev.c:999
#17 0x080dad2f in main (argc=0, argv=0xb7c3a958)
at ../../../trunk/gcc/main.c:35
--
Summary: ICE on complex
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fxcoudert at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28151
[Bug fortran/28005] [4.1 only] gfortran: mathmul produces wrong result
--- Comment #6 from pault at gcc dot gnu dot org 2006-06-24 10:55 --- The patch did not apply to 4.1, so I will have to submit a back port. Watch this space! Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Summary|gfortran: mathmul produces |[4.1 only] gfortran: mathmul |wrong result|produces wrong result http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28005
[Bug middle-end/28151] ICE on complex
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-06-24 11:37 --- Confirmed. We have Breakpoint 3, const_binop (code=RDIV_EXPR, arg1=0xa7bc6708, arg2=0xa7bc6690, notrunc=0) at /home/richard/src/trunk/gcc/fold-const.c:1691 (gdb) call debug_generic_expr (arg1) __complex__ (1.0e+0, 0.0) (gdb) call debug_generic_expr (arg2) __complex__ (1.9007326203904e+19, 0.0) which calls the const_binop (PLUS_EXPR, ...) with the results of const_binop (code=MULT_EXPR, arg1=0xa7bc6660, arg2=0xa7bc6660, notrunc=0) at /home/richard/src/trunk/gcc/fold-const.c:1554 1554 STRIP_NOPS (arg1); (gdb) call debug_generic_expr (arg1) 0.0 (gdb) call debug_generic_expr (arg2) 0.0 Value returned is $5 = (union tree_node *) 0xa7bc67e0 (gdb) call debug_generic_expr ($5) 0.0 and const_binop (code=MULT_EXPR, arg1=0xa7bc6630, arg2=0xa7bc6630, notrunc=0) at /home/richard/src/trunk/gcc/fold-const.c:1554 1554 STRIP_NOPS (arg1); (gdb) call debug_generic_expr (arg1) 1.9007326203904e+19 (gdb) call debug_generic_expr (arg2) 1.9007326203904e+19 Value returned is $6 = (union tree_node *) 0x0 !? We hit 1614 /* Don't constant fold this floating point operation if 1615 the result has overflowed and flag_trapping_math. */ 1616 1617 if (flag_trapping_math 1618 MODE_HAS_INFINITIES (mode) 1619 REAL_VALUE_ISINF (result) 1620 !REAL_VALUE_ISINF (d1) 1621 !REAL_VALUE_ISINF (d2)) 1622return NULL_TREE; because the multiplication result is infinity (in SFmode). -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-06-24 11:37:02 date|| Summary|ICE on complex |ICE on complex http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28151
[Bug middle-end/28151] ICE on complex
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-06-24 11:40 --- So the fix is simply to watch for failed folding from const_binop in itself. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28151
[Bug fortran/28118] ICE calling subroutine defined via explicit interface
--- Comment #4 from pault at gcc dot gnu dot org 2006-06-24 13:04 --- Subject: Bug 28118 Author: pault Date: Sat Jun 24 13:04:37 2006 New Revision: 114964 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114964 Log: 2006-06-24 Paul Thomas [EMAIL PROTECTED] PR fortran/28118 * trans-array.c (gfc_conv_expr_descriptor): When building temp, use the substring reference to calculate the length if the expression does not have a charlen. 2006-06-24 Paul Thomas [EMAIL PROTECTED] PR fortran/28118 * gfortran.dg/actual_array_substr_1.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/actual_array_substr_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-array.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28118
[Bug middle-end/28151] ICE on complex
--- Comment #3 from steven at gcc dot gnu dot org 2006-06-24 13:50 --- We ICE in fold-const.c line 1691 (r114961): = const_binop (PLUS_EXPR, const_binop (MULT_EXPR, r2, r2, notrunc), const_binop (MULT_EXPR, i2, i2, notrunc), notrunc); This happens because const_binop (MULT_EXPR, r2, r2, notrunc) returns NULL_TREE. The input argument r2 is 0.0: Breakpoint 3, const_binop (code=RDIV_EXPR, arg1=0x2affafc0, arg2=0x2affaf90, notrunc=0) at fold-const.c:1691 1691 notrunc); (gdb) step const_binop (code=MULT_EXPR, arg1=0x2af2e5c8, arg2=0x2af2e5c8, notrunc=0) at fold-const.c:1554 1554 STRIP_NOPS (arg1); (gdb) p debug_tree(arg1) real_cst 0x2af2e5c8 type real_type 0x2af45210 real4 SF size integer_cst 0x2af29540 constant invariant 32 unit size integer_cst 0x2af29060 constant invariant 4 align 32 symtab 0 alias set -1 precision 32 pointer_to_this pointer_type 0x2af45420 constant invariant 0.0 $17 = void (gdb) p debug_tree(arg2) real_cst 0x2af2e5c8 type real_type 0x2af45210 real4 SF size integer_cst 0x2af29540 constant invariant 32 unit size integer_cst 0x2af29060 constant invariant 4 align 32 symtab 0 alias set -1 precision 32 pointer_to_this pointer_type 0x2af45420 constant invariant 0.0 $18 = void (gdb) -- steven at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |steven at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-06-24 11:37:02 |2006-06-24 13:50:09 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28151
[Bug middle-end/28151] ICE on complex
--- Comment #4 from steven at gcc dot gnu dot org 2006-06-24 13:53 --- Uhm, Richi is right. Ignore comment #4. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28151
[Bug middle-end/28151] [4.1/4.2 Regression] ICE on complex assignment in nested function
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-06-24 13:55 ---
Confirmed a regression from 4.0.2, here is a C testcase:
_Complex float b;
int main(void)
{
_Complex float a = 1.9E19;
b = 1/a;
}
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Known to fail||4.2.0 4.1.0
Known to work||4.0.2
Summary|ICE on complex |[4.1/4.2 Regression] ICE on
||complex assignment in nested
||function
Target Milestone|--- |4.1.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28151
[Bug c/28152] New: Diagnostic about wrong use _Complex prints __complex__
$ cat t.c
int
main (void)
{
_Complex float z;
z = _Complex (1.9007326203904e+19, 0.0);
z = _Complex (1.0e+0, 0.0) / z;
$ ./cc1 -quiet t.c
t.c: In function 'main':
t.c:6: error: expected expression before '__complex__'
t.c:7: error: expected expression before '__complex__'
$ ./cc1 --version
GNU C version 4.2.0 20060624 (experimental) (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.0.2 20050901 (prerelease) (SUSE Linux).
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
$
--
Summary: Diagnostic about wrong use _Complex prints __complex__
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: steven at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28152
[Bug middle-end/28151] [4.1/4.2 Regression] ICE with complex division
--- Comment #6 from steven at gcc dot gnu dot org 2006-06-24 14:13 --- The code that causes this regression is actually in the first ever checkin of fold-const.c (r330). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28151
[Bug middle-end/28151] [4.1/4.2 Regression] ICE with complex division
--- Comment #7 from steven at gcc dot gnu dot org 2006-06-24 14:15 --- The problem appears to be caused by the change of semantics of const_binop in this patch: 2005-11-16 Eric Botcazou [EMAIL PROTECTED] * fold-const.c (const_binop): Don't constant fold the operation if the result has overflowed and flag_trapping_math. * simplify-rtx.c (simplify_const_binary_operation): Likewise. -- steven at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28151
[Bug middle-end/28151] [4.1/4.2 Regression] ICE with complex division
-- steven at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|steven at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28151
[Bug middle-end/28151] [4.1/4.2 Regression] ICE with complex math
--- Comment #8 from steven at gcc dot gnu dot org 2006-06-24 14:20 ---
Another test case:
_Complex float b;
int
main (void)
{
_Complex float a = __FLT_MAX__;
b = __FLT_MAX__ + a;
}
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Summary|[4.1/4.2 Regression] ICE|[4.1/4.2 Regression] ICE
|with complex division |with complex math
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28151
[Bug fortran/28118] ICE calling subroutine defined via explicit interface
--- Comment #5 from pault at gcc dot gnu dot org 2006-06-24 14:25 --- Subject: Bug 28118 Author: pault Date: Sat Jun 24 14:25:24 2006 New Revision: 114965 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114965 Log: 2006-06-24 Paul Thomas [EMAIL PROTECTED] PR fortran/28118 * trans-array.c (gfc_conv_expr_descriptor): When building temp, use the substring reference to calculate the length if the expression does not have a charlen. 2006-06-24 Paul Thomas [EMAIL PROTECTED] PR fortran/28118 * gfortran.dg/actual_array_substr_1.f90: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/actual_array_substr_1.f90 Modified: branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/trans-array.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28118
[Bug fortran/28118] ICE calling subroutine defined via explicit interface
--- Comment #6 from pault at gcc dot gnu dot org 2006-06-24 14:26 --- Fixed on trunk and 4.1 Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28118
[Bug middle-end/28151] [4.1/4.2 Regression] ICE with complex math
--- Comment #9 from ebotcazou at gcc dot gnu dot org 2006-06-24 14:54 --- The problem appears to be caused by the change of semantics of const_binop in this patch: 2005-11-16 Eric Botcazou [EMAIL PROTECTED] * fold-const.c (const_binop): Don't constant fold the operation if the result has overflowed and flag_trapping_math. * simplify-rtx.c (simplify_const_binary_operation): Likewise. This patch doesn't change the semantics of const_binop, it only plugs a hole. It looks like const_binop is not prepared for itself returning NULL_TREE... -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC|ebotcazou at gcc dot gnu dot| |org | AssignedTo|unassigned at gcc dot gnu |ebotcazou at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-06-24 13:50:09 |2006-06-24 14:54:58 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28151
[Bug fortran/23862] Select Fortran source form appropriately for -pipe
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2006-06-24 16:06 --- Subject: Bug 23862 Author: fxcoudert Date: Sat Jun 24 16:06:28 2006 New Revision: 114970 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114970 Log: PR fortran/23862 * lang-specs.h (f95-cpp-input): Pass -ffree-form to f951 unless -ffixed-form is explicitly specified. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/lang-specs.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23862
[Bug java/28153] New: Under Windows Xp the generated JNI headers need to have a '_' prepended for each function.
I had some problems when I tried to compile a JNI-example from wikipedia: http://en.wikipedia.org/wiki/JNI I compiled the Java-source containing the native function with 'gcj -C' (gcc version 3.4.2 (mingw-special)): public native void sayHello(); I passed the class-file to 'gcjh -jni' and it produced a header with the line: extern JNIEXPORT void JNICALL Java_JavaSide_sayHello (JNIEnv *env, jobject); I implemented the function, compiled it with 'g++ -O2 -shared' When I tried to run the java class it gave an error when it called the native function. I examined some other dll's used by java (with depens.exe) and all the functions had a '_' prepended. I changed the line in the header file to: extern JNIEXPORT void JNICALL _Java_JavaSide_sayHello (JNIEnv *env, jobject); Recompiled the C++ source and ran the java class. This time the function worked without any problems. -- Summary: Under Windows Xp the generated JNI headers need to have a '_' prepended for each function. Product: gcc Version: 3.4.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bcmpinc at hotmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28153
[Bug target/28150] ICE in reload_cse_simplify_operands, at postreload.c:394
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-06-24 17:49 --- How did you configure GCC becase having TFmode there sounds like you configured to have 128bit long double to be default. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28150
[Bug target/27827] gcc 4 produces worse x87 code on all platforms than gcc 3
--- Comment #15 from whaley at cs dot utsa dot edu 2006-06-24 18:10 --- Hi, Can someone tell me if anyone is looking into this problem with the hopes of fixing it? I just noticed that despite the posted code demonstrating the problem, and verification on: Pentium Pro, Pentium III, Pentium 4e, Pentium-D, Athlon-64 X2 and Opteron, it is still marked as new, and no one is assigned to look at it . . . The reason I ask is that I am preparing the next stable release of ATLAS, and I'm getting close to having to make a decision on what compilers I will support. If someone is working feverishly in the background, I will be sure to wait for it, in the hopes that there'll be a fix that will allow me to use gcc 4, which I think will be what most of my users want. If this problem is not being looked into, I should not delay the ATLAS release for it, and just require my users to install gcc 3 in order to get decent performance. I realize you guys are busy, and fp performance is probably not your main concern, so hopefully this message sounds more like a request for info on what is going on, than a bitch about help that I'm getting for free :) Thanks, Clint -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27827
[Bug fortran/28081] Undue compile-time error for zero-sized substring
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2006-06-24 18:10 --- Subject: Bug 28081 Author: fxcoudert Date: Sat Jun 24 18:10:47 2006 New Revision: 114972 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114972 Log: PR fortran/28081 * resolve.c (resolve_substring): Don't issue out-of-bounds error messages when the range has zero size. * gfortran.dg/substr_3.f: New test. * gfortran.dg/equiv_2.f90: Update expected error message. Added: trunk/gcc/testsuite/gfortran.dg/substr_3.f Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/equiv_2.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28081
[Bug middle-end/27889] [4.1/4.2 Regression] ICE on complex assignment in nested function
--- Comment #13 from pinskia at gcc dot gnu dot org 2006-06-24 18:24 --- Janis could you do a regression hunt with the testcase in comment #6? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||janis at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27889
[Bug target/27827] gcc 4 produces worse x87 code on all platforms than gcc 3
--- Comment #16 from rguenth at gcc dot gnu dot org 2006-06-24 19:00 --- Don't hold your breath. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27827
[Bug fortran/28154] New: SPREAD (and friends) on unallocated arrays
This is not a bug (I don't think the code is legal), but surely we could do better than this: $ cat zero_spread_2.f90 real,allocatable :: bar(:,:),foo(:) allocate(foo(0)) bar = spread(foo,dim=1,ncopies=1) print *, allocated(bar) end $ gfortran zero_spread_2.f90 ./a.out T Same goes for most of the transformational intrinsics. libgfortran/intrinsic/spread_generic.c says: /* The front end has signalled that we need to populate the return array descriptor. */ We should really find another way of signaling this to the library (additional argument?) so that we can perform some checking. -- Summary: SPREAD (and friends) on unallocated arrays Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: diagnostic Severity: enhancement Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: fxcoudert at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28154
[Bug libstdc++/28155] New: codecvt causes infinite loop in C locale by not returning an error status on failure
std::codecvt has in and out methods. These are used to convert from one codeset to another. They return a status: std::codecvt_base::ok || std::codecvt_base::partial on success or success where the conversion was only partially done std::codecvt_base::noconv if no conversion is necessary std::codecvt_base::error on error (e.g. a character could not be converted because it is an invalid byte sequence). When doing a conversion between char and wchar_t in UTF-8 and Latin-1 locales, this appears to behave correctly. But, when run in a C locale, and e.g. UTF-8 characters are in the input (invalid US-ASCII), it does not return an error, it returns partial or ok, but the pointers to the next character are not updated, leading to an infinite loop because the task is not completed. A testcase is attached. Try running in a UTF-8 locale, then run in a C locale to compare (or comment out the first line of main). Next, remove the UTF-8 chars from the string foo in main, and repeat (this works correctly in both UTF-8 and C locales). I think in this case codecvt is failing to correctly report an error when given invalid input. Regards, Roger -- Summary: codecvt causes infinite loop in C locale by not returning an error status on failure Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rleigh at debian dot org GCC build triplet: powerpc-linux-gnu GCC host triplet: powerpc-linux-gnu GCC target triplet: powerpc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28155
[Bug libstdc++/28155] codecvt causes infinite loop in C locale by not returning an error status on failure
--- Comment #1 from rleigh at debian dot org 2006-06-24 19:16 --- Created an attachment (id=11741) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11741action=view) Test codecvt roundtrip from narrow-wide-narrow. Testcase. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28155
[Bug libstdc++/28155] codecvt causes infinite loop in C locale by not returning an error status on failure
--- Comment #2 from rleigh at debian dot org 2006-06-24 19:21 --- Sorry, the testcase is broken. This isn't a bug. -- rleigh at debian dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28155
[Bug c++/28156] New: spurious warning: function defined but not used
Hi,
$ cat try.cc
#include iostream
static void foo() {
std::cout hello, world\n;
}
int main() {
extern void foo();
foo();
}
$ g++-4.1.0 -Wall try.cc
try.cc:3: warning: `void foo()' defined but not used
$ ./a.out
hello, world
foo() is clearly used there so why does g++ warn about it?
--
Summary: spurious warning: function defined but not used
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rwxr-xr-x at gmx dot de
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28156
[Bug c++/28156] spurious warning: function defined but not used
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-06-24 20:52 --- Fixed in 4.2.0. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Known to fail||3.0.4 4.1.0 3.2.3 2.95.3 Known to work||4.2.0 Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28156
[Bug c++/28157] New: cannot create STL iterator using template types
#include map
templateclass C, class D
int testit(const std::mapC,D m) {
std::mapC,D::const_iterator iter = m.begin();
return 0;
}
This code does not compile using G++ on cygwin
$ g++ -c utilities.cpp
utilities.cpp: In function `int testit(const std::mapC, D, std::less_Key,
std::allocatorstd::pairconst _Key, _Tp )':
utilities.cpp:6: error: expected `;' before iter
--
Summary: cannot create STL iterator using template types
Product: gcc
Version: 3.4.4
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jaybny at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28157
[Bug c++/28157] cannot create STL iterator using template types
--- Comment #1 from jaybny at gmail dot com 2006-06-24 21:22 --- $ g++ -c utilities.cpp -v Reading specs from /usr/lib/gcc/i686-pc-cygwin/3.4.4/specs Configured with: /gcc/gcc-3.4.4/gcc-3.4.4-1/configure --verbose --prefix=/usr --exec-prefix=/usr --sysconfdir=/etc --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --enable-languages=c,ada,c++,d,f77,java,objc --enable-nls --without-included-gettext --enable-version-specific-runtime-libs --without-x --enable-libgcj --disable-java-awt --with-system-zlib --enable-interpreter --disable-libgcj-debug --enable-threads=posix --enable-java-gc=boehm --disable-win32-registry --enable-sjlj-exceptions --enable-hash-synchronization --enable-libstdcxx-debug : (reconfigured) Thread model: posix gcc version 3.4.4 (cygming special) (gdc 0.12, using dmd 0.125) /usr/lib/gcc/i686-pc-cygwin/3.4.4/cc1plus.exe -quiet -v -D__CYGWIN32__ -D__CYGWIN__ -Dunix -D__unix__ -D__unix -idirafter /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api -idirafter /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/lib/../../include/w32api utilities.cpp -quiet -dumpbase utilities.cpp -mtune=pentiumpro -auxbase utilities -version -o /cygdrive/c/DOCUME~1/Jay/LOCALS~1/Temp/ccFVMJJj.s ignoring nonexistent directory /usr/local/include ignoring nonexistent directory /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/include ignoring duplicate directory /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/lib/../../include/w32api #include ... search starts here: #include ... search starts here: /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++ /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/i686-pc-cygwin /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/backward /usr/lib/gcc/i686-pc-cygwin/3.4.4/include /usr/include /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api End of search list. GNU C++ version 3.4.4 (cygming special) (gdc 0.12, using dmd 0.125) (i686-pc-cygwin) compiled by GNU C version 3.4.4 (cygming special) (gdc 0.12, using dmd 0.125). GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 utilities.cpp: In function `int testit(const std::mapC, D, std::less_Key, std::allocatorstd::pairconst _Key, _Tp )': utilities.cpp:6: error: expected `;' before iter -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28157
[Bug c++/28157] cannot create STL iterator using template types
--- Comment #2 from schwab at suse dot de 2006-06-24 21:27 --- You need to tell the compiler that std::mapC,D::const_iterator is a type by prefixing it with typename. -- schwab at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28157
[Bug target/28158] New: ICE on complex operation with -O1 -msse
The following Fortran testcase exhibits a failure with -O(=1) -msse: $ cat foo.f90 subroutine yhalf(z) complex cdexpj,z z=cdexpj((0.d0,1.d0)*z) end $ gfortran -c -O3 -msse -mfpmath=sse,387 foo.f90 foo.f90: In function yhalf: foo.f90:3: error: unrecognizable insn: (insn 13 12 14 3 (set (reg:DF 63) (neg:DF (reg:DF 62))) -1 (nil) (nil)) foo.f90:3: internal compiler error: in extract_insn, at recog.c:2077 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. $ gfortran -c -O3 -msse2 -mfpmath=sse,387 foo.f90 $ -- Summary: ICE on complex operation with -O1 -msse Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: fxcoudert at gcc dot gnu dot org GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28158
[Bug target/28158] ICE on complex operation with -O1 -msse
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-06-24 21:41 --- Confirmed. Fix: Index: config/i386/i386.md === --- config/i386/i386.md (revision 114974) +++ config/i386/i386.md (working copy) @@ -9913,7 +9913,7 @@ (define_insn *negsf2_1 (define_insn *negdf2_1 [(set (match_operand:DF 0 register_operand =f) (neg:DF (match_operand:DF 1 register_operand 0)))] - TARGET_80387 (reload_completed || !TARGET_SSE_MATH) + TARGET_80387 (reload_completed || !(TARGET_SSE2 TARGET_SSE_MATH)) fchs [(set_attr type fsgn) (set_attr mode DF)]) @@ -9937,7 +9937,7 @@ (define_insn *abssf2_1 (define_insn *absdf2_1 [(set (match_operand:DF 0 register_operand =f) (abs:DF (match_operand:DF 1 register_operand 0)))] - TARGET_80387 (reload_completed || !TARGET_SSE_MATH) + TARGET_80387 (reload_completed || !(TARGET_SSE2 TARGET_SSE_MATH)) fabs [(set_attr type fsgn) (set_attr mode DF)]) -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Keywords||ice-on-valid-code Last reconfirmed|-00-00 00:00:00 |2006-06-24 21:41:50 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28158
[Bug target/28158] ICE on complex operation with -O1 -msse
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2006-06-24 22:00 --- (In reply to comment #1) Index: config/i386/i386.md === --- config/i386/i386.md (revision 114974) +++ config/i386/i386.md (working copy) @@ -9913,7 +9913,7 @@ (define_insn *negsf2_1 (define_insn *negdf2_1 [(set (match_operand:DF 0 register_operand =f) (neg:DF (match_operand:DF 1 register_operand 0)))] - TARGET_80387 (reload_completed || !TARGET_SSE_MATH) + TARGET_80387 (reload_completed || !(TARGET_SSE2 TARGET_SSE_MATH)) fchs [(set_attr type fsgn) (set_attr mode DF)]) @@ -9937,7 +9937,7 @@ (define_insn *abssf2_1 (define_insn *absdf2_1 [(set (match_operand:DF 0 register_operand =f) (abs:DF (match_operand:DF 1 register_operand 0)))] - TARGET_80387 (reload_completed || !TARGET_SSE_MATH) + TARGET_80387 (reload_completed || !(TARGET_SSE2 TARGET_SSE_MATH)) fabs [(set_attr type fsgn) (set_attr mode DF)]) That does fix it for me. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28158
[Bug libfortran/27895] problem with SPREAD and zero-sized arrays
--- Comment #8 from fxcoudert at gcc dot gnu dot org 2006-06-24 22:16 --- (In reply to comment #3) I believe the segfault is appropriately fixed by the following patch I still think this patch is the right thing, and I've been looking through the other transformational function to see which are affected by similar bugs on zero-sized arrays. - SPREAD and CSHIFT are subject to this bug, which is easily fixed (in spread_generic.c and cshift0.c - RESHAPE and PACK are completely failing on zero-sized arrays All others, including EOSHIFT, UNPACK, TRANSPOSE, appear to work fine. Here is a bunch of testcases, now the task is to make all these work as expected: $ cat zero_cshift.f90 real :: tempn(1), tempm(1,2) real,allocatable :: foo(:),bar(:,:),gee(:,:) tempn = 2.0 tempm = 1.0 allocate(foo(0),bar(2,0),gee(0,7)) print *, cshift(foo,dim=1,shift=1) print *, cshift(tempn(2:1),dim=1,shift=1) print *, cshift(bar,shift=(/1,-1/),dim=1) print *, cshift(bar,shift=(/1,-1/),dim=2) print *, cshift(gee,shift=(/1,-1/),dim=1) print *, cshift(gee,shift=(/1,-1/),dim=2) print *, cshift(tempm(5:4,:),shift=(/1,-1/),dim=1) print *, cshift(tempm(5:4,:),shift=(/1,-1/),dim=2) print *, cshift(tempm(:,5:4),shift=(/1,-1/),dim=1) print *, cshift(tempm(:,5:4),shift=(/1,-1/),dim=2) end $ cat zero_eoshift.f90 real :: tempn(1), tempm(1,2) real,allocatable :: foo(:),bar(:,:),gee(:,:) tempn = 2.0 tempm = 1.0 allocate(foo(0),bar(2,0),gee(0,7)) print *, eoshift(foo,dim=1,shift=1) print *, eoshift(tempn(2:1),dim=1,shift=1) print *, eoshift(bar,shift=(/1,-1/),dim=1) print *, eoshift(bar,shift=(/1,-1/),dim=2) print *, eoshift(gee,shift=(/1,-1/),dim=1) print *, eoshift(gee,shift=(/1,-1/),dim=2) print *, eoshift(tempm(5:4,:),shift=(/1,-1/),dim=1) print *, eoshift(tempm(5:4,:),shift=(/1,-1/),dim=2) print *, eoshift(tempm(:,5:4),shift=(/1,-1/),dim=1) print *, eoshift(tempm(:,5:4),shift=(/1,-1/),dim=2) print *, eoshift(foo,dim=1,shift=1,boundary=42.0) print *, eoshift(tempn(2:1),dim=1,shift=1,boundary=42.0) print *, eoshift(bar,shift=(/1,-1/),dim=1,boundary=42.0) print *, eoshift(bar,shift=(/1,-1/),dim=2,boundary=42.0) print *, eoshift(gee,shift=(/1,-1/),dim=1,boundary=42.0) print *, eoshift(gee,shift=(/1,-1/),dim=2,boundary=42.0) print *, eoshift(tempm(5:4,:),shift=(/1,-1/),dim=1,boundary=42.0) print *, eoshift(tempm(5:4,:),shift=(/1,-1/),dim=2,boundary=42.0) print *, eoshift(tempm(:,5:4),shift=(/1,-1/),dim=1,boundary=42.0) print *, eoshift(tempm(:,5:4),shift=(/1,-1/),dim=2,boundary=42.0) print *, eoshift(foo,dim=1,shift=1,boundary=(/42.0,-7.0/)) print *, eoshift(tempn(2:1),dim=1,shift=1,boundary=(/42.0,-7.0/)) print *, eoshift(bar,shift=(/1,-1/),dim=1,boundary=(/42.0,-7.0/)) print *, eoshift(bar,shift=(/1,-1/),dim=2,boundary=(/42.0,-7.0/)) print *, eoshift(gee,shift=(/1,-1/),dim=1,boundary=(/42.0,-7.0/)) print *, eoshift(gee,shift=(/1,-1/),dim=2,boundary=(/42.0,-7.0/)) print *, eoshift(tempm(5:4,:),shift=(/1,-1/),dim=1,boundary=(/42.0,-7.0/)) print *, eoshift(tempm(5:4,:),shift=(/1,-1/),dim=2,boundary=(/42.0,-7.0/)) print *, eoshift(tempm(:,5:4),shift=(/1,-1/),dim=1,boundary=(/42.0,-7.0/)) print *, eoshift(tempm(:,5:4),shift=(/1,-1/),dim=2,boundary=(/42.0,-7.0/)) end $ cat zero_pack.f90 integer :: tempn(1,5) integer,allocatable :: foo(:,:) tempn = 2 allocate(foo(0,1:7)) print *, pack(foo,foo/=0) print *, pack(foo,foo/=0,(/1,3,4,5,1,0,7,9/)) print *, pack(tempn(:,-4:-5),tempn(:,-4:-5)/=0) print *, pack(tempn(:,-4:-5),tempn(:,-4:-5)/=0,(/1,3,4,5,1,0,7,9/)) print *, pack(foo,.true.) print *, pack(foo,.true.,(/1,3,4,5,1,0,7,9/)) print *, pack(tempn(:,-4:-5),.true.) print *, pack(tempn(:,-4:-5),.true.,(/1,3,4,5,1,0,7,9/)) end $ cat zero_reshape.f90 character(len=1) :: tempn(1,2) character(len=1),allocatable :: foo(:,:), bar(:,:) tempn = 'a' x = 0 allocate(foo(3,0),bar(-2:-4,7:9)) print *, reshape(tempn(-7:-8,:),(/3,3/),pad=(/'a'/)) print *, reshape(tempn(-7:-8,:),(/3,3,3/),pad=(/'a'/)) print *, reshape(tempn(-7:-8,:),(/3,3,3,3,3,3,3/),pad=(/'a'/)) ! print *, reshape(tempn(:,9:8)) ! print *, reshape(foo) ! print *, reshape(bar) end $ cat zero_spread_2.f90 real,allocatable :: bar(:,:),foo(:) allocate(foo(0)) bar = spread(foo,dim=1,ncopies=1) print *, allocated(bar) end $ cat zero_spread.f90 real :: tempn(1) real,allocatable :: foo(:) tempn = 2.0 allocate(foo(0)) print *, spread(1,dim=1,ncopies=3) print *, spread(1,dim=1,ncopies=0) print *, spread(foo,dim=1,ncopies=1) print *, spread(tempn(2:1),dim=1,ncopies=1) end $ cat zero_transpose.f90 character(len=1) :: tempn(1,2) character(len=1),allocatable :: foo(:,:), bar(:,:) tempn = 'a' allocate(foo(3,0),bar(-2:-4,7:9)) print *, transpose(tempn(-7:-8,:)) print *, transpose(tempn(:,9:8)) print *, transpose(foo) print *, transpose(bar) end $ cat zero_unpack.f90 integer :: tempn(1,5), tempv(5)
[Bug rtl-optimization/26244] [4.2 Regression] FAIL: gcc.c-torture/execute/builtin-bitops-1.c execution, -O3 -fomit-frame-pointer -funroll-loops
--- Comment #20 from dave at hiauly1 dot hia dot nrc dot ca 2006-06-24 23:08 --- Subject: Re: [4.2 Regression] FAIL: gcc.c-torture/execute/builtin-bitops-1.c execution, -O3 -fomit-frame-pointeRO The transformations in the invariant motion pass look correct to me, as well as the code immediately after it. Maybe it is a latent bug in some of the later passes, but the code produced for the shift is looong and I was not able to find where things go wrong. I totally agree ;( I think things go wrong in this snippet of code: 0x00010760 main+244: mtsar r20 0x00010764 main+248: shrpw r0,r25,sar,r4 0x00010768 main+252: ldo 1(r20),r21 0x0001076c main+256: extrw,u r4,31,1,ret1 0x00010770 main+260: bb,* r21,1a,0x10850 main+484 0x00010774 main+264: add,l r5,ret1,r20 The last instruction is one of many places where count is incremented. r25 contains the most significant 32-bits of the long long that fails (i.e., 1). The mtsar and shrpw perform a lshiftrt operation. However, the sar register is special. It only holds 5 or 6 bit shift amounts depending on instruction. In the case of shrpw, only 5 bits are used (i.e, the leftmost bit of the sar register is ignored). Thus, valid shift amounts range between 0 and 31. The first time this code is entered, r20 contains the value 32. As a result, r25 is simply copied to r4 (i.e., no shift occurs). So, count gets incremented. This bit is also counted at the beginning of the function due to extracting loop invariants and various other optimizations: 0x0001069c main+48: ldw 0(r7),r25 0x000106a0 main+52: ldw 4(r7),r26 0x000106a4 main+56: copy r25,r5 0x000106a8 main+60: ldi 3,r19 0x000106ac main+64: or r5,r26,r8 0x000106b0 main+68: depw,z r5,30,31,r31 0x000106b4 main+72: ldi 1,r20 0x000106b8 main+76: cmpb,= r6,r20,0x10800 main+404 0x000106bc main+80: extrw,u r8,31,1,r5 The long long value is loaded in the first two instructions. The leftmost 32 bits are copied to r5. Don't ask me why the left and right halves are or'ed and put in r8 because I don't know. The last instruction extracts the least significant bit from the or'ed value. This is the initial value for count. This all seems very broken to me and it doesn't happen in the non-inlined version of my_parityll. I get the same assembly code with an x86 cross built today. I looked at the documentation for lshiftrt, but it doesn't say whether the shift amount range handled by the PA insn for variable shifts is ok or not. On the otherhand, there's no obvious reason why we should need to support logical right shifts larger than 31 bits and I have to wonder why the generated code does this. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26244
[Bug c++/28159] New: [4.1/4.2 regression] ICE when building gdl with -O3
when building gdl with gcc-4.1.1 or gcc-4.2, gcc ICEs: datatypes.cpp: In constructor 'Data_ template-parameter-1-1 ::Data_(const dimension, BaseGDL::InitType) [with Sp = SpDObj]': datatypes.cpp:3545: internal compiler error: Segmentation fault gcc-4.0.3 compiles the code just fine validated on Gentoo and Debian -- Summary: [4.1/4.2 regression] ICE when building gdl with -O3 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: vapier at gentoo dot org GCC host triplet: i686-linux-gnu GCC target triplet: i686-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28159
[Bug c++/28159] [4.1/4.2 regression] ICE when building gdl with -O3
--- Comment #1 from vapier at gentoo dot org 2006-06-24 23:19 --- Created an attachment (id=11742) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11742action=view) PR28159-ice.ii -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28159
[Bug c++/28159] [4.1/4.2 regression] ICE when building gdl with -O3
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-06-24 23:53 --- *** This bug has been marked as a duplicate of 28058 *** -- 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=28159
[Bug c++/28058] [4.1/4.2 regression] ICE in inline_forbidden_p
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-06-24 23:53 --- *** Bug 28159 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||vapier at gentoo dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28058
[Bug testsuite/12096] dejagnu truncates output from spawned commands randomly, causing intermittant failed tests
--- Comment #14 from duncan_roe at acslink dot net dot au 2006-06-25 05:31 --- This problem is still displayed at gcc-4.1.1 using expect 5.43 and tcl 8.4.13. The patch above requires that one uses patch's --ignore-whitespace option because tab/space information is no longer present. See bug 28137. -- duncan_roe at acslink dot net dot au changed: What|Removed |Added CC||duncan_roe at acslink dot ||net dot au http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12096
[Bug target/28137] make check gets 10 FAIL reports with gcc.dg/c99-typespec-1.c
--- Comment #4 from duncan_roe at acslink dot net dot au 2006-06-25 05:53
---
HJ's patch can still be applied to expect-5.43 (but I wasted some time before I
realised you must use --ignore-whitespace). This *does* reduce the number of
errors reported, but one error remains:
FAIL: gcc.dg/visibility-11.c scan-assembler [EMAIL PROTECTED]
Also make check seemed to test more things when I changed ARCH from amd64 to
x86_64. So now the config line is:
ARCH=x86_64
SRC=/usr/src/gcc-4.1.1
ARCH=${ARCH:-i486}
TARGET=${TARGET:-$ARCH-pc-linux-gnu}
$SRC/configure \
--prefix=/usr/local64/gcc402 \
--enable-shared \
--enable-threads=posix \
--enable-__cxa_atexit \
--disable-checking \
--with-gnu-ld \
--target=${TARGET} \
--host=${TARGET} \
--build=${TARGET}
I guess amd64 should not be used then?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28137
