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,
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)
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
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
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
> 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
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)
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
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
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: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
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: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 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 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 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 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
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 -
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
(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: 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
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
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
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
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
25 matches
Mail list logo
