[Bug rtl-optimization/11832] Optimization of common code in switch statements
-- aldot at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |aldot at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2005-12-07 04:15:54 |2007-08-17 07:17:48 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11832
[Bug c/33096] New: Internal compiler error with register global variables
Compile the following program with -O3 on FreeBSD or Linux, x86:
///
#include
#include
register long foo asm("esi");
register long bar asm("edi");
char * crash_me_baby(char *str) {
char *path = malloc(1024 + strlen(str));
return path;
}
///
This results in an error like the following:
test.c:10: error: unable to find a register to spill in class 'DIREG'
test.c:10: error: this is the insn:
(insn:HI 16 83 17 2 (parallel [
(set (reg:SI 2 cx [66])
(unspec:SI [
(mem:BLK (reg/v/f:SI 63 [ suffix ]) [0 A8])
(reg:QI 0 ax [70])
(const_int 1 [0x1])
(reg:SI 2 cx [69])
] 20))
(use (reg:SI 19 dirflag))
(clobber (reg/f:SI 68 [ suffix ]))
(clobber (reg:CC 17 flags))
]) 530 {*strlenqi_1} (insn_list:REG_DEP_TRUE 6 (insn_list:REG_DEP_TRUE
12 (insn_list:REG_DEP_TRUE 14 (insn_list:REG_DEP_TRUE 15 (nil)
(expr_list:REG_DEAD (reg:SI 19 dirflag)
(expr_list:REG_DEAD (reg:SI 2 cx [69])
(expr_list:REG_DEAD (reg:QI 0 ax [70])
(expr_list:REG_UNUSED (reg:CC 17 flags)
(expr_list:REG_UNUSED (reg/f:SI 68 [ suffix ])
(expr_list:REG_EQUAL (unspec:SI [
(mem:BLK (reg/v/f:SI 63 [ suffix ]) [0 A8])
(reg:QI 0 ax [70])
(const_int 1 [0x1])
(reg:SI 2 cx [69])
] 20)
(nil
--
Summary: Internal compiler error with register global variables
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: slava at factorcode dot org
GCC build triplet: i386-unknown-freebsd6.2
GCC host triplet: i386-unknown-freebsd6.2
GCC target triplet: i386-unknown-freebsd6.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33096
[Bug c/33096] Internal compiler error with register global variables
--- Comment #1 from slava at factorcode dot org 2007-08-17 07:56 --- Created an attachment (id=14068) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14068&action=view) Test case This is a test case for the bug. Compile with -O1, -O2 or -O3 to trigger it. With -O0, it compiles fine. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33096
[Bug fortran/31298] F2003: use mod, operator(+) => operator(.userOp.) not supported
--- Comment #10 from burnus at gcc dot gnu dot org 2007-08-17 08:14 ---
Rejecting "operator(.procedure.)" has been fixed by PR33072.
Accepting multiple renames/imports of an operator ("operator(.op.),
operator(.myop.)=>operator(.op.)") is fixed by the submitted patch
http://gcc.gnu.org/ml/gcc-patches/2007-08/msg01081.html
Remains to be done:
Supporting "operator(+)=>operator(.myPlusOp.)", which can be based on the
attachment 13369 and the submitted patch.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
Keywords|wrong-code |rejects-valid
Summary|Uninitialized variable in |F2003: use mod, operator(+)
|f951 (in read_module) / |=> operator(.userOp.) not
|renaming operator in USE|supported
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31298
[Bug tree-optimization/23330] FIXME from passes.c: pass_may_alias should be a TODO item
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-08-17 09:15 --- Fixed by: 2007-08-14 Daniel Berlin <[EMAIL PROTECTED]> * tree-pass.h (PROP_pta): Removed. (TODO_rebuild_alias): New. (pass_may_alias): Removed. * tree-ssa-ccp.c (execute_fold_all_builtins): Only rebuild aliasing if we changed something. * tree-ssa-alias.c (compute_may_aliases): Make non-static. Update SSA internally. (pass_may_alias): Removed. (create_structure_vars): Return TODO_rebuild_alias. * tree-ssa-pre.c (do_pre): Return TODO_rebuild_alias. * tree-sra.c (tree_sra): Only rebuild aliasing if something changed. (tree_sra_early): We never affect aliasing right now. * tree-flow.h (compute_may_aliases): New prototype. * passes.c: Remove pass_may_alias from the passes. (execute_function_todo): Support TODO_rebuild_alias. -- pinskia 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=23330
[Bug middle-end/19430] V_MAY_DEF (taking address of var) causes missing uninitialized warning
--- Comment #15 from manu at gcc dot gnu dot org 2007-08-17 09:17 --- This seems to me a duplicate of PR179. I am going to add a dependency to remember to check this PR when PR179 gets fixed. -- manu at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||179 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19430
[Bug c++/31751] [4.1/4.2 regression] ICE with forgotten member declaration
--- Comment #3 from pcarlini at suse dot de 2007-08-17 09:23 --- Hi Volker. I will be away for some days on vacations... In the meanwhile, if you could double check that we really want the fix for 27211 (not a regression) on the branches and, in case, take care of the backport, it would be great. Thanks in advance. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31751
[Bug libstdc++/33084] Small typo in valarray header
--- Comment #2 from paolo at gcc dot gnu dot org 2007-08-17 09:27 --- Subject: Bug 33084 Author: paolo Date: Fri Aug 17 09:27:06 2007 New Revision: 127579 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127579 Log: 2007-08-17 Johannes Willkomm <[EMAIL PROTECTED]> PR libstdc++/33084 * include/std/valarray (operator _Op(const _Tp&, const valarray<>&)): Fix typo. * testsuite/26_numerics/numeric_arrays/valarray/33084.cc: New. Added: trunk/libstdc++-v3/testsuite/26_numerics/numeric_arrays/valarray/33084.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/std/valarray -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33084
[Bug middle-end/33088] [4.1/4.2/4.3 Regression] spurious exceptions with -ffloat-store
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-08-17 09:27 --- For one, I don't think " __real__ X = R; __imag__ X = C; " is really nice looking. Now if the person did: *(double*) &X = R; ((double*) & X)[1] = C; it might be a different story but then again X is still defined piece wise so you will still get NaN. I really don't think this is a bug as we have an uninitialized variables here in the same way doing: short a; a = b&0xff|a; a = (b<<8)&0xFF00|a; Would be defined code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33088
[Bug libstdc++/33084] Small typo in valarray header
--- Comment #3 from paolo at gcc dot gnu dot org 2007-08-17 09:28 --- Subject: Bug 33084 Author: paolo Date: Fri Aug 17 09:28:09 2007 New Revision: 127580 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127580 Log: 2007-08-17 Johannes Willkomm <[EMAIL PROTECTED]> PR libstdc++/33084 * include/std/valarray (operator _Op(const _Tp&, const valarray<>&)): Fix typo. * testsuite/26_numerics/numeric_arrays/valarray/33084.cc: New. Added: branches/gcc-4_2-branch/libstdc++-v3/testsuite/26_numerics/valarray/33084.cc Modified: branches/gcc-4_2-branch/libstdc++-v3/ChangeLog branches/gcc-4_2-branch/libstdc++-v3/include/std/std_valarray.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33084
[Bug c++/33094] [4.2/4.3 Regression] ICE on valid C++ virtual template static member in anonymous namespace
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-08-17 09:29 --- /* An in-class declaration of a static data member should be external; it is only a declaration, and not a definition. */ if (init == NULL_TREE) gcc_assert (DECL_EXTERNAL (decl)); Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||ice-on-valid-code Last reconfirmed|-00-00 00:00:00 |2007-08-17 09:29:10 date|| Summary|ICE on valid C++ virtual|[4.2/4.3 Regression] ICE on |template static member in |valid C++ virtual template |namespace |static member in anonymous ||namespace Target Milestone|--- |4.2.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33094
[Bug rtl-optimization/11001] global register %edi versus string builtins
--- Comment #11 from pinskia at gcc dot gnu dot org 2007-08-17 09:03 --- *** Bug 33096 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||slava at factorcode dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11001
[Bug target/33096] Internal compiler error with register global variables
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-08-17 09:03 --- *** This bug has been marked as a duplicate of 11001 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Component|c |target Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33096
[Bug c++/32870] Unclear error message when declaring struct in wrong namespace
--- Comment #2 from paolo at gcc dot gnu dot org 2007-08-17 09:35 --- Subject: Bug 32870 Author: paolo Date: Fri Aug 17 09:35:23 2007 New Revision: 127581 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127581 Log: /cp 2007-08-17 Paolo Carlini <[EMAIL PROTECTED]> PR c++/32870 * parser.c (cp_parser_class_head): Improve error message. /testsuite 2007-08-17 Paolo Carlini <[EMAIL PROTECTED]> PR c++/32870 * g++.dg/other/error17.C: Adjust. Added: trunk/gcc/testsuite/g++.dg/other/error17.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32870
[Bug c++/32870] Unclear error message when declaring struct in wrong namespace
--- Comment #3 from pcarlini at suse dot de 2007-08-17 09:36 --- Fixed. -- 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=32870
[Bug libstdc++/33084] Small typo in valarray header
--- Comment #4 from pcarlini at suse dot de 2007-08-17 09:30 --- Fixed for 4.2.2. -- pcarlini at suse dot de changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.2.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33084
[Bug middle-end/33086] warn for read-only uninitialized variables passed as arguments
--- Comment #4 from manu at gcc dot gnu dot org 2007-08-17 10:15 ---
(In reply to comment #3)
>
> void use(const int *a)
> {
> int *b = (int*)a;
Andrew, you are right. I tend to forget how fragile is 'const', even in C++.
So, then this is invalid and thus it is PR10138.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33086
[Bug c++/32190] wrong error recovery on parsing template arguments
--- Comment #5 from pcarlini at suse dot de 2007-08-17 10:22 --- This is now fixed both in mainline and in 4_2-branch: 32190.C: In function 'int main()': 32190.C:5: error: template argument 1 is invalid at this point, not being a regression, I think we can close it. -- pcarlini at suse dot de changed: What|Removed |Added Known to work||4.2.1 4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32190
[Bug c++/32190] wrong error recovery on parsing template arguments
--- Comment #6 from manu at gcc dot gnu dot org 2007-08-17 10:24 --- (In reply to comment #5) > This is now fixed both in mainline and in 4_2-branch: > > 32190.C: In function 'int main()': > 32190.C:5: error: template argument 1 is invalid > > at this point, not being a regression, I think we can close it. > Is there a testcase for this? If not, perhaps we can close this *after* the testcase is added. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32190
[Bug c++/32190] wrong error recovery on parsing template arguments
--- Comment #7 from pcarlini at suse dot de 2007-08-17 10:26 --- Sure, I'll take care of that... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32190
[Bug c++/32190] wrong error recovery on parsing template arguments
--- Comment #8 from manu at gcc dot gnu dot org 2007-08-17 10:28 --- Ivan, would you like to write, test and post the testcase? Once it is approved I can commit it for you (with your name of course!). A starting point will be http://gcc.gnu.org/wiki/HowToPrepareATestcase, if you need further help, please contact me. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32190
[Bug c++/32190] wrong error recovery on parsing template arguments
--- Comment #9 from igodard at pacbell dot net 2007-08-17 10:37 --- Subject: Re: wrong error recovery on parsing template arguments Begging your pardon, but what's wrong with the one I put in already? Ivan manu at gcc dot gnu dot org wrote: > --- Comment #8 from manu at gcc dot gnu dot org 2007-08-17 10:28 --- > Ivan, would you like to write, test and post the testcase? Once it is approved > I can commit it for you (with your name of course!). > A starting point will be http://gcc.gnu.org/wiki/HowToPrepareATestcase, if you > need further help, please contact me. > > > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32190
[Bug middle-end/33088] [4.1/4.2/4.3 Regression] spurious exceptions with -ffloat-store
--- Comment #2 from joseph at codesourcery dot com 2007-08-17 10:37 --- Subject: Re: [4.1/4.2/4.3 Regression] spurious exceptions with -ffloat-store On Fri, 17 Aug 2007, pinskia at gcc dot gnu dot org wrote: > For one, I don't think " __real__ X = R; __imag__ X = C; " is really nice > looking. Now if the person did: > *(double*) &X = R; ((double*) & X)[1] = C; > > it might be a different story but then again X is still defined piece wise so > you will still get NaN. I think setting parts is cleaner than using casts like that, and safer (because of not involving arithmetic that GCC's liable to get wrong in cases involving -0) than R + C * I. > I really don't think this is a bug as we have an uninitialized variables here > in the same way doing: > short a; > a = b&0xff|a; > a = (b<<8)&0xFF00|a; > > Would be defined code. I think setting the parts is valid GNU C (ISO C doesn't have the __real__ and __imag__ operators), and should be considered much like initializing a struct by parts, where it would definitely be incorrect to generate an exception from an uninitialized part. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33088
[Bug c++/32190] wrong error recovery on parsing template arguments
--- Comment #10 from manu at gcc dot gnu dot org 2007-08-17 10:50 ---
(In reply to comment #9)
> Subject: Re: wrong error recovery on parsing template arguments
>
> Begging your pardon, but what's wrong with the one I put in already?
>
Nothing is wrong, but to be useful for GCC testsuite, we need to add some
markers (for example, // { dg-error "template argument 1 is invalid" }) and
then run an old version and check that the test fails and run it for mainline
and check that the test passes. Then the patch adding the testcase is submitted
to gcc-patches for review with an appropriate changelog, approved and
committed. I think it would be a feasible contribution from you, letting more
advance developers like Paolo to focus on more complex stuff.
But if you don't want to do it just say so, no problem at all.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32190
[Bug fortran/33095] MAX with optional arguments gives run-time error
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-08-17 11:24 --- Oh, sh**, I didn't think about simplification. Well, I don't see an easy way to have error messages at runtime, so we should simply skip those. We won't have any diagnostic, but no compiler that I know of does it, but we will be accepting valid code, so it's a no-brainer. I'll work on that. PS: I'm not sure it's a 4.3 regression, but it probably is (I can't test right now). -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Known to fail||4.3.0 Last reconfirmed|-00-00 00:00:00 |2007-08-17 11:24:13 date|| Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33095
[Bug other/33087] Add dependency information to object files and make use of it
--- Comment #4 from raselmsh at hotmail dot com 2007-08-17 12:04 --- I took a look at ccache again, and it is definitely not what I was thinking of. ccache is more aimed at accelerating multiple full compile rounds of the same package, whereas I was thinking of improving dependency handling in makefiles in order to simplify them - the same problem that 'gcc -M' solves, but to my mind a more elegant solution. Although ccache can do this, I think it is rather clumsy for the job, just as I wouldn't use it as a substitute for 'gcc -M'. On the other hand, I can live with the fact that you don't agree about the need for this :) If I had time (and you were interested), I would take a look at doing it myself, but unfortunately I don't... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33087
[Bug fortran/33097] New: Invalid decl trees are created for external intrinsics
Recently I discovered, that gfortran FE creates invalid decl trees for exteranl intrinsics: only return value is added to arg chain, and none of the actual arguments. This can potentially break much stuff, because of inconsistency of CALL_EXPR and corresponding fndecl. This was due to the following TODO in gfc_get_symbol_for_expr(): /* TODO: proper argument lists for external intrinsics. */ -- Summary: Invalid decl trees are created for external intrinsics Product: gcc Version: 4.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: asl at math dot spbu dot ru http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33097
[Bug fortran/33097] Invalid decl trees are created for external intrinsics
--- Comment #1 from asl at math dot spbu dot ru 2007-08-17 12:42 --- Created an attachment (id=14069) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14069&action=view) Quick and dirty patch Attached is quick and dirty patch to populate symbol with arguments. It seems to be incomplete (at least for optional args, as it seems to me), and maybe invalid in general (I touched gfortran FE yesterday for the first time). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33097
[Bug rtl-optimization/32300] [4.3 Regression] ICE with -O2 -fsee
--- Comment #9 from wouter dot vermaelen at scarlet dot be 2007-08-17
12:44 ---
Here is a simpler testcase:
int f(int i) { return 100LL / (1 + i); }
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32300
[Bug fortran/33097] Invalid decl trees are created for external intrinsics
--- Comment #2 from asl at math dot spbu dot ru 2007-08-17 12:49 --- Quick example of the problem: > QI size unit size align 8 symtab 0 alias set -1 arg-types chain >> pointer_to_this > addressable public external asm-frame-size 0 QI file rnflow.f90 line 2723 chain > Note, we have only 1 arg for matmul_r4 and it's return value actually. And such decl is attached to CALL_EXPR, which has 3 arguments to provide for callee :) The gcf_show_symbol() returns (no formal args, as expected): symbol _gfortran_matmul_r4 (REAL 4)(PROCEDURE UNKNOWN-INTENT UNKNOWN-ACCESS INTRINSIC-PROC DIMENSION EXTERNAL FUNCTION) Array spec:(2 AS_ASSUMED_SHAPE () () () () ) result: _gfortran_matmul_r4 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33097
[Bug rtl-optimization/32300] [4.3 Regression] ICE with -O2 -fsee
--- Comment #10 from zadeck at naturalbridge dot com 2007-08-17 12:48
---
Subject: Re: [4.3 Regression] ICE with -O2 -fsee
wouter dot vermaelen at scarlet dot be wrote:
> --- Comment #9 from wouter dot vermaelen at scarlet dot be 2007-08-17
> 12:44 ---
> Here is a simpler testcase:
>
> int f(int i) { return 100LL / (1 + i); }
>
>
>
thanks,
everyone knows what the problems with see.c are, it is simply a matter
of having the authors fix their code. Virtually anything that invokes
this pass will cause it to fail.
kenny
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32300
[Bug libfortran/33079] Optional empty strings do not appear to be 'PRESENT'
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2007-08-17 13:09 --- Subject: Bug 33079 Author: fxcoudert Date: Fri Aug 17 13:09:23 2007 New Revision: 127584 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127584 Log: PR fortran/33079 * intrinsics/string_intrinsics.c (string_trim, string_minmax): Fix the zero-length result case. * gfortran.dg/zero_length_2.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/zero_length_2.f90 Modified: trunk/gcc/testsuite/ChangeLog trunk/libgfortran/ChangeLog trunk/libgfortran/intrinsics/string_intrinsics.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33079
[Bug libfortran/33079] Optional empty strings do not appear to be 'PRESENT'
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2007-08-17 13:10 --- Fixed. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33079
[Bug fortran/33095] MAX with optional arguments gives run-time error
--- Comment #2 from burnus at gcc dot gnu dot org 2007-08-17 13:21 --- > Oh, sh**, I didn't think about simplification. > Well, I don't see an easy way to > have error messages at runtime, so we should simply skip those. Good idea. As long as the compiler does the right thing (TM) we don't need run-time errors. Otherwise they make mostly sense with some -f*check-* option. > PS: I'm not sure it's a 4.3 regression, but it probably is (I can't test right > now). I don't think so. The message was introduced with PR31198 and older versions did probably the same as gfortran 4.2: It crashes if any of the optional arguments is not present (NULL pointers). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33095
[Bug c++/33094] [4.2/4.3 Regression] ICE on valid C++ virtual template static member in anonymous namespace
--- Comment #2 from ian at airs dot com 2007-08-17 14:31 --- This patch fixes the problem and passes the g++ testsuite. Index: cp/decl.c === --- cp/decl.c (revision 127491) +++ cp/decl.c (working copy) @@ -4963,7 +4963,7 @@ make_rtl_for_nonlocal_decl (tree decl, t gcc_assert (TREE_STATIC (decl)); /* An in-class declaration of a static data member should be external; it is only a declaration, and not a definition. */ - if (init == NULL_TREE) + if (init == NULL_TREE && DECL_INITIAL (decl) == NULL_TREE) gcc_assert (DECL_EXTERNAL (decl)); } -- ian at airs dot com changed: What|Removed |Added Target Milestone|4.2.2 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33094
[Bug fortran/31298] F2003: use mod, operator(+) => operator(.userOp.) not supported
--- Comment #11 from patchapp at dberlin dot org 2007-08-17 15:10 --- Subject: Bug number PR31298 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-08/msg01081.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31298
[Bug fortran/32875] Not Implemented: complex character array constructor
--- Comment #4 from patchapp at dberlin dot org 2007-08-17 15:10 --- Subject: Bug number PR32875 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-08/msg01077.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32875
[Bug c++/29077] Incorrect error message for destructor in wrong namespace
--- Comment #6 from pcarlini at suse dot de 2007-08-17 15:30 --- I guess we can indeed close this one as fixed in mainline... -- 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=29077
[Bug c++/28107] Incomplete type in struct added to global namespace
--- Comment #2 from pcarlini at suse dot de 2007-08-17 15:37 --- FWIW, Comeau gives very similar errors: "ComeauTest.c", line 3: error: incomplete type is not allowed union B b; ^ "ComeauTest.c", line 6: error: tag kind of class or struct is incompatible with declaration of union "B" (declared at line 3) struct B; ^ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28107
[Bug libstdc++/33098] New: __is_convertible_helper in tr1_impl/type_traits uses deprecated add_reference
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc/configure CC=gcc43 CXX=g++43 --program-suffix=43
--disable-multilib --enable-languages=c,c++
Thread model: posix
gcc version 4.3.0 20070816 (experimental)
The following code:
#include
int main() {
bool b = std::is_convertible::value;
}
when compiled with:
g++43 -std=c++0x test.cpp -o test
Gives:
include/c++/4.3.0/type_traits: In instantiation of const bool
std::__is_convertible_helper::__value:
include/c++/4.3.0/type_traits:258: instantiated from
std::is_convertible
test.cpp:5: instantiated from here
include/c++/4.3.0/type_traits:243: error: invalid use of incomplete type
struct std::add_reference
include/c++/4.3.0/tr1_impl/type_traitsfwd.h:157: error: declaration of struct
std::add_reference
include/c++/4.3.0/type_traits: In instantiation of std::is_convertible:
test.cpp:5: instantiated from here
include/c++/4.3.0/type_traits:258: error: std::__is_convertible_helper::__value is not a valid template argument for type bool because
it is a non-constant expression
test.cpp: In function int main():
test.cpp:5: error: value is not a member of std::is_convertible
Besauce the following structure uses deprecated add_reference.
template::value || is_void<_To>::value
|| is_function<_To>::value || is_array<_To>::value
// This special case is here only to avoid warnings.
|| (is_floating_point::type>::value
&& __is_int_or_cref<_To>::__value))>
struct __is_convertible_helper
{
// "An imaginary lvalue of type From...".
static const bool __value = (__is_convertible_simple::type, _To>::__value);
};
FIX:
change add_reference to add_lvalue_reference (see attached patch)
--
Summary: __is_convertible_helper in tr1_impl/type_traits uses
deprecated add_reference
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: chris dot fairles at gmail dot com
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33098
[Bug libstdc++/33098] __is_convertible_helper in tr1_impl/type_traits uses deprecated add_reference
--- Comment #1 from chris dot fairles at gmail dot com 2007-08-17 15:48 --- Created an attachment (id=14070) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14070&action=view) patch to fix compile error when using pointers with is_convertible -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33098
[Bug libstdc++/33098] __is_convertible_helper in tr1_impl/type_traits uses deprecated add_reference
--- Comment #2 from chris dot fairles at gmail dot com 2007-08-17 15:48 --- Created an attachment (id=14071) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14071&action=view) test case that gives compile error -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33098
[Bug fortran/32881] PURE attribute escapes from contained procedure
--- Comment #5 from patchapp at dberlin dot org 2007-08-17 15:10 --- Subject: Bug number PR32881 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-08/msg01078.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32881
[Bug c++/18207] misleading diagnostic for ill-formed implicitly-defined default constructor
--- Comment #2 from pcarlini at suse dot de 2007-08-17 16:15 --- This is fixed in the active branches. Now the diagnostic is: 18207.C: In constructor 's::s()': 18207.C:8: error: no matching function for call to 'm::m()' 18207.C:4: note: candidates are: m::m(const m&) 18207.C: In constructor 's1::s1()': 18207.C:15: note: synthesized method 's::s()' first required here -- pcarlini at suse dot de changed: What|Removed |Added Status|NEW |RESOLVED Known to work||4.1.2 4.2.1 4.3.0 Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18207
[Bug libstdc++/33098] [c++0x] __is_convertible_helper in type_traits uses deprecated add_reference
--- Comment #4 from paolo at gcc dot gnu dot org 2007-08-17 16:39 --- Subject: Bug 33098 Author: paolo Date: Fri Aug 17 16:39:10 2007 New Revision: 127588 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127588 Log: 2007-08-17 Chris Fairles <[EMAIL PROTECTED]> PR libstdc++/33098 * include/std/type_traits (__is_convertible_helper): Use add_lvalue_reference. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/std/type_traits -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33098
[Bug c++/32190] wrong error recovery on parsing template arguments
--- Comment #11 from igodard at pacbell dot net 2007-08-17 17:25 ---
Subject: Re: wrong error recovery on parsing template arguments
Seems impractical. I don't have access to the old versions or mainline,
and don't know what magic to put in the source for your system to use.
I'm sure all that could be fixed, but it's more likely to take more of
someone's time holding my hand than it would be to do it themselves. If
I were doing a hundred of them it would be worth the investment, but for
a one-off it seems hardly useful.
Ivan
manu at gcc dot gnu dot org wrote:
> --- Comment #10 from manu at gcc dot gnu dot org 2007-08-17 10:50 ---
> (In reply to comment #9)
>
>> Subject: Re: wrong error recovery on parsing template arguments
>>
>> Begging your pardon, but what's wrong with the one I put in already?
>>
>>
>
> Nothing is wrong, but to be useful for GCC testsuite, we need to add some
> markers (for example, // { dg-error "template argument 1 is invalid" }) and
> then run an old version and check that the test fails and run it for mainline
> and check that the test passes. Then the patch adding the testcase is
> submitted
> to gcc-patches for review with an appropriate changelog, approved and
> committed. I think it would be a feasible contribution from you, letting more
> advance developers like Paolo to focus on more complex stuff.
>
> But if you don't want to do it just say so, no problem at all.
>
>
>
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32190
[Bug c++/33094] [4.2/4.3 Regression] ICE on valid C++ virtual template static member in anonymous namespace
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Target Milestone|--- |4.2.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33094
[Bug libstdc++/33098] [c++0x] __is_convertible_helper in type_traits uses deprecated add_reference
--- Comment #3 from pcarlini at suse dot de 2007-08-17 16:31 --- Yes, let's patch-up this, but really I have to finish the builtin, this is only temporary. -- 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-08-17 16:31:46 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33098
[Bug libstdc++/33098] [c++0x] __is_convertible_helper in type_traits uses deprecated add_reference
--- Comment #5 from pcarlini at suse dot de 2007-08-17 16:40 --- Fixed. -- 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=33098
[Bug testsuite/31884] priority_queue_dijkstra.cc operates on deallocated memory
--- Comment #2 from drow at gcc dot gnu dot org 2007-08-17 17:24 --- Subject: Bug 31884 Author: drow Date: Fri Aug 17 17:24:22 2007 New Revision: 127590 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127590 Log: PR testsuite/31884 * testsuite/ext/pb_ds/example/priority_queue_dijkstra.cc (main): Do not access deleted nodes. * testsuite/25_algorithms/copy/streambuf_iterators/char/4.cc, testsuite/25_algorithms/find/istreambuf_iterators/char/2.cc, testsuite/27_io/basic_filebuf/open/char/4.cc, testsuite/27_io/objects/char/9.cc: Use dg-require-fileio. * testsuite/ext/forced_exception_error/cons_virtual_derivation.cc, testsuite/ext/pb_ds/regression/hash_data_map_rand.cc, testsuite/ext/pb_ds/regression/trie_data_map_rand.cc, testsuite/ext/pb_ds/regression/list_update_no_data_map_rand.cc, testsuite/ext/pb_ds/regression/tree_no_data_map_rand.cc, testsuite/ext/pb_ds/regression/list_update_data_map_rand.cc, testsuite/ext/pb_ds/regression/hash_no_data_map_rand.cc, testsuite/ext/pb_ds/regression/priority_queue_rand.cc, testsuite/ext/pb_ds/regression/tree_data_map_rand.cc, testsuite/ext/pb_ds/regression/trie_no_data_map_rand.cc, testsuite/ext/throw_allocator/deallocate_global.cc, testsuite/ext/throw_allocator/check_delete.cc, testsuite/ext/throw_allocator/check_allocate_max_size.cc, testsuite/ext/throw_allocator/check_deallocate_null.cc, testsuite/ext/throw_allocator/check_new.cc, testsuite/ext/throw_allocator/deallocate_local.cc, testsuite/tr1/5_numerical_facilities/random/subtract_with_carry_01/cons/gen1.cc, testsuite/tr1/5_numerical_facilities/random/subtract_with_carry/cons/gen1.cc, testsuite/tr1/5_numerical_facilities/random/linear_congruential/cons/gen1.cc, testsuite/tr1/5_numerical_facilities/random/mersenne_twister/cons/gen1.cc, testsuite/23_containers/list/modifiers/insert/25288.cc: Use dg-require-time. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/testsuite/23_containers/list/modifiers/insert/25288.cc trunk/libstdc++-v3/testsuite/25_algorithms/copy/streambuf_iterators/char/4.cc trunk/libstdc++-v3/testsuite/25_algorithms/find/istreambuf_iterators/char/2.cc trunk/libstdc++-v3/testsuite/27_io/basic_filebuf/open/char/4.cc trunk/libstdc++-v3/testsuite/27_io/objects/char/9.cc trunk/libstdc++-v3/testsuite/ext/forced_exception_error/cons_virtual_derivation.cc trunk/libstdc++-v3/testsuite/ext/pb_ds/example/priority_queue_dijkstra.cc trunk/libstdc++-v3/testsuite/ext/pb_ds/regression/hash_data_map_rand.cc trunk/libstdc++-v3/testsuite/ext/pb_ds/regression/hash_no_data_map_rand.cc trunk/libstdc++-v3/testsuite/ext/pb_ds/regression/list_update_data_map_rand.cc trunk/libstdc++-v3/testsuite/ext/pb_ds/regression/list_update_no_data_map_rand.cc trunk/libstdc++-v3/testsuite/ext/pb_ds/regression/priority_queue_rand.cc trunk/libstdc++-v3/testsuite/ext/pb_ds/regression/tree_data_map_rand.cc trunk/libstdc++-v3/testsuite/ext/pb_ds/regression/tree_no_data_map_rand.cc trunk/libstdc++-v3/testsuite/ext/pb_ds/regression/trie_data_map_rand.cc trunk/libstdc++-v3/testsuite/ext/pb_ds/regression/trie_no_data_map_rand.cc trunk/libstdc++-v3/testsuite/ext/throw_allocator/check_allocate_max_size.cc trunk/libstdc++-v3/testsuite/ext/throw_allocator/check_deallocate_null.cc trunk/libstdc++-v3/testsuite/ext/throw_allocator/check_delete.cc trunk/libstdc++-v3/testsuite/ext/throw_allocator/check_new.cc trunk/libstdc++-v3/testsuite/ext/throw_allocator/deallocate_global.cc trunk/libstdc++-v3/testsuite/ext/throw_allocator/deallocate_local.cc trunk/libstdc++-v3/testsuite/tr1/5_numerical_facilities/random/linear_congruential/cons/gen1.cc trunk/libstdc++-v3/testsuite/tr1/5_numerical_facilities/random/mersenne_twister/cons/gen1.cc trunk/libstdc++-v3/testsuite/tr1/5_numerical_facilities/random/subtract_with_carry/cons/gen1.cc trunk/libstdc++-v3/testsuite/tr1/5_numerical_facilities/random/subtract_with_carry_01/cons/gen1.cc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31884
[Bug c++/14283] Diagnostic for invalid template-id could be improved
--- Comment #12 from pcarlini at suse dot de 2007-08-17 18:09 --- Hi Giovanni, any update on this? -- pcarlini at suse dot de changed: What|Removed |Added CC||pcarlini at suse dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14283
[Bug target/31385] gcc fails to find spill register for decimal arithmetic
--- Comment #1 from janis at gcc dot gnu dot org 2007-08-17 18:21 --- Current mainline (revision 127590) still gets this ICE for i686-pc-linux-gnu with either bid or dpd decimal float support. The current line number for the ICE is reload1.c:2001. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31385
[Bug tree-optimization/33099] New: Scalar evolutions confusing VRP with pointer values that wrap around
The following test case is miscompiled with GCC 4.2:
extern void abort (void);
volatile int N = 5;
void foo (void)
{
int i;
char *p, value[10];
value[0] = 0x42;
for (i = 0; i < N; i++)
if (i > 0)
{
p = (char *)i - 1;
*(value + (int) p) = (char) i;
}
if (value[0] != 1)
abort ();
}
main()
{
foo ();
return 0;
}
$ gcc --version
gcc (GCC) 4.2.2 20070816 (prerelease)
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ gcc -O2 -o a a.c
$ ./a
Aborted (core dumped)
This was originally a C++ program which I converted into this C snippet from
GIMPLE. I believe it's valid C, but I am not actually sure. The original C++
code *is* valid, though.
The problem here starts in tree-vrp.c:adjust_range_with_scev() when we ask for
the scalar evolution of p_8 in the loop
:;
i_24 = ASSERT_EXPR ;
if (i_24 > 0) goto ; else goto ;
[ ... ]
:;
i_4 = ASSERT_EXPR 0>;
i.0_7 = (char *) i_4;
p_8 = i.0_7 - 1B;
[...]
:;
i_11 = i_24 + 1;
# i_1 = PHI <0(2), i_11(5)>;
:;
if (i_1 < N.1_6) goto ; else goto ;
The call to analyze_scalar_evolution(loop, p_8) returns the chrec {-1B, +, 1B}
which is more or less understandable because the initial value i.0_7 can be
traced all the way back to the start of the loop to 0.
However:
1- SCEV has not realized that there is an ASSERT_EXPR in the path. The initial
value of i.0_7 is actually 1, not 0.
2- When VRP sees the chrec {-1B, +, 1B} it asks whether it may wrap. Since we
assumes that pointers never wrap, scev_probably_wraps_p returns false. Which
is understandable, I guess, but in this case we get burnt by the logic that
follows in adjust_range_with_scev:
* Since the range we have is VARYING, we take the initial value of the given
chrec and set it as the min value for the range. So, the minimum value for the
new range is set to -1B.
* Since the scalar evolution goes forward, we set the maximum value to the
max value for the type (upper_bound_in_type). Which also happens to be -1B.
* So, we end up with the range [-1B, -1B] which we later propagate into the
pointer dereference, causing the failure.
This problem does not happen in mainline because of the PTR_PLUS_EXPR cleanup.
Pointer arithmetic uses unsigned types and all this is avoided.
I think that the core problem is that we are tripping over the fact that while
we don't consider pointers to wrap, the instantiation of the chrec is giving
wrapped-around pointer values. This confuses VRP.
So far, I see the following options for fixing this:
1- Teach SCEV that subtracting pointer values from 0 yields an unkown
chrec. Similarly, adding to upper_bound_in_type will yield an unkown
chrec. What's the wording in the standard wrt pointer arithmetic? Is
the following undefined, implementation defined, or valid?
char *p = 0;
--p;
*p = 'x';
2- Teach SCEV about ASSERT_EXPRs when instantiating chrecs. Would
benefit both mainline and 4.2. May hide other bugs that occur when
there are no assertions around. But that's unlikely.
3- Tell VRP to refuse to do anything with pointer chrecs that have a constant
initial value. This may prove suboptimal in some cases where we could've
gotten a good range, but they should be few and far between.
4- In mainline, the representation of pointer arithmetic has been
cleaned up considerably with the PTR_PLUS_EXPR patches. Bringing those
in to 4.2 is IMO out of the question because of the sheer invasiveness.
But if the problem was widespread enough maybe we could consider it. I
don't think it is, though.
--
Summary: Scalar evolutions confusing VRP with pointer values that
wrap around
Product: gcc
Version: 4.2.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dnovillo at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33099
[Bug fortran/20441] -finit-local-zero is missing from gfortran
--- Comment #8 from patchapp at dberlin dot org 2007-08-17 20:15 --- Subject: Bug number PR20441 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-08/msg01151.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20441
[Bug tree-optimization/33099] [4.2 Regression] Scalar evolutions confusing VRP with pointer values that wrap around
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-08-17 20:18 --- Confirmed (and yes this was fixed by PtrPlus). -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||wrong-code Known to fail||4.2.1 Known to work||4.3.0 4.1.1 Last reconfirmed|-00-00 00:00:00 |2007-08-17 20:18:57 date|| Summary|Scalar evolutions confusing |[4.2 Regression] Scalar |VRP with pointer values that|evolutions confusing VRP |wrap around |with pointer values that ||wrap around Target Milestone|--- |4.2.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33099
[Bug tree-optimization/33099] [4.2 Regression] Scalar evolutions confusing VRP with pointer values that wrap around
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-08-17 20:20 --- Exposed by: 2006-02-07 Jeff Law <[EMAIL PROTECTED]> Which added VRP after IV-OPTs. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||law at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33099
[Bug tree-optimization/33099] [4.2 Regression] Scalar evolutions confusing VRP with pointer values that wrap around
--- Comment #3 from dnovillo at google dot com 2007-08-17 20:27 --- Subject: Re: [4.2 Regression] Scalar evolutions confusing VRP with pointer values that wrap around On 8/17/07 4:20 PM, pinskia at gcc dot gnu dot org wrote: > --- Comment #2 from pinskia at gcc dot gnu dot org 2007-08-17 20:20 > --- > Exposed by: > 2006-02-07 Jeff Law <[EMAIL PROTECTED]> > > > Which added VRP after IV-OPTs. No, no that is completely unrelated. This happens in the first VRP pass. It's all inside adjust_range_with_scev which specifically calls scalar evolutions code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33099
[Bug tree-optimization/33099] [4.2 Regression] Scalar evolutions confusing VRP with pointer values that wrap around
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-08-17 20:34 --- Oh you are correct but this still worked in 4.1.1 though, I have not looked into what changed between 4.1.1 and 4.2.0 with respect of scev yet. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC|law at gcc dot gnu dot org | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33099
[Bug tree-optimization/33099] [4.2 Regression] Scalar evolutions confusing VRP with pointer values that wrap around
--- Comment #5 from dnovillo at google dot com 2007-08-17 20:37 --- Subject: Re: [4.2 Regression] Scalar evolutions confusing VRP with pointer values that wrap around On 8/17/07 4:34 PM, pinskia at gcc dot gnu dot org wrote: > --- Comment #4 from pinskia at gcc dot gnu dot org 2007-08-17 20:34 > --- > Oh you are correct but this still worked in 4.1.1 though, I have not looked > into what changed between 4.1.1 and 4.2.0 with respect of scev yet. Since you are looking, two things to check for: (1) IL representation for the pointer subtraction, and (2) SCEV may have returned an unknown chrec back in 4.1. Or maybe we still didn't consider pointers to not-wrap. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33099
[Bug tree-optimization/33099] [4.2 Regression] Scalar evolutions confusing VRP with pointer values that wrap around
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-08-17 20:42 ---
The IR is the same but scev did something different:
Visiting statement:
p_10 = i.0_9 - 1B;
(analyze_scalar_evolution
(loop_nb = 1)
(scalar = p_10)
(get_scalar_evolution
(scalar = p_10)
(scalar_evolution = ))
(analyze_scalar_evolution
(loop_nb = 1)
(scalar = i.0_9)
(get_scalar_evolution
(scalar = i.0_9)
(scalar_evolution = {0B, +, 1B}_1))
(set_scalar_evolution
(scalar = i.0_9)
(scalar_evolution = {0B, +, 1B}_1))
)
(analyze_scalar_evolution
(loop_nb = 1)
(scalar = 1B)
(get_scalar_evolution
(scalar = 1B)
(scalar_evolution = 1B))
)
(set_scalar_evolution
(scalar = p_10)
(scalar_evolution = {4294967295B, +, 1B}_1))
)
(instantiate_parameters
(loop_nb = 1)
(chrec = {4294967295B, +, 1B}_1)
(res = {4294967295B, +, 1B}_1))
Found new range for p_10: VARYING
vs (in 4.2):
Visiting statement:
i.0_4 = (char *) i_23;
(analyze_scalar_evolution
(loop_nb = 1)
(scalar = i.0_4)
(get_scalar_evolution
(scalar = i.0_4)
(scalar_evolution = ))
(analyze_scalar_evolution
(loop_nb = 1)
(scalar = i_23)
(get_scalar_evolution
(scalar = i_23)
(scalar_evolution = {0, +, 1}_1))
(set_scalar_evolution
(scalar = i_23)
(scalar_evolution = {0, +, 1}_1))
)
(analyze_scalar_evolution
(loop_nb = 1)
(scalar = i_1)
(get_scalar_evolution
(scalar = i_1)
(scalar_evolution = {0, +, 1}_1))
(set_scalar_evolution
(scalar = i_1)
(scalar_evolution = {0, +, 1}_1))
)
(analyze_scalar_evolution
(loop_nb = 1)
(scalar = N.1_3)
(get_scalar_evolution
(scalar = N.1_3)
(scalar_evolution = ))
(set_scalar_evolution
(scalar = N.1_3)
(scalar_evolution = N.1_3))
)
(analyze_scalar_evolution
(loop_nb = 1)
(scalar = N.1_3)
(get_scalar_evolution
(scalar = N.1_3)
(scalar_evolution = N.1_3))
(set_scalar_evolution
(scalar = N.1_3)
(scalar_evolution = N.1_3))
)
(analyze_scalar_evolution
(loop_nb = 1)
(scalar = N.1_3)
(get_scalar_evolution
(scalar = N.1_3)
(scalar_evolution = N.1_3))
(set_scalar_evolution
(scalar = N.1_3)
(scalar_evolution = N.1_3))
)
(instantiate_parameters
(loop_nb = 1)
(chrec = N.1_3)
(analyze_scalar_evolution
(loop_nb = 1)
(scalar = N.1_3)
(get_scalar_evolution
(scalar = N.1_3)
(scalar_evolution = N.1_3))
(set_scalar_evolution
(scalar = N.1_3)
(scalar_evolution = N.1_3))
)
(res = scev_not_known))
(analyze_scalar_evolution
(loop_nb = 1)
(scalar = i_8)
(get_scalar_evolution
(scalar = i_8)
(scalar_evolution = ))
(analyze_scalar_evolution
(loop_nb = 1)
(scalar = i_25)
(get_scalar_evolution
(scalar = i_25)
(scalar_evolution = {0, +, 1}_1))
(set_scalar_evolution
(scalar = i_25)
(scalar_evolution = {0, +, 1}_1))
)
(analyze_scalar_evolution
(loop_nb = 1)
(scalar = 1)
(get_scalar_evolution
(scalar = 1)
(scalar_evolution = 1))
)
(set_scalar_evolution
(scalar = i_8)
(scalar_evolution = {1, +, 1}_1))
)
(instantiate_parameters
(loop_nb = 1)
(chrec = {1, +, 1}_1)
(res = {1, +, 1}_1))
Induction variable (int) 1 + 1 * iteration does not wrap in statement i_8 =
i_25 + 1 in loop 1.
Statement i_8 = i_25 + 1 is executed at most 2147483646 (bounded by 2147483646)
+ 1 times in loop 1.
(analyze_scalar_evolution
(loop_nb = 1)
(scalar = i_25)
(get_scalar_evolution
(scalar = i_25)
(scalar_evolution = {0, +, 1}_1))
(set_scalar_evolution
(scalar = i_25)
(scalar_evolution = {0, +, 1}_1))
)
(instantiate_parameters
(loop_nb = 1)
(chrec = {0, +, 1}_1)
(res = {0, +, 1}_1))
Induction variable (int) 0 + 1 * iteration does not wrap in statement i_25 =
ASSERT_EXPR in loop 1.
Statement i_25 = ASSERT_EXPR is executed at most 2147483647
(bounded by 2147483647) + 1 times in loop 1.
(set_scalar_evolution
(scalar = i.0_4)
(scalar_evolution = {0B, +, 1B}_1))
)
(instantiate_parameters
(loop_nb = 1)
(chrec = {0B, +, 1B}_1)
(res = {0B, +, 1B}_1))
Found new range for i.0_4: [0B, -1B]
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33099
[Bug c/30013] Multiple flaws in decimal floating-point arithmetic conversions fixed
--- Comment #5 from janis at gcc dot gnu dot org 2007-08-17 20:44 --- Why use "%.9e", "%.17e", and "%.36Le" to write the binary float values to a string, instead of using lengths of FLT_DIG, DBL_DIG, and LDBL_DIG? For i686-linux those are 6, 15, and 18. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30013
[Bug c++/32112] [4.1/4.2/4.3 regression] #'unbound_class_template' not supported by dump_decl#
--- Comment #3 from paolo at gcc dot gnu dot org 2007-08-17 20:47 --- Subject: Bug 32112 Author: paolo Date: Fri Aug 17 20:46:59 2007 New Revision: 127596 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127596 Log: /cp 2007-08-17 Paolo Carlini <[EMAIL PROTECTED]> PR c++/32112 * error.c (dump_decl): Deal with UNBOUND_CLASS_TEMPLATE. * cxx-pretty-print.c (pp_cxx_unqualified_id): Likewise. /testsuite 2007-08-17 Paolo Carlini <[EMAIL PROTECTED]> PR c++/32112 * g++.dg/template/error26.C: New. Added: trunk/gcc/testsuite/g++.dg/template/error26.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cxx-pretty-print.c trunk/gcc/cp/error.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32112
[Bug bootstrap/33100] New: on bootstrap getting section .eh_frame: bad cie version 0: offset 0x0
I now get this during bootstrap on Solaris x86 using the native linker (/usr/ccs/bin/ld): ld: fatal: unwind table: file /u01/var/tmp/gcc_trunk_svn/gcc_20070817/./gcc/amd64/crtend.o: section .eh_frame: bad cie version 0: offset 0x0 collect2: ld returned 1 exit status gmake[5]: *** [libgcc_s.so] Error 1 gmake[5]: Leaving directory `/u01/var/tmp/gcc_trunk_svn/gcc_20070817/i386-pc-solaris2.11/amd64/libgcc' Let me know if you need more information. It seems to occur when linking the 64bit libgcc. Brett Albertson -- Summary: on bootstrap getting section .eh_frame: bad cie version 0: offset 0x0 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: brett dot albertson at stratech dot com GCC build triplet: i386-pc-solaris2.11 GCC host triplet: i386-pc-solaris2.11 GCC target triplet: i386-pc-solaris2.11 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33100
[Bug c++/32190] wrong error recovery on parsing template arguments
--- Comment #12 from paolo at gcc dot gnu dot org 2007-08-17 21:31 --- Subject: Bug 32190 Author: paolo Date: Fri Aug 17 21:31:40 2007 New Revision: 127597 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127597 Log: 2007-08-17 Paolo Carlini <[EMAIL PROTECTED]> PR c++/32190 * g++.dg/parse/error31.C: New. Added: trunk/gcc/testsuite/g++.dg/parse/error31.C Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32190
[Bug preprocessor/32974] #pragma GCC dependency generates extra token error.
--- Comment #1 from tromey at gcc dot gnu dot org 2007-08-17 21:32 --- Looks like directives.c:parse_include is not handling the "dependency" case correctly. -- tromey at gcc dot gnu dot org changed: What|Removed |Added CC||tromey at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-08-17 21:32:12 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32974
[Bug c++/32190] wrong error recovery on parsing template arguments
--- Comment #13 from paolo at gcc dot gnu dot org 2007-08-17 21:38 --- Subject: Bug 32190 Author: paolo Date: Fri Aug 17 21:38:19 2007 New Revision: 127598 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127598 Log: 2007-08-17 Paolo Carlini <[EMAIL PROTECTED]> PR c++/32190 * g++.dg/parse/error31.C: New. Added: branches/gcc-4_2-branch/gcc/testsuite/g++.dg/parse/error31.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32190
[Bug c++/32190] wrong error recovery on parsing template arguments
--- Comment #14 from paolo at gcc dot gnu dot org 2007-08-17 21:38 --- Subject: Bug 32190 Author: paolo Date: Fri Aug 17 21:38:40 2007 New Revision: 127599 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127599 Log: 2007-08-17 Paolo Carlini <[EMAIL PROTECTED]> PR c++/32190 * g++.dg/parse/error31.C: New. Modified: branches/gcc-4_2-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32190
[Bug c++/32190] wrong error recovery on parsing template arguments
--- Comment #15 from pcarlini at suse dot de 2007-08-17 21:40 --- Already fixed in 4_2-branch and mainline. -- pcarlini at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32190
[Bug c++/31749] [4.1/4.2/4.3 regression] ICE with invalid redeclaration of builtin
--- Comment #8 from aaw at gcc dot gnu dot org 2007-08-17 21:42 --- Subject: Bug 31749 Author: aaw Date: Fri Aug 17 21:42:38 2007 New Revision: 127600 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127600 Log: PR c++/31749 gcc/cp/ * name-lookup.c (do_nonmember_using_decl): Shift implicit type declarations into appropriate slots for comparison. Fix type comparison. gcc/testsuite/ * g++.dg/lookup/builtin3.C: New test. * g++.dg/lookup/builtin4.C: New test. * g++.dg/lookup/using19.C: New test. Added: trunk/gcc/testsuite/g++.dg/lookup/builtin3.C trunk/gcc/testsuite/g++.dg/lookup/builtin4.C trunk/gcc/testsuite/g++.dg/lookup/using19.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/name-lookup.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31749
[Bug preprocessor/32974] #pragma GCC dependency generates extra token error.
--- Comment #2 from tromey at gcc dot gnu dot org 2007-08-17 22:08 --- Testing a patch. -- tromey at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tromey at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-08-17 21:32:12 |2007-08-17 22:08:53 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32974
[Bug c++/28989] [4.0/4.1/4.2 Regression] post-increment of bool variable accepted as lvalue
--- Comment #11 from pinskia at gcc dot gnu dot org 2007-08-17 22:15 --- Fixed on the trunk. --- Comment #12 from pinskia at gcc dot gnu dot org 2007-08-17 22:15 --- Subject: Bug 28989 Author: pinskia Date: Fri Aug 17 22:14:47 2007 New Revision: 127603 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127603 Log: 2007-08-17 Andrew Pinski <[EMAIL PROTECTED]> PR c++/28989 * tree.c (lvalue_p_1 ): SAVE_EXPRs are never lvalues. 2007-08-17 Andrew Pinski <[EMAIL PROTECTED]> PR c++/28989 * g++.dg/expr/lval3.C: New test. * g++.dg/expr/lval4.C: New test. Added: trunk/gcc/testsuite/g++.dg/expr/lval3.C trunk/gcc/testsuite/g++.dg/expr/lval4.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/tree.c trunk/gcc/testsuite/ChangeLog -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Known to work|3.4.0 3.0.4 3.3.3 3.2.3 |3.4.0 3.0.4 3.3.3 3.2.3 ||4.3.0 Summary|[4.0/4.1/4.2/4.3 Regression]|[4.0/4.1/4.2 Regression] |post-increment of bool |post-increment of bool |variable accepted as lvalue |variable accepted as lvalue http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28989
[Bug c++/28989] [4.0/4.1/4.2 Regression] post-increment of bool variable accepted as lvalue
--- Comment #11 from pinskia at gcc dot gnu dot org 2007-08-17 22:15 --- Fixed on the trunk. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Known to work|3.4.0 3.0.4 3.3.3 3.2.3 |3.4.0 3.0.4 3.3.3 3.2.3 ||4.3.0 Summary|[4.0/4.1/4.2/4.3 Regression]|[4.0/4.1/4.2 Regression] |post-increment of bool |post-increment of bool |variable accepted as lvalue |variable accepted as lvalue http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28989
[Bug c++/33101] New: C++ error on valid code: has incomplete type
This C++ test case works with gcc 4.1.1. With gcc 4.2 and with mainline it gets an inexplicable error. typedef void v; typedef v (*pf)(v); foo.cc:2: error: has incomplete type foo.cc:2: error: invalid use of v -- Summary: C++ error on valid code: has incomplete type Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ian at airs dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33101
[Bug c++/33101] C++ error on valid code: has incomplete type
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-08-17 23:33 --- This is not valid code. *** This bug has been marked as a duplicate of 9278 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33101
[Bug c++/9278] Illegal use of typedef to "void"
--- Comment #29 from pinskia at gcc dot gnu dot org 2007-08-17 23:33 --- *** Bug 33101 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||ian at airs dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9278
[Bug c/33102] New: volatile excessively suppresses optimizations in range checks
Source code:
--
volatile int i;
int j;
int testme(void)
{
return i <= 1;
}
int testme2(void)
{
return j <= 1;
}
--
Compiler command line: "cc -S -O torvalds.c"
--
Expected results: volatile accesses not moved past sequence points,
optimization otherwise unaffected.
--
Observed results: redundant move to register generated, unecessarily increasing
register pressure, increasing the size of the binary, and potentially consuming
more power and decreasing performance.
--
Build date and platform: August 17 2007 Ubuntu Feisty Fawn.
--
gcc -v output:
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu
--enable-libstdcxx-debug --enable-mpfr --enable-checking=release i486-linux-gnu
Thread model: posix
gcc version 4.1.2 (Ubuntu 4.1.2-0ubuntu4)
--
Code generated to compare volatile variable to constant:
movli, %eax
cmpl$1, %eax
Code generated to compare non-volatile variable to constant:
cmpl$1, j
The latter code sequence should be generated for the volatile case as well as
the non-volatile case. Similar inefficiencies are produced in response to
other uses of volatile variables.
--
Summary: volatile excessively suppresses optimizations in range
checks
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: paulmck at linux dot vnet dot ibm dot com
GCC build triplet: i486-linux-gnu
GCC host triplet: i486-linux-gnu
GCC target triplet: i486-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33102
[Bug c/33102] volatile excessively suppresses optimizations in range checks
--- Comment #2 from paulmck at linux dot vnet dot ibm dot com 2007-08-18 00:11 --- Hmmm... I wasn't asking for volatile to be atomic, just for it to avoid generating unnecessary code. -- paulmck at linux dot vnet dot ibm dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|DUPLICATE | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33102
[Bug c/33102] volatile excessively suppresses optimizations in range checks
--- Comment #3 from segher at kernel dot crashing dot org 2007-08-18 00:12 --- (In reply to comment #1) > volatile != atomic. And that is relevant why? Paul is perfectly aware of this, btw. There might be other reasons why GCC doesn't want to do this optimisation, but this isn't one of them. Please reopen, bugzilla won't allow me to do that myself. Segher -- segher at kernel dot crashing dot org changed: What|Removed |Added CC||segher at kernel dot ||crashing dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33102
[Bug c/33102] volatile excessively suppresses optimizations in range checks
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-08-18 00:12 --- It is still the same issue. *** This bug has been marked as a duplicate of 3506 *** *** This bug has been marked as a duplicate of 3506 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33102
[Bug target/3506] weird behaviour when incrementing volatile ints
--- Comment #11 from pinskia at gcc dot gnu dot org 2007-08-18 00:12 --- *** Bug 33102 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3506
[Bug target/21580] Less-than-ideal code generation for incrementing volatile variables
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-08-18 00:21 --- >omewhat also related, "(void)x;" still accesses memory when x is volatile -- > I suppose this might be desirable, however. It is because you say to load from x. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21580
[Bug c/33102] volatile excessively suppresses optimizations in range checks
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-08-18 00:05 --- volatile != atomic. *** This bug has been marked as a duplicate of 3506 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33102
[Bug target/3506] weird behaviour when incrementing volatile ints
--- Comment #10 from pinskia at gcc dot gnu dot org 2007-08-18 00:05 --- *** Bug 33102 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||paulmck at linux dot vnet ||dot ibm dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3506
[Bug c/33102] volatile excessively suppresses optimizations in range checks
--- Comment #5 from segher at kernel dot crashing dot org 2007-08-18 00:31 --- > It is still the same issue. > > *** This bug has been marked as a duplicate of 3506 *** It isn't the same issue. The submitter of #3506 claimed the code that GCC currently generates is incorrect, which obviously is not the case. _This_ PR on the other hand merely asks for GCC to be enhanced to generate _better_ code for this; a wholly different thing. So do not close as a duplicate again, thank you. Segher -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33102
[Bug c/33102] volatile excessively suppresses optimizations in range checks
--- Comment #6 from paulmck at linux dot vnet dot ibm dot com 2007-08-18 01:04 --- (In reply to comment #4) > It is still the same issue. Perhaps I am missing something, but I don't know of any hardware that would react differently to this two-instruction sequence: movli, %eax cmpl$1, %eax than it would to the following single instruction: cmpl$1, j Either way, there is a single memory reference, and for all hardware I know of, it looks the same to both memory and external devices. -- paulmck at linux dot vnet dot ibm dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|DUPLICATE | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33102
[Bug middle-end/33102] volatile excessively suppresses optimizations in range checks
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-08-18 01:10 --- One should note this is actually hard to do without changing the code for 3506 also. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33102
[Bug middle-end/33102] volatile excessively suppresses optimizations in range checks
--- Comment #8 from pinskia at gcc dot gnu dot org 2007-08-18 01:11 --- PS you should have reported this first to debian since you are using their modified version of GCC. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33102
[Bug middle-end/33102] volatile excessively suppresses optimizations in range checks
--- Comment #9 from pinskia at gcc dot gnu dot org 2007-08-18 01:12 --- s/debian/Ubuntu/ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33102
[Bug middle-end/33102] volatile excessively suppresses optimizations in range checks
--- Comment #10 from pinskia at gcc dot gnu dot org 2007-08-18 01:13 --- Actually as I understand it, the expanded version is slightly faster under newer x86's anyways as they don't have an extra decode stage. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33102
[Bug middle-end/33102] volatile excessively suppresses optimizations in range checks
--- Comment #11 from paulmck at linux dot vnet dot ibm dot com 2007-08-18 01:21 --- (In reply to comment #10) > Actually as I understand it, the expanded version is slightly faster under > newer x86's anyways as they don't have an extra decode stage. The main concern on the recent LKML thread appeared to be code size rather than speed. That said, if you are correct, it certainly wouldn't be the first time that multiple instructions turned out to be cheaper than a single instruction. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33102
[Bug middle-end/33102] volatile excessively suppresses optimizations in range checks
--- Comment #12 from paulmck at linux dot vnet dot ibm dot com 2007-08-18 01:23 --- (In reply to comment #9) > s/debian/Ubuntu/ Please accept my apologies for skipping that step -- I wasn't aware of this. Should I replicate this bug at Ubuntu, or is this strictly advice for future bug submissions? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33102
[Bug middle-end/33102] volatile excessively suppresses optimizations in range checks
--- Comment #13 from pinskia at gcc dot gnu dot org 2007-08-18 01:25 --- (In reply to comment #11) > The main concern on the recent LKML thread appeared to be code size rather > than > speed. One should note this only helps CISC based processors, it will not help stuff like PowerPC anyways. It is better to remove volatile in 95% of the places where the kernel uses it anyways than fix this bug. (In reply to comment #12) > Please accept my apologies for skipping that step -- I wasn't aware of this. > Should I replicate this bug at Ubuntu, or is this strictly advice for future > bug submissions? It would be better next time unless you can test it on a FSF GCC source release/SVN. Thanks, Andrew Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33102
[Bug c++/33101] C++ error on valid code: has incomplete type
--- Comment #2 from ian at airs dot com 2007-08-18 04:19 --- Thanks for the explanation. That is new to me. I am now going to reopen this bug because the error message is terrible. There is no anonymous or incomplete type here. gcc should perhaps print something like error: invalid use of typedef 'v' in function parameter declaration -- ian at airs dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|DUPLICATE | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33101
[Bug target/33103] New: Redundant multiplications for memset
This report was prompted by a mail on the lkml which was suggesting to
hand-craft memset: http://lkml.org/lkml/2007/8/17/309 . So I wondered if the
code generated for __builtin_memset was any good, and could be used instead of
hand-crafted code. I tested with (Debian) GCC 3.4.6, 4.1.3, 4.2.1, and also
with a snapshot of GCC 4.3. All the results are similar, so I will only show
them for GCC 4.2 on x86-64. Compilation was done with -O3.
First, the __builtin_memset code:
void fill1(char *s, int a)
{
__builtin_memset(s, a, 15);
}
GCC generates:
0: 40 0f b6 c6 movzbl %sil,%eax
4: 48 ba 01 01 01 01 01mov$0x101010101010101,%rdx
b: 01 01 01
e: 40 0f b6 ce movzbl %sil,%ecx
12: 48 0f af c2 imul %rdx,%rax
16: 40 88 77 0e mov%sil,0xe(%rdi)
1a: 48 89 07mov%rax,(%rdi)
1d: 40 0f b6 c6 movzbl %sil,%eax
21: 69 c0 01 01 01 01 imul $0x1010101,%eax,%eax
27: 89 47 08mov%eax,0x8(%rdi)
2a: 89 c8 mov%ecx,%eax
2c: c1 e0 08shl$0x8,%eax
2f: 01 c8 add%ecx,%eax
31: 66 89 47 0c mov%ax,0xc(%rdi)
35: c3 retq
Notice that GCC first computes %sil * (01)^8 and puts it into %rax, then it
computes %sil * (01)^4 and puts it into %eax (where it already was, due to the
previous multiplication), then it computes %sil * (01)^2 and puts it into %ax
(where it already was, again).
Second, some code where multiplication results are reused:
void fill2(char *s, int a)
{
unsigned long long int v = (unsigned char)a * 0x0101010101010101ull;
*(unsigned long long int *)s = v;
*(unsigned *)(s + 8) = v;
*(unsigned short *)(s + 12) = v;
*(s + 15) = v;
}
GCC generates:
0: 40 0f b6 f6 movzbl %sil,%esi
4: 48 b8 01 01 01 01 01mov$0x101010101010101,%rax
b: 01 01 01
e: 48 0f af f0 imul %rax,%rsi
12: 48 89 37mov%rsi,(%rdi)
15: 89 77 08mov%esi,0x8(%rdi)
18: 66 89 77 0c mov%si,0xc(%rdi)
1c: 40 88 77 0f mov%sil,0xf(%rdi)
20: c3 retq
The function is 21 bytes smaller (-40%), it does not require two additional
registers (c and d), and it will not be slower.
The same issue arises on x86_32. The hand-written code (with 32bit integers
this time) is 14 bytes smaller for memset(,,15).
--
Summary: Redundant multiplications for memset
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: guillaume dot melquiond at ens-lyon dot fr
GCC target triplet: x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33103
[Bug fortran/31564] Error: Type/rank mismatch in argument
--- Comment #6 from pault at gcc dot gnu dot org 2007-08-18 06:04 ---
This one is a real head-banger. The array element reference is being
completely ignored in translation. I tried simplifying it by grabbing out the
array component and attaching the array reference to it. The resulting
expression looks fine but the reference is ignore further downstream; I have
run out of time to look at this, for a while. Note that replacing the array
component of a derived type parameter with a parameter array works fine.
Just for the record, my attempt to fix this by simplification appears below.
Paul
Index: gcc/fortran/expr.c
===
*** gcc/fortran/expr.c (revision 127505)
--- gcc/fortran/expr.c (working copy)
*** simplify_ref_chain (gfc_ref *ref, int ty
*** 1461,1466
--- 1461,1535
}
+ /* Simplify structure references. */
+
+ static void
+ simplify_structure_refs (gfc_expr *e)
+ {
+ int n;
+ bool seen_array_ref;
+ bool reduced_structure = false;
+ gfc_ref *ref;
+ gfc_component *cmp;
+ gfc_constructor *ctr;
+ gfc_expr *p = e;
+ gfc_symtree *st;
+
+ if (e->expr_type != EXPR_STRUCTURE)
+ return;
+
+ start:
+ seen_array_ref = false;
+ ref = p->ref;
+
+ for (; ref; ref = ref->next)
+ {
+ switch (ref->type)
+ {
+ case REF_COMPONENT:
+ if (p->symtree
+ && p->symtree->n.sym->ts.derived
+ && !p->ts.derived)
+ p->ts = p->symtree->n.sym->ts;
+
+ if (seen_array_ref || !p->ts.derived)
+ break;
+
+ ctr = p->value.constructor;
+ cmp = p->ts.derived->components;
+ for (;ctr; ctr = ctr->next, cmp = cmp->next)
+ {
+ if (ref->u.c.component != cmp || ctr->expr == NULL)
+ continue;
+ p = ctr->expr;
+ p->ts = cmp->ts;
+ ctr->expr = NULL;
+ p->ref = ref->next;
+ ref->next = NULL;
+ gfc_free_expr (e);
+ *e = *p;
+ reduced_structure = true;
+ goto start;
+ }
+ break;
+
+ case REF_ARRAY:
+ for (n = 0; n < ref->u.ar.dimen; n++)
+ {
+ if (reduced_structure
+ && ref->u.ar.dimen_type[n] == DIMEN_ELEMENT)
+ p->rank--;
+ }
+ seen_array_ref = true;
+ break;
+
+ default:
+ break;
+ }
+ }
+ }
+
+
/* Try to substitute the value of a parameter variable. */
static try
*** gfc_simplify_expr (gfc_expr *p, int type
*** 1604,1609
--- 1673,1681
if (simplify_ref_chain (p->ref, type) == FAILURE)
return FAILURE;
+ if (p->ref)
+ simplify_structure_refs (p);
+
if (simplify_constructor (p->value.constructor, type) == FAILURE)
return FAILURE;
*** gfc_check_pointer_assign (gfc_expr *lval
*** 2749,2755
is_pure = gfc_pure (NULL);
! if (is_pure && gfc_impure_variable (lvalue->symtree->n.sym))
{
gfc_error ("Bad pointer object in PURE procedure at %L",
&lvalue->where)
;
return FAILURE;
--- 2821,2828
is_pure = gfc_pure (NULL);
! if (is_pure && gfc_impure_variable (lvalue->symtree->n.sym)
! && lvalue->symtree->n.sym->value != rvalue)
{
gfc_error ("Bad pointer object in PURE procedure at %L",
&lvalue->where)
;
return FAILURE;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31564
[Bug c++/31749] [4.1/4.2/4.3 regression] ICE with invalid redeclaration of builtin
--- Comment #9 from aaw at gcc dot gnu dot org 2007-08-18 06:26 --- Fixed by change 127600. -- aaw at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31749
[Bug target/33104] New: Missing error check in .md converter
(define_insn "mov" [(set (match_operand:MVM 0 "vg_general_operand" "=r, , r, t, r") (match_operand:MVM 1 "vg_general_operand" "r, r, t, r, I"))] "" "mov %0,%1") When both match_operands mistakenly mention 0 (instead of 0 and 1 as above), then ... build/genextract $src/gcc/config/$machine/$machine.md \ insn-conditions.md > tmp-extract.c genextract: Internal error: abort in VEC_safe_set_locstr, at genextract.c:190 ... which is not exactly a useful diagnostic. -- Summary: Missing error check in .md converter Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: kai-gcc-bugs at khms dot westfalen dot de GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: private http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33104
