--- Comment #4 from igodard at pacbell dot net 2006-04-19 06:36 ---
I can send you a linked binary with symbols, for either x86 Linux or Cygwin.
Would that help?
Ivan
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26974
--- Comment #3 from law at redhat dot com 2006-04-19 06:43 ---
I'm peeking at DOM.
jeff
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
--- Comment #3 from yokoyama-hxb at necst dot nec dot co dot jp 2006-04-19
07:23 ---
(In reply to comment #2)
I'm tring to write a kind of c analizer which inputs intermediate language of
gcc.
If it's only debugging porpose and some infomation like might NOT be print, I
guess what
Using a recent gcc build (4.2.0 20060418) the following code:
template class foo class junk {
void bar(int a)
{
unsigned char *c = new unsigned char[a*sizeof(foo)];
}
};
gets an ICE:
foo.c: In member function 'void junkfoo::bar(int)':
foo.c:4: internal
--- Comment #9 from patchapp at dberlin dot org 2006-04-19 08:00 ---
Subject: Bug number PR26869
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-04/msg00690.html
--
--- Comment #4 from pluto at agmk dot net 2006-04-19 08:12 ---
(In reply to comment #2)
Well this works with just compiling like:
g++ -O2 -pthread t.ii
With 4.1.0 (4.1.0 20051026).
Yes, it works with libstdcxx but the testcase uses STLport-5.0.2.
--
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-04-19 08:25 ---
Confirmed.
#0 internal_error (
gmsgid=0x8a04870 tree check: did not expect class %qs, have %qs (%s) in
%s, at %s:%d) at /space/rguenther/src/svn/gcc/gcc/diagnostic.c:586
#1 0x0875e9b2 in
--- Comment #5 from pluto at agmk dot net 2006-04-19 08:33 ---
(In reply to comment #3)
Are you sure that you are not mixing operator new and deletes up so the
stlport's operator delete is being called on memory allocated from
operator new from libstdc++?
STLport uses
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
--- Comment #6 from pluto at agmk dot net 2006-04-19 08:38 ---
It works also with 4.1.x -fstrict-aliasing -fno-inline.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27156
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-04-19 08:39 ---
I have a patch (and found this bug too late).
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pcarlini at suse dot de 2006-04-19 08:59 ---
Indeed, not a libstdc++ bug. And, by the way, per the Standard (27.8.1.3/2) we
have to use fopen.
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #10 from rguenth at gcc dot gnu dot org 2006-04-19 09:02
---
Now, we have
/* Initial scalar cleanups. */
NEXT_PASS (pass_ccp);
NEXT_PASS (pass_fre);
NEXT_PASS (pass_dce);
NEXT_PASS (pass_forwprop);
NEXT_PASS (pass_copy_prop);
NEXT_PASS (pass_merge_phi);
The following testcase generates a questionable diagnostic:
===
struct A {};
templateint void A::foo() {}
===
bug1.cc:3: error: no 'void A::foo()' member function declared in class 'A'
bug1.cc:3: error: template definition of
--- Comment #3 from patchapp at dberlin dot org 2006-04-19 09:30 ---
Subject: Bug number PR c++/26739
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-04/msg00692.html
--
Given the Altivec function:
vector unsigned short peepholebug(vector unsigned short a, vector unsigned
short b) {
vector unsigned short mask = (vector unsigned short)vec_cmplt(a, b);
if (vec_all_ge(a, b)) return a;
return mask;
}
XCode 2.2.1 / gcc 4.0 on
--- Comment #6 from reichelt at gcc dot gnu dot org 2006-04-19 09:34
---
Mark,
are you really working on this one or did you only accidentally assign the PR
to
you? The following fixes the problem for me and allows to get rid of
error_mark_list as it is then unused:
--- Comment #4 from patchapp at dberlin dot org 2006-04-19 09:35 ---
Subject: Bug number PR c++/10385
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-04/msg00693.html
--
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|dnovillo at gcc dot gnu dot |jakub at gcc dot gnu dot org
|org
--- Comment #4 from pcarlini at suse dot de 2006-04-19 10:49 ---
Working on it.
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|unassigned at
--- Comment #19 from marc dot glisse at normalesup dot org 2006-04-19
11:09 ---
(In reply to comment #18)
Probably this PR should be suspended, while waiting for the resolution of DR
456:
http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#456
Whether the situation
--- Comment #20 from pcarlini at suse dot de 2006-04-19 11:19 ---
(In reply to comment #19)
(In reply to comment #18)
Probably this PR should be suspended, while waiting for the resolution of DR
456:
http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#456
Whether
--- Comment #21 from marc dot glisse at normalesup dot org 2006-04-19
11:38 ---
(In reply to comment #20)
the
very same source code would not be be portable across those targets. I don't
think we would like that. Besides, more generally, I'm not at all sure that
all the users would
--- Comment #22 from pcarlini at suse dot de 2006-04-19 11:44 ---
(In reply to comment #21)
I meant proposing it as a choice, with a flag like -fclean-global-namespace
(better than a macro since it probably means changing the include path and
redefining a few macros), which needs not
The C frontend creates pointer arithmetic that assumes that pointer
overflow is defined (and wraps).
char *foo(char *p)
{
return p + -4;
}
results in
foo (p)
{
char * D.1523;
D.1523 = p + -4B;
return D.1523;
}
this is via c-common.c:pointer_int_sum().
plus_expr 0xb7da4144
type
enum A{b,c};
enum M{n,o};
class foo {
public:
operator A() { return b; }
operator int() { return 0; }
};
int main() {
foo a;
unsigned int x = a;
}
gets you:
~/ootbc/sim/test$ g++ foo.cc
foo.cc: In function `int main()':
foo.cc:10: error: conversion from `foo' to `unsigned
In the following code, the lifetime of the temporary
bound to the static const reference in g() is wrong.
In fact, the destructor is called every time the function
is left (although the constructor is called only the
first time the function is entered, which is correct).
According to the C++
--- Comment #2 from kkojima at gcc dot gnu dot org 2006-04-19 12:42 ---
I'd like to add Joern to the CC list.
I've looked the rtl dumps for the testcase. It seems that
the wrong code is generated during the peephole2 optimization.
The corresponding part of .41.csa dump is:
(insn:HI
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-04-19 12:46 ---
Confirmed. Testcase:
extern C void abort(void);
bool ok = false;
struct C
{
~C() { if (!ok) abort(); }
};
void g()
{
static const C c = C();
}
int main()
{
g();
ok = true;
return 0;
}
The C++ frontend
--- Comment #7 from jakub at gcc dot gnu dot org 2006-04-19 13:00 ---
Honza, this is caused by your patch:
http://gcc.gnu.org/ml/gcc-patches/2005-06/msg00661.html
In -fno-unit-at-a-time mode, we used to pass the local var to dwarf2out only
when the containing function has been
--- Comment #5 from reichelt at gcc dot gnu dot org 2006-04-19 13:25
---
Testing a patch.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from dave at hiauly1 dot hia dot nrc dot ca 2006-04-19
13:26 ---
Subject: Re: [4.2 Regression] libgcc2.c:382: internal compiler error: in
prune_unused_types_update_strings, at dwarf2out.c:RO
--- Comment #8 from sje at cup dot hp dot com 2006-04-18 18:34 ---
When compiling using gcc-4.1.0 I get this errors in the stl headers:
---
/home/jacob/gcc41bin/lib/gcc/x86_64-unknown-linux-gnu/4.1.0/../../../../include/
c++/4.1.0/bits/stl_bvector.h: In member function 'void
--- Comment #14 from jakub at gcc dot gnu dot org 2006-04-19 13:45 ---
It is the TREE_OVERFLOW set on 0x8000.
That seems to be created by convert_to_integer.
type in that case is unsigned short and expr is (intD.0) xD.1878 32768.
As the expr was using signed type, convert_to_integer
I get the following ICE with G+ 4.1.0 and 4.2 snapshot on i386 and powerpc (but
not on amd64). It works fine with 4.0 or without -O2.
(sid)596:[EMAIL PROTECTED]: ~] g++-4.1 -c -O2 ./mini.c
./mini.c: In member function void studio::Duckmatic::add_duck(const
etl::handlestudio::Duck):
--- Comment #1 from tbm at cyrius dot com 2006-04-19 14:07 ---
Created an attachment (id=11298)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11298action=view)
test case, reduced with delta
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27218
--- Comment #2 from tbm at cyrius dot com 2006-04-19 14:10 ---
Created an attachment (id=11299)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11299action=view)
smaller test case
--
tbm at cyrius dot com changed:
What|Removed |Added
--- Comment #5 from bangerth at dealii dot org 2006-04-19 14:11 ---
No, because then I can't play around with the source. But seriously,
how is the code supposed to be linkable when for example noAssembler
only has a declaration, no definition?
W.
--
--- Comment #15 from falk at debian dot org 2006-04-19 14:20 ---
Roger's patch
http://gcc.gnu.org/ml/gcc/2006-04/msg8.html
fixes this. I don't know about the status of this patch, though.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26729
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.2.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26026
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-19 15:03 ---
This already has been fixed at least for 4.1.0 though it is still a regression
on the 4.0 branch.
Anyways this is a dup of bug 22077 which I filed back when I first heard about
this bug from some Apple employees.
--- Comment #15 from pinskia at gcc dot gnu dot org 2006-04-19 15:03
---
*** Bug 27212 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-19 15:06 ---
There is no wrapping here or undefinedness here as far as I can see
You just have to learn that a + -CST is the same as a - CST.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-19 15:07 ---
Shorter might not mean better. IIRC the standard defines these as ambiguous
conversions.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27215
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-19 15:08 ---
*** This bug has been marked as a duplicate of 20416 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-04-19 15:08 ---
*** Bug 27216 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-19 15:10 ---
Can you provide the preprocessed source? And maybe even the unpreprocessed
source too?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-04-19 15:13 ---
-CST in this case is unsigned 4294967292, it just happens to be printed as
-4B.
So the addition wraps, as it is done using unsigned arithmetic. Writing
char *foo(char *p)
{
return p + 4294967292;
}
results in
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-04-19 15:22 ---
Both are those are the same. Maybe we should just get a POINTER_PLUS_EXPR but
that is really not an issue here.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-04-19 15:31 ---
How's that the same? Either you say that pointers follow unsigned integer
types in overflow behavior (quote me the standard for that) or explain why
p + -4 is treated as p + (char *)-4
but p - 4 is
--- Comment #4 from law at redhat dot com 2006-04-19 15:32 ---
OK, as expected, DOM was doing something totally stupid with immediate uses.
On my x86 box I've got a patch which takes us from ~250 seconds in DOM to
around 5.
I'm going to get this fix bootstrapped and regression tested,
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-04-19 15:34 ---
Then p + -4 is overflowed already -4 is no different than the unsigned version.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from bkoz at gcc dot gnu dot org 2006-04-19 15:43 ---
patches to fully qualify size_t as std::size_t within __gnu_cxx are
pre-approved.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27199
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-04-19 15:53 ---
Reduced testcase at least for PPC:
struct Vector
{
double _x, _y;
};
typedef Vector Point;
Vector d;
static inline Vector f(void)
{
return d;
}
void add_duck (void)
{
new Point (f());
}
--
pinskia at
--- Comment #4 from tbm at cyrius dot com 2006-04-19 16:03 ---
Yep, also on i386, thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27218
--- Comment #3 from zhong dot xie at yahoo dot ca 2006-04-19 16:08 ---
1.
Agree, I wouldn't call it a bug. But I don't know where to put it other than
here.
2.
I don't think you have to use fopen for fstream defined by the C++
standard.(see the details below)
3.
It is solaris itself
I'm looking at natPlainSocketImplPosix.cc:write_helper().
* Why not throw an exception on ENOTCONN or ECONNRESET?
We could at least use a better comment here.
* This code doesn't handle EINTR properly.
The recv code also doesn't seem to handle EINTR properly.
--
Summary:
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
--- Comment #6 from rakdver at gcc dot gnu dot org 2006-04-19 16:32 ---
I do not think this PR is invalid:
int a[100];
int *p = a[50];
p - 1 is well defined, and points to 50 - 1 th element of a, as standard
specifies
p + (-1) is also well defined, and points to 50 + (-1) th element,
--- Comment #4 from pcarlini at suse dot de 2006-04-19 16:38 ---
(In reply to comment #3)
1.
Agree, I wouldn't call it a bug. But I don't know where to put it other than
here.
Maybe report it to Sun?
2.
I don't think you have to use fopen for fstream defined by the C++
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-19 16:49 ---
Actually this is a different issue than I orginally thought (just waking up).
(insn:TI 16 9 14 (parallel [
(set (reg:CC 74 6)
(unspec:CC [
(reg/v:V8HI 77 0
--- Comment #7 from mark at codesourcery dot com 2006-04-19 16:57 ---
Subject: Re: [4.0/4.1/4.2 Regression] Treating a class object
as a function with member variables causes hang
reichelt at gcc dot gnu dot org wrote:
--- Comment #6 from reichelt at gcc dot gnu dot org
--- Comment #7 from mmitchel at gcc dot gnu dot org 2006-04-19 16:58
---
Subject: Bug 27102
Author: mmitchel
Date: Wed Apr 19 16:58:23 2006
New Revision: 113081
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113081
Log:
PR c++/27102
* class.c
--- Comment #8 from mmitchel at gcc dot gnu dot org 2006-04-19 17:01
---
Fixed in 4.2.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from mmitchel at gcc dot gnu dot org 2006-04-19 17:11
---
In C++ the type of the FIELD_DECL should be unsigned int, not 4-bit unsigned
int. So, this is the usual problem that we don't quite know how lowered the
representation shared across the front-end and back-end
--- Comment #7 from joseph at codesourcery dot com 2006-04-19 17:15 ---
Subject: Re: The C frontend introduces undefined pointer overflow
On Wed, 19 Apr 2006, rakdver at gcc dot gnu dot org wrote:
Andrew, please do not mark PRs as invalid until the people involved in the
discussion
--- Comment #5 from reichelt at gcc dot gnu dot org 2006-04-19 17:15
---
Subject: Bug 10385
Author: reichelt
Date: Wed Apr 19 17:15:54 2006
New Revision: 113084
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113084
Log:
PR c++/10385
* rtti.c
--- Comment #6 from reichelt at gcc dot gnu dot org 2006-04-19 17:19
---
Subject: Bug 10385
Author: reichelt
Date: Wed Apr 19 17:19:35 2006
New Revision: 113085
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113085
Log:
PR c++/10385
* rtti.c
--- Comment #7 from reichelt at gcc dot gnu dot org 2006-04-19 17:23
---
Subject: Bug 10385
Author: reichelt
Date: Wed Apr 19 17:23:10 2006
New Revision: 113086
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113086
Log:
PR c++/10385
* rtti.c
--- Comment #8 from reichelt at gcc dot gnu dot org 2006-04-19 17:25
---
Fixed on mainline, 4.1 branch, and 4.0 branch.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from reichelt at gcc dot gnu dot org 2006-04-19 17:37
---
Subject: Bug 26036
Author: reichelt
Date: Wed Apr 19 17:36:59 2006
New Revision: 113087
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113087
Log:
PR c++/26036
* typeck.c
--- Comment #9 from reichelt at gcc dot gnu dot org 2006-04-19 17:40
---
Subject: Bug 26036
Author: reichelt
Date: Wed Apr 19 17:40:27 2006
New Revision: 113088
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113088
Log:
PR c++/26036
* typeck.c
--- Comment #10 from reichelt at gcc dot gnu dot org 2006-04-19 17:43
---
Subject: Bug 26036
Author: reichelt
Date: Wed Apr 19 17:43:01 2006
New Revision: 113089
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113089
Log:
PR c++/26036
* typeck.c
--- Comment #11 from reichelt at gcc dot gnu dot org 2006-04-19 17:46
---
Fixed on mainline, 4.1 branch, and 4.0 branch.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from patchapp at dberlin dot org 2006-04-19 17:50 ---
Subject: Bug number PR c++/26036
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-04/msg00711.html
--
--- Comment #4 from reichelt at gcc dot gnu dot org 2006-04-19 18:07
---
Subject: Bug 26739
Author: reichelt
Date: Wed Apr 19 18:07:19 2006
New Revision: 113090
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113090
Log:
PR c++/26739
* pt.c
--- Comment #5 from reichelt at gcc dot gnu dot org 2006-04-19 18:08
---
Fixed on mainline.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--
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
--- Comment #2 from jacob dot navia at ants dot com 2006-04-19 18:21
---
Excuse me, this is the same problem as bug 16605. The problem is that max is
defined as something in my sources...
Thanks for your time.
jacob
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27217
--- Comment #3 from pcarlini at suse dot de 2006-04-19 18:24 ---
*** This bug has been marked as a duplicate of 16605 ***
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #6 from pcarlini at suse dot de 2006-04-19 18:24 ---
*** Bug 27217 has been marked as a duplicate of this bug. ***
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #2 from reichelt at gcc dot gnu dot org 2006-04-19 18:26
---
Even shorter testcase:
===
templatetypename T void foo()
{
new char[2*sizeof(T)];
}
===
--
reichelt at gcc dot gnu dot org changed:
--- Comment #1 from tromey at gcc dot gnu dot org 2006-04-19 18:39 ---
I spent some time looking into this bug today.
I am not certain that it is a bug, but I'm also not convinced
that it isn't.
I tracked it down to the ftp data socket's available() method
returning 0. This causes the
--- Comment #2 from tromey at gcc dot gnu dot org 2006-04-19 18:56 ---
Subject: Bug 27163
Author: tromey
Date: Wed Apr 19 18:56:10 2006
New Revision: 113091
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113091
Log:
PR classpath/27163:
*
--- Comment #3 from geoffk at gcc dot gnu dot org 2006-04-19 19:15 ---
I think that the actual reported behaviour is not a bug. Some related
behaviour is covered by bug 26612, but in this particular case the name 'Abc'
refers to something that is hidden, and so it shouldn't be possible
--- Comment #6 from geoffk at gcc dot gnu dot org 2006-04-19 19:23 ---
I believe that the problem here is that you haven't defined foo::bar in
linkfoo.so. Because the foo in linkfoo.so is hidden, it is not the same foo as
the foo in liblinkfoo.so.
--
geoffk at gcc dot gnu dot org
--- Comment #3 from amylaar at gcc dot gnu dot org 2006-04-19 19:35 ---
(In reply to comment #2)
I'd like to add Joern to the CC list.
I've looked the rtl dumps for the testcase. It seems that
the wrong code is generated during the peephole2 optimization.
...
(reg:SI 1 r1 [656])
--- Comment #3 from reichelt at gcc dot gnu dot org 2006-04-19 20:07
---
Confirmed.
Reduced testcase (compile with -O -ftrapv):
==
char *p, *q;
inline int foo(int i)
{
return (p - q) + i;
}
void bar()
{
int n, i;
for (n = 7; n-- 0; )
for
--- Comment #3 from ben at shellandslate dot com 2006-04-19 20:20 ---
It's true that the instructions are not identical (the first sets the condition
register, the second doesn't.) But the second still duplicates work already
performed, and should be removed. (The two instructions are
--- Comment #1 from reichelt at gcc dot gnu dot org 2006-04-19 20:25
---
Confirmed.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #6 from bangerth at dealii dot org 2006-04-19 21:20 ---
No. Class C is implicitly a friend of itself.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26838
--- Comment #2 from bangerth at dealii dot org 2006-04-19 21:26 ---
(In reply to comment #0)
However, the path foo-int-unsigned int is shorter than the path
foo-A-int-unsigned int, so the former should be chosen.
There is no separate conversion A-int: values of type A already have
--- Comment #6 from patchapp at dberlin dot org 2006-04-19 21:35 ---
Subject: Bug number PR c++/26558
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-04/msg00725.html
--
--- Comment #5 from reichelt at gcc dot gnu dot org 2006-04-19 21:47
---
Subject: Bug 26790
Author: reichelt
Date: Wed Apr 19 21:47:03 2006
New Revision: 113095
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113095
Log:
PR mudflap/26789
*
--- Comment #5 from reichelt at gcc dot gnu dot org 2006-04-19 21:47
---
Subject: Bug 26789
Author: reichelt
Date: Wed Apr 19 21:47:03 2006
New Revision: 113095
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113095
Log:
PR mudflap/26789
*
--- Comment #6 from reichelt at gcc dot gnu dot org 2006-04-19 21:51
---
Fixed on mainline. Testcase now also on mainline.
Btw, the second half of comment #4 is bogus. I just confused the patches.
See http://gcc.gnu.org/ml/gcc-patches/2006-04/msg00722.html for details.
--
reichelt
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-04-19 21:54 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #6 from reichelt at gcc dot gnu dot org 2006-04-19 21:55
---
Testcase now also on mainline.
Btw, I confused the patch for this PR with the one for PR 26790.
Since both were applied to mainline this doesn't really matter.
See
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-04-19 21:57
---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
1 - 100 of 123 matches
Mail list logo
