[Bug bootstrap/25511] bootstrap-lean fails
--- Comment #1 from prj-bugzilla-gcc at multivac dot cwru dot edu 2005-12-21 07:11 --- Created an attachment (id=10540) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10540&action=view) 3.4.5 bootstrap-lean build log -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25511
[Bug bootstrap/25511] New: bootstrap-lean fails
bootstrap-lean fails for me with gcc 3.4.3-3.4.5. It looks like it goes through the bootstrap, comparison, and deletion of stage2, but then tries to use stage2 to build the runtime libraries. -- Summary: bootstrap-lean fails Product: gcc Version: 3.4.5 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: prj-bugzilla-gcc at multivac dot cwru dot edu GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25511
[Bug fortran/24268] gfortran rejects valid format statement
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2005-12-21 06:56 --- This is now fixed for the specific test case. 4.1 and 4.2 are in sync. I plan to go back and review for other possible cases of whitespace. Just want to keep this synchronized. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24268
[Bug fortran/24268] gfortran rejects valid format statement
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2005-12-21 06:52 --- Subject: Bug 24268 Author: jvdelisle Date: Wed Dec 21 06:52:38 2005 New Revision: 108900 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108900 Log: 2005-12-20 Jerry DeLisle <[EMAIL PROTECTED]> PR fortran/24268 * gfortran.dg/fmt_white.f: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/fmt_white.f Modified: branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24268
[Bug fortran/24268] gfortran rejects valid format statement
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2005-12-21 06:51 --- Subject: Bug 24268 Author: jvdelisle Date: Wed Dec 21 06:51:02 2005 New Revision: 108899 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108899 Log: 2005-12-20 Jerry DeLisle <[EMAIL PROTECTED]> PR fortran/24268 * io.c (format_lex): Allow whitespace within text of format specifier. Modified: branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/io.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24268
[Bug tree-optimization/25382] VRP does not get a range from BIT_AND_EXPR if the second operand is constant
-- kazu at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25382
[Bug tree-optimization/25382] VRP does not get a range from BIT_AND_EXPR if the second operand is constant
--- Comment #2 from kazu at gcc dot gnu dot org 2005-12-21 05:58 --- Just checked in a patch. -- kazu at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25382
[Bug libfortran/25510] Add ERROR_INTERNAL and ERROR_INTERNAL_UNIT
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2005-12-21 05:58 --- Possible places to check. If the error is on actual file IO will leave it as is: io/file_pos.c: generate_error (&fpp->common, ERROR_OS, NULL); io/file_pos.c: generate_error (&fpp->common, ERROR_OS, NULL); io/file_pos.c: generate_error (&fpp->common, ERROR_OS, NULL); io/list_read.c: generate_error (&dtp->common, ERROR_OS, NULL); io/list_read.c: generate_error (&dtp->common, ERROR_OS, NULL); io/open.c: generate_error (&opp->common, ERROR_OS, NULL); io/open.c: generate_error (&opp->common, ERROR_OS, NULL); io/open.c: generate_error (&opp->common, ERROR_OS, NULL); io/open.c:generate_error (&opp->common, ERROR_OS, io/transfer.c: generate_error (&dtp->common, ERROR_OS, NULL); io/transfer.c:generate_error (&dtp->common, ERROR_OS, NULL); io/transfer.c: generate_error (&dtp->common, ERROR_OS, NULL); io/transfer.c:generate_error (&dtp->common, ERROR_OS, NULL); io/transfer.c:generate_error (&dtp->common, ERROR_OS, NULL); io/transfer.c: generate_error (&dtp->common, ERROR_OS, NULL); io/transfer.c:generate_error (&dtp->common, ERROR_OS, NULL); io/transfer.c:generate_error (&dtp->common, ERROR_OS, NULL); io/transfer.c:generate_error (&dtp->common, ERROR_OS, NULL); io/transfer.c: generate_error (&dtp->common, ERROR_OS, NULL); io/transfer.c: generate_error (&dtp->common, ERROR_OS, NULL); io/transfer.c:generate_error (&dtp->common, ERROR_OS, NULL); -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Summary|Add ERROR_INTERNAL and |Add ERROR_INTERNAL and |ERROR_INTERNAL_UNIT |ERROR_INTERNAL_UNIT http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25510
[Bug tree-optimization/25382] VRP does not get a range from BIT_AND_EXPR if the second operand is constant
--- Comment #1 from kazu at gcc dot gnu dot org 2005-12-21 05:58 --- Subject: Bug 25382 Author: kazu Date: Wed Dec 21 05:58:02 2005 New Revision: 108898 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108898 Log: gcc/ PR tree-optimization/25382. * tree-vrp.c (extract_range_from_binary_expr): Extract a range from BIT_AND_EXPR. gcc/testsuite/ PR tree-optimization/25382. * gcc.dg/tree-ssa/pr25382.c: New. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/pr25382.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vrp.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25382
[Bug libfortran/25510] New: Add ERROR_INTERNAL and ERROR_INTERNAL_UNIT
Need new error types to provide clearer messages rather that use ERROR_OS which for internal problems reports a run-time error of 'Success'. -- Summary: Add ERROR_INTERNAL and ERROR_INTERNAL_UNIT Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran AssignedTo: jvdelisle at gcc dot gnu dot org ReportedBy: jvdelisle at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25510
[Bug libfortran/25463] T edit descriptor and ADVANCE="no"
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2005-12-21 05:09 --- Subject: Bug 25463 Author: jvdelisle Date: Wed Dec 21 05:08:53 2005 New Revision: 108897 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108897 Log: 2005-12-20 Jerry DeLisle <[EMAIL PROTECTED]> PR libgfortran/25463 * gfortran.dg/advance.f90: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/advance.f90 Modified: branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25463
[Bug libfortran/25463] T edit descriptor and ADVANCE="no"
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2005-12-21 04:50 --- Subject: Bug 25463 Author: jvdelisle Date: Wed Dec 21 04:50:19 2005 New Revision: 108896 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108896 Log: 2005-12-20 Jerry DeLisle <[EMAIL PROTECTED]> PR libgfortran/25463 * io/transfer.c (finalize_transfer): Fix execution order so that next_record is set to zero in all cases. Modified: branches/gcc-4_1-branch/libgfortran/ChangeLog branches/gcc-4_1-branch/libgfortran/io/transfer.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25463
[Bug middle-end/25328] [4.0/4.1 regression] ICE in get_indirect_ref_operands, at tree-ssa-operands.c:1453
--- Comment #6 from law at redhat dot com 2005-12-21 04:44 ---
Definitely a type problem. The Obj-C front-end is playing it too lose with
types.
main (argc, argv)
{
char msg[100];
int status;
const unsigned char D.1189;
char * msg.0;
# BLOCK 0
# PRED: ENTRY (fallthru)
# msg_3 = V_MUST_DEF ;
msg = "";
msg.0_4 = &msg; /* Mis-matched types here */
# VUSE ;
D.1189_5 = *msg.0_4; /* And again here. */
return;
# SUCC: EXIT
}
I *think* the right code is that msg.0 should have type
const unsigned char *. In the assignment to msg.0_4 the
RHS should be casted to const unsigned char *
This is a front-end problem as far as I can tell.
Jeff
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25328
[Bug middle-end/25328] [4.0/4.1 regression] ICE in get_indirect_ref_operands, at tree-ssa-operands.c:1453
--- Comment #5 from law at redhat dot com 2005-12-21 04:33 --- Was able to reproduce with gcc-4.0 branch sources. Investigating, looks like we might have a type botch somewhere... Jeff -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25328
[Bug c/25509] can't voidify __attribute__((warn_unused_result))
--- Comment #8 from mueller at kde dot org 2005-12-21 04:17 --- > ok, lets assume that you meant with "can not be ignored" actually "must not > > be ignored". now thats where the definitions in RFC2119 kick in: Hmm, that wasn't meant so harsh than it sounds after rereading. sorry about that. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25509
[Bug c/25509] can't voidify __attribute__((warn_unused_result))
--- Comment #7 from mueller at kde dot org 2005-12-21 04:02 --- ok, lets assume that you meant with "can not be ignored" actually "must not be ignored". now thats where the definitions in RFC2119 kick in: 2. MUST NOT This phrase, or the phrase "SHALL NOT", mean that the definition is an absolute prohibition of the specification. 4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label. The documentation correctly states SHOULD NOT, and thats distinctively different from MUST NOT. I already agreed that glibc is over the top, nevertheless the (void)ify trick doesn't suppress the warning, and either that behaviour is a bug or the behaviour that assigning to a dummy variable (which is never read and therefore dead storage) doesn't warn is a bug. you choose. -- mueller at kde dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25509
[Bug c/25509] can't voidify __attribute__((warn_unused_result))
--- Comment #6 from joseph at codesourcery dot com 2005-12-21 03:55 --- Subject: Re: can't voidify __attribute__((warn_unused_result)) On Wed, 21 Dec 2005, pinskia at gcc dot gnu dot org wrote: > The reason why it is a glibc bug is that it is very over the top of adding the > attribute here. And indeed there is no logical difference between printf and fwrite here, but glibc is marking fwrite and not printf. In both cases, a valid programming style is to use fflush and ferror at the end to check for errors, rather than checking on every write, or to check the return value of fclose. A program that uses fwrite without checking the return value or such a subsequent error is buggy - so is one using printf and failing later to check for errors on stdout. (GCC is among such buggy programs; "gcc --help >/dev/full" does not return error status as it should.) But checking at the end suffices (albeit losing information about the value of errno for the original error), you don't need to check at every call. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25509
[Bug c/25509] can't voidify __attribute__((warn_unused_result))
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-12-21 03:47 --- Actually it is documented that this is acting the way it is acting, just not with the docs of the attributes: Warning when a non-void function value is ignored. C contains many standard functions that return a value that most programs choose to ignore. One obvious example is printf. Warning about this practice only leads the defensive programmer to clutter programs with dozens of casts to void. Such casts are required so frequently that they become visual noise. Writing those casts becomes so automatic that they no longer convey useful information about the intentions of the programmer. For functions where the return value should never be ignored, use the warn_unused_result function attribute (see Function Attributes). "should never" means it cannot be the result cannot be ignored at all (well assigning to a variable and ignoring that is a work around). As shown this is not a GCC bug as GCC is acting as documented. The reason why it is a glibc bug is that it is very over the top of adding the attribute here. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25509
[Bug c/25509] can't voidify __attribute__((warn_unused_result))
--- Comment #4 from mueller at kde dot org 2005-12-21 03:35 --- Care to explain how it is a glibc bug? its not documented that there shouldn't be a way to suppress the warning. I agree glibc is overly paranoid and pedantic, but that doesn't make it less of a gcc issue. -- mueller at kde dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25509
[Bug other/20939] ld segmentation fault linking libgfortran.sl.0.0
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Priority|P2 |P3 Summary|[4.1/4.2 Regression] ld |ld segmentation fault |segmentation fault linking |linking libgfortran.sl.0.0 |libgfortran.sl.0.0 | Target Milestone|4.1.0 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20939
[Bug c/25509] can't voidify __attribute__((warn_unused_result))
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-12-21 03:20 --- This is a glibc bug and not a GCC bug then. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25509
[Bug libgcj/25026] -libXtst not detected [--enable-java-awt=gtk]
--- Comment #2 from smithj at rpath dot com 2005-12-21 02:51 --- oh, and i also get this on 4.0.2, the 4.0 weekly snapshots, and the 4.2 snapshots (sorry, i meant to say that in the first post) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25026
[Bug c++/25369] [3.4/4.0/4.1/4.2 Regression] use of inline function in template class leads to undefined reference
--- Comment #8 from reichelt at gcc dot gnu dot org 2005-12-21 02:49
---
Confirmed. Reduced testcase:
==
template struct A
{
void foo() {}
};
void bar(void (A::*)()) {}
template void baz()
{
bar(&A::foo);
}
int main()
{
baz<0>();
return 0;
}
==
This fails to link since gcc 3.4.4.
I.e. we have a regression on the 3.4 branch. Ouch.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
CC||reichelt at gcc dot gnu dot
||org
Status|WAITING |NEW
Ever Confirmed|0 |1
Keywords||monitored
Known to fail||3.4.4 3.4.5 4.0.0 4.1.0
Known to work|3.3.5 |3.3.5 3.3.6 3.4.0 3.4.3
Last reconfirmed|-00-00 00:00:00 |2005-12-21 02:49:44
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25369
[Bug libgcj/25026] -libXtst not detected [--enable-java-awt=gtk]
--- Comment #1 from smithj at rpath dot com 2005-12-21 02:49 --- I have this issue as well, but only with x86_64; x86 configures and compiles fine. x11 and gcc are both built with the same configure options between the archs. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25026
[Bug c++/25364] [4.0/4.1/4.2 Regression] Internal compiler error in templated C++
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25364
[Bug c/25509] can't voidify __attribute__((warn_unused_result))
--- Comment #2 from mueller at kde dot org 2005-12-21 00:07 --- background: glibc 2.3 CVS attributes "fwrite" and "write" with it, and it causes a lot (in the hundreds/thousands) of false positives for bigger software projects, because while it is indeed the case that they ignore the return value, it simply doesn't matter for the application (if, for example, it is used as debug output). Yes, write(2) can fail, but there are cases where the application can't possibly do anything about it, or even cares. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25509
[Bug c/25509] can't voidify __attribute__((warn_unused_result))
--- Comment #1 from joseph at codesourcery dot com 2005-12-20 23:53 --- Subject: Re: New: can't voidify __attribute__((warn_unused_result)) On Tue, 20 Dec 2005, mueller at kde dot org wrote: > casting to (void) doesn't avoid the unused_result warning. testcase: Why do you think this is a bug? warn_unused_result is for cases where "not checking the result is either a security problem or always a bug". -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25509
[Bug c/25509] New: can't voidify __attribute__((warn_unused_result))
casting to (void) doesn't avoid the unused_result warning. testcase:
=== Cut ===
extern int foo() __attribute__((warn_unused_result));
int main()
{
(void) foo();
return 0;
}
=== Cut ===
g++ -Wall -W -O2 -c unused.cc
unused.cc: In function 'int main()':
unused.cc:4: warning: ignoring return value of 'int foo()', declared with
attribute warn_unused_result
--
Summary: can't voidify __attribute__((warn_unused_result))
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mueller at kde dot org
GCC host triplet: i686-suse-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25509
[Bug rtl-optimization/25505] [4.0/4.1/4.2 Regression] gcc uses way too much stack space for this code
--- Comment #8 from pinskia at gcc dot gnu dot org 2005-12-20 21:53 --- This looks very much related to PR 16269. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||16269 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25505
[Bug rtl-optimization/25505] [4.0/4.1/4.2 Regression] gcc uses way too much stack space for this code
--- Comment #7 from pinskia at gcc dot gnu dot org 2005-12-20 21:50 ---
(In reply to comment #6)
> Re: comment #5:
>
> That is a similar testcase, but not an identical one. A better one would be
> something like:
Actually GCC gets the following testcase "correct":
typedef struct a
{
int f[1000];
} a;
a f(void);
int g(void)
{
{ a t = f();}
{ a t = f();}
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25505
[Bug rtl-optimization/25505] [4.0/4.1/4.2 Regression] gcc uses way too much stack space for this code
--- Comment #6 from sabre at nondot dot org 2005-12-20 21:47 ---
Re: comment #5:
That is a similar testcase, but not an identical one. A better one would be
something like:
void foo() {
if (...) {
std::pair = ..
...
}
if (...) {
std::pair = ..
...
}
if (...) {
std::pair = ..
...
}
}
Further, a huge amount of the wastage appears to be coming from C++
temporaries, not explicit variable definitions.
-Chris
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25505
[Bug rtl-optimization/25505] [4.0/4.1/4.2 Regression] gcc uses way too much stack space for this code
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-12-20 21:44 ---
Small testcase:
typedef struct a
{
int f[1000];
} a;
a f(void);
int g(void)
{
f();
f();
}
Note that the C front-end has always produced bad stack usage.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Keywords||missed-optimization
Known to fail||4.0.0 4.1.0 4.2.0
Known to work||3.3.3
Last reconfirmed|-00-00 00:00:00 |2005-12-20 21:44:03
date||
Summary|gcc uses way too much stack |[4.0/4.1/4.2 Regression] gcc
|space for this code |uses way too much stack
||space for this code
Target Milestone|--- |4.0.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25505
[Bug middle-end/25328] [4.0/4.1 regression] ICE in get_indirect_ref_operands, at tree-ssa-operands.c:1453
--- Comment #4 from law at redhat dot com 2005-12-20 21:33 --- I've been unable to reproduce this with the gcc-4.1 branch sources. IT's going to be awful difficult to fix if I can't reproduce the problem. At the very least I'll need the before-dom dumps and some analysis of whatever transformation is causing the problem. Note that a failure to fold is more likely a symptom of a problem elsewhere, like mucked up types and such -- which may also explain why this has been reported as front-end specific. Jeff -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25328
[Bug other/25508] New: MULTILIB_OSDIRNAMES undocumented
MULTILIB_OSDIRNAMES, as used in target makefile fragments t-*, is undocumented. -- Summary: MULTILIB_OSDIRNAMES undocumented Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jsm28 at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25508
[Bug other/25507] New: -print-multi-os-directory undocumented
The command-line option -print-multi-os-directory is undocumented. -- Summary: -print-multi-os-directory undocumented Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jsm28 at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25507
[Bug fortran/25423] Error with nested where statements
--- Comment #2 from eedelman at gcc dot gnu dot org 2005-12-20 21:26 --- Working on a patch. -- eedelman at gcc dot gnu dot org changed: What|Removed |Added CC||eedelman at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25423
[Bug ada/24994] raised STORAGE_ERROR : stack overflow or erroneous memory access
--- Comment #10 from laurent at guerby dot net 2005-12-20 21:19 --- Bootstrap started to fail after the following patch: Index: gcc/ChangeLog === --- gcc/ChangeLog (revision 108421) +++ gcc/ChangeLog (revision 108425) @@ -1,3 +1,23 @@ +2005-12-12 Jeff Law <[EMAIL PROTECTED]> + + * tree-ssa-dom.c (simplify_rhs_and_lookup_avail_expr): Remove + reassociation code. + * passes.c (init_optimization_passes): Run reassociation again + after loop optimizations. + +2005-12-12 Daniel Berlin <[EMAIL PROTECTED]> + + * tree-ssa-dom.c (thread_across_edge): Canonicalize condition + if necessary. + (optimize_stmt): Ditto. + (canonicalize_comparison): New function. + * tree-ssa-operands.c (swap_tree_operands): Make external. + (get_expr_operands): Stop auto-canonicalization. + * tree-ssa-reassoc.c: Rewrite. + (init_optimization_passes): + * tree-flow.h (swap_tree_operands): Prototype. + * Makefile.in (tree-ssa-reassoc.o): Update dependencies. + -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24994
[Bug tree-optimization/24793] [4.1 Regression] ICE: expected ssa_name, have var_decl in verify_ssa, at tree-ssa.c:746
--- Comment #12 from rguenth at gcc dot gnu dot org 2005-12-20 20:54 --- Zdenek, please apply to 4.1, too. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24793
Important
Salut ! Royal Contact a maintenant décidé d'orienter sa clientèle dans la tranche d'âge entre 18 et 40 ans. Une publicité sera faite dans les CEGEPS et Universités pour recrutter du nouveau monde. Si vous êtes dans cette tranche d'âge, Faites-vous une fiche sur le site et une fois entré, cliquez le lien pour contacter l'administration. Inscrivez votre nick et dites que vous aimeriez être membre privilège. Si votre profil comporte une photo, toutes les options y compris la salle video vous seront offertes gratuitement pour toute la période de la promotion de départ. Profitez-en pendant que ça passe. Joyeux Noel et au plaisir de vous voir sur Royal Contact. www.royalcontact.com
[Bug rtl-optimization/25505] gcc uses way too much stack space for this code
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-12-20 20:20 --- at -O2 -fno-schedule-insns on the mainline: stwu r1,-17088(r1) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25505
[Bug rtl-optimization/25505] gcc uses way too much stack space for this code
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-12-20 20:18 --- 3.3 at -O2 -fno-schedule-insns gave: stwu r1,-4016(r1) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25505
[Bug rtl-optimization/25505] gcc uses way too much stack space for this code
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-12-20 20:15 --- At -O0 in 4.2.0, we have: stwu r1,-7920(r1) as the max. so that is 8k (I have not looked into why there is 8k). -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Known to fail|4.0.1 | Known to work|3.3 | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25505
[Bug middle-end/23518] some gcc optimizations do not take overflow into account with -fwrapv
--- Comment #4 from kazu at gcc dot gnu dot org 2005-12-20 19:58 --- I've got a patch. -- kazu at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |kazu at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Known to fail|3.4.0 4.0.0 4.1.0 |3.4.0 4.0.0 4.1.0 4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23518
[Bug rtl-optimization/25505] gcc uses way too much stack space for this code
--- Comment #1 from sabre at nondot dot org 2005-12-20 19:57 --- Created an attachment (id=10537) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10537&action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25505
[Bug rtl-optimization/25505] New: gcc uses way too much stack space for this code
The SelectCode function requires a huge amount of stack space (over 20K on darwin-PPC with GCC 4.x. With GCC 3.3 it only took 512 bytes of stack space. -Chris -- Summary: gcc uses way too much stack space for this code Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sabre at nondot dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25505
[Bug c/25504] -ansi -Wall should warn about variable-size arrays
--- Comment #4 from giles at xiph dot org 2005-12-20 18:46 --- I think you misunderstood. This is not about rejecting C99 code, this about warning about portability. I understand it is a C99 feature as well as an long-standing gnu extension, and -pedantic doesn't reject the program, it just prints a warning. If the correct was to generate warnings for source that isn't compliant to the selected standard (and the documentation says -ansi is the same as -std=c89) is to include -pedantic then the documentation should say so. If, as the name suggests, -pedantic is for issues that aren't likely to trouble one in practice, then either '-ansi -Wall' or vanilla '-ansi' should warn about this C99 feature precisely because it is not portable to another major compiler in common use. This would provides helpful assistance to programmers and reduce the number of portability bugs people must file, track down, and fix. If one were happy with the portability of the default gnu89 or gnu99 C, one wouldn't be adding -ansi to the commandline. :P -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25504
[Bug c/25504] -ansi -Wall should warn about variable-size arrays
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-12-20 18:26 --- This is not really a bug: -ansi In C mode, support all ISO C90 programs. In C++ mode, remove GNU extensions that conflict with ISO C++. The -ansi option does not cause non-ISO programs to be rejected gratuitously. For that, -pedantic is required in addition to -ansi. And since this extension is also part of C99. This is not a bug really. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25504
[Bug c/25504] -ansi -Wall should warn about variable-size arrays
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-12-20 18:23 --- I should note that variable-sized arrays are part of C99. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25504
[Bug c/25504] -ansi -Wall should warn about variable-size arrays
--- Comment #1 from giles at xiph dot org 2005-12-20 18:22 --- Created an attachment (id=10536) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10536&action=view) example which should trigger the warning behavior Here's an example which triggers the warning (or lack thereof) we ran into. Also, for the record this is gcc from Ubuntu 5.10 "Breezy Badger" on x86, $ gcc --version gcc (GCC) 4.0.2 20050808 (prerelease) (Ubuntu 4.0.1-4ubuntu9) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25504
[Bug c/25504] New: -ansi -Wall should warn about variable-size arrays
I generally expect 'gcc -ansi -Wall' to catch non-portable code, but it does not throw a warning about variable-size arrays. 'gcc -ansi -pedantic' does throw an appropriate warning. However, it appears that MSVC still doesn't support this feature, and so I think it would be more appropriate to throw a warning either with '-ansi -Wall' or just with '-ansi' without requiring -pedantic to reflect the danger using this feature. -- Summary: -ansi -Wall should warn about variable-size arrays Product: gcc Version: 4.0.2 Status: UNCONFIRMED Severity: minor Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: giles at xiph dot org GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25504
[Bug target/23482] [ColdFire] ICE in in final_scan_insn
--- Comment #3 from pbrook at gcc dot gnu dot org 2005-12-20 18:15 --- *** Bug 25136 has been marked as a duplicate of this bug. *** -- pbrook at gcc dot gnu dot org changed: What|Removed |Added CC||kazu at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23482
[Bug target/25136] FAIL: gcc.c-torture/compile/20050303-1.c -O0
--- Comment #1 from pbrook at gcc dot gnu dot org 2005-12-20 18:15 --- Looks like a dup of PR23482 *** This bug has been marked as a duplicate of 23482 *** -- pbrook at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25136
[Bug fortran/25458] [4.1] Kind of constants in generic intrinsics
--- Comment #5 from kargl at gcc dot gnu dot org 2005-12-20 18:15 --- Subject: Bug 25458 Author: kargl Date: Tue Dec 20 18:15:19 2005 New Revision: 108861 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108861 Log: 2005-12-20 Steven G. Kargl <[EMAIL PROTECTED]> Tobias Schlueter <[EMAIL PROTECTED]> PR fortran/25458 * simplify.c (gfc_simplify_ibset, gfc_simplify_not): Add call to twos_complement. 2005-12-20 Steven G. Kargl <[EMAIL PROTECTED]> * PR fortran/25458 * gfortran.dg/chkbits.f90: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/chkbits.f90 Modified: branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/simplify.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25458
[Bug preprocessor/25240] [OPENMP] _Pragma parsing problem on the gomp branch
--- Comment #3 from rth at gcc dot gnu dot org 2005-12-20 18:00 --- Fixed. -- rth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25240
[Bug target/23482] [ColdFire] ICE in in final_scan_insn
--- Comment #2 from pbrook at gcc dot gnu dot org 2005-12-20 17:48 --- Patch here: http://gcc.gnu.org/ml/gcc-patches/2005-12/msg01534.html -- pbrook at gcc dot gnu dot org changed: What|Removed |Added Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23482
[Bug preprocessor/25240] [OPENMP] _Pragma parsing problem on the gomp branch
--- Comment #2 from rth at gcc dot gnu dot org 2005-12-20 17:40 --- Subject: Bug 25240 Author: rth Date: Tue Dec 20 17:40:17 2005 New Revision: 108859 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108859 Log: PR preprocessor/25240 * directives.c (run_directive): Remove pragma hacks. (destringize_and_run): Save tokens for deferred pragmas. * internal.h (_cpp_push_token_context): Declare. * macro.c (builtin_macro): Remove pragma token hack. (_cpp_push_token_context): Rename from push_token_context and export. Added: branches/gomp-20050608-branch/gcc/testsuite/gcc.dg/weak/weak-15.c Modified: branches/gomp-20050608-branch/libcpp/ChangeLog.gomp branches/gomp-20050608-branch/libcpp/directives.c branches/gomp-20050608-branch/libcpp/internal.h branches/gomp-20050608-branch/libcpp/macro.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25240
[Bug target/25259] bootstrap failures on non-C99 platforms
--- Comment #10 from ebotcazou at gcc dot gnu dot org 2005-12-20 17:29 --- > Created an attachment (id=10535) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10535&action=view) [edit] > fix the #ifndef -> use #ifdef instead Much better! However: stage1/xgcc -Bstage1/ -B/opt/build/eric/local/gcc/sparc-sun-solaris2.5.1/bin/ -c -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wold-style-definition -Wmissing-format-attribute -Werror -fno-common -DHAVE_CONFIG_H -I. -I. -I/home/eric/svn/gcc/gcc -I/home/eric/svn/gcc/gcc/. -I/home/eric/svn/gcc/gcc/../include -I./../intl -I/home/eric/svn/gcc/gcc/../libcpp/include -I/opt/build/eric/local/include -I/opt/build/eric/local/include -I/home/eric/svn/gcc/gcc/../libdecnumber -I../libdecnumber/home/eric/svn/gcc/gcc/dfp.c -o dfp.o cc1: warnings being treated as errors In file included from /home/eric/svn/gcc/gcc/../libdecnumber/decContext.h:43, from /home/eric/svn/gcc/gcc/../libdecnumber/decNumber.h:30, from /home/eric/svn/gcc/gcc/../libdecnumber/decimal128.h:50, from /home/eric/svn/gcc/gcc/dfp.c:34: ../libdecnumber/gstdint.h:41: warning: type defaults to 'int' in declaration of'int16_t' gmake[2]: *** [dfp.o] Error 1 gmake[2]: Leaving directory `/opt/build/eric/gcc/gcc' #ifndef _UINT16_T #define _UINT16_T typedef unsigned uint16_t; #endif #ifndef _INT16_T #define _INT16_T typedef int16_t; #endif -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25259
[Bug middle-end/24306] [3.4/4.0 Regression] va_arg gets confused when skipping over certain zero-sized types with -msse
--- Comment #9 from rguenth at gcc dot gnu dot org 2005-12-20 17:24 --- Fixed on head and 4.1. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Known to fail|3.4.0 4.0.0 4.1.0 |3.4.0 4.0.0 Known to work|3.3.3 4.2.0 |3.3.3 4.2.0 4.1.0 Summary|[3.4/4.0/4.1 Regression]|[3.4/4.0 Regression] va_arg |va_arg gets confused when |gets confused when skipping |skipping over certain zero- |over certain zero-sized |sized types with -msse |types with -msse http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24306
[Bug c++/25260] [4.0/4.1/4.2 Regression] Forward explicit intantiation declaration doesn't mix well with static integral member
--- Comment #6 from gdr at integrable-solutions dot net 2005-12-20 17:23
---
Subject: Re: [4.0/4.1/4.2 Regression] Forward explicit intantiation
declaration doesn't mix well with static integral member
"fang at csl dot cornell dot edu" <[EMAIL PROTECTED]> writes:
| Subject: Re: [4.0/4.1/4.2 Regression] Forward explicit
| intantiation declaration doesn't mix well with static integral member
|
| > --- Comment #3 from nicos at maunakeatech dot com 2005-12-20 09:20
---
| > I was under the belief that out of class definitions of const static
integral
| > members was optional for gcc and that static const N = k; was equivalent to
| > enum { N = k};, was I wrong ?
|
| in-class definitions of static const integral types are *permitted* in
| lieu of out-of-class definitions -- but you need one or the other. Also
| enums are never allocated memory in object files (data section), as per
| W.B.'s remark.
For me, this discussion is yet another evidence for the remark
"that is a misfeature" (about the whole in-class initialization for
const integral business) that could be found in earlier printings of TC++PL3.
-- Gaby
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25260
[Bug middle-end/24306] [3.4/4.0/4.1 Regression] va_arg gets confused when skipping over certain zero-sized types with -msse
--- Comment #8 from rguenth at gcc dot gnu dot org 2005-12-20 17:23 --- Subject: Bug 24306 Author: rguenth Date: Tue Dec 20 17:23:12 2005 New Revision: 108857 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108857 Log: 2005-12-20 Richard Guenther <[EMAIL PROTECTED]> PR middle-end/24306 * builtins.c (std_gimplify_va_arg_expr): Do not align va frame for zero sized types. * config/i386/i386.c (ix86_gimplify_va_arg): Likewise. * gcc.target/i386/pr24306.c Added: branches/gcc-4_1-branch/gcc/testsuite/gcc.target/i386/pr24306.c Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/builtins.c branches/gcc-4_1-branch/gcc/config/i386/i386.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24306
[Bug rtl-optimization/25115] [4.2 Regression] Segmentation fault in pre_insert_copy_insn
--- Comment #11 from bonzini at gnu dot org 2005-12-20 17:22 --- patch committed -- bonzini at gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25115
[Bug rtl-optimization/25115] [4.2 Regression] Segmentation fault in pre_insert_copy_insn
--- Comment #10 from bonzini at gnu dot org 2005-12-20 17:06 --- Subject: Bug 25115 Author: bonzini Date: Tue Dec 20 17:06:14 2005 New Revision: 108855 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108855 Log: 2005-12-20 Roger Sayle <[EMAIL PROTECTED]> Paolo Bonzini <[EMAIL PROTECTED]> PR rtl-optimization/25115 * gcse.c (pre_insert_copy_insn): Fall back to the sole SET in the insn if there is no SET for an expression that is equivalent to EXPR. Modified: trunk/gcc/ChangeLog trunk/gcc/gcse.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25115
[Bug libfortran/25305] [4.0 regression]: libfortran failed fma3d in SPEC CPU 2K
--- Comment #22 from kargl at gcc dot gnu dot org 2005-12-20 17:01 --- The testcase isn't needed and should not be committed. As explained elsewhere, the problem was caused by merging one line from a 4.1 patch into 4.0 that should not have been committed. Jerry has fixed that problem. With very limited gfortran manpower, gfortran 4.0.x will see very few if any new changes. In fact, using gfortran 4.0.x to obtain SPEC benchmarks is actually rather stupid. Do yourself a favor and upgrade to gfortran 4.1 (pre-release). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25305
[Bug bootstrap/25502] Werror problem in build
--- Comment #3 from mmitchel at gcc dot gnu dot org 2005-12-20 16:44 --- This was discussed after I posted the patch. The GCC format-checking stuff does not know about the Windows extensions. So, on MinGW, you should --disable-werror. This bug should be reclassified as a diagnostic bug; it's a limitation in the format checkers, not a bug in the macros. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25502
[Bug bootstrap/25502] Werror problem in build
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-12-20 16:37 --- Would be caused by: 2005-08-23 Mark Mitchell <[EMAIL PROTECTED]> * hwint.h (HOST_WIDE_INT_PRINT): Use HOST_LONG_LONG_FORMAT. 2004-11-23 Mark Mitchell <[EMAIL PROTECTED]> * hwint.h (HOST_LONG_LONG_FORMAT): New macro. Use it throughout. * config/i386/xm-mingw32.h (HOST_LONG_LONG_FORMAT): Define. * doc/hostconfig.texi (HOST_LONG_LONG_FORMAT): Document. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||mmitchel at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25502
[Bug c++/25260] [4.0/4.1/4.2 Regression] Forward explicit intantiation declaration doesn't mix well with static integral member
--- Comment #5 from fang at csl dot cornell dot edu 2005-12-20 16:27
---
Subject: Re: [4.0/4.1/4.2 Regression] Forward explicit
intantiation declaration doesn't mix well with static integral member
> --- Comment #3 from nicos at maunakeatech dot com 2005-12-20 09:20
> ---
> I was under the belief that out of class definitions of const static integral
> members was optional for gcc and that static const N = k; was equivalent to
> enum { N = k};, was I wrong ?
in-class definitions of static const integral types are *permitted* in
lieu of out-of-class definitions -- but you need one or the other. Also
enums are never allocated memory in object files (data section), as per
W.B.'s remark.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25260
[Bug middle-end/24306] [3.4/4.0/4.1/4.2 Regression] va_arg gets confused when skipping over certain zero-sized types with -msse
--- Comment #7 from rguenth at gcc dot gnu dot org 2005-12-20 16:20 --- Subject: Bug 24306 Author: rguenth Date: Tue Dec 20 16:20:27 2005 New Revision: 108854 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108854 Log: 2005-12-20 Richard Guenther <[EMAIL PROTECTED]> PR middle-end/24306 * builtins.c (std_gimplify_va_arg_expr): Do not align va frame for zero sized types. * config/i386/i386.c (ix86_gimplify_va_arg): Likewise. * gcc.target/i386/pr24306.c: New testcase. Added: trunk/gcc/testsuite/gcc.target/i386/pr24306.c Modified: trunk/gcc/ChangeLog trunk/gcc/builtins.c trunk/gcc/config/i386/i386.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24306
[Bug c++/25260] [4.0/4.1/4.2 Regression] Forward explicit intantiation declaration doesn't mix well with static integral member
--- Comment #4 from bangerth at dealii dot org 2005-12-20 16:14 --- Yes, you were wrong. This certainly can't be equivalent to the enum snippet you posted since once can take the address of this static member, but can't take the address of an enum member. W. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25260
[Bug rtl-optimization/23453] [4.0/4.1/4.2 regression] miscompilation of PARI/GP on x86 with gcse after reload
--- Comment #14 from steven at gcc dot gnu dot org 2005-12-20 16:11 --- The patch proposed in bug 25196 comment #8 indeed makes the test case from comment #6 in this PR work (at least, it stops it from segfaulting). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23453
[Bug other/22313] [4.2 Regression] profiledbootstrap is broken on the mainline
--- Comment #26 from papadako at csd dot uoc dot gr 2005-12-20 16:07 --- I still can't profiledbootstrap gcc 4.1 branch. Stops with the following message: tage1/xgcc -Bstage1/ -B/usr/gcc_4_1/i486-slackware-linux/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-4_1-branch/gcc -I../../gcc-4_1-branch/gcc/. -I../../gcc-4_1-branch/gcc/../include -I../../gcc-4_1-branch/gcc/../libcpp/include ../../gcc-4_1-branch/gcc/attribs.c -o attribs.o /tmp/ccXgVrwC.s: Assembler messages: /tmp/ccXgVrwC.s:1280: Error: invalid sections for operation on `.LCFI71' and `.LCFI70' make[2]: *** [attribs.o] Error 1 This is with binutils 2.16.91.0.4 2005 and gcc version 4.0.3 20051207 (prerelease) on a linux x86 machine. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22313
[Bug c++/25503] g++ accepts invalid typedef in template code
--- Comment #2 from bangerth at dealii dot org 2005-12-20 16:03 --- Confirmed. The typedef is only rejected if it is actually used to define a variable. W. -- bangerth at dealii dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||accepts-invalid Last reconfirmed|-00-00 00:00:00 |2005-12-20 16:03:30 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25503
[Bug rtl-optimization/25196] [4.0/4.1 Regression] i386: wrong arguments passed
--- Comment #8 from steven at gcc dot gnu dot org 2005-12-20 15:58 ---
Gross. According to a comment in postreload.c:move2add_note_store(), we can
have pushes without REG_INC notes:
/* Some targets do argument pushes without adding REG_INC notes. */
So we need to go look for those {pre,post}{decrements,increments} ourselves.
With this patch, we just do what postreload.c does.
Index: postreload-gcse.c
===
--- postreload-gcse.c (revision 108853)
+++ postreload-gcse.c (working copy)
@@ -676,6 +676,17 @@ record_last_set_info (rtx dest, rtx sett
/* Ignore pushes, they clobber nothing. */
&& ! push_operand (dest, GET_MODE (dest)))
record_last_mem_set_info (last_set_insn);
+
+ /* ??? Some targets do argument pushes without adding REG_INC notes.
+ See e.g. PR25196, where a pushsi2 on i386 doesn't have REG_INC
+ notes. */
+ if (MEM_P (dest))
+{
+ dest = XEXP (dest, 0);
+ if (GET_CODE (dest) == PRE_INC || GET_CODE (dest) == POST_INC
+ || GET_CODE (dest) == PRE_DEC || GET_CODE (dest) == POST_DEC)
+ record_last_reg_set_info (last_set_insn, REGNO (XEXP (dest, 0)));
+}
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25196
[Bug target/25005] [4.1/4.2 regression] ICE in extract_constrain_insn_cached, at recog.c:2002
--- Comment #7 from jakub at gcc dot gnu dot org 2005-12-20 15:40 --- The problem is regrename pass. replace_oldest_value_reg called indirectly from copyprop_hardreg_forward doesn't validate the change, so if both old and new registers are in the same class, but only the old one is valid (as in this case, old reg is r9, and r9 * 2 is valid address_operand, but new reg is rsp and rsp * 2 is not a valid address_oprand). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25005
[Bug rtl-optimization/25196] [4.0/4.1 Regression] i386: wrong arguments passed
--- Comment #7 from steven at gcc dot gnu dot org 2005-12-20 14:59 --- Does not fail with trunk or the head of the gcc 4.1 branch. But it does fail with gcc 4.0.2. I'm going to try it with the head of the gcc 4.0 branch now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25196
[Bug target/25005] [4.1/4.2 regression] ICE in extract_constrain_insn_cached, at recog.c:2002
--- Comment #6 from jakub at gcc dot gnu dot org 2005-12-20 14:58 ---
Slightly less reduced testcase that doesn't have uninitialized variables:
// { dg-options "-O2 -funroll-loops" }
// { dg-do compile }
inline void *operator new (__SIZE_TYPE__, void *__p) throw() { return __p; }
struct M { ~M() { } };
struct P
{
P () { v[0] = 0; v[1] = 0; v[2] = 0; }
P (const P &x) { for (int i = 0; i < 3; ++i) v[i] = x.v[i]; }
double v[3];
};
struct V : public M
{
V (const P *x, const P *y)
{
P *b = this->a = ::new P[2];
for (; x != y; ++x, ++b)
::new (b) P(*x);
}
P *a;
};
void bar (const V &);
void
foo ()
{
const P d[2] = { P(), P() };
bar (V (&d[0], &d[2]));
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25005
[Bug tree-optimization/25501] [4.2 Regression] Segfault
--- Comment #7 from kazu at gcc dot gnu dot org 2005-12-20 14:48 --- Just checked in a patch. -- kazu at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25501
[Bug tree-optimization/25501] [4.2 Regression] Segfault
--- Comment #6 from kazu at gcc dot gnu dot org 2005-12-20 14:47 --- Subject: Bug 25501 Author: kazu Date: Tue Dec 20 14:47:07 2005 New Revision: 108853 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108853 Log: gcc/ PR tree-optimization/25501 * tree-cfgcleanup.c (merge_phi_nodes): Check that RESULT is used in the PHI argument corresponding to the edge from BB to DEST. gcc/testsuite/ PR tree-optimization/25501 * testsuite/gcc.dg/tree-ssa/pr25501.c: New. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/pr25501.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-cfgcleanup.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25501
[Bug libfortran/25305] [4.0 regression]: libfortran failed fma3d in SPEC CPU 2K
--- Comment #21 from hjl at lucon dot org 2005-12-20 14:44 --- Steven, see comment #1. I was talking about the testcase. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25305
[Bug target/25259] bootstrap failures on non-C99 platforms
--- Comment #9 from bonzini at gnu dot org 2005-12-20 14:15 --- Created an attachment (id=10535) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10535&action=view) fix the #ifndef -> use #ifdef instead -- bonzini at gnu dot org changed: What|Removed |Added Attachment #10496|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25259
[Bug c++/25503] g++ accepts invalid typedef in template code
--- Comment #1 from d dot bonekaemper at rtsgroup dot net 2005-12-20 12:28
---
(Sorry, pressed return to early...)
g++ accepts the following code, which contains a typedef that's supposed to act
as a static assert.
---
template
struct Test
{
Test()
{
typedef struct StaticAssert {unsigned condition : (N); } XXX;
}
};
int
main()
{
Test<0> T;
}
---
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25503
[Bug c++/25503] New: g++ accepts invalid typedef in template code
-- Summary: g++ accepts invalid typedef in template code Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: d dot bonekaemper at rtsgroup dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25503
[Bug rtl-optimization/24982] [4.1/4.2 Regression] Bootstrap failure with ICE in refers_to_regno_for_reload_p
--- Comment #14 from jakub at gcc dot gnu dot org 2005-12-20 11:55 --- This has been fixed on the trunk earlier with Joern's patch and now on gcc-4_1-branch as well. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24982
[Bug bootstrap/25502] Werror problem in build
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2005-12-20 11:35 --- Same problem for gcc/cfg.c, gcc/loop-unroll.c, gcc/loop-iv.c and others. Seems like a definition problem with HOST_WIDEST_INT_PRINT_DEC. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25502
[Bug bootstrap/25502] New: Werror problem in build
On i686-pc-mingw32, configuring with the following: ../gcc/configure --prefix=/mingw --enable-languages=c,fortran --with-gmp=$HOME/local --with-mpfr=$HOME/local --disable-libssp --disable-libmudflap --disable-nls --with-ld=/mingw/bin/ld --with-as=/mingw/bin/as and running make gives: cc1.exe: warnings being treated as errors ../../gcc/gcc/tree-pretty-print.c: In function 'dump_bb_header': ../../gcc/gcc/tree-pretty-print.c:2267: warning: ISO C does not support the 'I' printf flag ../../gcc/gcc/tree-pretty-print.c:2267: warning: format '%I64d' expects type 'int', but argument 3 has type 'gcov_type' make: *** [tree-pretty-print.o] Error 1 -- Summary: Werror problem in build Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: build Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: fxcoudert at gcc dot gnu dot org GCC build triplet: i686-pc-mingw32 GCC host triplet: i686-pc-mingw32 GCC target triplet: i686-pc-mingw32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25502
[Bug rtl-optimization/25196] [4.0/4.1 Regression] i386: wrong arguments passed
--- Comment #6 from belyshev at depni dot sinp dot msu dot ru 2005-12-20 10:59 --- *** Bug 23453 has been marked as a duplicate of this bug. *** -- belyshev at depni dot sinp dot msu dot ru changed: What|Removed |Added CC||debian-gcc at lists dot ||debian dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25196
[Bug rtl-optimization/23453] [4.0/4.1/4.2 regression] miscompilation of PARI/GP on x86 with gcse after reload
--- Comment #13 from belyshev at depni dot sinp dot msu dot ru 2005-12-20 10:59 --- Marking as dup of bug 25196 because that bug contains simpler test case. *** This bug has been marked as a duplicate of 25196 *** -- belyshev at depni dot sinp dot msu dot ru changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23453
[Bug rtl-optimization/23453] [4.0/4.1/4.2 regression] miscompilation of PARI/GP on x86 with gcse after reload
--- Comment #12 from steven at gcc dot gnu dot org 2005-12-20 10:48 --- Almost certainly a dup of PR25196 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23453
[Bug rtl-optimization/25196] [4.0/4.1 Regression] i386: wrong arguments passed
-- steven at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |steven at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2005-12-20 09:17:31 |2005-12-20 10:18:24 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25196
[Bug rtl-optimization/25196] [4.0/4.1 Regression] i386: wrong arguments passed
--- Comment #5 from steven at gcc dot gnu dot org 2005-12-20 10:17 --- Re. comment #4: but this new PR has a much simpler test case :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25196
[Bug c++/25260] [4.0/4.1/4.2 Regression] Forward explicit intantiation declaration doesn't mix well with static integral member
--- Comment #3 from nicos at maunakeatech dot com 2005-12-20 09:20 ---
I was under the belief that out of class definitions of const static integral
members was optional for gcc and that static const N = k; was equivalent to
enum { N = k};, was I wrong ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25260
[Bug rtl-optimization/25196] [4.0/4.1 Regression] i386: wrong arguments passed
--- Comment #4 from belyshev at depni dot sinp dot msu dot ru 2005-12-20
09:17 ---
// short testcase, compile with "-m32 -march=i386 -O3 -fomit-frame-pointer"
extern void abort (void);
static int j;
static void __attribute__((noinline))
f1 (int a, int b, int c, int d, int e)
{
j = a;
}
int __attribute__((noinline))
f2 (int a, int b, int c, int d, int e)
{
if ((b & 0x) != 1)
f1 (a, b, c, d, e);
return 0;
}
int main (void)
{
f2 (123, 0, 0, 0, 0);
if (j != 123)
abort ();
return 0;
}
---
Note that this bug disappears with -fno-gcse-after-reload, here is difference
in generated assembly between -fno-gcse-after-reload (---) and
-fgcse-after-reload (+++):
$ diff -U 5 1.s 2.s
--- 1.s 2005-12-20 12:10:44.0 +0300
+++ 2.s 2005-12-20 12:10:41.0 +0300
@@ -14,13 +14,13 @@
movl12(%esp), %ecx
movl%edx, %eax
andl$4369, %eax
decl%eax
je .L4
+ movl%ecx, %eax
pushl 20(%esp)
pushl 20(%esp)
- movl12(%esp), %eax
callf1
popl%eax
popl%edx
.L4:
xorl%eax, %eax
$
So this bug looks very much like bug 23453.
--
belyshev at depni dot sinp dot msu dot ru changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Component|target |rtl-optimization
Ever Confirmed|0 |1
GCC host triplet|i386-pc-linux |
GCC target triplet||i386-pc-linux
Last reconfirmed|-00-00 00:00:00 |2005-12-20 09:17:31
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25196
[Bug c++/21228] [4.0/4.1/4.2 Regression] -Wunreachable-code produces spurious warnings for constructor
--- Comment #7 from mmitchel at gcc dot gnu dot org 2005-12-20 08:48 --- Subject: Bug 21228 Author: mmitchel Date: Tue Dec 20 08:48:13 2005 New Revision: 108851 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108851 Log: PR c++/21228 * decl.c (use_eh_spec_block): New function. (store_parm_decls): Use it. (finish_function): Likewise. PR c++/21228 * g++.dg/warn/Wunreachable-code-2.C: New test. Added: trunk/gcc/testsuite/g++.dg/warn/Wunreachable-code-2.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21228
[Bug c++/25294] [4.0/4.1/4.2 Regression] Bogus "unterminated comment" error from #pragma comment
--- Comment #6 from mmitchel at gcc dot gnu dot org 2005-12-20 08:47 --- The problem is that directives.c:do_pragma says: /* Squirrel away the pragma text. Pragmas are newline-terminated. */ However, as this example shows, simply saving the entire line is incorrect; we have not already performed the Phase 3 elimination of comments at this point. I don't see any good alternative other than to check for the specific case of a comment starting on this line, and, if the comment is not ended before the end of the line, treating the end of the pragma as occurring directly before the comment, rather than at the end of the line. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25294
[Bug c++/21228] [4.0/4.1/4.2 Regression] -Wunreachable-code produces spurious warnings for constructor
--- Comment #6 from mmitchel at gcc dot gnu dot org 2005-12-20 08:30 --- Fixed in 4.0.3. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21228
[Bug fortran/25020] NAG extension: module F90_UNIX providing access to UNIX functions (abort ...)
--- Comment #2 from anlauf at gmx dot de 2005-12-20 08:29 --- (In reply to comment #0) I have written a portable version of the module F90_UNIX, which runs under several platforms but need to be configured manually. It is available from: http://home.arcor.de/harald.anlauf/f90_unix.tar.gz Tested with different compilers on different platforms. Works best with compilers that support the Fortran 2003 IMPORT statement (PR 24549) and the BIND(C) construct for interoperability with C, but these features are not required. Cheers, -ha -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25020
[Bug c++/21228] [4.0/4.1/4.2 Regression] -Wunreachable-code produces spurious warnings for constructor
--- Comment #5 from mmitchel at gcc dot gnu dot org 2005-12-20 08:26 --- Subject: Bug 21228 Author: mmitchel Date: Tue Dec 20 08:26:04 2005 New Revision: 108850 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108850 Log: PR c++/21228 * decl.c (use_eh_spec_block): New function. (store_parm_decls): Use it. (finish_function): Likewise. PR c++/21228 * g++.dg/warn/Wunreachable-code-2.C: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/g++.dg/warn/Wunreachable-code-2.C Modified: branches/gcc-4_1-branch/gcc/cp/ChangeLog branches/gcc-4_1-branch/gcc/cp/decl.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21228
[Bug c++/21228] [4.0/4.1/4.2 Regression] -Wunreachable-code produces spurious warnings for constructor
--- Comment #4 from mmitchel at gcc dot gnu dot org 2005-12-20 08:24 --- Subject: Bug 21228 Author: mmitchel Date: Tue Dec 20 08:24:10 2005 New Revision: 108849 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108849 Log: PR c++/21228 * decl.c (use_eh_spec_block): New function. (store_parm_decls): Use it. (finish_function): Likewise. PR c++/21228 * g++.dg/warn/Wunreachable-code-2.C: New test. Added: branches/gcc-4_0-branch/gcc/testsuite/g++.dg/warn/Wunreachable-code-2.C Modified: branches/gcc-4_0-branch/gcc/cp/ChangeLog branches/gcc-4_0-branch/gcc/cp/decl.c branches/gcc-4_0-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21228
