[Bug libstdc++/31426] TR1 includes do not work with -std=c++0x
--- Comment #4 from bkoz at gcc dot gnu dot org 2007-04-06 09:33 --- Hey Doug. Yes, indeed this is the case: I pointed it out a couple of times already. I'll try to implement this other behavior, but without injecting namespace std::tr1 as part of C++0x items. -benjamin -- bkoz at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |bkoz at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2007-04-02 17:26:11 |2007-04-06 09:33:09 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31426
[Bug other/23572] No warning for assigning a value to a 'float' variable that overflows with option -Wextra
--- Comment #14 from manu at gcc dot gnu dot org 2007-04-06 12:25 --- > /home/apinski/src/local/gcc/gcc/testsuite/gcc.dg/float-range-3.c:10: error: > 'FP_INFINITE' undeclared (first use in this function) Is FP_INFINITE undeclared in spu-elf? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23572
[Bug fortran/31204] wrong host association of implied loop variable
--- Comment #2 from pault at gcc dot gnu dot org 2007-04-06 12:49 ---
This fixes it and half regtests(I got bored with the time that it was taking
with Chug_chugwin.). I will regest tonight on something more spritely!
Paul
Index: gcc/fortran/decl.c
===
*** gcc/fortran/decl.c (révision 123517)
--- gcc/fortran/decl.c (copie de travail)
*** build_sym (const char *name, gfc_charlen
*** 769,774
--- 769,777
if (gfc_copy_attr (&sym->attr, &attr, var_locus) == FAILURE)
return FAILURE;
+ /* Reset because symbol is not only declared implicitly as an implied
+ do loop index. */
+ sym->attr.implied_index = 0;
return SUCCESS;
}
Index: gcc/fortran/gfortran.h
===
*** gcc/fortran/gfortran.h (révision 123516)
--- gcc/fortran/gfortran.h (copie de travail)
*** typedef struct
*** 483,489
/* Variable attributes. */
unsigned allocatable:1, dimension:1, external:1, intrinsic:1,
optional:1, pointer:1, save:1, target:1, value:1, volatile_:1,
! dummy:1, result:1, assign:1, threadprivate:1, not_always_present:1;
unsigned data:1,/* Symbol is named in a DATA statement. */
protected:1, /* Symbol has been marked as protected. */
--- 483,490
/* Variable attributes. */
unsigned allocatable:1, dimension:1, external:1, intrinsic:1,
optional:1, pointer:1, save:1, target:1, value:1, volatile_:1,
! dummy:1, result:1, assign:1, threadprivate:1, not_always_present:1,
! implied_index:1;
unsigned data:1,/* Symbol is named in a DATA statement. */
protected:1, /* Symbol has been marked as protected. */
Index: gcc/fortran/match.c
===
*** gcc/fortran/match.c (révision 123516)
--- gcc/fortran/match.c (copie de travail)
*** gfc_match_iterator (gfc_iterator *iter,
*** 536,541
--- 536,543
goto cleanup;
}
+ var->symtree->n.sym->attr.implied_index = 1;
+
m = init_flag ? gfc_match_init_expr (&e1) : gfc_match_expr (&e1);
if (m == MATCH_NO)
goto syntax;
Index: gcc/fortran/primary.c
===
*** gcc/fortran/primary.c (révision 123516)
--- gcc/fortran/primary.c (copie de travail)
*** gfc_match_rvalue (gfc_expr **result)
*** 2017,2023
--- 2017,2038
e = NULL;
where = gfc_current_locus;
+ /* If this is an implicit do loop index and implicitly typed,
+ it should not be host associated. */
+ if (sym->attr.flavor == FL_VARIABLE
+ && sym->ns != gfc_current_ns
+ && sym->attr.implied_index
+ && sym->attr.implicit_type
+ && !sym->attr.use_assoc)
+ {
+ i = gfc_get_sym_tree (name, NULL, &symtree);
+ if (i)
+ return MATCH_ERROR;
+ sym = symtree->n.sym;
+ }
+
gfc_set_sym_referenced (sym);
+ sym->attr.implied_index = 0;
if (sym->attr.function && sym->result == sym)
{
*** match_variable (gfc_expr **result, int e
*** 2386,2391
--- 2401,2424
where = gfc_current_locus;
sym = st->n.sym;
+
+ /* If this is an implicit do loop index and implicitly typed,
+ it should not be host associated. */
+ if (sym->ns != gfc_current_ns
+ && sym->attr.implied_index
+ && sym->attr.implicit_type
+ && !sym->attr.use_assoc)
+ {
+ int i;
+
+ i = gfc_get_sym_tree (sym->name, NULL, &st);
+ if (i)
+ return MATCH_ERROR;
+ sym = st->n.sym;
+ }
+
+ sym->attr.implied_index = 0;
+
gfc_set_sym_referenced (sym);
switch (sym->attr.flavor)
{
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org
|dot org |
Status|NEW |ASSIGNED
Last reconfirmed|2007-03-16 20:53:01 |2007-04-06 12:49:48
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31204
[Bug libstdc++/31117] c++locale.o thread-unsafe in libstdc++
-- pcarlini at suse dot de changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-04-06 14:59:42 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31117
[Bug libffi/31491] libffi: bug in example program
--- Comment #2 from tromey at gcc dot gnu dot org 2007-04-06 15:30 --- Subject: Bug 31491 Author: tromey Date: Fri Apr 6 15:30:27 2007 New Revision: 123617 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123617 Log: PR libffi/31491: * README: Fixed bug in example. Modified: trunk/libffi/ChangeLog trunk/libffi/README -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31491
[Bug libffi/31491] libffi: bug in example program
--- Comment #3 from tromey at gcc dot gnu dot org 2007-04-06 15:31 --- Thanks, I fixed this. -- tromey at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31491
[Bug target/27869] "-O -fregmove" handles SSE scalar instructions incorrectly
--- Comment #7 from hubicka at ucw dot cz 2007-04-06 16:07 --- Subject: Re: "-O -fregmove" handles SSE scalar instructions incorrectly > Investigating... The attached patch to remove '%' seems correct to me. Merge operating wrapping the (commutative) plus/mult/min/max is not commutative, so '%' is wrong. Or am I missing something? Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27869
[Bug middle-end/31492] New: FAIL: gcc.c-torture/execute/20040709-2.c execution at -O1 and above
Executing on host: /home/dave/gnu/gcc-4.3/objdir/gcc/xgcc -B/home/dave/gnu/gcc-4 .3/objdir/gcc/ /home/dave/gnu/gcc-4.3/gcc/gcc/testsuite/gcc.c-torture/execute/20 040709-2.c -w -O1 -fno-show-column -lm -o /home/dave/gnu/gcc-4.3/objdir/gc c/testsuite/gcc/20040709-2.x1(timeout = 300) PASS: gcc.c-torture/execute/20040709-2.c compilation, -O1 Setting LD_LIBRARY_PATH to :/home/dave/gnu/gcc-4.3/objdir/gcc::/home/dave/gnu/gc c-4.3/objdir/gcc:/home/dave/gnu/gcc-4.3/objdir/hppa-linux/libstdc++-v3/.libs:/ho me/dave/gnu/gcc-4.3/objdir/hppa-linux/libmudflap/.libs:/home/dave/gnu/gcc-4.3/ob jdir/hppa-linux/libssp/.libs:/home/dave/gnu/gcc-4.3/objdir/hppa-linux/libgomp/.l ibs:/home/dave/gnu/gcc-4.3/objdir/./gcc:/home/dave/gnu/gcc-4.3/objdir/./prev-gcc FAIL: gcc.c-torture/execute/20040709-2.c execution, -O1 (gdb) bt #0 0x40313300 in abort () from /lib/libc.so.6 #1 0x000176ac in testK () at /home/dave/gnu/gcc-4.3/gcc/gcc/testsuite/gcc.c-torture/execute/20040709-2.c:101 #2 0x0001a0c4 in main () at /home/dave/gnu/gcc-4.3/gcc/gcc/testsuite/gcc.c-torture/execute/20040709-2.c:131 -- Summary: FAIL: gcc.c-torture/execute/20040709-2.c execution at - O1 and above Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org GCC build triplet: hppa*-*-* GCC host triplet: hppa*-*-* GCC target triplet: hppa*-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31492
[Bug libstdc++/31117] c++locale.o thread-unsafe in libstdc++
--- Comment #31 from bkoz at gcc dot gnu dot org 2007-04-06 16:38 --- For generic targets, can't you just -errno = 0; +static __thread int errno = 0; on releases of gcc (4.3+) that have the wherewithal to fudge the issue for all systems, even the ones without builtin-TLS? -benjamin -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31117
[Bug fortran/31395] Colon edit descriptor is ignored unless preceded by a comma or a slash
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2007-04-06 16:39 --- Subject: Bug 31395 Author: jvdelisle Date: Fri Apr 6 16:39:02 2007 New Revision: 123620 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123620 Log: 2007-04-06 Jerry DeLisle <[EMAIL PROTECTED]> PR libgfortran/31395 * io/format.c (parse_format_list): Fix parsing. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/format.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31395
[Bug middle-end/31493] New: FAIL: gcc.c-torture/execute/bf64-1.c execution at -Os and -O3
Executing on host: /home/dave/gnu/gcc-4.3/objdir/gcc/xgcc -B/home/dave/gnu/gcc-4 .3/objdir/gcc/ /home/dave/gnu/gcc-4.3/gcc/gcc/testsuite/gcc.c-torture/execute/99 1118-1.c -w -O3 -fomit-frame-pointer -fno-show-column -lm -o /home/dave/gn u/gcc-4.3/objdir/gcc/testsuite/gcc/991118-1.x3(timeout = 300) PASS: gcc.c-torture/execute/991118-1.c compilation, -O3 -fomit-frame-pointer Setting LD_LIBRARY_PATH to :/home/dave/gnu/gcc-4.3/objdir/gcc::/home/dave/gnu/gc c-4.3/objdir/gcc:/home/dave/gnu/gcc-4.3/objdir/hppa-linux/libstdc++-v3/.libs:/ho me/dave/gnu/gcc-4.3/objdir/hppa-linux/libmudflap/.libs:/home/dave/gnu/gcc-4.3/ob jdir/hppa-linux/libssp/.libs:/home/dave/gnu/gcc-4.3/objdir/hppa-linux/libgomp/.l ibs:/home/dave/gnu/gcc-4.3/objdir/./gcc:/home/dave/gnu/gcc-4.3/objdir/./prev-gcc FAIL: gcc.c-torture/execute/991118-1.c execution, -O3 -fomit-frame-pointer Breakpoint 2, 0x40313300 in abort () from /lib/libc.so.6 (gdb) bt #0 0x40313300 in abort () from /lib/libc.so.6 #1 0x0001082c in main () at /home/dave/gnu/gcc-4.3/gcc/gcc/testsuite/gcc.c-torture/execute/991118-1.c:77 This fail wasn't present in revision 123512. -- Summary: FAIL: gcc.c-torture/execute/bf64-1.c execution at -Os and -O3 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org GCC build triplet: hppa*-*-* GCC host triplet: hppa*-*-* GCC target triplet: hppa*-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31493
[Bug fortran/31395] Colon edit descriptor is ignored unless preceded by a comma or a slash
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2007-04-06 16:42 --- Subject: Bug 31395 Author: jvdelisle Date: Fri Apr 6 16:42:26 2007 New Revision: 123621 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123621 Log: 2007-04-06 Jerry DeLisle <[EMAIL PROTECTED]> PR libgfortran/31395 * gfortran.dg/fmt_colon.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/fmt_colon.f90 Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31395
[Bug target/27869] "-O -fregmove" handles SSE scalar instructions incorrectly
--- Comment #8 from stevenb dot gcc at gmail dot com 2007-04-06 16:43 --- Subject: Re: "-O -fregmove" handles SSE scalar instructions incorrectly > The attached patch to remove '%' seems correct to me. Merge operating > wrapping the (commutative) plus/mult/min/max is not commutative, so '%' > is wrong. Or am I missing something? The commutative alternative asm output should also be removed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27869
[Bug fortran/31395] [4.2 Only] Colon edit descriptor is ignored unless preceded by a comma or a slash
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2007-04-06 16:44 --- Fixed on trunk, may backport to 4.2.1 -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Summary|Colon edit descriptor is|[4.2 Only] Colon edit |ignored unless preceded by a|descriptor is ignored unless |comma or a slash|preceded by a comma or a ||slash Target Milestone|--- |4.2.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31395
[Bug middle-end/31493] FAIL: gcc.c-torture/execute/991118-1.c execution at -Os and -O3
--- Comment #1 from danglin at gcc dot gnu dot org 2007-04-06 16:45 --- Oops, wrong subject. -- danglin at gcc dot gnu dot org changed: What|Removed |Added Summary|FAIL: gcc.c-|FAIL: gcc.c- |torture/execute/bf64-1.c|torture/execute/991118-1.c |execution at -Os and -O3|execution at -Os and -O3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31493
[Bug libstdc++/31117] c++locale.o thread-unsafe in libstdc++
--- Comment #32 from pcarlini at suse dot de 2007-04-06 16:46 --- (In reply to comment #31) > For generic targets, can't you just > > -errno = 0; > +static __thread int errno = 0; > > on releases of gcc (4.3+) that have the wherewithal to fudge the issue for all > systems, even the ones without builtin-TLS? Nice idea, but I'm not sure it would work (i'm not very familiar with __thread, etc.): are we sure that with that kind of declaration the strtof & co functions themselves automatically use that new "improved" errno instead of the global one? Besides that, from a correctness point of view, I don't think we want to fail in case of underflow, other implementations behave differently from v3... -- pcarlini at suse dot de changed: What|Removed |Added CC||bkoz at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31117
[Bug middle-end/31493] FAIL: gcc.c-torture/execute/991118-1.c execution at -Os and -O3
--- Comment #2 from danglin at gcc dot gnu dot org 2007-04-06 16:49 --- We also have these new fails which appear related: FAIL: gcc.c-torture/execute/bf64-1.c execution, -O3 -fomit-frame-pointer FAIL: gcc.c-torture/execute/bf64-1.c execution, -O3 -g FAIL: gcc.c-torture/execute/bf64-1.c execution, -Os -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31493
[Bug middle-end/31322] [4.3 Regression] ld: Invalid symbol type for plabel (.libs/debug_list.o, __gxx_personality_v0).
--- Comment #1 from sje at cup dot hp dot com 2007-04-06 16:59 --- I am seeing this on my HPPA build as well. David sent me a patch for it off-list and that patch fixed the build problem for me. -- sje at cup dot hp dot com changed: What|Removed |Added CC||sje at cup dot hp dot com Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-04-06 16:59:41 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31322
[Bug target/27869] "-O -fregmove" handles SSE scalar instructions incorrectly
--- Comment #9 from hubicka at ucw dot cz 2007-04-06 17:01 --- Subject: Re: "-O -fregmove" handles SSE scalar instructions incorrectly > > > --- Comment #8 from stevenb dot gcc at gmail dot com 2007-04-06 16:43 > --- > Subject: Re: "-O -fregmove" handles SSE scalar instructions incorrectly > > > The attached patch to remove '%' seems correct to me. Merge operating > > wrapping the (commutative) plus/mult/min/max is not commutative, so '%' > > is wrong. Or am I missing something? > > The commutative alternative asm output should also be removed. I don't think there are alternative asm outputs, just intel variants, unless I missed something. The min/max commutative variant should be removed however, I am testing the attached patch. Honza --- Comment #10 from hubicka at ucw dot cz 2007-04-06 17:01 --- Created an attachment (id=13334) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13334&action=view) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27869
[Bug libstdc++/31117] c++locale.o thread-unsafe in libstdc++
--- Comment #33 from bkoz at gcc dot gnu dot org 2007-04-06 17:15 --- >Nice idea, but I'm not sure it would work (i'm not very familiar with __thread, >etc.): are we sure that with that kind of declaration the strtof & co functions >themselves automatically use that new "improved" errno instead of the global >one? Ack, no, they will not. So, this is a non-starter. >Besides that, from a correctness point of view, I don't think we want to >fail in case of underflow, other implementations behave differently from v3... Hmm. Well, I leave this in your capable hands. -benjamin -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31117
[Bug fortran/31494] New: spurious error: PROCEDURE attribute conflicts with DIMENSION attribute
When I compile the module listed below I get the following message: k.f90:5.13: CALL sub2 1 Error: PROCEDURE attribute conflicts with DIMENSION attribute in 'sub2' at (1) It resembles Bug 24633. However, g95 and Lahey regard 24633 as an error but do not regard this as an error. MODULE ksbin2_aux_mod REAL, DIMENSION(1) :: sub2 CONTAINS SUBROUTINE sub1 CALL sub2 CONTAINS SUBROUTINE sub2 END SUBROUTINE sub2 END SUBROUTINE sub1 END MODULE ksbin2_aux_mod -- Summary: spurious error: PROCEDURE attribute conflicts with DIMENSION attribute Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: michael dot a dot richmond at nasa dot gov http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31494
[Bug middle-end/31322] [4.3 Regression] ld: Invalid symbol type for plabel (.libs/debug_list.o, __gxx_personality_v0).
--- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca 2007-04-06 17:53 --- Subject: Re: [4.3 Regression] ld: Invalid symbol type for plabel (.libs/debug_list.o, __gxx_personality_v0). > I am seeing this on my HPPA build as well. David sent me a patch for it > off-list and that patch fixed the build problem for me. The patch just reverts Mark's change. The previous code papers over the real problem. The reference to the __gxx_personality_v0 personality function occurs in the eh frame table and not in the exception table. Looking at this a bit, I think the fix is to add if (eh_personality_libfunc) assemble_external_libcall (eh_personality_libfunc); to output_call_frame_info in dwarf2out.c. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31322
[Bug libgcj/23758] java::lang::ConcreteProcess::nativeSpawn unsafe
-- daney at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |daney at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2005-09-07 00:49:54 |2007-04-06 17:53:52 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23758
[Bug fortran/31204] wrong host association of implied loop variable
--- Comment #3 from patchapp at dberlin dot org 2007-04-06 18:30 --- Subject: Bug number PR31204 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/2007-04/msg00276.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31204
[Bug fortran/31495] New: Is this continuation line legal?
When I compile the program listed below I get the message: Warning: '&' not allowed by itself in line 4 The other compilers I tried do not print any messages. PROGRAM print_ascertain CHARACTER (LEN=20) :: str str = "Hello world & & & &" END PROGRAM print_ascertain -- Summary: Is this continuation line legal? Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: michael dot a dot richmond at nasa dot gov http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31495
[Bug target/30483] Internal compiler error with inline volatile assembly on AVR
-- aesok at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-04-06 19:15:59 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30483
[Bug fortran/31495] Is this continuation line legal?
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2007-04-06 19:32 --- Confirmed: The relevant section in the standard is 3.3.1.3 . This diallows a single '&' by it self on a line, but says nothing about two. Part of th eproblem is we treat ' ' (a blank) as non printable in the scanner. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jvdelisle at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-04-06 19:32:47 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31495
[Bug other/23572] No warning for assigning a value to a 'float' variable that overflows with option -Wextra
--- Comment #15 from danglin at gcc dot gnu dot org 2007-04-06 19:58 --- The same errors occur on hppa*-*-hpux*. FP_INFINITE isn't defined in HP-UX 10. For HP-UX 11, we need "-D_HPUX_SOURCE" to get math.h to define FP_INFINITE. -- danglin at gcc dot gnu dot org changed: What|Removed |Added CC||danglin at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23572
[Bug middle-end/31496] New: FAIL: gcc.dg/builtins-20.c (test for excess errors)
Executing on host: /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/ /te st/gnu/gcc/gcc/gcc/testsuite/gcc.dg/builtins-20.c -O2 -ffast-math -fno-show-co lumn -lm -o builtins-20.exe(timeout = 300) ld: Unsatisfied symbol "cargf" in file /var/tmp//ccKMBpML.o ld: Unsatisfied symbol "cargl" in file /var/tmp//ccKMBpML.o ld: Unsatisfied symbol "atan2l" in file /var/tmp//ccKMBpML.o ld: Unsatisfied symbol "link_error" in file /var/tmp//ccKMBpML.o 4 errors. collect2: ld returned 1 exit status compiler exited with status 1 output is: ld: Unsatisfied symbol "cargf" in file /var/tmp//ccKMBpML.o ld: Unsatisfied symbol "cargl" in file /var/tmp//ccKMBpML.o ld: Unsatisfied symbol "atan2l" in file /var/tmp//ccKMBpML.o ld: Unsatisfied symbol "link_error" in file /var/tmp//ccKMBpML.o 4 errors. collect2: ld returned 1 exit status -- Summary: FAIL: gcc.dg/builtins-20.c (test for excess errors) Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org GCC build triplet: hppa*-*-hpux* GCC host triplet: hppa*-*-hpux* GCC target triplet: hppa*-*-hpux* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31496
[Bug fortran/31495] Is this continuation line legal?
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2007-04-06 20:18 --- Index: scanner.c === --- scanner.c (revision 123528) Here is a preliminary patch, I a, testing some combinations so the final patch may vary from this a bit. +++ scanner.c (working copy) @@ -1071,7 +1071,7 @@ load_line (FILE *input, char **pbuf, int if (c == '&') seen_ampersand = 1; - if ((c != ' ' && c != '&' && c != '!') || (c == '!' && !seen_ampersand)) + if ((c != '&' && c != '!') || (c == '!' && !seen_ampersand)) seen_printable = 1; if (gfc_current_form == FORM_FREE -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31495
[Bug target/27869] "-O -fregmove" handles SSE scalar instructions incorrectly
--- Comment #11 from echristo at apple dot com 2007-04-06 20:31 --- Jan, Yeah, that's exactly the patch I had when it finishes testing ok (it did for me on i386), would you please commit it to the 4.2 branch as well? -- echristo at apple dot com changed: What|Removed |Added CC||echristo at apple dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27869
[Bug middle-end/31497] New: FAIL: gcc.dg/builtins-59.c on PA HP-UX
Executing on host: /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/builtins-59.c -fdump-tree-gimple
-fno-show-column -S -o builtins-59.s(timeout = 300)
PASS: gcc.dg/builtins-59.c (test for excess errors)
FAIL: gcc.dg/builtins-59.c scan-tree-dump __builtin_cexpi
FAIL: gcc.dg/builtins-59.c scan-tree-dump-not sincos
Related fails are:
Executing on host: /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/builtins-61.c -O -ffast-math
-fdump-tree-optimized -fno-show-column -S -o builtins-61.s(timeout = 300)
PASS: gcc.dg/builtins-61.c (test for excess errors)
FAIL: gcc.dg/builtins-61.c scan-tree-dump cexpi
FAIL: gcc.dg/builtins-61.c scan-tree-dump sin
FAIL: gcc.dg/builtins-61.c scan-tree-dump cos
FAIL: gcc.dg/builtins-61.c scan-tree-dump return 0.0
Executing on host: /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/builtins-62.c -O -ffinite-math-only
-fdump-tree-optimized -fno-show-column -S -o builtins-62.s(timeout = 300)
PASS: gcc.dg/builtins-62.c (test for excess errors)
FAIL: gcc.dg/builtins-62.c scan-tree-dump-times cexpi 3
The builtins-59.c and builtins-61 fails were introduced in their current
form between revision 121100 and 121219. The tests initially started failing
after revision 120836.
The tree dump for builtin-59.c looks like:
test (x)
{
double D.1590;
double s___0;
double c___1;
double s;
double c;
__builtin_sincos (x, &s, &c);
s___0 = s;
c___1 = c;
D.1590 = s___0 + c___1;
return D.1590;
}
For builtins-61.c,
;; Function test3 (test3)
Analyzing Edge Insertions.
test3 (x)
{
complex double c;
:
c = __builtin_cexp (COMPLEX_EXPR <-0.0, x>);
return REALPART_EXPR + IMAGPART_EXPR ;
}
;; Function test2 (test2)
Analyzing Edge Insertions.
test2 (x)
{
:
return IMAGPART_EXPR <__builtin_cexp (COMPLEX_EXPR <-0.0, x>)>;
}
;; Function test1 (test1)
Analyzing Edge Insertions.
test1 (x)
{
:
return REALPART_EXPR <__builtin_cexp (COMPLEX_EXPR <-0.0, x>)>;
}
;; Function test4 (test4)
Analyzing Edge Insertions.
test4 (x, y)
{
:
return __builtin_exp (x) - REALPART_EXPR <__builtin_cexp (COMPLEX_EXPR )>;
}
and for builtins-62.c
;; Function test4 (test4)
Analyzing Edge Insertions.
test4 (x)
{
:
return __builtin_sin (x * 2.0e+0);
}
;; Function test3 (test3)
Analyzing Edge Insertions.
test3 (x, b)
{
:
if (b != 0) goto ; else goto ;
:;
x = x * 2.0e+0;
:;
return __builtin_sin (x) + __builtin_cos (x);
}
;; Function test2 (test2)
Analyzing Edge Insertions.
test2 (x)
{
double x___73;
:
x___73 = x * 2.0e+0;
return __builtin_sin (x___73) + __builtin_cos (x___73);
}
;; Function test1 (test1)
Analyzing Edge Insertions.
test1 (x)
{
:
return __builtin_sin (x) + __builtin_cos (x);
}
--
Summary: FAIL: gcc.dg/builtins-59.c on PA HP-UX
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: danglin at gcc dot gnu dot org
GCC build triplet: hppa*-*-hpux*
GCC host triplet: hppa*-*-hpux*
GCC target triplet: hppa*-*-hpux*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31497
[Bug middle-end/31322] [4.3 Regression] ld: Invalid symbol type for plabel (.libs/debug_list.o, __gxx_personality_v0).
--- Comment #3 from mark at codesourcery dot com 2007-04-06 22:09 ---
Subject: Re: [4.3 Regression] ld: Invalid symbol type
for plabel (.libs/debug_list.o, __gxx_personality_v0).
dave at hiauly1 dot hia dot nrc dot ca wrote:
> Looking at this a bit, I think the fix is to add
>
> if (eh_personality_libfunc)
> assemble_external_libcall (eh_personality_libfunc);
>
> to output_call_frame_info in dwarf2out.c.
That makes sense to me. I think you could do it just in the
for_eh/eh_personality case here:
> if (eh_personality_libfunc)
> {
> *p++ = 'P';
> augmentation_size += 1 + size_of_encoded_value (per_encoding);
> }
That would emit the reference only in situations where we're actually
going to need the personality routine. The reason for my earlier change
was that we were referencing it even when we'd optimized away all of the
EH information in the module. I'm sorry this broke HP-UX; let me know
if I can help.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31322
[Bug c++/31498] New: [4.1/4.2/4.3 Regression] ICE with vector initializer in template
Testcase:
typedef __attribute__((__vector_size__(16) )) unsigned char vec_uchar16;
template
void permute(Tx x, Ty y, Tz z, Tw w)
{
const vec_uchar16 pattern =
(vec_uchar16){4*x, 4*x+1, 4*x+2, 4*x+3,
4*y, 4*y+1, 4*y+2, 4*y+3,
4*z, 4*z+1, 4*z+2, 4*z+3,
4*w, 4*w+1, 4*w+2, 4*w+3};
}
int main()
{
permute(1,2,3,4);
return 0;
}
--
Summary: [4.1/4.2/4.3 Regression] ICE with vector initializer in
template
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31498
[Bug fortran/30881] Select case of case(transfer(...)) wrongly rejected
-- brooks at gcc dot gnu dot org changed: What|Removed |Added CC||brooks at gcc dot gnu dot ||org AssignedTo|unassigned at gcc dot gnu |brooks at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-03-03 12:36:28 |2007-04-06 22:56:55 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30881
[Bug c++/31498] [4.1/4.2/4.3 Regression] ICE with vector initializer in template
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Known to fail||3.4.0 4.0.2 4.1.0 4.2.0 ||4.3.0 Known to work||3.3.3 Target Milestone|--- |4.1.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31498
[Bug fortran/31216] TRANSFER in CASE leads to ICE
-- brooks at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |brooks at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-03-16 19:50:30 |2007-04-06 22:58:01 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31216
[Bug testsuite/31369] 100's of new libgomp fails
--- Comment #4 from dave at hiauly1 dot hia dot nrc dot ca 2007-04-06
22:59 ---
Subject: Re: 100's of new libgomp fails
> Perhaps hppa64 needs the same change to libgomp.exp as in
> http://gcc.gnu.org/ml/gcc-patches/2007-03/msg01497.html ?
I don't think this is necessary.
> These tests all fail because shared libgcc library is not found.
Yes (well almost all). They fail because of whitespace in LD_LIBRARY_PATH
in the c++ and fortran tests. You can see it in the test log.
The enclosed change fixes the problem for me.
Dave
--
J. David Anglin [EMAIL PROTECTED]
National Research Council of Canada (613) 990-0752 (FAX: 952-6602)
Index: testsuite/libgomp.c++/c++.exp
===
--- testsuite/libgomp.c++/c++.exp (revision 123536)
+++ testsuite/libgomp.c++/c++.exp (working copy)
@@ -28,7 +28,7 @@
# Gather a list of all tests.
set tests [lsort [glob -nocomplain $srcdir/$subdir/*.C]]
-set ld_library_path [concat $always_ld_library_path
":${blddir}/${lang_library_path}"]
+set ld_library_path
"$always_ld_library_path:${blddir}/${lang_library_path}"
set_ld_library_path_env_vars
# Main loop.
Index: testsuite/libgomp.fortran/fortran.exp
===
--- testsuite/libgomp.fortran/fortran.exp (revision 123536)
+++ testsuite/libgomp.fortran/fortran.exp (working copy)
@@ -12,7 +12,7 @@
# Gather a list of all tests.
set tests [lsort [find $srcdir/$subdir *.\[fF\]{,90,95,03}]]
-set ld_library_path [concat $always_ld_library_path
":${blddir}/${lang_library_path}"]
+set ld_library_path
"$always_ld_library_path:${blddir}/${lang_library_path}"
set_ld_library_path_env_vars
# Main loop.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31369
[Bug fortran/31194] NaN transfer - internal compiler error: in gfc_conv_constant
-- brooks at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |brooks at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-03-16 20:24:20 |2007-04-06 23:00:09 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31194
[Bug c/31499] New: rejects vector int a[] = {1,1,1,1,1};
Testcase:
#define vector __attribute__((__vector_size__(16) ))
vector signed int v1[]={0,1,2,3,4,5,6,7};
The reason why I am saying this is valid code is two fold, one the C/C++
Language extension for CBEA says this is valid code and two the C++ front-end
accepts this.
--
Summary: rejects vector int a[] = {1,1,1,1,1};
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31499
[Bug fortran/31218] ICE on valid code with gfortran
--- Comment #2 from brooks at gcc dot gnu dot org 2007-04-06 23:06 ---
The following code repeats the ICE:
character(LEN=2), parameter :: a="a "
real, dimension(2,2), parameter :: r=1.0
character(LEN=4) :: b=REPEAT(a,2)
real, dimension(4) :: l=RESHAPE(r,(/4/))
character(LEN=3) :: c=TRIM("a ")
IF (b.NE."a a ") CALL ABORT()
IF (ANY(l.NE.1.0)) CALL ABORT()
IF (c.NE."a ") CALL ABORT()
END
This is thus not something coming from the lack of transfer constant-folding.
--
brooks at gcc dot gnu dot org changed:
What|Removed |Added
CC||brooks at gcc dot gnu dot
||org
OtherBugsDependingO|31237 |
nThis||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31218
[Bug fortran/31427] TRANSFER with mold kind /= lval kind: ICE on ia64, i686; no warning
-- brooks at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |brooks at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-04-03 17:54:10 |2007-04-06 23:11:11 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31427
[Bug fortran/31257] ICE in gfc_conv_expr_descriptor
--- Comment #2 from brooks at gcc dot gnu dot org 2007-04-06 23:12 --- This looks related to 31218, so I'm adding a dependency even though I'm not certain it's the same. Also confirming, because it's definitely a bug even if it's a duplicate one. -- brooks at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO||31218 nThis|| Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-04-06 23:12:54 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31257
[Bug testsuite/31369] 100's of new libgomp fails
--- Comment #5 from patchapp at dberlin dot org 2007-04-06 23:35 --- Subject: Bug number PR testsuite/31369 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/2007-04/msg00284.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31369
[Bug middle-end/31322] [4.3 Regression] ld: Invalid symbol type for plabel (.libs/debug_list.o, __gxx_personality_v0).
--- Comment #4 from dave at hiauly1 dot hia dot nrc dot ca 2007-04-06 23:44 --- Subject: Re: [4.3 Regression] ld: Invalid symbol type for plabel (.libs/debug_list.o, __gxx_personality_v0). > That would emit the reference only in situations where we're actually > going to need the personality routine. The reason for my earlier change > was that we were referencing it even when we'd optimized away all of the > EH information in the module. I'm sorry this broke HP-UX; let me know > if I can help. I must admit I'm to blame for this ;( Importing functions that aren't used doesn't cause a problem on HP-UX, but I can see that it might cause the routine to be unnecessarily included in an executable on other systems. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31322
[Bug middle-end/31322] [4.3 Regression] ld: Invalid symbol type for plabel (.libs/debug_list.o, __gxx_personality_v0).
--- Comment #5 from mark at codesourcery dot com 2007-04-07 00:01 --- Subject: Re: [4.3 Regression] ld: Invalid symbol type for plabel (.libs/debug_list.o, __gxx_personality_v0). dave at hiauly1 dot hia dot nrc dot ca wrote: > --- Comment #4 from dave at hiauly1 dot hia dot nrc dot ca 2007-04-06 > 23:44 --- > Subject: Re: [4.3 Regression] ld: Invalid symbol type for plabel > (.libs/debug_list.o, __gxx_personality_v0). > >> That would emit the reference only in situations where we're actually >> going to need the personality routine. The reason for my earlier change >> was that we were referencing it even when we'd optimized away all of the >> EH information in the module. I'm sorry this broke HP-UX; let me know >> if I can help. > > I must admit I'm to blame for this ;( > > Importing functions that aren't used doesn't cause a problem on HP-UX, > but I can see that it might cause the routine to be unnecessarily included > in an executable on other systems. Yes, the standard behavior for GNU as/ld on ELF systems is that a .globl emission in the .as file becomes an undefined symbol in the ELF object file, and the linker then pulls in files from an archive to satisfy that reference at link-time, even if there are no relocations against the symbol. One could reasonably argue that the linker shouldn't do this, but it does, and changing it might break things; people may well be relying on this trick. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31322
[Bug libstdc++/31117] c++locale.o thread-unsafe in libstdc++
--- Comment #34 from paolo at gcc dot gnu dot org 2007-04-07 00:37 --- Subject: Bug 31117 Author: paolo Date: Sat Apr 7 00:36:56 2007 New Revision: 123635 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123635 Log: 2007-04-06 Paolo Carlini <[EMAIL PROTECTED]> PR libstdc++/31117 * config/locale/gnu/c_locale.cc (__convert_to_v): Do not use errno, just check that the value is finite. * config/locale/generic/c_locale.cc (__convert_to_v): Likewise. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/config/locale/generic/c_locale.cc trunk/libstdc++-v3/config/locale/gnu/c_locale.cc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31117
[Bug libstdc++/31117] c++locale.o thread-unsafe in libstdc++
--- Comment #35 from pcarlini at suse dot de 2007-04-07 00:37 --- Fixed for 4.3.0. -- pcarlini at suse dot de changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31117
[Bug rtl-optimization/31500] New: FAIL: gcc.dg/Warray-bounds.c (internal compiler error)
Executing on host: /home/dave/gnu/gcc-4.3/objdir/gcc/xgcc -B/home/dave/gnu/gcc-4 .3/objdir/gcc/ /home/dave/gnu/gcc-4.3/gcc/gcc/testsuite/gcc.dg/Warray-bounds.c -O2 -Warray-bounds -fno-show-column -S -o Warray-bounds.s(timeout = 300) /home/dave/gnu/gcc-4.3/gcc/gcc/testsuite/gcc.dg/Warray-bounds.c: In function 'f' :^M /home/dave/gnu/gcc-4.3/gcc/gcc/testsuite/gcc.dg/Warray-bounds.c:21: warning: arr ay subscript is below array bounds^M /home/dave/gnu/gcc-4.3/gcc/gcc/testsuite/gcc.dg/Warray-bounds.c:27: warning: arr ay subscript is above array bounds^M /home/dave/gnu/gcc-4.3/gcc/gcc/testsuite/gcc.dg/Warray-bounds.c:28: warning: arr ay subscript is above array bounds^M /home/dave/gnu/gcc-4.3/gcc/gcc/testsuite/gcc.dg/Warray-bounds.c:29: warning: arr ay subscript is below array bounds^M /home/dave/gnu/gcc-4.3/gcc/gcc/testsuite/gcc.dg/Warray-bounds.c:32: warning: arr ay subscript is above array bounds^M /home/dave/gnu/gcc-4.3/gcc/gcc/testsuite/gcc.dg/Warray-bounds.c:34: warning: arr ay subscript is below array bounds^M /home/dave/gnu/gcc-4.3/gcc/gcc/testsuite/gcc.dg/Warray-bounds.c:38: warning: arr ay subscript is above array bounds^M /home/dave/gnu/gcc-4.3/gcc/gcc/testsuite/gcc.dg/Warray-bounds.c:39: warning: arr ay subscript is above array bounds^M /home/dave/gnu/gcc-4.3/gcc/gcc/testsuite/gcc.dg/Warray-bounds.c:40: warning: arr ay subscript is below array bounds^M /home/dave/gnu/gcc-4.3/gcc/gcc/testsuite/gcc.dg/Warray-bounds.c:43: warning: arr ay subscript is above array bounds^M /home/dave/gnu/gcc-4.3/gcc/gcc/testsuite/gcc.dg/Warray-bounds.c:45: warning: arr ay subscript is below array bounds^M /home/dave/gnu/gcc-4.3/gcc/gcc/testsuite/gcc.dg/Warray-bounds.c:49: warning: arr ay subscript is above array bounds^M /home/dave/gnu/gcc-4.3/gcc/gcc/testsuite/gcc.dg/Warray-bounds.c:50: warning: arr ay subscript is above array bounds^M /home/dave/gnu/gcc-4.3/gcc/gcc/testsuite/gcc.dg/Warray-bounds.c:51: warning: arr ay subscript is below array bounds^M /home/dave/gnu/gcc-4.3/gcc/gcc/testsuite/gcc.dg/Warray-bounds.c:54: warning: arr ay subscript is above array bounds^M /home/dave/gnu/gcc-4.3/gcc/gcc/testsuite/gcc.dg/Warray-bounds.c:59: warning: arr ay subscript is above array bounds^M /home/dave/gnu/gcc-4.3/gcc/gcc/testsuite/gcc.dg/Warray-bounds.c:60: warning: arr ay subscript is above array bounds^M /home/dave/gnu/gcc-4.3/gcc/gcc/testsuite/gcc.dg/Warray-bounds.c:65: warning: arr ay subscript is above array bounds^M /home/dave/gnu/gcc-4.3/gcc/gcc/testsuite/gcc.dg/Warray-bounds.c:66: warning: arr ay subscript is above array bounds^M /home/dave/gnu/gcc-4.3/gcc/gcc/testsuite/gcc.dg/Warray-bounds.c:67: warning: arr ay subscript is above array bounds^M /home/dave/gnu/gcc-4.3/gcc/gcc/testsuite/gcc.dg/Warray-bounds.c:73: warning: arr ay subscript is above array bounds^M /home/dave/gnu/gcc-4.3/gcc/gcc/testsuite/gcc.dg/Warray-bounds.c:74: warning: arr ay subscript is above array bounds^M /home/dave/gnu/gcc-4.3/gcc/gcc/testsuite/gcc.dg/Warray-bounds.c:90: warning: arr ay subscript is above array bounds^M /home/dave/gnu/gcc-4.3/gcc/gcc/testsuite/gcc.dg/Warray-bounds.c:93: error: Attem pt to delete prologue/epilogue insn:^M (insn/f 274 273 275 2 (set (mem:SI (plus:SI (reg/f:SI 30 %r30)^M (const_int -100 [0xff9c])) [0 S4 A32])^M (reg:SI 4 %r4)) -1 (nil)^M (nil))^M /home/dave/gnu/gcc-4.3/gcc/gcc/testsuite/gcc.dg/Warray-bounds.c:93: internal com piler error: in propagate_one_insn, at flow.c:1735^M Please submit a full bug report,^M with preprocessed source if appropriate.^M See http://gcc.gnu.org/bugs.html> for instructions.^M compiler exited with status 1 g++.dg/warn/Warray-bounds.C also fails in a similar manner. -- Summary: FAIL: gcc.dg/Warray-bounds.c (internal compiler error) Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org GCC build triplet: hppa*-*-* (32-bit) GCC host triplet: hppa*-*-* (32-bit) GCC target triplet: hppa*-*-* (32-bit) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31500
[Bug rtl-optimization/31500] FAIL: gcc.dg/Warray-bounds.c (internal compiler error)
--- Comment #1 from dave at hiauly1 dot hia dot nrc dot ca 2007-04-07 01:35 --- Subject: Re: New: FAIL: gcc.dg/Warray-bounds.c (internal compiler error) The tests have been failing since they were added last January. Dave --- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca 2007-04-07 01:35 --- Created an attachment (id=13335) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13335&action=view) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31500
[Bug libfortran/31501] New: libgfortran I/O performance issues
Keeping in mind that correct is better than fast. I would like to start looking at refactoring the I/O library to eliminate some of the overhead. Beginning with internal units where there is no need for alloc buffering like we do now, Flat profile: Each sample counts as 0.01 seconds. % cumulative self self total time seconds secondscalls ms/call ms/call name 18.02 1.84 1.84 next_char 10.87 2.95 1.11 _gfortrani_read_sf 7.84 3.75 0.80 _gfortrani_is_array_io 5.83 4.35 0.60 memcpy 5.83 4.94 0.60 push_char 5.68 5.52 0.58 read_real 5.58 6.09 0.57 strtod_l_internal 5.19 6.62 0.53 fd_alloc_r_at 4.60 7.09 0.47 mem_alloc_r_at 3.92 7.49 0.40 eat_spaces 3.77 7.88 0.39 _gfortrani_is_stream_io 2.89 8.17 0.30 list_formatted_read_scalar 2.55 8.43 0.26 _gfortrani_is_internal_unit 2.25 8.66 0.23 __read_nocancel 1.13 8.78 0.12 _gfortran_transfer_array 1.08 8.89 0.11 _gfortrani_convert_real 1.08 9.00 0.11 nml_bad_return 0.88 9.09 0.09 eat_line 0.88 9.18 0.09 str_to_mpn 0.83 9.26 0.09 _gfortrani_list_formatted_read 0.78 9.34 0.08 __lseek_nocancel -- Summary: libgfortran I/O performance issues Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jvdelisle at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31501
[Bug libfortran/31501] libgfortran I/O performance issues
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2007-04-07 01:45 --- Created an attachment (id=13336) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13336&action=view) Test case used to get a profile This is a reference test case we can use to measure progress. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31501
[Bug rtl-optimization/31500] FAIL: gcc.dg/Warray-bounds.c (internal compiler error)
--- Comment #3 from dave at hiauly1 dot hia dot nrc dot ca 2007-04-07
03:37 ---
Subject: Re: FAIL: gcc.dg/Warray-bounds.c (internal compiler error)
The ICE is caused by the presence of this insn:
(insn 124 118 128 2 (set (mem/s:SI (plus:SI (reg/f:SI 30 %r30)
(const_int -100 [0xff9c])) [4 c.c+44 S4 A32])
(const_int 0 [0x0])) 37 {*pa.md:2537} (nil)
(nil))
The insn is emitted during expand as:
;; c.c[11] = 0
(insn 124 122 0 (set (mem/s:SI (plus:SI (reg/f:SI 90 virtual-stack-vars)
(const_int 84 [0x54])) [4 c.c+44 S4 A32])
(const_int 0 [0x0])) -1 (nil)
(nil))
The fact that we have a conflict with a memory location used for
a general register save suggests that there is a problem with the
size of the frame for this function.
Dave
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31500
[Bug rtl-optimization/31500] FAIL: gcc.dg/Warray-bounds.c (internal compiler error)
--- Comment #4 from dave at hiauly1 dot hia dot nrc dot ca 2007-04-07 04:08 --- Subject: Re: FAIL: gcc.dg/Warray-bounds.c (internal compiler error) > ;; c.c[11] = 0 Ok, so out-of-bounds array writes in user code can cause the compiler to ICE. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31500
