[Bug tree-optimization/20514] hoisting of label out of jumptable would take place at cse, should happen at trees
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-09-17 07:59 ---
(In reply to comment #2)
> Two things, we just don't jump thread.
The testcase mentioned in comment #2 is fixed but we still don't make an
infinite loop for the orginal case:
:;
switch (i_lsm.25)
{
case 0 ... 1: goto ;
case 2 ... 3: goto ;
case 5: goto ;
default : goto ;
}
:;
i_lsm.25 = 4;
goto ();
...
Which is obvious an infinite loop but we still go through the switch every
time.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Last reconfirmed|2006-01-21 03:00:56 |2006-09-17 07:59:49
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20514
[Bug tree-optimization/26400] Missed jump threading on the tree level
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Last reconfirmed|2006-02-22 09:55:47 |2006-09-17 08:23:30 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26400
[Bug tree-optimization/15558] [tree-ssa] A missed forward propagation opportunity involving floats
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-09-17 08:25 ---
I was thinking about this one recently, I might implement this because we could
do it also for:
int f(_Bool a)
{
if (!a)
return 1000;
return 1001;
}
Where we really only need to swap the two arms and such.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15558
[Bug tree-optimization/15347] [tree-ssa] fold if ("<12ers" + 1 == 0).
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-09-17 08:44 ---
Just to clarify what testcase is still broken, here it is:
void baz (void)
{
if ("<12ers" + 1 == 0)
bar ();
}
--
The reason why strchr testcase is fixed is because we turn the strchr call into
&"<12ers"[1].
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
||org
Last reconfirmed|2006-03-01 02:45:29 |2006-09-17 08:44:52
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15347
[Bug c/28568] compiler generates incorrect ARM instructions when using long bitfields
--- Comment #7 from jason dot morgan at vpnsolutions dot uk dot com 2006-09-17 08:47 --- Subject: RE: compiler generates incorrect ARM instructions when using long bitfields Why not? What are the criteria? It is obviously wrong and would be so simple to fix, even optionally with a runtime option. -Original Message- From: rearnsha at arm dot com [mailto:[EMAIL PROTECTED] Sent: 11 September 2006 13:15 To: [EMAIL PROTECTED] Subject: [Bug c/28568] compiler generates incorrect ARM instructions when using long bitfields --- Comment #6 from rearnsha at arm dot com 2006-09-11 12:14 --- Subject: Re: compiler generates incorrect ARM instructions when using long bitfields On Wed, 2006-08-02 at 13:56, jason dot morgan at vpnsolutions dot uk dot com wrote: > Where do I obtain EABI and what effect will it have on my toolchain? http://www.arm.com/products/DevTools/ABI.html > Is there any plan or project to merge the resolution to PR23623 back into gcc > 4.1.1 No, this doesn't fit the critera for a regression, so it won't be fixed in FSF releases. However, I think the CodeSourcery distributions have this feature in a 4.1 build. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28568 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. You reported the bug, or are watching the reporter. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28568
[Bug target/28568] compiler generates incorrect ARM instructions when using long bitfields
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-09-17 08:51 --- (In reply to comment #7) > Subject: RE: compiler generates incorrect ARM instructions when using long > bitfields > > Why not? What are the criteria? It is obviously wrong and would be so > simple to fix, even optionally with a > runtime option. It just is not a regression since it has been wrong since the begining of time for GCC. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|major |normal Component|c |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28568
[Bug c++/29105] [4.2 Regression] segfault in add_candidates
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-09-17 09:08 ---
Reduced testcase:
struct Observer
{
template < typename T > void observeComponent ();
};
template < typename T >
struct TagFilter : Observer
{
TagFilter ()
{
observeComponent < int > ();
}
};
--
This also can ICE on invalid code if we change struct to class for Observer
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Keywords||ice-on-invalid-code
Last reconfirmed|-00-00 00:00:00 |2006-09-17 09:08:30
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29105
[Bug tree-optimization/21591] not vectorizing a loop with access to structs
--- Comment #8 from irar at gcc dot gnu dot org 2006-09-17 09:18 --- Subject: Bug 21591 Author: irar Date: Sun Sep 17 09:17:51 2006 New Revision: 117003 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117003 Log: PR tree-opt/21591 * tree-data-ref.c (ptr_decl_may_alias_p): Look for the name memory tag first. (ptr_ptr_may_alias_p): Likewise. (record_record_differ_p): New function. (base_object_differ_p): Call record_record_differ_p. Added: trunk/gcc/testsuite/gcc.dg/vect/pr21591.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-data-ref.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21591
[Bug c++/22620] Accepts invalid, inaccessible overloaded function is accepted
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-09-17 09:18 --- Fixed on the mainline: t1.cc:4: error: int foo::mf() is private t1.cc:10: error: within this context -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Known to work||4.2.0 Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22620
[Bug rtl-optimization/21299] [4.0/4.1/4.2 Regression] internal error on invalid asm statement
--- Comment #8 from steven at gcc dot gnu dot org 2006-09-17 09:54 --- Created an attachment (id=12286) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12286&action=view) patch implementing what Ian suggested See http://gcc.gnu.org/ml/gcc-patches/2006-08/msg00271.html -- steven at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|hubicka at gcc dot gnu dot |steven at gcc dot gnu dot |org |org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21299
[Bug fortran/29115] New: ICE in structure constructor for array, ponter component with non-pointer data
[EMAIL PROTECTED] pr29098]# cat ../prs/homer.f90 type :: homer integer, pointer :: bart(:) end type homer type(homer) :: marge integer :: duff_beer marge = homer (duff_beer) end [EMAIL PROTECTED] pr29098]# /svn-4.2/bin/gfortran ../prs/homer.f90f90 ../prs/homer.f90: In function MAIN__: ../prs/homer.f90:1: internal compiler error: in gfc_conv_expr_descriptor, at fortran/trans-array.c:4065 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. -- Summary: ICE in structure constructor for array, ponter component with non-pointer data Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pault at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29115
[Bug fortran/29098] allocation of a pointer to a derived type crashes
--- Comment #4 from patchapp at dberlin dot org 2006-09-17 11:30 --- Subject: Bug number PR29098 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-09/msg00671.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29098
[Bug fortran/29060] spread causes ICE in gfc_trans_array_constructor
--- Comment #4 from patchapp at dberlin dot org 2006-09-17 11:40 --- Subject: Bug number PR29060 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-09/msg00672.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29060
[Bug fortran/28817] [gfortran] problems with -Wunused
--- Comment #3 from patchapp at dberlin dot org 2006-09-17 12:45 --- Subject: Bug number PR28817 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-09/msg00674.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28817
[Bug c/25993] [4.0/4.1/4.2 Regression] -std= produces incorrect preprocessor output for .S
--- Comment #4 from steven at gcc dot gnu dot org 2006-09-17 13:15 --- Subject: Bug 25993 Author: steven Date: Sun Sep 17 13:14:53 2006 New Revision: 117005 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117005 Log: gcc/ PR c/25993 * c-opts.c (c_common_handle_option): Ignore the -std options if the input language is assembly. testsuite/ PR c/25993 * gcc.dg/pr25993.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr25993.c Modified: trunk/gcc/ChangeLog trunk/gcc/c-opts.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25993
[Bug c/25993] [4.0/4.1 Regression] -std= produces incorrect preprocessor output for .S
--- Comment #5 from steven at gcc dot gnu dot org 2006-09-17 13:17 --- Fixed on the trunk. -- steven at gcc dot gnu dot org changed: What|Removed |Added Known to fail|3.3.6 3.4.6 4.1.2 4.2.0 |3.3.6 3.4.6 4.1.2 Known to work|2.95.4 |2.95.4 4.2.0 Summary|[4.0/4.1/4.2 Regression] - |[4.0/4.1 Regression] -std= |std= produces incorrect |produces incorrect |preprocessor output for .S |preprocessor output for .S http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25993
[Bug fortran/28974] Extremely slow compilation of enumerated DATA statements.
--- Comment #4 from bdavis at gcc dot gnu dot org 2006-09-17 13:54 --- before the patch: $ time /usr/local/bin/gfortran -c data.f90 real3m1.263s user3m0.519s sys 0m0.120s after: $ time /usr/local/bin/gfortran -c data.f90 real0m3.215s user0m3.052s sys 0m0.092s -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28974
[Bug target/29114] [4.1/4.2 Regression] ICE when cross-compiling glibc for hppa on a 64bit host
--- Comment #2 from steven at gcc dot gnu dot org 2006-09-17 13:57 --- Probably a problem with all 64 bit hosts. -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to fail|4.1.1 |4.1.1 4.2.0 Last reconfirmed|-00-00 00:00:00 |2006-09-17 13:57:00 date|| Summary|[4.1 Regression] ICE when |[4.1/4.2 Regression] ICE |cross-compiling glibc for |when cross-compiling glibc |hppa on a 64bit host|for hppa on a 64bit host http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29114
[Bug target/29114] [4.1/4.2 Regression] ICE when cross-compiling glibc for hppa on a 64bit host
--- Comment #3 from steven at gcc dot gnu dot org 2006-09-17 13:59 --- This is an initial RTL generation problem. The ICE happens in instantiate-virtual-regs but the offending insn already exists right after expand: ;; Generating RTL for tree basic block 2 ;; a = 25214903917 (insn 7 5 8 (set (reg:DI 96) (const_int 25214910464 [0x5deed])) -1 (nil) (nil)) (insn 8 7 9 (set (reg:DI 95) (plus:DI (reg:DI 96) (const_int -6547 [0xe66d]))) -1 (nil) (expr_list:REG_EQUAL (const_int 25214903917 [0x5deece66d]) (nil))) (insn 9 8 0 (set (mem/c/i:DI (reg/f:SI 90 virtual-stack-vars) [0 a+0 S8 A64]) (reg:DI 95)) -1 (nil) (nil)) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29114
[Bug target/29114] [4.1/4.2 Regression] ICE when cross-compiling glibc for hppa on a 64bit host
--- Comment #4 from steven at gcc dot gnu dot org 2006-09-17 14:07 --- Are you _really_ sure this worked with GCC 3.4.5? $ ./cc1 --version GNU C version 3.4.6 (hppa2.0-linux-gnu) compiled by GNU C version 4.0.2 20050901 (prerelease) (SUSE Linux). GGC heuristics: --param ggc-min-expand=98 --param ggc-min-heapsize=127550 $ ./cc1 t.c main t.c: In function `main': t.c:1: error: unrecognizable insn: (insn 9 8 10 0 (set (reg:DI 95) (plus:DI (reg:DI 96) (const_int -6547 [0xe66d]))) -1 (nil) (expr_list:REG_DEAD (reg:DI 96) (expr_list:REG_EQUAL (const_int 25214903917 [0x5deece66d]) (nil t.c:1: internal compiler error: in extract_insn, at recog.c:2083 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29114
[Bug target/29114] [4.1/4.2 Regression] ICE when cross-compiling glibc for hppa on a 64bit host
--- Comment #5 from steven at gcc dot gnu dot org 2006-09-17 14:18 --- $ ./cc1 --version GNU C version 3.3.6-hammer 20050117 (prerelease) (hppa2.0-linux-gnu) compiled by GNU C version 4.0.2 20050901 (prerelease) (SUSE Linux). GGC heuristics: --param ggc-min-expand=98 --param ggc-min-heapsize=127550 $ ./cc1 t.c main t.c: In function `main': t.c:1: error: unrecognizable insn: (insn 9 8 10 0 0x2ab206c0 (set (reg:DI 95) (plus:DI (reg:DI 96) (const_int -6547 [0xe66d]))) -1 (nil) (expr_list:REG_DEAD (reg:DI 96) (expr_list:REG_EQUAL (const_int 25214903917 [0x5deece66d]) (nil t.c:1: internal compiler error: in extract_insn, at recog.c:2175 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29114
[Bug target/29114] ICE when cross-compiling glibc for hppa on a 64bit host
-- steven at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |NEW Known to fail|4.1.1 4.2.0 |3.3.6 3.4.6 4.1.1 4.2.0 Last reconfirmed|2006-09-17 13:57:00 |2006-09-17 14:19:27 date|| Summary|[4.1/4.2 Regression] ICE|ICE when cross-compiling |when cross-compiling glibc |glibc for hppa on a 64bit |for hppa on a 64bit host|host http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29114
[Bug c/29116] New: Failure to diagnose violation of constraint 6.7.5.2p2
int n = 0, p[n * 0 + 1]; For C90 and C99, as of June SVN at least, and going back at least as far as 3.3.3. Almost certainly because of overly early CF. -- Summary: Failure to diagnose violation of constraint 6.7.5.2p2 Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: neil at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29116
[Bug target/28568] compiler generates incorrect ARM instructions when using long bitfields
--- Comment #9 from jason dot morgan at vpnsolutions dot uk dot com 2006-09-17 15:14 --- Subject: RE: compiler generates incorrect ARM instructions when using long bitfields Surely that's the definition of a bug? I've heard of "If it ain't broke, don't fix it.." but never "If it's always been broke, its probably supposed to be like that.." Its a bit like the guy with a knackered car that never fixes it because "It's always made that noise" :) j. -Original Message- From: pinskia at gcc dot gnu dot org [mailto:[EMAIL PROTECTED] Sent: 17 September 2006 09:52 To: [EMAIL PROTECTED] Subject: [Bug target/28568] compiler generates incorrect ARM instructions when using long bitfields --- Comment #8 from pinskia at gcc dot gnu dot org 2006-09-17 08:51 --- (In reply to comment #7) > Subject: RE: compiler generates incorrect ARM instructions when using long > bitfields > > Why not? What are the criteria? It is obviously wrong and would be so > simple to fix, even optionally with a > runtime option. It just is not a regression since it has been wrong since the begining of time for GCC. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|major |normal Component|c |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28568 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. You reported the bug, or are watching the reporter. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28568
[Bug target/28568] compiler generates incorrect ARM instructions when using long bitfields
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-09-17 15:21 --- (In reply to comment #9) > Subject: RE: compiler generates incorrect ARM instructions when using long > bitfields > > Surely that's the definition of a bug? > I've heard of "If it ain't broke, don't fix it.." but never "If it's always > been broke, its probably supposed to be like that.." Its a bit like the guy > with a knackered car that never fixes it because "It's always made that > noise" Except it is fixed and really it is not a bug for most ABIs, only the ARM EABI which is new for GCC to support recently. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28568
[Bug tree-optimization/21591] not vectorizing a loop with access to structs
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-09-17 15:23 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21591
[Bug c/29116] Failure to diagnose violation of constraint 6.7.5.2p2
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-17 15:26 --- Confirmed, not a regression. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||accepts-invalid Known to fail||2.95 3.2.3 3.4.0 4.0.0 4.2.0 ||4.0.4 4.1.2 3.3.3 Last reconfirmed|-00-00 00:00:00 |2006-09-17 15:26:28 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29116
[Bug fortran/29115] ICE in structure constructor for array, ponter component with non-pointer data
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-17 15:32 --- 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-09-17 15:32:08 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29115
[Bug bootstrap/29102] mudflap's configure tries to link a binary and fails because I don
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-09-17 15:39 --- So what is the problem here? This works for me when I am building a cross compiler with a sysroot. What configure options are you using? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29102
gcc-bugs@gcc.gnu.org
/*
Hi,
in the following program the copy constructor of class C is called with
the constructor argument having the same address as the to be constructed
object.
Best regards,
Oliver Schmidt
$ for i in g++-3.3 g++-3.4 g++-4.0; do echo ""; $i --version;
$i -Wall t3.cpp; a.out ; echo; done
g++-3.3 (GCC) 3.3.5 (Debian 1:3.3.5-13)
Copyright (C) 2003 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
1) getValue() -> 100,getValue() -> 101
2) getValue() -> 200,getValue() -> 201
3) getValue() -> 300,XXX getValue() -> 201
4) getValue() -> 400,getValue() -> 400
g++-3.4 (GCC) 3.4.4 20050314 (prerelease) (Debian 3.4.3-13)
Copyright (C) 2004 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
1) getValue() -> 100,getValue() -> 101
2) getValue() -> 200,getValue() -> 201
3) getValue() -> 300,XXX getValue() -> 201
4) getValue() -> 400,XXX getValue() -> 201
g++-4.0 (GCC) 4.0.4 20060507 (prerelease) (Debian 4.0.3-3)
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
1) getValue() -> 100,getValue() -> 101
2) getValue() -> 200,getValue() -> 201
3) getValue() -> 300,XXX getValue() -> 201
4) getValue() -> 400,XXX getValue() -> 201
*/
///
#include
class C
{
public:
C() : v(counter++)
{}
C(const C& rhs) {
v = rhs.v;
if (this == &rhs) {
printf("XXX ");
}
}
int getValue() {
return v;
}
void setValue(int v) {
this->v = v;
}
static void setCounter(int i) {
counter = i;
}
private:
int v;
static int counter;
};
int C::counter = 100;
class D
{
public:
int getValue() {
return c.getValue();
}
private:
C c;
};
void f1()
{
D d1;
printf("1) getValue() -> %d,", d1.getValue());
{
D d1;
printf("getValue() -> %d\n", d1.getValue());
}
}
void f2()
{
D d2;
printf("2) getValue() -> %d,", d2.getValue());
{
D d2;
d2 = d2;
printf("getValue() -> %d\n", d2.getValue());
}
}
void f3()
{
D d3;
printf("3) getValue() -> %d,", d3.getValue());
{
D d3 = d3;
printf("getValue() -> %d\n", d3.getValue());
}
}
void f4()
{
D d4;
printf("4) getValue() -> %d,", d4.getValue());
{
D d4(d4);
printf("getValue() -> %d\n", d4.getValue());
}
}
int main(int argc, char **argv)
{
C::setCounter(100); f1();
C::setCounter(200); f2();
C::setCounter(300); f3();
C::setCounter(400); f4();
return 0;
}
///
--
Summary: Copy constructor is called with "this == &rhs"
Product: gcc
Version: 4.0.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: oschmidt at gmx dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29117
[Bug libstdc++/29118] New: Timeouts in libstdc++, libjava and libgomp testsuites
=== libstdc++ tests === Running target unix WARNING: program timed out. FAIL: 19_diagnostics/23591_thread-1.c execution test ... WARNING: program timed out. FAIL: ext/mt_allocator/22309_thread.cc execution test WARNING: program timed out. FAIL: thread/18185.cc execution test WARNING: program timed out. FAIL: thread/pthread1.cc execution test WARNING: program timed out. FAIL: thread/pthread2.cc execution test WARNING: program timed out. FAIL: thread/pthread3.cc execution test WARNING: program timed out. FAIL: thread/pthread4.cc execution test WARNING: program timed out. FAIL: thread/pthread5.cc execution test WARNING: program timed out. FAIL: thread/pthread6.cc execution test WARNING: program timed out. FAIL: thread/pthread7-rope.cc execution test WARNING: program timed out. FAIL: tr1/2_general_utilities/memory/shared_ptr/thread/default_weaktoshared.cc execution test WARNING: program timed out. FAIL: tr1/2_general_utilities/memory/shared_ptr/thread/mutex_weaktoshared.cc execution test === libjava tests === Running target unix WARNING: program timed out. FAIL: cxxtest run === libgomp tests === Running target unix WARNING: program timed out. FAIL: libgomp.c++/ctor-1.C -O0 execution test WARNING: program timed out. FAIL: libgomp.c++/ctor-1.C -O1 execution test WARNING: program timed out. FAIL: libgomp.c++/ctor-1.C -O2 execution test WARNING: program timed out. FAIL: libgomp.c++/ctor-1.C -O3 -fomit-frame-pointer execution test WARNING: program timed out. FAIL: libgomp.c++/ctor-1.C -O3 -fomit-frame-pointer -funroll-loops execution test WARNING: program timed out. FAIL: libgomp.c++/ctor-1.C -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions execution test WARNING: program timed out. FAIL: libgomp.c++/ctor-1.C -O3 -g execution test WARNING: program timed out. FAIL: libgomp.c++/ctor-1.C -Os execution test WARNING: program timed out. FAIL: libgomp.c++/ctor-2.C -O0 execution test WARNING: program timed out. FAIL: libgomp.c++/ctor-2.C -O1 execution test WARNING: program timed out. FAIL: libgomp.c++/ctor-2.C -O2 execution test WARNING: program timed out. FAIL: libgomp.c++/ctor-2.C -O3 -fomit-frame-pointer execution test WARNING: program timed out. FAIL: libgomp.c++/ctor-2.C -O3 -fomit-frame-pointer -funroll-loops execution test WARNING: program timed out. FAIL: libgomp.c++/ctor-2.C -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions execution test WARNING: program timed out. FAIL: libgomp.c++/ctor-2.C -O3 -g execution test WARNING: program timed out. FAIL: libgomp.c++/ctor-2.C -Os execution test WARNING: program timed out. FAIL: libgomp.c++/ctor-3.C -O0 execution test WARNING: program timed out. FAIL: libgomp.c++/ctor-3.C -O1 execution test WARNING: program timed out. FAIL: libgomp.c++/ctor-3.C -O2 execution test WARNING: program timed out. FAIL: libgomp.c++/ctor-3.C -O3 -fomit-frame-pointer execution test WARNING: program timed out. FAIL: libgomp.c++/ctor-3.C -O3 -fomit-frame-pointer -funroll-loops execution test WARNING: program timed out. FAIL: libgomp.c++/ctor-3.C -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions execution test WARNING: program timed out. FAIL: libgomp.c++/ctor-3.C -O3 -g execution test WARNING: program timed out. FAIL: libgomp.c++/ctor-3.C -Os execution test WARNING: program timed out. FAIL: libgomp.c++/ctor-4.C -O0 execution test WARNING: program timed out. FAIL: libgomp.c++/ctor-4.C -O1 execution test WARNING: program timed out. FAIL: libgomp.c++/ctor-4.C -O2 execution test WARNING: program timed out. FAIL: libgomp.c++/ctor-4.C -O3 -fomit-frame-pointer execution test WARNING: program timed out. FAIL: libgomp.c++/ctor-4.C -O3 -fomit-frame-pointer -funroll-loops execution test WARNING: program timed out. FAIL: libgomp.c++/ctor-4.C -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions execution test WARNING: program timed out. FAIL: libgomp.c++/ctor-4.C -O3 -g execution test WARNING: program timed out. FAIL: libgomp.c++/ctor-4.C -Os execution test WARNING: program timed out. FAIL: libgomp.c++/ctor-6.C -O0 execution test WARNING: program timed out. FAIL: libgomp.c++/ctor-6.C -O1 execution test WARNING: program timed out. FAIL: libgomp.c++/ctor-6.C -O2 execution test WARNING: program timed out. FAIL: libgomp.c++/ctor-6.C -O3 -fomit-frame-pointer execution test WARNING: program timed out. FAIL: libgomp.c++/ctor-6.C -O3 -fomit-frame-pointer -funroll-loops execution test WARNING: program timed out. FAIL: libgomp.c++/ctor-6.C -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions execution test WARNING: program timed out. FAIL: libgomp.c++/ctor-6.C -O3 -g execution test WARNING: program timed out. FAIL: libgomp.c++/ctor-6.C -Os execution test WARNING: program timed out. FAIL: libgomp.c++/ctor-7.C -O0 execution test WARNING: program timed out. FAIL: libgomp.c++/ctor-7.C -O1 execution test WARNING: program timed out. FAIL: libgomp.c
[Bug fortran/20779] ALLOCATEing the STAT variable not detected
--- Comment #4 from patchapp at dberlin dot org 2006-09-17 17:40 --- Subject: Bug number PR20779 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-09/msg00680.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20779
[Bug c++/26167] -Wconversion fails to detect signedness conversion from int to unsigned int in fuction call
--- Comment #7 from kristian dot hermansen at gmail dot com 2006-09-17 18:37 --- Will gcc/g++ integrate the Wcoercion project's solution? It seems to have been sponsored by Google's Summer of Code 2006. Maybe it will be tested/included soon? Here is the developer: [EMAIL PROTECTED] Should we contact him? -Wcoercion would be very useful for warning about many security flaws in software... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26167
[Bug c++/26167] -Wconversion fails to detect signedness conversion from int to unsigned int in fuction call
--- Comment #8 from kristian dot hermansen at gmail dot com 2006-09-17 18:39 --- Sorry, I didn't notice at first that this was you!!! Will you integrate Wcoercion into gcc/g++ soon or will it always remain a side project? It would be nice to see such a warning come from using -Wall. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26167
gcc-bugs@gcc.gnu.org
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-17 18:51 --- Well d2, we call the default operator= with lhs and rhs as the same. So which version do you think have a bug? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29117
[Bug target/29114] ICE when cross-compiling glibc for hppa on a 64bit host
--- Comment #6 from vapier at gentoo dot org 2006-09-17 19:13 --- i had a report from someone that it worked with 3.4.5; i only verified that 4.1.1 was ICEing -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29114
[Bug c++/29106] [4.0/4.1 Regression] sizeof(*var) in expression drops entire line of code out of compile
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-09-17 19:27 --- Confirmed, still broken as of today "4.1.2 20060917". -- 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-09-17 19:27:47 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29106
[Bug c++/27732] [4.0/4.1/4.2 Regression] Parentheses elicit spurious error: "missing '>' to terminate the template argument list"
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Summary|Parentheses elicit spurious |[4.0/4.1/4.2 Regression] |error: "missing '>' to |Parentheses elicit spurious |terminate the template |error: "missing '>' to |argument list" |terminate the template ||argument list" Target Milestone|4.1.2 |4.0.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27732
[Bug tree-optimization/25211] [4.1 Regression] verify_ssa ICE with -Os -ftree-loop-linear
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-09-17 19:31 --- 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=25211
[Bug c++/26988] [4.0/4.1/4.2 Regression] template constructor in template class derived from virtual base can not be specialized
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Summary|template constructor in |[4.0/4.1/4.2 Regression] |template class derived from |template constructor in |virtual base can not be |template class derived from |specialized |virtual base can not be ||specialized Target Milestone|4.1.2 |4.0.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26988
[Bug libgcj/9715] Not all required character encodings are supported
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.1.2 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9715
[Bug ada/29015] Ada 2005 observer pattern with mutually dependent packages and containers produces compiler error
--- Comment #1 from laguest at archangeli dot demon dot co dot uk 2006-09-17 19:42 --- Using the current SVN source (17/09/06) I get a slightly different error (with the same source): gcc -c -gnat05 test_observers.adb +===GNAT BUG DETECTED==+ | 4.2.0 20060917 (experimental) (i686-pc-linux-gnu) Assert_Failure atree.adb:812| | Error detected at subjects.ads:17:3 | | Please submit a bug report; see http://gcc.gnu.org/bugs.html.| | Use a subject line meaningful to you and us to track the bug.| | Include the entire contents of this bug box in the report. | | Include the exact gcc or gnatmake command that you entered. | | Also include sources listed below in gnatchop format | | (concatenated together with no headers between files). | +==+ Please include these source files with error report Note that list may not be accurate in some cases, so please double check that the problem can still be reproduced with the set of files listed. test_observers.adb my_observer.ads observers.ads subjects.ads compilation abandoned gnatmake: "test_observers.adb" compilation error -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29015
[Bug middle-end/21107] [4.0/4.1/4.2 regression] internal compiler error: in expand_one_stack_var_at, at cfgexpand.c:476
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-09-17 19:49 --- Fixed by: 2005-11-12 Eric Botcazou <[EMAIL PROTECTED]> * function.c (assign_stack_local_1): Restrict sanity check on frame size overflow to 32-bit and above platforms. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|4.1.2 |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21107
[Bug c++/20173] [4.0 regression] gcc accepts invalid partial specialization attempt of member function
--- Comment #16 from pinskia at gcc dot gnu dot org 2006-09-17 19:57 --- Fixed so closing as such. -- 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=20173
[Bug c++/26433] [4.0 Regression] Syntax error using __FUNCTION__ in catch handler
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-09-17 19:57 --- Fixed so closing as such. -- 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=26433
[Bug middle-end/29111] [4.2 Regression] FAIL: gcc.dg/torture/pr26565.c -O0 execution test
--- Comment #3 from danglin at gcc dot gnu dot org 2006-09-17 20:05 --- There's a question in my mind as to whether we should always be emitting a library call: /* When not optimizing, generate calls to library functions for a certain set of builtins. */ if (!optimize && !called_as_built_in (fndecl) && DECL_ASSEMBLER_NAME_SET_P (fndecl) && fcode != BUILT_IN_ALLOCA) return expand_call (exp, target, ignore); The setting of DECL_ASSEMBLER_NAME doesn't seem to be entirely reliable. We have in builtin_function: if (library_name) SET_DECL_ASSEMBLER_NAME (decl, get_identifier (library_name)); library_name is set for __builtin_memcpy but not for memcpy. The difference in behavior between the 32-bit hpux targets and the 32-bit linux target arises because the hpux target defines ASM_OUTPUT_EXTERNAL. So, the assembler name for memcpy gets set indirectly by assemble_external_real and this causes expand_builtin to use the library routine. Is this the intended behavior? Ok, back to looking at the linux SEGV. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29111
[Bug fortran/29101] Memory leak in gfortran
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2006-09-17 20:14 --- Problem is not in library side. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Component|libfortran |fortran Summary|memory leak in libgfortran |Memory leak in gfortran http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29101
[Bug middle-end/29111] [4.2 Regression] FAIL: gcc.dg/torture/pr26565.c -O0 execution test
--- Comment #4 from danglin at gcc dot gnu dot org 2006-09-17 20:21 --- Hmmm, seems this is a known issue that never got fixed. See this thread: http://gcc.gnu.org/ml/gcc-patches/2006-03/msg01558.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29111
[Bug c++/26167] -Wconversion fails to detect signedness conversion from int to unsigned int in fuction call
--- Comment #9 from tbm at cyrius dot com 2006-09-17 20:31 --- It's aiming for inclusion in GCC 4.3, see http://gcc.gnu.org/wiki/GCC_4.3_Release_Planning -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26167
[Bug c++/26298] -Wconversion fails to detect signedness change during widening conversion
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-09-17 21:02 --- Well, you are right. This bug is a dup of the bug requesting -Wcoercion (if we have such). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26298
[Bug c/29119] New: Internal compiler error while adding __asm__ statement
Hi,
I got an internal compiler error while compiling a source file.
I was not able to reproduce the bug on a smaller source file.
I only notice that the error occurs when I add an
__asm__ volatile ("movl %0,%%eax"::"m"(get_segment_base_address(*entry)));
but not at the line of this addition.
On gcc 3.x adding this statement produce a normal warning of indirectly
addressable input. (entry is an array of uint8_t[8])
Here is the output of gcc -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu
--enable-libstdcxx-debug --enable-mpfr --with-tune=i686
--enable-checking=release i486-linux-gnu
Thread model: posix
gcc version 4.1.2 20060901 (prerelease) (Debian 4.1.1-13)
Command line that triggers the bug:
/usr/lib/gcc/i486-linux-gnu/4.1.2/cc1 -fpreprocessed ldt.i -quiet -dumpbase
ldt.c -mtune=i686 -auxbase-strip mm/ldt.o -O2 -Wall -Wstrict-aliasing=2
-std=gnu99 -version -fomit-frame-pointer -ffreestanding -o ldt.s
GNU C version 4.1.2 20060901 (prerelease) (Debian 4.1.1-13) (i486-linux-gnu)
compiled by GNU C version 4.1.2 20060901 (prerelease) (Debian
4.1.1-13).
GGC heuristics: --param ggc-min-expand=63 --param ggc-min-heapsize=62590
Compiler executable checksum: 87670b01f6c8def5369835011f9cd001
Compiler output:
mm/ldt.c: In function 'ldt_add_entry':
mm/ldt.c:149: internal compiler error: in bitmap_first_set_bit, at bitmap.c:535
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
For Debian GNU/Linux specific bug reporting instructions,
see .
Preprocessed source stored into /tmp/ccgHytIr.out file, please attach this to
your bugreport.
make[1]: *** [mm/ldt.o] Error 1
make[1]: Leaving directory `/divers/work/ExAmour/kernel/src/arch/i386'
make: *** [install_exAmour] Error 2
Have a great day.
--
Rémy SAISSY
--
Summary: Internal compiler error while adding __asm__ statement
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: remy dot saissy at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29119
[Bug c/29119] Internal compiler error while adding __asm__ statement
--- Comment #1 from remy dot saissy at gmail dot com 2006-09-17 21:25 --- Created an attachment (id=12287) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12287&action=view) The .i file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29119
[Bug inline-asm/29119] [4.0/4.1/4.2 Regression] Internal compiler error while adding __asm__ statement
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-09-17 21:57 ---
Reduced testcase:
void ldt_add_entry(void)
{
__asm__ ("" :: "m"(({unsigned __v; __v;})));
}
--
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-09-17 21:57:22
date||
Summary|Internal compiler error |[4.0/4.1/4.2 Regression]
|while adding __asm__|Internal compiler error
|statement |while adding __asm__
||statement
Target Milestone|--- |4.0.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29119
[Bug inline-asm/29119] [4.0/4.1/4.2 Regression] Internal compiler error while adding __asm__ statement
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-09-17 22:01 --- We must had forgot to mark the variable as ADDRESSABLE. Also this used to work with the C++ front-end in 4.1.x but now does not in 4.2.0. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29119
[Bug target/28919] IV selection is messed up
--- Comment #6 from rakdver at gcc dot gnu dot org 2006-09-17 22:48 --- (In reply to comment #4) > Actually this is just a problem of IV selection, what is happening is the IV > selection chooses the 1024+(const char *)&base[quad] as the IV instead of just > &base[quad] which causes the bigger encoding. My guess is that there are two reasons for this: 1) at the moment, ivopts do not know that _mm_prefetch (or __builtin_prefetch or any other prefetching builtin) is special and that the address it takes may be expressed using an addressing mode 2) the cost function for addresses pretends that more complicated addressing modes are cheaper Both problems can be solved, but most likely not in stage3. Regarding the "-fprefetch-loop-arrays's heuristic is way off the mark" part, gcc badly overestimates the size of the loop (it guesses 300 insns). I will check what I can do with that. -- rakdver 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-09-17 22:48:12 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28919
[Bug c/24542] potential integer overflow should be warned on assignment to wider variable
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-09-18 00:18 --- We should never warn on multiply because it is just too crazy to. This is what debugging is about, debug your program for mistakes like this. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24542
[Bug c++/28211] [4.0/4.1/4.2 Regression] wrong linkage of template argument, diagnostic could be improved
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-18 00:48 --- Confirmed, a regression from 3.3.3 which gave: t.cc:4: error: address of non-extern `foo' cannot be used as template argument -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|minor |normal Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to fail||3.4.0 4.0.0 4.1.0 4.2.0 Known to work||3.3.3 Last reconfirmed|-00-00 00:00:00 |2006-09-18 00:48:45 date|| Summary|wrong linkage of template |[4.0/4.1/4.2 Regression] |argument, diagnostic could |wrong linkage of template |be improved |argument, diagnostic could ||be improved Target Milestone|--- |4.0.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28211
[Bug bootstrap/21544] xgcc fails (1rst stage) if binutils is not installed into --prefix directory
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-18 01:15 --- Can you try a 4.0.2 or a 4.1.1 version of GCC? Also can you give the part of the log of where the command failed? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Priority|P2 |P3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21544
[Bug bootstrap/21544] xgcc fails (1rst stage) if binutils is not installed into --prefix directory
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21544
[Bug middle-end/22072] bizarre code for int*int/2 for -Os
--- Comment #11 from pinskia at gcc dot gnu dot org 2006-09-18 01:24 --- So the only bug here is that -Os produces an extra move. That comes from the register allocator/reload: Reloads for insn # 13 Reload 0: reload_in (SI) = (reg:SI 1 dx [65]) GENERAL_REGS, RELOAD_FOR_INPUT (opnum = 3) reload_in_reg: (reg:SI 1 dx [65]) reload_reg_rtx: (reg:SI 2 cx) -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|minor |enhancement Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||missed-optimization, ra Last reconfirmed|-00-00 00:00:00 |2006-09-18 01:24:44 date|| Summary|bizarre code for int*int/2 |bizarre code for int*int/2 ||for -Os http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22072
[Bug c/25151] GCC issues warnings to a syntactically correct expression.
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-09-18 01:38 --- This code still involes undefined runtime behavior. So the warning is valid. -- 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=25151
[Bug target/23605] memset() Optimization on x86-32 bit
--- Comment #17 from pinskia at gcc dot gnu dot org 2006-09-18 01:45 --- (In reply to comment #13) > Notice in the tektester.386.s testcase, you have an xor instruction on ebx, > when all what's needed to clear out al/ax/eax is a > mov $0, al/ax/eax xor is both faster and has a smaller encoding than mov does. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23605
[Bug target/24156] sibling call with -O2 copies parameters twice
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-18 01:49 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Component|rtl-optimization|target Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-09-18 01:49:05 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24156
[Bug tree-optimization/28887] [4.2 Regression] rejects valid code (bitfields and loops) with -O1 -fprefetch-loop-arrays
--- Comment #7 from sayle at gcc dot gnu dot org 2006-09-18 01:54 --- Subject: Bug 28887 Author: sayle Date: Mon Sep 18 01:54:33 2006 New Revision: 117012 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117012 Log: 2006-09-17 Zdenek Dvorak <[EMAIL PROTECTED]> PR tree-optimization/28887 * tree-ssa-loop-prefetch.c (analyze_ref): Strip nonaddressable component parts from the reference. (gather_memory_references_ref): Record the reference without the nonaddressable component parts. * gcc.dg/prefetch-loop-arrays-1.c: New test case. Added: trunk/gcc/testsuite/gcc.dg/prefetch-loop-arrays-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-loop-prefetch.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28887
[Bug tree-optimization/28887] [4.2 Regression] rejects valid code (bitfields and loops) with -O1 -fprefetch-loop-arrays
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-09-18 02:04 --- 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=28887
[Bug target/18562] SSE constant vector initialization produces dead constant values on stack
--- Comment #13 from pinskia at gcc dot gnu dot org 2006-09-18 03:13 --- The problem here is the x86 back-end pushes constant vectors to the constant pool. Note my patch will not work any more because it has been outdated to take into account the new CONSTRUCTOR layout. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|2006-01-27 22:11:23 |2006-09-18 03:13:39 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18562
[Bug target/26792] [4.2 Regression] need to use autoconf when using newly-added libgcc functions
--- Comment #17 from bryce at mckinlay dot net dot nz 2006-09-18 03:49 --- (In reply to comment #15) Yes, I think the #ifdef is a reasonable solution. Stack traces will be inaccurate when GetIPInfo is unavailable, but I don't see any easy way around that. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26792
[Bug target/28919] IV selection is messed up
--- Comment #7 from steven at gcc dot gnu dot org 2006-09-18 04:15 --- To cut down the estimate for the loop size, you need to treat CALL_EXPRs to machine specific builtins specially (and probably some of the normal builtins too). See estimate_num_insns_1, the case for CALL_EXPR. You probably need to add a target hook to make this work. This has been discussed before on the mailing lists. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28919
[Bug target/26792] [4.2 Regression] need to use autoconf when using newly-added libgcc functions
--- Comment #18 from howarth at nitro dot med dot uc dot edu 2006-09-18 04:34 --- Created an attachment (id=12288) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12288&action=view) Patch to revert to _Unwind_GetIP when HAVE_GETIPINFO undefined -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26792
[Bug target/26792] [4.2 Regression] need to use autoconf when using newly-added libgcc functions
--- Comment #19 from howarth at nitro dot med dot uc dot edu 2006-09-18
04:40 ---
Tested the patch on Darwin 8 with no regressions. Verified that the
_Unwind_GetIPInfo
symbols are absent for libgcj with HAVE_GETIPINFO undefined. While the patch is
over
10 lines, I would argue that I only wrote the lines with the preprocessor
statements and
the rest is simply a return of previously existing code from others.
LAST_UPDATED: Tue Sep 5 01:41:47 UTC 2006 (revision 116689)
Native configuration is powerpc-apple-darwin8
=== libjava tests ===
Running target unix
=== libjava Summary ===
# of expected passes6989
# of expected failures 12
# of untested testcases 8
Compiler version: gcc libjava
Platform: powerpc-apple-darwin8
configure flags: --prefix=/sw --prefix=/sw/lib/gcc4 --with-gmp=/sw
--with-included-gettext --host=powerpc-apple-darwin8
--with-as=/sw/lib/odcctools/bin/as --with-ld=/sw/lib/odcctools/bin/ld
--with-nm=/sw/lib/odcctools/bin/nm '--mandir=\${prefix}/share/man'
'--infodir=\${prefix}/share/info' --with-libiconv-prefix=/sw
--disable-bootstrap --enable-languages=c,c++,fortran,java,objc
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26792
[Bug target/26792] [4.2 Regression] need to use autoconf when using newly-added libgcc functions
--- Comment #20 from howarth at nitro dot med dot uc dot edu 2006-09-18 04:58 --- Created an attachment (id=12289) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12289&action=view) clean up whitespace in Changelog for patch to revert to _Unwind_GetIP when HAVE_GETIPINFO undefined -- howarth at nitro dot med dot uc dot edu changed: What|Removed |Added Attachment #12288|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26792
[Bug c/24542] potential integer overflow should be warned on assignment to wider variable
--- Comment #10 from alexey at hyperroll dot com 2006-09-18 05:48 --- (In reply to comment #9) > We should never warn on multiply because it is just too crazy to. This is > what > debugging is about, debug your program for mistakes like this. The citation may be used to eliminate every warning any compiler produces: "just debug, why bother? Ain't you a programmer?" I've tried to specify a warning that comes for developers when they do a scaling of their applications for a larger input data, and just do not see when the overflowing happens. So, you're free to reject the issue, but the reason you've given... Personally, I do not accept it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24542
[Bug target/28919] IV selection is messed up
--- Comment #8 from tbptbp at gmail dot com 2006-09-18 05:52 --- Subject: Re: IV selection is messed up On 17 Sep 2006 22:48:12 -, rakdver at gcc dot gnu dot org <[EMAIL PROTECTED]> wrote: > Regarding the "-fprefetch-loop-arrays's heuristic is way off the mark" part, > gcc badly overestimates the size of the loop (it guesses 300 insns). I will > check what I can do with that. Provided i understand what you meant, it's the other way around; with -fprefetch-loop-array gcc prefetch distance is much too short. If i remember correctly, that testcase takes a bunch of cycles per iteration on my k8 (opteron 252) and you have to prefetch at the very least 256 bytes away to make that profitable; it's less than 128 with gcc-4.2-20060908. That testcase is pretty silly anyway. Here's what i get with the real code and -fprefetch-loop-array 4011c2: movdqa (%ecx),%xmm2 4011c6: lea0x10(%ecx),%eax 4011c9: movdqa %xmm6,%xmm4 4011cd: dec%edx 4011ce: movdqa %xmm2,%xmm0 4011d2: mov%eax,%ecx 4011d4: prefetcht0 (%eax) 4011d7: movdqa %xmm6,%xmm1 4011db: punpckldq %xmm2,%xmm0 4011df: punpckhdq %xmm2,%xmm2 4011e3: movdqa %xmm0,%xmm3 4011e7: punpcklqdq %xmm0,%xmm3 4011eb: punpckhqdq %xmm0,%xmm0 4011ef: pcmpgtd %xmm3,%xmm4 4011f3: pcmpgtd %xmm0,%xmm1 4011f7: paddd 0x10(%esp),%xmm4 4011fd: paddd %xmm1,%xmm4 401201: movdqa %xmm5,%xmm1 401205: pcmpgtd %xmm3,%xmm1 401209: movdqa %xmm1,%xmm3 40120d: movdqa %xmm5,%xmm1 401211: paddd %xmm7,%xmm3 401215: pcmpgtd %xmm0,%xmm1 401219: movdqa %xmm6,%xmm0 40121d: paddd %xmm1,%xmm3 401221: movdqa %xmm2,%xmm1 401225: punpcklqdq %xmm2,%xmm1 401229: punpckhqdq %xmm2,%xmm2 40122d: pcmpgtd %xmm1,%xmm0 401231: paddd %xmm0,%xmm4 401235: movdqa %xmm6,%xmm0 401239: pcmpgtd %xmm2,%xmm0 40123d: paddd %xmm0,%xmm4 401241: movdqa %xmm5,%xmm0 401245: movaps %xmm4,0x10(%esp) 40124a: pcmpgtd %xmm1,%xmm0 40124e: paddd %xmm0,%xmm3 401252: movdqa %xmm5,%xmm0 401256: pcmpgtd %xmm2,%xmm0 40125a: paddd %xmm0,%xmm3 40125e: movdqa %xmm3,%xmm7 401262: jne4011c2 Each iteration takes about 8 cycles when not starved and prefetching isn't a win unless done at least 4 or 8 cachelines away, so this one is nothing but a hinderance. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28919
[Bug fortran/28817] [gfortran] problems with -Wunused
--- Comment #4 from pault at gcc dot gnu dot org 2006-09-18 06:25 --- Subject: Bug 28817 Author: pault Date: Mon Sep 18 06:24:54 2006 New Revision: 117014 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117014 Log: 2006-09-18 Paul Thomas <[EMAIL PROTECTED]> PR fortran/29060 * iresolve.c (resolve_spread): Build shape for result if the source shape is available and dim and ncopies are constants. PR fortran/28817 PR fortran/21918 * trans-decl.c (generate_local_decl): Change from 'warning' to 'gfc_warning' to have line numbers correctly reported. 2006-09-18 Paul Thomas <[EMAIL PROTECTED]> PR fortran/29060 * gfortran.dg/spread_shape_1.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/spread_shape_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/iresolve.c trunk/gcc/fortran/trans-decl.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28817
[Bug fortran/29060] spread causes ICE in gfc_trans_array_constructor
--- Comment #5 from pault at gcc dot gnu dot org 2006-09-18 06:25 --- Subject: Bug 29060 Author: pault Date: Mon Sep 18 06:24:54 2006 New Revision: 117014 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117014 Log: 2006-09-18 Paul Thomas <[EMAIL PROTECTED]> PR fortran/29060 * iresolve.c (resolve_spread): Build shape for result if the source shape is available and dim and ncopies are constants. PR fortran/28817 PR fortran/21918 * trans-decl.c (generate_local_decl): Change from 'warning' to 'gfc_warning' to have line numbers correctly reported. 2006-09-18 Paul Thomas <[EMAIL PROTECTED]> PR fortran/29060 * gfortran.dg/spread_shape_1.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/spread_shape_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/iresolve.c trunk/gcc/fortran/trans-decl.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29060
[Bug fortran/21918] Warnings about unused variables should point to the declaration
--- Comment #5 from pault at gcc dot gnu dot org 2006-09-18 06:25 --- Subject: Bug 21918 Author: pault Date: Mon Sep 18 06:24:54 2006 New Revision: 117014 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117014 Log: 2006-09-18 Paul Thomas <[EMAIL PROTECTED]> PR fortran/29060 * iresolve.c (resolve_spread): Build shape for result if the source shape is available and dim and ncopies are constants. PR fortran/28817 PR fortran/21918 * trans-decl.c (generate_local_decl): Change from 'warning' to 'gfc_warning' to have line numbers correctly reported. 2006-09-18 Paul Thomas <[EMAIL PROTECTED]> PR fortran/29060 * gfortran.dg/spread_shape_1.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/spread_shape_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/iresolve.c trunk/gcc/fortran/trans-decl.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21918
[Bug bootstrap/29102] mudflap's configure tries to link a binary and fails because I don
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-09-18 06:36 --- The root issue is that I don't have a libc for the target system. And the bug is that mudflap tries to link something, and then fails because it can't find crt1.o. The idea is that you can build binutils for arm-linux, then gcc for arm-linux, and then with these compile glibc for arm-linux. That's the idea of having a platform where you have the source code for everything, right? However, only the binutils part actually works. gcc wants header files from the target platform for libgcc (!?!?), and mudflap wants object and library files, too. And glibc won't cross compile unless you already have a libc for the target platform, but that's not your fault. I'm just mentioning it to make clear what miserable shape we're in here. Felix --- You should try using crosstool which what is recommended to build a cross compiler. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29102
[Bug fortran/28817] [gfortran] problems with -Wunused
--- Comment #5 from pault at gcc dot gnu dot org 2006-09-18 06:46 --- Subject: Bug 28817 Author: pault Date: Mon Sep 18 06:46:36 2006 New Revision: 117015 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117015 Log: 2006-09-18 Paul Thomas <[EMAIL PROTECTED]> PR fortran/29060 * iresolve.c (resolve_spread): Build shape for result if the source shape is available and dim and ncopies are constants. PR fortran/28817 PR fortran/21918 * trans-decl.c (generate_local_decl): Change from 'warning' to 'gfc_warning' to have line numbers correctly reported. 2006-09-18 Paul Thomas <[EMAIL PROTECTED]> PR fortran/29060 * gfortran.dg/spread_shape_1.f90: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/spread_shape_1.f90 Modified: branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/iresolve.c branches/gcc-4_1-branch/gcc/fortran/trans-decl.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28817
[Bug fortran/29060] spread causes ICE in gfc_trans_array_constructor
--- Comment #6 from pault at gcc dot gnu dot org 2006-09-18 06:46 --- Subject: Bug 29060 Author: pault Date: Mon Sep 18 06:46:36 2006 New Revision: 117015 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117015 Log: 2006-09-18 Paul Thomas <[EMAIL PROTECTED]> PR fortran/29060 * iresolve.c (resolve_spread): Build shape for result if the source shape is available and dim and ncopies are constants. PR fortran/28817 PR fortran/21918 * trans-decl.c (generate_local_decl): Change from 'warning' to 'gfc_warning' to have line numbers correctly reported. 2006-09-18 Paul Thomas <[EMAIL PROTECTED]> PR fortran/29060 * gfortran.dg/spread_shape_1.f90: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/spread_shape_1.f90 Modified: branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/iresolve.c branches/gcc-4_1-branch/gcc/fortran/trans-decl.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29060
[Bug fortran/21918] Warnings about unused variables should point to the declaration
--- Comment #6 from pault at gcc dot gnu dot org 2006-09-18 06:46 --- Subject: Bug 21918 Author: pault Date: Mon Sep 18 06:46:36 2006 New Revision: 117015 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117015 Log: 2006-09-18 Paul Thomas <[EMAIL PROTECTED]> PR fortran/29060 * iresolve.c (resolve_spread): Build shape for result if the source shape is available and dim and ncopies are constants. PR fortran/28817 PR fortran/21918 * trans-decl.c (generate_local_decl): Change from 'warning' to 'gfc_warning' to have line numbers correctly reported. 2006-09-18 Paul Thomas <[EMAIL PROTECTED]> PR fortran/29060 * gfortran.dg/spread_shape_1.f90: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/spread_shape_1.f90 Modified: branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/iresolve.c branches/gcc-4_1-branch/gcc/fortran/trans-decl.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21918
[Bug fortran/29101] Memory leak in gfortran
--- Comment #3 from pault at gcc dot gnu dot org 2006-09-18 06:53 --- (In reply to comment #2) > Problem is not in library side. > Jerry, This is an easy one: Somebody forgot to add the post block for the evaluation of the select expression to the block of code, for the specific case of character expressions. This Index: gcc/fortran/trans-stmt.c === *** gcc/fortran/trans-stmt.c(revision 117013) --- gcc/fortran/trans-stmt.c(working copy) *** gfc_trans_character_select (gfc_code *co *** 1467,1472 --- 1467,1474 tmp = build1 (GOTO_EXPR, void_type_node, tmp); gfc_add_expr_to_block (&block, tmp); + gfc_add_block_to_block (&block, &se.post); + tmp = gfc_finish_block (&body); gfc_add_expr_to_block (&block, tmp); tmp = build1_v (LABEL_EXPR, end_label); fixes it by producing the code: pstr.6 = (char[1:D.960] *) _gfortran_internal_malloc (D.960); tolower (pstr.6, D.960, D.958, D.959); goto _gfortran_select_string ((void *) &jumptable.5, 2, &L.5, pstr.6, D.960); _gfortran_internal_free ((void *) pstr.6); L.4:; *value = 1; goto L.5; L.3:; __result_validate_value = 0; goto L.5; L.5:; I am not going to be in a position to do anything about this for two weeks - "I'm on the road again...". I can submit it today; if it is determined to be essential to get into the 4.2 release, could you do the honors with the commit? Are there any more such constructs in fortran that take a character expression? I could not immediately think of any. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added CC||jvdelisle at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29101
[Bug fortran/29060] spread causes ICE in gfc_trans_array_constructor
--- Comment #7 from pault at gcc dot gnu dot org 2006-09-18 06:54 --- Fixed on trunk and 4.1 Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29060
[Bug fortran/28817] [gfortran] problems with -Wunused
--- Comment #6 from pault at gcc dot gnu dot org 2006-09-18 06:55 --- Fixed on trunk and 4.1 Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28817
[Bug fortran/21918] Warnings about unused variables should point to the declaration
--- Comment #7 from pault at gcc dot gnu dot org 2006-09-18 06:56 --- Fixed on trunk and 4.1 Paul Thanks, Tobi! -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21918
[Bug fortran/22210] gfc_conv_array_initializer weirdness
--- Comment #9 from pault at gcc dot gnu dot org 2006-09-18 06:58 --- (In reply to comment #8) > (In reply to comment #7) > > Where did this one go to? Can we close it? > > It is still funny looking code. I might take a look this weekend or on June 27 > when I am traveling to the GCC summit. > ...and did you? *smile* Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22210
