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
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 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,
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 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
> 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 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
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
> 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
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
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
> 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:
>> 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
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
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:
> 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 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
\
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 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);
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 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
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
> 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, 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
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 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 Mon, 2012-03-05 at 11:00 -0800, Richard Henderson wrote:
> On 03/04/2012 11:09 AM, Oleg Endo wrote:
> > Richard, could you also please take the
> > TARGET_ATOMIC_TEST_AND_SET_TRUEVAL hunk from this patch for the 4.7
> > branch?
>
> Done.
Thanks!
> I've also moved the TARGET_ATOMIC_TEST_AND_
Hello,
This is a simple cleanup that introduces a new function
add_builtin_type and uses it in the mep and rs6000 back ends.
Bootstrapped and tested on powerpc64-unknown-linux-gnu (gcc110) and
verified that a cross to mep builds.
OK for trunk?
Ciao!
Steven
* langhooks.c (add_builtin_typ
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 (ASSEMBLER_DIALECT == ASM_ATT)
> + fputs ("addr32; "
Hello!
Attached RFC patch enhances stringop patterns to emit addr32 prefix
when Pmode == SImode. I have introduced %^ operand modifier that
conditionally emits "addr32" to all stringop insn templates.
H.J., can you please test the patch if it works OK on SImode X32
target? I have tested it on x86
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?
commit 2ad07fd7f293027ed3f779fc0d7e79b58a4b7e2a
Author: Jason Merrill
Date: Mon Mar 5 16:05:2
Er, not actually a C++ patch. Fingers on autopilot...
objc-map.c has been calling _stat allocation functions without using
MEM_STAT_INFO for passing the file location information to the
allocator, which breaks bootstrap with
--enable-gather-detailed-mem-stats. Fixed by calling the non-_stat
variant instead.
Applying as obvious.
commit c70308c0c
> IIUC, you are annoyed by:
>
> +#ifndef __RTM__
> +# error "RTM instruction set not enabled"
> +#endif /* __RTM__ */
That, yes, but also
(and see PR44987)
>
> in the headers. Indeed, this prevents "#pragma GCC target" to be effective.
>
> But OTOH, intrinsics are internally implemented using
Hi,
The patch below addresses an issue with gcc-4.7.0 the issue I had
reported in
http://gcc.gnu.org/ml/gcc/2012-03/msg00035.html
and somebody else had bz'ed as
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51417
Tested by cross-building gcc-4_7-branch for several *rtems targets on
Fedora 16.
On 03/05/2012 03:08 AM, Jakub Jelinek wrote:
> - PR51902 dwarf2out .debug_ranges ~ 22% reduction
> http://gcc.gnu.org/ml/gcc-patches/2012-01/msg01171.html
Ok.
r~
On 02/07/2012 12:12 AM, Andreas Krebbel wrote:
> Hi,
>
> I would like to get rid of the atomic-2 failure on s390x. What do you think
> about my
> comments on the BIGGEST_ALIGNMENT check in omp-low.c?
>
> http://gcc.gnu.org/ml/gcc-patches/2012-02/msg9.html
I've reverted the patch in question
> -Original Message-
> From: Georg-Johann Lay
> Sent: Monday, March 05, 2012 12:00 PM
> To: Georg-Johann Lay
> Cc: gcc-patches@gcc.gnu.org; Denis Chertykov; Weddington, Eric
> Subject: Re: [Patch,AVR]: Document -mmcu=avrxmega...
>
> Georg-Johann Lay schrieb:
> > This patch adds the docum
On Mon, Mar 5, 2012 at 8:12 PM, Andi Kleen wrote:
>> Removing -mrtm option would remove one point of control.
>
> If I use the intrinsics I can never remove it because it would just make the
> code not compile.
>
> If I don't use the intrinsics I never need it in the first place.
Aha, I see your
> Removing -mrtm option would remove one point of control.
If I use the intrinsics I can never remove it because it would just make the
code not compile.
If I don't use the intrinsics I never need it in the first place.
-Andi
--
a...@linux.intel.com -- Speaking for myself only.
Georg-Johann Lay schrieb:
This patch adds the documentation for -mmcu= for xmega cores that is still
missing.
Moreover, there is some explanation of RAMP SFR usage.
Ok for the trunk and 4.7?
This patch is just for trunk, not for 4.7
Johann
* doc/invoke.texi (AVR Options): -mmcu=:
On 03/04/2012 11:09 AM, Oleg Endo wrote:
> Richard, could you also please take the
> TARGET_ATOMIC_TEST_AND_SET_TRUEVAL hunk from this patch for the 4.7
> branch?
Done. I've also moved the TARGET_ATOMIC_TEST_AND_SET_TRUEVAL
definition from sh.h to sh.c where it belongs.
r~
On Mon, Mar 5, 2012 at 7:47 PM, Andi Kleen wrote:
> The problem I have with the flag is that the typical use model is to
> have multiple code paths, like:
>
> if (cpuid_has_rtm())
> ... do rtm ...
> else
> ... do something else ...
>
> So you have a basic block which needs RTM and another o
On 03/05/2012 10:37 AM, Aldy Hernandez wrote:
> I thought there'd be a lot less overhead by callocing the value myself. Is
> the overhead negligible?
Yes, it's negligible.
> I can certainly make it a VEC in a follow up patch if you want, though I'll
> commit this now so I can at get Rainer and
On Mon, Mar 05, 2012 at 07:04:47PM +0100, 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
> --- Comment #1 from Mikael Pettersson 2012-03-04
> 21:01:28 UTC ---
> Created attachment 26827
> --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26827
> reduced test case in C
>
> Depends on target CPU selection. -mcpu=680[012346]0 and -mcpu=cpu32 all work,
> but -mcpu=5206 (or apparently
On some targets in rare cases, LRA can put a live-range splitting insn
right after a jump insn setting up the split pseudo. The following
patch fixes the problem by putting such insn at the beginning of next BB.
The patch was successfully bootstrapped on x86/x86-64.
Committed as rev. 184942.
On 03/05/12 11:08, Rainer Orth wrote:
Aldy Hernandez writes:
Torvald has a testcase from the STAMP benchmark that is showing a memory
corruption error after my fix to publication safety problems.
The problem is we're allocating a chunk of worklist memory of size
n_basic_blocks which changes w
On 03/05/12 11:16, Richard Henderson wrote:
On 03/05/2012 08:54 AM, Aldy Hernandez wrote:
region_worklist =
(struct tm_region **) xcalloc (sizeof (struct tm_region *),
- n_basic_blocks + NUM_FIXED_BLOCKS + 2);
+ last_basic
In a defaulted constructor, the destructors used for subobject cleanups
affect whether or not the constructor is deleted. But discussion in
Kona pointed out that they should not affect the
exception-specification, since if one of those cleanups throws an
exception then it's a double-fault, and
On 03/05/2012 01:05 PM, Jason Merrill wrote:
While looking at the class variant of this issue, I noticed that some of
the code in determine_visibility was wrong; template_class_depth only
considers unbound template parameters, and the number we want is the
total number of levels. I've also adjust
While looking at the class variant of this issue, I noticed that some of
the code in determine_visibility was wrong; template_class_depth only
considers unbound template parameters, and the number we want is the
total number of levels. I've also adjusted the diagnostic for misplaced
class attr
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 just a pain to add to Makefiles,
> but don't give
Bruce Korb writes:
> On 03/05/12 09:01, Rainer Orth wrote:
>> This is where I need explicit approval and/or guidance:
>>
>> * 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 handl
Richard Henderson writes:
>> HAVE_STAMP_H1
>>
>> In my understanding, this is purely a OSF thing and can go, but maybe
>> other OSes on alpha mimiced OSF here?
>
> I've no idea what that actually is.
It's used to emit .verstamp directives for ECOFF objects. I've just
Hello,
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 failures.
OK?
Cheers,
Oleg
C
OK.
Jason
On 5 March 2012 17:01, Rainer Orth wrote:
>
> * The libstdc++ testsuite is messy since every thing pthread test
> includes the complete list of targets where it should be run, and the
> options required. I've long meant to clean this up, but this will
> have to wait until after osf and irix are
Richard Guenther wrote:
> On Mon, Mar 5, 2012 at 6:15 PM, Georg-Johann Lay wrote:
>> Richard Guenther wrote:
>>> On Mon, Mar 5, 2012 at 4:56 PM, Georg-Johann Lay wrote:
Richard Guenther wrote:
> On Mon, Mar 5, 2012 at 4:25 PM, Georg-Johann Lay wrote:
>> Richard Guenther wrote:
>
Douglas Rupp writes:
> On 3/5/2012 9:28 AM, Richard Henderson wrote:
>> On 03/05/2012 09:14 AM, Rainer Orth wrote:
>>> * In the alpha backend, there are a couple of cases that might be
>>>osf-specific, but I cannot tell for certain:
>>>
>>>macro osf5.h
Jakub Jelinek writes:
> On Mon, Mar 05, 2012 at 09:28:18AM -0800, Richard Henderson wrote:
>> > TARGET_HAS_XFLOATING_LIBS 1 TARGET_LONG_DOUBLE_128
>> >
>> > Same here: any configurations with !TARGET_LONG_DOUBLE_128?
>>
>> I wouldn't think so; glibc before version 2.4,
On Mon, Mar 5, 2012 at 9: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 just a pain to add to Makefiles,
> but don't give
On 3/5/2012 9:28 AM, Richard Henderson wrote:
On 03/05/2012 09:14 AM, Rainer Orth wrote:
* In the alpha backend, there are a couple of cases that might be
osf-specific, but I cannot tell for certain:
macro osf5.halpha.h
TARGET_AS_CAN_SUBTRACT_L
On Mon, Mar 05, 2012 at 09:28:18AM -0800, Richard Henderson wrote:
> > TARGET_HAS_XFLOATING_LIBS 1 TARGET_LONG_DOUBLE_128
> >
> > Same here: any configurations with !TARGET_LONG_DOUBLE_128?
>
> I wouldn't think so; glibc before version 2.4, circa 1998?
No idea about MIPS, but f
CF:
fixincludes:
* inclhack.def (alpha___extern_prefix): Remove.
(alpha___extern_prefix_standards): Remove.
(alpha___extern_prefix_sys_stat): Remove.
(alpha_bad_lval): Remove.
(alpha_pthread): Remove.
(alpha_pthread_gcc): Remove.
(alpha_pthre
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, what we get
> >> >> is 0x1000 + 0x, not 0x1000 sin
On 03/05/12 09:01, Rainer Orth wrote:
This is where I need explicit approval and/or guidance:
* 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
On 03/05/2012 09:14 AM, Rainer Orth wrote:
> * In the alpha backend, there are a couple of cases that might be
> osf-specific, but I cannot tell for certain:
>
> macro osf5.halpha.h
>
> TARGET_AS_CAN_SUBTRACT_LABELS 1 TARGET_GAS
>
On Mon, Mar 5, 2012 at 6:15 PM, Georg-Johann Lay wrote:
> Richard Guenther wrote:
>> On Mon, Mar 5, 2012 at 4:56 PM, Georg-Johann Lay wrote:
>>> Richard Guenther wrote:
On Mon, Mar 5, 2012 at 4:25 PM, Georg-Johann Lay wrote:
> Richard Guenther wrote:
>
>> All commits to the 4.7
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, what we get
>> >> is 0x1000 + 0x, not 0x1000 since 0x67 address prefix only applies
>> >> to
>> >> base register
On Mon, Mar 5, 2012 at 6:03 PM, H.J. Lu wrote:
>>> X86-64 linker optimizes TLS_MODEL_INITIAL_EXEC to TLS_MODEL_LOCAL_EXEC
>>> by checking
>>>
>>> movq foo@gottpoff(%rip), %reg
>>>
>>> and
>>>
>>> addq foo@gottpoff(%rip), %reg
>>>
>>> It uses the REX prefix to avoid the last byte of
Hi,
I've re-tested the patch from:
http://gcc.gnu.org/ml/gcc-patches/2011-11/msg01819.html
on s390x and x86_64.
Ok for mainline?
Bye,
-Andreas-
On 03/05/2012 09:20 AM, Rainer Orth wrote:
> 2012-02-24 Rainer Orth
>
> * config/alpha/alpha.h (MIPS_DEBUGGING_INFO): Remove.
> * config/alpha/elf.h (MIPS_DEBUGGING_INFO): Don't undef.
> * config/alpha/vms.h (MIPS_DEBUGGING_INFO): Don't undef.
>
> * dwarf2cfi.c (def_cfa
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 for quirks in SGI dbx, so the
following patch remo
On Mon, Mar 05, 2012 at 09:13:49AM -0800, 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.
> >
> > I would call th
On 03/05/2012 05:01 PM, Rainer Orth wrote:
> * In libjava, there were several workarounds for OSF bugs/quirks. I've
> ripped them out as explained above.
>
> There's one particular issue: the change to java/io/File.java required
> my to regenerate the .class file in classpath. I've used Su
On Mon, Mar 5, 2012 at 12:24 AM, Uros Bizjak wrote:
> On Mon, Mar 5, 2012 at 9:01 AM, Uros Bizjak wrote:
>
@@ -11388,6 +11400,11 @@ ix86_decompose_address (rtx addr, struct
ix86_address *out)
else
disp = addr; /* displacement */
+ /* Sinc
On 03/05/2012 08:54 AM, Aldy Hernandez wrote:
>region_worklist =
> (struct tm_region **) xcalloc (sizeof (struct tm_region *),
> - n_basic_blocks + NUM_FIXED_BLOCKS + 2);
> + last_basic_block + NUM_FIXED_BLOCKS);
This is ok.
I w
Richard Guenther wrote:
> On Mon, Mar 5, 2012 at 4:56 PM, Georg-Johann Lay wrote:
>> Richard Guenther wrote:
>>> On Mon, Mar 5, 2012 at 4:25 PM, Georg-Johann Lay wrote:
Richard Guenther wrote:
> All commits to the 4.7 branch need explicit release manager approval. AVR
> isn't p
On Mon, Mar 5, 2012 at 12:01 AM, Uros Bizjak wrote:
> On Sun, Mar 4, 2012 at 11:01 PM, H.J. Lu wrote:
>
>>> @@ -11388,6 +11400,11 @@ ix86_decompose_address (rtx addr, struct
>>> ix86_address *out)
>>> else
>>> disp = addr; /* displacement */
>>>
>>> + /* Since address
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 just a pain to add to Makefiles,
but don't give any benefit.
-Andi
On Sun, Mar 4, 2012 at 11:47 PM, Uros Bizjak wrote:
> On Mon, Mar 5, 2012 at 4:53 AM, H.J. Lu wrote:
>
>> and compiler does generate the same output. i386.c also has
>>
>> xasm = "jmp\t%A0";
>> xasm = "call\t%A0";
>>
>> for calls. There are no separate indirect call patterns. For x32,
Aldy Hernandez writes:
> Torvald has a testcase from the STAMP benchmark that is showing a memory
> corruption error after my fix to publication safety problems.
>
> The problem is we're allocating a chunk of worklist memory of size
> n_basic_blocks which changes with tail merge optimization and
Uros Bizjak writes:
> It looks that this patch introduced:
>
> /home/uros/gcc-build-go/x86_64-unknown-linux-gnu/32/libgo/.libs/libgo.so:
> undefined reference to `libgo_runtime.runtime.Callers'
> collect2: error: ld returned 1 exit status
>
> All libgo tests fail due to this undefined reference.
On Mon, Mar 5, 2012 at 7:31 AM, Uros Bizjak wrote:
> On Fri, Mar 2, 2012 at 9:36 PM, H.J. Lu wrote:
>
>> X86-64 linker optimizes TLS_MODEL_INITIAL_EXEC to TLS_MODEL_LOCAL_EXEC
>> by checking
>>
>> movq foo@gottpoff(%rip), %reg
>>
>> and
>>
>> addq foo@gottpoff(%rip), %reg
>>
>> It u
On Mon, Mar 5, 2012 at 4:56 PM, Georg-Johann Lay wrote:
> Richard Guenther wrote:
>> On Mon, Mar 5, 2012 at 4:25 PM, Georg-Johann Lay wrote:
>>> Richard Guenther wrote:
>>>
All commits to the 4.7 branch need explicit release manager approval. AVR
isn't primary/secondary so please do no
Hi folks.
Torvald has a testcase from the STAMP benchmark that is showing a memory
corruption error after my fix to publication safety problems.
The problem is we're allocating a chunk of worklist memory of size
n_basic_blocks which changes with tail merge optimization and such. We
end up w
On 01/03/12 13:06 , Sandeep Soni wrote:
2012-03-01 Sandeep Soni
* parser.c : Include hashtab.h.
(gimple_symtab): New. The symbol table.
(gimple_symtab_entry_hash): New.
(gimple_symtab_eq_hash): New.
(gimple_symtab_entry_marked_p):New.
(gimple_sym
On 03/05/2012 05:35 AM, Torvald Riegel wrote:
> libitm/
> * dispatch.h (CREATE_DISPATCH_METHODS_MEM): Don't execute
> memtransfer/memset if size isn't larger than zero.
Ok everywhere.
r~
Richard Guenther wrote:
> On Mon, Mar 5, 2012 at 4:25 PM, Georg-Johann Lay wrote:
>> Richard Guenther wrote:
>>
>>> All commits to the 4.7 branch need explicit release manager approval. AVR
>>> isn't primary/secondary so please do not change anything before is
>>> released 4.7.0 for it.
>>>
>>> T
On 3/4/2012 11:18 PM, Anthony Green wrote:
On 3/4/2012 10:22 PM, John David Anglin wrote:
I'm just wondering why Anthony Green and Redhat are listed as
copyright holders. I can understand the Free Software Foundation
addition since the file was contributed to it.
Simply because of changes tha
On Fri, Mar 2, 2012 at 9:36 PM, H.J. Lu wrote:
> X86-64 linker optimizes TLS_MODEL_INITIAL_EXEC to TLS_MODEL_LOCAL_EXEC
> by checking
>
> movq foo@gottpoff(%rip), %reg
>
> and
>
> addq foo@gottpoff(%rip), %reg
>
> It uses the REX prefix to avoid the last byte of the previous
> instr
On Mon, Mar 5, 2012 at 4:25 PM, Georg-Johann Lay wrote:
> Richard Guenther wrote:
>
>> All commits to the 4.7 branch need explicit release manager approval. AVR
>> isn't primary/secondary so please do not change anything before is
>> released 4.7.0 for it.
>>
>> Thanks,
>> Richard.
>
> What is th
Richard Guenther wrote:
> All commits to the 4.7 branch need explicit release manager approval. AVR
> isn't primary/secondary so please do not change anything before is
> released 4.7.0 for it.
>
> Thanks,
> Richard.
What is the exact procedure in that case?
Wait until approve from release mana
This patch adds the documentation for -mmcu= for xmega cores that is still
missing.
Moreover, there is some explanation of RAMP SFR usage.
Ok for the trunk and 4.7?
Johann
* doc/invoke.texi (AVR Options): -mmcu=: Document the XMEGA cores.
Explain RAMPD, RAMPX, RAMPDY, RAMPZ usa
I'm currently working on removing the obsolete Tru64 UNIX and IRIX
ports. When IRIX is gone, the obsoleted OpenBSD/MIPS is the only
remaining port that uses MIPS_DEBUGGING_INFO (which I plan to remove as
a followup once IRIX is gone).
The following patch has been included in a i386-pc-solaris2.10
On Mon, Mar 5, 2012 at 3:11 PM, Georg-Johann Lay wrote:
> Georg-Johann Lay wrote:
>> This patch fixes several issues with RAMP registers:
>>
>> * On Devices with more than 64 KiB RAM, RAMPZ is used as high-byte of
>> RAM address. If RAMPZ is used to read flash, it must be reset to 0
>> after t
Georg-Johann Lay wrote:
> This patch fixes several issues with RAMP registers:
>
> * On Devices with more than 64 KiB RAM, RAMPZ is used as high-byte of
> RAM address. If RAMPZ is used to read flash, it must be reset to 0
> after the read so that RAM-read will operate correctly in the remainde
Currently verify_loop_structure assumes dominators are up-to-date.
Most of the callers of verify_loop_structure verify dominators before
calling it, some do it afterwards, some don't do it at all. This
cleans things up by moving the verification into verify_loop_structure.
It also notices some un
On Mon, Mar 5, 2012 at 2:34 PM, Torvald Riegel wrote:
> This patch skips execution of memtransfer/memset if there actually isn't
> anything to do. Calls to memcpy/memmove/memset with size==0 should be
> rare I'd suppose but prior code would still treat this no-op like some
> store (ml_wt was part
1 - 100 of 126 matches
Mail list logo
