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 override works only on the (reg) part in fs:(reg),
>> + w
2012/3/4 Georg-Johann Lay :
> This patch adds a straight forward combine pattern and split for int + 2*byte
> as frequently seen with accesses to int-arrays with byte offset.
>
> Ok for trunk?
>
> Johann
>
> * config/avr/avr.md (*umaddqihi4.2): New insn-and-split.
Approved.
Denis.
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 */
>>>
>>> + /* Since address override works only on the (reg) part in fs:(reg),
>
Hello,
The PR is about selective scheduling not trying hard enough to find a
neighbor block to stick the note list from an empty block being removed.
Fixed by a) trying harder and b) making sure that if we fail to find the
right place, we just drop the notes instead of asserting.
Tested on x
On Fri, Mar 2, 2012 at 9:56 PM, H.J. Lu wrote:
> Since the 0x67 address prefix only zeros out the upper 32bits of the
> (reg) part in address fs:(reg), we can't use fs:(reg) as memory operand
> for x32 with Pmode == SImode. We have to load the address into a
> register first and use it as memory
On Fri, Mar 2, 2012 at 10:14 PM, H.J. Lu wrote:
> This is the last patch for Pmode == SImod in x32. In x32, the return value
> of the symbol address must be zero-extended to DImode, This patch adds
> *zero_extendsidi2_x32 to load the address of a symbol in SImode and
> zero-extend it to DImode. I
2012/3/5 Andrey Belevantsev :
> Hello,
>
> The PR is about selective scheduling not trying hard enough to find a
> neighbor block to stick the note list from an empty block being removed.
> Fixed by a) trying harder and b) making sure that if we fail to find the
> right place, we just drop the note
Richard Sandiford writes:
> Rainer Orth writes:
>> 2012-02-22 Rainer Orth
>>
>> * config/mips/iris6.h [!USED_FOR_TARGET] (long_intmax): Declare.
>> (INTMAX_TYPE): Use it.
>> (UINTMAX_TYPE): Likewise.
>> (SUBTARGET_OVERRIDE_OPTIONS): Define.
>> (irix6_c_common_override
On Mon, 5 Mar 2012, Rainer Orth wrote:
> Richard Sandiford writes:
>
> > Rainer Orth writes:
> >> 2012-02-22 Rainer Orth
> >>
> >>* config/mips/iris6.h [!USED_FOR_TARGET] (long_intmax): Declare.
> >>(INTMAX_TYPE): Use it.
> >>(UINTMAX_TYPE): Likewise.
> >>(SUBTARGET_OVERRIDE_
Hi!
I'd like to ping two patches deferred to 4.8. I've bootstrapped/regtested
them on x86_64-linux and i686-linux:
- PR51721 VRP register_edge_assert_for_2 improvements
http://gcc.gnu.org/ml/gcc-patches/2012-01/msg00046.html
- PR51902 dwarf2out .debug_ranges ~ 22% reduction
http://gcc.gnu.o
Hi!
Here is a tiny cleanup, written as part of PR52139 fix.
Bootstrapped/regtested on x86_64-linux and i686-linux,
ok for trunk?
2012-03-05 Jakub Jelinek
* cfgrtl.c (cfg_layout_merge_blocks): Cleanup.
--- gcc/cfgrtl.c.jj 2012-02-07 16:05:47.977533716 +0100
+++ gcc/cfgrtl.c
On Mon, 5 Mar 2012, Jakub Jelinek wrote:
> Hi!
>
> Here is a tiny cleanup, written as part of PR52139 fix.
> Bootstrapped/regtested on x86_64-linux and i686-linux,
> ok for trunk?
Ok.
Thanks,
Richard.
> 2012-03-05 Jakub Jelinek
>
> * cfgrtl.c (cfg_layout_merge_blocks): Cleanup.
>
>
Hi!
This patch changes local_specializations into a pointer map.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2012-03-05 Jakub Jelinek
* pt.c (local_specializations): Change from htab_t into
struct pointer_map_t *.
(retrieve_local_specializatio
This handles VECTOR_CSTs in integer_zerop, integer_onep and
integer_all_onesp to allow trivial foldings to work on them.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.
Richard.
2012-03-05 Richard Guenther
* tree.c (integer_zerop): Handle VECTOR_CSTs.
Hello Uros,
> As the first remark, you don't have to add BLKmode memory clobbers.
> unspec_volatile RTX is considered to use and clobber all memory:
>
Thanks, fixed!
>
> But, I think that we want to use code label from the top of the false
> branch instead of ".+6". The question is, how to get i
Adding patch
On Mon, Mar 5, 2012 at 3:30 PM, Kirill Yukhin wrote:
> Hello Uros,
>
>> As the first remark, you don't have to add BLKmode memory clobbers.
>> unspec_volatile RTX is considered to use and clobber all memory:
>>
>
> Thanks, fixed!
>
>>
>> But, I think that we want to use code label fr
On Mon, Mar 05, 2012 at 03:30:53PM +0400, Kirill Yukhin wrote:
> Agreed, this seems not as nice, but still it works :)
> I still do not understand, why not to put something like this?
> "xbegin\t1f\n1:"
> This is local label, which is not intercept others...
Because they should be reserved for inl
This patch fixes PR52353 towards a point we no longer ICE. We fail
to properly treat -ftrapv operations (or rather their libcall block)
as trapping after RTL expansion because we simply check may_trap_p
on the REG_EQUAL note. The following patch re-arranges
emit_libcall_block to take an addition
On Sat, Mar 3, 2012 at 00:35, FX wrote:
> Hi all,
>
> I'll offer my first patch to the new 4.8 trunk. I noticed that the
> -fbacktrace option and the GFORTRAN_ERROR_BACKTRACE environment variable are
> somewhat inconsistently handled. Currently, the environment variabled doesn't
> actually over
On Mon, Mar 5, 2012 at 3:34 PM, Jakub Jelinek wrote:
> On Mon, Mar 05, 2012 at 03:30:53PM +0400, Kirill Yukhin wrote:
>> Agreed, this seems not as nice, but still it works :)
>> I still do not understand, why not to put something like this?
>> "xbegin\t1f\n1:"
>> This is local label, which is not
On Mon, Mar 5, 2012 at 1:02 PM, Kirill Yukhin wrote:
>>> Agreed, this seems not as nice, but still it works :)
>>> I still do not understand, why not to put something like this?
>>> "xbegin\t1f\n1:"
>>> This is local label, which is not intercept others...
>>
>> Because they should be reserved fo
On Wed, Jan 18, 2012 at 3:21 PM, Richard Guenther wrote:
>
> This fixes PR49484 by protecting __gcov_flush against concurrent
> execution. To be able to use the gthread facility I have to
> introduce the requirement that __GTHREAD_MUTEX_INIT_FUNCTION
> is always available, even if __GTHREAD_MUTEX
On Mon, 5 Mar 2012, Jakub Jelinek wrote:
> Hi!
>
> I'd like to ping two patches deferred to 4.8. I've bootstrapped/regtested
> them on x86_64-linux and i686-linux:
>
> - PR51721 VRP register_edge_assert_for_2 improvements
> http://gcc.gnu.org/ml/gcc-patches/2012-01/msg00046.html
Ok.
Thanks,
The following patch adds checking to calculate_dominance_info that
if we re-use existing dominance info it is correct (unsurprisingly
this wasn't always the case, noticed when using verify_loop_structure
in random places ...).
Bootstrap and regtest pending on x86_64-unknown-linux-gnu.
Do people
This fixes PRs 52080 (unexpected access to adjacent fields for bitfield
access), 52097 (ICE with the C++ memory model enabled) and 48124
(wrong code accessing adjacent objects). It's an unchanged re-post
of the RFCs I sent out during stage4 (it now re-uses the pointer
for DECL_QUALIFIER instead o
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 particularly bad: it would to acquire _all_ locks in
such a case du
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
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
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
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
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
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
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
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
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 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
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 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~
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
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 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
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
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.
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
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,
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 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
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 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
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 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 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
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 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
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 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
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: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 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 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 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
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: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
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 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
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,
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
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:
>
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
OK.
Jason
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
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
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
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
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 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
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/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
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 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.
> --- 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 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
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 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/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~
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=:
> 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.
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
> -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 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
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~
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.
> 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
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
Er, not actually a C++ patch. Fingers on autopilot...
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
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
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,
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, 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_
1 - 100 of 126 matches
Mail list logo
