On Mon, 2009-09-21 at 13:06 -0400, Jason Merrill wrote:
> On 09/14/2009 11:54 AM, Jason Merrill wrote:
> > I think the way to go with this is to revert the compiler bits of
> > r149964, not mess with mangle.c at all, and insert the initial * if the
> > typeinfo name won't have TREE_PUBLIC set, sinc
The following causes missed loop optimizations in O2 from creating
unnecessary loop induction variables. Or, is a case of IV opts not
able to coalesce copies of induction variables. A previous post related
to this was made in PR41026 which had a type promoted loop index
variable
copied. I believe t
I have a theory that if both displacements in the S-type (ie register plus
displacement) address are non-zero, that something fails. So the
next thing I will do is see if I can detect just that situation, and stop
it going into the CLC.
I now have that detection in place, and done a self-compil
On Tue, Sep 22, 2009 at 1:52 PM, Rahul Kharche wrote:
> The following causes missed loop optimizations in O2 from creating
> unnecessary loop induction variables. Or, is a case of IV opts not
> able to coalesce copies of induction variables. A previous post related
> to this was made in PR41026 wh
On 09/22/2009 07:04 AM, Jerry Quinn wrote:
On Mon, 2009-09-21 at 13:06 -0400, Jason Merrill wrote:
On 09/14/2009 11:54 AM, Jason Merrill wrote:
I think the way to go with this is to revert the compiler bits of
r149964, not mess with mangle.c at all, and insert the initial * if the
typeinfo name
On Mon, 21 Sep 2009, Jon Beniston wrote:
> Probably best to review an updated patch which is attached, which implements
> all the 4.5 changes.
The target-side files now need to use the new GPLv3 exception, not the old
GPLv3 one.
> * config/lm32/xm-lm32.h: New file.
As I said before, th
The SC has decided to remove powerpc-apple-darwin from the secondary
platform list (due to the fact that Apple is no longer supporting
Power in OS X and Apple's overall shift from Power to x86) and to move
i686-apple-darwin from the primary to the secondary platform list (due
to the lack of active
Ian Lance Taylor wrote:
"Amker.Cheng" writes:
In function new_ready, it calls to min_insn_conflict_delay with
"min_insn_conflict_delay (curr_state, next, next)".
But the function's comments say that it returns minimal delay of issue of
the 2nd insn after issuing the 1st in given state.
W
Gerald Pfeifer writes:
> It turns out that IRIX and OSF have not managed to keep Rainer Orth
> sufficiently busy after I sent
>
> http://gcc.gnu.org/ml/gcc/2006-07/msg00654.html
>
> so I am pleased to announce that the steering committee is appointing
> him maintainer for our Solaris ports as
* Gabriel Dos Reis:
>>> Is this intentional? The equivalent "new char[a][b]" is rejected (as
>>> required by the C++ standard).
>>
>> Is there any reason that g++ should reject your sample program?
>
> Yes: there is no obvious reason for gratuitous incompatibility in
> semantics.
That, and it re
* Joel Sherrill:
> What is the proper type to use in an Ada binding
> for a C method that returns a C99 bool?
Whatever the answer is, it should be used to define Interfaces.C.Bool.
(I don't know what GCC's options for representing _Bool are, sorry.)
Florian Weimer wrote:
* Joel Sherrill:
What is the proper type to use in an Ada binding
for a C method that returns a C99 bool?
Whatever the answer is, it should be used to define Interfaces.C.Bool.
(I don't know what GCC's options for representing _Bool are, sorry.)
It appears t
On Tue, Sep 22, 2009 at 12:54 PM, Joel Sherrill
wrote:
> Florian Weimer wrote:
>>
>> * Joel Sherrill:
>>
>>
>>>
>>> What is the proper type to use in an Ada binding
>>> for a C method that returns a C99 bool?
>>>
>>
>> Whatever the answer is, it should be used to define Interfaces.C.Bool.
>> (I do
* Joel Sherrill:
>> Whatever the answer is, it should be used to define Interfaces.C.Bool.
>> (I don't know what GCC's options for representing _Bool are, sorry.)
> It appears to be unsigned char or at least sizeof(bool)=1
> on the architectures I tried this test program on.
That's only half of
On Tue, 22 Sep 2009, Joel Sherrill wrote:
> It appears to be unsigned char or at least sizeof(bool)=1
> on the architectures I tried this test program on.
The size is determined by BOOL_TYPE_SIZE (and is not 1 byte for
powerpc-darwin).
--
Joseph S. Myers
jos...@codesourcery.com
No nasty surprises this time. Bootstrapped on x86_64 and x86.
Diego.
On Tue, Sep 22, 2009 at 17:37, Diego Novillo wrote:
> No nasty surprises this time. Bootstrapped on x86_64 and x86.
Gah, I lied. On x86, the build failed with:
dwarf2out.c:414: option `param_is' may only be applied to structures
or structure pointers.
This happens in many other files. Anyon
Snapshot gcc-4.4-20090922 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20090922/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.4 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
Hi,
Probably a long shot but I wonder if anyone would have a useful tip on a
problem porting gcc4.4.0 to interix (a BSD-like OS running on top of the
Windows kernel).
As libgomp in GCC so far isn't targeting interix I have made some changes to
libgomp in my copy of the GCC 4.4.0
distribution
I've been implementing ISO/IEC TR 24733, "an extension for the
programming language C++ to support decimal floating-point arithmetic",
in GCC. It might be ready as an experimental feature for 4.5, but I
would particularly like to get in the compiler changes that are needed
for it.
Most of the sup
Will the lambda branch be merged into 4.5?
-Kenny
21 matches
Mail list logo
