[Bug fortran/27155] Transfer of character to integer array and vice versa still doesn't work
--- Comment #4 from bo dot berggren at glocalnet dot net 2006-05-13 06:41 --- Subject: Re: Transfer of character to integer array and vice versa still doesn't work paul dot richard dot thomas at cea dot fr skrev: > --- Comment #3 from paul dot richard dot thomas at cea dot fr 2006-05-12 > 14:50 --- > Created an attachment (id=11445) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11445&action=view) > --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11445&action=view) > Patch for bug (not regtested) > > The problem turned out to be less severe than I imagined. The attached patch > runs your program and the existing testcases correctly. I do not ever seem to > have tested the case of a character scalar with anything other than len=4. The > code is such that it only produces a value of 4 for any length of string - > blush, blush! > > I will endeavour to go through this with a fine toothcomb and, maybe, to fix > PR27449 before submitting. > > Once again, "takk" > > Paul > > > You're very welcome, but actually thanks in Swedish spells "tack". Due to this bug I'm currently stuck with using g95, but I'm looking forward to be able to move to gfortran instead. Thanks, Bo -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27155
[Bug target/27531] [4.2 regression] sparc: undefined reference to .LL226 with -O2
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-05-13 04:59 --- The label comes from a switch table. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27531
[Bug fortran/18315] missing error for incompatible array assignment involving lbound
--- Comment #6 from pault at gcc dot gnu dot org 2006-05-13 04:25 --- Fixed on trunk and 4.1 - see #5 Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18315
[Bug target/27531] [4.2 regression] sparc: undefined reference to .LL226 with -O2
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-05-13 04:08 --- I can confirm this, trying to figure out to reduce this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27531
[Bug fortran/27554] Strange assembler produced
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-05-13 03:52 --- Confirmed, -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-05-13 03:52:09 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27554
[Bug c++/27581] [4.0/4.1/4.2 regression] ICE using this-pointer in static member function
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.0.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27581
[Bug c++/27582] [4.0/4.1/4.2 regression] ICE with invalid template parameter
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.1.1 |4.0.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27582
[Bug c++/27582] [4.0/4.1/4.2 regression] ICE with invalid template parameter
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.1.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27582
[Bug c++/27582] New: [4.0/4.1/4.2 regression] ICE with invalid template parameter
The following invalid testcase triggers an ICE since GCC 3.4.0:
===
struct A
{
template void foo();
};
template > struct B {};
B b;
===
bug.cc:8: error: type/value mismatch at argument 1 in template parameter list
for 'template)()> struct B'
bug.cc:8: error: expected a constant of type 'int', got 'int'
bug.cc:8: internal compiler error: tree check: expected tree_vec, have
error_mark in any_dependent_template_arguments_p, at cp/pt.c:12751
Please submit a full bug report, [etc.]
Patch on the way.
--
Summary: [4.0/4.1/4.2 regression] ICE with invalid template
parameter
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, error-recovery, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27582
[Bug c++/27581] New: [4.0/4.1/4.2 regression] ICE using this-pointer in static member function
The following invalid testcase triggers an ICE since GCC 3.4.0:
===
struct A
{
template static void foo();
static void bar() { this->A::foo<0>(); }
};
===
bug.cc: In static member function 'static void A::bar()':
bug.cc:4: error: 'this' is unavailable for static member functions
bug.cc:4: internal compiler error: in adjust_result_of_qualified_name_lookup,
at cp/search.c:1488
Please submit a full bug report, [etc.]
Patch on the way.
--
Summary: [4.0/4.1/4.2 regression] ICE using this-pointer in
static member function
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, error-recovery, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27581
[Bug libstdc++/27579] no warning for the non-standard integral overloads of math functions
--- Comment #2 from gdr at integrable-solutions dot net 2006-05-12 21:47 --- Subject: Re: New: no warning for the non-standard integral overloads of math functions "marc dot glisse at normalesup dot org" <[EMAIL PROTECTED]> writes: | As a solution to "bug" 3181, integral overloads of many math functions (like | sqrt) were introduced. Would it be possible to add a warning when such | overloads are instantiated? I don't know how to do that with g++ (if it is not | possible, then it would be a nice feature to add). It would help people write | more portable code. this is a non-issue. PR should be closed. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27579
[Bug c++/27577] Change "control reaches end of non-void function" to an error, when a complex type gets returned
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-05-12 21:19 --- (In reply to comment #0) > Yes, I am fully aware, that my snipplet is buggy, however an ignored warning > should not cause a crash in the program. Code that invokes undefined behavior at runtime cannot be turned into an error as it might never be reached. An example is you never call foo which the code is valid semantically but is undefined. -- 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=27577
[Bug fortran/25104] Non-initialization expr. as case-selector
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2006-05-12 21:18 --- Well, the testcase is valid F2003 but not valid F95. We have to get it working (for F2003 mode), which probably means adding a simplification function for MAXLOC. And the same is true for all the intrinsics allowed by F2003 in an initialization expression. But we also have to get it rejected in F95 mode, which means keeping an explicit list of the intrinsics that are allowed in initialization expressions in F95, under the rules of 7.1.6.1 (all subcases a to e of case #7). I see two options here: either we add a property for all intrinsics, define it in the list and use that (lots of changes and thinking) or we add a new function valid_intrinsic_in_init_expr(). I'd prefer the second option, and will be thinking of something along these lines. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-01-27 20:55:34 |2006-05-12 21:18:24 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25104
[Bug c++/27577] Change "control reaches end of non-void function" to an error, when a complex type gets returned
--- Comment #2 from schwab at suse dot de 2006-05-12 21:13 --- > Yes, I am fully aware, that my snipplet is buggy, however an ignored warning > should not cause a crash in the program. There are many ways an ignored warning can cause a program to crash. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27577
[Bug c++/27578] [4.2 Regression] ICE with attribute on a pointer in a function prototype
--- Comment #6 from janis at gcc dot gnu dot org 2006-05-12 20:38 --- A regression hunt on powerpc-linux using the testcase from comment #5 identified this patch: http://gcc.gnu.org/viewcvs?view=rev&rev=113081 r113081 | mmitchel | 2006-04-19 16:58:23 + (Wed, 19 Apr 2006) -- janis at gcc dot gnu dot org changed: What|Removed |Added CC||mmitchel at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27578
[Bug libstdc++/27579] no warning for the non-standard integral overloads of math functions
--- Comment #1 from pcarlini at suse dot de 2006-05-12 20:12 ---
Really, there is no point in trying to implement that warning, given the
ongoing developments of the C++ standard: those overloads are already part of
the current draft of the next ("C++0x") standard (and are also in TR1).
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27579
[Bug c++/27572] [4.0/4.1/4.2 regression] ICE on typedef in parameter declaration
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-05-12 19:36:31 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27572
[Bug rtl-optimization/27538] [4.2 Regression] execute/20030128-1.c FAILs
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-05-12 19:36:18 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27538
[Bug libstdc++/3181] Unable to use sqrt,cos,sin,... with int argument.
--- Comment #18 from pinskia at gcc dot gnu dot org 2006-05-12 19:27 --- Hmm, don't we now violate the C++ standard by providing these overloads? (http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#213). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3181
[Bug c++/27578] [4.2 Regression] ICE with attribute on a pointer in a function prototype
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-05-12 19:13 --- Actually this is any attribute on the pointer in the function prototype: void readv (int *__attribute__((aligned(16) )) ); -- pinskia at gcc dot gnu dot org changed: What|Removed |Added GCC target triplet|powerpc-*-linux-gnu | Keywords||ice-on-valid-code Summary|ICE with altivec(vector__) |[4.2 Regression] ICE with |on a pointer in a function |attribute on a pointer in a |prototype |function prototype Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27578
[Bug c++/27578] ICE with altivec(vector__) on a pointer in a function prototype
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-05-12 19:08 --- (In reply to comment #3) Reduced testcase: void readv (int *__attribute__((altivec(vector__))) ); -- 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-05-12 19:08:15 date|| Summary|ICE during build of |ICE with altivec(vector__) |libstdc++-v3|on a pointer in a function ||prototype http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27578
[Bug libstdc++/27579] New: no warning for the non-standard integral overloads of math functions
As a solution to "bug" 3181, integral overloads of many math functions (like sqrt) were introduced. Would it be possible to add a warning when such overloads are instantiated? I don't know how to do that with g++ (if it is not possible, then it would be a nice feature to add). It would help people write more portable code. See also: http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#213 -- Summary: no warning for the non-standard integral overloads of math functions Product: gcc Version: 4.0.3 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: marc dot glisse at normalesup dot org GCC host triplet: i486-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27579
[Bug c++/27578] ICE during build of libstdc++-v3
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-05-12 18:59 --- extern ssize_t readv (int __fd, __const struct iovec *__attribute__((altivec(vector__))), int __count); That is invalid code. Hmm, I wonder if someone uses __vector somewhere. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Keywords|ice-on-valid-code |ice-on-invalid-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27578
[Bug c++/27578] ICE during build of libstdc++-v3
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-05-12 18:52 --- I can also reproduce this on a cross compiler to powerpc-linux-gnu. and it is a front-end issue. Reducing. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|middle-end |c++ GCC target triplet|powerpc-unknown-linux- |powerpc-unknown-linux-gnu |gnualtivec | Keywords||build http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27578
[Bug c++/27577] Change "control reaches end of non-void function" to an error, when a complex type gets returned
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-05-12 18:47 --- I cannot remember if the C++ standard allows this to be an error. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27577
[Bug c/27578] ICE during build of libstdc++-v3
--- Comment #1 from edmar at freescale dot com 2006-05-12 18:42 --- Created an attachment (id=11449) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11449&action=view) File generated with --save-temps This is the .ii file that causes ICE. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27578
[Bug c/27578] New: ICE during build of libstdc++-v3
This problem started somewhere between april 17, and april 20. Afftects 4.2 only. Here is the -v output of the compilation terminated with ICE: /local/gnu_toolchain/build_area/obj_gcc-trunk_7450/./gcc/xgcc -shared-libgcc -B/local/gnu_toolchain/build_area/obj_gcc-trunk_7450/./gcc -nostdinc++ -L/local/gnu_toolchain/build_area/obj_gcc-trunk_7450/powerpc-unknown-linux-gnualtivec/libstdc++-v3/src -L/local/gnu_toolchain/build_area/obj_gcc-trunk_7450/powerpc-unknown-linux-gnualtivec/libstdc++-v3/src/.libs -B/local/gnu_toolchain/install_area/gcc-trunk-20060511-7450/powerpc-unknown-linux-gnualtivec/bin/ -B/local/gnu_toolchain/install_area/gcc-trunk-20060511-7450/powerpc-unknown-linux-gnualtivec/lib/ -isystem /local/gnu_toolchain/install_area/gcc-trunk-20060511-7450/powerpc-unknown-linux-gnualtivec/include -isystem /local/gnu_toolchain/install_area/gcc-trunk-20060511-7450/powerpc-unknown-linux-gnualtivec/sys-include -I/local/gnu_toolchain/build_area/obj_gcc-trunk_7450/powerpc-unknown-linux-gnualtivec/libstdc++-v3/include/powerpc-unknown-linux-gnualtivec -I/local/gnu_toolchain/build_area/obj_gcc-trunk_7450/powerpc-unknown-linux-gnualtivec/libstdc++-v3/include -I/local/gnu_toolchain/build_area/gcc-trunk/libstdc++-v3/libsupc++ -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -g -O2 -D_GNU_SOURCE -c basic_file.cc -fPIC -DPIC -o .libs/basic_file.o -v --save-temps Reading specs from /local/gnu_toolchain/build_area/obj_gcc-trunk_7450/./gcc/specs Target: powerpc-unknown-linux-gnualtivec Configured with: ../gcc-trunk/configure --prefix=/local/gnu_toolchain/install_area/gcc-trunk-20060511-7450 --with-local-prefix=/local/gnu_toolchain/install_area/gcc-trunk-20060511-7450 --enable-languages=c,c++ --enable-threads --target=powerpc-unknown-linux-gnualtivec --disable-linux-futex Thread model: posix gcc version 4.2.0 20060511 (experimental) /local/gnu_toolchain/build_area/obj_gcc-trunk_7450/./gcc/cc1plus -E -quiet -nostdinc++ -v -I/local/gnu_toolchain/build_area/obj_gcc-trunk_7450/powerpc-unknown-linux-gnualtivec/libstdc++-v3/include/powerpc-unknown-linux-gnualtivec -I/local/gnu_toolchain/build_area/obj_gcc-trunk_7450/powerpc-unknown-linux-gnualtivec/libstdc++-v3/include -I/local/gnu_toolchain/build_area/gcc-trunk/libstdc++-v3/libsupc++ -iprefix /temp/gnu_toolchain/build_area/obj_gcc-trunk_7450/gcc/../lib/gcc/powerpc-unknown-linux-gnualtivec/4.2.0/ -isystem /local/gnu_toolchain/build_area/obj_gcc-trunk_7450/./gcc/include -D_GNU_SOURCE -D__unix__ -D__gnu_linux__ -D__linux__ -Dunix -D__unix -Dlinux -D__linux -Asystem=linux -Asystem=unix -Asystem=posix -D_GNU_SOURCE -DPIC -isystem /local/gnu_toolchain/install_area/gcc-trunk-20060511-7450/powerpc-unknown-linux-gnualtivec/include -isystem /local/gnu_toolchain/install_area/gcc-trunk-20060511-7450/powerpc-unknown-linux-gnualtivec/sys-include basic_file.cc -Wall -Wextra -Wwrite-strings -Wcast-qual -fno-implicit-templates -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -fPIC -fworking-directory -O2 -fpch-preprocess -o basic_file.ii ignoring nonexistent directory "/local/gnu_toolchain/install_area/gcc-trunk-20060511-7450/powerpc-unknown-linux-gnualtivec/include" ignoring nonexistent directory "/temp/gnu_toolchain/build_area/obj_gcc-trunk_7450/gcc/../lib/gcc/powerpc-unknown-linux-gnualtivec/4.2.0/include" ignoring nonexistent directory "/temp/gnu_toolchain/build_area/obj_gcc-trunk_7450/gcc/../lib/gcc/powerpc-unknown-linux-gnualtivec/4.2.0/../../../../powerpc-unknown-linux-gnualtivec/sys-include" ignoring nonexistent directory "/temp/gnu_toolchain/build_area/obj_gcc-trunk_7450/gcc/../lib/gcc/powerpc-unknown-linux-gnualtivec/4.2.0/../../../../powerpc-unknown-linux-gnualtivec/include" ignoring duplicate directory "/local/gnu_toolchain/install_area/gcc-trunk-20060511-7450/lib/gcc/powerpc-unknown-linux-gnualtivec/4.2.0/../../../../powerpc-unknown-linux-gnualtivec/sys-include" ignoring nonexistent directory "/local/gnu_toolchain/install_area/gcc-trunk-20060511-7450/lib/gcc/powerpc-unknown-linux-gnualtivec/4.2.0/../../../../powerpc-unknown-linux-gnualtivec/include" #include "..." search starts here: #include <...> search starts here: /local/gnu_toolchain/build_area/obj_gcc-trunk_7450/powerpc-unknown-linux-gnualtivec/libstdc++-v3/include/powerpc-unknown-linux-gnualtivec /local/gnu_toolchain/build_area/obj_gcc-trunk_7450/powerpc-unknown-linux-gnualtivec/libstdc++-v3/include /local/gnu_toolchain/build_area/gcc-trunk/libstdc++-v3/libsupc++ /local/gnu_toolchain/build_area/obj_gcc-trunk_7450/./gcc/include /local/gnu_toolchain/install_area/gcc-trunk-20060511-7450/powerpc-unknown-linux-gnualtivec/sys-include /local/gnu_toolchain/install_area/gcc-trunk-20060511-7450/lib/gcc/powerpc-unknown-linux-gnualtivec/4.2.0/include End of search list. /local/gnu_toolchain/build_area/obj_gcc-trunk_7450/./gcc/cc1plus -fpreprocessed basic_file.ii -quiet -dumpbase basic_file.cc -auxbase-strip .libs/basic_fil
[Bug c++/27577] New: Change "control reaches end of non-void function" to an error, when a complex type gets returned
At least on x86 and x86_64 the following program crashes
8<--
#include
std::string foo()
{
}
int main()
{
foo();
}
8<--
When one compiles this snipplet with warnings turned on, then this warning
shows up:g++ -Wall m.c
m.c: In function `std::string foo()':
m.c:5: warning: control reaches end of non-void function
Although, a missing return type for a primitive type like int, float, ... is
sure not worth an error, not returning a complex type like std::string which
crashes the program should be treated as an error.
Yes, I am fully aware, that my snipplet is buggy, however an ignored warning
should not cause a crash in the program.
--
Summary: Change "control reaches end of non-void function" to an
error, when a complex type gets returned
Product: gcc
Version: 3.4.4
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: wfor at arcor dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27577
[Bug fortran/18026] boz initialization of REALs fails
--- Comment #6 from kargl at gcc dot gnu dot org 2006-05-12 17:43 --- (In reply to comment #5) > Created an attachment (id=11443) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11443&action=view) [edit] > A simple program showing that initialization of BOZ constants > fails in modules. > Please read Comment #3. Your code is invalid for several reasons. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18026
[Bug tree-optimization/27548] [4.2 regression] ICE: SSA corruption - Conflict across an abnormal edge
--- Comment #6 from patchapp at dberlin dot org 2006-05-12 17:36 --- Subject: Bug number PR 27548 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-05/msg00511.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27548
[Bug other/27576] New: The .eh_frame section in crtend.o has wrong aligment
In gcc/unwind-dw2-fde.h
/* The first few fields of a CIE. The CIE_id field is 0 for a CIE,
to distinguish it from a valid FDE. FDEs are aligned to an addressing
unit boundary, but the fields within are unaligned. */
struct dwarf_cie
{
uword length;
sword CIE_id;
ubyte version;
unsigned char augmentation[];
} __attribute__ ((packed, aligned (__alignof__ (void *;
/* The first few fields of an FDE. */
struct dwarf_fde
{
uword length;
sword CIE_delta;
unsigned char pc_begin[];
} __attribute__ ((packed, aligned (__alignof__ (void *;
It indicates that CIE/FDE should be aligned at the pointer size. But crtstuff.c
has:
STATIC EH_FRAME_SECTION_CONST char __EH_FRAME_BEGIN__[]
__attribute__((section(EH_FRAME_SECTION_NAME), aligned(4)))
= { };
STATIC EH_FRAME_SECTION_CONST int32 __FRAME_END__[]
__attribute__ ((unused, section(EH_FRAME_SECTION_NAME),
aligned(sizeof(int32
= { 0 };
This leads to the corrupted .eh_frame section on x86-64:
http://sources.redhat.com/bugzilla/show_bug.cgi?id=2655
--
Summary: The .eh_frame section in crtend.o has wrong aligment
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl at lucon dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27576
[Bug debug/27574] [4.1/4.2 Regression] MIssing debug info at -O0 for a C++ constructor
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-05-12 17:11 --- Confirmed. -- 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-debug Known to fail||4.1.0 4.2.0 Last reconfirmed|-00-00 00:00:00 |2006-05-12 17:11:45 date|| Summary|MIssing debug info at -O0 |[4.1/4.2 Regression] MIssing |for a constructor |debug info at -O0 for a C++ ||constructor Target Milestone|--- |4.1.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27574
[Bug rtl-optimization/27538] [4.2 Regression] execute/20030128-1.c FAILs
--- Comment #6 from kazu at gcc dot gnu dot org 2006-05-12 17:05 --- Note that the same bug is causing FAIL: gcc.c-torture/execute/941014-2.c execution, -O1 FAIL: gcc.c-torture/execute/941014-2.c execution, -O2 FAIL: gcc.c-torture/execute/941014-2.c execution, -Os -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27538
[Bug rtl-optimization/27538] [4.2 Regression] execute/20030128-1.c FAILs
--- Comment #5 from kazu at gcc dot gnu dot org 2006-05-12 17:04 --- *** Bug 27539 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27538
[Bug target/27539] gcc.c-torture/execute/941014-2.c FAILs
--- Comment #1 from kazu at gcc dot gnu dot org 2006-05-12 17:04 --- The exact same problem as PR rtl-optmization/27538 is happening. *** This bug has been marked as a duplicate of 27538 *** -- kazu at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27539
[Bug debug/27574] MIssing debug info at -O0
--- Comment #2 from amylaar at gcc dot gnu dot org 2006-05-12 17:02 --- Created an attachment (id=11448) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11448&action=view) With the translation result for this file, the testcase can be linked This file provides a definition of main and f so that when this file and the test case are translated to an object file, they can be linked together so that you can observe gdb showing - or rather not showing - the variable named "problem". -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27574
[Bug debug/27574] MIssing debug info at -O0
--- Comment #1 from amylaar at gcc dot gnu dot org 2006-05-12 16:58 --- Created an attachment (id=11447) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11447&action=view) test case Compiled for either sh-elf or i686-pc-linux-gnu, currrent mainline cc1plus does not generate any debug information for the variable 'problem'. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27574
[Bug libfortran/27575] New: gfortran - does not generate error when trying to read too much data
This program writes one word and then reads two words. g77 finds the error but gfortran does not - [dranta:~/tests/gfortran-D] dir% gfortran -o read01 read01.f [dranta:~/tests/gfortran-D] dir% read01 [dranta:~/tests/gfortran-D] dir% cat read01.f program test integer i1,i2 open(unit=11,form='unformatted') write(11)i1 close(11,status='keep') open(unit=11,form='unformatted') rewind 11 read(11)i1,i2 close(11,status='delete') stop end[dranta:~/tests/gfortran-D] dir% gfortran --v Using built-in specs. Target: powerpc-apple-darwin8.6.0 Configured with: ../gcc/configure --prefix=/Users/dir/gfortran --enable-languages=c,f95 Thread model: posix gcc version 4.2.0 20060511 (experimental) [dranta:~/tests/gfortran-D] dir% g77 -o read01 read01.f [dranta:~/tests/gfortran-D] dir% read01 do_us: off end of record apparent state: unit 11 named fort.11 lately reading sequential unformatted external IO Abort [dranta:~/tests/gfortran-D] dir% -- Summary: gfortran - does not generate error when trying to read too much data Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dir at lanl dot gov GCC target triplet: powerpc-apple-darwin8.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27575
[Bug debug/27574] New: MIssing debug info at -O0
Compilation with -O0 -g no longer creates debug information for all variables. -- Summary: MIssing debug info at -O0 Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: amylaar at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27574
[Bug c++/27527] invalid types produced out of argument deduction (SFINAE bug)
--- Comment #3 from sebor at roguewave dot com 2006-05-12 16:30 --- Created an attachment (id=11446) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11446&action=view) Corrected test program exercising SFINAE. After modifying the test program from comment #1 to correct these problems most test cases still fail (with both gcc and EDG eccp). The modified test program is in the attachment. Here's a script I used to run the test program: $ (c=1; \ while [ $c -lt 17 ]; do \ printf "%s: " "$c"; \ gcc -DCASE=$c t.cpp 2>/dev/null; \ if [ $? -eq 0 ]; then echo okay; else echo ERROR; fi; \ c=`expr $c + 1`; \ done) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27527
[Bug c++/27527] invalid types produced out of argument deduction (SFINAE bug)
--- Comment #2 from sebor at roguewave dot com 2006-05-12 16:27 --- EDG points out to me that both the original test case and the one from comment #1 are ambiguous because only the declaration of the signature of the function (and thus only the declaration of its return type and its arguments) is required the be well-formed and not the definition. Since the declaration of both A and B is well-formed in all cases the call is ambiguous. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27527
[Bug fortran/21130] 38822 lines of Fortran 90 takes more than 10 minutes to compile on a dual 3GHz P4 Linux box with lots of RAM
--- Comment #15 from bdavis at gcc dot gnu dot org 2006-05-12 16:05 --- looks like there is agreement that the problem is fixed. -- bdavis at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21130
[Bug target/27571] [4.2 regression] alpha: ICE in get_attr_usegp, at config/alpha/alpha.md:171
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27571
[Bug target/27556] Wrong code generation when cross compile for attiny2313
--- Comment #10 from eweddington at cso dot atmel dot com 2006-05-12 15:10 --- Subject: Re: Wrong code generation when cross compile for attiny2313 p dot mateja at sh dot cvut dot cz wrote: > In other words: Is there any way how to say to gcc that const arrays shoud > stay > just in flash and they are not needed in SRAM? This has been discussed before in many places. That's what the progmem attribute is for: to put data in to the flash. const means essentially "read-only" but it should not be overloaded to mean "put the data in flash". -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27556
[Bug c++/27568] [4.0/4.1/4.2 Regression] ICE in check_classfn, at cp/decl2.c:607
--- Comment #2 from reichelt at gcc dot gnu dot org 2006-05-12 14:53
---
Here's a shorter testcase:
==
template class> struct A;
template struct B
{
template void foo(T);
};
template<> template class T> void B<0>::foo(A) {}
==
If I turn the template-template parameters into regular template parameters
the code is (IMHO wrongly) accepted:
==
template struct A;
template struct B
{
template void foo(T);
};
template<> template void B<0>::foo(A) {}
==
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
CC||reichelt at gcc dot gnu dot
||org
Keywords||accepts-invalid, ice-on-
||invalid-code, monitored
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27568
[Bug fortran/27155] Transfer of character to integer array and vice versa still doesn't work
--- Comment #3 from paul dot richard dot thomas at cea dot fr 2006-05-12 14:50 --- Created an attachment (id=11445) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11445&action=view) Patch for bug (not regtested) The problem turned out to be less severe than I imagined. The attached patch runs your program and the existing testcases correctly. I do not ever seem to have tested the case of a character scalar with anything other than len=4. The code is such that it only produces a value of 4 for any length of string - blush, blush! I will endeavour to go through this with a fine toothcomb and, maybe, to fix PR27449 before submitting. Once again, "takk" Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27155
[Bug tree-optimization/27548] [4.2 regression] ICE: SSA corruption - Conflict across an abnormal edge
--- Comment #5 from rakdver at gcc dot gnu dot org 2006-05-12 14:46 --- Can also be reproduced on i686. Patch: http://gcc.gnu.org/ml/gcc-patches/2006-05/msg00511.html -- rakdver at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2006- ||05/msg00511.html Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27548
[Bug gcov/profile/27573] New: ICE with -fopenmp -fprofile-generate
gfortran-4.2-HEAD -fopenmp -fprofile-generate -c /src/gfc-4.2/libgomp/testsuite/libgomp.fortran/omp_parse1.f90 omp_parse1.f90:3: internal compiler error: in expand_omp_parallel, at omp-low.c:2396 smallish testcase: program test_omp implicit none integer i,j,k,omp_get_num_threads,omp_get_thread_num !$omp parallel write(6,"(2(a,i3))") " OpenMP: N_threads = ", omp_get_num_threads(), & " thread = ", omp_get_thread_num() do i=1,j-1 ! k=i+1 !2 continue enddo !$omp end parallel end -- Summary: ICE with -fopenmp -fprofile-generate Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: ice-on-valid-code, openmp Severity: normal Priority: P3 Component: gcov/profile AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: aldot at gcc dot gnu dot org GCC build triplet: i686-linux-gnu GCC host triplet: i686-linux-gnu GCC target triplet: i686-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27573
[Bug tree-optimization/18219] [4.0/4.1/4.2 Regression] bloats code by 31%
--- Comment #21 from rguenth at gcc dot gnu dot org 2006-05-12 14:00 --- This looks related to PR26726 as IVOPTs produces now : i = minLen + 1; D.1588 = (int *) (unsigned int) (i * 4); ivtmp.34 = limit + D.1588 - 4B; ivtmp.40 = base + D.1588; goto (); :; D.1595 = (int *) ivtmp.40; MEM[base: D.1595, offset: -4B] = (MEM[base: (int *) ivtmp.34, offset: -4B] + 1 << 1) - MEM[base: D.1595, offset: -4B]; i = i + 1; :; ivtmp.34 = ivtmp.34 + 4B; ivtmp.40 = ivtmp.40 + 4B; if (i <= maxLen) goto ; else goto ; with the seemingly innocuous offset: -4B canonicalization because of the weird i386 backend cost model. Now if fixing that would fix the size issue is another thing. Not replacing the exit test or using i as solely IV is another thing - but it doesn't even consider i as IV candidate. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||26726 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18219
[Bug fortran/19015] shape / rank mismatch in maxloc / minloc could be caught at compile time
--- Comment #5 from paul dot richard dot thomas at cea dot fr 2006-05-12 13:45 --- Created an attachment (id=11444) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11444&action=view) Corrected version of patch This version of the patch survives regtesting! -- paul dot richard dot thomas at cea dot fr changed: What|Removed |Added Attachment #11442|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19015
[Bug tree-optimization/17506] [4.0/4.1/4.2 regression] warning about uninitialized variable points to wrong location
--- Comment #23 from rguenth at gcc dot gnu dot org 2006-05-12 13:42
---
The patch from comment #14 is not really useful as it f.i. warns for
int sink;
void bar()
{
int j;
sink = j;
}
t.c: In function 'bar':
t.c:5: warning: 'j' is used uninitialized in this function
t.c:4: note: 'j' was declared here
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17506
[Bug c++/16625] Discarded Linkonce sections in .rodata
--- Comment #30 from karol at mikronika dot com dot pl 2006-05-12 13:40 --- Strange... I don't know why 3.3.x will not be updated. Currently line 3.3.x is used in many stable/production environments like stable: Debian (sarge), Slackware 10, Suse 10. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16625
[Bug fortran/18026] boz initialization of REALs fails
--- Comment #5 from guilloteau at obs dot u-bordeaux1 dot fr 2006-05-12 13:05 --- Created an attachment (id=11443) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11443&action=view) A simple program showing that initialization of BOZ constants fails in modules. The test program shows initialization of BOZ constant failing when in a MODULE. The initialization would work if the module code was put in a simple INCLUDE file in Fortran-77 style. GNU Fortran 95 (GCC) 4.2.0 20060420 (experimental) on Cygwin (April 2006 update) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18026
[Bug fortran/19015] shape / rank mismatch in maxloc / minloc could be caught at compile time
--- Comment #4 from paul dot richard dot thomas at cea dot fr 2006-05-12 11:42 --- Created an attachment (id=11442) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11442&action=view) Patch to effect compile time checking Thomas, The attached patch corrects the problem and is presently regtesting. Of course, it can only deal with constant values of dim so the runtime checking should remain in place. Gruesse Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19015
[Bug fortran/27446] ICE on OpenMP array REDUCTION clause
--- Comment #4 from jakub at gcc dot gnu dot org 2006-05-12 11:27 --- -fbounds-check is completely useless option, it is so buggy that you can't use it for anything real. E.g. it doesn't handle assumed size or allocatable arrays. Try running make check-gfortran RUNTESTFLAGS="--target_board unix/-fbounds-check" and you'll see a half of the tests fail. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27446
[Bug c++/27572] [4.0/4.1/4.2 regression] ICE on typedef in parameter declaration
--- Comment #1 from patchapp at dberlin dot org 2006-05-12 09:47 --- Subject: Bug number PR c++/27572 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-05/msg00502.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27572
[Bug c++/27572] [4.0/4.1/4.2 regression] ICE on typedef in parameter declaration
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |reichelt at gcc dot gnu dot |dot org |org URL||http://gcc.gnu.org/ml/gcc- ||patches/2006- ||05/msg00502.html Target Milestone|--- |4.0.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27572
[Bug c++/27572] New: [4.0/4.1/4.2 regression] ICE on typedef in parameter declaration
The C++ frontend currently chokes on invalid typedefs in parameter
declarations for both functions and templates.
One can generate ICEs in many different places like the following
examples show:
==
void foo(typedef) {}
==
bug.cc:1: error: ISO C++ forbids declaration of 'parameter' with no type
bug.cc:1: error: typedef declaration invalid in parameter declaration
bug.cc: In function 'void foo(int)':
bug.cc:1: internal compiler error: tree check: expected tree that contains
'decl with RTL' structure, have 'type_decl' in set_decl_rtl, at emit-rtl.c:949
Please submit a full bug report, [etc.]
==
void foo(typedef x[]) {}
==
ICE in pop_binding, at cp/name-lookup.c:380
==
template void foo();
void bar()
{
foo();
}
==
ICE in instantiate_decl, at cp/pt.c:11703
==
template struct A;
==
tree check ICE: expected template_type_parm or template_template_parm or
bound_template_template_parm, have integer_type in process_template_parm, at
cp/pt.c:2336
==
template struct A
{
void foo();
void bar();
};
A a;
==
ICE in finish_member_declaration, at cp/semantics.c:2212
==
template struct A
{
friend void foo();
};
A a;
==
ICE in tsubst_decl, at cp/pt.c:6263
Some of these examples crash since GCC 2.95.3, but some (like the first
and last) since 3.4.0, so this is a regression.
Patch to follow.
--
Summary: [4.0/4.1/4.2 regression] ICE on typedef in parameter
declaration
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, error-recovery, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27572
[Bug fortran/24168] Problems with SPREAD and/or scalarization
--- Comment #1 from paul dot richard dot thomas at cea dot fr 2006-05-12 09:23 --- I find this to be "surprising": $ cat pr24168.f90;rm a.exe;/irun/bin/gfortran -fdump-tree-original pr24168.f90; ./a program bug implicit none integer, parameter :: nx=2,ny=2 real, dimension(nx,ny) :: f real, dimension(nx) :: x integer, dimension(nx) :: p integer :: i x = real ((/ (i, i = 1, nx) /)) print '(A,2F4.1)', "x = ", x print '(A,2F4.1)', "cshift( x, nx/2) * 2 = ",cshift( x, nx/2) * 2 print '(A,4F4.1)', "spread(cshift( x, nx/2) * 2, 2, ny) = ", spread(cshift( x, nx/2) * 2, 2, ny) end program bug x = 1.0 2.0 cshift( x, nx/2) * 2 = 4.0 2.0 spread(cshift( x, nx/2) * 2, 2, ny) = 4.0 4.0 4.0 4.0 Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24168
[Bug libstdc++/27569] Problem with mixing wcout and cout
--- Comment #1 from pcarlini at suse dot de 2006-05-12 08:51 --- This is a (new) feature, not a bug, see libstdc++/11705 and in general search about stream orientation in the C standard (C99, 7.19.2). In a nutshell you cannot mix byte oriented and wide oriented I/O. For now, due to the *bug* pointed out in libstdc++/11705, you can obtain something close to your expectations by calling std::ios::sync_with_stdio(false); at the beginning of your program. -- pcarlini at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27569
[Bug target/27571] [4.2 regression] alpha: ICE in get_attr_usegp, at config/alpha/alpha.md:171
--- Comment #1 from tbm at cyrius dot com 2006-05-12 08:47 --- Created an attachment (id=11441) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11441&action=view) test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27571
[Bug target/27571] New: [4.2 regression] alpha: ICE in get_attr_usegp, at config/alpha/alpha.md:171
ICE in get_attr_usegp, at config/alpha/alpha.md:171 using gcc 4.2.0 20060508: [EMAIL PROTECTED]:~$ /usr/lib/gcc-snapshot/bin/gcc -c -O1 mini.c mini.c: In function 'r7to_double': mini.c:36: error: unrecognizable insn: (jump_insn 50 49 51 (addr_diff_vec:SI (label_ref:DI 49) [ (label_ref:DI 52) (label_ref:DI 62) (label_ref:DI 70) (label_ref:DI 171) (label_ref:DI 171) (label_ref:DI 70) (label_ref:DI 70) ] (const_int 0 [0x0]) (const_int 0 [0x0])) -1 (nil) (nil)) mini.c:36: internal compiler error: in get_attr_usegp, at config/alpha/alpha.md:171 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. [EMAIL PROTECTED]:~$ /usr/lib/gcc-snapshot/bin/gcc -c mini.c [EMAIL PROTECTED]:~$ gcc-4.1 -c -O2 mini.c [EMAIL PROTECTED]:~$ -- Summary: [4.2 regression] alpha: ICE in get_attr_usegp, at config/alpha/alpha.md:171 Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tbm at cyrius dot com GCC build triplet: alpha-linux-gnu GCC host triplet: alpha-linux-gnu GCC target triplet: alpha-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27571
[Bug libstdc++/27569] New: Problem with mixing wcout and cout
#include
int main()
{
//std::cout << "Hello!" << std::endl;
std::wcout << L"Wello!" << std::endl;
std::cout << "Hello!" << std::endl;
return 0;
}
//
$ g++ test.cpp
$ ./a.out
Wello!
There is no output from std::cout, but if first line is uncommented:
$ g++ test.cpp
$ ./a.out
Hello!
Wello!
Hello!
It seems to work well with GCC versions 3.3 and 3.2 and fails with +3.4.
I've checked it on Debian Testing and Fedora Core 3 (standard distribution
compilers). It works fine on Solaris 8 GCC 3.4.
--
Summary: Problem with mixing wcout and cout
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kuba at parasoft dot com dot pl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27569
[Bug rtl-optimization/27567] [4.0/4.1/4.2 Regression] __builtin_memcpy generates redundant stores/moves.
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-05-12 08:27 --- f is marked addressable and assigned a stack slot. That the stores are not optimized away later is probably due to aliasing issues - an open-coded memcpy must behave like the -fno-strict-aliasing case, so I guess we applied measures to assure this and this prevents this optimization. 3.3 and 3.3-hammer can do the optimization. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org, hubicka at gcc dot gnu ||dot org Status|UNCONFIRMED |NEW Component|other |rtl-optimization Ever Confirmed|0 |1 Keywords||missed-optimization Known to fail||3.4.6 4.0.3 4.1.0 4.2.0 Known to work||3.3.6 Last reconfirmed|-00-00 00:00:00 |2006-05-12 08:27:14 date|| Summary|__builtin_memcpy generates |[4.0/4.1/4.2 Regression] |redundant stores/moves. |__builtin_memcpy generates ||redundant stores/moves. Target Milestone|--- |4.0.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27567
