Thanks Daniel for the useful piece of information.
Initially I thought of error from compiler side...Now I consider
upgrading my gdb .
Thanks,
Sumanth
Daniel Jacobowitz wrote:
On Sat, Apr 25, 2009 at 10:35:07AM -0700, Ian Lance Taylor wrote:
Yes, while there are of course occasional bugs
On Tue, Apr 28, 2009 at 11:12 PM, Mark Mitchell wrote:
> We're in Stage 1, and in Stage 1 big changes happen -- and then there is
> naturally some instability. We clearly have some instability at
> present, so we need to slow down until that's resolved.
Bah.
> With the benefit of hindsight, I
Snapshot gcc-4.4-20090428 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20090428/
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
On Tue, 2009-04-28 at 14:52 -0700, Doug Kwan (關振德) wrote:
> I would like to run the testsuite using qemu as the gdb simulator does
> not support newer ARMs. However, there does not seems to be any good
> documents on that topic. Could someone give me a pointer or two?
If you are running a full
I would like to run the testsuite using qemu as the gdb simulator does
not support newer ARMs. However, there does not seems to be any good
documents on that topic. Could someone give me a pointer or two?
Thanks.
-Doug
We're in Stage 1, and in Stage 1 big changes happen -- and then there is
naturally some instability. We clearly have some instability at
present, so we need to slow down until that's resolved.
Therefore, effective immediately, please commit only bug fixes to the
middle end and to architectures th
On Tue, Apr 28, 2009 at 7:50 PM, Shobaki, Ghassan
wrote:
> Hi,
>
> In some optimization passes it may be useful to know the programming
> language that we are compiling. Is there a way to get that information
> in the middle end and back end?
There is no way that should be used in new code.
Rich
My c++ sourcefiles that compile with gcc 3.3.5 generate hundreds of errors if
compiled with gcc 4.3.2.
Where can I find guidelines on how to change my files?
http://gcc.gnu.org/gcc-3.4/changes.html
http://gcc.gnu.org/gcc-4.0/changes.html
etc...
under the C++ sections.
In my experience, most C++
My c++ sourcefiles that compile with gcc 3.3.5 generate hundreds of errors if
compiled with gcc 4.3.2.
Where can I find guidelines on how to change my files?
Thanks
Nieuwenhuizen, J.K.
2009-04-28T22:23
+===+
| I st
Basile STARYNKEVITCH wrote:
> Shobaki, Ghassan wrote:
>> In some optimization passes it may be useful to know the programming
>> language that we are compiling. Is there a way to get that information
>> in the middle end and back end?
>
> I am not sure that would be a good idea. In fact you are su
On Tue, Apr 28, 2009 at 10:50:52AM -0700, Shobaki, Ghassan wrote:
> In some optimization passes it may be useful to know the programming
> language that we are compiling. Is there a way to get that information
> in the middle end and back end?
Is that really a good idea? If a particular optimizat
Shobaki, Ghassan wrote:
> In some optimization passes it may be useful to know the programming
> language that we are compiling. Is there a way to get that information
> in the middle end and back end?
Hmm. I would rather that the amount of language-specific optimization
were kept to an absolute
Oh, OK. Apparently there is no way to query directly the repository
version on a server, so I misused some dry-run merge command to find
out.
Anyway, I have tried svn trunk -> branch merge and it works, provided
that at least 1.5.5 client is used. I haven't tested branch -> trunk
(I wish I could :
Shobaki, Ghassan wrote:
In some optimization passes it may be useful to know the programming
language that we are compiling. Is there a way to get that information
in the middle end and back end?
I am not sure that would be a good idea. In fact you are suggesting that
the intermediate represen
Hi,
In some optimization passes it may be useful to know the programming
language that we are compiling. Is there a way to get that information
in the middle end and back end?
Thanks in advance!
-Ghassan
From: "Mark Mitchell"
That is not a decision, however, on whether using MPC is or is not a
good idea. There have been objections raised to MPC, on the grounds
that it may not build on all host systems, or that the costs it brings
in terms of complexity of building GCC outweigh its benefits. W
On Sat, Apr 25, 2009 at 10:35:07AM -0700, Ian Lance Taylor wrote:
> Yes, while there are of course occasional bugs and mismatches, in
> general all versions of gcc and gdb are compatible. That said, gdb 5.3
> is old; it was released over five years ago. It will ignore some of the
> newer types of
Hans-Peter Nilsson wrote:
> I don't see a request, yet more than two people seem to agree,
> so: can we have a slush (no new merges or features) while the
> tree is stabilized?
>
> I'll let other people answer the "why" wrt. priority platforms;
> the double breakages for cris-elf (PR39927, PR39938
On Tue, Apr 28, 2009 at 7:17 AM, Hans-Peter Nilsson wrote:
> I don't see a request, yet more than two people seem to agree,
> so: can we have a slush (no new merges or features) while the
> tree is stabilized?
>
> I'll let other people answer the "why" wrt. priority platforms;
> the double breakag
I don't see a request, yet more than two people seem to agree,
so: can we have a slush (no new merges or features) while the
tree is stabilized?
I'll let other people answer the "why" wrt. priority platforms;
the double breakages for cris-elf (PR39927, PR39938) don't
count. :/
brgds, H-P
2009/4/28 H.J. Lu :
> 2009/4/27 Ben Elliston :
>> On Manuel's recommendation, I have backed out revision 145102 for the
>> time being. If someone wishes to have another go at it, the code is in
>> svn.
>>
>> Cheers, Ben
>
> You should use "patch -E" apply any patches. I checked in revision 14689
>
2009/4/27 Ben Elliston :
> On Manuel's recommendation, I have backed out revision 145102 for the
> time being. If someone wishes to have another go at it, the code is in
> svn.
>
> Cheers, Ben
You should use "patch -E" apply any patches. I checked in revision 14689
to remove the empty g++.dg/war
22 matches
Mail list logo
