Dorit Nuzman/Haifa/IBM wrote on 23/01/2008 21:49:51:
> There are however a couple of small cost-model changes that were
> going to be submitted this week for the Cell SPU - it's unfortunate
> if these cannot get into 4.3.
It's indeed unfortunate. However, those changes are not crucial and there
On Mon, Jan 21, 2008 at 07:06:52PM +, Joseph S. Myers wrote:
>
> Of the others: arc, crx, iq2000, mt, pdp11, stormy16, I see no recent
> testing or development. Joern Rennecke was intending to improve ARC
> support but is listed as "Waiting for paperwork" in MAINTAINERS; is
> there any news o
PR c++/34935 illustrates a problem with the way attributes interact
with type identity. The example in question looks something like this:
typedef int X __attribute((may_alias));
void foo(X);
void foo(int);
The fundamental question here is whether 'X' is a new type distinct
from 'int', or
On Jan 24, 2008 3:58 PM, Doug Gregor <[EMAIL PROTECTED]> wrote:
> PR c++/34935 illustrates a problem with the way attributes interact
> with type identity. The example in question looks something like this:
>
> typedef int X __attribute((may_alias));
>
> void foo(X);
> void foo(int);
>
> The
> "Joseph" == Joseph S Myers <[EMAIL PROTECTED]> writes:
Joseph> ... There is good coverage for
Joseph> bare-metal ELF targets, but none for bare-metal a.out and
Joseph> COFF targets (perhaps we should consider deprecating all of
Joseph> those, on the presumption that bare-metal use has m
On Thu, Jan 24, 2008 at 04:06:47PM +0100, Richard Guenther wrote:
> On Jan 24, 2008 3:58 PM, Doug Gregor <[EMAIL PROTECTED]> wrote:
> The middle-end type system (useless_type_conversion_p) says that
> pointers to int and pointers to int __attribute__((may_alias)) are
> distinct (you can't use one i
On Jan 24, 2008 11:41 AM, Jakub Jelinek <[EMAIL PROTECTED]> wrote:
> On Thu, Jan 24, 2008 at 04:06:47PM +0100, Richard Guenther wrote:
> > On Jan 24, 2008 3:58 PM, Doug Gregor <[EMAIL PROTECTED]> wrote:
> > The middle-end type system (useless_type_conversion_p) says that
> > pointers to int and poi
Per http://gcc.gnu.org/ml/gcc/2006-10/msg00141.html it is possible to
build GMP/MPFR in the local tree with the current Trunk. This build
method may ease issues with building gcc. Would it be possible to
document this for 4.3?
Thanks,
Matt
On Thu, 24 Jan 2008, Paul Koning wrote:
> > "Joseph" == Joseph S Myers <[EMAIL PROTECTED]> writes:
>
> Joseph> ... There is good coverage for
> Joseph> bare-metal ELF targets, but none for bare-metal a.out and
> Joseph> COFF targets (perhaps we should consider deprecating all of
> Joseph
ed tests 7144
/sata/dj/gnu/gcc/sh-elf/gcc/xgcc version 4.3.0 20080124 (experimental) [trunk
revision 131776] (GCC)
=== g++ Summary for sh-sim/-m4a-single-only ===
# of expected passes16696
# of unexpected failures30
# of unexpected successes 2
On Thu, 24 Jan 2008, DJ Delorie wrote:
> "Joseph S. Myers" <[EMAIL PROTECTED]> writes:
> > * Any target with test results posted to gcc-testresults within the
> > past year,
>
> I did a test run of the sh-elf test results script. There are so many
> multilibs that the email is 437 Kb long. Stil
> Actively maintained targets need a maintainer doing enough work on
> the results (fixing bugs and arranging for inapplicable tests to be
> skipped or XFAILed) to get them down below that size.
At the moment, I'm working on getting sh, h8300, and m32c in shape for
4.3 (or future). I can easily
On Thu, 24 Jan 2008, DJ Delorie wrote:
> At the moment, I'm working on getting sh, h8300, and m32c in shape for
> 4.3 (or future). I can easily get the test results under 400k by
> removing some of the multilibs, but I don't think that's a good idea.
> My sh-elf test tests 38 multilibs, if I only
The m32c port has this:
#define DWARF2_ADDR_SIZE4
However, dwarf2asm.c has this:
int
size_of_encoded_value (int encoding)
{
. . .
case DW_EH_PE_absptr:
return POINTER_SIZE / BITS_PER_UNIT;
The net result is that the EH sections have 2 byte pointers for the
m16c variant (HIm
On Thu, Jan 24, 2008 at 11:16:43PM +, Joseph S. Myers wrote:
> On Thu, 24 Jan 2008, DJ Delorie wrote:
>
> > At the moment, I'm working on getting sh, h8300, and m32c in shape for
> > 4.3 (or future). I can easily get the test results under 400k by
> > removing some of the multilibs, but I don
> I'm not actually convinced these long default multilib lists are a
> good idea;
If my goal was to write SH software, I'd agree. However, my goal is
to try to get the port into shape, so a long list is useful.
Internally, we use an even longer list, but the FSF sources don't
support (by default
> message was truncated because of the massive number of failures.
Or massive number of multilibs :-)
On Wed, 2008-01-23 12:57:00 +0100, Jan-Benedict Glaw <[EMAIL PROTECTED]> wrote:
I played a bit with it, so I can answer these questions myself:
> Most specific questions:
>
> - What is the largest HDD SIMH supports? There seems to be RA92
> support, but that's only 1.5GB. With today's sof
Minor stylistic suggestions...
+ "*
+ switch (which_alternative)
+{
+case 0:
+ if (TARGET_A16
+ && GET_CODE (operands[2]) == SYMBOL_REF
+ && far_data_p (operands[2])== 1
+ && near_data_p (operands[2])== 0)
+return m32c_disp_pattern (insn, operands)
DJ Delorie <[EMAIL PROTECTED]> writes:
> The m32c port has this:
>
> #define DWARF2_ADDR_SIZE 4
>
> However, dwarf2asm.c has this:
>
> int
> size_of_encoded_value (int encoding)
> {
> . . .
> case DW_EH_PE_absptr:
> return POINTER_SIZE / BITS_PER_UNIT;
>
> The net result is th
20 matches
Mail list logo
