On 11/04/2011 09:01 PM, Joern Rennecke wrote:
> Is there a way to have a predicate forward declaration?
No, sadly. Something for a future enhancement in the genfoo.
r~
Quoting Richard Henderson :
(define_predicate "call_address_operand"
(match_code "symbol_ref,const,reg")
{
return (symbolic_operand (op, mode) || (GET_CODE (op) == REG));
})
Nit.
(define_predicate "call_address_operand"
(ior (match_code "reg")
(match_operand 0 "symbolic_operand")
DJ Delorie writes:
>> Does it help if we change
>> if (pic_offset_table_rtx)
>> to
>> if (PIC_OFFSET_TABLE_REGNUM != INVALID_REGNUM)
>
> That seems to work.
That patch is fine if it bootstraps.
Ian
From: Jakub Jelinek
Date: Thu, 3 Nov 2011 09:22:51 +0100
> I think much better would be to handle sparc*/s390*/powerpc* differently
> here, just using #ifdef __LP64__ test. i?86/x86_64 is different because
> of the third weirdo multilib option.
I just tested and committed the following, it seem
On Fri, Nov 4, 2011 at 6:01 PM, DJ Delorie wrote:
>
>> > if (pic_offset_table_rtx)
>> > add_to_hard_reg_set (&set_up_by_prologue, Pmode,
>> > PIC_OFFSET_TABLE_REGNUM);
>>
>> But if PIC_OFFSET_TABLE_REGNUM == INVALID_REGNUM, then
>> pic_offset_table_rtx should be NULL
> Does it help if we change
> if (pic_offset_table_rtx)
> to
> if (PIC_OFFSET_TABLE_REGNUM != INVALID_REGNUM)
That seems to work.
DJ Delorie writes:
>> > if (pic_offset_table_rtx)
>> >add_to_hard_reg_set (&set_up_by_prologue, Pmode,
>> > PIC_OFFSET_TABLE_REGNUM);
>>
>> But if PIC_OFFSET_TABLE_REGNUM == INVALID_REGNUM, then
>> pic_offset_table_rtx should be NULL_RTX.
>
> It is, but is gcc smart
> > if (pic_offset_table_rtx)
> > add_to_hard_reg_set (&set_up_by_prologue, Pmode,
> > PIC_OFFSET_TABLE_REGNUM);
>
> But if PIC_OFFSET_TABLE_REGNUM == INVALID_REGNUM, then
> pic_offset_table_rtx should be NULL_RTX.
It is, but is gcc smart enough to know that causal
DJ Delorie writes:
> gcc/function.c: In function 'thread_prologue_and_epilogue_insns':
> gcc/regs.h:322:34: error: array subscript is above array bounds
> [-Werror=array-bounds]
>
> function.c has this:
>
> if (pic_offset_table_rtx)
> add_to_hard_reg_set (&set_up_by_prologue, Pmode,
For example, rx-elf...
gcc/function.c: In function 'thread_prologue_and_epilogue_insns':
gcc/regs.h:322:34: error: array subscript is above array bounds
[-Werror=array-bounds]
function.c has this:
if (pic_offset_table_rtx)
add_to_hard_reg_set (&set_up_by_prologue, Pmode,
Snapshot gcc-4.6-2004 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.6-2004/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.6 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
_FOR_TARGET=g++-4
Thread model: posix
gcc version 4.7.0 2004 (experimental) [trunk revision 180977] (GCC)
Note the --enable-threads=posix.
Backing off to revision 180766 does not yield this problem, while
180767 has the problem.
--
Cheers,
/ChJ
> Since it looks like a lot of the failures
> in both cases are lto, vect and stack-align
> tests, I suspect that of the ~3100 tests
> that were added, we have a number of new
> tests that won't work on when compiling
> specifically for an erc32 (-mcpu=cypress).
The results can hardly be analyzed,
On 11/04/11 15:37, Hans-Peter Nilsson wrote:
> On Thu, 3 Nov 2011, Iyer, Balaji V wrote:
>> Is it possible to make sure that the "LABELX" occurs right
>> after the "Call some_function" instruction (and the instruction
>> scheduler moves the label with the call INSN)? I insert the
>> label right aft
Thanks Jeff for your help!
So, are the errors confined to these files? Or could it be anywhere?
Comparing stages 2 and 3
warning: gcc/cc1obj-checksum.o differs
warning: gcc/cc1-checksum.o differs
warning: gcc/cc1plus-checksum.o differs
Bootstrap comparison failure!
gcc/i386-common.o differs
gcc/
lures97
# of unexpected successes1
# of expected failures161
# of unsupported tests446
=
4.7.0 20111104
http://gcc.gnu.org/ml/gcc-testresults/2011-11/msg00440.html
=== gcc Summary ===
# of expected passes71190
# of unexp
Greetings,
Now that C++11 user-defined literals are in trunk I was thinking about
reclaiming some of the numeric suffixes that are currently recognized by gcc in
the preprocessor. The C++11 spec stipulates that any suffix that is recognized
by the implementation is not allowable as a user-defi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/04/11 12:34, Iyer, Balaji V wrote:
> Hello Everyone, I am getting a bootstrap failure right now when I
> try to build GCC. Here is the output. Can someone please tell me
> how to fix this? Is this something I have modified? I just
> configured us
Hello Everyone,
I am getting a bootstrap failure right now when I try to build GCC.
Here is the output. Can someone please tell me how to fix this? Is this
something I have modified? I just configured using the following command
(../gcc/configure -prefix=). I haven't modified any of the
Hi,
I am testing powerpc-rtems on the head and
have gotten a weird error compiling libgcc.
It is definitely a regression from 4.6.
I have no idea who might be the best person
to help resolve this.
/home2/joel/build/b-powerpc-gcc/powerpc-rtems4.11/libgcc
[joel@rtbf64a libgcc]$ make
/users/joel/te
On Thu, 3 Nov 2011, Iyer, Balaji V wrote:
> Is it possible to make sure that the "LABELX" occurs right
> after the "Call some_function" instruction (and the instruction
> scheduler moves the label with the call INSN)? I insert the
> label right after the call is expanded and LABELX is being moved
>
I propose myself as maintainer of the Epiphany port.
This port is currently being submitted / reviewed on the gcc-patches
mailing list.
Joel,
>> That's what my patch does. It would be good if Joel could test on
>> i386-rtems before comitting (as I will on Solaris/SPARC and x86, of
>> course).
>>
> i386-rtems builds fine after moving the files.
>
> From my perspective, you can commit.
Thanks for the confirmation. I've run i386-p
23 matches
Mail list logo
