--- Comment #21 from dick_guertin at yahoo dot com 2006-01-19 08:26 ---
>From what I can tell with the testcase, any static data that is not
'referenced' is eliminated. This is terribly non-transparent in programs that
create tables by using static data to define table members. Only th
--- Comment #22 from ebotcazou at gcc dot gnu dot org 2006-01-19 08:39
---
> From what I can tell with the testcase, any static data that is not
> 'referenced' is eliminated. This is terribly non-transparent in programs that
> create tables by using static data to define table members.
--- Comment #3 from backes at rhrk dot uni-kl dot de 2006-01-19 08:53
---
I will report it to the WindowMaker developpers. You may close the bag.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25853
--- Comment #3 from bl at rosetechnology dot dk 2006-01-19 08:52 ---
Created an attachment (id=10673)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10673&action=view)
Another example, this time on windows-xp
I think this is the same bug.
Compiler version 3.4.3 Windows
Target avr m
--- Comment #9 from reichelt at gcc dot gnu dot org 2006-01-19 09:52
---
Subject: Bug 16829
Author: reichelt
Date: Thu Jan 19 09:51:57 2006
New Revision: 109950
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109950
Log:
PR c++/16829
* decl.c (start_preparsed_fun
--- Comment #10 from reichelt at gcc dot gnu dot org 2006-01-19 09:56
---
Subject: Bug 16829
Author: reichelt
Date: Thu Jan 19 09:56:44 2006
New Revision: 109952
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109952
Log:
PR c++/16829
* decl.c (start_preparsed_fu
--- Comment #11 from reichelt at gcc dot gnu dot org 2006-01-19 10:01
---
Subject: Bug 16829
Author: reichelt
Date: Thu Jan 19 10:01:20 2006
New Revision: 109953
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109953
Log:
PR c++/16829
* decl.c (start_preparsed_fu
--- Comment #12 from reichelt at gcc dot gnu dot org 2006-01-19 10:06
---
This is fixed now in gcc 4.0.3.
I'll wait a couple of days until I'll apply the patch to the 3.4 branch, too.
Btw, the following testcase is a regression from 3.3.x:
struct A
{
For the testcase
=
template struct A {};
template<> struct A<> {};
=
we issue the following diagnostic:
diag.cc:2: error: wrong number of template arguments (0, should be 1)
diag.cc:1: error: provided for 'template struct A'
d
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |reichelt at gcc dot gnu dot
|dot org
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last r
there seems to be a possibly a regression in c++ 4.0.2 / 4.1 and newer
depending on if BREAK and WORKAROUND is not defined in the attached testcase.
I'm not 100% sure if this is defined behavior or not, or if the WORKAROUND is
actually the correct solution. So it varies between wrong-code, accept
--- Comment #1 from mueller at kde dot org 2006-01-19 11:12 ---
Created an attachment (id=10674)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10674&action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25855
--- Comment #2 from mueller at kde dot org 2006-01-19 11:13 ---
attaching testcase inline for better bugzilla queries:
#ifdef BREAK
templatebool qCompare(const T *t1, const T
*t2);
templatebool qCompare(T *t1, T *t2);
#else
template
The following invalid code triggers an
internal compiler error: Segmentation fault
I accidentally found this while reducing another testcase with the delta script
(and a faulty check.sh script), so I guess this has little real world
relevance. But still gcc shouldn't crash.
I can reproduce thi
--- Comment #6 from hp at gcc dot gnu dot org 2006-01-19 11:17 ---
Sorry, the patch in comment #3 did not help.
Same error, same assertion error message.
(No regressions though, tested cross to
cris-elf, cris-axis-linux-gnu, mmix-knuth-mmixware.)
--
hp at gcc dot gnu dot org changed:
--- Comment #7 from pcarlini at suse dot de 2006-01-19 11:22 ---
(In reply to comment #6)
> Sorry, the patch in comment #3 did not help.
> Same error, same assertion error message.
> (No regressions though, tested cross to
> cris-elf, cris-axis-linux-gnu, mmix-knuth-mmixware.)
Thanks fo
--- Comment #8 from hp at gcc dot gnu dot org 2006-01-19 11:25 ---
Confirmed that compiling the test-case with -fno-strict-aliasing yields
the same error.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25815
-- foo.cc -
#include
struct Foo { void f(); };
struct Bar { Foo& getFoo(); };
struct Qux {
~Qux();
Bar bar;
std::string s1, s2, s3, s4;
};
Qux::~Qux() { bar.getFoo().f(); }
---
> g++ -O2 foo.cc
foo.cc: In dest
--- Comment #1 from reichelt at gcc dot gnu dot org 2006-01-19 11:41
---
Confirmed.
Here's something "less" invalid thar also causes an ICE:
==
struct A;
A::~A() {}
==
--
reichelt at gcc dot gnu dot org changed:
What|Removed
--- Comment #23 from pinskia at gcc dot gnu dot org 2006-01-19 12:16
---
Closing as invalid as this is depending on undefined bahvior.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-19 12:30 ---
I can confirm it but I am not reducing this currently. From the looks of it,
it looks to be another issue with the mergephi.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-01-19 12:38 ---
Yes this is a dup of the closed (invalid) bug 11203.
*** This bug has been marked as a duplicate of 11203 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #33 from pinskia at gcc dot gnu dot org 2006-01-19 12:38
---
*** Bug 25853 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-01-19 13:09 ---
14.7.3/11 and /12 suggest, that while having the template-argument unspecified
in the template-id is valid only if the template-argument can be deduced from
the function arguments unambiguously (it does not say if a
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-01-19 13:15 ---
So, for
template int qCompare(const T *t1, const T *t2) { return 1; }
template int qCompare(T *t1, T *t2) { return 2; }
template int qCompare(const T1 *t1, const T2 *t2) {
return 3; }
template<> int qCompare(co
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-01-19 13:36 ---
Note, this is very much related to PR 19203 and PR 4672 and DRs 214.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25855
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-01-19 13:42 ---
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#214
DR 214 describes what is going on here dead on but I don't really understand
what is the expected behavior.
--
http://gcc.gnu.org/bugzilla/show_b
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-01-19 13:53 ---
This is also related to PR 12536. I don't think should have been marked as new
if it was not obvious if this a bug or not.
Nathan,
Can you look at this like you did with the other three PRs and see if this is
wha
--- Comment #2 from reichelt at gcc dot gnu dot org 2006-01-19 14:10
---
Confirmed. Reduced testcase:
===
int foo();
int i;
struct A
{
~A() { if (this != (A*)(&i)) foo(); }
};
struct B
{
A a1, a2, a3, a4;
~B() { foo(); }
};
B b;
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-01-19 14:13 ---
14.7.3/12 has been removed by DR 64.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25855
--- Comment #9 from nathan at gcc dot gnu dot org 2006-01-19 14:22 ---
The bug appears to be not in the deduction machinery, but in the instantiation
machinery. In all cases we end up calling _Z8qCompareIcEiPKT_S2_, but the body
of that function differs! Using the example in comment #4
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-01-19 14:29
---
Here is what is happening here:
template int qCompare(const T *t1, const T *t2) { return 1; }
template int qCompare(T *t1, T *t2) { return 2; }
template int qCompare(const T1 *t1, const T2 *t2) {
return 3; }
t
--- Comment #14 from hjl at gcc dot gnu dot org 2006-01-19 14:42 ---
Subject: Bug 25840
Author: hjl
Date: Thu Jan 19 14:42:47 2006
New Revision: 109958
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109958
Log:
2006-01-19 H.J. Lu <[EMAIL PROTECTED]>
PR libgcj/25840
--- Comment #15 from hjl at gcc dot gnu dot org 2006-01-19 14:43 ---
Subject: Bug 25840
Author: hjl
Date: Thu Jan 19 14:43:21 2006
New Revision: 109959
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109959
Log:
2006-01-19 H.J. Lu <[EMAIL PROTECTED]>
PR libgcj/25840
--- Comment #16 from hjl at gcc dot gnu dot org 2006-01-19 14:43 ---
Subject: Bug 25840
Author: hjl
Date: Thu Jan 19 14:43:44 2006
New Revision: 109960
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109960
Log:
2006-01-19 H.J. Lu <[EMAIL PROTECTED]>
PR libgcj/25840
--- Comment #11 from nathan at gcc dot gnu dot org 2006-01-19 14:43 ---
comment #10 is incorrect. Regardless of the validity/invalidity of the code,
the fact that comment#4 shows us producing different code depending on the
ordering of the template decls indicates a bug. (I also fail t
--- Comment #32 from matz at suse dot de 2006-01-19 14:44 ---
Mark, I agree that it's saner when both structures (with #pragma pack and
attribute packed) have the same length of 8 on i686 and x86_64 (because
the bitfield was declared 'int' in difference to 'long' for instance).
Then I h
The following code snippet crashes the C++ frontend:
===
namespace N
{
template struct A {};
}
struct B N::A<0> {};
===
bug.cc:6: error: invalid use of constructor as a template
bug.cc:6: internal compiler error: Segmentation fault
Please
# gnattools2
make -C ../gcc/ada/tools -f ../Makefile \
"CC=../../xgcc -B../../" "CFLAGS=-g -O2" "ADAFLAGS=-gnatpg -gnata"
"IN
CLUDES=-I. -I.. -I../.. -I/home/dave/gcc-4.1/gcc/gcc/ada
-I/home/dave/gcc-4.1/gc
c/gcc/ada/../config -I/home/dave/gcc-4.1/gcc/gcc/ada/../../include
-I/home/dave/
g
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-19 15:48 ---
Confirmed, it worked on 20051217.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
> This doesn't happen on the trunk.
The following from ada/Makefile.in is supposed to take care of that:
GCC_LINK="$(CC) -static-libgcc $(ADA_INCLUDES)"
(and uses of $(GCC_LINK) elsewhere in the tools).
Basically we certainly do *not* want to link with libgcc_s, in particular
to avoid this kind
--- Comment #1 from charlet at adacore dot com 2006-01-19 15:53 ---
Subject: Re: New: gnatmake: error while loading shared libraries:
libgcc_s.so.4: cannot open
> This doesn't happen on the trunk.
The following from ada/Makefile.in is supposed to take care of that:
GCC_LINK="$(CC) -
--- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca 2006-01-19
15:53 ---
Subject: Re: New: gnatmake: error while loading shared libraries:
libgcc_s.so.4: cannot open
> ../../gnatmake: error while loading shared libraries: libgcc_s.so.4: cannot
> open
> shared object file: No
--- Comment #2 from reichelt at gcc dot gnu dot org 2006-01-19 15:57
---
Confirmed. Reduced testcase:
===
struct A
{
ERROR;
~A();
};
struct B
{
virtual ~B();
};
struct C : B, A {};
struct D : C {};
D d;
===
--
reichelt at gcc dot gn
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-01-19 16:06 ---
Fixed by:
2006-01-09 Jeff Law <[EMAIL PROTECTED]>
* tree-ssa-dom.c (simplify_cond_and_lookup_avail_expr): Remove
code to propagate the RHS of a cast into COND_EXPR_COND. Remove
now unused
--- Comment #3 from dave at hiauly1 dot hia dot nrc dot ca 2006-01-19
16:10 ---
Subject: Re: gnatmake: error while loading shared libraries: libgcc_s.so.4:
cannot open
> --- Comment #1 from charlet at adacore dot com 2006-01-19 15:53 ---
> Subject: Re: New: gnatmake: error
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-01-19 16:11 ---
I wonder if we could get the aliasing mechanism to say that this array
descriptor is not changed and move the stores out of the loop.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24520
--- Comment #2 from eweddington at cso dot atmel dot com 2006-01-19 16:18
---
I would concur with Richard. The fact that you're getting "no such instruction"
points to an issue with the assembler, and that you probably don't have a
target assembler (AVR assembler) installed, or you forg
> For some reason, the above doesn't seem to have been used in linking gnatmake:
Indeed, gnatmake has to be handled specially.
So I guess the gnatmake rule needs to use $(GCC_LINK)
one way or another (although there should be no difference between
trubk and 4.1 in that respect).
Same for gnatlin
--- Comment #4 from charlet at adacore dot com 2006-01-19 16:19 ---
Subject: Re: gnatmake: error while loading shared libraries: libgcc_s.so.4:
cannot open
> For some reason, the above doesn't seem to have been used in linking gnatmake:
Indeed, gnatmake has to be handled specially.
S
--- Comment #4 from eweddington at cso dot atmel dot com 2006-01-19 16:22
---
Bjoerne, could you post a comment to this bug that includes the link to the
patch in the gcc-patches list?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25035
--- Comment #5 from dave at hiauly1 dot hia dot nrc dot ca 2006-01-19
16:41 ---
Subject: Re: gnatmake: error while loading shared libraries: libgcc_s.so.4:
cannot open
> So I guess the gnatmake rule needs to use $(GCC_LINK)
I'll try the above change
> one way or another (although th
--- Comment #33 from mark at codesourcery dot com 2006-01-19 16:59 ---
Subject: Re: [3.4/4.0/4.1/4.2 Regression] bitfield
layout change (regression?)
matz at suse dot de wrote:
> --- Comment #32 from matz at suse dot de 2006-01-19 14:44 ---
> Mark, I agree that it's saner whe
--- Comment #11 from pinskia at gcc dot gnu dot org 2006-01-19 17:18
---
Subject: Bug 15642
Author: pinskia
Date: Thu Jan 19 17:18:29 2006
New Revision: 109973
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109973
Log:
2006-01-19 Andrew Pinski <[EMAIL PROTECTED]>
PR
--- Comment #12 from pinskia at gcc dot gnu dot org 2006-01-19 17:18
---
Fixed in 4.2.0.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Statu
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-01-19 17:28
---
Subject: Bug 22099
Author: pinskia
Date: Thu Jan 19 17:28:53 2006
New Revision: 109974
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109974
Log:
2006-01-19 Andrew Pinski <[EMAIL PROTECTED]>
PR
--- Comment #11 from pinskia at gcc dot gnu dot org 2006-01-19 17:29
---
Fixed in 4.2.0 and above.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from reichelt at gcc dot gnu dot org 2006-01-19 17:29
---
Subject: Bug 25854
Author: reichelt
Date: Thu Jan 19 17:29:42 2006
New Revision: 109975
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109975
Log:
PR c++/25854
* pt.c (maybe_process_partial
--- Comment #3 from loizeaux1 at hotmail dot com 2006-01-19 17:30 ---
Here's the results I got after following the directions on the website you gave
me (I realize this may be moot since you pointed out that it is a false
positive, but I'll just do this for completeness' sake):
> cat te
--- Comment #2 from reichelt at gcc dot gnu dot org 2006-01-19 17:33
---
Subject: Bug 25854
Author: reichelt
Date: Thu Jan 19 17:33:07 2006
New Revision: 109976
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109976
Log:
PR c++/25854
* pt.c (maybe_process_partial
--- Comment #3 from reichelt at gcc dot gnu dot org 2006-01-19 17:35
---
Subject: Bug 25854
Author: reichelt
Date: Thu Jan 19 17:35:08 2006
New Revision: 109977
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109977
Log:
PR c++/25854
* pt.c (maybe_process_partial
--- Comment #4 from reichelt at gcc dot gnu dot org 2006-01-19 17:37
---
Subject: Bug 25854
Author: reichelt
Date: Thu Jan 19 17:37:49 2006
New Revision: 109978
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109978
Log:
PR c++/25854
* pt.c (maybe_process_partial
--- Comment #5 from reichelt at gcc dot gnu dot org 2006-01-19 17:39
---
Fixed in GCC 3.4.6, 4.0.3 and later.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #34 from steven at gcc dot gnu dot org 2006-01-19 17:40 ---
I looked up a few links to see how people use zero-length bit-fields and what
semantics they're expecting. I mostly found links to compiler documentation
about how other compilers interpret these bit-fields. Perhaps
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-01-19 17:53 ---
So this is a purify bug as valgrind says the memory is still reachable which is
correct because it is a thread specific location for the main thread. Closing
as invalid.
--
pinskia at gcc dot gnu dot org changed
--- Comment #24 from dick_guertin at yahoo dot com 2006-01-19 17:54 ---
Although you have closed this, many people would disagree with you. Laying out
static data this way has always 'worked' in the past, and continues to work
with -O, but not -O2. Just for completeness, here is a simp
--- Comment #25 from dick_guertin at yahoo dot com 2006-01-19 18:23 ---
In your closing arguments you said these static object need to be members of an
array. How would I do that? Here's a sample from comm.c where there is a
mixture of objects:
- - - -
static struct sckw sckw58 = {
0x4
--- Comment #13 from tromey at gcc dot gnu dot org 2006-01-19 18:23 ---
FWIW I suspect there is undefined code in gcjx.
For instance I think the constant evaluation code assumes
-fwrapv behavior. There could well be other undefined code,
but I don't know of any.
That said, it seems unl
--- Comment #26 from ebotcazou at gcc dot gnu dot org 2006-01-19 18:33
---
> In your closing arguments you said these static object need to be members of
> an array. How would I do that?
You need to use a single array for your table if all the elements have the same
type or a single b
I just tried to compile package gammu-1.04.0-2 from Suse Linux with a recent
GNU C compiler version 4.2 snapshot 20060114.
The compiler snapshot said
Making common/service/backup/gsmback.c
common/service/gsmring.c: In function "savewav":
common/service/gsmring.c:93: internal compiler error: in a
--- Comment #1 from dcb314 at hotmail dot com 2006-01-19 18:44 ---
Created an attachment (id=10675)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10675&action=view)
C source code for ice
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25860
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-01-19 18:45 ---
/* If this is a real operand, the operand is either ssa name or decl.
Virtual operands may only be decls. */
gcc_assert (is_real_op || DECL_P (var));
Was where it was crashing. The code has moved though.
I just tried to compile package gnugk-2.2.3-2 from Suse Linux with a recent
GNU C compiler version 4.2 snapshot 20060114.
The compiler snapshot said
/home/dcb/gnu/42-20060114/results/bin/g++ -g -O3 -Wall -fmessage-length=0
-DHAS_RADIUS=1 -DHAS_MSG_NOSIGNAL=1 -D'MANUFACTURER=GNU'
-D'PROGRAMMNAME
--- Comment #1 from dcb314 at hotmail dot com 2006-01-19 18:48 ---
Created an attachment (id=10676)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10676&action=view)
C++ source code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25861
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||ice-on-valid-code
Summary|ice with -g -O2 -fPIC |[4.
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-01-19 18:50 ---
Reducing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25860
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-01-19 18:53 ---
Reducing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25861
The following test case produces wrong result when compiled with -O2 or -O3.
expected result (-O1, or using intel compiler):
ReadX: x = -5.9436e+29 [ OK ]
WriteX: [ OK ]
observed results (-O2 or -O3)
ReadX: x = 0 [ FAIL ]
WriteX:
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-01-19 18:54 ---
This has been faling since at least 20051219.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25861
--- Comment #1 from andreg at discreet dot com 2006-01-19 18:56 ---
Created an attachment (id=10677)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10677&action=view)
C++ test case
To compile: g++ -O3 test3.C -o test3
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25862
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-01-19 18:59 ---
you are violating C/C++ aliasing rules, accessing doubles as int.
*** This bug has been marked as a duplicate of 21920 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #82 from pinskia at gcc dot gnu dot org 2006-01-19 18:59
---
*** Bug 25862 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
This piece of code:
#include
using namespace std;
class A
{
private: class B {public: int l;};
public: B getB() { B b; return (b); }
};
int main()
{
A a;
cout << a.getB().l;
}
-
--- Comment #35 from mark at codesourcery dot com 2006-01-19 19:14 ---
Subject: Re: [3.4/4.0/4.1/4.2 Regression] bitfield
layout change (regression?)
steven at gcc dot gnu dot org wrote:
> - Older HP compilers and MS compilers use zero-length bit-fields to force
> the following mem
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-01-19 19:16 ---
Reduced testcase:
struct g
{
int i;
};
struct f
{
struct g i;
};
int GSM_RingNoteGetFullDuration(struct g)__attribute__((const));
void savewav(struct f *gg)
{
struct g *Note;
long i = 0,j,length=0;
Note = &
--- Comment #4 from dcb314 at hotmail dot com 2006-01-19 19:17 ---
(In reply to comment #3)
> This has been faling since at least 20051219.
I rather suspect there would be a useful job for someone
to take each weekly snapshot of gcc 4.2 and make
sure it compiles some recentish distribu
--- Comment #5 from bkoz at gcc dot gnu dot org 2006-01-19 19:21 ---
Ack! Some of this stuff was fixed on mainline and 4.1 recently. I thought I'd
gotten everything, but I guess not.
Please put this type of fix in 4.1 as well...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2582
--- Comment #16 from amacleod at redhat dot com 2006-01-19 19:50 ---
Created an attachment (id=10678)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10678&action=view)
updated patch
I updated the patch to the current mainline, and have built and verified no
additional failures on
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-01-19 20:16 ---
Semi reduced:
void f(void);
class PNotifierFunction
{
public:
PNotifierFunction(
void * obj
) {
void * object;
object = ((&(obj)&&(obj)!=__null)?(obj): (f(),(obj)));
}
};
--
http
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-01-19 20:18 ---
Reduced C testcase:
int f(void *a)
{
return !(&a);
}
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-01-19 20:20 ---
Caused by:
2005-12-14 Ben Elliston <[EMAIL PROTECTED]>
* c-common.c (c_common_truthvalue_conversion): Generalise warning
for addresses converted to booleans; not just function addresses.
*
Use IBM long double format in 32-bit PowerPC Linux and enable 128-bit long
double by default.
--
Summary: Enable IBM long double format in 32-bit PowerPC Linux
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Keywords: ABI
Severity:
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-19 20:27 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #2 from dje at gcc dot gnu dot org 2006-01-19 20:28 ---
This is an enhancement request in conjunction with Glibc.
--
dje at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #3 from mmitchel at gcc dot gnu dot org 2006-01-19 20:44
---
David has indicated to me that it's possible (but not certain) that the PowerPC
GNU/Linux community wants this on by default in GCC 4.1. Since we'd very much
like to avoid ABI changes throughout the 4.1 series, an
--- Comment #18 from mmitchel at gcc dot gnu dot org 2006-01-19 21:27
---
I've spoken with the folks at EDG, and we all agree that we should not be
checking that, in "using S::f", "S" is a base class of the current class if
we're in a template; the set of base classes of the template is
--- Comment #7 from bkoz at gcc dot gnu dot org 2006-01-19 22:32 ---
paolo I can reproduce this on x86/linux with binutils 2.16.1
=== libstdc++ Summary ===
# of expected passes3837
# of unexpected failures134
# of unexpected successes 1
# of e
--- Comment #8 from hjl at gcc dot gnu dot org 2006-01-19 22:36 ---
Subject: Bug 25797
Author: hjl
Date: Thu Jan 19 22:36:41 2006
New Revision: 109985
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109985
Log:
2006-01-19 H.J. Lu <[EMAIL PROTECTED]>
PR libstdc++/25797
--- Comment #15 from uweigand at gcc dot gnu dot org 2006-01-19 23:10
---
This testcase also fails on s390x-ibm-linux (crash of f951).
The patch in comment 13 fixes the crash.
Any chance of getting the fix into 4.1?
--
uweigand at gcc dot gnu dot org changed:
What|R
1 - 100 of 141 matches
Mail list logo
