[Bug fortran/29806] Error if CONTAINS is present without SUBPROGRAM
-- burnus at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |burnus at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-11-12 21:02:23 |2006-11-14 07:42:55 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29806
[Bug fortran/29821] ICE in gfc_typenode_for_spec, at fortran/trans-types.c:666ans-types.c:666
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2006-11-14 06:31 --- Still more reduced testcase: module gfcbug45 implicit none contains subroutine foo integer :: i real:: a real, parameter :: eps(1) = (/ 1 /) i = 1 a = sum (eps(i:i) * eps) end subroutine foo end module gfcbug45 If the "implicit none" or the "module ... end module" is removed, the ICE goes away. Probably worth running using a non-optimized front-end under valgrind. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org Last reconfirmed|2006-11-13 21:39:59 |2006-11-14 06:31:49 date|| Summary|ICE in |ICE in |gfc_typenode_for_spec, at |gfc_typenode_for_spec, at |fortran/trans-types.c:666 |fortran/trans- |ans-types.c:666 |types.c:666ans-types.c:666 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29821
[Bug libfortran/27895] problem with RESHAPE and zero-sized arrays
--- Comment #16 from fxcoudert at gcc dot gnu dot org 2006-11-14 06:24 --- Fixed on all active release branches. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to fail|4.2.0 4.1.2 | Known to work|4.3.0 |4.3.0 4.2.0 4.1.2 Resolution||FIXED Summary|[4.1/4.2 only] problem with |problem with RESHAPE and |RESHAPE and zero-sized |zero-sized arrays |arrays | Target Milestone|4.2.0 |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27895
[Bug libfortran/27895] [4.1/4.2 only] problem with RESHAPE and zero-sized arrays
--- Comment #15 from fxcoudert at gcc dot gnu dot org 2006-11-14 06:19 --- Subject: Bug 27895 Author: fxcoudert Date: Tue Nov 14 06:19:04 2006 New Revision: 118805 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118805 Log: PR libfortran/27895 * intrinsics/cshift0.c: Special cases for zero-sized arrays. * intrinsics/pack_generic.c: Likewise. * intrinsics/spread_generic.c: Likewise. * intrinsics/reshape_generic.c (reshape_internal): Fix so that it works correctly for zero-sized arrays. * m4/reshape.m4: Likewise. * generated/reshape_r16.c: Regenerate. * generated/reshape_c4.c: Regenerate. * generated/reshape_i4.c: Regenerate. * generated/reshape_c16.c: Regenerate. * generated/reshape_r10.c: Regenerate. * generated/reshape_r8.c: Regenerate. * generated/reshape_c10.c: Regenerate. * generated/reshape_c8.c: Regenerate. * generated/reshape_i8.c: Regenerate. * generated/reshape_i16.c: Regenerate. * generated/reshape_r4.c: Regenerate. * gfortran.dg/zero_sized_1.f90: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/zero_sized_1.f90 - copied, changed from r117890, trunk/gcc/testsuite/gfortran.dg/zero_sized_1.f90 Modified: branches/gcc-4_1-branch/gcc/testsuite/ChangeLog branches/gcc-4_1-branch/libgfortran/ChangeLog branches/gcc-4_1-branch/libgfortran/generated/reshape_c10.c branches/gcc-4_1-branch/libgfortran/generated/reshape_c16.c branches/gcc-4_1-branch/libgfortran/generated/reshape_c4.c branches/gcc-4_1-branch/libgfortran/generated/reshape_c8.c branches/gcc-4_1-branch/libgfortran/generated/reshape_i16.c branches/gcc-4_1-branch/libgfortran/generated/reshape_i4.c branches/gcc-4_1-branch/libgfortran/generated/reshape_i8.c branches/gcc-4_1-branch/libgfortran/generated/reshape_r10.c branches/gcc-4_1-branch/libgfortran/generated/reshape_r16.c branches/gcc-4_1-branch/libgfortran/intrinsics/cshift0.c branches/gcc-4_1-branch/libgfortran/intrinsics/pack_generic.c branches/gcc-4_1-branch/libgfortran/intrinsics/reshape_generic.c branches/gcc-4_1-branch/libgfortran/intrinsics/spread_generic.c branches/gcc-4_1-branch/libgfortran/m4/reshape.m4 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27895
[Bug libfortran/27895] [4.1/4.2 only] problem with RESHAPE and zero-sized arrays
--- Comment #14 from fxcoudert at gcc dot gnu dot org 2006-11-14 06:18 --- Subject: Bug 27895 Author: fxcoudert Date: Tue Nov 14 06:18:36 2006 New Revision: 118804 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118804 Log: PR libfortran/27895 * intrinsics/reshape_generic.c (reshape_internal): Fix so that it works correctly for zero-sized arrays. * m4/reshape.m4: Likewise. * generated/reshape_r16.c: Regenerate. * generated/reshape_c4.c: Regenerate. * generated/reshape_i4.c: Regenerate. * generated/reshape_c16.c: Regenerate. * generated/reshape_r10.c: Regenerate. * generated/reshape_r8.c: Regenerate. * generated/reshape_c10.c: Regenerate. * generated/reshape_c8.c: Regenerate. * generated/reshape_i8.c: Regenerate. * generated/reshape_i16.c: Regenerate. * generated/reshape_r4.c: Regenerate. * gcc/testsuite/gfortran.dg/zero_sized_1.f90: Uncomment checks for RESHAPE. Modified: branches/gcc-4_2-branch/gcc/testsuite/ChangeLog branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/zero_sized_1.f90 branches/gcc-4_2-branch/libgfortran/ChangeLog branches/gcc-4_2-branch/libgfortran/generated/reshape_c10.c branches/gcc-4_2-branch/libgfortran/generated/reshape_c16.c branches/gcc-4_2-branch/libgfortran/generated/reshape_c4.c branches/gcc-4_2-branch/libgfortran/generated/reshape_c8.c branches/gcc-4_2-branch/libgfortran/generated/reshape_i16.c branches/gcc-4_2-branch/libgfortran/generated/reshape_i4.c branches/gcc-4_2-branch/libgfortran/generated/reshape_i8.c branches/gcc-4_2-branch/libgfortran/generated/reshape_r10.c branches/gcc-4_2-branch/libgfortran/generated/reshape_r16.c branches/gcc-4_2-branch/libgfortran/generated/reshape_r4.c branches/gcc-4_2-branch/libgfortran/generated/reshape_r8.c branches/gcc-4_2-branch/libgfortran/intrinsics/reshape_generic.c branches/gcc-4_2-branch/libgfortran/m4/reshape.m4 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27895
[Bug target/27521] internal compiler error: in rs6000_split_multireg_move, at config/rs6000/rs6000.c:10613
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-11-14 06:08 --- No feedback in 3 months so closing. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27521
[Bug other/28298] Problem compiling gcc 4.1.1
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-11-14 06:07 --- building inside the src directory is not really supported. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28298
[Bug libstdc++/26810] error when building cross-compiler
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-11-14 06:06 --- No feedback in 3 months so closing. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26810
[Bug c++/29824] std::string() causes assignment errors
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-11-14 05:21 --- std::string a(); This declares a function that returns std::string. This is what the C++ standard says how to resolve this ambigous statement. -- 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=29824
[Bug c++/29824] std::string() causes assignment errors
--- Comment #1 from diltsman at gmail dot com 2006-11-14 05:18 --- I neglected to comment that the command line was: g++ test.cpp -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29824
[Bug c++/29106] [4.0 Regression] sizeof(*var) in expression drops entire line of code out of compile
--- Comment #9 from mmitchel at gcc dot gnu dot org 2006-11-14 05:17 --- Fixed in 4.1.2. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.0/4.1 Regression]|[4.0 Regression] |sizeof(*var) in expression |sizeof(*var) in expression |drops entire line of code |drops entire line of code |out of compile |out of compile http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29106
[Bug c++/29824] New: std::string() causes assignment errors
#include
int main()
{
std::string a();
a="alskdfjasdj";
return 0;
}
output:
test.cpp: In function int main():
test.cpp:6: error: assignment of function std::string a()
test.cpp:6: error: cannot convert const char [12] to std::string ()() in
assignment
#include
int main()
{
std::string a("");
a="alskdfjasdj";
return 0;
}
This compiles.
My understanding is that std::string a() and std::string a("") should have
exactly the same result, such that the assignment of the c-string should be
valid in both situations.
--
Summary: std::string() causes assignment errors
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: diltsman at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29824
[Bug c++/29106] [4.0/4.1 Regression] sizeof(*var) in expression drops entire line of code out of compile
--- Comment #8 from mmitchel at gcc dot gnu dot org 2006-11-14 05:11 --- Subject: Bug 29106 Author: mmitchel Date: Tue Nov 14 05:11:32 2006 New Revision: 118803 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118803 Log: PR c++/29106 * init.c (constant_value_1): Treat a DECL_INITIAL of error_mark_node as meaning that the variable is uninitialized, rather than erroneously initialized. PR c++/29106 * g++.dg/init/self1.C: New test. * g++.dg/other/fold1.C: Adjust error markers. * g++.dg/init/member1.C: Likewise. Added: branches/gcc-4_1-branch/gcc/testsuite/g++.dg/init/self1.C Modified: branches/gcc-4_1-branch/gcc/cp/ChangeLog branches/gcc-4_1-branch/gcc/cp/init.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog branches/gcc-4_1-branch/gcc/testsuite/g++.dg/init/member1.C branches/gcc-4_1-branch/gcc/testsuite/g++.dg/other/fold1.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29106
[Bug c++/29518] [4.0 Regression] rejects valid template argument, enums vs templates
--- Comment #19 from mmitchel at gcc dot gnu dot org 2006-11-14 05:00 --- Fixed in 4.1.2, 4.2.0. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.0/4.1/4.2 Regression]|[4.0 Regression] rejects |rejects valid template |valid template argument, |argument, enums vs templates|enums vs templates http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29518
[Bug c++/29518] [4.0/4.1/4.2 Regression] rejects valid template argument, enums vs templates
--- Comment #18 from mmitchel at gcc dot gnu dot org 2006-11-14 04:59 --- Subject: Bug 29518 Author: mmitchel Date: Tue Nov 14 04:59:48 2006 New Revision: 118801 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118801 Log: PR c++/29518 * pt.c (coerce_template_parms): Do not skip_evaluation while substituting template arguments. PR c++/29518 * g++.dg/template/static28.C: New test. Added: branches/gcc-4_2-branch/gcc/testsuite/g++.dg/template/static28.C Modified: branches/gcc-4_2-branch/gcc/cp/ChangeLog branches/gcc-4_2-branch/gcc/cp/pt.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29518
[Bug debug/29792] DWARF: Not all inline concrete instances are being generated
--- Comment #9 from dberlin at gcc dot gnu dot org 2006-11-14 04:53 --- Subject: Re: DWARF: Not all inline concrete instances are being generated On 13 Nov 2006 16:16:50 -, acme at mandriva dot com <[EMAIL PROTECTED]> wrote: > > > --- Comment #8 from acme at mandriva dot com 2006-11-13 16:16 --- > > > OK, I thought that this was due to something like what you described, > > > even not > > > knowing that much about gcc internals, but I thought that even in this > > > case the > > > DW_TAG_inlined_subroutine would be emitted, or hoped to as it would allow > > > me to > > > do what I want with my tools :-\ > > > > There is nothing to emit debug info about, so we don't. > > > > Well, at least gcc emits this: > > <1>: Abbrev Number: 65 (DW_TAG_subprogram) > DW_AT_sibling : > DW_AT_name: (indirect string, offset: 0x4515): __task_rq_lock > DW_AT_decl_file : 1 > DW_AT_decl_line : 378 > DW_AT_prototyped : 1 > DW_AT_type: <9a2f> > DW_AT_inline : 3 (declared as inline and inlined) > > But no DW_TAG_inlined_subroutine, as we've been discussing: > > [EMAIL PROTECTED] net-2.6.20]$ readelf -wi > ../OUTPUT/qemu/net-2.6.20/kernel/sched.o > | grep a2f2 > DW_AT_sibling : > <1>: Abbrev Number: 65 (DW_TAG_subprogram) > [EMAIL PROTECTED] net-2.6.20]$ I'm quite aware of what GCC outputs here :) However, past the initial declarations, we don't output debug information about what the state of the IR is at random points in the compilation, only about what the final output looks like. Since there is no inlined code left, we don't end up saying there is an inlined subroutine. Even if we could change this, i'm not sure we'd want to. It doesn't seem incorrect at all to do what we do. Otherwise, you'd end up with inlined subroutine dies with no low pc/high pc associated with them, which seems nonsensical. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29792
Re: [Bug debug/29792] DWARF: Not all inline concrete instances are being generated
On 13 Nov 2006 16:16:50 -, acme at mandriva dot com <[EMAIL PROTECTED]> wrote: --- Comment #8 from acme at mandriva dot com 2006-11-13 16:16 --- > > OK, I thought that this was due to something like what you described, even not > > knowing that much about gcc internals, but I thought that even in this case the > > DW_TAG_inlined_subroutine would be emitted, or hoped to as it would allow me to > > do what I want with my tools :-\ > > There is nothing to emit debug info about, so we don't. > Well, at least gcc emits this: <1>: Abbrev Number: 65 (DW_TAG_subprogram) DW_AT_sibling : DW_AT_name: (indirect string, offset: 0x4515): __task_rq_lock DW_AT_decl_file : 1 DW_AT_decl_line : 378 DW_AT_prototyped : 1 DW_AT_type: <9a2f> DW_AT_inline : 3 (declared as inline and inlined) But no DW_TAG_inlined_subroutine, as we've been discussing: [EMAIL PROTECTED] net-2.6.20]$ readelf -wi ../OUTPUT/qemu/net-2.6.20/kernel/sched.o | grep a2f2 DW_AT_sibling : <1>: Abbrev Number: 65 (DW_TAG_subprogram) [EMAIL PROTECTED] net-2.6.20]$ I'm quite aware of what GCC outputs here :) However, past the initial declarations, we don't output debug information about what the state of the IR is at random points in the compilation, only about what the final output looks like. Since there is no inlined code left, we don't end up saying there is an inlined subroutine. Even if we could change this, i'm not sure we'd want to. It doesn't seem incorrect at all to do what we do. Otherwise, you'd end up with inlined subroutine dies with no low pc/high pc associated with them, which seems nonsensical.
[Bug c++/29823] attribute((sentinel)) warning does not trigger for member function template
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-11-14 04:34 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||diagnostic Known to fail||4.1.2 4.0.4 4.2.0 4.3.0 Last reconfirmed|-00-00 00:00:00 |2006-11-14 04:34:35 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29823
[Bug libmudflap/19319] Mudflap produce many violations on simple, correct c++ program
--- Comment #24 from ppluzhnikov at charter dot net 2006-11-14 04:26 --- Created an attachment (id=12615) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12615&action=view) annotated transcript Might the problem be that I am compiling on an "old" glibc? Or that you didn't invoke ./make and didn't in fact run the resulting exe? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19319
[Bug java/29812] env->klass value is not updated during the native calls
--- Comment #2 from wfragg at gmail dot com 2006-11-14 04:01 --- The patch mentioned in mailing list does not solves the problem (and this is stated in one of the reply). It just demonstrates the problem. If this problem was solved - that's fine, just close the bug. Yesterday I realized that I've sent a problem to the mailing list few months ago, but did not reported the bug here. So to make sure that this issue will not be lost in burden, I've posted this report. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29812
[Bug libmudflap/19319] Mudflap produce many violations on simple, correct c++ program
--- Comment #23 from fche at redhat dot com 2006-11-14 03:53 --- As I said in comment 16, this problem isn't limited to C++ code either. > Instrument gmake-3.81, and you'll get 100,000+ violations Sorry, I don't see that. configured gnu make 3.81 compiled with mainline, CFLAGS="-fmudflap" LDFLAGS="-lmudflap". ran resulting executable. No problems at all, just slower. Tried again with "-O2 -fmudflap". Same result. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19319
[Bug c++/29704] [4.1 Regression] ICE: default non-type template argument of pointer-to-member type
--- Comment #2 from bangerth at dealii dot org 2006-11-14 03:45 ---
I believe the code is in fact invalid, based on 14.3.2/1 and this wording
in 14.3.2/5:
-- For a non-type template-parameter of type pointer to member
function, no conversions apply.
The latter reference means that there is also no way to simply say
template
struct S { };
because the argument is not converted.
W.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29704
[Bug fortran/26994] [4.2 Regression] Scalar TRANSFER - error: invalid operand to unary operator
--- Comment #18 from pinskia at gcc dot gnu dot org 2006-11-14 03:28 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26994
[Bug fortran/26994] [4.2 Regression] Scalar TRANSFER - error: invalid operand to unary operator
--- Comment #17 from pinskia at gcc dot gnu dot org 2006-11-14 03:28 --- Subject: Bug 26994 Author: pinskia Date: Tue Nov 14 03:28:17 2006 New Revision: 118800 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118800 Log: 2006-11-13 Andrew Pinski <[EMAIL PROTECTED]> PR fortran/26994 * gfortran.fortran-torture/compile/transfer-1.f90: New testcase. 2006-11-13 Andrew Pinski <[EMAIL PROTECTED]> PR fortran/26994 * trans-expr.c (gfc_conv_expr_reference): Set TREE_STATIC on the new CONST_DECL. Added: branches/gcc-4_2-branch/gcc/testsuite/gfortran.fortran-torture/compile/transfer-1.f90 Modified: branches/gcc-4_2-branch/gcc/fortran/ChangeLog branches/gcc-4_2-branch/gcc/fortran/trans-expr.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26994
[Bug c++/29823] New: attribute((sentinel)) warning does not trigger for member function template
// gcc-bug: attribute((sentinel)) warning does not trigger for member function
template
//
// how to reproduce: g++-4.1.1 -Wall -c test.cpp
// Markus F.X.J. Oberhumer <[EMAIL PROTECTED]>
#define SENTINEL __attribute__((__sentinel__))
void func1(const char *, ...) SENTINEL;
template void func2(const T *, ...)SENTINEL;
static void func3(const char *, ...) SENTINEL;
template static void func4(const T *, ...)SENTINEL;
struct C {
void func1(const char *, ...) SENTINEL;
template void func2(const T *, ...)SENTINEL;
static void func3(const char *, ...) SENTINEL;
template static void func4(const T *, ...)SENTINEL;
};
static void func3(const char *, ...) { } // definition
void foo(C &c)
{
func1("a", "b");// warning here
func2("a", "b");// warning here
func3("a", "b");// warning here
func4("a", "b");// warning here
c.func1("a", "b"); // warning here
c.func2("a", "b"); // NO warning here !
c.func3("a", "b"); // warning here
c.func4("a", "b"); // NO warning here !
}
--
Summary: attribute((sentinel)) warning does not trigger for
member function template
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: markus at oberhumer dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29823
[Bug target/29818] code with SSE segfaults with gcc-3.4.6, runs fine with gcc-4.1.1
--- Comment #7 from sergstesh at yahoo dot com 2006-11-14 02:54 --- (In reply to comment #6) > (In reply to comment #5) > > We can make a deal: I obfuscate and publish the code, you guys fix the > > bug preserving, if possible, performance. > > > > The code is really complex, and it's not realistic for me to make it > > smaller. > > I guess our side of the deal would be: if you don't want to help us, we don't > want to help you. You need to give us some more information to entice us to > spend our leisure time on it. This is free software, after all. > > W. > I don't quite understand what you want. Will it be enough if I give you the code which shows the above performance difference ? Are you interested to do the research and improvement ? I am simply saying I do not want to spend my time changing the code to be able to publish it if you are not going to deal with the performance issue anyway. I think it's common interest to have a well performing compiler, especially taking into account that the newer version performs somewhat worse than the older one. If you are talking about the size - believe me the code is really sensitive, that's why I am afraid to change it significantly. For example, initially there were parts organized like this: - it was easier to think of the implementation this way. Logically it was possible to interleave pieces of and , so I tried this change, and it improved performance. I tried other things like interleaved/separate buffers, but the result deteriorated. So, I am where am, and I'm afraid if I changed the code the performance phenomena would change with it. I probably can still make the code smaller - there are kind of unrolled by myself loops in it (but not quite, i.e. it's not only array elements in the unrolled pieces), so I can probably decrease the number of iterations. So, say, instead of 60 similar pieces in each portion you'll have 30 or 20 ones. But it will still be thousands of lines. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29818
[Bug target/29818] code with SSE segfaults with gcc-3.4.6, runs fine with gcc-4.1.1
--- Comment #6 from bangerth at dealii dot org 2006-11-14 02:29 --- (In reply to comment #5) > We can make a deal: I obfuscate and publish the code, you guys fix the > bug preserving, if possible, performance. > > The code is really complex, and it's not realistic for me to make it smaller. I guess our side of the deal would be: if you don't want to help us, we don't want to help you. You need to give us some more information to entice us to spend our leisure time on it. This is free software, after all. W. -- bangerth at dealii dot org changed: What|Removed |Added CC||bangerth at dealii dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29818
[Bug target/29818] code with SSE segfaults with gcc-3.4.6, runs fine with gcc-4.1.1
--- Comment #5 from sergstesh at yahoo dot com 2006-11-14 01:36 --- (In reply to comment #4) > (In reply to comment #3) > > I am developing pretty heavy SSE-based code, and performance-wise gcc-3.4.6 > > is > > the best so far. Sorry, I cant' post the code, but here are performance > > figures (output of 'time' command): > > Then, you are not helping the project: a closed branch is not re-opened > because > of a bug and posting performance numbers without a *reduced* snippet > pinpointing the specific issue is not useful to the developers (the only > possible effect is making someone slightly nervous ;) > The "real" piece of code I'm working on is 14923 lines long (the "C" file, not the "i" file). I can think of obfuscating it to the point it becomes not clear what it is doing functionally. We can make a deal: I obfuscate and publish the code, you guys fix the bug preserving, if possible, performance. The code is really complex, and it's not realistic for me to make it smaller. By the way, using gcc-3.4.6 with '-O3' makes performance much worse, worse than the one obtained with gcc-4.1.1. On the other hand, '-O3' applied to gcc-4.1.1 does not change the performance that drastic, though I do not remember at the moment whether the performance improves or deteriorates. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29818
[Bug fortran/29814] integer assignment in hexadecimal fails
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2006-11-14 01:23 --- Try -fno-range-check or use standard conforming methods. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29814
[Bug ada/29802] wrong directory in makefile for ada and libada when building the src directory
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||bonzini at gnu dot org Severity|major |normal Summary|wrong directory in makefile |wrong directory in makefile |for ada and libada |for ada and libada when ||building the src directory http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29802
[Bug target/29818] code with SSE segfaults with gcc-3.4.6, runs fine with gcc-4.1.1
--- Comment #4 from pcarlini at suse dot de 2006-11-14 01:17 --- (In reply to comment #3) > I am developing pretty heavy SSE-based code, and performance-wise gcc-3.4.6 is > the best so far. Sorry, I cant' post the code, but here are performance > figures (output of 'time' command): Then, you are not helping the project: a closed branch is not re-opened because of a bug and posting performance numbers without a *reduced* snippet pinpointing the specific issue is not useful to the developers (the only possible effect is making someone slightly nervous ;) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29818
[Bug middle-end/29756] SSE intrinsics hard to use without redundant temporaries appearing
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-11-14 01:15 --- This is mostly PR 28367. There are most likely other issues like some of the SSE intrinsics not being declared as pure/const. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||28367 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29756
[Bug middle-end/27945] [4.0/4.1/4.2/4.3 Regression] Packed struct of variable length has wrong size
--- Comment #8 from jason at gcc dot gnu dot org 2006-11-14 01:10 --- Ah, I see the problem. The code I removed from the C and C++ front ends was redundant with code in layout_decl, except that the code in layout_decl deliberately ignores DECL_PACKED for fields of variable size. /* If the field is of variable size, we can't misalign it since we have no way to make a temporary to align the result. But this isn't an issue if the decl is not addressable. Likewise if it is of unknown size. Note that do_type_align may set DECL_USER_ALIGN, so we need to check old_user_align instead. */ =>if (packed_p && !old_user_align && (DECL_NONADDRESSABLE_P (decl) || DECL_SIZE_UNIT (decl) == 0 || TREE_CODE (DECL_SIZE_UNIT (decl)) == INTEGER_CST)) DECL_ALIGN (decl) = MIN (DECL_ALIGN (decl), BITS_PER_UNIT); This dates back to a change of Kenner's from 2001: Sat Dec 29 15:48:54 2001 Richard Kenner <[EMAIL PROTECTED]> * stor-layout.c (layout_decl): Don't misalign field of variable size for packed record. Richard, do you have any input? Do you think there a way to make that test more specific to the case were fixing? -- jason at gcc dot gnu dot org changed: What|Removed |Added CC||kenner at vlsi1 dot ultra ||dot nyu dot edu AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2006-06-09 07:45:54 |2006-11-14 01:10:19 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27945
[Bug tree-optimization/29751] not optimizing access a[0] , a[1]
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-11-14 01:06 ---
This is a problem of our VOPs not having base+offset and has nothing to do with
restrict.
int f(int *r)
{
r[0] = 0;
r[1] = 0;
if(r[0]) foo();
}
is enough to reproduce the issue. Also I think there might be a couple dups of
this with respect of structs instead.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Summary|Missed optimization of |not optimizing access a[0] ,
|restrict pointer assigned |a[1]
|value |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29751
[Bug target/29818] code with SSE segfaults with gcc-3.4.6, runs fine with gcc-4.1.1
--- Comment #3 from sergstesh at yahoo dot com 2006-11-14 01:04 --- (In reply to comment #2) > You should note that 3.4.x is no longer being maintained so this bug will most > likely be closed as fixed as you already mention it works in 4.1.1. > That's too bad. I am developing pretty heavy SSE-based code, and performance-wise gcc-3.4.6 is the best so far. Sorry, I cant' post the code, but here are performance figures (output of 'time' command): with gcc-4.1.1 -O3: 567.341u 2.098s 9:35.75 98.9% 0+0k 0+0io 0pf+0w 567.055u 2.229s 9:37.18 98.6% 0+0k 0+0io 0pf+0w with gcc-3.4.6 -O2: 543.440u 2.038s 9:13.76 98.5% 0+0k 0+0io 0pf+0w 542.925u 2.149s 9:16.29 97.9% 0+0k 0+0io 0pf+0w . -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29818
[Bug target/29817] --enable-threads=posix not working under AIX
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-11-14 01:00 --- AIX "threading" is always enabled. Note this threading model is only for libstdc++, exceptions, and libobjc and not your own program. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29817
[Bug target/29817] --enable-threads=posix not working under AIX
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-11-14 00:57 --- In fact it is. #ifdef _THREAD_SAFE #include "gthr-posix.h" #else #include "gthr-single.h" #endif -- 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=29817
[Bug target/29817] --enable-threads=posix not working under AIX
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-11-14 00:55 --- (In reply to comment #0) > I am compiling with a gcc-4.1.1 binary that someone else had built. The > reason > I am not using his binary is because I need a posix threading model. Am I > doing something wrong? IIRC AIX threading is really POSIX thread or single threading depending on the compile time options you give to GCC while compiling your sources. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29817
[Bug target/29818] code with SSE segfaults with gcc-3.4.6, runs fine with gcc-4.1.1
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-11-14 00:53 --- You should note that 3.4.x is no longer being maintained so this bug will most likely be closed as fixed as you already mention it works in 4.1.1. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29818
[Bug libstdc++/29688] resize initializes whole array
--- Comment #6 from pcarlini at suse dot de 2006-11-14 00:53 --- I have analized in detail the case at issue (resize to the same size of the current one) and came to the conclusion that trying to optimize for it (at the cost of increasing the size of the inlined function) isn't really worth the trouble, taking also into account that for PODs __valarray_destroy_elements is already optimized out. -- pcarlini at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29688
[Bug middle-end/28915] [4.1 regression] ICE: tree check: expected class 'constant', have 'declaration' (var_decl) in build_vector, at tree.c:973
--- Comment #23 from jason at gcc dot gnu dot org 2006-11-13 23:42 --- fixed. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28915
[Bug middle-end/28915] [4.1 regression] ICE: tree check: expected class 'constant', have 'declaration' (var_decl) in build_vector, at tree.c:973
--- Comment #22 from jason at gcc dot gnu dot org 2006-11-13 23:31 --- Subject: Bug 28915 Author: jason Date: Mon Nov 13 23:31:16 2006 New Revision: 118786 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118786 Log: PR middle-end/28915 * gimplify.c (gimplify_init_constructor): Don't reduce TREE_CONSTANT vector ctors. * tree-cfg.c (verify_expr): Don't look into TREE_CONSTANT vector ctors. * expmed.c (make_tree): Handle CONST, SYMBOL_REF. * tree.c (build_vector): Handle non-_CST elements. Added: branches/gcc-4_1-branch/gcc/testsuite/gcc.target/i386/vectorize1.c - copied unchanged from r118747, trunk/gcc/testsuite/gcc.target/i386/vectorize1.c Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/expmed.c branches/gcc-4_1-branch/gcc/gimplify.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog branches/gcc-4_1-branch/gcc/tree-cfg.c branches/gcc-4_1-branch/gcc/tree.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28915
[Bug middle-end/28651] [4.0 Regression] signed compare incorrectly false for (int)(U+4)<(int)U where U is unsigned INT_MAX (for optimized x86)
--- Comment #18 from janis at gcc dot gnu dot org 2006-11-13 23:03 --- Richard's testsuite change is now on the 4.1 branch, so the test passes again there. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28651
[Bug testsuite/28703] FAIL: gcc.c-torture/execute/pr28651.c execution
--- Comment #10 from janis at gcc dot gnu dot org 2006-11-13 23:01 --- Subject: Bug 28703 Author: janis Date: Mon Nov 13 23:01:09 2006 New Revision: 118782 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118782 Log: Backport from mainline: 2006-08-14 Richard Guenther <[EMAIL PROTECTED]> PR testsuite/28703 * gcc.c-torture/execute/pr28651.c: Do not use argc to avoid optimization, instead forbid inlining. Modified: branches/gcc-4_1-branch/gcc/testsuite/ChangeLog branches/gcc-4_1-branch/gcc/testsuite/gcc.c-torture/execute/pr28651.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28703
[Bug bootstrap/23158] building GCC 3.3.6 fails on ppc64 with gcc4 and gcc4.1
--- Comment #19 from tom_gall at mac dot com 2006-11-13 22:32 --- This is still an issue and I'm seeing it on both my power3 and power4 hardware using gcc 4.1.1 and glibc 2.5, granted using gcc 3.3.6 to build libstdc++.so.5 It's of interest as there are several pieces of proprietary software in the universe that require this shared lib, so I'm motivated. I'll see if I can dig some more this evening. -- tom_gall at mac dot com changed: What|Removed |Added CC||tom_gall at mac dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23158
[Bug fortran/29821] ICE in gfc_typenode_for_spec, at fortran/trans-types.c:666
--- Comment #2 from burnus at gcc dot gnu dot org 2006-11-13 21:39 --- Slightly reduced test case: module gfcbug45 implicit none type cartesian real :: x(2) end type cartesian contains subroutine foo (z) type(cartesian), intent(in) :: z integer :: i real:: a real, parameter :: eps(2) = (/ 1, 2 /) i = 1 a = sum (eps(i:2) * z%x(1:2)) end subroutine foo end module gfcbug45 #1 0x004956f7 in gfc_typenode_for_spec (spec=) at fortran/trans-types.c:666 #2 0x00495d55 in gfc_sym_type (sym=0xde0be0) at fortran/trans-types.c:1316 #3 0x00496265 in gfc_get_function_type (sym=0xde0be0) at fortran/trans-types.c:1781 #4 0x0047405e in gfc_get_extern_function_decl (sym=0xde0be0) at fortran/trans-decl.c:1125 #5 0x0047ab54 in gfc_conv_function_val (se=0x7fff1a23f3a0, sym=0xde0be0) at fortran/trans-expr.c:1222 -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||burnus at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||ice-on-valid-code Last reconfirmed|-00-00 00:00:00 |2006-11-13 21:39:59 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29821
[Bug fortran/29821] ICE in gfc_typenode_for_spec, at fortran/trans-types.c:666
--- Comment #1 from anlauf at gmx dot de 2006-11-13 21:31 --- Created an attachment (id=12612) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12612&action=view) ICE demo code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29821
[Bug fortran/29821] New: ICE in gfc_typenode_for_spec, at fortran/trans-types.c:666
Hi, here's another one: gfcbug45.f90: In function 'foo': gfcbug45.f90:8: internal compiler error: in gfc_typenode_for_spec, at fortran/trans-types.c:666 Sample code attached. Enough for tonight... -- Summary: ICE in gfc_typenode_for_spec, at fortran/trans- types.c:666 ans-types.c:666 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: anlauf at gmx dot de GCC host triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29821
[Bug fortran/29820] ICE in fold_convert, at fold-const.c:2146
--- Comment #3 from burnus at gcc dot gnu dot org 2006-11-13 21:18 ---
Funny enough, gfortran does not crash when one reverts the order of point and
plane.
Debug information:
In trans-expr.c's gfc_trans_scalar_assign
gfc_add_block_to_block (&block, &lse->pre);
gfc_add_block_to_block (&block, &rse->pre);
gfc_add_modify_expr (&block, lse->expr,
fold_convert (TREE_TYPE (lse->expr), rse->expr));
Where TREE_TYPE (lse->expr) and TREE_TYPE (rse->expr) are:
(gdb) p rse->expr->common.type->common.code
$4 = RECORD_TYPE
(gdb) p lse->expr->common.type->common.code
$5 = RECORD_TYPE
And in fold_convert:
fold_convert (tree type, tree arg)
{
tree orig = TREE_TYPE (arg);
tree tem;
if (type == orig)
return arg;
(gdb) p arg->common.type # TREE_TYPE (arg) == orig
$14 = (tree) 0x2b3117d25c60
(gdb) p type # type
$15 = (tree) 0x2b3117d25a50
Thus the first "if" does not match. As RECORD_TYPE is not supported (except for
that if), the ICE happens.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
CC||burnus at gcc dot gnu dot
||org
Keywords||ice-on-valid-code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29820
[Bug fortran/29820] ICE in fold_convert, at fold-const.c:2146
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-11-13 20:03 --- Here is a shorter testcase: module geo type geodetic real :: h end type geodetic end module geo module gfcbug44 implicit none contains subroutine point ( gp) use geo type(geodetic), intent(out) :: gp type(geodetic) :: gpx(1) gp = gpx(1) end subroutine point subroutine plane () use geo type(geodetic) :: gp call point ( gp) end subroutine plane end module gfcbug44 -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-11-13 20:03:19 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29820
[Bug fortran/29820] ICE in fold_convert, at fold-const.c:2146
--- Comment #1 from anlauf at gmx dot de 2006-11-13 19:57 --- Created an attachment (id=12611) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12611&action=view) Demo code provoking ICE -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29820
[Bug fortran/29820] New: ICE in fold_convert, at fold-const.c:2146
Hi, the attached code exhibits an ICE: gfcbug44.f90: In function 'point': gfcbug44.f90:28: internal compiler error: in fold_convert, at fold-const.c:2146 Cheers, -ha -- Summary: ICE in fold_convert, at fold-const.c:2146 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: anlauf at gmx dot de GCC host triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29820
[Bug target/27067] Compile errors with multiple inheritance where the stdcall attribute is applied to virtual functions.
--- Comment #6 from thomas at reactsoft dot com 2006-11-13 19:55 --- Created an attachment (id=12610) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12610&action=view) Updated patch against the gcc-4_1-branch The posted patch works fine, it fixes compilation errors of some win32 COM code with mingw. Please commit the patch. I merged the patch by hand and created a new patch file against gcc-4_1-branch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27067
[Bug fortran/29759] ice on line continuation in OMP statements (gfc_next_char_literal, at fortran/scanner.c:701)
--- Comment #5 from jakub at gcc dot gnu dot org 2006-11-13 19:54 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29759
[Bug fortran/29759] ice on line continuation in OMP statements (gfc_next_char_literal, at fortran/scanner.c:701)
--- Comment #4 from jakub at gcc dot gnu dot org 2006-11-13 19:44 --- Subject: Bug 29759 Author: jakub Date: Mon Nov 13 19:44:23 2006 New Revision: 118774 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118774 Log: PR fortran/29759 * fortran/scanner.c (skip_free_comments): Clear openmp_flag before returning true. * gfortran.dg/gomp/pr29759.f90: New test. Added: branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/gomp/pr29759.f90 Modified: branches/gcc-4_2-branch/gcc/fortran/ChangeLog branches/gcc-4_2-branch/gcc/fortran/scanner.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29759
[Bug fortran/29759] ice on line continuation in OMP statements (gfc_next_char_literal, at fortran/scanner.c:701)
--- Comment #3 from jakub at gcc dot gnu dot org 2006-11-13 19:43 --- Subject: Bug 29759 Author: jakub Date: Mon Nov 13 19:42:55 2006 New Revision: 118773 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118773 Log: PR fortran/29759 * fortran/scanner.c (skip_free_comments): Clear openmp_flag before returning true. * gfortran.dg/gomp/pr29759.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/gomp/pr29759.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/scanner.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29759
[Bug libfortran/29568] implement unformatted files with subrecords (Intel style)
--- Comment #7 from tkoenig at gcc dot gnu dot org 2006-11-13 19:11 --- Created an attachment (id=12609) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12609&action=view) newest version Here's the newest version of the patch, which does reading and backspace, plus defaults to four-byte record markers, with requried corrections in the testsuite. Unfortunately, there was one thinko in the approach I took with reading. Even for subrecords, we need to be able to spot if we exceed recl. Back to the drawing board... -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added Attachment #12581|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29568
[Bug fortran/29806] Error if CONTAINS is present without SUBPROGRAM
--- Comment #3 from patchapp at dberlin dot org 2006-11-13 18:55 --- Subject: Bug number PR29806 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-11/msg00871.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29806
[Bug middle-end/28915] [4.1 regression] ICE: tree check: expected class 'constant', have 'declaration' (var_decl) in build_vector, at tree.c:973
--- Comment #21 from hjl at gcc dot gnu dot org 2006-11-13 18:55 --- Subject: Bug 28915 Author: hjl Date: Mon Nov 13 18:55:08 2006 New Revision: 118772 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118772 Log: 2006-11-12 Jason Merrill <[EMAIL PROTECTED]> Andrew Pinski <[EMAIL PROTECTED]> Backport form mainline: PR middle-end/28915 * gcc.target/i386/vectorize1.c: New. Modified: branches/gcc-4_2-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28915
[Bug middle-end/28915] [4.1 regression] ICE: tree check: expected class 'constant', have 'declaration' (var_decl) in build_vector, at tree.c:973
--- Comment #20 from hjl at gcc dot gnu dot org 2006-11-13 18:53 --- Subject: Bug 28915 Author: hjl Date: Mon Nov 13 18:53:27 2006 New Revision: 118771 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118771 Log: 2006-11-12 Jason Merrill <[EMAIL PROTECTED]> Andrew Pinski <[EMAIL PROTECTED]> PR middle-end/28915 * gcc.target/i386/vectorize1.c: New. Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28915
[Bug java/29812] env->klass value is not updated during the native calls
--- Comment #1 from mtrudel at gmx dot ch 2006-11-13 18:48 --- Why do you make a bugreport if there's already a fix for that? Did no one reply to your patch or don't you have copyright assignment? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29812
[Bug c++/29518] [4.0/4.1/4.2 Regression] rejects valid template argument, enums vs templates
--- Comment #17 from mmitchel at gcc dot gnu dot org 2006-11-13 18:41 --- Subject: Bug 29518 Author: mmitchel Date: Mon Nov 13 18:41:26 2006 New Revision: 118770 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118770 Log: PR c++/29518 * pt.c (coerce_template_parms): Do not skip_evaluation while substituting template arguments. PR c++/29518 * g++.dg/template/static28.C: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/g++.dg/template/static28.C Modified: branches/gcc-4_1-branch/gcc/cp/ChangeLog branches/gcc-4_1-branch/gcc/cp/pt.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29518
[Bug fortran/29642] Fortran 2003: VALUE Attribute (call by value not call by reference for actual arguments)
--- Comment #2 from pault at gcc dot gnu dot org 2006-11-13 18:39 --- Created an attachment (id=12608) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12608&action=view) Implementation of VALUE and three testcases This patch is regtesting as I write; I have to leave right now, so I will not see the confirmation until tomorrow. I will submit in the next 24hours. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29642
[Bug target/29818] code with SSE segfaults with gcc-3.4.6, runs fine with gcc-4.1.1
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|blocker |normal Component|c |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29818
[Bug middle-end/28651] [4.0 Regression] signed compare incorrectly false for (int)(U+4)<(int)U where U is unsigned INT_MAX (for optimized x86)
--- Comment #17 from janis at gcc dot gnu dot org 2006-11-13 18:01 --- The version of the test in mainline was modified to not check argc; I'll backport Richard's test fix to 4.1. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28651
[Bug middle-end/28651] [4.0 Regression] signed compare incorrectly false for (int)(U+4)<(int)U where U is unsigned INT_MAX (for optimized x86)
--- Comment #16 from janis at gcc dot gnu dot org 2006-11-13 17:54 --- I a saw a failure for this when testing backported testsuite changes, but it passed when I ran it alone (with execute.exp=pr28651.c in RUNTESTFLAGS). I'm testing it again now to see if the failure is intermittent, or if my testsuite changes somehow broke the (argc > 1) check in the test. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28651
[Bug c++/29518] [4.0/4.1/4.2 Regression] rejects valid template argument, enums vs templates
--- Comment #16 from mmitchel at gcc dot gnu dot org 2006-11-13 17:52 --- Fixed in 4.3.0. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.0/4.1/4.2/4.3 Regression]|[4.0/4.1/4.2 Regression] |rejects valid template |rejects valid template |argument, enums vs templates|argument, enums vs templates http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29518
[Bug c++/29518] [4.0/4.1/4.2/4.3 Regression] rejects valid template argument, enums vs templates
--- Comment #15 from mmitchel at gcc dot gnu dot org 2006-11-13 17:49 --- Subject: Bug 29518 Author: mmitchel Date: Mon Nov 13 17:49:43 2006 New Revision: 118768 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118768 Log: PR c++/29518 * pt.c (coerce_template_parms): Do not skip_evaluation while substituting template arguments. PR c++/29518 * g++.dg/template/static28.C: New test. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29518
[Bug c++/29518] [4.0/4.1/4.2/4.3 Regression] rejects valid template argument, enums vs templates
--- Comment #14 from mmitchel at gcc dot gnu dot org 2006-11-13 17:48 --- Subject: Bug 29518 Author: mmitchel Date: Mon Nov 13 17:48:28 2006 New Revision: 118767 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118767 Log: PR c++/29518 * pt.c (coerce_template_parms): Do not skip_evaluation while substituting template arguments. PR c++/29518 * g++.dg/template/static28.C: New test. Added: trunk/gcc/testsuite/g++.dg/template/static28.C Modified: trunk/gcc/cp/pt.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29518
[Bug fortran/29819] New: Error/warning message should ignore comments for "1" in %C output
If one compiles with -std=f95 the following program:
---
! { dg-do compile }
! { dg-options "-std=f2003" }
! Check whether empty contains are allowd
module x
contains
end module x ! { dg-error "CONTAINS statement must be followed by a FUNCTION or
SUBROUTINE statement" }
program y
contains
end program y ! { dg-error "CONTAINS statement must be followed by a FUNCTION
or SUBROUTINE statement" }
--
The location shown is not really helpful:
--
contains.f90:6:
nt" }
1
Error: Fortran 2008: CONTAINS statement must be followed by a FUNCTION or
SUBROUTINE statement at (1).
contains.f90:10:
nt" }
1
--
Expected:
- String is not trimmed that early (only 5 characters shown)
- 1 is not under a comment
Example for a better output:
end module x ! { dg-error "CONTAINS statement must
1
or as ifort (the "^" is below the "e" of "end module"):
end module x ! { dg-error "CONTAINS statement must be followed by a FUNCTION or
SUBROUTINE statement" }
^
--
Summary: Error/warning message should ignore comments for "1" in
%C output
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: enhancement
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29819
[Bug tree-optimization/29581] Latent bug in 4.1/4.2/4.3 lambda-code.c
--- Comment #4 from jakub at gcc dot gnu dot org 2006-11-13 16:56 --- Created an attachment (id=12607) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12607&action=view) gcc43-pr29581.patch Yeah, found that out too earlier today. This is the fix which I have regtested, including RUNTESTFLAGS=--target_board=unix/-ftree-loop-linear. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Attachment #12601|0 |1 is obsolete|| AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29581
[Bug c/29818] code with SSE segfaults with gcc-3.4.6, runs fine with gcc-4.1.1
--- Comment #1 from sergstesh at yahoo dot com 2006-11-13 16:40 --- Created an attachment (id=12606) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12606&action=view) source code which causes the segfault under gcc-3.4.6 and runs fine under gcc-4.1.1 The file is the result -save-temps command line option used during compilation. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29818
[Bug c/29818] New: code with SSE segfaults with gcc-3.4.6, runs fine with gcc-4.1.1
A (now pretty simple) piece of code segfaults when compiled with gcc-3.4.6, but runs fine with gcc-4.1.1. The offending line is: vtmp1.v = *(vFloat *)&inp_array_1[bn]; -please wait until upload the source file. Both gcc-3.4.6 and gcc-4.1.1 were built by myself; the same code segfaults when compiled using stock Mandrivaa gcc-3.3.6 and runs fine when compiled using stock Mandriva gcc-4.0.1, so, I guess, it doesn't really matter how I built gcc-3.4.6 and gcc-4.1.1. Anyway, gcc-3.4.6 and gcc-4.1.1 were built using my http://appsfromscratch.berlios.de/ tool, I can send the log files showing pretty standard, except for local installation dir, configuration options. When the code fails (i.e. compiled by gcc-3.4.6), the screen output is: " checkpoint 1 &inp_array_1[0]=80498e0 checkpoint 2 bn=1 &inp_array_1[1]=80498e4 checkpoint 3 Segmentation fault "; when the code runs fine (i.e. compiled by gcc-4.1.1), the screen output is: " checkpoint 1 &inp_array_1[0]=80498e0 checkpoint 2 bn=1 &inp_array_1[1]=80498e4 checkpoint 3 checkpoint 4 bn=5 &inp_array_1[5]=80498f4 checkpoint 3 checkpoint 4 bn=9 &inp_array_1[9]=8049904 checkpoint 3 checkpoint 4 inp_array_1[0]=1 inp_array_1[1]=2 inp_array_1[2]=3 inp_array_1[3]=4 inp_array_1[4]=5 inp_array_1[5]=6 inp_array_1[6]=7 inp_array_1[7]=8 inp_array_1[8]=9 inp_array_1[9]=10 inp_array_1[10]=11 inp_array_1[11]=12 inp_array_1[12]=13 inp_array_1[13]=14 inp_array_1[14]=15 inp_array_1[15]=16 inp_array_1[16]=17 inp_array_1[17]=18 inp_array_1[18]=19 inp_array_1[19]=20 inp_array_1[20]=21 inp_array_1[21]=22 inp_array_1[22]=23 inp_array_1[23]=24 inp_array_1[24]=25 inp_array_1[25]=26 inp_array_1[26]=27 inp_array_1[27]=28 inp_array_1[28]=29 inp_array_1[29]=30 inp_array_1[30]=31 inp_array_1[31]=32 ". The command line used for compilation: /AppsFromScratchWD/install/gcc-3.4.6/bin/gcc -save-temps -O2 -Wall -msse -mfpmath=sse -o sse_bug sse_bug.c . The command line used to run: ./sse_bug . -- Summary: code with SSE segfaults with gcc-3.4.6, runs fine with gcc-4.1.1 Product: gcc Version: 3.4.6 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sergstesh at yahoo dot com GCC build triplet: Linux comp.home.net 2.6.12-27mdk-i686-up-4GB #1 Tue Sep 26 12:41 GCC host triplet: Linux comp.home.net 2.6.12-27mdk-i686-up-4GB #1 Tue Sep 26 12:41 GCC target triplet: Linux comp.home.net 2.6.12-27mdk-i686-up-4GB #1 Tue Sep 26 12:41 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29818
[Bug target/29816] Faulty register allocation
--- Comment #7 from manuel dot serrano at inria dot fr 2006-11-13 16:33 --- The problem is solved. The error IS NOT IN GCC. I feel totally stupid and I present my most humbles excuses to everyone that has lost time because of my false bug report. The error (of course) was in my code. One more time, I sincerely apologize. -- manuel dot serrano at inria dot fr changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29816
[Bug debug/29792] DWARF: Not all inline concrete instances are being generated
--- Comment #8 from acme at mandriva dot com 2006-11-13 16:16 --- > > OK, I thought that this was due to something like what you described, even > > not > > knowing that much about gcc internals, but I thought that even in this case > > the > > DW_TAG_inlined_subroutine would be emitted, or hoped to as it would allow > > me to > > do what I want with my tools :-\ > > There is nothing to emit debug info about, so we don't. > Well, at least gcc emits this: <1>: Abbrev Number: 65 (DW_TAG_subprogram) DW_AT_sibling : DW_AT_name: (indirect string, offset: 0x4515): __task_rq_lock DW_AT_decl_file : 1 DW_AT_decl_line : 378 DW_AT_prototyped : 1 DW_AT_type: <9a2f> DW_AT_inline : 3 (declared as inline and inlined) But no DW_TAG_inlined_subroutine, as we've been discussing: [EMAIL PROTECTED] net-2.6.20]$ readelf -wi ../OUTPUT/qemu/net-2.6.20/kernel/sched.o | grep a2f2 DW_AT_sibling : <1>: Abbrev Number: 65 (DW_TAG_subprogram) [EMAIL PROTECTED] net-2.6.20]$ :-\ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29792
[Bug debug/29792] DWARF: Not all inline concrete instances are being generated
--- Comment #7 from dberlin at gcc dot gnu dot org 2006-11-13 16:00 --- Subject: Re: DWARF: Not all inline concrete instances are being generated On 12 Nov 2006 20:39:43 -, acme at mandriva dot com <[EMAIL PROTECTED]> wrote: > > > --- Comment #5 from acme at mandriva dot com 2006-11-12 20:39 --- > (In reply to comment #4) > > The only thing left from __task_rq_lock is a label. > > > > > task_cpu were inlined and we constant proped the value of rq the first of > > the > > way through the function which we inlined this to. > > OK, I thought that this was due to something like what you described, even not > knowing that much about gcc internals, but I thought that even in this case > the > DW_TAG_inlined_subroutine would be emitted, or hoped to as it would allow me > to > do what I want with my tools :-\ There is nothing to emit debug info about, so we don't. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29792
Re: [Bug debug/29792] DWARF: Not all inline concrete instances are being generated
On 12 Nov 2006 20:39:43 -, acme at mandriva dot com <[EMAIL PROTECTED]> wrote: --- Comment #5 from acme at mandriva dot com 2006-11-12 20:39 --- (In reply to comment #4) > The only thing left from __task_rq_lock is a label. > task_cpu were inlined and we constant proped the value of rq the first of the > way through the function which we inlined this to. OK, I thought that this was due to something like what you described, even not knowing that much about gcc internals, but I thought that even in this case the DW_TAG_inlined_subroutine would be emitted, or hoped to as it would allow me to do what I want with my tools :-\ There is nothing to emit debug info about, so we don't.
[Bug c++/29817] New: --enable-threads=posix not working under AIX
Hello, I configured gcc 4.1.1 under AIX 5.3 with the following: ../gcc-4.1.1/configure --enable-threads=posix --enable-tls --enable-gather-detailed-mem-stats --enable-languages=c,c++ when I do a "gcc -v" it says this: Thread model: aix I believe it should say "posix". I am compiling with a gcc-4.1.1 binary that someone else had built. The reason I am not using his binary is because I need a posix threading model. Am I doing something wrong? -- Summary: --enable-threads=posix not working under AIX Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: brandon at homeisp dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29817
[Bug target/29815] internal compiler error, if float-comparison is done with option -mfloat-gprs=yes
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-11-13 14:51 --- GCC 3.4.x is out of maintainance, can you try with at least 4.0.3 or 4.1.1? Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29815
[Bug tree-optimization/29439] [4.2 regression] ICE in fold-const.c:1385 with -O1 -fwrapv -ftree-vrp
--- Comment #19 from pinskia at gcc dot gnu dot org 2006-11-13 14:46 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29439
[Bug tree-optimization/29439] [4.2 regression] ICE in fold-const.c:1385 with -O1 -fwrapv -ftree-vrp
--- Comment #18 from pinskia at gcc dot gnu dot org 2006-11-13 14:46 --- Subject: Bug 29439 Author: pinskia Date: Mon Nov 13 14:46:05 2006 New Revision: 118763 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118763 Log: 2006-11-13 Andrew Pinski <[EMAIL PROTECTED]> PR tree-opt/29439 * tree-vrp.c (vrp_int_const_binop): Use the correct tree when checking for overflow. Modified: branches/gcc-4_2-branch/gcc/ChangeLog branches/gcc-4_2-branch/gcc/tree-vrp.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29439
[Bug middle-end/28915] [4.1 regression] ICE: tree check: expected class 'constant', have 'declaration' (var_decl) in build_vector, at tree.c:973
--- Comment #19 from pinskia at gcc dot gnu dot org 2006-11-13 14:41 --- Fixed in at least 4.2.0 and the trunk. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Known to work|4.0.0 |4.0.0 4.2.0 4.3.0 Summary|[4.1/4.2/4.3 regression]|[4.1 regression] ICE: tree |ICE: tree check: expected |check: expected class |class 'constant', have |'constant', have |'declaration' (var_decl) in |'declaration' (var_decl) in |build_vector, at tree.c:973 |build_vector, at tree.c:973 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28915
[Bug fortran/26994] [4.2 Regression] Scalar TRANSFER - error: invalid operand to unary operator
--- Comment #16 from pinskia at gcc dot gnu dot org 2006-11-13 14:38 --- Fixed on the mainline at least. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.2/4.3 Regression] Scalar |[4.2 Regression] Scalar |TRANSFER - error: invalid |TRANSFER - error: invalid |operand to unary operator |operand to unary operator http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26994
[Bug fortran/26994] [4.2/4.3 Regression] Scalar TRANSFER - error: invalid operand to unary operator
--- Comment #15 from pinskia at gcc dot gnu dot org 2006-11-13 14:36 --- Subject: Bug 26994 Author: pinskia Date: Mon Nov 13 14:36:09 2006 New Revision: 118761 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118761 Log: 2006-11-12 Andrew Pinski <[EMAIL PROTECTED]> PR fortran/26994 * gfortran.fortran-torture/compile/transfer-1.f90: New testcase. 2006-11-12 Andrew Pinski <[EMAIL PROTECTED]> PR fortran/26994 * trans-expr.c (gfc_conv_expr_reference): Set TREE_STATIC on the new CONST_DECL. Added: trunk/gcc/testsuite/gfortran.fortran-torture/compile/transfer-1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26994
[Bug target/29816] Faulty register allocation
--- Comment #6 from manuel dot serrano at inria dot fr 2006-11-13 14:12 --- Created an attachment (id=12605) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12605&action=view) The generated .i file that shows the problem -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29816
[Bug target/29816] Faulty register allocation
--- Comment #5 from manuel dot serrano at inria dot fr 2006-11-13 14:12 --- (In reply to comment #4) > Can you just attach the preprocessed source? which can be found via > -save-temps > and it is names "something".i. > The end of the bug report contains the source of the faulty function extracted from the .i source file. I presume that you want the entire .i file. I will attach it just after sending this reply. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29816
[Bug tree-optimization/29581] Latent bug in 4.1/4.2/4.3 lambda-code.c
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-11-13 14:09 --- > error: statement makes a memory store, but has no V_MAY_DEFS nor V_MUST_DEFS > perfecttmp.42 = perfectiv.40_5 + 16; > I called update_stmt, o not sure what I'm still missing. You forgot to mark perfecttmp.42 for renaming (or manually name it yourself). -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29581
[Bug target/29816] Faulty register allocation
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-11-13 14:05 --- Can you just attach the preprocessed source? which can be found via -save-temps and it is names "something".i. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29816
[Bug fortran/24828] Z and negative integers
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-11-13 13:59 --- *** Bug 29814 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||vahtras at pdc dot kth dot ||se http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24828
[Bug fortran/29814] integer assignment in hexadecimal fails
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-11-13 13:59 --- Gfortran is doing the correct thing for BOZs. This is a dup of bug 24828. *** This bug has been marked as a duplicate of 24828 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED GCC build triplet| powerpc-apple-darwin8.8.0 |powerpc-apple-darwin8.8.0 GCC host triplet| powerpc-apple-darwin8.8.0 |powerpc-apple-darwin8.8.0 GCC target triplet| powerpc-apple-darwin8.8.0 |powerpc-apple-darwin8.8.0 Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29814
[Bug target/29816] Faulty register allocation
--- Comment #3 from manuel dot serrano at inria dot fr 2006-11-13 13:55 --- Created an attachment (id=12604) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12604&action=view) second header file needed to compile the code given with the bug entry. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29816
[Bug target/29816] Faulty register allocation
--- Comment #2 from manuel dot serrano at inria dot fr 2006-11-13 13:55 --- Created an attachment (id=12603) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12603&action=view) One of the two needed .h file In order to compile the source code given with that bug, you need to header files: bigloo.h and bigloo_gc.h. These two are provided as attachements. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29816
[Bug tree-optimization/14784] [Tree-ssa] alias analysis deficiency
--- Comment #15 from pinskia at gcc dot gnu dot org 2006-11-13 13:54 --- Reopening since part of the patch was reverted. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | Target Milestone|4.3.0 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14784
[Bug tree-optimization/29680] [4.3 Regression] Misscompilation of spec2006 gcc
--- Comment #38 from pinskia at gcc dot gnu dot org 2006-11-13 13:54 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29680
[Bug target/29816] Faulty register allocation
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-11-13 13:47 --- Can you attach sources that actually compile because the sources you gave so far cannot compile as there is no typedef for obj_t. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29816
[Bug target/29816] Faulty register allocation
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|blocker |normal Component|c |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29816
[Bug target/29815] internal compiler error, if float-comparison is done with option -mfloat-gprs=yes
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|blocker |normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29815
[Bug c/29816] New: Faulty register allocation
Enabling optimization (starting with -O option) the following code is
erroneously compiled:
obj_t BGl_GLOPz00zz__evmeaningz00(obj_t BgL_codez00_1, obj_t BgL_stackz00_2) {
AN_OBJECT;
obj_t BgL_g1120z00_632;
obj_t BgL_vectorz00_1820;
int BgL_kz00_1821;
BgL_vectorz00_1820 = BgL_codez00_1;
BgL_kz00_1821 = (int) (((long) 3));
BgL_g1120z00_632 = VECTOR_REF(BgL_vectorz00_1820, BgL_kz00_1821);
{
obj_t BgL_valsz00_1823;
obj_t BgL_envz00_1824;
BgL_valsz00_1823 = BgL_g1120z00_632;
BgL_envz00_1824 = BgL_stackz00_2;
printf( "AVANT LOOP: %p code=%p\n", BgL_valsz00_1823, BgL_codez00_1);
dprint( BgL_valsz00_1823 );
dprint( BgL_codez00_1 );
BgL_loopz00_1822:
if( !((NULLP(BgL_valsz00_1823)) || (PAIRP( BgL_valsz00_1823 ) ) ) ) {
fprintf( stderr, "GOT ONE: %p code=%p\n", BgL_valsz00_1823,
BgL_codez00_1 );
dprint( BgL_valsz00_1823 );
dprint( BgL_codez00_1 );
exit( 12 );
}
if (NULLP(BgL_valsz00_1823)) {
obj_t BgL_arg1193z00_1832;
{
obj_t BgL_vectorz00_1838;
int BgL_kz00_1839;
BgL_vectorz00_1838 = BgL_codez00_1;
BgL_kz00_1839 = (int) (((long) 2));
BgL_arg1193z00_1832 =
VECTOR_REF(BgL_vectorz00_1838, BgL_kz00_1839);
}
return
BGl_evmeaningz00zz__evmeaningz00(BgL_arg1193z00_1832,
BgL_envz00_1824);
} else {
obj_t BgL_arg1194z00_1833;
obj_t BgL_arg1195z00_1834;
BgL_arg1194z00_1833 = CDR(BgL_valsz00_1823);
fprintf( stderr, "CDR=%p\n", BgL_arg1194z00_1833 );
{
obj_t BgL_arg1196z00_1835;
{
obj_t BgL_arg1197z00_1836;
BgL_arg1197z00_1836 = CAR(BgL_valsz00_1823);
BgL_arg1196z00_1835 =
BGl_evmeaningz00zz__evmeaningz00(BgL_arg1197z00_1836,
BgL_stackz00_2);
}
BgL_arg1195z00_1834 =
MAKE_PAIR(BgL_arg1196z00_1835, BgL_envz00_1824);
}
{
obj_t BgL_envz00_6066;
obj_t BgL_valsz00_6065;
fprintf( stderr, "CDR.2=%p\n", BgL_arg1194z00_1833 );
BgL_valsz00_6065 = BgL_arg1194z00_1833;
BgL_envz00_6066 = BgL_arg1195z00_1834;
BgL_envz00_1824 = BgL_envz00_6066;
BgL_valsz00_1823 = BgL_valsz00_6065;
goto BgL_loopz00_1822;
}
}
}
}
That is, the variable BgL_arg1194z00_1833 is not BgL_arg1194z00_1833 correctly
restored after the call to BGl_evmeaningz00zz__evmeaningz00. That is, the two
calls to printf show different value for that variable while it is not
changed.
Here is the definition of the fault function extracted from the .i file:
obj_t BGl_GLOPz00zz__evmeaningz00(obj_t BgL_codez00_1, obj_t BgL_stackz00_2) {
;
obj_t BgL_g1120z00_632;
obj_t BgL_vectorz00_1820;
int BgL_kz00_1821;
BgL_vectorz00_1820 = BgL_codez00_1;
BgL_kz00_1821 = (int) (((long) 3));
BgL_g1120z00_632 = (&(((obj_t)(BgL_vectorz00_1820))->vector_t.obj0))[
BgL_kz00_1821 ];
{
obj_t BgL_valsz00_1823;
obj_t BgL_envz00_1824;
BgL_valsz00_1823 = BgL_g1120z00_632;
BgL_envz00_1824 = BgL_stackz00_2;
printf( "AVANT LOOP: %p code=%p\n", BgL_valsz00_1823, BgL_codez00_1);
dprint( BgL_valsz00_1823 );
dprint( BgL_codez00_1 );
BgL_loopz00_1822:
if( !long)(BgL_valsz00_1823) ==
(long)((obj_t)(obj_t)((long)(((long)(0) << 2) | 2) ||
(long)BgL_valsz00_1823) & ((1 << 2) - 1)) == 3) ) ) ) {
fprintf( stderr, "GOT ONE: %p code=%p\n", BgL_valsz00_1823, BgL_codez00_1 );
dprint( BgL_valsz00_1823 );
dprint( BgL_codez00_1 );
exit( 12 );
}
if (((long)(BgL_valsz00_1823) == (long)((obj_t)(obj_t)((long)(((long)(0)
<< 2) | 2) {
obj_t BgL_arg1193z00_1832;
{
obj_t BgL_vectorz00_1838;
int BgL_kz00_1839;
BgL_vectorz00_1838 = BgL_codez00_1;
BgL_kz00_1839 = (int) (((long) 2));
BgL_arg1193z00_1832 =
(&(((obj_t)(BgL_vectorz00_1838))->vector_t.obj0))[ BgL_kz00_1839 ];
}
return
BGl_evmeaningz00zz__evmeaningz00(BgL_arg1193z00_1832,
BgL_envz00_1824);
} else {
obj_t BgL_arg1194z00_1833;
obj_t BgL_arg1195z00_1834;
BgL_arg1194z00_1833 = obj_t)((long)BgL_valsz00_1823 - 3))->pair_t).cdr);
fprintf( stderr, "CDR=%p\n", BgL_arg1194z00_1833 );
{
obj_t BgL_arg1196z00_1835;
{
obj_t BgL_arg1197z00_1836;
BgL_arg1197z00_1836 = obj_t)((long)BgL_valsz00_1823 - 3))->pair_t).car);
BgL_arg1196z00_1835 =
BGl_evmeaningz00zz__evmeaningz00(BgL_arg1197z00_1836,
BgL_stackz00_2);
}
BgL_arg1195z00_1834 =
make_pair( BgL_arg1196z00_1835, BgL_envz00_1824 );
}
{
obj
[Bug tree-optimization/14784] [Tree-ssa] alias analysis deficiency
--- Comment #14 from rakdver at gcc dot gnu dot org 2006-11-13 12:37 --- Subject: Bug 14784 Author: rakdver Date: Mon Nov 13 12:37:29 2006 New Revision: 118754 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118754 Log: PR tree-optimization/29680 * tree-ssa-operands.c (access_can_touch_variable): Revert fix for PR 14784. * gcc.dg/alias-11.c: New test. Added: trunk/gcc/testsuite/gcc.dg/alias-11.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-operands.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14784
[Bug tree-optimization/29680] [4.3 Regression] Misscompilation of spec2006 gcc
--- Comment #37 from rakdver at gcc dot gnu dot org 2006-11-13 12:37 --- Subject: Bug 29680 Author: rakdver Date: Mon Nov 13 12:37:29 2006 New Revision: 118754 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118754 Log: PR tree-optimization/29680 * tree-ssa-operands.c (access_can_touch_variable): Revert fix for PR 14784. * gcc.dg/alias-11.c: New test. Added: trunk/gcc/testsuite/gcc.dg/alias-11.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-operands.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29680
