There was some discussion over the weekend about putting mainline into a
slush mode to deal with recent breakage. I never formally instituted
the slush, but there seems to have some self-healing activity, and a lot
of the problems are gone.
As was pointed out earlier, having multiple major
Shrirang Khishti [EMAIL PROTECTED] writes:
I have ported GCC-4.0 for a new target. Initially I started porting
with GCC-3.4 and then shifted to GCC-4.0 without any problems. Now I
want to port same code for GCC-4.1 . As there are some structural
differences in GCC-4.0 and gcc-4.1 back-ends
Hi,
In this page http://gcc.gnu.org/news/egcs-vcg.html, it's said that
If you view these files using a suitable program, you'll get output
similar to the following. However, when I use xvcg to view
test.c.01.sibling.vcg, xvcg errors:
Wait.aLine 5: attribute T_Co_hidden currently not implemented
On 1/25/06, Alexandre Oliva [EMAIL PROTECTED] wrote:
On Jan 22, 2006, Richard Guenther [EMAIL PROTECTED] wrote:
On 1/22/06, Alexandre Oliva [EMAIL PROTECTED] wrote:
I don't think it is any different. GCC's exception for unions only
applies if the object is accessed using the union type.
Joern RENNECKE wrote:
For easier reviewing, I have attached the diff to the cfgcleanup version
previous to the patch backout.
Thanks. Let me see if I understood the problem - please correct me if I
describe anything incorrectly.
The previous cross jumping code didn't care about register
On 1/26/06, Jie Zhang [EMAIL PROTECTED] wrote:
Hi,
In this page http://gcc.gnu.org/news/egcs-vcg.html, it's said that
If you view these files using a suitable program, you'll get output
similar to the following. However, when I use xvcg to view
test.c.01.sibling.vcg, xvcg errors:
On Jan 26, 2006, Richard Guenther [EMAIL PROTECTED] wrote:
So it is perfectly valid, but if GCC reorders the read from *ip past
the store to *dp, it turns the valid program into one that misbehaves.
*ip = 15; ii = *ip; *dp = 1.5; dd = *dp;
Here^^^
you are accessing
So, is union is a very useful feature in ISO C, without
gcc's extension? It seems that the only legal use of union
is to use the same type through the whole life of the object.
Here is the rationale:
Quoting Richard Guenther [EMAIL PROTECTED]:
On 1/25/06, Alexandre Oliva [EMAIL PROTECTED]
On Thu, 26 Jan 2006, Giovanni Bajo wrote:
Geoffrey Keating [EMAIL PROTECTED] wrote:
re this mail:
http://gcc.gnu.org/ml/gcc/2004-09/msg01357.html
do you still have the code around? Are you still willing to
contribute it?
Maybe you could upload it to a branch just to have it around
Bernd Schmidt wrote:
Thanks. Let me see if I understood the problem - please correct me
if I describe anything incorrectly.
The previous cross jumping code didn't care about register liveness,
since it just checked for identical instruction streams. The new,
more clever code, requires
On Thu, 2006-01-26 at 11:20 +0100, Bernd Schmidt wrote:
Joern RENNECKE wrote:
For easier reviewing, I have attached the diff to the cfgcleanup version
previous to the patch backout.
Thanks. Let me see if I understood the problem - please correct me if I
describe anything incorrectly.
Michael Veksler [EMAIL PROTECTED] writes:
| So, is union is a very useful feature in ISO C, without
| gcc's extension? It seems that the only legal use of union
| is to use the same type through the whole life of the object.
|
| Here is the rationale:
|
| Quoting Richard Guenther [EMAIL
On 25/01/2006, at 11:52 PM, Giovanni Bajo wrote:
svn log --stop-on-copy svn://gcc.gnu.org/svn/gcc/branches/stree-branch
I got my branches confused; it's on static-tree-branch. Revision 88377.
smime.p7s
Description: S/MIME cryptographic signature
On Jan 26, 2006, Gabriel Dos Reis [EMAIL PROTECTED] wrote:
I don't see anything in the ISO C standard that implies that.
This
x.v1 = 384;
x.v2 = 94.08;
int v = x.v2;
x.v1 = v;
is valid fragment.
But can you see anything in it that makes it undefined?
Failing that,
Hi,
On 2006-01-25 13:10:50 -0600, Aleksandar Milivojevic wrote:
Compile GMP 4.1.4:
$ ../configure ABI=32 --prefix=/gcc-test --enable-mpfr
You shouldn't use the MPFR version distributed with GMP; it is very
old and buggy. It is much better to compile GMP without MPFR support
then compile
Alexandre Oliva [EMAIL PROTECTED] writes:
| On Jan 26, 2006, Gabriel Dos Reis [EMAIL PROTECTED] wrote:
|
| I don't see anything in the ISO C standard that implies that.
|
| This
|
| x.v1 = 384;
| x.v2 = 94.08;
| int v = x.v2;
| x.v1 = v;
|
| is valid fragment.
|
| But
On 1/25/06, Diego Novillo [EMAIL PROTECTED] wrote:
You'll need to do what this message suggests. http://gcc.gnu.org/bugzilla/
Sorry for the lag.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25983
Quoting Vincent Lefevre [EMAIL PROTECTED]:
Hi,
On 2006-01-25 13:10:50 -0600, Aleksandar Milivojevic wrote:
Compile GMP 4.1.4:
$ ../configure ABI=32 --prefix=/gcc-test --enable-mpfr
You shouldn't use the MPFR version distributed with GMP; it is very
old and buggy. It is much better to
Snapshot gcc-4.0-20060126 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.0-20060126/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.0 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
I'm using store_data_bypass_p from recog.c as the guard for a define_bypass
within a machine description. I'm seeing the following warning/error that
I'd like to clean up.
cc1: warnings being treated as errors
insn-automata.c: In function 'internal_insn_latency':
insn-automata.c:53265: warning:
Peter Steinmetz wrote:
I'm using store_data_bypass_p from recog.c as the guard for a define_bypass
within a machine description. I'm seeing the following warning/error that
I'd like to clean up.
cc1: warnings being treated as errors
insn-automata.c: In function 'internal_insn_latency':
I'm working on a series of profile-driven optimes with gcc-3.4.3.
I need profile information available for the PRE phase (implemented in
gcc with gcse.c and lcm.c).
However, gcc-3.4.3 does not provide profile information that early in the
compile, so I moved the call to
Now that the GPL v3 looks as though it may be EPL-compatible, the time
has come to reconsider using the Eclipse java compiler (ecj) as our
primary gcj front end. This has both political and technical
ramifications, I discuss them below.
Steering committee members, please read through if you
Technical approach.
Historically we've wanted to have a 'native' java-source-code-reading
compiler, that is, one which parses java sources and converts them
directly to trees. From what I can remember this was based on 3
things:
A couple of other factors:
* Compile time. It is at least
Vincent Lefevre wrote:
You shouldn't use the MPFR version distributed with GMP; it is very
old and buggy. It is much better to compile GMP without MPFR support
then compile MPFR 2.2.0 separately: http://www.mpfr.org/mpfr-current/
Heh... If MPFR 2.2.0 (fully patched) is configured with
Il giorno mer, 25/01/2006 alle 22.29 +0100, Marcel Cox ha scritto:
I saw that stack instructions on Intel platform are not used that
much. I think this is a pity cause stack operations are small (size
optimization) and usually fast (from Pentium two consecutive push/pop
are executed
FYI, it is a linker bug:
http://sourceware.org/bugzilla/show_bug.cgi?id=2218
I posted a patch for it.
H.J.
The naked attribute is ignored on the intel architecture (according to
documentation). The MS VC++ compiler supports the naked attribute, and the
functionality is used there quite frequent.
A quick search on the internet shows that there is a lot of people waiting for
this feature (including
--- Comment #8 from laurent at guerby dot net 2006-01-26 08:02 ---
Waiting for feedback.
--
laurent at guerby dot net changed:
What|Removed |Added
--- Comment #3 from mmitchel at gcc dot gnu dot org 2006-01-26 08:36
---
I *said* P2 -- but apparently I didn't update the actual priority field. Done
now; sorry for the churn.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from dorit at il dot ibm dot com 2006-01-26 09:07 ---
Can you please send the dump files generated by -fdump-tree-vect-details?
reduc-dot-s16.c needs the sdot_prodv4hi pattern, which is implemented for ia64,
so I'd expect one loop to be vectorized. I wonder what's the
--- Comment #18 from charlet at gcc dot gnu dot org 2006-01-26 09:56
---
Adding dependency on PR 21553
--
charlet at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #22 from tobi at gcc dot gnu dot org 2006-01-26 10:14 ---
Fixed on trunk and 4.1.
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-01-26 11:06 ---
I believe the error is instead that
for (main_clone = cgraph_node (node-decl); main_clone;
main_clone = main_clone-next_clone)
if (main_clone == node)
break;
if (!node)
{
error (node
--- Comment #7 from amodra at gcc dot gnu dot org 2006-01-26 11:18 ---
Subject: Bug 25176
Author: amodra
Date: Thu Jan 26 11:18:39 2006
New Revision: 110251
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=110251
Log:
PR middle-end/25176
* function.c
--- Comment #8 from amodra at bigpond dot net dot au 2006-01-26 11:19
---
Fixed
--
amodra at bigpond dot net dot au changed:
What|Removed |Added
--- Comment #14 from pinskia at gcc dot gnu dot org 2006-01-26 12:22
---
Closing as works for me as Mark's email works for me.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Compile the following with -m64 -mlong-double-128 -O2 -S
long double
pack (double a, double aa)
{
union { long double ld; double d[2]; } u;
u.d[0] = a;
u.d[1] = aa;
return u.ld;
}
void
unpack (long double x, double *a, double *aa)
{
union { long double ld; double d[2]; } u;
u.ld = x;
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-26 12:28 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-26 12:29 ---
A quick question here. Why not use a .s file instead?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25967
--- Comment #3 from denisc at overta dot ru 2006-01-26 12:35 ---
Done.
--
denisc at overta dot ru changed:
What|Removed |Added
Severity|blocker
--- Comment #11 from denisc at overta dot ru 2006-01-26 12:55 ---
Change Status to FIXED.
--
denisc at overta dot ru changed:
What|Removed |Added
Status|NEW
-Wall produces warning on second function, not on slightly simpler first
function.
struct C {
C() { }
~C() {}
};
int fine(int p) {
C c;
if (p) {
if (p == 4) {
return 1;
} else {
return 2;
}
} else {
return 3;
}
}
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-26 13:57 ---
Confirmed, the problem is slightly different from PR 20624 (but it is related).
I might look at this more.
-
We are adding an extra goto when gimplifing. I have not looked why yet.
if (p == 4)
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.0.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25973
--- Comment #19 from hjl at lucon dot org 2006-01-26 14:20 ---
*** Bug 21553 has been marked as a duplicate of this bug. ***
--
hjl at lucon dot org changed:
What|Removed |Added
--- Comment #6 from hjl at lucon dot org 2006-01-26 14:20 ---
It is the same as PR 14435. I posted a one-line patch for it.
*** This bug has been marked as a duplicate of 14435 ***
--
hjl at lucon dot org changed:
What|Removed |Added
The following program should print Got a NaN:
gcc-4.0.2 nan.c ./a.out
Got a NaN
...but...
gcc-4.0.2 -ffast-math nan.c ./a.out
Ugh!
I don't think that is proper behaviour even for -ffast-math.
This came up because someone compiled Gnumeric with -ffast-math. It seems
that this option is
--- Comment #1 from terra at gnome dot org 2006-01-26 14:43 ---
Created an attachment (id=10732)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10732action=view)
Output from gcc-4.0.2 -E -ffast-math nan.c
gcc-4.0.2 -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-01-26 14:44 ---
Please read the docs about -ffast-math. It enables the option
-ffinite-math-only which means no NaNs.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-01-26 14:47 ---
-ffast-math
Sets -fno-math-errno, -funsafe-math-optimizations,
-fno-trapping-math, -ffinite-math-only, -fno-rounding-math, -fno-signaling-nans
and fcx-limited-range.
This option causes the preprocessor macro
| grep GOOD || exit 1
make: *** [foo.s] Error 1
[EMAIL PROTECTED] prefix]$
With my patch, I got
[EMAIL PROTECTED] prefix]$ make
/export/build/gnu/gcc/build-x86_64-linux/./prev-gcc//xgcc --version
xgcc (GCC) 4.2.0 20060126 (experimental) [trunk revision 110254 clean]
Copyright (C) 2006 Free Software
--- Comment #11 from pinskia at gcc dot gnu dot org 2006-01-26 14:59
---
Subject: Bug 25861
Author: pinskia
Date: Thu Jan 26 14:59:26 2006
New Revision: 110256
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=110256
Log:
2006-01-26 Andrew Pinski [EMAIL PROTECTED]
PR
--- Comment #12 from pinskia at gcc dot gnu dot org 2006-01-26 14:59
---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #20 from amylaar at gcc dot gnu dot org 2006-01-26 15:22
---
http://gcc.gnu.org/ml/gcc-patches/2006-01/msg01782.html was regression tested
successfully for sh-elf in Revision 110178.
However, it makes sense to write or collect a number of new test cases to test
the affected
--- Comment #22 from pinskia at gcc dot gnu dot org 2006-01-26 15:32
---
Patch posted:
http://gcc.gnu.org/ml/gcc-patches/2006-01/msg01843.html
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Hmm, the summary is really bad. I'm seeing the attached testcase to fail on
4.2.0 and 4.1.0, both with -O0 and with -O2.
--
Summary: miscompile with classes without copy constructor
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity:
--- Comment #1 from mueller at gcc dot gnu dot org 2006-01-26 15:40 ---
Created an attachment (id=10734)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10734action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25977
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-01-26 15:45 ---
retval = operator (retval, r) [return slot optimization];
We cannot do RSO here.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25977
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-01-26 15:50 ---
Confirmed. Very much related to PR 19317 so CCing Jason.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-01-26 15:54 ---
Hmm:
(void) (retval = *(struct A ) (struct A *) TARGET_EXPR D.1827, operator
(retval, (struct A ) (struct A *) r))
;
Maybe it is not fully related to PR 19317 but a different issue really.
--
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-01-26 15:58 ---
No feedback in 3 months (T-4 days).
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-01-26 15:58 ---
No feedback in 3 months (T-4 days).
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Because Darwin does not implement sem_init correctly all the tests timeout.
One way of fixing this is to change libgomp for Darwin to use the mach
semaphores.
Another way is to use named semaphores.
--
Summary: All libgomp tests timeout on ppc-darwin
Product: gcc
--- Comment #14 from bkoz at gcc dot gnu dot org 2006-01-26 16:32 ---
Gaby, here's the one thing that I can think of that changed between 3.4.x and
mainline/4.1 in this code path:
2005-10-10 Ian Lance Taylor ian@airs.com
PR libstdc++/13583
*
--- Comment #15 from bkoz at gcc dot gnu dot org 2006-01-26 16:35 ---
ps tom this kind of organization for compiling looks dreamy:
#20 0x400afc18 in compiler::do_analyze_unit (this=0x8055248, unit=0x8089dc0)
at exception.hh:63
#21 0x400afebf in compiler::semantic_analysis
--- Comment #16 from gdr at cs dot tamu dot edu 2006-01-26 16:44 ---
Subject: Re: g++ miscompiles gcjx
bkoz at gcc dot gnu dot org [EMAIL PROTECTED] writes:
| Gaby, here's the one thing that I can think of that changed between 3.4.x and
| mainline/4.1 in this code path:
Thank you
--- Comment #66 from yanov at il dot ibm dot com 2006-01-26 16:45 ---
Bootstrapped and tested on PowerPC linux. No regressions.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24626
--- Comment #17 from gdr at cs dot tamu dot edu 2006-01-26 16:45 ---
Subject: Re: g++ miscompiles gcjx
bkoz at gcc dot gnu dot org [EMAIL PROTECTED] writes:
| ps tom this kind of organization for compiling looks dreamy:
Yup! I dream of when other GCC parts would be similarly
--- Comment #10 from tobi at gcc dot gnu dot org 2006-01-26 16:46 ---
I don't know when I will have time for this, so I'm unassigning myself.
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from rcbilson at plg dot uwaterloo dot ca 2006-01-26 16:59
---
(In reply to comment #6)
class xxx is NOT a POD.
Indeed not. Thank you for explaining, and sorry to waste your time.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25927
--- Comment #9 from kazu at gcc dot gnu dot org 2006-01-26 17:07 ---
Posted a new patch.
--
kazu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from law at gcc dot gnu dot org 2006-01-26 17:14 ---
Subject: Bug 25900
Author: law
Date: Thu Jan 26 17:14:22 2006
New Revision: 110261
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=110261
Log:
PR ada/25900
* tree-vrp.c (extract_range_from_assert):
--- Comment #8 from law at redhat dot com 2006-01-26 17:14 ---
Subject: Re: [4.2 Regression] ACATS ICE cxac0004 in
set_value_range, at tree-vrp.c:161 on x86-linux
On Tue, 2006-01-24 at 15:12 -0700, Jeffrey A Law wrote:
That fixes cxac004, but causes c99004a to fail!
As
--- Comment #10 from law at redhat dot com 2006-01-26 17:14 ---
Fixed with today's patch to tree-vrp.c
--
law at redhat dot com changed:
What|Removed |Added
--- Comment #4 from terra at gnome dot org 2006-01-26 17:22 ---
ok, thanks. I'll prevent this by checking for __FAST_MATH__ in my code.
One could argue for a warning like
nan.c:13: warning: comparison is always false due to limited range of data type
for use of isnan and similarly
I'm not positive whether or not this is a duplicate of 25895. I figured I'd
better enter it just in case it wasn't. Test case:
#include stdio.h
struct A
{
A() : data1_(0), data2_(0) {}
A(int i, int j) : data1_(i), data2_(j) {}
A operator+(int);
friend A operator+(int, const A);
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-26 17:31 ---
This is actually a dup of bug 25977. But I think it was worked around in 4.0.2
(or maybe just 4.0.3, I have to double check that).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25979
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-01-26 17:36 ---
It was worked around in 4.0.2 (done on 2005-04-05 23:13:35) by:
PR c++/19317
* calls.c (expand_call): Disable return slot optimization.
Which just disabled the return slot optimization for 4.0.x
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-01-26 17:39 ---
Actually this is not a full dup as this one is also still broken on the 4.0
branch.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-01-26 17:43 ---
Confirmed, very much related to PR 25977. Though I think this and PR 25977 are
almost the same bug as we get:
TARGET_EXPR D.3014, Unknown tree: aggr_init_expr
operator+
3, (struct A ) (struct A *) a1
D.3014
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-01-26 17:36 ---
*** Bug 25979 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-01-26 17:50 ---
Fixed applied.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-01-26 17:51
---
Subject: Bug 17064
Author: pinskia
Date: Thu Jan 26 17:51:25 2006
New Revision: 110263
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=110263
Log:
2006-01-26 Richard Guenther [EMAIL PROTECTED]
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-01-26 17:51 ---
Subject: Bug 21470
Author: pinskia
Date: Thu Jan 26 17:51:25 2006
New Revision: 110263
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=110263
Log:
2006-01-26 Richard Guenther [EMAIL PROTECTED]
--- Comment #11 from pinskia at gcc dot gnu dot org 2006-01-26 17:51
---
The partial fix has been applied, I have another patch which fixes another part
of this but still not fully.
It just helps the call cloberring mechanism.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17064
--- Comment #12 from dberlin at gcc dot gnu dot org 2006-01-26 17:53
---
Fixed
--
dberlin at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from sje at cup dot hp dot com 2006-01-26 18:00 ---
See
http://gcc.gnu.org/ml/gcc-patches/2006-01/msg01864.html
http://gcc.gnu.org/ml/gcc-patches/2006-01/msg01779.html
For the two patches needed to fix this.
Waiting for approval.
--
sje at cup dot hp dot com
--- Comment #12 from pinskia at gcc dot gnu dot org 2006-01-26 18:15
---
This is the patch which helps the call clobering but does not fix it all the
way (because a different call clobbering issue):
Index: tree-ssa-alias.c
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |critical
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25979
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P5
Target Milestone|4.2.0 |4.1.0
The following fails to compile, it would appear that symbols from seperate
namespaces are colliding in error:
[EMAIL PROTECTED] tmp]$ cat test2.cpp
namespace ns1 {
class c {};
typedef int f;
static c x;
}
namespace ns2 {
void f(ns1::c cc)
{
}
void g()
{
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-26 18:49 ---
I think you (and EDG) are missing what argument dependent lookup does for this
case.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25980
--- Comment #7 from aoliva at gcc dot gnu dot org 2006-01-26 18:50 ---
Subject: Bug 25892
Author: aoliva
Date: Thu Jan 26 18:50:37 2006
New Revision: 110265
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=110265
Log:
gcc/ChangeLog:
PR c/25892
* c.opt (Wpointer-sign): Init to -1.
*
--- Comment #3 from sje at cup dot hp dot com 2006-01-26 18:55 ---
These tests pass for me on the 4.1 branch and on mainline.
--
sje at cup dot hp dot com changed:
What|Removed |Added
--- Comment #2 from gdr at cs dot tamu dot edu 2006-01-26 18:56 ---
Subject: Re: New: Unexpected name conflict between symbols
dwhorton at gmail dot com [EMAIL PROTECTED] writes:
| The following fails to compile, it would appear that symbols from seperate
| namespaces are colliding
--- Comment #2 from pault at gcc dot gnu dot org 2006-01-26 19:01 ---
The patch is on its way in the next hour or so
Statement functions = internal procedures, as far as the standard is concerned.
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25964
--- Comment #8 from aoliva at gcc dot gnu dot org 2006-01-26 19:06 ---
Subject: Bug 25892
Author: aoliva
Date: Thu Jan 26 19:06:06 2006
New Revision: 110267
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=110267
Log:
gcc/ChangeLog:
PR c/25892
* c.opt (Wpointer-sign): Init to -1.
*
--- Comment #9 from aoliva at gcc dot gnu dot org 2006-01-26 19:09 ---
Fixed
--
aoliva at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
1 - 100 of 160 matches
Mail list logo
