[Bug target/26879] LibJava not compile under alpha
--- Comment #6 from zerocool at modemsoft dot it 2006-03-30 08:19 --- > Now run "debugx jc1 ", where "" > was the entire command noted earlier that causes the failure. Before i reproduce the error, after i make the command : debugx jcl /gcc-929a0346fb3027265ab1a9f2683e27c6/gcc-4.1-20060324/libjava/classpath/gnu/CORBA/CDR/gnuRuntime.java answer : debugx: command not found maybe that not find jcl command? How i can to resolve it? Thanks for help -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26879
[Bug tree-optimization/26797] [4.2 Regression] ACATS c35507m cd2a23e cxh1001 failures
--- Comment #11 from ebotcazou at gcc dot gnu dot org 2006-03-30 08:25 --- > I think it's a front-end problem and the argument of c35507m__charRP should be > in the base type. Humpf... Freeze_Enumeration_Type has this big comment: -- Now we build the function that converts representation values to -- position values. This function has the form: --function _Rep_To_Pos (A : etype; F : Boolean) return Integer is --begin -- case ityp!(A) is -- when enum-lit'Enum_Rep => return posval; -- when enum-lit'Enum_Rep => return posval; -- ... -- when others => -- [raise Constraint_Error when F "invalid data"] -- return -1; -- end case; --end; -- Note: the F parameter determines whether the others case (no valid -- representation) raises Constraint_Error or returns a unique value -- of minus one. The latter case is used, e.g. in 'Valid code. -- Note: the reason we use Enum_Rep values in the case here is to avoid -- the code generator making inappropriate assumptions about the range -- of the values in the case where the value is invalid. ityp is a -- signed or unsigned integer type of appropriate width. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26797
[Bug tree-optimization/26797] [4.2 Regression] ACATS c35507m cd2a23e cxh1001 failures
--- Comment #12 from ebotcazou at gcc dot gnu dot org 2006-03-30 08:32 --- So, in the end, the problem seems to be equivalent to the 'Valid stuff. Richard, I know Robert and you have come up with a plan to address the 'Valid problem. Is there an implementation sketch available somewhere? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26797
[Bug tree-optimization/26919] [4.1/4.2 regression] ICE in cgraph_estimate_size_after_inlining caused by boost::lambda
--- Comment #8 from rguenth at gcc dot gnu dot org 2006-03-30 09:01 --- It looks like we got a mismatch between the fndecls number of arguments and the call site number of arguments, so we calculate the wrong saving of instruction numbers. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||hubicka at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26919
[Bug middle-end/26900] Number of iterations not know for simple loop
--- Comment #9 from patchapp at dberlin dot org 2006-03-30 09:15 --- Subject: Bug number PR26900 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-03/msg01736.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26900
[Bug tree-optimization/26830] [4.1/4.2 Regression] Insane amount of compile-time / memory needed at -O1 and above
--- Comment #20 from bonzini at gnu dot org 2006-03-30 09:17 --- Trying a naive patch that moves update_ssa from tree_duplicate_sese_region to after all loop headers are copied... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26830
[Bug bootstrap/26936] fix-header segfault with glibc-2.4 header
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-03-30 09:45 --- I believe this has been fixed for the mainline with 2006-02-25 Juergen Weigert <[EMAIL PROTECTED]> Richard Guenther <[EMAIL PROTECTED]> * scan-decls.c (scan_decls): Don't fetch new statement after CPP_EOF. it's not a regression though. -- 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 Known to fail||4.1.0 Known to work||4.2.0 Last reconfirmed|-00-00 00:00:00 |2006-03-30 09:45:20 date|| Target Milestone|--- |4.1.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26936
[Bug c++/26938] New: [4.0/4.1/4.2 regression] ICE with wrong number of template parameters
The following invalid testcase causes an ICE since GCC 3.1:
template struct A;
template struct A
{
A();
};
A<0> a;
bug.cc:1: error: previous declaration 'template, int
> struct A'
bug.cc:3: error: used 2 template parameter(s) instead of 1
bug.cc: In constructor 'A<, >::A() [with int
= 0]':
bug.cc:8: instantiated from here
bug.cc:5: internal compiler error: tree check: accessed elt 2 of tree_vec with
1 elts in tsubst, at cp/pt.c:7080
Please submit a full bug report, [etc.]
--
Summary: [4.0/4.1/4.2 regression] ICE with wrong number of
template parameters
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26938
[Bug tree-optimization/26939] New: PRE confuses loop number of iterations analysis
/* { dg-do compile } */
/* { dg-options "-O2 -fdump-tree-sccp-details" } */
void bar(int);
void foo(int i1, int j1)
{
int i, j;
for (j=0; j<=j1; ++j)
for (i=0; i<=i1; ++i)
bar(j+1);
}
/* { dg-final { scan-tree-dump-not "set_nb_iterations_in_loop = scev_not_known"
"sccp"} } */
/* { dg-final { cleanup-tree-dump "sccp" } } */
Compare to using j-1 in the inner loop, which makes # iterations analysis
succeed.
--
Summary: PRE confuses loop number of iterations analysis
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26939
[Bug tree-optimization/26919] [4.1/4.2 regression] ICE in cgraph_estimate_size_after_inlining caused by boost::lambda
--- Comment #9 from reichelt at gcc dot gnu dot org 2006-03-30 11:13
---
Even shorter testcase:
If I remove an argument of the constructor, the code compiles fine.
struct A
{
A() {}
};
struct B
{
A a;
B(A, int, int, int, int, int, int, int, int, int,
int, int, int, int, int, int, int, int, int, int) {}
};
void foo()
{
B b(A(), 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0);
}
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||monitored
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26919
[Bug c++/26940] New: C++ name space issue
The following test case fails to compile with all compiler from 4.x series. (I
didn't check with any earlier version.) Comeaue's test drive compiler does not
complain.
Changing the declaration of "a" in "struct b" into "struct a a;" makes it
compile.
8<---8<---8<---8<---
struct a {
};
struct b {
a a;
};
8<---8<---8<---8<---
The error:
ville.cxx:5: error: declaration of 'a b::a'
ville.cxx:1: error: changes meaning of 'a' from 'struct a'
--
Summary: C++ name space issue
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: v dot haisman at sh dot cvut dot cz
GCC build triplet: *-*-*
GCC host triplet: *-*-*
GCC target triplet: *-*-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26940
[Bug bootstrap/26936] fix-header segfault with glibc-2.4 header
--- Comment #2 from sugioka at itonet dot co dot jp 2006-03-30 11:50 --- Thanks for the information. I have confirmed that this is fixed on mainline. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26936
[Bug tree-optimization/26797] [4.2 Regression] ACATS c35507m cd2a23e cxh1001 failures
--- Comment #13 from kenner at vlsi1 dot ultra dot nyu dot edu 2006-03-30 12:13 --- Subject: Re: [4.2 Regression] ACATS c35507m cd2a23e cxh1001 failures Richard, I know Robert and you have come up with a plan to address the 'Valid problem. Is there an implementation sketch available somewhere? No, because it's just a matter of having the unchecked conversion converted to a VIEW_CONVERT_EXPR. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26797
[Bug tree-optimization/26939] PRE confuses loop number of iterations analysis
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-03-30 12:22 ---
Note this testcase requires the fix(es) for PR26900 to figure out the number of
iterations for the inner loop. The failure to figure out the number of
iterations of the outer loop can be reproduced with mainline. Basically we
have (in the working case with using j-1):
foo (i1, j1)
{
int pretmp.20;
int j;
int i;
int D.1534;
:
if (j1_4 >= 0) goto ; else goto ;
:;
goto ();
:;
# i_14 = PHI ;
:;
D.1534_8 = pretmp.20_10;
bar (pretmp.20_10);
i_9 = i_14 + 1;
if (i1_6 >= i_9) goto ; else goto ;
:;
j_7 = j_12 + 1;
if (j1_4 >= j_7) goto ; else goto ;
:;
# j_12 = PHI ;
:;
if (i1_6 >= 0) goto ; else goto ;
:;
pretmp.20_10 = j_12 - 1;
goto ();
:;
return;
}
while with using j+1 we get
foo (i1, j1)
{
int prephitmp.21;
int pretmp.20;
int j;
int i;
int D.1534;
:
if (j1_4 >= 0) goto ; else goto ;
:;
goto ();
:;
# i_14 = PHI ;
:;
D.1534_8 = pretmp.20_13;
bar (pretmp.20_13);
i_9 = i_14 + 1;
if (i1_6 >= i_9) goto ; else goto ;
# D.1534_2 = PHI ;
:;
# prephitmp.21_11 = PHI ;
:;
j_7 = prephitmp.21_11;
if (j1_4 >= prephitmp.21_11) goto ; else goto ;
:;
# j_12 = PHI ;
:;
if (i1_6 >= 0) goto ; else goto ;
:;
pretmp.20_1 = j_12 + 1;
goto ();
:;
pretmp.20_13 = j_12 + 1;
goto ();
:;
return;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26939
[Bug tree-optimization/26939] PRE confuses loop number of iterations analysis
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-03-30 12:31 --- You can see that PRE makes a mess out of it because of the copied loop header of the inner loop. So maybe Zdeneks patch to move the loop header copy outside of the first loop helps here. Though I'd prefer to prevent PRE from doing the transformation here. Danny, any ideas? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26939
[Bug tree-optimization/26909] [4.2 Regression] ICE compiling GLIB with gcc 4.2-20060325
--- Comment #3 from reichelt at gcc dot gnu dot org 2006-03-30 13:02
---
Reduced testcase (fails with "-O2 -m32" on x86_64-unknown-linux-gnu):
===
typedef struct { int i; } A;
typedef struct { int i; } B;
int M;
void foo(A* p)
{
B *q;
int i, j, N;
if (M) bar();
if (p->i > 0) j = 1; else j = 0;
q = __builtin_expect (__extension__ ({ j; }), 1) ? (B*)p : (B*)0;
N = p->i;
bar();
for (i = 0; i < N; i++)
q[i].i=0;
bar();
}
===
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
CC||reichelt at gcc dot gnu dot
||org
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Keywords||monitored
Last reconfirmed|-00-00 00:00:00 |2006-03-30 13:02:40
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26909
[Bug target/26879] LibJava not compile under alpha
--- Comment #7 from rmathew at gcc dot gnu dot org 2006-03-30 13:07 --- (In reply to comment #6) > > Now run "debugx jc1 ", where "" > > was the entire command noted earlier that causes the failure. > Before i reproduce the error, after i make the command : > > debugx jcl > /gcc-929a0346fb3027265ab1a9f2683e27c6/gcc-4.1-20060324/libjava/classpath/gnu/CORBA/CDR/gnuRuntime.java > > > answer : debugx: command not found Put *both* of 'debugx' and 'debug' in a folder in your PATH and make sure they have execute permission. For example, you can put these in your "$HOME/bin" folder and then add this folder to your PATH variable. It is not strictly necessary, but you might also want to define the environment variable "DEBUG" to point to your debugger of choice, normally, gdb. The command-line you have pasted seems incomplete. As I noted earlier, make sure that you have the entire command-line from the build log and that you can reproduce the error on the command-line before trying to run "debugx jc1" on it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26879
[Bug c/26941] New: float optimization bug
[EMAIL PROTECTED] tmp]# cat a.c
#include
float Q_rsqrt(float number)
{
long i;
float x2, y;
float threehalfs = 1.5f;
x2 = number * 0.5f;
y = number;
i = *(long *)&y;
i = 0x5f3759df-(i>>1);
y = *(float *)&i;
y = y * (threehalfs -(x2 *y *y));
y = y *(threehalfs - (x2 *y *y));
return y;
}
int main()
{
printf("%f\n", Q_rsqrt(305.0f));
return 0;
}
[EMAIL PROTECTED] tmp]# gcc a.c
[EMAIL PROTECTED] tmp]# ./a.out
0.057260
[EMAIL PROTECTED] tmp]# gcc -O2 a.c
[EMAIL PROTECTED] tmp]# ./a.out
0.00
[EMAIL PROTECTED] tmp]# gcc -v
Using built-in specs.
Target: i386-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--enable-checking
=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-libgcj-multifile
--enable-languages=c,c++,objc,obj-c++,java,
fortran,ada --enable-java-awt=gtk --disable-dssi
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --with-cpu=generic
--host=i386-redhat-linux
Thread model: posix
gcc version 4.1.0 20060304 (Red Hat 4.1.0-3)
--
Summary: float optimization bug
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: zengpan at goldhuman dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26941
[Bug tree-optimization/26939] PRE confuses loop number of iterations analysis
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-03-30 13:34 --- Created an attachment (id=11164) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11164&action=view) candidate patch The attached patch is maybe a fix - though a better way to detect what could be a loop header copy is appreciated ;) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26939
[Bug fortran/21130] 38822 lines of Fortran 90 takes more than 10 minutes to compile on a dual 3GHz P4 Linux box with lots of RAM
--- Comment #9 from bdavis at gcc dot gnu dot org 2006-03-30 13:52 --- after the above patch, here is a profile of the last file (that takes so long to compile): Each sample counts as 0.01 seconds. % cumulative self self total time seconds secondscalls s/call s/call name 15.52 19.0419.04 60138476 0.00 0.00 parse_atom 9.33 30.4811.44 239125668 0.00 0.00 module_char 5.22 36.88 6.40 89284617 0.00 0.00 compare_integers 4.60 42.52 5.64 ht_lookup_with_hash 4.22 47.70 5.18 2224328 0.00 0.00 insert 3.56 52.07 4.37 622 0.01 0.07 load_needed 2.96 55.70 3.63 5543817 0.00 0.00 get_integer 2.63 58.93 3.23 4035787 0.00 0.00 check_interface0 2.32 61.78 2.85 312 0.01 0.03 read_cleanup 2.31 64.61 2.83 74319506 0.00 0.00 get_module_locus 2.28 67.41 2.80 21727690 0.00 0.00 set_module_locus 1.77 69.58 2.17 25323260 0.00 0.00 require_atom 1.59 71.53 1.95 4464297 0.00 0.00 clear_sym_mark 1.57 73.45 1.92 720088 0.00 0.00 count_types_test 1.56 75.36 1.91 13155211 0.00 0.00 compare_true_names 1.50 77.20 1.84 948414 0.00 0.00 traverse_ns 1.37 78.88 1.68 5424920 0.00 0.00 compare_type_rank 1.37 80.56 1.68 5424108 0.00 0.00 compare_type_rank_if --bud -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21130
[Bug fortran/21130] 38822 lines of Fortran 90 takes more than 10 minutes to compile on a dual 3GHz P4 Linux box with lots of RAM
--- Comment #10 from bdavis at gcc dot gnu dot org 2006-03-30 13:58 --- with the same patch, the aermod.f90 : Each sample counts as 0.01 seconds. % cumulative self self total time seconds secondscalls s/call s/call name 7.69 8.80 8.80 29723933 0.00 0.00 parse_atom 5.26 14.82 6.02 125084260 0.00 0.00 module_char 3.51 18.83 4.01 record_reg_classes 2.83 22.07 3.24 find_reloads 2.19 24.58 2.51 walk_tree 1.85 26.70 2.12 2331175 0.00 0.00 gt_ggc_mx_lang_tree_node 1.77 28.73 2.03 ht_lookup_with_hash 1.72 30.70 1.97 ggc_set_mark 1.48 32.39 1.69 ggc_alloc_stat 1.37 33.96 1.57 10696036 0.00 0.00 set_module_locus 1.27 35.41 1.45 13353395 0.00 0.00 require_atom 1.14 36.71 1.30 722236 0.00 0.00 gfc_match_strings 1.12 37.99 1.28 817282 0.00 0.00 insert 1.12 39.27 1.28 constrain_operands 1.08 40.50 1.23 31922526 0.00 0.00 get_module_locus 1.03 41.68 1.18 3220 0.00 0.00 traverse_ns 0.94 42.76 1.08 706 0.00 0.02 load_needed --bud -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21130
[Bug tree-optimization/26939] PRE confuses loop number of iterations analysis
--- Comment #4 from dberlin at gcc dot gnu dot org 2006-03-30 14:04 --- (In reply to comment #2) > You can see that PRE makes a mess out of it because of the copied loop header > of the inner loop. So maybe Zdeneks patch to move the loop header copy > outside > of the first loop helps here. Though I'd prefer to prevent PRE from doing the > transformation here. Danny, any ideas? > Errr, why can't we just improve SCEV to handle this case if we can detect it? :) Either that, or stop mucking up the inner loop in the first place by copying it's header (which, BTW, also screws up other transformations). Zdenek has said that loop header copying is there, in part, to increase the effectiveness of code motion. This is the increased code motion you get :). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26939
[Bug tree-optimization/26830] [4.1/4.2 Regression] Insane amount of compile-time / memory needed at -O1 and above
--- Comment #21 from bonzini at gnu dot org 2006-03-30 14:04 --- Patch bootstrapped, regtesting in progress. With checking enabled I have this which is not bad at all. tree PHI insertion: 49.68 ( 5%) tree SSA rewrite : 63.75 ( 7%) tree SSA incremental : 4.75 ( 1%) dominator optimization: 12.66 ( 1%) tree loop init: 6.25 ( 1%) tree SSA uncprop : 7.68 ( 1%) tree SSA verifier : 214.56 (24%) tree STMT verifier: 197.87 (22%) expand: 21.19 ( 2%) loop analysis : 10.96 ( 1%) global alloc : 276.20 (30%) <-- i think this is due to ENABLE_CHECKING We still consume more than a GB of memory though. -- bonzini at gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |bonzini at gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2006-03-24 14:16:42 |2006-03-30 14:04:12 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26830
[Bug fortran/21130] 38822 lines of Fortran 90 takes more than 10 minutes to compile on a dual 3GHz P4 Linux box with lots of RAM
--- Comment #11 from bdavis at gcc dot gnu dot org 2006-03-30 14:04 --- if this patch gets accepted, i vote to close the PR. we are still slower than we should be, but it is now linear and compiles in a 'reasonable time'. --bud -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21130
[Bug libgcj/26858] NullPointerException not generated for large classes...
-- aph at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |aph at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-03-30 14:24:24 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26858
[Bug libgcj/26858] NullPointerException not generated for large classes...
--- Comment #5 from aph at gcc dot gnu dot org 2006-03-30 14:24 --- I'm testing a patch for this. -- aph at gcc dot gnu dot org changed: What|Removed |Added CC||aph at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26858
[Bug tree-optimization/26830] [4.1/4.2 Regression] Insane amount of compile-time / memory needed at -O1 and above
--- Comment #22 from bonzini at gnu dot org 2006-03-30 14:31 --- Subject: Bug 26830 Author: bonzini Date: Thu Mar 30 14:31:13 2006 New Revision: 112534 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112534 Log: 2006-03-30 Paolo Bonzini <[EMAIL PROTECTED]> PR tree-optimization/26830 * tree-ssa-copy.c (copy_prop_visit_assignment): Do not check loop depth. (copy_prop_visit_stmt): Remove write-only variable ann. (init_copy_prop): Check variable loop depth here. Do not simulate memory-tag and virtual operand PHIs except for store copy prop. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-copy.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26830
[Bug tree-optimization/26939] PRE confuses loop number of iterations analysis
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-03-30 14:37 --- Loop header copying for the inner loop is required for # of iterations analysis - though we should move that header copy out of the outer loop, too, if possible. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26939
[Bug rtl-optimization/26942] New: Code generation bug (-fprofile-use)
I've found this bug while building gcc 4.1.0 (on GNU/Linux x86). In the
'rebuild with -fprofile-use' stage I get the following error:
stage1/xgcc -Bstage1/ -B/usr/i386-unknown-linux-gnu/bin/ -c -O2 -g
-fomit-frame-pointer -fprofile-use -freorder-blocks-and-partition -DIN_GCC -W
-Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic
-Wno-long-long -Wno-variadic-macros -Wold-style-definition
-Wmissing-format-attribute -DHAVE_CONFIG_H -I. -I. -I../../gcc -I../../gcc/.
-I../../gcc/../include -I../../gcc/../libcpp/include ../../gcc/attribs.c -o
attribs.o
/tmp/cc9Aywrx.s: Assembler messages:
/tmp/cc9Aywrx.s:1256: Error: can't resolve `.text.unlikely' {.text.unlikely
section} - `.LCFI70' {.text section}
the line 1256 in the generated assembler output reads:
.long .LCFI71-.LCFI70
but the symbol .LCFI71 is in the .text.unlikely section while .LCFI70 is in
.text.
--
Summary: Code generation bug (-fprofile-use)
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: clifford at clifford dot at
GCC build triplet: i386-unknown-linux-gnu
GCC host triplet: i386-unknown-linux-gnu
GCC target triplet: i386-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26942
[Bug rtl-optimization/26942] Code generation bug (-fprofile-use)
--- Comment #1 from clifford at clifford dot at 2006-03-30 14:43 --- Created an attachment (id=11165) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11165&action=view) Testcase This are the prerpocessed C input file, the .gcda and .gcno files (for -fprofile-use) and a little shell script containing the gcc options I was using. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26942
[Bug tree-optimization/26939] PRE confuses loop number of iterations analysis
--- Comment #6 from dberlin at gcc dot gnu dot org 2006-03-30 14:43 --- Subject: Re: PRE confuses loop number of iterations analysis On Thu, 2006-03-30 at 14:37 +, rguenth at gcc dot gnu dot org wrote: > > --- Comment #5 from rguenth at gcc dot gnu dot org 2006-03-30 14:37 > --- > Loop header copying for the inner loop is required for # of iterations > analysis > - though we should move that header copy out of the outer loop, too, if > possible. Again, you should spend your time improving SCEV, or improving the # of iterations analysis. Really. You are saying "we want to copy loop headers, but don't want PRE to take advantage of the copied loop headers". If we can copy the loop header and prove that we iterate at least once (or whatever condition this proves for # of iterations analysis), you should be able to do it without copying the loop header as well. Though, it's probably just better to teach SCEV to deal with the code that PRE has made, since improving SCEV improves a lot of things. > > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26939
[Bug c/26941] float optimization bug
--- Comment #1 from reichelt at gcc dot gnu dot org 2006-03-30 14:56 --- You code violates the aliasing rules in this line: y = *(float *)&i; Please read http://gcc.gnu.org/bugs.html In the non-bug section you will find: "Casting does not work as expected when optimization is turned on." *** This bug has been marked as a duplicate of 21920 *** -- reichelt at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26941
[Bug c/21920] alias violating
--- Comment #89 from reichelt at gcc dot gnu dot org 2006-03-30 14:56 --- *** Bug 26941 has been marked as a duplicate of this bug. *** -- reichelt at gcc dot gnu dot org changed: What|Removed |Added CC||zengpan at goldhuman dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21920
[Bug libstdc++/20448] locale testsuite fails when GCC is configured with --disable-nls
--- Comment #6 from pcarlini at suse dot de 2006-03-30 15:06 --- Fixed. -- pcarlini at suse dot de changed: What|Removed |Added Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20448
[Bug libstdc++/20448] locale testsuite fails when GCC is configured with --disable-nls
--- Comment #7 from pcarlini at suse dot de 2006-03-30 15:07 --- Fixed. -- pcarlini at suse dot de changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20448
[Bug libstdc++/20451] Missing po files in multilib systems
--- Comment #3 from pcarlini at suse dot de 2006-03-30 15:08 --- Fixed. -- pcarlini at suse dot de changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20451
[Bug tree-optimization/26939] PRE confuses loop number of iterations analysis
--- Comment #7 from rguenth at gcc dot gnu dot org 2006-03-30 15:11 --- You are probably right about improving SCEV - I hope Sebastian can make it work for this and similar cases. Wrt the loop header it is that we convert the loop to a do-while style loop, which at least iterates once, but to make this transformation valid, we need to copy the loop header. The "bug" is of course that we later try to prove again that this is a do-while style loop, which we could better have remembered somehow. I.e. for (i = start; i < end; ++i) ; iterates end-start times, if start <= end. So we transform it to if (start < end) for (i = start; i < end; ++i) ; and later we "prove" that this new loop runs at least once by taking the loop exit condition and trying to simplify that based on dominating conditions from the loop header. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26939
[Bug rtl-optimization/26725] [4.2 Regression] ICE in check_reg_live, at haifa-sched.c:4645 with -O2 on ia64
-- mkuvyrkov at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |mkuvyrkov at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-03-22 04:16:48 |2006-03-30 15:11:46 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26725
[Bug libstdc++/24538] --enable-shared not supported
--- Comment #3 from pcarlini at suse dot de 2006-03-30 15:12 --- Feedback not forthcoming. -- pcarlini at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24538
[Bug tree-optimization/26939] PRE confuses loop number of iterations analysis
--- Comment #8 from rguenth at gcc dot gnu dot org 2006-03-30 15:29 --- Just for the record, the attached patch bootstrapped and regtested on x86_64-unknown-linux-gnu, with the following fallout: FAIL: gcc.dg/tree-ssa/loadpre4.c scan-tree-dump-times Eliminated: 1 1 FAIL: gcc.dg/tree-ssa/loadpre6.c scan-tree-dump-times Eliminated: 2 1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26939
[Bug target/26734] [4.2 Regression] GCC cannot bootstrap on IA64 HP-UX
--- Comment #11 from mkuvyrkov at gcc dot gnu dot org 2006-03-30 15:41 --- Subject: Bug 26734 Author: mkuvyrkov Date: Thu Mar 30 15:41:00 2006 New Revision: 112538 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112538 Log: 2006-03-30 Maxim Kuvyrkov <[EMAIL PROTECTED]> PR target/26734 * rtl.def (DEPS_LIST): Change type of the second operand to 'int'. * target.h (struct gcc_target.speculate_insn): Change type of the second parameter to 'int'. * lists.c (alloc_DEPS_LIST): Change signature. Update reference to the second operand of the DEPS_LIST. (copy_DEPS_LIST_list): Update reference to the second operand of the DEPS_LIST. * rtl.h (alloc_DEPS_LIST): Update signature. * sched-int.h (ds_t): Change typedef to 'int'. (DEP_STATUS, BITS_PER_DEP_STATUS): Update. Modified: trunk/gcc/ChangeLog trunk/gcc/lists.c trunk/gcc/rtl.def trunk/gcc/rtl.h trunk/gcc/sched-int.h trunk/gcc/target.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26734
[Bug target/26734] [4.2 Regression] GCC cannot bootstrap on IA64 HP-UX
--- Comment #12 from mkuvyrkov at gcc dot gnu dot org 2006-03-30 15:43 --- The patch was reapplied: http://gcc.gnu.org/ml/gcc-patches/2006-03/msg01721.html -- mkuvyrkov at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26734
[Bug libgcj/13212] JNI/CNI AttachCurrentThread does not register thread with garbage collector
--- Comment #31 from rguenth at gcc dot gnu dot org 2006-03-30 15:48 --- How did you test the patch with OpenOffice? Are there OpenOffice modifications necessary? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13212
[Bug tree-optimization/26830] [4.1/4.2 Regression] Insane amount of compile-time / memory needed at -O1 and above
--- Comment #23 from rguenth at gcc dot gnu dot org 2006-03-30 15:49 --- Note that the regression is in 4.1, too, so we should consider backporting changes that accumulate here to the branch after a while. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26830
[Bug libgcj/13212] JNI/CNI AttachCurrentThread does not register thread with garbage collector
--- Comment #32 from mckinlay at redhat dot com 2006-03-30 15:51 --- (In reply to comment #31) Yes, this patch should fix all the OpenOffice issues. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13212
[Bug c++/26943] New: [gomp] firstprivate not working properly with non-POD
Two problems here. The first was trying to show that we don't necessarily honor the requirement that all firstprivate copies are executed before the lastprivate assignment happens. The second is that we're not properly substituting for the global X here within the scope of the privatization. -- Summary: [gomp] firstprivate not working properly with non-POD Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: wrong-code, openmp Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rth at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26943
[Bug c++/26943] [gomp] firstprivate not working properly with non-POD
--- Comment #1 from rth at gcc dot gnu dot org 2006-03-30 15:56 --- Created an attachment (id=11166) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11166&action=view) test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26943
[Bug tree-optimization/26944] New: -ftree-ch generates worse code
The loop from the code below is compiled to this when using gcc-4.1 -O2
.L5:
movl16(%ebp), %eax
addl%ecx, %eax
addl$1, %ecx
movl%edx, 20(%ebx,%eax,4)
leal(%edx,%ecx), %eax
cmpl%edi, %eax
jle .L5
but the code is much better when using gcc -fno-tree-ch -O2
.L3:
addl$1, %ecx
movl%ebx, -4(%edx)
addl$4, %edx
cmpl%eax, %ecx
jle .L3
This is a regression as gcc-3.4.3 generates similar code.
The code is from the Dhrystone as included in Unixbench.
The regression is quite important as embedded processor people still use
Dhrystone for benchmarking compiler/processor speed.
Its strange that tree-ch messes up, the loop is about as simple as loops can
get.
typedef int One_Fifty;
typedef int Arr_1_Dim [50];
typedef int Arr_2_Dim [50] [50];
extern int Int_Glob;
void Proc_8 (Arr_1_Par_Ref, Arr_2_Par_Ref, Int_1_Par_Val, Int_2_Par_Val)
Arr_1_Dim Arr_1_Par_Ref;
Arr_2_Dim Arr_2_Par_Ref;
int Int_1_Par_Val;
int Int_2_Par_Val;
{
register One_Fifty Int_Index;
register One_Fifty Int_Loc;
Int_Loc = Int_1_Par_Val + 5;
Arr_1_Par_Ref [Int_Loc] = Int_2_Par_Val;
Arr_1_Par_Ref [Int_Loc+1] = Arr_1_Par_Ref [Int_Loc];
Arr_1_Par_Ref [Int_Loc+30] = Int_Loc;
for (Int_Index = Int_Loc; Int_Index <= Int_Loc+1; ++Int_Index)
Arr_2_Par_Ref [Int_Loc] [Int_Index] = Int_Loc;
Arr_2_Par_Ref [Int_Loc] [Int_Loc-1] += 1;
Arr_2_Par_Ref [Int_Loc+20] [Int_Loc] = Arr_1_Par_Ref [Int_Loc];
Int_Glob = 5;
}
Intel's compiler generates even tighter code:
..B1.7: # Preds ..B1.10 ..B1.7
movl %ebx, (%ecx,%edx,4) #20.5
addl $1, %edx #19.55
cmpl %eax, %edx#19.3
jle ..B1.7# Prob 80% #19.3
--
Summary: -ftree-ch generates worse code
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dann at godzilla dot ics dot uci dot edu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26944
[Bug libfortran/26712] gfortran on mac intel runtime floating point exception when printing
--- Comment #8 from schnetter at aei dot mpg dot de 2006-03-30 16:18 --- I had the same problem. I replaced this file, ran the test cases, and sent the results. The summary is === gfortran Summary === # of expected passes12636 # of unexpected failures1 # of expected failures 7 # of unsupported tests 46 /Users/eschnett/src/gcc-build/gcc/testsuite/gfortran/../../gfortran version 4.2 .0 20060329 (experimental) with the unexpected failure FAIL: gfortran.dg/assign_2.f90 -O0 (test for excess errors) WARNING: gfortran.dg/assign_2.f90 -O0 compilation failed to produce executable which seems unrelated to me after looking at the source code and error message of that file. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26712
[Bug tree-optimization/26944] [4.1/4.2 Regression] -ftree-ch generates worse code
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-03-30 16:25 --- Note that this may be also PRE confusing SCEV in presence of loop headers. I.e. a sort of dup of PR26939. Confirmed though. A regression from 4.0.3, which is also fine. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||26939 Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC target triplet|i686-pc-linux-gnu | Keywords||missed-optimization Known to work||4.0.3 Last reconfirmed|-00-00 00:00:00 |2006-03-30 16:25:17 date|| Summary|-ftree-ch generates worse |[4.1/4.2 Regression] -ftree- |code|ch generates worse code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26944
[Bug rtl-optimization/26945] New: [3.4/4.0/4.1 regression] Attempt to delete prologue/epilogue insn
Compile attached test case with optimization causes an ICE: $ gcc -c -O1 bug.c bug.c: In function 'parsearguments': bug.c:46: error: Attempt to delete prologue/epilogue insn: (insn/f 97 96 98 0 (set (mem:SI (plus:SI (reg/f:SI 30 %r30) (const_int -124 [0xff84])) [0 S4 A32]) (reg:SI 4 %r4)) -1 (nil) (nil)) bug.c:46: internal compiler error: in propagate_one_insn, at flow.c:1690 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. For Debian GNU/Linux specific bug reporting instructions, see . This may be related to PR12535 but the code that triggers the problem is different. -- Summary: [3.4/4.0/4.1 regression] Attempt to delete prologue/epilogue insn Product: gcc Version: 4.0.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tausq at debian dot org GCC build triplet: hppa-unknown-linux GCC host triplet: hppa-unknown-linux GCC target triplet: hppa-unknown-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26945
[Bug rtl-optimization/26945] [3.4/4.0/4.1 regression] Attempt to delete prologue/epilogue insn
--- Comment #1 from tausq at debian dot org 2006-03-30 16:28 --- Created an attachment (id=11167) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11167&action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26945
[Bug fortran/25031] Allocatable array can be reallocated.
--- Comment #5 from tkoenig at gcc dot gnu dot org 2006-03-30 16:30 --- Subject: Bug 25031 Author: tkoenig Date: Thu Mar 30 16:30:26 2006 New Revision: 112539 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112539 Log: 2006-03-30 Thomas Koenig <[EMAIL PROTECTED]> PR fortran/25031 * runtime/memory.c (allocate_array): If stat is present and the variable is already allocated, free the variable, do the allocation and set stat. (allocate_array_64): Likewise. Whitespace fix. 2006-03-30 Thomas Koenig <[EMAIL PROTECTED]> PR fortran/25031 * gfortran.dg/multiple_allocation_1.f90: Check that the size has changed after a re-allocation with stat. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/multiple_allocation_1.f90 trunk/libgfortran/ChangeLog trunk/libgfortran/runtime/memory.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25031
[Bug rtl-optimization/26945] [3.4/4.0/4.1 regression] Attempt to delete prologue/epilogue insn
--- Comment #2 from tausq at debian dot org 2006-03-30 16:31 --- The code is valid syntactically, but there is actually a bug. the longoptions array only has 3 elements, but we try to fill in 4 entries. if we make the longoptions array bigger than it doesn't cause the ICE. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26945
[Bug java/26042] ICE in mark_reference_fields, at java/boehm.c:105
--- Comment #10 from tromey at gcc dot gnu dot org 2006-03-30 16:39 --- Subject: Bug 26042 Author: tromey Date: Thu Mar 30 16:39:17 2006 New Revision: 112540 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112540 Log: gcc/java PR java/26042: * parse.y (java_reorder_fields): Reset superclass field's size as well. libjava PR java/26042: * testsuite/libjava.compile/pr26042.java: New file. Added: trunk/libjava/testsuite/libjava.compile/pr26042.java Modified: trunk/gcc/java/ChangeLog trunk/gcc/java/parse.y trunk/libjava/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26042
[Bug tree-optimization/26944] [4.1/4.2 Regression] -ftree-ch generates worse code
--- Comment #2 from dann at godzilla dot ics dot uci dot edu 2006-03-30 16:43 --- (In reply to comment #1) > Note that this may be also PRE confusing SCEV in presence of loop headers. Talking about PRE, here's a maybe interesting observation in the PRE dump: :; pretmp.30_53 = Int_Loc.0_4 * 200; pretmp.32_23 = (int[50] *) pretmp.30_53; pretmp.32_11 = pretmp.32_23 + Arr_2_Par_Ref_30; goto (); :; pretmp.27_59 = Int_Loc.0_4 * 200; pretmp.28_45 = (int[50] *) pretmp.27_59; pretmp.28_49 = Arr_2_Par_Ref_30 + pretmp.28_45; # Int_Index_37 = PHI ; :; D.1544_54 = pretmp.27_59; D.1545_55 = pretmp.28_45; D.1546_56 = pretmp.28_49; (*D.1546_56)[Int_Index_37] = Int_Loc_3; Int_Index_58 = Int_Index_37 + 1; if (D.1548_41 >= Int_Index_58) goto ; else goto ; :; goto (); :; # prephitmp.33_40 = PHI ; # prephitmp.33_18 = PHI ; # prephitmp.31_25 = PHI ; Compare pretmp.28_49 with pretmp.32_11, why are the arguments in a different order? Is there something unstable in the PRE algorithm? One has to wonder what are the tree-ch effects on more complex loops. It might be interesting test SPEC with and without tree-ch... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26944
[Bug java/26042] ICE in mark_reference_fields, at java/boehm.c:105
--- Comment #11 from tromey at gcc dot gnu dot org 2006-03-30 16:47 --- Subject: Bug 26042 Author: tromey Date: Thu Mar 30 16:47:23 2006 New Revision: 112541 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112541 Log: gcc/java PR java/26042: * parse.y (java_reorder_fields): Reset superclass field's size as well. libjava PR java/26042: * testsuite/libjava.compile/pr26042.java: New file. Added: branches/gcc-4_1-branch/libjava/testsuite/libjava.compile/pr26042.java - copied unchanged from r112540, trunk/libjava/testsuite/libjava.compile/pr26042.java Modified: branches/gcc-4_1-branch/gcc/java/ChangeLog branches/gcc-4_1-branch/gcc/java/parse.y branches/gcc-4_1-branch/libjava/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26042
[Bug libfortran/26889] selected_int_kind.inc broken, causing failure
--- Comment #30 from quanah at stanford dot edu 2006-03-30 16:48 --- Here is what happens when I run it by hand: solaris8-build:/afs/ir/src/pubsw/languages/gcc-build/sun4x_58/sparc-sun-solaris2.8/libgfortran> /bin/ksh ../../../../gcc-4.0.3/libgfortran/mk-sik-inc.sh '/afs/ir.stanford.edu/src/pubsw/languages/gcc-build/sun4x_58/gcc/gfortran -B/afs/ir.stanford.edu/src/pubsw/languages/gcc-build/sun4x_58/gcc/ -B/usr/pubsw/sparc-sun-solaris2.8/bin/ -B/usr/pubsw/sparc-sun-solaris2.8/lib/ -isystem /usr/pubsw/sparc-sun-solaris2.8/include -isystem /usr/pubsw/sparc-sun-solaris2.8/sys-include -I . -Wall -fno-repack-arrays -fno-underscoring ' integer, parameter :: c = 0 type (int_info), parameter :: int_infos(c) = (/ & No errors or anything... It just spits out the broken bits. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26889
[Bug java/26042] ICE in mark_reference_fields, at java/boehm.c:105
--- Comment #12 from tromey at gcc dot gnu dot org 2006-03-30 16:49 --- I checked the fix into the 4.1 branch and the trunk. -- tromey at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.1.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26042
[Bug libfortran/26889] selected_int_kind.inc broken, causing failure
--- Comment #31 from ebotcazou at gcc dot gnu dot org 2006-03-30 16:52 --- > No errors or anything... It just spits out the broken bits. OK. Could you then break apart the script and run the various pieces manually? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26889
[Bug libfortran/26889] selected_int_kind.inc broken, causing failure
--- Comment #32 from quanah at stanford dot edu 2006-03-30 17:10 --- Okay, I created the following file (as is generated by the script): solaris8-build:/tmp> cat /tmp/q1.f90 integer (kind=1) :: x end Then ran the build command on it as is done by the script: /afs/ir.stanford.edu/src/pubsw/languages/gcc-build/sun4x_58/gcc/gfortran -B/afs/ir.stanford.edu/src/pubsw/languages/gcc-build/sun4x_58/gcc/ -B/usr/pubsw/sparc-sun-solaris2.8/bin/ -B/usr/pubsw/sparc-sun-solaris2.8/lib/ -isystem /usr/pubsw/sparc-sun-solaris2.8/include -isystem /usr/pubsw/sparc-sun-solaris2.8/sys-include -I . -Wall -fno-repack-arrays -fno-underscoring /tmp/q1.f90 and I get: :0: internal compiler error: Segmentation Fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. so the compiler is completely flailing on this. :( -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26889
[Bug tree-optimization/21829] [4.1/4.2 Regression] missed jump threading after unroller
--- Comment #14 from law at redhat dot com 2006-03-30 17:15 --- Just a note on the compile-time regressions for tramp3d... After fixing the timevars it was pretty clear that it isn't the cprop code itself that is slow, it is in fact very fast. THe slowdowns for tramp3d are in operand scanning and incremental SSA updates. I built a little instrumentation code and was rewarded with some insight into why tramp3d behaves differently for operand scanning. When we propagate into a statement, we (of course) fold and rescan the operands for the use statement. Clearly if we propagate several distinct copies into a single use statement, then we end up wasting time rescanning the use statement. My instrumentation recorded how often we perform more than one propagation into a statement vs how often we only propagate into a statement one time. In my test bucket that ratio is a little less than 1:1. I would have expected significantly smaller, but it is what it is. What's interesting is that for tramp3d that ratio is about 3:1 -- primarily from copy propagating into VUSE and V_MAY_DEF operands. I'm currently experimenting with some code to queue folding/rescanning of use statements in cases where there's a reasonable chance we're going to do more than one propagation into the statement. Initial experiments are showing a measurable compile-time improvement for both tramp3d as well as my testbucket. [ Note that Diego's memory tag rewrite work may make all this moot one day... ] Jeff -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21829
[Bug libfortran/26889] selected_int_kind.inc broken, causing failure
--- Comment #33 from quanah at stanford dot edu 2006-03-30 17:17 --- GDB shows: GNU gdb 6.3 Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "sparc-sun-solaris2.8"... (gdb) run Starting program: /afs/ir.stanford.edu/src/pubsw/languages/gcc-build/sun4x_58/gcc/f951 Program received signal SIGSEGV, Segmentation fault. 0x0035c398 in mpfr_set_default_prec () (gdb) bt #0 0x0035c398 in mpfr_set_default_prec () #1 0x0001496c in gfc_arith_init_1 () at ../../../gcc-4.0.3/gcc/fortran/arith.c:180 #2 0x0003e730 in gfc_init_1 () at ../../../gcc-4.0.3/gcc/fortran/misc.c:287 #3 0x0005d7d4 in gfc_init () at ../../../gcc-4.0.3/gcc/fortran/f95-lang.c:292 #4 0x00281514 in toplev_main (argc=Variable "argc" is not available. ) at ../../../gcc-4.0.3/gcc/toplev.c:2019 #5 0x000118d4 in .nope () #6 0x000118d4 in .nope () -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26889
[Bug libfortran/26889] selected_int_kind.inc broken, causing failure
--- Comment #34 from ebotcazou at gcc dot gnu dot org 2006-03-30 17:35 --- > Program received signal SIGSEGV, Segmentation fault. > 0x0035c398 in mpfr_set_default_prec () > (gdb) bt > #0 0x0035c398 in mpfr_set_default_prec () OK. Could you ditch MPFR 2.2.0 entirely and use the MPFR library bundled with GMP 4.2? The configure line for GMP is on the Solaris build instructions page. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26889
[Bug libfortran/26889] selected_int_kind.inc broken, causing failure
--- Comment #35 from quanah at stanford dot edu 2006-03-30 17:40 --- >From the GMP 4.2 NEWS file: Mis-features: * mpfr is gone, and will from now on be released only separately. Please see www.mpfr.org. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26889
[Bug target/17959] -mpowerpc64 can cause worse code than without it
--- Comment #2 from sayle at gcc dot gnu dot org 2006-03-30 17:47 --- Subject: Bug 17959 Author: sayle Date: Thu Mar 30 17:47:48 2006 New Revision: 112543 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112543 Log: PR target/17959 * expr.c (emit_group_store): Optimize group stores into a pseudo register by using a paradoxical subreg to initialize the destination if the first or last member of the group specifies a "low part". Modified: trunk/gcc/ChangeLog trunk/gcc/expr.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17959
[Bug libfortran/26889] selected_int_kind.inc broken, causing failure
--- Comment #36 from quanah at stanford dot edu 2006-03-30 17:48 --- Just to note, if I haven't already, I was able to build gcc 4.0.3 with GMP 4.2 and MPFR 2.2.0 on i386 and amd64 without a problem (including fortran), so this seems to be a problem specific to Solaris 8/9. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26889
[Bug tree-optimization/26948] New: ICE: tree check: expected ssa_name, have struct_field_tag in is_old_name, at tree-into-ssa.c:466
With the actual snapshot (gcc-4.2-20060325) I get the ICE: tree check: expected ssa_name, have struct_field_tag in is_old_name, at tree-into-ssa.c:466 Michael Cieslinski g++42f -O1 -msse2 -mfpmath=sse -ftree-vectorize -c in.ii -S -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../gcc-4.2-20060325/configure --prefix=/usr/local/gcc42f --program-suffix=42f --with-arch=opteron --enable-languages=c,c++ --enable-__cxa_atexit --disable-nls --enable-threads=posix --disable-multilib --enable-checking Thread model: posix gcc version 4.2.0 20060325 (experimental) /usr/local/gcc42f/libexec/gcc/x86_64-unknown-linux-gnu/4.2.0/cc1plus -fpreprocessed in.ii -quiet -dumpbase in.ii -msse2 -mfpmath=sse -march=opteron -auxbase in -O1 -version -ftree-vectorize -o in.s GNU C++ version 4.2.0 20060325 (experimental) (x86_64-unknown-linux-gnu) compiled by GNU C version 4.2.0 20060325 (experimental). GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: b091679bfe10b065fa639aec2f0c7166 in.ii: In function 'EVT MatchDeadPix(int, MatchDeadPixParType, long int)': in.ii:49: internal compiler error: tree check: expected ssa_name, have struct_field_tag in is_old_name, at tree-into-ssa.c:466 Please submit a full bug report, with preprocessed source if appropriate. -- Summary: ICE: tree check: expected ssa_name, have struct_field_tag in is_old_name, at tree-into-ssa.c:466 Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: micis at gmx dot de GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26948
[Bug tree-optimization/26948] ICE: tree check: expected ssa_name, have struct_field_tag in is_old_name, at tree-into-ssa.c:466
--- Comment #1 from micis at gmx dot de 2006-03-30 18:13 --- Created an attachment (id=11168) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11168&action=view) preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26948
[Bug target/26949] New: [4.2 regression] worse code generated for -march=pentium4
Compiling the code in PR26944 with -O2 -march=pentium4 -fno-tree-ch generates this for the loop: .L3: movl%esi, -4(%eax) addl$1, %edx addl$4, %eax cmpl-16(%ebp), %edx <- note an extra memory access here jle .L3 compiling for -march=i686 (or even just adding -fomit-frame-pointer) generates: .L3: addl$1, %ecx movl%ebx, -4(%edx) addl$4, %edx cmpl%eax, %ecx < no memory access here jle .L3 The above problem does not happen with gcc-4.0.3 or 4.1.0 -- Summary: [4.2 regression] worse code generated for - march=pentium4 Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dann at godzilla dot ics dot uci dot edu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26949
[Bug libfortran/26889] selected_int_kind.inc broken, causing failure
--- Comment #37 from ebotcazou at gcc dot gnu dot org 2006-03-30 18:48 --- > From the GMP 4.2 NEWS file: > > Mis-features: > * mpfr is gone, and will from now on be released only separately. Please > see > www.mpfr.org. Grumpf... Could you downgrade to 4.1.x then? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26889
[Bug c++/26950] New: Error diagnostic not issued for unacceptable result of lookup for a name used in a nested-name-specifier
The following should elicit an error during processing of e0's initializer:
namespace N {
const int a = 42;
enum N { e0 = N::a };
}
... because 3.4.3p1 [basic.lookup.qual] indicates that the enumeration [tag]
name N should be found during lookup in the nested-name-specifier and renders
the program ill-formed.
--
Summary: Error diagnostic not issued for unacceptable result of
lookup for a name used in a nested-name-specifier
Product: gcc
Version: 4.0.1
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: widman at gimpel dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26950
[Bug target/26879] LibJava not compile under alpha
--- Comment #8 from zerocool at modemsoft dot it 2006-03-30 19:28 --- Created an attachment (id=11169) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11169&action=view) The Gcc Build Log It's My build log... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26879
[Bug target/26879] LibJava not compile under alpha
--- Comment #9 from zerocool at modemsoft dot it 2006-03-30 19:31 --- Hello Mathew, i have tried to perform your indications, but without success; with a lot of probability because of my little competence in matter. I would pray you, considering that I have posted the build complete log, if reading it, you succeed in giving me some more precise indication. Thanks for the patience and understanding Regards ! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26879
[Bug c++/26940] C++ name space issue
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-30 19:55 --- This is actually invalid code which the C++ standard says implementions don't have to error out about. *** This bug has been marked as a duplicate of 17353 *** -- 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=26940
[Bug c++/17353] type name in nested class conflicts with name in outer class
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-03-30 19:55 --- *** Bug 26940 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||v dot haisman at sh dot cvut ||dot cz http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17353
[Bug rtl-optimization/26942] Code generation bug -freorder-blocks-and-partition
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-30 19:57 --- This has nothing to do with -fprofile-use and all to do with -freorder-blocks-and-partition -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Summary|Code generation bug (- |Code generation bug - |fprofile-use) |freorder-blocks-and- ||partition http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26942
[Bug rtl-optimization/26945] [3.4/4.0/4.1 regression] Attempt to delete prologue/epilogue insn
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-03-30 19:59 --- I am starting to think we should change a[outofbounds] = 1 to be an __builtin_trap() so that we will not run into stuff like this again. Also we should have a keyword for ice-on-undefined-code too :). -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |minor GCC build triplet|hppa-unknown-linux | GCC host triplet|hppa-unknown-linux | Keywords|ice-on-valid-code | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26945
[Bug c++/26950] Error diagnostic not issued for unacceptable result of lookup for a name used in a nested-name-specifier
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-30 20:02 --- Hmm, Comeau C++ does not reject this code either (but that does not mean this is not invalid code). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26950
[Bug middle-end/26823] ICE with OpenMP in add_stmt_to_eh_region_fn, at tree-eh.c:100
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-30 20:04 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-03-30 20:04:18 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26823
[Bug rtl-optimization/26847] [4.2 Regression] Missed optimization in simplify_plus_minus
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-30 20:09 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-03-30 20:09:49 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26847
[Bug middle-end/26853] [4.2 Regression] ACATS c43212a failure at runtime
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |critical http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26853
[Bug rtl-optimization/26855] [4.2 Regression] ICE in add_deps_for_def with -fmodulo-sched -maltivec
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-03-30 20:11:02 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26855
[Bug preprocessor/26857] Warning for absolute or dotted header paths
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-30 20:12 --- Confirmed, just a note, all patches need to go on the mainline before even thinking about being backported. (Yes I know how long the copyright issues are because I am trying to get my fixed up too). -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC build triplet|N/A | GCC host triplet|N/A | GCC target triplet|N/A | Last reconfirmed|-00-00 00:00:00 |2006-03-30 20:12:14 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26857
[Bug target/26877] configure switches --with-arch and --with-tune are broken on x86
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|trivial |normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26877
[Bug c++/26950] Error diagnostic not issued for unacceptable result of lookup for a name used in a nested-name-specifier
--- Comment #2 from widman at gimpel dot com 2006-03-30 21:06 ---
Subject: Error diagnostic not issued for unacceptable result of lookup for a
name used in a nested-name-specifier
On Mar 30, 2006, at 2:56 PM, Daveed Vandevoorde wrote:
> Hi James,
>
> On Mar 30, 2006, at 2:31 PM, James Widman wrote:
>
>> [This can probably also be categorized as "low priority".]
>>
>> The GCC and EDG front ends both appear to think that this test
>> case is well-formed:
>>
>> namespace N {
>> const int a = 42;
>> enum N { e0 = N::a };
>> }
>>
>> ... but I think 3.4.3p1 makes it ill-formed.
>
>
> Can you elaborate on that? 3.4.3/1 says:
>
> The name of a class or namespace member can be referred to
> after the :: scope resolution operator (5.1) applied to a
> nested-name-specifier that nominates its class or namespace.
> During the lookup for a name preceding the :: scope resolution
> operator, object, function, and enumerator names are ignored.
> If the name found is not a class-name (clause 9) or
> namespace-name (7.3.1), the program is ill-formed.
>
> So when looking up N in N::a, the "enum N" entry is ignored, and the
> "namespace N" entry is found. "a" is a member of that namespace, and
> it can be used in an integral constant-expression.
>
> Am I missing something?
>
> Daveed Vandevoorde
> Edison Design Group
"enum N" is not an enumerator name; it's an enumeration name (or an /
enum-name/ [7.2p1]), so "enum N" cannot be ignored.
In C (ignoring the namespace N for now), we would say that the
enumeration name N resides in the tag name space (along with the tag
names of structs and unions) and e0 resides in the ordinary name
space (along with the names of functions, variables, and typedef
names -- see C89: 3.1.2.3, C99:6.2.3).
So when I read that excerpt of 3.4.3/1, I thought to myself:
"During the lookup for a name preceding the :: scope resolution
operator, ordinary names are ignored, except that typedef names and
namespace names are considered."
... with the implication being that tag names (including the names of
classes, unions, and enumerations) are considered without exception.
>> I also reported this to:
>>
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26950
>>
>> MSVC (6 through 8) and Borland 5.6 appear to treat the enum-name
>> as hiding the namespace name during lookup for the nested-name-
>> specifier.
>>
>> James Widman
>> --
>> Gimpel Software
>> http://gimpel.com
>>
>>
>
James Widman
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26950
[Bug preprocessor/26857] Warning for absolute or dotted header paths
--- Comment #3 from mbland at google dot com 2006-03-30 21:09 --- Right, I've got a mainline patch now, too. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26857
[Bug libfortran/26889] selected_int_kind.inc broken, causing failure
--- Comment #38 from quanah at stanford dot edu 2006-03-30 21:18 --- Yeah, I'll give that a shot next week (i'm now in a freeze period). I've also been poking at MPFR. There are apparently 10 or more patches now for 2.2.0, that may resolve the issues, too. I'll look at that. I've rebuilt it, and ran the "check" area for mpfr, and 115/117 tests fail, so I'm guessing there are some serious issues there with MPFR. I've also subscribed to their list, because I can see that until MPFR is no longer busted, gcc isn't going to be working. ;) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26889
[Bug c++/22494] C++ front-end produces mis-match types in EQ_EXPR (array deconstructor)
--- Comment #2 from roger at eyesopen dot com 2006-03-30 21:24 --- This should now be fixed on mainline. -- roger at eyesopen dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22494
[Bug target/17959] -mpowerpc64 can cause worse code than without it
--- Comment #3 from roger at eyesopen dot com 2006-03-30 21:35 --- This is now be fixed on mainline. With -mpowerpc64, we now generate: _div16: rldimi 3,4,0,32 srdi 4,3,4 srdi 3,3,36 blr -- roger at eyesopen dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17959
[Bug bootstrap/26892] Can't compile a 64-bit gcc
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-30 21:46 --- ld64 warning: in /usr/lib/libiconv.dylib, file does not contain requested architecture ld64 warning: in /usr/lib/libiconv.dylib, file does not contain requested architecture I don't think there is anything GCC can do to fix this problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26892
[Bug middle-end/26898] Fold does not fold signed + CST1 CMP signed + CST2 where CST1 == CST2
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-30 21:49 --- Confirmed, only when CST1 == CST2 does this work based on: http://gcc.gnu.org/ml/gcc-patches/2006-03/msg01746.html -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-03-30 21:49:44 date|| Summary|Fold does not fold signed +-|Fold does not fold signed + |CST CMP signed +- CST |CST1 CMP signed + CST2 where ||CST1 == CST2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26898
[Bug middle-end/26899] Fold does not fold (i0 > i1 + 1) || (i1 < i0 - 1)
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Severity|normal |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26899
[Bug target/26902] missed optimization during x87 args load with inline-asm
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-30 21:53 --- Note it works correctly without the inline-asm. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Component|other |target Keywords||missed-optimization Summary|missed optimization during |missed optimization during |x87 args load. |x87 args load with inline- ||asm http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26902
[Bug libfortran/26712] gfortran on mac intel runtime floating point exception when printing
--- Comment #9 from fxcoudert at gcc dot gnu dot org 2006-03-30 22:00 --- Subject: Bug 26712 Author: fxcoudert Date: Thu Mar 30 22:00:21 2006 New Revision: 112546 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112546 Log: PR libfortran/26712 * config/fpu-387.h: Add special case for handling of SSE control bit on i386-darwin. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/config/fpu-387.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26712
[Bug c++/26905] default-visibility class symbol improperly resolved as hidden-visibility
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-30 22:00 ---
#pragma GCC visibility push(hidden)
struct __attribute__ ((visibility ("default"))) nsINIParser
{
static void Init();
};
__attribute__ ((visibility ("default")))
void
CheckCompatibility(void)
{
nsINIParser::Init();
}
Confirmed, not a regression, with -fPIC this should call a PLT based function
but does not.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Component|middle-end |c++
Ever Confirmed|0 |1
GCC build triplet|x86_64-unknown-linux-gcc|
GCC host triplet|x86_64-unknown-linux-gcc|
GCC target triplet|x86_64-unknown-linux-gcc|
Keywords||wrong-code
Known to fail||4.0.3 4.1.0 4.2.0
Last reconfirmed|-00-00 00:00:00 |2006-03-30 22:00:53
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26905
[Bug middle-end/26906] internal compiler error: in do_SUBST, at combine.c:447
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-03-30 22:01 --- 3.4.x is no longer being updated, can you try 4.0.x or 4.1.0? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|major |normal GCC target triplet|armeb-unknown-linux |armeb-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26906
[Bug libfortran/26712] gfortran on mac intel runtime floating point exception when printing
--- Comment #10 from fxcoudert at gcc dot gnu dot org 2006-03-30 22:04 --- Can someone confirm this issue is now fixed on trunk? I'd then apply the patch to 4.1 as well. And Erik, btw, the assign_2.f90 failure is PR25765. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-03-30 22:04:44 date|| Target Milestone|--- |4.1.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26712
[Bug other/26914] missed optimization / lack of conditional moves
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-30 22:04 --- Conditional move is not always faster. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26914
[Bug other/26914] missed optimization / lack of conditional moves
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26914
