On Mon, Mar 5, 2012 at 9:01 AM, Uros Bizjak ubiz...@gmail.com 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
On Fri, Mar 2, 2012 at 9:56 PM, H.J. Lu hongjiu...@intel.com 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
On Fri, Mar 2, 2012 at 10:14 PM, H.J. Lu hongjiu...@intel.com 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
2012/3/5 Andrey Belevantsev a...@ispras.ru:
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
Richard Sandiford rdsandif...@googlemail.com writes:
Rainer Orth r...@cebitec.uni-bielefeld.de writes:
2012-02-22 Rainer Orth r...@cebitec.uni-bielefeld.de
* config/mips/iris6.h [!USED_FOR_TARGET] (long_intmax): Declare.
(INTMAX_TYPE): Use it.
(UINTMAX_TYPE): Likewise.
On Mon, 5 Mar 2012, Rainer Orth wrote:
Richard Sandiford rdsandif...@googlemail.com writes:
Rainer Orth r...@cebitec.uni-bielefeld.de writes:
2012-02-22 Rainer Orth r...@cebitec.uni-bielefeld.de
* config/mips/iris6.h [!USED_FOR_TARGET] (long_intmax): Declare.
(INTMAX_TYPE):
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
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 ja...@redhat.com
* cfgrtl.c (cfg_layout_merge_blocks): Cleanup.
--- gcc/cfgrtl.c.jj 2012-02-07 16:05:47.977533716 +0100
+++
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 ja...@redhat.com
* cfgrtl.c (cfg_layout_merge_blocks):
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 ja...@redhat.com
* pt.c (local_specializations): Change from htab_t into
struct pointer_map_t *.
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 rguent...@suse.de
* tree.c (integer_zerop): Handle
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 it ...
Adding patch
On Mon, Mar 5, 2012 at 3:30 PM, Kirill Yukhin kirill.yuk...@gmail.com 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
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
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
On Sat, Mar 3, 2012 at 00:35, FX fxcoud...@gmail.com 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
On Mon, Mar 5, 2012 at 3:34 PM, Jakub Jelinek ja...@redhat.com 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
On Mon, Mar 5, 2012 at 1:02 PM, Kirill Yukhin kirill.yuk...@gmail.com 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
On Wed, Jan 18, 2012 at 3:21 PM, Richard Guenther rguent...@suse.de 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
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
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
On Mon, Mar 5, 2012 at 2:34 PM, Torvald Riegel trie...@redhat.com 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
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
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 remainder.
On Mon, Mar 5, 2012 at 3:11 PM, Georg-Johann Lay a...@gjlay.de 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
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
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
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 manager
On Mon, Mar 5, 2012 at 4:25 PM, Georg-Johann Lay a...@gjlay.de 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 the
On Fri, Mar 2, 2012 at 9:36 PM, H.J. Lu hongjiu...@intel.com 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
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
Richard Guenther wrote:
On Mon, Mar 5, 2012 at 4:25 PM, Georg-Johann Lay a...@gjlay.de 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,
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 Sonisoni.sande...@gmail.com
* parser.c : Include hashtab.h.
(gimple_symtab): New. The symbol table.
(gimple_symtab_entry_hash): New.
(gimple_symtab_eq_hash): New.
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
On Mon, Mar 5, 2012 at 4:56 PM, Georg-Johann Lay a...@gjlay.de wrote:
Richard Guenther wrote:
On Mon, Mar 5, 2012 at 4:25 PM, Georg-Johann Lay a...@gjlay.de wrote:
Richard Guenther wrote:
All commits to the 4.7 branch need explicit release manager approval. AVR
isn't primary/secondary so
On Mon, Mar 5, 2012 at 7:31 AM, Uros Bizjak ubiz...@gmail.com wrote:
On Fri, Mar 2, 2012 at 9:36 PM, H.J. Lu hongjiu...@intel.com wrote:
X86-64 linker optimizes TLS_MODEL_INITIAL_EXEC to TLS_MODEL_LOCAL_EXEC
by checking
movq foo@gottpoff(%rip), %reg
and
addq
Uros Bizjak ubiz...@gmail.com 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
Aldy Hernandez al...@redhat.com 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
On Sun, Mar 4, 2012 at 11:47 PM, Uros Bizjak ubiz...@gmail.com wrote:
On Mon, Mar 5, 2012 at 4:53 AM, H.J. Lu hjl.to...@gmail.com 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
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 ubiz...@gmail.com wrote:
On Sun, Mar 4, 2012 at 11:01 PM, H.J. Lu hjl.to...@gmail.com wrote:
@@ -11388,6 +11400,11 @@ ix86_decompose_address (rtx addr, struct
ix86_address *out)
else
disp = addr; /* displacement */
+
Richard Guenther wrote:
On Mon, Mar 5, 2012 at 4:56 PM, Georg-Johann Lay a...@gjlay.de wrote:
Richard Guenther wrote:
On Mon, Mar 5, 2012 at 4:25 PM, Georg-Johann Lay a...@gjlay.de wrote:
Richard Guenther wrote:
All commits to the 4.7 branch need explicit release manager approval. AVR
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 was
On Mon, Mar 5, 2012 at 12:24 AM, Uros Bizjak ubiz...@gmail.com wrote:
On Mon, Mar 5, 2012 at 9:01 AM, Uros Bizjak ubiz...@gmail.com wrote:
@@ -11388,6 +11400,11 @@ ix86_decompose_address (rtx addr, struct
ix86_address *out)
else
disp = addr; /* displacement */
+
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 Sun
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 this a bug in the
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
On 03/05/2012 09:20 AM, Rainer Orth wrote:
2012-02-24 Rainer Orth r...@cebitec.uni-bielefeld.de
* 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.
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 hjl.to...@gmail.com 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
On Mon, Mar 5, 2012 at 9:20 AM, Jakub Jelinek ja...@redhat.com 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 a...@gjlay.de wrote:
Richard Guenther wrote:
On Mon, Mar 5, 2012 at 4:56 PM, Georg-Johann Lay a...@gjlay.de wrote:
Richard Guenther wrote:
On Mon, Mar 5, 2012 at 4:25 PM, Georg-Johann Lay a...@gjlay.de wrote:
Richard Guenther wrote:
All
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
I
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 ja...@redhat.com 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
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.
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 for
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
On Mon, Mar 5, 2012 at 9:12 PM, Andi Kleen a...@firstfloor.org 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
Jakub Jelinek ja...@redhat.com 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
Richard Guenther wrote:
On Mon, Mar 5, 2012 at 6:15 PM, Georg-Johann Lay a...@gjlay.de wrote:
Richard Guenther wrote:
On Mon, Mar 5, 2012 at 4:56 PM, Georg-Johann Lay a...@gjlay.de wrote:
Richard Guenther wrote:
On Mon, Mar 5, 2012 at 4:25 PM, Georg-Johann Lay a...@gjlay.de wrote:
Richard
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
Richard Henderson r...@redhat.com 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
Bruce Korb bk...@gnu.org 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
On Mon, Mar 5, 2012 at 6:12 PM, Andi Kleen a...@firstfloor.org 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
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
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
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,
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);
+
On 03/05/12 11:08, Rainer Orth wrote:
Aldy Hernandezal...@redhat.com 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
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 mikpe at it dot uu.se 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
On Mon, Mar 05, 2012 at 07:04:47PM +0100, Uros Bizjak wrote:
On Mon, Mar 5, 2012 at 6:12 PM, Andi Kleen a...@firstfloor.org 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
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 a...@firstfloor.org 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
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 a...@firstfloor.org 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.
-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 documentation
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
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 code
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
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 ja...@redhat.com
Date:
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
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; , file);
+
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
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
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 ja...@redhat.com 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
1 - 100 of 122 matches
Mail list logo
