[Bug libgcj/20160] [4.0 Regression] link errors building libgcj tests
-- What|Removed |Added Status|ASSIGNED|WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20160
[Bug c++/20195] Internal compiler error on legal code
--- Additional Comments From romein at astron dot nl 2005-02-25 08:27
---
Probably the bug has already been solved then. I used 4.0.0 20041214 (Red Hat
4.0.0-0.14.EL4), the one that has just been released by RedHat/CentOS.
(In reply to comment #1)
I cannot reproduce this with gcc 4.0.0 20050224
(In reply to comment #0)
g++4 yields an internal compiler error in do_nonmember_using_decl, at
cp/name-lookup.c:2074 when compiling:
namespace std
{
templatetypename _Tp class complex;
templatetypename _Tp complex_Tp conj(const complex_Tp);
}
using std::conj;
Kinds Regards, John Romein
---
dr. John W. Romein
Stichting ASTRON (Netherlands Foundation for Research in Astronomy)
Oude Hoogeveensedijk 4
7991 PD Dwingeloo
The Netherlands
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20195
[Bug c++/20201] requesting -Wfatal-errors=n
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-02-25 08:43 --- Confirmed. Would be a Good Thing IMHO. -- What|Removed |Added CC||reichelt at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed||1 GCC build triplet|i686-pc-linux-gnu | GCC host triplet|i686-pc-linux-gnu | GCC target triplet|i686-pc-linux-gnu | Last reconfirmed|-00-00 00:00:00 |2005-02-25 08:43:25 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20201
[Bug c++/20172] member function template declaration not instantiated during the instantiation of the enclosing class template
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-02-25
09:13 ---
Confirmed. Accepted since at least gcc 2.95.3.
Reduced testcase:
templatetypename T struct A
{
templateT void foo();
};
Adouble a;
Even Avoid is accepted.
--
What|Removed |Added
CC||reichelt at gcc dot gnu dot
||org
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Keywords||monitored
Last reconfirmed|-00-00 00:00:00 |2005-02-25 09:13:12
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20172
[Bug tree-optimization/17863] [4.0 Regression] threefold performance loss, not inlining as much
--- Additional Comments From kunert at physik dot tu-dresden dot de 2005-02-25 09:52 --- Subject: Re: [4.0 Regression] threefold performance loss, not inlining as much Wow. Many thanks for that analysis. Now I will go and fetch the patch. Since nobody seems to care about improving the inlining parameters, I'd love to see this patch in 4.0. Thomas Kunert rguenth at gcc dot gnu dot org wrote: --- Additional Comments From rguenth at gcc dot gnu dot org 2005-02-24 17:09 --- With __attribute__((leafify)) sticked to v4c_quad and mult_pq runtime goes down from 16.0s to 4.4s with recent gcc 4.0. For gcc 3.4.3 runtimes are 5.0s and 4.9s. We indeed do not very well on estimating the size of template metaprograms in 4.0. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17863
[Bug tree-optimization/17863] [4.0 Regression] threefold performance loss, not inlining as much
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-02-25 10:06 --- Patch at http://gcc.gnu.org/ml/gcc-patches/2005-02/msg01571.html improves the testcase from 16.2s to 12.1s (3.4: 5.0s) - aka, still not good enough. As we have (with the patch) still size estimates for the functions that are 15-40% higher than for 3.4 we'd probably need to bump our inlining limits accordingly, say by 20%. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17863
[Bug c++/20206] New: COMDAT broken for C++ thunks
The following testcase fails to link on targets that have
TARGET_USE_LOCAL_THUNK_ALIAS_P(DECL) nonzero.
// { dg-do run }
// { dg-options -O0 }
void
bar (int x)
{
asm ( : : g (x));
}
struct S { S () {}; virtual ~S () {}; };
struct T { virtual void foo (int) = 0; };
struct U : public S, public T
{
bool a;
U () {}
virtual ~U () {}
virtual void foo (int x)
{
switch (x)
{
case 12:
break;
case 9:
bar (7);
break;
case 10:
bar (12);
break;
case 4:
bar (18);
break;
case 2:
bar (26);
break;
}
}
};
U u;
int
main ()
{
}
g++4 -o thunk2{,.C}
/tmp/ccWXeK5j.s: Assembler messages:
/tmp/ccWXeK5j.s:647: Error: can't resolve `.gnu.linkonce.t._ZN1U3fooEi'
{.gnu.linkonce.t._ZN1U3fooEi section} - `.LFB20' {.gnu.linkonce.t._ZN1U3fooEi
section}
--
Summary: COMDAT broken for C++ thunks
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20206
[Bug c++/20206] [4.0 Regression] COMDAT broken for C++ thunks
--- Additional Comments From jakub at gcc dot gnu dot org 2005-02-25 11:45 --- Works in 3.4.x and earlier. Patch here: http://gcc.gnu.org/ml/gcc-patches/2005-02/msg01590.html -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed||1 Keywords||patch Last reconfirmed|-00-00 00:00:00 |2005-02-25 11:45:50 date|| Summary|COMDAT broken for C++ thunks|[4.0 Regression] COMDAT ||broken for C++ thunks Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20206
[Bug tree-optimization/19937] [4.0 regression] Wrong loop exit (causes binutils to fail)
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-02-25 12:08 --- Subject: Bug 19937 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-02-25 12:07:17 Modified files: gcc: ChangeLog tree-ssa-loop-ivopts.c Log message: PR tree-optimization/19937 * tree-ssa-loop-ivopts.c (rewrite_use_compare): Cast the final value to the type of the induction variable. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.7592r2=2.7593 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-ssa-loop-ivopts.c.diff?cvsroot=gccr1=2.49r2=2.50 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19937
[Bug tree-optimization/19937] [4.0 regression] Wrong loop exit (causes binutils to fail)
--- Additional Comments From rakdver at gcc dot gnu dot org 2005-02-25 12:10 --- Fixed. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19937
[Bug tree-optimization/19938] Missed jump threading opportunity due to signedness difference
-- Bug 19938 depends on bug 19937, which changed state. Bug 19937 Summary: [4.0 regression] Wrong loop exit (causes binutils to fail) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19937 What|Old Value |New Value Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19938
[Bug tree-optimization/19938] Missed jump threading opportunity due to signedness difference
-- Bug 19938 depends on bug 19937, which changed state. Bug 19937 Summary: [4.0 regression] Wrong loop exit (causes binutils to fail) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19937 What|Old Value |New Value Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19938
[Bug tree-optimization/19937] [4.0 regression] Wrong loop exit (causes binutils to fail)
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-25 12:29 --- Yes but only on the mainline, 4.0 is now branched. -- What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19937
[Bug tree-optimization/19937] [4.0 regression] Wrong loop exit (causes binutils to fail)
-- What|Removed |Added Status|REOPENED|ASSIGNED Known to fail||4.0.0 Known to work||4.1.0 3.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19937
[Bug rtl-optimization/20117] [4.0 Regression] duplicated labels in PIC
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-25 12:32 --- Fixed in 4.0.0 (before the branch) so closing as fixed. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20117
[Bug c++/20195] [4.0 Regression] Internal compiler error on legal code
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-25 12:33 --- So lets close it as fixed. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Summary|Internal compiler error on |[4.0 Regression] Internal |legal code |compiler error on legal code Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20195
[Bug c++/20206] [4.0 Regression] COMDAT broken for C++ thunks
-- What|Removed |Added Severity|normal |critical Keywords||wrong-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20206
[Bug target/20203] [4.0 Regression] unrecognizable insn building binutils
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-25 12:39 --- Patch here: http://gcc.gnu.org/ml/gcc-patches/2005-02/msg01592.html. -- What|Removed |Added Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20203
[Bug tree-optimization/20204] [4.0 regression] miscompilation of asm-declared registers
--- Additional Comments From dnovillo at gcc dot gnu dot org 2005-02-25 13:31 --- Could you show me how to configure a cris-axis-elf target and build a simulator? Have you tried undoing the tree-into-ssa.c change? It should be easy with: $ cvs up -r 2.40 tree-into-ssa.c If there had been a bug in the tree-into-ssa.c changes we would be seeing widespread carnage on every target. And that is just not the case: http://gcc.gnu.org/ml/gcc-testresults/2005-02/msg01103.html http://gcc.gnu.org/ml/gcc-testresults/2005-02/msg01100.html http://gcc.gnu.org/ml/gcc-testresults/2005-02/msg01101.html Diego. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20204
[Bug libgcj/20160] [4.0 Regression] link errors building libgcj tests
--- Additional Comments From rearnsha at gcc dot gnu dot org 2005-02-25 14:07 --- The build fails: rm -fr .libs/libgcj.lax/libgcjgc_convenience.a mkdir .libs/libgcj.lax/libgcjgc_convenience.a (cd .libs/libgcj.lax/libgcjgc_convenience.a /work/rearnsha/gnu/egcs/binutils/ar x /work/rearnsha/gnu/egcs/arm-elf/thumb/libjava/../boehm-gc/.libs/libgcjgc_convenience.a) copying selected object files to avoid basename conflicts... rm -fr .libs/libgcj.lax mkdir .libs/libgcj.lax cp org/ietf/jgss/MessagesBundle.properties.o .libs/libgcj.lax/lt1-MessagesBundle.properties.o cp .libs/libgcj.lax/libgcj0_convenience.a/EventListener.o .libs/libgcj.lax/lt2-EventListener.o cp: cannot stat `.libs/libgcj.lax/libgcj0_convenience.a/EventListener.o': No such file or directory cp .libs/libgcj.lax/libgcj0_convenience.a/ContentHandler.o .libs/libgcj.lax/lt3-ContentHandler.o cp: cannot stat `.libs/libgcj.lax/libgcj0_convenience.a/ContentHandler.o': No such file or directory cp .libs/libgcj.lax/libgcj0_convenience.a/Attributes.o .libs/libgcj.lax/lt4-Attributes.o cp: cannot stat `.libs/libgcj.lax/libgcj0_convenience.a/Attributes.o': No such file or directory etc. Incidentally, wouldn't it be more efficient to use links (either hard or soft) rather than doing a copy? -- What|Removed |Added AssignedTo|aoliva at gcc dot gnu dot |rearnsha at gcc dot gnu dot |org |org Status|WAITING |ASSIGNED Last reconfirmed|2005-02-24 22:01:51 |2005-02-25 14:07:21 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20160
[Bug c++/20207] New: null constructor not needed in multiple inheritance
In a dreaded diamon hierarchy
A0
|
A
/ \
B C
\ /
D
I get a request for a default constructor for A0 from the compiler
(gcc 3.4.4 )
If I drop A0, the error desappear.
testtemplate2.cpp: In constructor `BTYPE::B(int) [with TYPE = int]':
testtemplate2.cpp:57: instantiated from `DTYPE::D(int) [with TYPE =
int]'int::A0() »
testtemplate2.cpp:64: instantiated from hereint::A0(const A0int)
testtemplate2.cpp:37: erreur: pas de fonction concordante pour l'appel à «
A0int::A0() »
testtemplate2.cpp:15: note: candidats sont: A0int::A0(const A0int)
testtemplate2.cpp:18: note: A0TYPE::A0(TYPE) [with TYPE = int]
testtemplate2.cpp: In constructor `CTYPE::C(int) [with TYPE = int]':
testtemplate2.cpp:57: instantiated from `DTYPE::D(int) [with TYPE = int]'
testtemplate2.cpp:64: instantiated from here
testtemplate2.cpp:47: erreur: pas de fonction concordante pour l'appel à «
A0int::A0() »
testtemplate2.cpp:15: note: candidats sont: A0int::A0(const A0int)
testtemplate2.cpp:18: note: A0TYPE::A0(TYPE) [with TYPE = int]
templateclass TYPE
class A0
{ protected:
const int n;
public:
A0(TYPE a ) : n(a) { ;}
~A0() { ;}
virtual void foo() =0;
};
templateclass TYPE
class A : public virtual A0TYPE
{
public:
A(TYPE a ) : A0TYPE(a) { ;}
~A() { ;}
virtual void foo() =0;
};
templateclass TYPE
class B : public virtual ATYPE
{
public:
B(int b= 0) : ATYPE(b)
{ ;}
~B() { ;}
virtual void foo() =0;
};
templateclass TYPE
class C : public virtual ATYPE
{
public:
C(int c= 0) : ATYPE(c)
{ ;}
~C() { ;}
virtual void foo() =0;
};
templateclass TYPE
class D : public virtual BTYPE, public virtual CTYPE
{
public:
D(int d= 0) : A0TYPE(d), ATYPE(d), BTYPE(d), CTYPE(d)
{ ;}
~D() { ;}
virtual void foo() { ;}
};
int main(int argc, char *argv[])
{
Dint d(4);
}
--
Summary: null constructor not needed in multiple inheritance
Product: gcc
Version: 3.4.4
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Serge dot Iovleff at univ-lille1 dot fr
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20207
[Bug c++/20208] New: [4.0 Regression] No array-to-pointer decay happens for template functions
At -O1 and above, the following code ICE because well, the same reason why PR
2892 fails currently
really:
extern C void abort();
template typename T
inline void *Foo (T arg) { return arg[0]; }
int main () {
int bry[2];
if (Fooint[2](bry) != bry)
abort();
}
I filed this a seperate bug because well the ICE is a regression even though
fixing PR 2892 will fix this
also.
--
Summary: [4.0 Regression] No array-to-pointer decay happens for
template functions
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
OtherBugsDependingO 2892
nThis:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20208
[Bug c++/2892] No array-to-pointer decay happens for template functions
-- What|Removed |Added BugsThisDependsOn||20208 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2892
[Bug c++/20208] [4.0 Regression] No array-to-pointer decay happens for template functions
-- What|Removed |Added Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20208
[Bug c++/20175] [3.4 Regression] Warnings are issued when initializing struct members with strings
--- Additional Comments From gcc at magfr dot user dot lysator dot liu dot
se 2005-02-25 14:55 ---
(In reply to comment #3)
Patch here: http://gcc.gnu.org/ml/gcc-patches/2005-02/msg01489.html
This fixes the obvious case but it also makes the following pass with no
warnings and that is wrong, note especially S1 and S3!
struct S { char a[6]; int b[2]; };
S S0 = { { hello }, { 1, 2 } };
S S1 = { { hello }, 1, 2 }; // Highly suspicious
S S2 = { hello, { 1, 2 } };
S S3 = { hello, 1, 2 }; // Highly suspicious
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20175
[Bug c++/20209] New: [3.3/3.4/4.0 Regression] Missing warnings for aggregate has a partly bracketed initializer
The following should have warnings:
struct S { char a[6]; int b[2]; };
S S0 = { { hello }, { 1, 2 } };
S S1 = { { hello }, 1, 2 }; // { dg-warning }
S S2 = { hello, { 1, 2 } };
S S3 = { hello, 1, 2 }; // { dg-warning }
--
Summary: [3.3/3.4/4.0 Regression] Missing warnings for aggregate
has a partly bracketed initializer
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20209
[Bug c++/20175] [3.4 Regression] Warnings are issued when initializing struct members with strings
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-25 15:02 --- (In reply to comment #6) (In reply to comment #3) Patch here: http://gcc.gnu.org/ml/gcc-patches/2005-02/msg01489.html This fixes the obvious case but it also makes the following pass with no warnings and that is wrong, note especially S1 and S3! That looks like a different bug, I am filing a new bug for this (PR 20209). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20175
[Bug c++/20209] [3.3/3.4/4.0 Regression] Missing warnings for aggregate has a partly bracketed initializer
-- What|Removed |Added Target Milestone|--- |3.4.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20209
[Bug c++/20209] [3.3/3.4/4.0 Regression] Missing warnings for aggregate has a partly bracketed initializer
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-25 15:04 --- Obviously I compiled with -W -Wall. I wonder how this regression was missed for so long. -- What|Removed |Added Known to fail||3.3.3 3.4.0 4.0.0 Known to work||3.2.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20209
[Bug tree-optimization/20188] [4.0 Regression] asm and memory operands does not add a V_MAY_DEF
--- Additional Comments From dnovillo at gcc dot gnu dot org 2005-02-25 15:04 --- (In reply to comment #12) if (lhs (TREE_CODE (lhs) == TREE_LIST || EXPR_P (lhs)) will works for everyone, it works for this testcase too but I have not bootstrapped or tested it yet. This is the right fix. Could you bootstrap and test it? A test case for this would need a dg-scan test for two 'if ()' statements (i.e., we should not value number the second if() out). Thanks. Diego. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20188
[Bug inline-asm/20202] asm(movq %0, %mm0 : : X(*a)) generates invalid asm code
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-25 15:07 --- 'X' means Any operand whatsoever is allowed. so %eax there is fine. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20202
[Bug c++/20207] null constructor not needed in multiple inheritance
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-25 15:10 --- I think this is invalid code but I don't know how to produce it right now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20207
[Bug tree-optimization/20188] [4.0 Regression] asm and memory operands does not add a V_MAY_DEF
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-25 15:17 --- (In reply to comment #13) (In reply to comment #12) This is the right fix. Could you bootstrap and test it? A test case for this would need a dg-scan test for two 'if ()' statements (i.e., we should not value number the second if() out). Will do. -- Pinski -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pinskia at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20188
[Bug tree-optimization/20210] New: asm =m not taken into account
The following testcase is miscompiled on {powerpc,i386,x86_64}-redhat-linux
(well, any other for which an __asm is written).
extern void abort (void);
unsigned short v = 0x0300;
void
foo (unsigned short *p)
{
*p = v;
}
int
bar (void)
{
unsigned short x;
volatile unsigned short *z;
foo (x);
const unsigned int y = x;
z = x;
#ifdef __powerpc__
__asm __volatile (sthbrx %1,0,%2 : =m (*z) : r (y), r (z));
#elif defined __i386__ || defined __x86_64__
__asm __volatile (movb %b1,1(%2); movb %h1,(%2) : =m (*z) : r (y), r
(z));
#endif
return (x 1) == 0;
}
int
main (void)
{
if (bar ())
abort ();
return 0;
}
In final_cleanup, bar is:
bar ()
{
const unsigned intD.3 yD.1507;
short unsigned intD.8 xD.1505;
# BLOCK 0
# PRED: ENTRY [100.0%] (fallthru,exec)
# xD.1505_11 = V_MAY_DEF xD.1505_1;
foo (xD.1505);
yD.1507 = (const unsigned intD.3) xD.1505;
# xD.1505_12 = V_MAY_DEF xD.1505_11;
__asm__ __volatile__(movb %b1,1(%2); movb %h1,(%2):=m xD.1505:r yD.1507,
r xD.1505);
return (intD.0) (yD.1507 ^ 1) 1;
# SUCC: EXIT [100.0%]
}
which is wrong, it must reread xD.1505 instead of assuming xD.1505 == yD.1507.
--
Summary: asm =m not taken into account
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org,mikpe at csd dot uu dot
se
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20210
[Bug tree-optimization/20204] [4.0 regression] miscompilation of asm-declared registers
--- Additional Comments From hp at gcc dot gnu dot org 2005-02-25 15:35 --- In response to comment #6: Building a CRIS toolchain with simulator (but see further below): The general steps are exactly as any other simulator target, follow URL:http://gcc.gnu.org/simtest-howto.html, though you need the cris-sim.exp as per URL:http://gcc.gnu.org/ml/gcc-bugs/2005-02/msg00138.html (now in dejagnu CVS; not on sourceware). Because the baseboard file is not in the installed dir, special steps are necessary: mkdir ~/dejagnuboards Put cris-sim.exp in ~/dejagnurc echo 'set boards_dir ~/dejagnuboards' ~/.dejagnurc Then proceed as per simtest-howto.html But you actually just need to build cc1 and observe the assembly I posted. And again, I think I need to point out that a bug in handling of *asm-declared registers* is unlikely to show widespread carnage. But I certainly see how it can be overlooked and broken in tree-ssa cleanup operations! I have not tried reverting the patch but will do later, hoping it can convince you that the reorganization caused this regression (whether directly or indirectly exposing bugs elsewhere). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20204
[Bug tree-optimization/20188] [4.0 Regression] asm and memory operands does not add a V_MAY_DEF
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-25 15:35 --- *** Bug 20210 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||jakub at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20188
[Bug tree-optimization/20210] asm =m not taken into account
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-25 15:35 --- This is a dup of bug 20188 which I am testing a patch for already. *** This bug has been marked as a duplicate of 20188 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20210
[Bug c++/20207] null constructor not needed in multiple inheritance
--- Additional Comments From Serge dot Iovleff at univ-lille1 dot fr 2005-02-25 15:43 --- (In reply to comment #1) I think this is invalid code but I don't know how to produce it right now. Yes you can add an explicit call to the constructor of A0 in B and C, in this case the error deseappear. hovewer, as B and C are abstract virtual class, this constructor should never be called by these class, but only by the derived class, like D. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20207
[Bug target/16350] gcc only understands little endian ARM systems
--- Additional Comments From vapier at gentoo dot org 2005-02-25 15:49 --- this also applies pretty nicely to 3.3.5, 3.4.2, 3.4.3, and even gcc cvs HEAD :( one question though ... going by config/arm/arm.h, wouldnt you want to use this logic instead ? #if TARGET_BIG_ENDIAN_DEFAULT #define TARGET_ENDIAN_DEFAULT ARM_FLAG_BIG_END #else #define TARGET_ENDIAN_DEFAULT -ARM_FLAG_BIG_END #endif granted i havent fully tested this change from '0' to '-ARM_FLAG_BIG_END', but it *seems* to work :) also, what do we have to do in order to get this into mainline gcc ? this simple patch has been hanging around for a while :/ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16350
[Bug tree-optimization/20204] [4.0 regression] miscompilation of asm-declared registers
--- Additional Comments From hp at gcc dot gnu dot org 2005-02-25 15:59 --- I was lucky enough to have a source tree from just before the suspected change in the machine where I test using geoffk's script. (It's a RH9 machine as opposed to FC2, so thus we can supposedly also rule out miscompilation by the host gcc.) I have updated just the suspected change. Test in progress. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20204
signed enum bug
[My first time at reporting, so please bear with me if I do something wrong...] The compiler outputs a bg branch instruction when it should use a bgu. The cause seems to be related to having a negative value in the enumeration. If I just comment out the DummyValue1 line, the code is correct. It does this at any optimization level of 1 or higher, and I haven't figured out if there is a specific optimization I can turn off as a work around. add %o0, -2, %o0 cmp %o0, 1 .stabn 68,0,13,.LLM3-_Z13DummyFunction10tTestEnum2 .LLM3: .stabn 68,0,15,.LLM4-_Z13DummyFunction10tTestEnum2 .LLM4: bg .LL2 mov 0, %o0 .stabn 68,0,16,.LLM5-_Z13DummyFunction10tTestEnum2 .LLM5: mov 2, %o0 .LL2: .LLBE3: .LLBE2: retl nop Thanks, Aaron Coleman Software Engineering Manager Lowrance Electronics, Inc. 12000 E Skelly Dr. Tulsa, OK 74128 918-437-6881 x8551 test.ii Description: test.ii Reading specs from /compilers/sparc-elf/lib/gcc/sparc-elf/3.4.0/specs Configured with: /gcc_src/gcc-3.4-20040317/configure --prefix=/compilers/sparc-elf --target=sparc-elf --enable-languages=c++ --with-newlib --enable-clocale=generic --enable-cxx-flags=-fno-exceptions --disable-hosted-libstdcxx Thread model: single gcc version 3.4.0 20040317 (prerelease) /compilers/sparc-elf/libexec/gcc/sparc-elf/3.4.0/cc1plus.exe -E -quiet -v -D__sparc_v8__ -D__sparc_v8__ test.cpp -mcpu=v8 -mcpu=v8 -mtune=v8 -mv8 -m32 -Werror -Wall -fworking-directory -O1 -o test.ii ignoring nonexistent directory /compilers/sparc-elf/lib/gcc/sparc-elf/3.4.0/../../../../include/c++/3.4.0/backward ignoring nonexistent directory /compilers/sparc-elf/lib/gcc/sparc-elf/3.4.0/../../../../sparc-elf/sys-include #include ... search starts here: #include ... search starts here: /compilers/sparc-elf/lib/gcc/sparc-elf/3.4.0/../../../../include/c++/3.4.0 /compilers/sparc-elf/lib/gcc/sparc-elf/3.4.0/../../../../include/c++/3.4.0/sparc-elf /compilers/sparc-elf/lib/gcc/sparc-elf/3.4.0/include /compilers/sparc-elf/lib/gcc/sparc-elf/3.4.0/../../../../sparc-elf/include End of search list. /compilers/sparc-elf/libexec/gcc/sparc-elf/3.4.0/cc1plus.exe -fpreprocessed test.ii -mcpu=v8 -quiet -dumpbase test.cpp -mcpu=v8 -mtune=v8 -mv8 -m32 -auxbase-strip test.o -g -O1 -Werror -Wall -version -o test.s GNU C++ version 3.4.0 20040317 (prerelease) (sparc-elf) compiled by GNU C version 3.3.1 (cygming special). GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 /compilers/sparc-elf/lib/gcc/sparc-elf/3.4.0/../../../../sparc-elf/bin/as.exe -V -Qy -s -o test.o test.s GNU assembler version 040202 (sparc-elf) using BFD version 040202 20040202
[Bug tree-optimization/20204] [4.0 regression] miscompilation of asm-declared registers
--- Additional Comments From hp at gcc dot gnu dot org 2005-02-25 16:05 --- I've confirmed on this other machine that the update caused the same breakage. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-02-25 16:05:49 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20204
[Bug other/17652] [meta-bug] GCC 4.1 pending patches
-- What|Removed |Added BugsThisDependsOn||20211 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17652
[Bug rtl-optimization/20211] New: autoincrement generation is poor
When a processor does not allow register+offset addressing for a register class, as for the floating point registers on the SH3E / SH4, the way to avoid excessive reloads and to expose the issue to the rtl optimizers is to disallow this addressing mode for the machine modes for which pseudo registers are usually allocated to the register class in question, i.e. SFmode / DFmode in our example. Thus, when there is a structure access to a member with such a mode and a non-zero offset, the address cannot be expressed directly, and thus, during rtl expansion, the sum is calculated into a pseudo register first. cse typically places these additions together at the start of a basic block; the idea there is that we might find some cse opportunities, and if not, combine can do something with these sums. However, that doesn't work when these sums are used as addresses and the machine mode of the access does not allow reg+offset addressing. The auto-increment generation is flow can't do anything useful with these sums either, since the auto-inc generation in flow only looks for cases where a memory access already matches an exitsing add. Thus we end up with lots of adds and sky-high register pressure. On two-address machines, there i an added problem that the adds are so arranged that (at least, not counting reloads...) a two-instruction sequence is needed to do the additions. What is required is an optimization pass that finds all the uses of a sum of a base register and an offset in a basic block, and figures out where an auto-increment addressing mode can be profitably used, and also to reduce the register pressure and number of reg-reg copies. A patch against 4.0 20050218 is here: http://gcc.gnu.org/ml/gcc-patches/2005-02/msg01612.html -- Summary: autoincrement generation is poor Product: gcc Version: 2.95 Status: UNCONFIRMED Keywords: missed-optimization, patch Severity: enhancement Priority: P2 Component: rtl-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: amylaar at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org OtherBugsDependingO 17652 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20211
Re: signed enum bug
The compiler outputs a bg branch instruction when it should use a bgu. The cause seems to be related to having a negative value in the enumeration. Fixed in 3.4.4pre: _Z13DummyFunction10tTestEnum2: .LLFB2: !#PROLOGUE# 0 !#PROLOGUE# 1 add %o0, -2, %o0 cmp %o0, 1 bgu .LL2 mov 0, %g1 mov 2, %g1 .LL2: retl mov %g1, %o0 .LLFE2: .size _Z13DummyFunction10tTestEnum2, .-_Z13DummyFunction10tTestEnum2 .ident GCC: (GNU) 3.4.4 20050224 (prerelease) -- Eric Botcazou
[Bug tree-optimization/19938] Missed jump threading opportunity due to signedness difference
--- Additional Comments From kazu at cs dot umass dot edu 2005-02-25 16:29 --- Yes, this is fixed. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19938
[Bug middle-end/19721] [meta-bug] optimizations that CSE still catches
-- Bug 19721 depends on bug 19938, which changed state. Bug 19938 Summary: Missed jump threading opportunity due to signedness difference http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19938 What|Old Value |New Value Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19721
[Bug tree-optimization/19794] [meta-bug] Jump threading related bugs
-- Bug 19794 depends on bug 19938, which changed state. Bug 19938 Summary: Missed jump threading opportunity due to signedness difference http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19938 What|Old Value |New Value Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19794
[Bug c++/20209] [3.3/3.4/4.0 Regression] Missing warnings for aggregate has a partly bracketed initializer
--- Additional Comments From jakub at gcc dot gnu dot org 2005-02-25 16:38
---
Yeah, caused by addition of reshape_init.
Bigger testcase:
// PR c++/20209
// { dg-do compile }
// { dg-options -Wmissing-braces }
struct S { char a[6]; int b[2]; };
struct T { int a; int b[2]; };
struct U { int a; T b; };
struct V { char a[6]; int b[2]; int c; };
struct W { int a; int b[2]; int c; };
struct X { int a; W b; int c; };
S a = { { hello }, { 1, 2 } };
S b = { { hello }, 1, 2 };// { dg-warning }
S c = { hello, { 1, 2 } };
S d = { hello, 1, 2 };// { dg-warning }
T e = { 1, { 2, 3 } };
T f = { 1, 2, 3 }; // { dg-warning }
U g = { 1, { 2, { 3, 4 } } };
U h = { 1, 2, { 3, 4 } }; // { dg-warning }
U i = { 1, 2, 3, 4 }; // { dg-warning }
V j = { { hello }, { 1, 2 }, 3 };
V k = { { hello }, 1, 2, 3 }; // { dg-warning }
V l = { hello, { 1, 2 }, 3 };
V m = { hello, 1, 2, 3 }; // { dg-warning }
W n = { 1, { 2, 3 }, 4 };
W o = { 1, 2, 3, 4 }; // { dg-warning }
X p = { 1, { 2, { 3, 4 }, 5 }, 6 };
X q = { 1, 2, { 3, 4 }, 5, 6 }; // { dg-warning }
X r = { 1, 2, 3, 4, 5, 6 }; // { dg-warning }
--
What|Removed |Added
CC||mark at codesourcery dot com
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Last reconfirmed|-00-00 00:00:00 |2005-02-25 16:38:03
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20209
[Bug target/19019] GCC ldouble format incompatibility with XLC long double
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-02-25 16:42 --- Subject: Bug 19019 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-3_4-branch Changes by: [EMAIL PROTECTED] 2005-02-25 16:42:01 Modified files: gcc: ChangeLog reload.c gcc/config/rs6000: rs6000.md Log message: Backport from mainline: 2005-02-24 David Edelsohn [EMAIL PROTECTED] PR target/19019 * reload.c (operands_match_p): Only increment register number for SCALAR_INT_MODE_P modes in multiple hard registers. * config/rs6000/rs6000.md (trunctfdf2): Remove register constraints. Fix formatting. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=2.2326.2.805r2=2.2326.2.806 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/reload.c.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=1.229.4.7r2=1.229.4.8 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/rs6000/rs6000.md.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=1.284.4.16r2=1.284.4.17 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19019
[Bug tree-optimization/17863] [4.0 Regression] threefold performance loss, not inlining as much
--- Additional Comments From giovannibajo at libero dot it 2005-02-25 16:43 --- Why isn't this a critical regression? We're regressing *badly* on code generation. -- What|Removed |Added Severity|normal |critical http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17863
[Bug tree-optimization/20204] [4.0 regression] miscompilation of asm-declared registers
--- Additional Comments From dnovillo at gcc dot gnu dot org 2005-02-25 16:48 --- (In reply to comment #9) I've confirmed on this other machine that the update caused the same breakage. Ah, yes. I see it now. The reorg tickled a bug in the renamer: # n_21 = V_MUST_DEF n_18 n = D.1158_28 ... n_48 = PHI n_37, n21 L2: ... # VUSE n_21 n.5_40 = n; That's wrong. The last VUSE should be VUSE n_48. Virtual operands should always be in FUD-chain form. Working on a fix. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dnovillo at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20204
[Bug libgcj/20160] [4.0 Regression] link errors building libgcj tests
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-02-25 16:53 --- Hard-linking is an option, although we can't rely on hard-links being available. Soft-linking would require even more pathname tweaking, it's just not worth it. Anyhow, thanks for testing, I see what the problem is, and I'll have a new patch for you soon. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20160
[Bug tree-optimization/14703] Inadequate optimization of inline templated functions
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-02-25 16:53 --- http://gcc.gnu.org/ml/gcc-patches/2005-02/msg01571.html improves this to the extent that the inliner now estimates the size of fibconst to nsize 0,1,2 0 31 42 54 67 etc., i.e. to the number of additions required. Inlining all of fibconst90 now only requires the appropriate limits, or, of course folding during inlining. -- What|Removed |Added CC||rguenth at tat dot physik ||dot uni-tuebingen dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14703
[Bug tree-optimization/17863] [4.0 Regression] threefold performance loss, not inlining as much
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-02-25 16:56 --- Yes, the regression is even worse on the closed-duplicate #18704. There you can also find some analysis of inline parameter tuning. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17863
[Bug tree-optimization/19937] [4.0 regression] Wrong loop exit (causes binutils to fail)
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-02-25 16:58 --- Subject: Bug 19937 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-02-25 16:56:28 Modified files: gcc: ChangeLog tree-ssa-loop-ivopts.c Log message: PR tree-optimization/19937 * tree-ssa-loop-ivopts.c (rewrite_use_compare): Cast the final value to the type of the induction variable. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=2.7592r2=2.7592.2.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-ssa-loop-ivopts.c.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=2.49r2=2.49.2.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19937
[Bug tree-optimization/19937] [4.0 regression] Wrong loop exit (causes binutils to fail)
--- Additional Comments From rakdver at gcc dot gnu dot org 2005-02-25 17:04 --- Also in 4.0. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19937
[Bug tree-optimization/19938] Missed jump threading opportunity due to signedness difference
-- Bug 19938 depends on bug 19937, which changed state. Bug 19937 Summary: [4.0 regression] Wrong loop exit (causes binutils to fail) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19937 What|Old Value |New Value Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19938
[Bug c++/20212] New: attribute unused vs. member function template
Works with: 3.4.2 Fails with: 4.0.0 For some reason, the attached output warns (oddly) with the attached code: %COMP.sh -g -O2 -Wunused -Wextra debug.ii /mnt/hd/src/gcc/libstdc++-v3/src/debug.cc: In instantiation of 'void __gnu_debug::_Error_formatter::_M_format_word(char*, int, const char*, _Tp) const [with _Tp = const void*]': /mnt/hd/src/gcc/libstdc++-v3/src/debug.cc:274: instantiated from here /mnt/hd/bld/gcc.disable-c99/i686-pc-linux-gnu/libstdc++-v3/include/debug/formatter.h:363: warning: unused parameter '__n' /mnt/hd/src/gcc/libstdc++-v3/src/debug.cc: In instantiation of 'void __gnu_debug::_Error_formatter::_M_format_word(char*, int, const char*, _Tp) const [with _Tp = const char*]': /mnt/hd/src/gcc/libstdc++-v3/src/debug.cc:383: instantiated from here /mnt/hd/bld/gcc.disable-c99/i686-pc-linux-gnu/libstdc++-v3/include/debug/formatter.h:363: warning: unused parameter '__n' /mnt/hd/src/gcc/libstdc++-v3/src/debug.cc: In instantiation of 'void __gnu_debug::_Error_formatter::_M_format_word(char*, int, const char*, _Tp) const [with _Tp = unsigned int]': /mnt/hd/src/gcc/libstdc++-v3/src/debug.cc:473: instantiated from here /mnt/hd/bld/gcc.disable-c99/i686-pc-linux-gnu/libstdc++-v3/include/debug/formatter.h:363: warning: unused parameter '__n' /usr/bin/ld: cannot find -lv3test collect2: ld returned 1 exit status I believe this code to be fine (indeed, with 3.4.x I have no warning.) I tried to reduce this down but didn't hit anything with the obvious reduction. So, I file this instead. -benjamin -- Summary: attribute unused vs. member function template Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bkoz at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20212
[Bug c++/20212] attribute unused vs. member function template
--- Additional Comments From bkoz at gcc dot gnu dot org 2005-02-25 18:15 --- Created an attachment (id=8283) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8283action=view) pre-processed file, bzip2 compressed -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20212
[Bug tree-optimization/19938] Missed jump threading opportunity due to signedness difference
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-25 18:38 --- And in 4.0 also. -- What|Removed |Added Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19938
[Bug c++/20212] [4.0 Regression] attribute unused vs. member function template
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-25 18:41 --- I will try to reduce this later today. -- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Keywords||diagnostic Summary|attribute unused vs. member |[4.0 Regression] attribute |function template |unused vs. member function ||template http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20212
[Bug rtl-optimization/20211] autoincrement generation is poor
-- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20211
[Bug rtl-optimization/20211] autoincrement generation is poor
--- Additional Comments From giovannibajo at libero dot it 2005-02-25 18:59 --- What is the compile-time impact of this patch on cc-i compilation, the usual C++ testcases, and SPEC? I am sure this is something worthwile to mention for a review. And BTW, out of curiosity, does the new pass have to live in regmove.c? -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-02-25 18:59:53 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20211
[Bug c++/20212] [4.0 Regression] attribute unused vs. member function template
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-25
19:00 ---
Actually I figured out an obvious way to reduce it after looking at the error
message and seeing that the
unused parameter was pointing to the prototype of the function:
templateint void f(int);
void g(int i)
{
f0(i);
}
templateint void f(int i __attribute__((unused)) )
{}
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Known to fail||4.0.0
Known to work||3.4.0
Last reconfirmed|-00-00 00:00:00 |2005-02-25 19:00:48
date||
Target Milestone|--- |4.0.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20212
[Bug libstdc++/20213] New: cassert header documentation wrong
The cassert header states: * This is the C++ version of the Standard C Library header @c assert.h, * and its contents are (mostly) the same as that header, but are all * contained in the namespace @c std. However, this bug report http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15771 indicates that the assert macro is (and should be) in the global namespace, not in std. -- Summary: cassert header documentation wrong Product: gcc Version: 3.3.5 Status: UNCONFIRMED Severity: normal Priority: P2 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: fmhess at users dot sourceforge dot net CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20213
[Bug target/20214] New: [3.3/3.4/4.0 Regression] ICE with register name which is not a register in x86
The following invalid x86 code ICEs on the mainline and has since at least
3.2.3:
int main()
{
register void *return_dst __asm__ (r13);
return *(int*)(return_dst);
}
--
Summary: [3.3/3.4/4.0 Regression] ICE with register name which is
not a register in x86
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code
Severity: minor
Priority: P2
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20214
[Bug target/20214] [3.3/3.4/4.0 Regression] ICE with register name which is not a register in x86
-- What|Removed |Added Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20214
[Bug target/20214] [3.3/3.4/4.0 Regression] ICE with register name which is not a register in x86
-- What|Removed |Added Known to fail||4.0.0 3.3.3 3.2.3 3.4.0 Known to work||3.0.4 2.95.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20214
[Bug java/20215] New: gcj does not accept classes with same name fields
According to the JVM spec, class files can have several fields with the same name. As long as they have different types, they will be distinguished since all field operations specify both the name and the field of the field. Sun's JVM accepts such classes, and correctly distinguishes the fields, as you can see in the attached testcase. Here is the disassembly of this class: Access flags: 0x20 super This class: 2=DuplicateField, super: 4=java.lang.Object Interfaces (count: 0): Fields (count: 2): Field name:foo static Signature: 6=java.lang.String Field name:foo static Signature: 7=int Methods (count: 3): Method name:init Signature: 9=()void Attribute Code, length:17, max_stack:1, max_locals:1, code_length:5 0: aload_0 1: invokespecial #11=Method java.lang.Object.init ()void 4: return Method name:main public static Signature: 14=(java.lang.String[])void Attribute Code, length:31, max_stack:2, max_locals:1, code_length:19 0: getstatic #20=Field java.lang.System.out java.io.PrintStream 3: getstatic #22=Field DuplicateField.foo java.lang.String 6: invokevirtual #28=Method java.io.PrintStream.println (java.lang.String)void 9: getstatic #20=Field java.lang.System.out java.io.PrintStream 12: getstatic #30=Field DuplicateField.foo int 15: invokevirtual #33=Method java.io.PrintStream.println (int)void 18: return Method name:clinit static Signature: 9=()void Attribute Code, length:24, max_stack:1, max_locals:0, code_length:12 0: ldc #36=String WOW 2: putstatic #22=Field DuplicateField.foo java.lang.String 5: sipush 42 8: putstatic #30=Field DuplicateField.foo int 11: return Sun's JVM correctly executes that program: $ java DuplicateField WOW 42 gcj fails during compilation with: $ gcj DuplicateField.class DuplicateField.java: In class 'DuplicateField': DuplicateField.java: In method 'DuplicateField.main(java.lang.String[])': DuplicateField.java:0: error: mismatching signature for field 'foo' in 'DuplicateField' DuplicateField.java: In method 'DuplicateField.clinit()': DuplicateField.java:0: error: mismatching signature for field 'foo' in 'DuplicateField' Surprisingly, gij also fails with: Exception in thread main java.lang.NullPointerException at java.io.PrintStream.println(java.lang.String) (/tmp/gcc/lib/libgcj.so.6.0.0) at DuplicateField.main(java.lang.String[]) (Unknown Source) at gnu.java.lang.MainThread.call_main() (/tmp/gcc/lib/libgcj.so.6.0.0) at gnu.java.lang.MainThread.run() (/tmp/gcc/lib/libgcj.so.6.0.0) gcj (GCC) 4.0.0 20050223 -- Summary: gcj does not accept classes with same name fields Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bonniot at users dot sf dot net CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20215
[Bug target/20214] [3.3/3.4/4.0 Regression] ICE with register name which is not a register in x86
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-25 19:49 --- By the way here is the ICE: t4.c: In function main: t4.c:5: internal compiler error: in print_reg, at config/i386/i386.c:6241 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20214
[Bug java/20215] gcj does not accept classes with same name fields
--- Additional Comments From bonniot at users dot sf dot net 2005-02-25 19:50 --- Created an attachment (id=8285) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8285action=view) Testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20215
[Bug libfortran/17992] reading empty line does not return 0
--- Additional Comments From coudert at clipper dot ens dot fr 2005-02-25 19:50 --- I'm no language lawyer, but this works (returns two zeros and no error) for Sun, PGF, IBM, MIPSpro and Intel compilers. I think this should be considered as a bug (I confirm it is still present in CVS). -- What|Removed |Added CC||coudert at clipper dot ens ||dot fr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17992
[Bug middle-end/19956] [4.0/4.1 Regression] ICE copy_tree_r, at tree-inline.c:2320 on simple Ada code
--- Additional Comments From laurent at guerby dot net 2005-02-25 20:42 --- Someone who has more knowlege about the gimplifier and PLACEHOLDER_EXPRs should look into this Richard, any idea? This is not ACATS but has been reported to affect real Ada code. -- What|Removed |Added CC||kenner at vlsi1 dot ultra ||dot nyu dot edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19956
[Bug middle-end/19956] [4.0/4.1 Regression] ICE copy_tree_r, at tree-inline.c:2320 on simple Ada code
--- Additional Comments From kenner at vlsi1 dot ultra dot nyu dot edu 2005-02-25 20:44 --- Subject: Re: [4.0/4.1 Regression] ICE copy_tree_r, at tree-inline.c:2320 on simple Ada code Richard, any idea? This is not ACATS but has been reported to affect real Ada code. Not yet. I'm caught deep in the bowels of PR19900 right now ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19956
[Bug tree-optimization/20204] [4.0/4.1 regression] miscompilation of asm-declared registers
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-02-25 21:10 --- Subject: Bug 20204 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-02-25 21:10:30 Modified files: gcc: ChangeLog tree-into-ssa.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/gcc.dg: pr20204.c Log message: PR tree-optimization/20204 * tree-into-ssa.c (insert_phi_nodes_for): Do not use REWRITE_THIS_STMT markers on PHI nodes. (rewrite_initialize_block): Likewise. testsuite/ChangeLog PR tree-optimization/20204 * testsuite/gcc.dg/pr20204.c: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=2.7592.2.2r2=2.7592.2.3 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-into-ssa.c.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=2.41r2=2.41.2.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.5084r2=1.5084.2.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/pr20204.c.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=NONEr2=1.1.2.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20204
[Bug tree-optimization/20204] [4.0/4.1 regression] miscompilation of asm-declared registers
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-02-25 21:12 --- Subject: Bug 20204 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-02-25 21:12:34 Modified files: gcc: ChangeLog tree-into-ssa.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/gcc.dg: pr20204.c Log message: PR tree-optimization/20204 * tree-into-ssa.c (insert_phi_nodes_for): Do not use REWRITE_THIS_STMT markers on PHI nodes. (rewrite_initialize_block): Likewise. testsuite/ChangeLog PR tree-optimization/20204 * testsuite/gcc.dg/pr20204.c: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.7596r2=2.7597 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-into-ssa.c.diff?cvsroot=gccr1=2.41r2=2.42 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.5084r2=1.5085 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/pr20204.c.diff?cvsroot=gccr1=1.1r2=1.2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20204
[Bug tree-optimization/20204] [4.0/4.1 regression] miscompilation of asm-declared registers
--- Additional Comments From dnovillo at gcc dot gnu dot org 2005-02-25 21:18 --- Fixed. http://gcc.gnu.org/ml/gcc-patches/2005-02/msg01625.html -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20204
[Bug tree-optimization/20204] [4.0/4.1 regression] miscompilation of asm-declared registers
-- What|Removed |Added Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20204
[Bug tree-optimization/20204] [4.0/4.1 regression] miscompilation of asm-declared registers
-- What|Removed |Added Target Milestone|4.1.0 |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20204
[Bug preprocessor/20183] -D option handling doesn't account for character sets
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-25 21:25 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-02-25 21:25:58 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20183
[Bug tree-optimization/20216] New: Simple loop runs out of stack at -O1
Following test case runs out of stack space when
gcc tries to compute factorial (159). I have a patch which does two simple
things. 1) it rewrites
tree_fold_factorial
function into its non-recursive version, and 2) it sets a limit before deciding
to call chrec_evaluate. This
limit is arbitrary in this
patch. Author of the algorithm may want to decide when to stop evaluating
feasibility of this
optimization. Note that even with this limit,
the computed factorial overflows. So, even a much smaller limit is needed if
this value is significant.
/* bad.c */
static unsigned int *buffer;
void FUNC (void)
{
unsigned int *base;
int i, j;
for (i = 0; i 4; i++)
for (j = 0; j 160; j++)
*base++ = buffer[j];
}
% mygccm5 -c -O1 bad.c
Out of stack space.
Try running 'limit stacksize unlimited' in the shell to raise its limit.
--
Summary: Simple loop runs out of stack at -O1
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fjahanian at apple dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: powerpc-apple-darwin
GCC host triplet: powerpc-apple-darwin
GCC target triplet: powerpc-apple-darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20216
[Bug tree-optimization/20216] [4.0/4.1 Regression] Simple loop runs out of stack at -O1
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-25 21:30 --- Confirmed. -- What|Removed |Added Keywords||compile-time-hog, memory-hog Summary|Simple loop runs out of |[4.0/4.1 Regression] Simple |stack at -O1|loop runs out of stack at - ||O1 Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20216
[Bug tree-optimization/20216] [4.0/4.1 Regression] Simple loop runs out of stack at -O1
--- Additional Comments From fjahanian at apple dot com 2005-02-25 21:32 --- Created an attachment (id=8286) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8286action=view) A proposed patch to fix this Note that patch I attached is against the apple-ppc-branch. So, it may not apply to the mainline as is. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20216
[Bug target/19930] gcc.dg/pr19402-2.c fails on ia64-hpux
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-02-25 21:34 --- Subject: Bug 19930 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-02-25 21:34:49 Modified files: gcc: ChangeLog libgcc2.h libgcc2.c gcc/doc: tm.texi gcc/config/ia64: t-ia64 lib1funcs.asm hpux.h Log message: PR target/19930 * doc/tm.texi (LIBGCC2_LONG_DOUBLE_TYPE_SIZE): Document. (LIBGCC2_HAS_DF_MODE): New. (LIBGCC2_HAS_XF_MODE): New. (LIBGCC2_HAS_TF_MODE): New. * libgcc2.h (LIBGCC2_HAS_XF_MODE): New name for HAVE_XFMODE. (LIBGCC2_HAS_TF_MODE): New name for HAVE_TFMODE. * libgcc2.c (LIBGCC2_HAS_XF_MODE): New name for HAVE_XFMODE. (LIBGCC2_HAS_TF_MODE): New name for HAVE_TFMODE. (LIBGCC2_HAS_DF_MODE): New name for HAVE_DFMODE. * config/ia64/t-ia64 (LIB1ASMFUNCS): Remove __compat and add _fixtfdi, _fixunstfdi, _floatditf * lib1funcs.asm: Remove L__compat. Add L_fixtfdi, L_fixunstfdi, L_floatditf. * config/ia64/hpux.h (LIBGCC2_HAS_XF_MODE): Define. (LIBGCC2_HAS_TF_MODE): Define. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.7597r2=2.7598 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/libgcc2.h.diff?cvsroot=gccr1=1.37r2=1.38 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/libgcc2.c.diff?cvsroot=gccr1=1.185r2=1.186 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/doc/tm.texi.diff?cvsroot=gccr1=1.414r2=1.415 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/ia64/t-ia64.diff?cvsroot=gccr1=1.22r2=1.23 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/ia64/lib1funcs.asm.diff?cvsroot=gccr1=1.16r2=1.17 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/ia64/hpux.h.diff?cvsroot=gccr1=1.47r2=1.48 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19930
[Bug tree-optimization/20216] [4.0/4.1 Regression] Simple loop runs out of stack at -O1
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-25 21:36 --- (In reply to comment #2) Note that patch I attached is against the apple-ppc-branch. So, it may not apply to the mainline as is. It looks like it should from my updated sources. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-02-25 21:36:07 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20216
[Bug c/20217] New: Switching off the optimization triggers undefined reference at link time when building Linux kernel.
1. the exact version of GCC; % gcc -v Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.2.3/specs Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --with-system-zlib --enable-__cxa_atexit --host=i386-redhat-linux Thread model: posix gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-49) 2. the system type; % uname -a Linux engst3lux.afceng.afc.local 2.4.21-27.0.1.EL #1 Mon Dec 20 18:56:53 EST 2004 i686 i686 i386 GNU/Linux 3. the options given when GCC was configured/built; Please see #1. 4. the complete command line that triggers the bug; Please see the description below. 5. the compiler output (error messages, warnings, etc.) Please see the description below. 6. the preprocessed file (*.i*) Out of scope. DESCRIPTION. Summary: Building the Linux kernel with -O2 ends successfully. Building the Linux kernel with -O0 or no optimization flags breaks at final link with undefined symbols. Detail: I got this problem when building a Linux kernel without optimization for debug purpose on an embedded target. I retested on my host (#2) which is a Dell PC with preinstalled RedHat Entreprise Linux (#1). I tested building the Linux kernel 2.6.6, 2.6.8 and 2.6.10. The behavior is present with all these distributions. I think is a Gcc problem because depends of the presence/absence of the -O[0|1|2|3|s] flags. The undefined symbols are the whole family of network conversion macros: htonl, htons, To get the faulty behaviour: 1. Get a Linux kernel distribution (2.6.10 by example) 2. Install it 3. cd in linux-2-6-10 4. do a make defconfig 5. edit the Makefile 6. look for the line: ifdef CONFIG_CC_OPTIMIZE_FOR_SIZE 7. change the third line beneath from: CFLAGS += -O2 to: CFLAGS += -O0 (uppercase o zero) 8. do a make 21 | tee make.log 9. the final link phase fails with undefined symbols: Extract from output: ld -m elf_i386 -r -o init/built-in.o init/main.o init/version.o init/mounts.o init/initramfs.o ld -m elf_i386 -T arch/i386/kernel/vmlinux.lds.s arch/i386/kernel/head.o arch/i386/kernel/init_task.o init/built-in.o --start-group usr/built-in.o arch/i386/kernel/built-in.o arch/i386/mm/built-in.o arch/i386/ mach-default/built-in.o arch/i386/crypto/built-in.o kernel/built-in.o mm/built-in.o fs/built-in.o ipc/built -in.o security/built-in.o crypto/built-in.o lib/lib.a arch/i386/lib/lib.a lib/built-in.o arch/i386/lib/bui lt-in.o drivers/built-in.o sound/built-in.o arch/i386/pci/built-in.o arch/i386/oprofile/built-in.o arch/i38 6/power/built-in.o net/built-in.o --end-group -o .tmp_vmlinux1 fs/built-in.o(.text+0xa0969): In function `ext3_get_dev_journal': : undefined reference to `ntohl' fs/built-in.o(.text+0xa0980): In function `ext3_get_dev_journal': : undefined reference to `ntohl' -- Summary: Switching off the optimization triggers undefined reference at link time when building Linux kernel. Product: gcc Version: 3.2.3 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: stiriac at oddpost dot com CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20217
[Bug middle-end/20217] Switching off the optimization triggers undefined reference at link time when building Linux kernel.
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-25 22:08 --- Are you sure that this is a GCC bug, IIRC the linux kernel uses extern inline. -- What|Removed |Added Component|c |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20217
[Bug target/19930] gcc.dg/pr19402-2.c fails on ia64-hpux
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-02-25 22:22 --- Subject: Bug 19930 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-02-25 22:22:45 Modified files: gcc: ChangeLog libgcc2.c libgcc2.h gcc/doc: tm.texi gcc/config/ia64: t-ia64 lib1funcs.asm hpux.h Log message: PR target/19930 * doc/tm.texi (LIBGCC2_LONG_DOUBLE_TYPE_SIZE): Document. (LIBGCC2_HAS_DF_MODE): New. (LIBGCC2_HAS_XF_MODE): New. (LIBGCC2_HAS_TF_MODE): New. * libgcc2.h (LIBGCC2_HAS_XF_MODE): New name for HAVE_XFMODE. (LIBGCC2_HAS_TF_MODE): New name for HAVE_TFMODE. * libgcc2.c (LIBGCC2_HAS_XF_MODE): New name for HAVE_XFMODE. (LIBGCC2_HAS_TF_MODE): New name for HAVE_TFMODE. (LIBGCC2_HAS_DF_MODE): New name for HAVE_DFMODE. * config/ia64/t-ia64 (LIB1ASMFUNCS): Remove __compat and add _fixtfdi, _fixunstfdi, _floatditf * lib1funcs.asm: Remove L__compat. Add L_fixtfdi, L_fixunstfdi, L_floatditf. * config/ia64/hpux.h (LIBGCC2_HAS_XF_MODE): Define. (LIBGCC2_HAS_TF_MODE): Define. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=2.7592.2.3r2=2.7592.2.4 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/libgcc2.c.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.185r2=1.185.2.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/libgcc2.h.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.37r2=1.37.2.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/doc/tm.texi.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.414r2=1.414.2.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/ia64/t-ia64.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.22r2=1.22.42.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/ia64/lib1funcs.asm.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.16r2=1.16.70.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/ia64/hpux.h.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.47r2=1.47.2.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19930
[Bug target/19930] gcc.dg/pr19402-2.c fails on ia64-hpux
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-25 22:27 --- Fixed. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19930
[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations
--- Additional Comments From bkoz at gcc dot gnu dot org 2005-02-25 22:40
---
Personally, I think the better approach for the libstdc++ parts is to allow
__attribute__ visibility on namespace declarations.
That way, all this goo could be removed, and centralized in one place. Ie,
c++config.h could have something like:
namespace std __attribute__ ((visibility (default) ));
{
}
And volia! We are done.
(When I first saw this, I thought that the solution being proposed was mass
decoration of std:: names with some kind of pseudo-__declspec bullshit. Of
course, that is a non-starter, so I'm glad to see the thinking has evolved a
bit.)
-benjamin
--
What|Removed |Added
CC||bkoz at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
[Bug middle-end/20217] Switching off the optimization triggers undefined reference at link time when building Linux kernel.
--- Additional Comments From stiriac at oddpost dot com 2005-02-25 22:48 --- (In reply to comment #1) Are you sure that this is a GCC bug, IIRC the linux kernel uses extern inline. How to judge ? I do change nothing to the Linux kernel but I change a compilation flag and I get undefined symbols at link. The compiler does not signal any error even a warning. I'm not a Gcc expert but the common sense tells me is someting the compiler should report as error or warning before reaching the link phase. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20217
[Bug middle-end/20217] Switching off the optimization triggers undefined reference at link time when building Linux kernel.
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-25 22:51 --- You ask a linux kernel person :) or you read the source to make sure that all extern inline functions have a corresponding normal definition. -- What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20217
[Bug middle-end/20218] Can't use __attribute__ ((visibility (hidden))) to hide a symbol
--- Additional Comments From hjl at lucon dot org 2005-02-25 23:02 --- Created an attachment (id=8287) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8287action=view) A testcase On ia32 [EMAIL PROTECTED] hidden]$ make gcc -O -g -c -o main.o main.c gcc -O -g -fPIC -c -o foo1.o foo1.c gcc -O -g -fPIC -c -o bar.o bar.c gcc -O -g -fPIC -c -o foo2.o foo2.c ar rcs libfoo.a foo2.o gcc -o libbar.so -shared bar.o libfoo.a gcc -o main main.o foo1.o libbar.so -Wl,-rpath,. ./main make: *** [all] Error 1 On x86_64 with the older linker: gcc -B/usr/bin/ -O -g -c -o main.o main.c gcc -B/usr/bin/ -O -g -fPIC -c -o foo1.o foo1.c gcc -B/usr/bin/ -O -g -fPIC -c -o bar.o bar.c gcc -B/usr/bin/ -O -g -fPIC -c -o foo2.o foo2.c ar rcs libfoo.a foo2.o gcc -B/usr/bin/ -o libbar.so -shared bar.o libfoo.a gcc -B/usr/bin/ -o main main.o foo1.o libbar.so -Wl,-rpath,. ./main ./main: Symbol `foo' causes overflow in R_X86_64_PC32 relocation ./main: Symbol `bar' causes overflow in R_X86_64_PC32 relocation make: *** [all] Segmentation fault On x86_64 with the newer linker: gcc -O -g -c -o main.o main.c gcc -O -g -fPIC -c -o foo1.o foo1.c gcc -O -g -fPIC -c -o bar.o bar.c gcc -O -g -fPIC -c -o foo2.o foo2.c ar rcs libfoo.a foo2.o gcc -o libbar.so -shared bar.o libfoo.a /usr/local/bin/ld: bar.o: relocation R_X86_64_PC32 against `foo' can not be used when making a shared object; recompile with -fPIC /usr/local/bin/ld: final link failed: Bad value collect2: ld returned 1 exit status make: *** [libbar.so] Error 1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20218
[Bug middle-end/20218] Can't use __attribute__ ((visibility (hidden))) to hide a symbol
-- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20218
[Bug middle-end/20217] Switching off the optimization triggers undefined reference at link time when building Linux kernel.
--- Additional Comments From stiriac at oddpost dot com 2005-02-25 23:25 --- You mean this behavior is perfectly normal for the compiler ? This means the optimization flag plays somehow a redundant role with the options enabling/disabling error or warning messages ? I haven't seen anything like this in the Gcc doc, though I cannot say I learnt it by heart :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20217
[Bug rtl-optimization/20219] New: Missed optimisation sin / tan -- cos
GCC knows how to optimise tan * cos -- sin (fold-const line 7734) cos * tan -- sin sin / cos -- tan (fold-const line 8080) cos / sin -- 1.0 / tan (fold-const line 8094) but misses sin / tan -- cos tan / sin -- 1.0 / cos -- Summary: Missed optimisation sin / tan -- cos Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: rtl-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: christophe dot jaillet at wanadoo dot fr CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20219
[Bug target/20199] -fvisibility-inlines-hidden broken on powerpc64-linux
--- Additional Comments From janis at gcc dot gnu dot org 2005-02-25 23:53
---
Ah, yes. I haven't come up with a testcase that doesn't use libstdc++,
but the following testcase fails without the patch referenced in
comment #28 and passes with it:
#pragma GCC visibility push(default)
#include memory
#pragma GCC visibility pop
void foo()
{
std::allocatorchar c2;
}
Command line: g++ -m64 -fvisibility-inlines-hidden -shared -o libx.C x.C
Without the #pragmas, this works with 20050223 mainline and binutils
when char is replaced by int; there are explicit instantiations in
libstdc++ for allocatorchar but not for allocatorint. This is all
with -m64, with -m32 I haven't seen any problems at all.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20199
[Bug rtl-optimization/20219] Missed optimisation sin / tan -- cos
-- What|Removed |Added OtherBugsDependingO||19987 nThis|| Severity|normal |enhancement Keywords||missed-optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20219
[Bug target/20199] -fvisibility-inlines-hidden broken on powerpc64-linux
--- Additional Comments From janis at gcc dot gnu dot org 2005-02-26 00:15 --- My command line in the previous comment should have said -o libx.so. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20199
