On 03/05/2012 01:44 PM, Oleg Endo wrote:
> Yeah, however, I'm also using the value behind
> TARGET_ATOMIC_TEST_AND_SET_TRUEVAL in sync.md. If it's in sh.c it
> doesn't work. That's why I left it in sh.h.
That value should be available via targetm.atomic_test_and_set_trueval.
r~
On 03/05/2012 01:43 PM, Steven Bosscher wrote:
> * langhooks.c (add_builtin_type): New function.
> * langhooks.h (add_builtin_type): Export it.
> * config/mep/mep.c (mep_init_builtins): Use it.
> * config/rs6000/rs6000.c (rs6000_init_builtins): Use it.
Ok.
r~
On Mon, Mar 5, 2012 at 10:42 PM, Jakub Jelinek wrote:
> On Mon, Mar 05, 2012 at 10:33:19PM +0100, Uros Bizjak wrote:
>> + case '^':
>> + if (TARGET_64BIT && Pmode == SImode)
>> + {
>> + fputs ("addr32", file);
>> +#ifndef HAVE_AS_IX86_REP_LOCK_PREFIX
>> + if
> Rebuilding gcc was failing for me because the rule for gnat_ugn.texi was
> trying to use xgnatugn before it had been built. Fixed by making it
> directly, like the rule for projects.texi.
>
> OK for trunk?
Yes, thanks.
--
Eric Botcazou
On Mon, 2012-03-05 at 13:49 -0800, Richard Henderson wrote:
> On 03/05/2012 01:44 PM, Oleg Endo wrote:
> > Yeah, however, I'm also using the value behind
> > TARGET_ATOMIC_TEST_AND_SET_TRUEVAL in sync.md. If it's in sh.c it
> > doesn't work. That's why I left it in sh.h.
>
> That value should be
On 03/05/2012 01:49 PM, Richard Henderson wrote:
> On 03/05/2012 01:44 PM, Oleg Endo wrote:
>> Yeah, however, I'm also using the value behind
>> TARGET_ATOMIC_TEST_AND_SET_TRUEVAL in sync.md. If it's in sh.c it
>> doesn't work. That's why I left it in sh.h.
>
> That value should be available via
I found a weird piece of code that was added by kenner in a really early
revision. It checks for VAR_DECLs with frame or stack pointers as
DECL_RTL, and the comment in front of it mentions strength reduction.
Presumably this was for the old loop optimizer? I can't think of
anything that would requi
On Mon, Mar 5, 2012 at 2:04 PM, Uros Bizjak wrote:
> On Mon, Mar 5, 2012 at 10:42 PM, Jakub Jelinek wrote:
>
>> On Mon, Mar 05, 2012 at 10:33:19PM +0100, Uros Bizjak wrote:
>>> + case '^':
>>> + if (TARGET_64BIT && Pmode == SImode)
>>> + {
>>> + fputs ("addr32", file);
Oleg Endo wrote:
> The attached patch is the same as the last one proposed in the PR.
> Tested against rev 184877 with
>
> make -k check RUNTESTFLAGS="--target_board=sh-sim
> \{-m2/-ml,-m2/-mb,-m2a-single/-mb,
> -m4-single/-ml,-m4-single/-mb,
> -m4a-single/-ml,-m4a-single/-mb}"
>
> and no new fa
On Thu, 2012-03-01 at 13:11 +0900, Kaz Kojima wrote:
> Hi,
>
> The attached patch is to avoid PR target/48596 which is a 4.7
> regression on SH.
> [...]
I'd like to add the test case from the PR to the testsuite.
Tested with
make check-gcc RUNTESTFLAGS="sh.exp=pr48596.c --target_board=sh-sim
\
On Mon, 5 Mar 2012, Rainer Orth wrote:
> The only two users of MIPS_DEBUGGING_INFO are on their way out: I've
> just submitted a patch to remove the OpenBSD/MIPS configuration, and
> IRIX removal will follow soon. There seems to be no point in retaining
> what seems to be primarily workarounds fo
On 03/05/2012 10:04 AM, Uros Bizjak wrote:
> On Mon, Mar 5, 2012 at 6:12 PM, Andi Kleen wrote:
>> On Mon, Mar 05, 2012 at 03:31:32PM +0400, Kirill Yukhin wrote:
>>> Adding patch
>>
>> I would still remove the "-mrtm" option. I never understood what options
>> for intrinsics are good for. They are
On Mon, 5 Mar 2012, Rainer Orth wrote:
> * There are some fixincludes hacks that from their names seem to be
> osf-specific, but are not restricted to alpha*-dec-osf*. Bruce,
> what's the best way to handle those? Disable them e.g. with a mach
> clause like unused-alpha*-dec-osf* and see i
> Oleg Endo wrote:
>> The attached patch is the same as the last one proposed in the PR.
>> Tested against rev 184877 with
>>
>> make -k check RUNTESTFLAGS="--target_board=sh-sim
>> \{-m2/-ml,-m2/-mb,-m2a-single/-mb,
>> -m4-single/-ml,-m4-single/-mb,
>> -m4a-single/-ml,-m4a-single/-mb}"
>>
>> an
> My personal opinion is that it is better if open source software is not
> encumbered by multiple copyright
> holders. A copyright holder probably has the right to change the work's
> permission notice.
Off-topic, but that works both ways: if you want to ensure that a
work's license's terms wi
Oleg Endo wrote:
> I'd like to add the test case from the PR to the testsuite.
>
> Tested with
> make check-gcc RUNTESTFLAGS="sh.exp=pr48596.c --target_board=sh-sim
> \{-m2/-ml,-m2/-mb,-m2a-single/-mb,
> -m4-single/-ml,-m4-single/-mb,-m4a-single/-ml,-m4a-single/-mb}"
>
> OK?
A gcc.c-torture/com
Hello,
This is a long-overdue cleanup of f95-lang.c. This file was once added
as an almost one-to-one copy from one of the other languages and
tweaked until it worked. But the comments in the file are misleading,
out-dated, or wrong for other reasons, and there are remnants of the
pre tree-ssa era
> I found a weird piece of code that was added by kenner in a really early
> revision. It checks for VAR_DECLs with frame or stack pointers as
> DECL_RTL, and the comment in front of it mentions strength reduction.
> Presumably this was for the old loop optimizer? I can't think of
> anything that w
On Mon, Mar 5, 2012 at 3:13 PM, Joseph S. Myers wrote:
> On Mon, 5 Mar 2012, Rainer Orth wrote:
>
>> * There are some fixincludes hacks that from their names seem to be
>> osf-specific, but are not restricted to alpha*-dec-osf*. Bruce,
>> what's the best way to handle those? Disable them e.g
On power7 systems, the backend was not prepared to handle vector comparisons
with UNEQ, LTGT, ORDERED, and UNORDERED tests, since there is no single
comparison instruction for these cases. This patch adds support for doing
vector conditional move involving these operations. I have bootstrapped th
> That said, -mrtm could easily be tested by the compiler to generate
> (or not) inline HTM for implementing -fgnu-tm
Consider my earlier example
if (cpuid(rtm)) _xbegin() .. else fallback
Today if I want to do that I have to pass -mrtm. And the binary would work
on CPUs with and without RT
On Mon, Mar 5, 2012 at 7:23 PM, Michael Meissner
wrote:
> On power7 systems, the backend was not prepared to handle vector comparisons
> with UNEQ, LTGT, ORDERED, and UNORDERED tests, since there is no single
> comparison instruction for these cases. This patch adds support for doing
> vector con
Update x86_64-grtev3-linux-gnu test manifest.
This is a copy of the corresponding x86_64-unknown-linux-gnu one. Submitting
as obvious.
contrib/
* testsuite-management/x86_64-grtev3-linux-gnu.xfail: Updated to
reflect current x86_64-unknown-linux-gnu.xfail file.
diff --gi
On Mon, Mar 5, 2012 at 9:31 AM, Jakub Jelinek wrote:
> On Mon, Mar 05, 2012 at 09:26:20AM -0800, H.J. Lu wrote:
>> On Mon, Mar 5, 2012 at 9:20 AM, Jakub Jelinek wrote:
>> > On Mon, Mar 05, 2012 at 09:13:49AM -0800, H.J. Lu wrote:
>> >> >> We are expecting address to be 0x1001 - 1 == 0x1000. But,
On Tue, Mar 6, 2012 at 6:40 AM, H.J. Lu wrote:
>>> >> >> We are expecting address to be 0x1001 - 1 == 0x1000. But, what we get
>>> >> >> is 0x1000 + 0x, not 0x1000 since 0x67 address prefix only
>>> >> >> applies to
>>> >> >> base register to zero-extend 0x to 64bit.
>>> >> >
>>
On Mon, Mar 05, 2012 at 10:11:49PM -0500, David Edelsohn wrote:
> We need to ask the RMs if this patch is acceptable for GCC 4.7.0.
I think it should wait for 4.7.1.
Jakub
101 - 126 of 126 matches
Mail list logo
