I ran into a template-y ICE building a real app with gcc-4.0.1:
my-callback-specializations.h: At global scope:
my-callback-specializations.h: In instantiation of
'_MemberResultCallback_0_1':
my-flow.cc:894: instantiated from here
my-callback-specializations.h:2064: internal compiler error: in
Hi all,
I have recently downloaded, configured, bootstrapped and tested gcc 4.0.1 and
found the same problem that I reported for gcc 3.4.0 as PR/15356.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15356
See also the threads "gcc testsuite apparently can't find g++"
http://gcc.gnu.org/ml/gcc-help/2
On 22/07/2005, at 7:57 PM, Gabriel Dos Reis wrote:
There is a "semantics of access". It is implementation-defined.
I think you're thinking of "what constitutes an access", which is
implementation-defined, but is not the same of the semantics of an
access.
The standard describes things
On 22/07/2005, at 7:15 PM, Paul Schlie wrote:
Geoffrey Keating writes:
without 'volatile', then this object cannot be modified unknown to
the
implementation, even if someone also writes '(*(volatile int *)&i)
= 1'.
- merely means: treat the object being referenced as volatile
qualif
> From: Geoff Keating <[EMAIL PROTECTED]>
> On 22/07/2005, at 7:15 PM, Paul Schlie wrote:
>
>>> Geoffrey Keating writes:
>
>>> without 'volatile', then this object cannot be modified unknown to
>>> the implementation, even if someone also writes '(*(volatile int *)&i)
>>> = 1'.
>>
>> - merely me
(sorry, with intended statement this time)
> From: Geoff Keating <[EMAIL PROTECTED]>
> On 22/07/2005, at 7:15 PM, Paul Schlie wrote:
>
>>> Geoffrey Keating writes:
>
>>> without 'volatile', then this object cannot be modified unknown to
>>> the implementation, even if someone also writes '(*(vol
From: Dale Johannesen <[EMAIL PROTECTED]>
Date: Thu, 21 Jul 2005 16:56:01 -0700
On x86 currently the alignments of double and long long are linked:
they are either 4 or 8 depending on whether -malign-double is set.
This follows the documentation of -malign-double. But it's wrong fo
Mark Kettenis wrote:
>From: Dale Johannesen <[EMAIL PROTECTED]>
>Date: Thu, 21 Jul 2005 16:56:01 -0700
>
>On x86 currently the alignments of double and long long are linked:
>they are either 4 or 8 depending on whether -malign-double is set.
>This follows the documentation of -
On Fri, 2005-07-22 at 17:53 -0700, Steve Kargl wrote:
> On Fri, Jul 22, 2005 at 05:44:44PM -0700, Jerry DeLisle wrote:
> > Steve Kargl wrote:
> > >Does this look familiar to anyone?
> > >
> > I was having troubles doing a build after a cvs update. I had to delete
> > everything in the build direc
On Sat, Jul 23, 2005 at 08:29:19AM +0200, Thomas Koenig wrote:
> On Fri, Jul 22, 2005 at 10:01:43PM -0700, Steve Kargl wrote:
>
> > This is caused by
> >
> > 2005-07-21 Richard Henderson <[EMAIL PROTECTED]>
>
> Really?
Yes. I spent nearly 6 hours last night searching for
the quilty commit.
On Friday, July 22, 2005, at 06:28 PM, Geoff Keating wrote:
I am discussing here only with what GCC *could* do, and still be
standards-conforming. What it *should* do is a different > conversation.
You will have to explain the benefits to me of having discussions on
this list of discussing th
On Sat, Jul 23, 2005 at 07:30:08AM -0700, Steve Kargl wrote:
> > I have that in my tree (gcc version 4.1.0 20050722 (experimental)), but
> > don't experience that failure.
> >
> > See my comments on PR 22623.
>
> Your comments are not relevant.
Well I don't see the failure either.
r~
On Sat, Jul 23, 2005 at 10:08:07AM -0700, Richard Henderson wrote:
> On Sat, Jul 23, 2005 at 07:30:08AM -0700, Steve Kargl wrote:
> > > I have that in my tree (gcc version 4.1.0 20050722 (experimental)), but
> > > don't experience that failure.
> > >
> > > See my comments on PR 22623.
> >
> > You
On Jul 23, 2005, at 6:40 AM, Tobias Schlüter wrote:
I have a strong suspicion there is a reason why the two are linked,
and that that reason is FORTRAN. A lot of FORTRAN code assumes
EQUIVALENCE of floating-point and integer types of equal size. Such
code will in all likelyhood break if those
On Sat, Jul 23, 2005 at 10:17:25AM -0700, Steve Kargl wrote:
> Note, you need to start with either an empty object tree
> and do a complete bootstrap or remove the libgfortran directory
> and do a bubblestrap.
I always start from zero.
I can see a failure from pinski's reduced test case. Fixed
b
Snapshot gcc-4.1-20050723 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20050723/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.1 CVS branch
with the following options: -D2005-07-23 17:43 UTC
You'll
On Sat, Jul 23, 2005 at 10:31:46AM -0700, Richard Henderson wrote:
> On Sat, Jul 23, 2005 at 10:17:25AM -0700, Steve Kargl wrote:
> > Note, you need to start with either an empty object tree
> > and do a complete bootstrap or remove the libgfortran directory
> > and do a bubblestrap.
>
> I always
On 07/16/2005 03:14 PM, Maurizio Monge wrote:
[snip]
the informations i was looking for about the cxx reflection branch
[snip]
branch, as i was planning to try add to gcc some extension to
allow things like:
template
serialize(const T& t)
Isn't boost's serialization library:
http://www.bo
Hello,
I have quite a surpising behavior with gcc when compiling the following
code (*). Here is the output:
$ g++ deprecated.cxx /tmp
deprecated.cxx: In constructor `A::A(int)':
deprecated.cxx:11: warning: `A' is deprecated (declared at deprecated.cxx:9)
> Geoffrey Keating wrote:
>> Mirco Lorenzon wrote:
>>
>> .., are comparisons in the following program legal code?
>
> No.
>
>> ...
>> void *a, *b;
>> ...
>> if (a < b)
>
> Because 'a' and 'b' are not part of the same array,
> the behaviour is undefined.
Although I don't mean to contest the conclu
Devang Patel wrote:
C++ does not generate debug info for anonymous aggregates in cases like :
class A
{
public:
typedef struct
{
int d;
} mystruct;
mystruct data;
};
This is because FE sets DECL_IGNORED_P bit. This causes debug info
generator to
skip debug info wh
Mathieu Malaterre <[EMAIL PROTECTED]> writes:
> I have quite a surpising behavior with gcc when compiling the
> following code (*). Here is the output:
>
> $ g++ deprecated.cxx /tmp
> deprecated.cxx: In constructor `A::A(int)':
> deprecated.cxx:11: warn
Hi,
Some idea: Maybe local stack use in the code compiled by GCC should be
optimized 'cause some local variables are conditional. If the condition
is not satisfied, then these variables don't need to be allocated from
the stack (e.g. sub $VAR_SIZE, %esp).
For example:
int *func(unsigned int con
Hanzac Chen <[EMAIL PROTECTED]> writes:
> Some idea: Maybe local stack use in the code compiled by GCC should be
> optimized 'cause some local variables are conditional. If the condition
> is not satisfied, then these variables don't need to be allocated from
> the stack (e.g. sub $VAR_SIZE, %esp)
Ian Lance Taylor wrote:
You neglected to mention which version of gcc you were using, or which
target. The description and test case sound like GCC PR 9997:
http://gcc.gnu.org/PR9997
which was fixed for the 4.0 release.
Sorry, I'm using GCC 3.4.4, haven't tested on 4.0.X.
I saw the PR 9997,
25 matches
Mail list logo
