The problem relates to functoid objects ("function like" objects, ie
ones with an operator() defined) and references to them within a
namespace. When Koenig lookup is used to find such a
reference-to-functoid, g++ seems to find it okay, but then states
"cannot be used as a function". If I use
--
phython at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24066
--- Comment #3 from phython at gcc dot gnu dot org 2005-11-07 07:03 ---
Fixed in the commit message that shows up in PR21952.
--
phython at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #6 from phython at gcc dot gnu dot org 2005-11-07 07:02 ---
The last commit was meant for PR24066
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21952
--- Comment #5 from phython at gcc dot gnu dot org 2005-11-07 06:55 ---
Subject: Bug 21952
Author: phython
Date: Mon Nov 7 06:54:52 2005
New Revision: 106582
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106582
Log:
2005-11-07 James A. Morrison <[EMAIL PROTECTED]>
P
--- Comment #14 from jason at gcc dot gnu dot org 2005-11-07 06:17 ---
Subject: Bug 17256
Author: jason
Date: Mon Nov 7 06:17:47 2005
New Revision: 106581
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106581
Log:
PR c++/17256
* decl2.c (cp_finish_file): Fix con
--- Comment #6 from pcarlini at suse dot de 2005-11-07 02:49 ---
(In reply to comment #5)
> http://gcc.gnu.org/ml/gcc/2005-11/msg00326.html
>
> In short, you'll never get a completely unified way to implement these
> routines.
Disagree, see: http://gcc.gnu.org/ml/gcc/2005-11/msg00332.h
--- Comment #19 from ian at airs dot com 2005-11-07 02:26 ---
Created an attachment (id=10160)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10160&action=view)
Patch
I'm testing this patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24683
--- Comment #3 from dberlin at gcc dot gnu dot org 2005-11-06 23:59 ---
Subject: Re: New: Address taken and
addressable variables and call clobber
On Sun, 2005-11-06 at 15:46 +, pinskia at gcc dot gnu dot org wrote:
> Take the following code:
> int f(int);
> int g(void)
>
On Sun, 2005-11-06 at 15:46 +, pinskia at gcc dot gnu dot org wrote:
> Take the following code:
> int f(int);
> int g(void)
> {
> int i;
> int *iptr = &i;
> int **ipp = &iptr;
> **ipp = 1;
> f(i);
> return **ipp;
> }
> --
> Here we consider i being call clobber because we lo
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2005-11-06 23:58
---
Testing that patch gives the following results. I will put together a test
case and commit this as obvious unless there are objections.
hex dump of TEST file created using gfortran 4.0.1 gives, with no patch:
$
The following program from http://gcc.gnu.org/ml/fortran/2005-11/msg00084.html
incorrectly writesthe 'TEST' file. Thanks to Georgy Salnikov for finding and
submitting this bug.
PROGRAM TEST
CHARACTER*8 TXT
DATA TXT/'**TEST**'/
OPEN (1, FILE='TEST', STATUS='UNKNOWN', FORM
The following reduced test case fails to correctly read the same line twice
from the input file. This was derived from the new Polyhedron test aermod.f90
which fails.
character*132 :: rdfrm, runst1, foost
character*1 :: runst(132)
inunit = 11
open (inunit, file = "AERMODT
--- Comment #5 from rth at gcc dot gnu dot org 2005-11-06 23:40 ---
http://gcc.gnu.org/ml/gcc/2005-11/msg00326.html
In short, you'll never get a completely unified way to implement these
routines.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24692
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-11-06 23:27 ---
I have a patch.
Caused by:
2005-07-14 Daniel Berlin <[EMAIL PROTECTED]>
Fix PR c++/22452
* tree.c (decl_linkage): Don't check DECL_COMDAT on CONST_DECL.
--
pinskia at gcc dot gnu dot org change
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-11-06 23:23 ---
Actually it should be NULL as it is in a template.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24687
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-11-06 23:21 ---
The CONST_DECL's type is null.
Seems like it should be error_mark_node instead.
Looking more into it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24687
--- Comment #13 from pault at gcc dot gnu dot org 2005-11-06 22:55 ---
Fixed on mainline and 4.0
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from pault at gcc dot gnu dot org 2005-11-06 22:54 ---
Fixed on mainline and 4.0
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
S
--- Comment #5 from pault at gcc dot gnu dot org 2005-11-06 22:53 ---
Fixed on mainline and 4.0
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
S
--- Comment #11 from pault at gcc dot gnu dot org 2005-11-06 22:51 ---
Fixed on mainline and 4.0.
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pault at gcc dot gnu dot org 2005-11-06 22:50 ---
Subject: Bug 20840
Author: pault
Date: Sun Nov 6 22:50:38 2005
New Revision: 106572
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106572
Log:
2005-11-06 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #12 from pault at gcc dot gnu dot org 2005-11-06 22:50 ---
Subject: Bug 17737
Author: pault
Date: Sun Nov 6 22:50:38 2005
New Revision: 106572
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106572
Log:
2005-11-06 Paul Thomas <[EMAIL PROTECTED]>
PR fortran
--- Comment #10 from pault at gcc dot gnu dot org 2005-11-06 22:50 ---
Subject: Bug 24534
Author: pault
Date: Sun Nov 6 22:50:38 2005
New Revision: 106572
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106572
Log:
2005-11-06 Paul Thomas <[EMAIL PROTECTED]>
PR fortran
--- Comment #4 from pault at gcc dot gnu dot org 2005-11-06 22:50 ---
Subject: Bug 20838
Author: pault
Date: Sun Nov 6 22:50:38 2005
New Revision: 106572
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106572
Log:
2005-11-06 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #11 from halcy0n at gentoo dot org 2005-11-06 20:29 ---
This is reproducable on gcc mainline on amd64:
{standard input}: Assembler messages:
{standard input}:510: Error: can't resolve `.text.unlikely' {.text.unlikely
section} - `.LFB96' {.text section}
Building gcc-4.1.0_be
--- Comment #9 from pault at gcc dot gnu dot org 2005-11-06 20:05 ---
Subject: Bug 24534
Author: pault
Date: Sun Nov 6 20:05:12 2005
New Revision: 106567
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106567
Log:
2005-11-06 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #3 from pault at gcc dot gnu dot org 2005-11-06 20:05 ---
Subject: Bug 20840
Author: pault
Date: Sun Nov 6 20:05:12 2005
New Revision: 106567
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106567
Log:
2005-11-06 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #11 from pault at gcc dot gnu dot org 2005-11-06 20:05 ---
Subject: Bug 17737
Author: pault
Date: Sun Nov 6 20:05:12 2005
New Revision: 106567
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106567
Log:
2005-11-06 Paul Thomas <[EMAIL PROTECTED]>
PR fortran
--- Comment #3 from pault at gcc dot gnu dot org 2005-11-06 20:05 ---
Subject: Bug 20838
Author: pault
Date: Sun Nov 6 20:05:12 2005
New Revision: 106567
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106567
Log:
2005-11-06 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #8 from mmitchel at gcc dot gnu dot org 2005-11-06 19:59
---
Showstopper; crash on valid code.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #14 from mmitchel at gcc dot gnu dot org 2005-11-06 19:56
---
Fixed in 4.1.0.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Summ
--- Comment #13 from mmitchel at gcc dot gnu dot org 2005-11-06 19:53
---
*** Bug 18462 has been marked as a duplicate of this bug. ***
--
Bug 21308 depends on bug 18462, which changed state.
Bug 18462 Summary: [3.4 Regression] Segfault on declaration of large array
member
http://g
--- Comment #12 from mmitchel at gcc dot gnu dot org 2005-11-06 19:53
---
*** This bug has been marked as a duplicate of 21308 ***
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
--
Sorry for the vague description and huge test case - I don't speak Java beyond
the "it looks a lot like C++" level.
Trying to use a gcj 4.1 SVN rev 106562-compiled ecj (built using the workaround
from bug 24441) results in a SIGABRT when trying to translate any .java file
(even a simple helloworld
--- Comment #12 from mmitchel at gcc dot gnu dot org 2005-11-06 19:41
---
Subject: Bug 21308
Author: mmitchel
Date: Sun Nov 6 19:41:18 2005
New Revision: 106566
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106566
Log:
PR c++/21308
* class.c (sizeof_biggest_em
--- Comment #6 from green at redhat dot com 2005-11-06 18:41 ---
Created an attachment (id=10159)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10159&action=view)
A patch
I think the attached patch will fix.
--
green at redhat dot com changed:
What|Removed
--- Comment #12 from frederic dot riss at gmail dot com 2005-11-06 18:35
---
When I read the standard, I thought that 'reference to a class type' was used
in a sort of general way covering pointers and C++ references. I interpreted
this that way because I don't see what difference it co
--- Comment #3 from jb at gcc dot gnu dot org 2005-11-06 18:28 ---
Subject: Bug 24305
Author: jb
Date: Sun Nov 6 18:28:22 2005
New Revision: 106563
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106563
Log:
gfortran ChangeLog
2005-11-06 Janne Blomqvist <[EMAIL PROTECTED]>
--- Comment #11 from jb at gcc dot gnu dot org 2005-11-06 18:28 ---
Subject: Bug 24174
Author: jb
Date: Sun Nov 6 18:28:22 2005
New Revision: 106563
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106563
Log:
gfortran ChangeLog
2005-11-06 Janne Blomqvist <[EMAIL PROTECTED]>
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com
|dot org
--- Comment #11 from pcarlini at suse dot de 2005-11-06 17:57 ---
Ah, ah, the addresses should be equal in the first place! Ok, thanks for
looking
into this.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20647
--
nathan at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |nathan at gcc dot gnu dot
|dot org
--- Comment #10 from nathan at gcc dot gnu dot org 2005-11-06 17:54 ---
A * is not a reference to an incomplete type, but a pointer to one, so 5.2.8.4
does not apply. I'm fairly certain the correct output should be 'OK'. The two
type id objects should have different addresses (one shou
--- Comment #7 from green at redhat dot com 2005-11-06 17:51 ---
I'm unable to reproduce this with GCC 4.0.1 (x86 Linux).
Could you please try a more recent compiler?
If you are able to reproduce, could you please submit your example in the form
of a test case for the libffi testsuite?
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|WAITING |NEW
Last reconfirmed|2005-09-20 19:06:43 |2005-11-06 17:47:3
--- Comment #9 from pcarlini at suse dot de 2005-11-06 17:36 ---
Ok, I'm closing this, because the ABI, if not the standard, seems really
unequivocal. About the warning, I don't know, probably it's not that easy
to implement, I also looked for it, but no other compiler I have at hand
app
--- Comment #13 from danglin at gcc dot gnu dot org 2005-11-06 17:32
---
Fails on hppa2.0w-hp-hpux11.11 with 4.0.0, 4.0.1 and 4.0.2. However, it
doesn't fail using 3.4.4.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23837
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-06 17:14 ---
The mainline gives:
f:
.LFB2:
decq%rdx
movl$1, %eax
testq %rdi, %rdx
jne .L4
xorl%eax, %eax
testq %rsi, %rdx
setne %al
.L4:
rep ;
--- Comment #8 from pcarlini at suse dot de 2005-11-06 17:10 ---
(In reply to comment #7)
> section 2.9.3, and then the last sentence of 2.9.5/7... In your example the
> NTBS addresses (returned by type_info::name()) seem equal...
Sorry, I was wrong! The names, the strings, are equal,
Take this little program:
int
f (unsigned long a, unsigned long b, unsigned long c)
{
return (a & (c - 1)) != 0 || (b & (c - 1)) != 0;
}
Compiled on x86-64 with gcc 4.0.2 (but I think also with the current mainline)
yields with -O2 the following code:
:
0: 48 ff ca
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-06 17:05 ---
Are you sure that it is using the newest binutils?
.cpu and .fpu was added 10-08.
http://sourceware.org/ml/binutils-cvs/2005-10/msg00032.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24695
--- Comment #7 from pcarlini at suse dot de 2005-11-06 17:03 ---
(In reply to comment #6)
> I nearly forgot that I submitted this bug report...
> [...]
At first, I was under the same impression - not a bug - however, I'm not sure
anymore... Have also a look to the ABI:
http://www.co
Trying to generate an i686 -> armv5te EABI crosscompiler using both binutils
and gcc csl-arm-branch checkouts from today fails with
/home/oe/tmp/work/gcc-cross-initial-3.4.4+csl-arm-20051105-r0/csl-arm-branch/b
uild.i686-linux.arm-linuxeabi/gcc/xgcc
-B/home/oe/tmp/work/gcc-cross-initial-3.4
.4+csl
--- Comment #18 from phython at gcc dot gnu dot org 2005-11-06 16:51
---
Fixed on the 4.0 branch as well.
--
phython at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-11-06 16:35 ---
I am starting to think what 3.4.x did was just an accident that it got it right
in the first place.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #6 from frederic dot riss at gmail dot com 2005-11-06 16:33
---
I nearly forgot that I submitted this bug report...
I got myself a version of the C++ standard since I submitted that, and I just
had a look at the part describing typeid :
5.2.8.4 reads : "When typeid is appl
--- Comment #5 from pcarlini at suse dot de 2005-11-06 16:19 ---
Nathan, can you have a look to this PR? (Googling reveals a lot of hits for
nathan & typeid ;) Thanks in advance.
--
pcarlini at suse dot de changed:
What|Removed |Added
-
--- Comment #6 from aph at gcc dot gnu dot org 2005-11-06 16:15 ---
You can get the class by generating a special-purpose thunk using the libffi
invocation interface and pointing the vector at the thunk.
Virtual methods are easy to do by adding a suitable "NoClassDefFoundError"
method t
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-06 16:08 ---
Note this is not fixed on the iab.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24694
--- Comment #4 from pcarlini at suse dot de 2005-11-06 15:58 ---
FWIW, is also "KO" with ICC 9.0.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20647
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-06 15:47 ---
Found this while looking a little into PR 24689.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24694
Take the following code:
int f(int);
int g(void)
{
int i;
int *iptr = &i;
int **ipp = &iptr;
**ipp = 1;
f(i);
return **ipp;
}
--
Here we consider i being call clobber because we lose the fact that iptr is
addressable but we don't look to see if its address escapes at all (which
--- Comment #2 from bero at arklinux dot org 2005-11-06 15:32 ---
An alternative way of building that doesn't trigger this error:
cd build/bin
find -name '*.java' >filelist
gcj -C @filelist
That compiles all classes without complaining, but I suspect it of generating
broken code (will
--- Comment #11 from tkoenig at gcc dot gnu dot org 2005-11-06 15:01
---
(In reply to comment #10)
> Thomas, can you point to the text in the standard that
> prohibits the equivalence of integer and logical. AFAICT,
> the 4th constraint in 5.5.1, contradicts your assertation.
I was wr
--- Comment #4 from dnovillo at gcc dot gnu dot org 2005-11-06 14:56
---
Fixed. http://gcc.gnu.org/ml/gcc-patches/2005-11/msg00405.html
--
dnovillo at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #3 from dnovillo at gcc dot gnu dot org 2005-11-06 14:51
---
Subject: Bug 24670
Author: dnovillo
Date: Sun Nov 6 14:51:16 2005
New Revision: 106562
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106562
Log:
PR 24670
* tree-vrp.c (fix_equivalence_se
--- Comment #4 from pcarlini at suse dot de 2005-11-06 14:28 ---
(In reply to comment #3)
> Let first point out i486 is more than 15 years old.
Sure, but it's not up to me and you to decide what is on the market, in
embedded form or otherwise. And it's not only about i386, again, please
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-11-06 14:25 ---
(In reply to comment #2)
Let first point out i486 is more than 15 years old.
Second why do you really need an uniform way? This seems like a way to make
everything in the compiler. Maybe next you will be asking for
--- Comment #2 from pcarlini at suse dot de 2005-11-06 14:13 ---
(In reply to comment #1)
> Maybe the easy way to fix this is just have the distro change their policy of
> compiling with i386 to compile always with i686.
Indeed, that's one point. However, there isn't only i386 to cause
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-06 14:10 ---
Maybe the easy way to fix this is just have the distro change their policy of
compiling with i386 to compile always with i686.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24692
--- Comment #6 from pcarlini at suse dot de 2005-11-06 13:10 ---
Fixed for 4.0.3.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|NEW
--- Comment #5 from paolo at gcc dot gnu dot org 2005-11-06 13:09 ---
Subject: Bug 18174
Author: paolo
Date: Sun Nov 6 13:09:50 2005
New Revision: 106561
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106561
Log:
2005-11-06 Paolo Carlini <[EMAIL PROTECTED]>
PR libstd
--- Comment #4 from paolo at gcc dot gnu dot org 2005-11-06 13:07 ---
Subject: Bug 18174
Author: paolo
Date: Sun Nov 6 13:07:11 2005
New Revision: 106560
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106560
Log:
2005-11-06 Paolo Carlini <[EMAIL PROTECTED]>
PR libstd
version 4.1.0 20051106 (experimental)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24497
--- Comment #12 from steven at gcc dot gnu dot org 2005-11-06 11:50 ---
Folks, what's up with this bug? Is it HPPA-only now? Can someone comment on
the status of this bug please?
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from amodra at bigpond dot net dot au 2005-11-06 11:09
---
Revised patch http://gcc.gnu.org/ml/gcc-patches/2005-11/msg00388.html
--
amodra at bigpond dot net dot au changed:
What|Removed |Added
--
--
pcarlini at suse dot de changed:
What|Removed |Added
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24692
This is to track this issue:
http://gcc.gnu.org/ml/libstdc++/2005-11/msg00031.html
A first part, about _M_erase_at_end/_M_erase_at_begin, should be doable
relatively
quickly.
--
Summary: Deque improvements
Product: gcc
Version: 4.1.0
Status: UNCON
This is to track this issue:
http://gcc.gnu.org/ml/gcc/2005-11/msg00285.html
In a nutshell, we need an easy way to exploit the new atomic builtins in the
library, irrespective of the actual target.
--
Summary: Atomic builtins for v3
Product: gcc
Version: 4.1.
--- Comment #21 from simon dot strandman at telia dot com 2005-11-06 09:50
---
(In reply to comment #18)
> I posted an updated patch
>
> http://gcc.gnu.org/ml/gcc-patches/2005-02/msg00196.html
>
> I hope it will work better.
Sorry to bother but where is the updated patch? That link l
--- Comment #26 from ebotcazou at gcc dot gnu dot org 2005-11-06 08:42
---
> How does stopping violate the standard? If the standard says behavior is
> undefined, then you can do anything you want, including stopping.
You're confusing compile time and run time. Please read the whole
82 matches
Mail list logo
