Re: [PATCH] Fix sanitizer build on sparc64.
Konstantin Serebryany writes: > On Wed, Nov 21, 2012 at 2:50 AM, Andreas Schwab wrote: >> David Miller writes: >> >>> +// Are we using 32-bit or 64-bit syscalls? >>> +// x32 (which defines __x86_64__) has __WORDSIZE == 32 >>> +// but it still needs to use 64-bit syscalls. >>> +#if defined(__x86_64__) || __WORDSIZE == 64 >> >> I don't think it is a good idea to use a glibc-internal macro. How >> about __LP64__? > > __WORDSIZE is used throughout the library; That doesn't make it any better. > it is also redefined > properly for the compilers which don't have it and may not have > __LP64__ ??? __WORDSIZE is only defined by glibc. __LP64__ (or _LP64) is a standard macro defined by the compiler. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: Sparc ASAN
On Tue, Nov 20, 2012 at 11:19:33PM -0500, David Miller wrote:
> From: David Miller
> Date: Tue, 20 Nov 2012 21:20:40 -0500 (EST)
>
> > Those seem to be the only problems that need to be resolved for this
> > feature to be fully working.
>
> FWIW, here are the changes I am using which, besides the sparc backend
> bits, has some temporary workarounds for the issues I brought up.
To explain a little bit these unaligned stores.
>From what I understand LLVM will always put all the ASAN protected
automatic vars into a single block and align the whole block to 32 bytes
(on i?86/x86_64 in GCC that is the backend dynamic stack realignment,
those andq $-32, %rsp etc. in the prologue, on other targets rth added
a release or two ago handling of these via alloca that where the alloca
allocates up to the alignment - 1 bytes more and we add alignment - 1
to the result of alloca and mask it).
But it seemed nothing on the libasan relies on it actually being 32-byte
aligned, so what I've implemented was keep the vars as aligned as they
were before (well, the base), and just put the padding in between as if
the base was 32-byte aligned and I wanted to align them all to 32-bytes
(ignoring here in the description more aligned vars etc.).
That of course means the shadow memory stores may be unaligned, but as
i?86/x86_64 were the only supported targets initially, and the unaligned
stores are IMHO pretty fast there, it isn't a big deal.
Now, for strict alignment targets, the question is what is the fastest
way to implement this. There is the cost of dynamically realigning the
stack var block (which isn't just about the alloca at the beginning, but
also pretty much having one extra register reserved for the result of
the alloca, used as the base to access all the local vars, sure, you can
spill it, but if it is used frequently, it will likely be assigned to a hard
reg most of its lifetime), and on the other side there is the cost of
accessing the shadow memory at smaller granularity.
If some target has the virtual-stack-vars reg not even 8 byte aligned,
some realignment is required, as the shadow shift is 3.
If it is just 8 byte aligned and we don't realign the block, then yes,
shadow memory needs to be accessed by bytes, if it is 16 byte aligned,
perhaps we could use 16-bit stores instead of just 8-bit ones.
And perhaps the decision (for strict alignment arches) whether to realign or
not the whole block could be best dynamic, for small number of asan
protected vars (i.e. small number of expected shadow memory stores)
we could just not realign and use 8-bit or 16-bit shadow memory stores,
for larger amounts of vars perhaps it might be cheaper to realign.
So, concerning your patch, which implements basically the never realign,
just sometimes use smaller size of shadow memory accesses, the decision
shouldn't be done solely based on STRICT_ALIGNMENT, but needs to take
into account the alignment of virtual_stack_vars_rtx in the current
function, if it's byte alignment is >= (4 << ASAN_SHADOW_SHIFT), then
you can use the same code as for !STRICT_ALIGNMENT, if it's byte alignment
is >= (2 << ASAN_SHADOW_SHIFT), then you can use HImode stores, otherwise
QImode.
> --- a/gcc/asan.c
> +++ b/gcc/asan.c
> @@ -321,7 +321,10 @@ asan_emit_stack_protection (rtx base, HOST_WIDE_INT
> *offsets, tree *decls,
> NULL_RTX, 1, OPTAB_DIRECT);
>gcc_assert (asan_shadow_set != -1
> && (ASAN_RED_ZONE_SIZE >> ASAN_SHADOW_SHIFT) == 4);
> - shadow_mem = gen_rtx_MEM (SImode, shadow_base);
> + if (STRICT_ALIGNMENT)
> +shadow_mem = gen_rtx_MEM (QImode, shadow_base);
> + else
> +shadow_mem = gen_rtx_MEM (SImode, shadow_base);
>set_mem_alias_set (shadow_mem, asan_shadow_set);
>prev_offset = base_offset;
>for (l = length; l; l -= 2)
> @@ -349,7 +352,20 @@ asan_emit_stack_protection (rtx base, HOST_WIDE_INT
> *offsets, tree *decls,
> }
> else
> shadow_bytes[i] = ASAN_STACK_MAGIC_PARTIAL;
> - emit_move_insn (shadow_mem, asan_shadow_cst (shadow_bytes));
> + if (STRICT_ALIGNMENT)
> + {
> + for (i = 0; i < 4; i++)
> + {
> + rtx mem = adjust_address (shadow_mem, VOIDmode, i);
> + rtx val;
> +
> + val = GEN_INT (trunc_int_for_mode (shadow_bytes[i],
> + QImode));
> + emit_move_insn (mem, val);
> + }
> + }
> + else
> + emit_move_insn (shadow_mem, asan_shadow_cst (shadow_bytes));
> offset = aoff;
> }
>while (offset <= offsets[l - 2] - ASAN_RED_ZONE_SIZE)
> @@ -359,7 +375,22 @@ asan_emit_stack_protection (rtx base, HOST_WIDE_INT
> *offsets, tree *decls,
> >> ASAN_SHADOW_SHIFT);
> prev_offset = offset;
> memset (shadow_bytes, cur_shadow_byte, 4);
> - emit_move_insn (shadow_mem, asan_shadow_cst (shadow_bytes));
Re: [PATCH, RFC] Enable libsanitizer on powerpc{,64}
The ARM/Android failure is due to libstdc++ in android-ndk-r8b not containing debug info. As a result, stack unwinding breaks in "operator new", after exactly 2 frames. I guess we can simply tweak the assert to be OK with empty stack traces when user code stack can not be unwinded. Matching FP or SP also sounds good, and perhaps more reliable than just popping 2 frames from the top of the stack. AFAIK, the debug info issue is fixed in the latest NDK release. On Wed, Nov 21, 2012 at 2:27 AM, Richard Henderson wrote: > On 11/20/2012 02:14 PM, Peter Bergner wrote: >> Doesn't this save us, since the bottom frame in the backtrace will always >> be an ASAN functionand the frame we're interested in will always be higher >> in the backtrace? >> >> I guess I'm wondering, in this specific use case, do you think using >> the CFA to compare against is safe or not? > > Yes it saves us. I believe using the value of __builtin_dwarf_cfa from > the outermost ASAN function will reliably match the SP value of the > interesting user function outer of ASAN. > > > r~
Re: [RFC] Parallel build broken on trunk.
> Folks, Parallel builds contain a race due to a missing dependency > between gengtype-lex.o and $(BCONFIG_H). > > This was introduced by the commit: > > http://gcc.gnu.org/ml/gcc-patches/2010-11/msg00926.html > > .. which injects an include of bconfig.h into the top of > gengtype-lex.c but does not make both of the objects built from that > file dependent on bconfig.h > > There is a simple fix, below, but I'm concerned that this is just > papering over the cracks, is it really correct that both the build and > host machine variants include the same config file? Probably not, but I see your patch not as papering over but rather a missing piece of what's been committed in 2010. Fixing parallel builds does not preclude a better fix for build/host separation later. > diff --git a/gcc/Makefile.in b/gcc/Makefile.in > index d74e7b3..8e8f4d3 100644 > --- a/gcc/Makefile.in > +++ b/gcc/Makefile.in > @@ -3885,7 +3885,7 @@ build/gengenrtl.o : gengenrtl.c $(BCONFIG_H) > $(SYSTEM_H) rtl.def > # the build-%: rule doesn't apply to them. > > gengtype-lex.o build/gengtype-lex.o : gengtype-lex.c gengtype.h $(SYSTEM_H) > -gengtype-lex.o: $(CONFIG_H) > +gengtype-lex.o: $(CONFIG_H) $(BCONFIG_H) > CFLAGS-gengtype-lex.o += -DGENERATOR_FILE > build/gengtype-lex.o: $(BCONFIG_H) This is OK with a proper ChangeLog entry. Hopefully I am not overstepping my gengtype reviewer powers here. -- Laurynas
[www-docs] Add note to gcc-4.8/changes.html that DWARF4 is now the default.
As mentioned in some bug reports it should be documented that DWARF4 is now the default for 4.8 when -g is used (and that one might need a newer version of debugger/profiling/tracing tools to use it). So I added the following: Index: htdocs/gcc-4.8/changes.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.8/changes.html,v retrieving revision 1.61 diff -u -r1.61 changes.html --- htdocs/gcc-4.8/changes.html 20 Nov 2012 19:49:00 - 1.61 +++ htdocs/gcc-4.8/changes.html 21 Nov 2012 10:07:59 - @@ -53,6 +53,15 @@ General Optimizer Improvements (and Changes) +DWARF4 is now the default when generating DWARF debug information. + When -g is used on a platform that uses DWARF debugging information, + GCC will now default to -gdwarf-4 -fno-debug-types-section. + GDB 7.5, Valgrind 3.8.0 and elfutils 0.154 debug information consumers + support DWARF4 by default. Before GCC 4.8 the default version used + was DWARF2. To make GCC 4.8 generate an older DWARF version use -g + together with -gdwarf-2 or -gdwarf-3. The default for Darwin and + VxWorks is still -g-dwarf2 -gstrict-dwarf. + A new general optimization level, -Og, has been introduced. It addresses the need for fast compilation and a superior debugging experience while providing a reasonable level
Re: [www-docs] Add note to gcc-4.8/changes.html that DWARF4 is now the default.
On Wed, Nov 21, 2012 at 11:13:47AM +0100, Mark Wielaard wrote: > + VxWorks is still -g-dwarf2 -gstrict-dwarf. s/-g-dwarf2/-gdwarf-2/ Jakub
Re: [www-docs] Add note to gcc-4.8/changes.html that DWARF4 is now the default.
On Wed, 2012-11-21 at 11:16 +0100, Jakub Jelinek wrote: > On Wed, Nov 21, 2012 at 11:13:47AM +0100, Mark Wielaard wrote: > > + VxWorks is still -g-dwarf2 -gstrict-dwarf. > > s/-g-dwarf2/-gdwarf-2/ Oops. Fixed. Thanks, Mark
[PATCH] Recognize clones for all contexts in SCCs in IPA-CP
Hi,
in IPA-CP, a few functions look at callees of cgraph edges to see if
they still lead to the original node (those still need to be examined
or re-examined) or to a clone (those are considered already decided
and should be left alone). The problem is that currently, when
looking at an SCC, these functions decide not to "close" the SCC by
switching the last edge from a specialized clone to a specialized
clone because it already leads to a clone, albeit one for all
contexts.
In the testcase ipcp-agg-7.c that is part of this patch, this leads to
two copies of foo, one of them not specialized for known aggregate
values, even though there should have been just one.
The patch fixes this by introducing another flag is_all_contexts_clone
and testing it in the necessary functions. In order to avoid
confusion, I renamed already existing flag clone_for_all_contexts to
do_clone_for_all_contexts.
Additionally, I discovered that decide_whether_version_node contains a
bogus "|| !plats->aggs" in a test, which is harmless but just should
not be there, so I removed it.
Bootstrapped and tested on x86_64-linux. OK for trunk?
Martin
2012-11-20 Martin Jambor
* ipa-prop.h (struct ipa_node_params): Rename clone_for_all_contexts to
do_clone_for_all_contexts. Update all uses. New flag
is_all_contexts_clone.
* ipa-cp.c (cgraph_edge_brings_value_p): Also consider the case when cs
leads to the clone for all contexts.
(perhaps_add_new_callers): Likewise.
(decide_whether_version_node): Remove bogus !plats->aggs test. Set
is_all_contexts_clone when cloning for all contexts.
* testsuite/gcc.dg/ipa/ipcp-agg-7.c: New test.
* testsuite/gcc.dg/ipa/ipcp-agg-8.c: Likewise.
Index: src/gcc/ipa-cp.c
===
--- src.orig/gcc/ipa-cp.c
+++ src/gcc/ipa-cp.c
@@ -1828,7 +1828,7 @@ estimate_local_effects (struct cgraph_no
if (size <= 0
|| cgraph_will_be_removed_from_program_if_no_direct_calls (node))
{
- info->clone_for_all_contexts = true;
+ info->do_clone_for_all_contexts = true;
base_time = time;
if (dump_file)
@@ -1841,7 +1841,7 @@ estimate_local_effects (struct cgraph_no
{
if (size + overall_size <= max_new_size)
{
- info->clone_for_all_contexts = true;
+ info->do_clone_for_all_contexts = true;
base_time = time;
overall_size += size;
@@ -2314,8 +2314,9 @@ cgraph_edge_brings_value_p (struct cgrap
struct ipcp_value_source *src)
{
struct ipa_node_params *caller_info = IPA_NODE_REF (cs->caller);
+ struct ipa_node_params *dst_info = IPA_NODE_REF (cs->callee);
- if (IPA_NODE_REF (cs->callee)->ipcp_orig_node
+ if ((dst_info->ipcp_orig_node && !dst_info->is_all_contexts_clone)
|| caller_info->node_dead)
return false;
if (!src->val)
@@ -3177,8 +3178,9 @@ perhaps_add_new_callers (struct cgraph_n
while (cs)
{
enum availability availability;
-
- if (cgraph_function_node (cs->callee, &availability) == node
+ struct cgraph_node *dst = cgraph_function_node (cs->callee,
+ &availability);
+ if ((dst == node || IPA_NODE_REF (dst)->is_all_contexts_clone)
&& availability > AVAIL_OVERWRITABLE
&& cgraph_edge_brings_value_p (cs, src))
{
@@ -3337,8 +3339,8 @@ decide_whether_version_node (struct cgra
cgraph_node_name (node), node->uid);
gather_context_independent_values (info, &known_csts, &known_binfos,
-info->clone_for_all_contexts ? &known_aggs
-: NULL, NULL);
+ info->do_clone_for_all_contexts ? &known_aggs
+ : NULL, NULL);
for (i = 0; i < count ;i++)
{
@@ -3353,7 +3355,7 @@ decide_whether_version_node (struct cgra
ret |= decide_about_value (node, i, -1, val, known_csts,
known_binfos);
- if (!plats->aggs_bottom || !plats->aggs)
+ if (!plats->aggs_bottom)
{
struct ipcp_agg_lattice *aglat;
struct ipcp_value *val;
@@ -3370,8 +3372,9 @@ decide_whether_version_node (struct cgra
info = IPA_NODE_REF (node);
}
- if (info->clone_for_all_contexts)
+ if (info->do_clone_for_all_contexts)
{
+ struct cgraph_node *clone;
vec callers;
if (dump_file)
@@ -3381,11 +3384,12 @@ decide_whether_version_node (struct cgra
callers = collect_callers_of_node (node);
move_binfos_to_values (known_csts, known_binfos);
- create_specialized_node (node, known_csts,
+ clone = create_specialized_node (node, known_csts,
known_aggs_to_agg_replacement_list (known_agg
[aarch64-4.7][committed] Fix Bad backport of Refactor thunks code generation.
Hi,
Yesterday I committed a backport of this patch
http://gcc.gnu.org/ml/gcc-patches/2012-11/msg01398.html
which prevented aarch64-4.7 building due to a difference in how many
arguments plus_constant takes between trunk and 4.7.
Today I have fixed that by committing, as revision 193689, the patch
below as obvious.
Thanks (and sorry!),
James Greenhalgh
---
gcc/
2012-11-21 James Greenhalgh
* config/aarch64/aarch64.c
(aarch64_output_mi_thunk): Use 4.7 API for plus_constant.
diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index e121fd4..6da4db4 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -2286,7 +2286,7 @@ aarch64_output_mi_thunk (FILE *file, tree thunk ATTRIBUTE_UNUSED,
{
if (delta >= -256 && delta < 256)
addr = gen_rtx_PRE_MODIFY (Pmode, this_rtx,
- plus_constant (Pmode, this_rtx, delta));
+ plus_constant (this_rtx, delta));
else
aarch64_add_constant (file, this_regno, IP1_REGNUM, delta);
}
@@ -2294,7 +2294,7 @@ aarch64_output_mi_thunk (FILE *file, tree thunk ATTRIBUTE_UNUSED,
aarch64_emit_move (temp0, gen_rtx_MEM (Pmode, addr));
if (vcall_offset >= -256 && vcall_offset < 32768)
- addr = plus_constant (Pmode, temp0, vcall_offset);
+ addr = plus_constant (temp0, vcall_offset);
else
{
aarch64_build_constant (file, IP1_REGNUM, vcall_offset);
Re: [aarch64-4.7][committed] Fix Bad backport of Refactor thunks code generation.
On 21/11/12 10:55, James Greenhalgh wrote: Hi, Yesterday I committed a backport of this patch http://gcc.gnu.org/ml/gcc-patches/2012-11/msg01398.html which prevented aarch64-4.7 building due to a difference in how many arguments plus_constant takes between trunk and 4.7. Today I have fixed that by committing, as revision 193689, the patch below as obvious. Thanks (and sorry!), James Greenhalgh --- gcc/ 2012-11-21 James Greenhalgh * config/aarch64/aarch64.c (aarch64_output_mi_thunk): Use 4.7 API for plus_constant. OK. R.
RE: [PATCH][ARM][1/2] ARMv8 aarch32 round to integral instructions
Ping? Thanks, Kyrill -Original Message- From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-ow...@gcc.gnu.org] On Behalf Of Kyrylo Tkachov Sent: 14 November 2012 13:52 To: gcc-patches@gcc.gnu.org Cc: Richard Earnshaw; Ramana Radhakrishnan Subject: [PATCH][ARM][1/2] ARMv8 aarch32 round to integral instructions Hi all, This patch adds support for the vrint family of instructions in aarch32 (the 32-bit execution state in ARMv8). These are rounding instructions that can be used to implement round to integral functions from the math library such as: trunc, ceil, round, floor, nearbyint, rint. This patch implements the single and double precision variants of these functions. There is only one pattern for them in the machine description because it uses some new iterators to generate the correct variant for each function. The tests for this are coming in a second patch soon. These changes have been tested using AEM for the new functionality. Also, no regressions when testing for ARMv7-a (for which these changes should not have any effect) on qemu. Ok for trunk? Thanks, Kyrill gcc/ChangeLog 2012-11-14 Kyrylo Tkachov * config/arm/arm.h (TARGET_FPU_ARMV8): New macro. * config/arm/arm.md (UNSPEC_VRINTZ, UNSPEC_VRINTP, UNSPEC_VRINTM, UNSPEC_VRINTR, UNSPEC_VRINTX, UNSPEC_VRINTA): New unspecs. (f_rints, f_rintd): New types. * config/arm/iterators.md (VRINT): New int iterator. (F_fma_type): Remove. (vfp_type): New mode attribute. (vfp_double_cond): Likewise. (vrint_pattern, vrint_variant, vrint_predicable): New int attribute. * config/arm/vfp.md (fma4, *fmsub4, *fnmsub4, *fnmadd4): Use vfp_type iterator instead of F_fma_type. (2): New pattern.
RE: [PATCH][ARM][2/2] ARMv8 aarch32 round to integral instructions
Ping? Thanks, Kyrill -Original Message- From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-ow...@gcc.gnu.org] On Behalf Of Kyrylo Tkachov Sent: 14 November 2012 13:52 To: gcc-patches@gcc.gnu.org Cc: mikest...@comcast.net; Ramana Radhakrishnan; Richard Earnshaw Subject: [PATCH][ARM][2/2] ARMv8 aarch32 round to integral instructions Hi all, This patch adds the new tests for the vrint instructions in aarch32. It also adds an effective target check to see if we support an ARMv8 VFP and an add_options procedure for adding the required options to a testcase if we do. Ok for trunk? Thanks, Kyrill gcc/testsuite/ChangeLog 2012-11-21 Kyrylo Tkachov * lib/target-supports.exp (check_effective_target_arm_v8_vfp_ok): New procedure. (add_options_for_arm_v8_vfp): New procedure. * gcc.target/arm/vrintaf32.c: New test. * gcc.target/arm/vrintaf64.c: Likewise. * gcc.target/arm/vrintmf32.c: Likewise. * gcc.target/arm/vrintmf64.c: Likewise. * gcc.target/arm/vrintpf32.c: Likewise. * gcc.target/arm/vrintpf64.c: Likewise. * gcc.target/arm/vrintrf32.c: Likewise. * gcc.target/arm/vrintrf64.c: Likewise. * gcc.target/arm/vrintxf32.c: Likewise. * gcc.target/arm/vrintxf64.c: Likewise. * gcc.target/arm/vrintzf32.c: Likewise. * gcc.target/arm/vrintzf64.c: Likewise.
Re: [RFA/4.7/ARM] Backport arm-*-linux-gnueabihf triplet support to 4.7
On 21 November 2012 00:05, Matthias Klose wrote:
> Am 20.11.2012 21:34, schrieb Matthew Gretton-Dann:
>> All,
>>
>> This patch backports Matthais Klose's arm*-*-linux-gnueabihf triplet
>> support patch of 2012-10-15 to 4.7.
>>
>> The backport was not clean as 4.8 has obsoleted various arm*-*-*
>> triplets which are valid in 4.7.
>>
>> I have tested this cross with arm-none-linux-gnueabihf and
>> arm-none-linux-gnueabi.
>>
>> One question I do have having done this work - is there a canonical way to
>> test for the arm*-*-linux-gnueabi triplet (or variants)? Various configure
>> and testsuite files test for this, but there doesn't seem to be a consistent
>> method.
>>
>> OK for 4.7?
>
> looks fine, except one missing chunk from my original patch. maybe left out
> intentionally.
>
> Matthias
>
> Index: b/src/gcc/config.gcc
> ===
> --- a/src/gcc/config.gcc
> +++ b/src/gcc/config.gcc
> @@ -934,7 +934,7 @@
> tm_file="dbxelf.h elfos.h arm/unknown-elf.h arm/elf.h arm/linux-gas.h
> arm/uclinux-elf.h glibc-stdint.h"
> tmake_file="arm/t-arm arm/t-arm-elf"
> case ${target} in
> - arm*-*-uclinux*eabi)
> + arm*-*-uclinux*eabi*)
> tm_file="$tm_file arm/bpabi.h arm/uclinux-eabi.h"
> tmake_file="$tmake_file arm/t-bpabi"
> # The BPABI long long divmod functions return a 128-bit value in
This change isn't in your commit to trunk of 2012-10-15 which is what
I backported. This is because Richard Earnshaw effectively made this
change when he removed FPA support (SVN rev 188510).
I'm happy to do a patch that makes this change - but I think it should
be a separate patch to this backport one.
Thanks,
Matt
--
Matthew Gretton-Dann
Linaro Toolchain Working Group
matthew.gretton-d...@linaro.org
Re: [PATCH] Fix sanitizer build on sparc64.
On Wed, Nov 21, 2012 at 12:23 PM, Andreas Schwab wrote: > Konstantin Serebryany writes: > >> On Wed, Nov 21, 2012 at 2:50 AM, Andreas Schwab >> wrote: >>> David Miller writes: >>> +// Are we using 32-bit or 64-bit syscalls? +// x32 (which defines __x86_64__) has __WORDSIZE == 32 +// but it still needs to use 64-bit syscalls. +#if defined(__x86_64__) || __WORDSIZE == 64 >>> >>> I don't think it is a good idea to use a glibc-internal macro. How >>> about __LP64__? >> >> __WORDSIZE is used throughout the library; > > That doesn't make it any better. > >> it is also redefined >> properly for the compilers which don't have it and may not have >> __LP64__ > > ??? __WORDSIZE is only defined by glibc. __LP64__ (or _LP64) is a > standard macro defined by the compiler. libsanitizer is a third party library, its primary repository is not gcc. If we make such change (use __LP64__ instead of __WORDSIZE), we should make it upstream first. --kcc > > Andreas. > > -- > Andreas Schwab, sch...@linux-m68k.org > GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 > "And now for something completely different."
Re: [PATCH] Fix sanitizer build on sparc64.
On Wed, Nov 21, 2012 at 04:10:24PM +0400, Konstantin Serebryany wrote: > >> it is also redefined > >> properly for the compilers which don't have it and may not have > >> __LP64__ > > > > ??? __WORDSIZE is only defined by glibc. __LP64__ (or _LP64) is a > > standard macro defined by the compiler. > > libsanitizer is a third party library, its primary repository is not gcc. > If we make such change (use __LP64__ instead of __WORDSIZE), we should > make it upstream first. That is true, but it really should change, __WORDSIZE is a glibc private macro that other programs just shouldn't use. Jakub
Re: [aarch64-4.7][committed] Fix Bad backport of Refactor thunks code generation.
> Today I have fixed that by committing, as revision 193689, the patch > below as obvious. On the ARM/aarch64-4.7-branch the ChangeLog entry should be in ChangeLog.aarch64 rather than ChangeLog. Please move the entry. Cheers /Marcus
Re: [PATCH] Fix sanitizer build on sparc64.
>> >> libsanitizer is a third party library, its primary repository is not gcc. >> If we make such change (use __LP64__ instead of __WORDSIZE), we should >> make it upstream first. > > That is true, but it really should change, __WORDSIZE is a glibc private > macro that other programs just shouldn't use. Ok... I've committed http://llvm.org/viewvc/llvm-project?view=rev&revision=168424 upstream. (This defines SANITIZER_WORDSIZE based on __LP64__ and WIN64). --kcc
Re: [patch] [aarch64] add multiarch definitions for aarch64-linux-gnu
> --- config/aarch64/t-aarch64-linux (revision 193639) > +++ config/aarch64/t-aarch64-linux (working copy) > @@ -20,3 +20,6 @@ > > LIB1ASMSRC = aarch64/lib1funcs.asm > LIB1ASMFUNCS = _aarch64_sync_cache_range > + > +AARCH_BE = $(if $(findstring TARGET_BIG_ENDIAN_DEFAULT=1, $(tm_defines)),_be) > +MULTIARCH_DIRNAME = $(call if_multiarch,aarch64$(AARCH_BE)-linux-gnu) > OK /Marcus
Re: [PATCH] Use working set profile info to determine hotness (issue6852069)
> This patch uses the new working set information from the profile to select
> the hot count threshold for an application instead of using a hard cutoff.
> Currently the threshold is set by default to the minimum counter value
> needed to reach 99.9% of the profiled execution time, but I have added
> a parameter to control this.
>
> I saw a couple improvements in SPEC2006 on a Westmere, such as xalancbmk by a
> few
> percent.
>
> Bootstrapped and tested on x86_64-unknown-linux-gnu. Ok for trunk?
>
> Thanks,
> Teresa
>
>
> 2012-11-19 Teresa Johnson
>
> * predict.c (maybe_hot_count_p): Use threshold from profiled working
> set instead of hard limit.
> (cgraph_maybe_hot_edge_p): Invoke maybe_hot_count_p() instead of
> directly checking limit.
> * params.def (HOT_BB_COUNT_FRACTION): Remove.
> (HOT_BB_COUNT_WS_PERCENT): New parameter.
>
> Index: predict.c
> ===
> --- predict.c (revision 193614)
> +++ predict.c (working copy)
> @@ -134,13 +134,15 @@ maybe_hot_frequency_p (struct function *fun, int f
> static inline bool
> maybe_hot_count_p (struct function *fun, gcov_type count)
> {
> + gcov_working_set_t *ws;
>if (profile_status_for_function (fun) != PROFILE_READ)
> return true;
>/* Code executed at most once is not hot. */
>if (profile_info->runs >= count)
> return false;
> - return (count
> - > profile_info->sum_max / PARAM_VALUE (HOT_BB_COUNT_FRACTION));
> + ws = find_working_set (PARAM_VALUE (HOT_BB_COUNT_WS_PERCENT));
> + gcc_assert (ws);
> + return (count >= ws->min_counter);
I think you want to store the minimal count into a global variable to avoid the
repeated working set lookup.
> Index: params.def
> ===
> --- params.def(revision 193614)
> +++ params.def(working copy)
> @@ -365,10 +365,11 @@ DEFPARAM(PARAM_SMS_LOOP_AVERAGE_COUNT_THRESHOLD,
>"A threshold on the average loop count considered by the swing modulo
> scheduler",
>0, 0, 0)
>
> -DEFPARAM(HOT_BB_COUNT_FRACTION,
> - "hot-bb-count-fraction",
> - "Select fraction of the maximal count of repetitions of basic block in
> program given basic block needs to have to be considered hot",
> - 1, 0, 0)
> +DEFPARAM(HOT_BB_COUNT_WS_PERCENT,
> + "hot-bb-count-ws-percent",
> + "A basic block profile count is considered hot if it contributes to
> "
> + "the given percentage (times ten) of the entire profiled execution",
> + 999, 0, 1000)
And document the parameter.
Honza
> DEFPARAM(HOT_BB_FREQUENCY_FRACTION,
>"hot-bb-frequency-fraction",
>"Select fraction of the maximal frequency of executions of basic block
> in function given basic block needs to have to be considered hot",
> @@ -392,7 +393,7 @@ DEFPARAM (PARAM_ALIGN_LOOP_ITERATIONS,
> flatten the profile.
>
> We need to cut the maximal predicted iterations to large enough iterations
> - so the loop appears important, but safely within HOT_BB_COUNT_FRACTION
> + so the loop appears important, but safely within maximum hotness
> range. */
>
> DEFPARAM(PARAM_MAX_PREDICTED_ITERATIONS,
>
> --
> This patch is available for review at http://codereview.appspot.com/6852069
Re: [PATCH] Recognize clones for all contexts in SCCs in IPA-CP
> Hi, > > in IPA-CP, a few functions look at callees of cgraph edges to see if > they still lead to the original node (those still need to be examined > or re-examined) or to a clone (those are considered already decided > and should be left alone). The problem is that currently, when > looking at an SCC, these functions decide not to "close" the SCC by > switching the last edge from a specialized clone to a specialized > clone because it already leads to a clone, albeit one for all > contexts. > > In the testcase ipcp-agg-7.c that is part of this patch, this leads to > two copies of foo, one of them not specialized for known aggregate > values, even though there should have been just one. > > The patch fixes this by introducing another flag is_all_contexts_clone > and testing it in the necessary functions. In order to avoid > confusion, I renamed already existing flag clone_for_all_contexts to > do_clone_for_all_contexts. > > Additionally, I discovered that decide_whether_version_node contains a > bogus "|| !plats->aggs" in a test, which is harmless but just should > not be there, so I removed it. > > Bootstrapped and tested on x86_64-linux. OK for trunk? > > Martin > > > 2012-11-20 Martin Jambor > > * ipa-prop.h (struct ipa_node_params): Rename clone_for_all_contexts to > do_clone_for_all_contexts. Update all uses. New flag > is_all_contexts_clone. > > * ipa-cp.c (cgraph_edge_brings_value_p): Also consider the case when cs > leads to the clone for all contexts. > (perhaps_add_new_callers): Likewise. > (decide_whether_version_node): Remove bogus !plats->aggs test. Set > is_all_contexts_clone when cloning for all contexts. > > * testsuite/gcc.dg/ipa/ipcp-agg-7.c: New test. > * testsuite/gcc.dg/ipa/ipcp-agg-8.c: Likewise. OK, thanks! Honza
Re: [PATCH] Fix sanitizer build on sparc64.
Konstantin Serebryany writes: > libsanitizer is a third party library, its primary repository is not gcc. _LP64 is also defined by other compilers. Andreas. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different."
Re: [PATCH, PR 55260] Fix cgraph_edge_brings_all_agg_vals_for_node
> 2012-11-19 Martin Jambor > > PR tree-optimization/55260 > * ipa-cp.c (intersect_aggregates_with_edge): New function. > (find_aggregate_values_for_callers_subset): Part moved to the function > above. Call it. > (cgraph_edge_brings_all_agg_vals_for_node): Reimplemented using > intersect_aggregates_with_edge. > > * testsuite/g++.dg/torture/pr55260-2.C: New test. OK, thanks Honza
Re: rfc NOP vs CONVERT (was: Simplifying Gimple Generation)
Hi, On Tue, 20 Nov 2012, Martin Jambor wrote: > > +++ gcc/ipa-cp.c2009-09-29 15:29:05.0 +0200 > > @@ -298,7 +298,7 @@ ipcp_lattice_from_jfunc (struct ipa_node > > return; > >cst = caller_lat->constant; > > > > - if (jfunc->value.pass_through.operation != NOP_EXPR) > > + if (! CONVERT_EXPR_CODE_P (jfunc->value.pass_through.operation)) > > cst = fold_binary (jfunc->value.pass_through.operation, > >TREE_TYPE (cst), cst, > >jfunc->value.pass_through.operand); > > This will of course work but it is a bit strange, jump functions do > not do any conversions, NOP_EXPR operation really means they do > nothing to the value they pass. Similarly in ipa-prop.c. I see. So you're using NOP_EXPR really just as marker tree code not with its usual semantics (which includes conversions). My goal really was to totally get rid of any mention of NOP_EXPR starting with the middle end, with the next goal then being to exclusively use CONVERT_EXPR everywhere. So, while looking strange, I think IPA could also work with that marker being CONVERT_EXPR ultimately. Deserves a comment, though. And hey, who knows, perhaps eventually the jump functions could also express value conversion :) Ciao, Michael.
Re: [RFC] Parallel build broken on trunk.
On 21/11/12 09:48, Laurynas Biveinis wrote: Probably not, but I see your patch not as papering over but rather a missing piece of what's been committed in 2010. Fixing parallel builds does not preclude a better fix for build/host separation later. diff --git a/gcc/Makefile.in b/gcc/Makefile.in index d74e7b3..8e8f4d3 100644 --- a/gcc/Makefile.in +++ b/gcc/Makefile.in @@ -3885,7 +3885,7 @@ build/gengenrtl.o : gengenrtl.c $(BCONFIG_H) $(SYSTEM_H) rtl.def # the build-%: rule doesn't apply to them. gengtype-lex.o build/gengtype-lex.o : gengtype-lex.c gengtype.h $(SYSTEM_H) -gengtype-lex.o: $(CONFIG_H) +gengtype-lex.o: $(CONFIG_H) $(BCONFIG_H) CFLAGS-gengtype-lex.o += -DGENERATOR_FILE build/gengtype-lex.o: $(BCONFIG_H) This is OK with a proper ChangeLog entry. Hopefully I am not overstepping my gengtype reviewer powers here. Thanks for looking at this Laurynas. I've committed the attached to trunk. /Marcus 2012-11-21 Marcus Shawcroft * Makefile.in (gengtype-lex.o): Add dependency on $(BCONFIG_H). diff --git a/gcc/Makefile.in b/gcc/Makefile.in index d74e7b3..8e8f4d3 100644 --- a/gcc/Makefile.in +++ b/gcc/Makefile.in @@ -3885,7 +3885,7 @@ build/gengenrtl.o : gengenrtl.c $(BCONFIG_H) $(SYSTEM_H) rtl.def # the build-%: rule doesn't apply to them. gengtype-lex.o build/gengtype-lex.o : gengtype-lex.c gengtype.h $(SYSTEM_H) -gengtype-lex.o: $(CONFIG_H) +gengtype-lex.o: $(CONFIG_H) $(BCONFIG_H) CFLAGS-gengtype-lex.o += -DGENERATOR_FILE build/gengtype-lex.o: $(BCONFIG_H)
[PATCH, i386]: Simplify some SWI48x iterator uses
Hello!
SWI48x iterator with "(mode != DImode || TARGET_64BIT)"
insn constraint can be exactly represented with SWI48 mode iterator.
No functional change otherwise.
2012-11-21 Uros Bizjak
* config/i386/i386.md
(*float2_mixed_with_temp): Use SWI48 mode
iterator instead of SWI48x. Update insn constraint.
(*float2_mixed_interunit): Ditto.
(*float2_mixed_nointerunit): Ditto.
(*float2_sse_with_temp): Ditto.
(*float2_sse_interunit): Ditto.
(*float2_sse_nointerunit): Ditto.
(*float2 splitters): Ditto.
(lrint2): Ditto.
Tested on x86_64-pc-linux-gnu {,-m32}, committed to mainline SVN.
Uros.
Index: config/i386/i386.md
===
--- config/i386/i386.md (revision 193671)
+++ config/i386/i386.md (working copy)
@@ -4906,13 +4906,12 @@
(set_attr "bdver1_decode" "*,direct")
(set_attr "fp_int_src" "true")])
-(define_insn "*float2_mixed_with_temp"
+(define_insn "*float2_mixed_with_temp"
[(set (match_operand:MODEF 0 "register_operand" "=f,f,x,x")
(float:MODEF
- (match_operand:SWI48x 1 "nonimmediate_operand" "m,?r,r,m")))
- (clobber (match_operand:SWI48x 2 "memory_operand" "=X,m,m,X"))]
- "(mode != DImode || TARGET_64BIT)
- && SSE_FLOAT_MODE_P (mode) && TARGET_MIX_SSE_I387"
+ (match_operand:SWI48 1 "nonimmediate_operand" "m,?r,r,m")))
+ (clobber (match_operand:SWI48 2 "memory_operand" "=X,m,m,X"))]
+ "SSE_FLOAT_MODE_P (mode) && TARGET_MIX_SSE_I387"
"#"
[(set_attr "type" "fmov,multi,sseicvt,sseicvt")
(set_attr "mode" "")
@@ -4924,10 +4923,9 @@
(define_split
[(set (match_operand:MODEF 0 "register_operand")
- (float:MODEF (match_operand:SWI48x 1 "register_operand")))
- (clobber (match_operand:SWI48x 2 "memory_operand"))]
- "(mode != DImode || TARGET_64BIT)
- && SSE_FLOAT_MODE_P (mode) && TARGET_MIX_SSE_I387
+ (float:MODEF (match_operand:SWI48 1 "register_operand")))
+ (clobber (match_operand:SWI48 2 "memory_operand"))]
+ "SSE_FLOAT_MODE_P (mode) && TARGET_MIX_SSE_I387
&& TARGET_INTER_UNIT_CONVERSIONS
&& reload_completed
&& (SSE_REG_P (operands[0])
@@ -4937,10 +4935,9 @@
(define_split
[(set (match_operand:MODEF 0 "register_operand")
- (float:MODEF (match_operand:SWI48x 1 "register_operand")))
- (clobber (match_operand:SWI48x 2 "memory_operand"))]
- "(mode != DImode || TARGET_64BIT)
- && SSE_FLOAT_MODE_P (mode) && TARGET_MIX_SSE_I387
+ (float:MODEF (match_operand:SWI48 1 "register_operand")))
+ (clobber (match_operand:SWI48 2 "memory_operand"))]
+ "SSE_FLOAT_MODE_P (mode) && TARGET_MIX_SSE_I387
&& !(TARGET_INTER_UNIT_CONVERSIONS || optimize_function_for_size_p (cfun))
&& reload_completed
&& (SSE_REG_P (operands[0])
@@ -4949,24 +4946,23 @@
[(set (match_dup 2) (match_dup 1))
(set (match_dup 0) (float:MODEF (match_dup 2)))])
-(define_insn "*float2_mixed_interunit"
+(define_insn "*float2_mixed_interunit"
[(set (match_operand:MODEF 0 "register_operand" "=f,x,x")
(float:MODEF
- (match_operand:SWI48x 1 "nonimmediate_operand" "m,r,m")))]
- "(mode != DImode || TARGET_64BIT)
- && SSE_FLOAT_MODE_P (mode) && TARGET_MIX_SSE_I387
+ (match_operand:SWI48 1 "nonimmediate_operand" "m,r,m")))]
+ "SSE_FLOAT_MODE_P (mode) && TARGET_MIX_SSE_I387
&& (TARGET_INTER_UNIT_CONVERSIONS || optimize_function_for_size_p (cfun))"
"@
fild%Z1\t%1
- %vcvtsi2\t{%1, %d0|%d0, %1}
- %vcvtsi2\t{%1, %d0|%d0, %1}"
+ %vcvtsi2\t{%1, %d0|%d0, %1}
+ %vcvtsi2\t{%1, %d0|%d0, %1}"
[(set_attr "type" "fmov,sseicvt,sseicvt")
(set_attr "prefix" "orig,maybe_vex,maybe_vex")
(set_attr "mode" "")
(set (attr "prefix_rex")
(if_then_else
(and (eq_attr "prefix" "maybe_vex")
- (match_test "mode == DImode"))
+ (match_test "mode == DImode"))
(const_string "1")
(const_string "*")))
(set_attr "unit" "i387,*,*")
@@ -4975,23 +4971,22 @@
(set_attr "bdver1_decode" "*,double,direct")
(set_attr "fp_int_src" "true")])
-(define_insn "*float2_mixed_nointerunit"
+(define_insn "*float2_mixed_nointerunit"
[(set (match_operand:MODEF 0 "register_operand" "=f,x")
(float:MODEF
- (match_operand:SWI48x 1 "memory_operand" "m,m")))]
- "(mode != DImode || TARGET_64BIT)
- && SSE_FLOAT_MODE_P (mode) && TARGET_MIX_SSE_I387
+ (match_operand:SWI48 1 "memory_operand" "m,m")))]
+ "SSE_FLOAT_MODE_P (mode) && TARGET_MIX_SSE_I387
&& !(TARGET_INTER_UNIT_CONVERSIONS || optimize_function_for_size_p (cfun))"
"@
fild%Z1\t%1
- %vcvtsi2\t{%1, %d0|%d0, %1}"
+ %vcvtsi2\t{%1, %d0|%d0, %1}"
[(set_attr "type" "fmov,sseicvt")
(set_attr "prefix" "orig,maybe_vex")
(set_attr "mode" "")
(set (attr "prefix_rex")
(if_then_else
(and (eq_attr "prefix" "maybe_vex")
- (match_test "mode == DImode"))
+ (match_test "mode == DImode"))
(const_st
Re: Sparc ASAN
On Wed, Nov 21, 2012 at 1:05 PM, Jakub Jelinek wrote:
> On Tue, Nov 20, 2012 at 11:19:33PM -0500, David Miller wrote:
>> From: David Miller
>> Date: Tue, 20 Nov 2012 21:20:40 -0500 (EST)
>>
>> > Those seem to be the only problems that need to be resolved for this
>> > feature to be fully working.
>>
>> FWIW, here are the changes I am using which, besides the sparc backend
>> bits, has some temporary workarounds for the issues I brought up.
>
> To explain a little bit these unaligned stores.
> From what I understand LLVM will always put all the ASAN protected
> automatic vars into a single block and align the whole block to 32 bytes
> (on i?86/x86_64 in GCC that is the backend dynamic stack realignment,
> those andq $-32, %rsp etc. in the prologue, on other targets rth added
> a release or two ago handling of these via alloca that where the alloca
> allocates up to the alignment - 1 bytes more and we add alignment - 1
> to the result of alloca and mask it).
> But it seemed nothing on the libasan relies on it actually being 32-byte
> aligned,
I think your explanation is correct wrt the default mode, where the
memory to shadow ratio (mapping scale) is 8.
With greater values of mapping scale, you need greater alignment, but
these modes where never used except for experiment. So, don't bother.
As for the unaligned stores: aren't they 2x more expensive on x86
compared to properly aligned ones?
--kcc
> so what I've implemented was keep the vars as aligned as they
> were before (well, the base), and just put the padding in between as if
> the base was 32-byte aligned and I wanted to align them all to 32-bytes
> (ignoring here in the description more aligned vars etc.).
> That of course means the shadow memory stores may be unaligned, but as
> i?86/x86_64 were the only supported targets initially, and the unaligned
> stores are IMHO pretty fast there, it isn't a big deal.
>
> Now, for strict alignment targets, the question is what is the fastest
> way to implement this. There is the cost of dynamically realigning the
> stack var block (which isn't just about the alloca at the beginning, but
> also pretty much having one extra register reserved for the result of
> the alloca, used as the base to access all the local vars, sure, you can
> spill it, but if it is used frequently, it will likely be assigned to a hard
> reg most of its lifetime), and on the other side there is the cost of
> accessing the shadow memory at smaller granularity.
>
> If some target has the virtual-stack-vars reg not even 8 byte aligned,
> some realignment is required, as the shadow shift is 3.
> If it is just 8 byte aligned and we don't realign the block, then yes,
> shadow memory needs to be accessed by bytes, if it is 16 byte aligned,
> perhaps we could use 16-bit stores instead of just 8-bit ones.
> And perhaps the decision (for strict alignment arches) whether to realign or
> not the whole block could be best dynamic, for small number of asan
> protected vars (i.e. small number of expected shadow memory stores)
> we could just not realign and use 8-bit or 16-bit shadow memory stores,
> for larger amounts of vars perhaps it might be cheaper to realign.
>
> So, concerning your patch, which implements basically the never realign,
> just sometimes use smaller size of shadow memory accesses, the decision
> shouldn't be done solely based on STRICT_ALIGNMENT, but needs to take
> into account the alignment of virtual_stack_vars_rtx in the current
> function, if it's byte alignment is >= (4 << ASAN_SHADOW_SHIFT), then
> you can use the same code as for !STRICT_ALIGNMENT, if it's byte alignment
> is >= (2 << ASAN_SHADOW_SHIFT), then you can use HImode stores, otherwise
> QImode.
>
>> --- a/gcc/asan.c
>> +++ b/gcc/asan.c
>> @@ -321,7 +321,10 @@ asan_emit_stack_protection (rtx base, HOST_WIDE_INT
>> *offsets, tree *decls,
>> NULL_RTX, 1, OPTAB_DIRECT);
>>gcc_assert (asan_shadow_set != -1
>> && (ASAN_RED_ZONE_SIZE >> ASAN_SHADOW_SHIFT) == 4);
>> - shadow_mem = gen_rtx_MEM (SImode, shadow_base);
>> + if (STRICT_ALIGNMENT)
>> +shadow_mem = gen_rtx_MEM (QImode, shadow_base);
>> + else
>> +shadow_mem = gen_rtx_MEM (SImode, shadow_base);
>>set_mem_alias_set (shadow_mem, asan_shadow_set);
>>prev_offset = base_offset;
>>for (l = length; l; l -= 2)
>> @@ -349,7 +352,20 @@ asan_emit_stack_protection (rtx base, HOST_WIDE_INT
>> *offsets, tree *decls,
>> }
>> else
>> shadow_bytes[i] = ASAN_STACK_MAGIC_PARTIAL;
>> - emit_move_insn (shadow_mem, asan_shadow_cst (shadow_bytes));
>> + if (STRICT_ALIGNMENT)
>> + {
>> + for (i = 0; i < 4; i++)
>> + {
>> + rtx mem = adjust_address (shadow_mem, VOIDmode, i);
>> + rtx val;
>> +
>> + val = GEN_INT (trunc_int_for_mode (shadow_bytes[i],
>> + QImode));
>> + emit_move_insn
[AARCH64-4.7, PATCH, committed] Fix race in parallel build.
I've just committed the attached back port of: http://gcc.gnu.org/ml/gcc-patches/2012-11/msg01775.html to the ARM/aarch64-4.7-branch. /Marcus 2012-11-21 Marcus Shawcroft * Makefile.in (gengtype-lex.o): Add dependency on $(BCONFIG_H). Index: gcc/Makefile.in === --- gcc/Makefile.in (revision 193692) +++ gcc/Makefile.in (revision 193693) @@ -3888,7 +3888,7 @@ $(SYSTEM_H) coretypes.h $(GTM_H) errors.h $(READ_MD_H) gensupport.h build/gengenrtl.o : gengenrtl.c $(BCONFIG_H) $(SYSTEM_H) rtl.def gengtype-lex.o build/gengtype-lex.o : gengtype-lex.c gengtype.h $(SYSTEM_H) -gengtype-lex.o: $(CONFIG_H) +gengtype-lex.o: $(CONFIG_H) $(BCONFIG_H) build/gengtype-lex.o: $(BCONFIG_H) gengtype-parse.o build/gengtype-parse.o : gengtype-parse.c gengtype.h \ $(SYSTEM_H)
Re: Sparc ASAN (was Re: sparc bootstrap still broken)
On Wed, Nov 21, 2012 at 6:20 AM, David Miller wrote:
> From: David Miller
> Date: Tue, 20 Nov 2012 14:59:10 -0500 (EST)
>
>> From: Konstantin Serebryany
>> Date: Tue, 20 Nov 2012 23:52:48 +0400
>>
>>> Please apply whatever minimal patch required to unbreak the SPARC
>>> build. We will not be accepting any non-trivial patches until we
>>> set up semi-automated way to pull the upstream sources.
>>
>> Will do.
>
> I tossed together a quick sparc implementation and there seems to
> be only two issues to fix:
>
> 1) As noticed by the powerpc people, you have to probe the page
>size of the system properly. It's variable even within a
>target/OS.
>
>Probably a new hook, implemented in asan_linux.cc via:
>
> #include
>
> uptr GetPageSize()
> {
> return getpagesize();
> }
Today, kPageSize is used in several places where it is expected to be
a compile-time constant.
Even if it seems like replacing it with GetPageSize() is safe, it
would need very significant testing (including performance testing).
Can we just define kPageSize=1UL<<13 under ifdef __sparc__?
What are the possible page size values for SPARC?
>
>I would just get rid of kPageSizeBits,
Indeed, this is not used any more. Removed.
http://llvm.org/viewvc/llvm-project?rev=168426&view=rev
--kcc
> rather than compute it
>dynamically as well, as it's really not used as far as I can tell.
>
>The mmap of the shadow area won't work on sparc without this being
>resolved.
>
> 2) The current code emitted to set the shadow values results in
>unaligned stores. For example, for the memcmp-1.c test on 32-bit
>we get:
>
>0x10488 :add %fp, -160, %i5
> ...
>0x10490 : sethi %hi(0xf1f1f000), %g2
> ...
>0x104a0 : srl %i5, 3, %i5
> ...
>0x104a8 : or %g2, 0x1f1, %g2
>0x104ac : sethi %hi(0x2000), %g1
> ...
> => 0x104b4 : st %g2, [ %i5 + %g1 ]
>
>Here %fp is 0xd538, and this %i5 + %g1 is 0x3a93, which
>is not aligned properly for a 32-bit store.
>
>Therefore, this won't work for any STRICT_ALIGNMENT target.
>
> Those seem to be the only problems that need to be resolved for this
> feature to be fully working.
Re: Reduce complette unrolling & peeling limits
Hi Jan,
> this is patch I will try to test once I have chance :)
> It simply prevents unroller from analyzing loops when they are already too
> large.
> ...
This patch breaks bootstrap with
...
/opt/gcc/p_build/./prev-gcc/g++ -B/opt/gcc/p_build/./prev-gcc/
-B/opt/gcc/gcc4.8p-193652p3/x86_64-apple-darwin10.8.0/bin/ -nostdinc++
-B/opt/gcc/p_build/prev-x86_64-apple-darwin10.8.0/libstdc++-v3/src/.libs
-B/opt/gcc/p_build/prev-x86_64-apple-darwin10.8.0/libstdc++-v3/libsupc++/.libs
-I/opt/gcc/p_build/prev-x86_64-apple-darwin10.8.0/libstdc++-v3/include/x86_64-apple-darwin10.8.0
-I/opt/gcc/p_build/prev-x86_64-apple-darwin10.8.0/libstdc++-v3/include
-I/opt/gcc/p_work/libstdc++-v3/libsupc++
-L/opt/gcc/p_build/prev-x86_64-apple-darwin10.8.0/libstdc++-v3/src/.libs
-L/opt/gcc/p_build/prev-x86_64-apple-darwin10.8.0/libstdc++-v3/libsupc++/.libs
-c -g -O2 -mdynamic-no-pic -gtoggle -DIN_GCC -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long
-Wno-variadic-macros -Wno-overlength-strings -Werror -DHAVE_CONFIG_H -I. -I.
-I../../p_work/gcc -I../../p_work/gcc/. -I../../p_work/gcc/../include
-I./../intl -I../../p_work/gcc/../libcpp/include -I/opt/mp/include
-I../../p_work/gcc/../libdecnumber -I../../p_work/gcc/../libdecnumber/dpd
-I../libdecnumber -I../../p_work/gcc/../libbacktrace -DCLOOG_INT_GMP
-I/opt/mp/include ../../p_work/gcc/tree-ssa-loop-ivopts.c -o
tree-ssa-loop-ivopts.o
../../p_work/gcc/tree-ssa-loop-ivcanon.c: In function 'bool
canonicalize_loop_induction_variables(loop*, bool, unroll_level, bool)':
../../p_work/gcc/tree-ssa-loop-ivcanon.c:690:62: error: 'n_unroll' may be used
uninitialized in this function [-Werror=maybe-uninitialized]
&& (!n_unroll_found || (unsigned HOST_WIDE_INT)maxiter < n_unroll))
^
../../p_work/gcc/tree-ssa-loop-ivcanon.c:656:26: note: 'n_unroll' was declared
here
unsigned HOST_WIDE_INT n_unroll, ninsns, max_unroll, unr_insns;
^
cc1plus: all warnings being treated as errors
...
I have completed bootstrap with the following change
--- ../_clean/gcc/tree-ssa-loop-ivcanon.c 2012-11-18 11:27:28.0
+0100
+++ gcc/tree-ssa-loop-ivcanon.c 2012-11-20 16:27:07.0 +0100
@@ -641,9 +641,10 @@ try_unroll_loop_completely (struct loop
enum unroll_level ul,
HOST_WIDE_INT maxiter)
{
- unsigned HOST_WIDE_INT n_unroll, ninsns, max_unroll, unr_insns;
+ unsigned HOST_WIDE_INT ninsns, max_unroll, unr_insns;
gimple cond;
struct loop_size size;
+ unsigned HOST_WIDE_INT n_unroll = 0;
bool n_unroll_found = false;
edge edge_to_cancel = NULL;
int num = loop->num;
After that the compilation of gcc.c-torture/compile/pr43186.c is back to
a fraction of a second, but I see the following regressions:
FAIL: gcc.dg/graphite/interchange-8.c scan-tree-dump-times graphite "will be
interchanged" 2
FAIL: gcc.dg/graphite/pr42530.c (internal compiler error)
FAIL: gcc.dg/graphite/pr42530.c (test for excess errors)
FAIL: gcc.dg/tree-ssa/cunroll-1.c scan-tree-dump cunrolli "Unrolled loop 1
completely .duplicated 2 times.."
FAIL: gcc.dg/tree-ssa/cunroll-1.c scan-tree-dump cunrolli "Last iteration exit
edge was proved true."
FAIL: gcc.dg/tree-ssa/cunroll-3.c scan-tree-dump cunrolli "Unrolled loop 1
completely .duplicated 1 times.."
FAIL: gcc.dg/tree-ssa/loop-36.c scan-tree-dump-not dce2 "c.array"
FAIL: gcc.dg/tree-ssa/loop-37.c scan-tree-dump-not optimized "my_array"
FAIL: gcc.dg/tree-ssa/pr21829.c scan-tree-dump-not optimized "if \\("
FAIL: libgomp.fortran/reduction2.f90 -O3 -fomit-frame-pointer execution test
FAIL: libgomp.fortran/reduction2.f90 -O3 -fomit-frame-pointer -funroll-loops
execution test
FAIL: libgomp.fortran/reduction2.f90 -O3 -fomit-frame-pointer
-funroll-all-loops -finline-functions execution test
FAIL: libgomp.fortran/reduction2.f90 -O3 -g execution test
FAIL: libgomp.fortran/reduction2.f90 -O3 -fomit-frame-pointer execution test
FAIL: libgomp.fortran/reduction2.f90 -O3 -fomit-frame-pointer -funroll-loops
execution test
FAIL: libgomp.fortran/reduction2.f90 -O3 -fomit-frame-pointer
-funroll-all-loops -finline-functions execution test
FAIL: libgomp.fortran/reduction2.f90 -O3 -g execution test
for both -m32 and -m64 +
FAIL: gcc.dg/tree-ssa/loadpre6.c scan-tree-dump-times pre "Insertions: 2" 1
with -m32.
Dominique
[libquadmath, patch, committed] PR55225: Add a configure check whether math.h has signgam
POSIX's lgamma uses signgam – and hence has "extern int signgam" in math.h.
However, C99's lgamma doesn't mention signgam – and systems exist where
math.h doesn't include it.
Solution: A configure check. Comitted as Rev. 193695.
Tobias
2012-11-21 Tobias Burnus
PR libquadmath/55225
* math/lgammaq.c (lgammaq): Use local variable if
math.h does not provide signgam.
* acinclude.m4 (LIBQUAD_CHECK_MATH_H_SIGNGAM): New check.
* configure.ac: Use it.
* configure: Regenerate.
* config.h.in: Regenerate.
diff --git a/libquadmath/acinclude.m4 b/libquadmath/acinclude.m4
index 38e0808..ab73fb5 100644
--- a/libquadmath/acinclude.m4
+++ b/libquadmath/acinclude.m4
@@ -10,3 +10,20 @@ AC_DEFUN([AM_PROG_LIBTOOL])
AC_DEFUN([AC_LIBTOOL_DLOPEN])
AC_DEFUN([AC_PROG_LD])
])
+
+dnl Check whether POSIX's signgam is defined in math.h.
+AC_DEFUN([LIBQUAD_CHECK_MATH_H_SIGNGAM], [
+ AC_CACHE_CHECK([whether the math.h includes POSIX's signgam],
+ libgfor_cv_have_math_h_signgam, [
+ save_CFLAGS="$CFLAGS"
+ CFLAGS="$CFLAGS -Werror"
+ AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[
+#include
+void foo(void) { signgam = 1; }]], [])],
+libgfor_cv_have_math_h_signgam=yes,
+libgfor_cv_have_math_h_signgam=no)
+ CFLAGS="$save_CFLAGS"])
+ if test $libgfor_cv_have_math_h_signgam = yes; then
+AC_DEFINE(HAVE_MATH_H_SIGNGAM, 1,
+ [Define to 1 if the math.h includes POSIX's signgam.])
+ fi])
diff --git a/libquadmath/configure.ac b/libquadmath/configure.ac
index d3bfb04..c547da8 100644
--- a/libquadmath/configure.ac
+++ b/libquadmath/configure.ac
@@ -113,6 +113,7 @@ AC_SUBST(toolexecdir)
AC_SUBST(toolexeclibdir)
AC_CHECK_HEADERS(fenv.h langinfo.h locale.h wchar.h wctype.h limits.h ctype.h printf.h errno.h)
+LIBQUAD_CHECK_MATH_H_SIGNGAM
# If available, sqrtl and cbrtl speed up the calculation -
# but they are not required
diff --git a/libquadmath/math/lgammaq.c b/libquadmath/math/lgammaq.c
index 485939a..eef62db 100644
--- a/libquadmath/math/lgammaq.c
+++ b/libquadmath/math/lgammaq.c
@@ -69,7 +69,10 @@
Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA */
#include "quadmath-imp.h"
-#include /* For extern int signgam. */
+
+#ifdef HAVE_MATH_H_SIGNGAM
+#include /* For POSIX's extern int signgam. */
+#endif
static const __float128 PIQ = 3.1415926535897932384626433832795028841972E0Q;
static const __float128 MAXLGM = 1.0485738685148938358098967157129705071571E4928Q;
@@ -759,6 +762,9 @@ lgammaq (__float128 x)
{
__float128 p, q, w, z, nx;
int i, nn;
+#ifndef HAVE_MATH_H_SIGNGAM
+ int signgam;
+#endif
signgam = 1;
diff --git a/libquadmath/config.h.in b/libquadmath/config.h.in
index ea3f10c..9d18cc3 100644
--- a/libquadmath/config.h.in
+++ b/libquadmath/config.h.in
@@ -45,6 +45,9 @@
/* Define to 1 if you have the header file. */
#undef HAVE_LOCALE_H
+/* Define to 1 if the math.h includes POSIX's signgam. */
+#undef HAVE_MATH_H_SIGNGAM
+
/* Define to 1 if you have the header file. */
#undef HAVE_MEMORY_H
diff --git a/libquadmath/configure b/libquadmath/configure
index 1677671..0ea6e07 100755
--- a/libquadmath/configure
+++ b/libquadmath/configure
@@ -11947,6 +11947,43 @@ fi
done
+ { $as_echo "$as_me:${as_lineno-$LINENO}: checking whether the math.h includes POSIX's signgam" >&5
+$as_echo_n "checking whether the math.h includes POSIX's signgam... " >&6; }
+if test "${libgfor_cv_have_math_h_signgam+set}" = set; then :
+ $as_echo_n "(cached) " >&6
+else
+
+ save_CFLAGS="$CFLAGS"
+ CFLAGS="$CFLAGS -Werror"
+ cat confdefs.h - <<_ACEOF >conftest.$ac_ext
+/* end confdefs.h. */
+
+#include
+void foo(void) { signgam = 1; }
+int
+main ()
+{
+
+ ;
+ return 0;
+}
+_ACEOF
+if ac_fn_c_try_compile "$LINENO"; then :
+ libgfor_cv_have_math_h_signgam=yes
+else
+ libgfor_cv_have_math_h_signgam=no
+fi
+rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
+ CFLAGS="$save_CFLAGS"
+fi
+{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $libgfor_cv_have_math_h_signgam" >&5
+$as_echo "$libgfor_cv_have_math_h_signgam" >&6; }
+ if test $libgfor_cv_have_math_h_signgam = yes; then
+
+$as_echo "#define HAVE_MATH_H_SIGNGAM 1" >>confdefs.h
+
+ fi
+
# If available, sqrtl and cbrtl speed up the calculation -
# but they are not required
if test x$gcc_no_link != xyes; then
[aarch64-4.7][committed] Move misplaced ChangeLog entries to ChangeLog.aarch64
> On the ARM/aarch64-4.7-branch the ChangeLog entry should be in > ChangeLog.aarch64 rather than ChangeLog. Please move the entry. Hi Marcus, Sorry about that. I've committed this fix moving all the ChangeLog entries I added in the past two days to their correct place as revision 193696. Hopefully now everything is OK again. James fixup-changelog.patch Description: Binary data
Re: Reduce complette unrolling & peeling limits
> FAIL: gcc.dg/graphite/interchange-8.c scan-tree-dump-times graphite "will be
> interchanged" 2
> FAIL: gcc.dg/graphite/pr42530.c (internal compiler error)
> FAIL: gcc.dg/graphite/pr42530.c (test for excess errors)
> FAIL: gcc.dg/tree-ssa/cunroll-1.c scan-tree-dump cunrolli "Unrolled loop 1
> completely .duplicated 2 times.."
> FAIL: gcc.dg/tree-ssa/cunroll-1.c scan-tree-dump cunrolli "Last iteration
> exit edge was proved true."
> FAIL: gcc.dg/tree-ssa/cunroll-3.c scan-tree-dump cunrolli "Unrolled loop 1
> completely .duplicated 1 times.."
> FAIL: gcc.dg/tree-ssa/loop-36.c scan-tree-dump-not dce2 "c.array"
> FAIL: gcc.dg/tree-ssa/loop-37.c scan-tree-dump-not optimized "my_array"
> FAIL: gcc.dg/tree-ssa/pr21829.c scan-tree-dump-not optimized "if \\("
> FAIL: libgomp.fortran/reduction2.f90 -O3 -fomit-frame-pointer execution test
> FAIL: libgomp.fortran/reduction2.f90 -O3 -fomit-frame-pointer -funroll-loops
> execution test
> FAIL: libgomp.fortran/reduction2.f90 -O3 -fomit-frame-pointer
> -funroll-all-loops -finline-functions execution test
> FAIL: libgomp.fortran/reduction2.f90 -O3 -g execution test
> FAIL: libgomp.fortran/reduction2.f90 -O3 -fomit-frame-pointer execution test
> FAIL: libgomp.fortran/reduction2.f90 -O3 -fomit-frame-pointer -funroll-loops
> execution test
> FAIL: libgomp.fortran/reduction2.f90 -O3 -fomit-frame-pointer
> -funroll-all-loops -finline-functions execution test
> FAIL: libgomp.fortran/reduction2.f90 -O3 -g execution test
Yep, problem here is the *2/3 heuristic in estimated unroller body size. I am
back to internet access, so I will look into it today or tomorrow.
Honza
>
> for both -m32 and -m64 +
>
> FAIL: gcc.dg/tree-ssa/loadpre6.c scan-tree-dump-times pre "Insertions: 2" 1
>
> with -m32.
>
> Dominique
[PATCH][AARCH64] Fix the name mangling of va_list
Hi,
This patch updates the AArch64 port to mangle __va_list as it is in
namespace std in C++. This is specified in the AArch64 AAPCS64 ABI doc.
OK for the trunk?
Thanks,
Yufeng
gcc/ChangeLog
2012-11-21 Yufeng Zhang
* config/aarch64/aarch64.c (aarch64_mangle_type): New function.
(TARGET_MANGLE_TYPE): Define.
gcc/testsuite/ChangeLog
2012-11-21 Yufeng Zhang
* g++.dg/abi/arm_va_list.C: Also test on aarch64*-*-*.diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index 4437fef..792b086 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -5859,6 +5859,20 @@ aarch64_preferred_simd_mode (enum machine_mode mode)
return word_mode;
}
+/* Implement TARGET_MANGLE_TYPE. */
+
+const char *
+aarch64_mangle_type (const_tree type)
+{
+ /* The AArch64 ABI documents say that "__va_list" has to be
+ managled as if it is in the "std" namespace. */
+ if (lang_hooks.types_compatible_p (CONST_CAST_TREE (type), va_list_type))
+return "St9__va_list";
+
+ /* Use the default mangling. */
+ return NULL;
+}
+
/* Legitimize a memory reference for sync primitive implemented using
LDXR/STXR instructions. We currently force the form of the reference
to be indirect without offset. */
@@ -6923,6 +6937,9 @@ aarch64_c_mode_for_suffix (char suffix)
#undef TARGET_LIBGCC_CMP_RETURN_MODE
#define TARGET_LIBGCC_CMP_RETURN_MODE aarch64_libgcc_cmp_return_mode
+#undef TARGET_MANGLE_TYPE
+#define TARGET_MANGLE_TYPE aarch64_mangle_type
+
#undef TARGET_MEMORY_MOVE_COST
#define TARGET_MEMORY_MOVE_COST aarch64_memory_move_cost
diff --git a/gcc/testsuite/g++.dg/abi/arm_va_list.C b/gcc/testsuite/g++.dg/abi/arm_va_list.C
index 45a426a..d983ee1 100644
--- a/gcc/testsuite/g++.dg/abi/arm_va_list.C
+++ b/gcc/testsuite/g++.dg/abi/arm_va_list.C
@@ -1,9 +1,10 @@
-// { dg-do compile }
+// { dg-do compile { target { aarch64*-*-* arm*-*-* } } }
// { dg-options "-Wno-abi" }
-// { dg-require-effective-target arm_eabi }
+// { dg-require-effective-target arm_eabi { target arm*-*-* } }
// AAPCS \S 7.1.4 requires that va_list be a typedef for "struct
// __va_list". The mangling is as if it were "std::__va_list".
+// So is required for the AArch64 target.
// #include
typedef __builtin_va_list va_list;
libsanitizer/README.gcc update
Hi, This patch updates libsanitizer/README.gcc. Ok? (This is the first time I am trying to commit to gcc trunk) Index: ChangeLog === --- ChangeLog (revision 193693) +++ ChangeLog (working copy) @@ -1,3 +1,6 @@ +2012-11-21 Kostya Serebryany +* README.gcc: Extend the README.gcc with mode details. + 2012-11-20 Konstantin Serebryany * sanitizer_common/sanitizer_linux.cc Index: README.gcc === --- README.gcc (revision 193693) +++ README.gcc (working copy) @@ -1,4 +1,15 @@ -The AddressSanitizer (http://code.google.com/p/address-sanitizer) is -a project developed by Google Inc. The source files of the project -are hosted at http://llvm.org/svn/llvm-project/compiler-rt. These files -are the ones in the asan subdirectory of that project. +AddressSanitizer (http://code.google.com/p/address-sanitizer) and +ThreadSanitizer (http://code.google.com/p/thread-sanitizer/) are +projects initially developed by Google Inc. +Both tools consist of a compiler module and a run-time library. +The sources of the run-time library for these projects are hosted at +http://llvm.org/svn/llvm-project/compiler-rt in the following directories: + include/sanitizer + lib/sanitizer_common + lib/interception + lib/asan + lib/tsan + +Trivial and urgent fixes (portability, build fixes, etc) may go directly to the +GCC tree. All non-trivial changes, functionality improvements, etc should go +through the upstream tree first and then be merged back to the GCC tree.
[patch,avr] Ad PR54222: Move decimal point of signed accum one bit right.
This patch restores the GCC default layout of HA, SA and DA mode.
The original fixed point support tried to be binary compatible with fixed-point
support already provided by some non-FSF ports, but that turned out to result
in wrong code in some situations.
Reason is that these ports adjusted the signed accum fixed-point modes so that
the decimal point is byte aligned which results in smaller code.
This means GCC fixed-point engine is not generic enough to handle all mode
adjustments from -modes.md, thus this patch switches the modes to GCC
default.
There are no new regressions.
However, I could not drive all the tests I usually do, because my framework to
test arithmetics crashes with PR54814 (spill fail).
Ok for trunk?
Johann
libgcc/
Adjust decimal point of signed accum mode to GCC default.
PR target/54222
* config/avr/t-avr (LIB1ASMFUNCS): Add _fractsfsq _fractsfusq,
_divqq_helper.
* config/avr/lib1funcs-fixed.S (__fractqqsf, __fracthqsf)
(__fractsasf, __fractsfha, __fractusqsf, __fractsfsa)
(__mulha3, __mulsa3)
(__divqq3, __divha3, __divsa3): Adjust to new position of
decimal point of signed accum types.
(__mulusa3_round): New function.
(__mulusa3): Use it.
(__divqq_helper): New function.
(__udivuqq3): Use it.
gcc/
Adjust decimal point of signed accum mode to GCC default.
PR target/54222
* config/avr/avr-modes.def (HA, SA, DA): Remove mode adjustments.
(TA): Move decimal point one bit to the right.
* config/avr/avr.c (avr_out_fract): Rewrite.
Index: libgcc/config/avr/lib1funcs-fixed.S
===
--- libgcc/config/avr/lib1funcs-fixed.S (revision 193557)
+++ libgcc/config/avr/lib1funcs-fixed.S (working copy)
@@ -43,8 +43,8 @@ DEFUN __fractqqsf
;; Move in place for SA -> SF conversion
clr r22
mov r23, r24
-lsl r23
;; Sign-extend
+lsl r24
sbc r24, r24
mov r25, r24
XJMP__fractsasf
@@ -67,9 +67,8 @@ ENDF __fractuqqsf
DEFUN __fracthqsf
;; Move in place for SA -> SF conversion
wmov22, 24
-lsl r22
-rol r23
;; Sign-extend
+lsl r25
sbc r24, r24
mov r25, r24
XJMP__fractsasf
@@ -140,11 +139,13 @@ ENDF __fractusqsf
#if defined (L_fractsasf)
DEFUN __fractsasf
XCALL __floatsisf
-;; Divide non-zero results by 2^16 to move the
+;; Divide non-zero results by 2^15 to move the
;; decimal point into place
-cpser25, __zero_reg__
-subir25, exp_hi (16)
-ret
+tst r25
+breq0f
+subir24, exp_lo (15)
+sbcir25, exp_hi (15)
+0: ret
ENDF __fractsasf
#endif /* L_fractsasf */
@@ -186,8 +187,9 @@ ENDF __fractsfuqq
#if defined (L_fractsfha)
DEFUN __fractsfha
-;; Multiply with 2^24 to get a HA result in r25:r24
-subir25, exp_hi (-24)
+;; Multiply with 2^{16+7} to get a HA result in r25:r24
+subir24, exp_lo (-23)
+sbcir25, exp_hi (-23)
XJMP__fixsfsi
ENDF __fractsfha
#endif /* L_fractsfha */
@@ -201,8 +203,7 @@ ENDF __fractsfuha
#endif /* L_fractsfuha */
#if defined (L_fractsfhq)
-DEFUN __fractsfsq
-ENDF __fractsfsq
+FALIAS __fractsfsq
DEFUN __fractsfhq
;; Multiply with 2^{16+15} to get a HQ result in r25:r24
@@ -214,8 +215,7 @@ ENDF __fractsfhq
#endif /* L_fractsfhq */
#if defined (L_fractsfuhq)
-DEFUN __fractsfusq
-ENDF __fractsfusq
+FALIAS __fractsfusq
DEFUN __fractsfuhq
;; Multiply with 2^{16+16} to get a UHQ result in r25:r24
@@ -227,8 +227,9 @@ ENDF __fractsfuhq
#if defined (L_fractsfsa)
DEFUN __fractsfsa
-;; Multiply with 2^16 to get a SA result in r25:r22
-subir25, exp_hi (-16)
+;; Multiply with 2^15 to get a SA result in r25:r22
+subir24, exp_lo (-15)
+sbcir25, exp_hi (-15)
XJMP__fixsfsi
ENDF __fractsfsa
#endif /* L_fractsfsa */
@@ -325,6 +326,9 @@ ENDF __muluhq3
;;; Rounding: -0.5 LSB <= error <= 0.5 LSB
DEFUN __mulha3
XCALL __mulhisi3
+lsl r22
+rol r23
+rol r24
XJMP__muluha3_round
ENDF __mulha3
#endif /* L_mulha3 */
@@ -359,6 +363,9 @@ ENDF __muluha3_round
Fixed Multiplication 16.16 x 16.16
***/
+;; Bits outside the result (below LSB), used in the signed version
+#define GUARD __tmp_reg__
+
#if defined (__AVR_HAVE_MUL__)
;; Multiplier
@@ -381,9 +388,16 @@ ENDF __muluha3_round
#if defined (L_mulusa3)
;;; (C3:C0) = (A3:A0) * (B3:B0)
-;;; Clobbers: __tmp_reg__
-;;; Rounding: -0.5 LSB < error <= 0.5 LSB
-DEFUN __mulusa3
+DEFUN __mulusa3
+set
+;; Fallthru
+ENDF __mulusa3
+
+;;; Round for last digit iff T = 1
+;;; Return guard bits in GUARD (__tmp_reg__).
+;;; Rounding, T = 0: -1.0 LSB < error <= 0 LSB
+;;; Rounding, T = 1: -0.5 LSB
Re: libsanitizer/README.gcc update
On Wed, Nov 21, 2012 at 06:36:32PM +0400, Kostya Serebryany wrote: > This patch updates libsanitizer/README.gcc. Ok? > (This is the first time I am trying to commit to gcc trunk) > > Index: ChangeLog > === > --- ChangeLog (revision 193693) > +++ ChangeLog (working copy) > @@ -1,3 +1,6 @@ > +2012-11-21 Kostya Serebryany > +* README.gcc: Extend the README.gcc with mode details. > + Yes, but please add an empty line before the * README.gcc: line. > --- README.gcc (revision 193693) > +++ README.gcc (working copy) > @@ -1,4 +1,15 @@ > -The AddressSanitizer (http://code.google.com/p/address-sanitizer) is > -a project developed by Google Inc. The source files of the project > -are hosted at http://llvm.org/svn/llvm-project/compiler-rt. These files > -are the ones in the asan subdirectory of that project. > +AddressSanitizer (http://code.google.com/p/address-sanitizer) and > +ThreadSanitizer (http://code.google.com/p/thread-sanitizer/) are > +projects initially developed by Google Inc. > +Both tools consist of a compiler module and a run-time library. > +The sources of the run-time library for these projects are hosted at > +http://llvm.org/svn/llvm-project/compiler-rt in the following directories: > + include/sanitizer > + lib/sanitizer_common > + lib/interception > + lib/asan > + lib/tsan > + > +Trivial and urgent fixes (portability, build fixes, etc) may go directly to > the > +GCC tree. All non-trivial changes, functionality improvements, etc should go Two spaces after . ending a sentence, and etc. instead of etc > +through the upstream tree first and then be merged back to the GCC tree. Thanks. Jakub
[Patch AArch64] Add support for TARGET_BUILTIN_DECL
Hi,
This patch wires up support for TARGET_BUILTIN_DECL in the AArch64
backend.
Is this OK to commit?
Thanks,
James Greenhalgh
---
gcc/
2012-11-21 James Greenhalgh
* config/aarch64/aarch64-builtins.c (aarch64_builtin_decls): New.
(aarch64_init_simd_builtins): Store declaration after builtin
initialisation.
(aarch64_builtin_decl): New.
* config/aarch64/aarch64-protos.h (aarch64_builtin_decl): New.
* config/aarch64/aarch64.c (TARGET_BUILTIN_DECL): Define.
diff --git a/gcc/config/aarch64/aarch64-builtins.c b/gcc/config/aarch64/aarch64-builtins.c
index 0ce57d3..2cdda0f 100644
--- a/gcc/config/aarch64/aarch64-builtins.c
+++ b/gcc/config/aarch64/aarch64-builtins.c
@@ -304,6 +304,8 @@ enum aarch64_builtins
#undef VAR10
#undef VAR11
+static GTY(()) tree aarch64_builtin_decls[AARCH64_BUILTIN_MAX];
+
#define NUM_DREG_TYPES 6
#define NUM_QREG_TYPES 6
@@ -611,6 +613,7 @@ aarch64_init_simd_builtins (void)
};
char namebuf[60];
tree ftype = NULL;
+ tree fndecl = NULL;
int is_load = 0;
int is_store = 0;
@@ -951,8 +954,9 @@ aarch64_init_simd_builtins (void)
snprintf (namebuf, sizeof (namebuf), "__builtin_aarch64_%s%s",
d->name, modenames[d->mode]);
- add_builtin_function (namebuf, ftype, fcode, BUILT_IN_MD, NULL,
- NULL_TREE);
+ fndecl = add_builtin_function (namebuf, ftype, fcode, BUILT_IN_MD,
+ NULL, NULL_TREE);
+ aarch64_builtin_decls[fcode] = fndecl;
}
}
@@ -963,6 +967,15 @@ aarch64_init_builtins (void)
aarch64_init_simd_builtins ();
}
+tree
+aarch64_builtin_decl (unsigned code, bool initialize_p ATTRIBUTE_UNUSED)
+{
+ if (code >= AARCH64_BUILTIN_MAX)
+return error_mark_node;
+
+ return aarch64_builtin_decls[code];
+}
+
typedef enum
{
SIMD_ARG_COPY_TO_REG,
diff --git a/gcc/config/aarch64/aarch64-protos.h b/gcc/config/aarch64/aarch64-protos.h
index b5a32b3..ab84257 100644
--- a/gcc/config/aarch64/aarch64-protos.h
+++ b/gcc/config/aarch64/aarch64-protos.h
@@ -234,5 +234,6 @@ rtx aarch64_expand_builtin (tree exp,
rtx subtarget ATTRIBUTE_UNUSED,
enum machine_mode mode ATTRIBUTE_UNUSED,
int ignore ATTRIBUTE_UNUSED);
+tree aarch64_builtin_decl (unsigned, bool ATTRIBUTE_UNUSED);
#endif /* GCC_AARCH64_PROTOS_H */
diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index d4708bf..6241ba5 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -6736,6 +6736,9 @@ aarch64_c_mode_for_suffix (char suffix)
#undef TARGET_CLASS_MAX_NREGS
#define TARGET_CLASS_MAX_NREGS aarch64_class_max_nregs
+#undef TARGET_BUILTIN_DECL
+#define TARGET_BUILTIN_DECL aarch64_builtin_decl
+
#undef TARGET_EXPAND_BUILTIN
#define TARGET_EXPAND_BUILTIN aarch64_expand_builtin
[committed] Fix profile.c asan failure (PR gcov-profile/55417)
Hi!
I've committed as obvious a patch from Teresa from the PR.
--- gcc/ChangeLog (revision 193696)
+++ gcc/ChangeLog (working copy)
@@ -1,3 +1,9 @@
+2012-11-21 Teresa Johnson
+
+ PR gcov-profile/55417
+ * profile.c (compute_working_sets): Check index first
+ to avoid out-of-bounds array access.
+
2012-11-21 Matthias Klose
* config/aarch64/t-aarch64-linux: Define MULTIARCH_DIRNAME for
@@ -1400,7 +1406,7 @@
* cppdefault.h (default_include): Document multiarch in multilib
member.
* cppdefault.c: [LOCAL_INCLUDE_DIR, STANDARD_INCLUDE_DIR] Add an
-include directory for multiarch directories.
+ include directory for multiarch directories.
* common.opt: New options --print-multiarch and -imultilib.
* config.gcc (tmake_file):
Include i386/t-linux.
--- gcc/profile.c (revision 193696)
+++ gcc/profile.c (working copy)
@@ -288,11 +288,11 @@ compute_working_sets (void)
else
tmp_cum = cum + histo_bucket->cum_value;
- /* Next walk through successive working set entries and fill in
-the statistics for any whose size we have reached by accumulating
-this histogram counter. */
- while (tmp_cum >= working_set_cum_values[ws_ix]
- && ws_ix < NUM_GCOV_WORKING_SETS)
+ /* Next walk through successive working set entries and fill in
+the statistics for any whose size we have reached by accumulating
+this histogram counter. */
+ while (ws_ix < NUM_GCOV_WORKING_SETS
+&& tmp_cum >= working_set_cum_values[ws_ix])
{
gcov_working_sets[ws_ix].num_counters = count;
gcov_working_sets[ws_ix].min_counter
Jakub
Re: libsanitizer/README.gcc update
Done, thanks! --kcc On Wed, Nov 21, 2012 at 6:44 PM, Jakub Jelinek wrote: > On Wed, Nov 21, 2012 at 06:36:32PM +0400, Kostya Serebryany wrote: >> This patch updates libsanitizer/README.gcc. Ok? >> (This is the first time I am trying to commit to gcc trunk) >> >> Index: ChangeLog >> === >> --- ChangeLog (revision 193693) >> +++ ChangeLog (working copy) >> @@ -1,3 +1,6 @@ >> +2012-11-21 Kostya Serebryany >> +* README.gcc: Extend the README.gcc with mode details. >> + > > Yes, but please add an empty line before the * README.gcc: line. > >> --- README.gcc (revision 193693) >> +++ README.gcc (working copy) >> @@ -1,4 +1,15 @@ >> -The AddressSanitizer (http://code.google.com/p/address-sanitizer) is >> -a project developed by Google Inc. The source files of the project >> -are hosted at http://llvm.org/svn/llvm-project/compiler-rt. These files >> -are the ones in the asan subdirectory of that project. >> +AddressSanitizer (http://code.google.com/p/address-sanitizer) and >> +ThreadSanitizer (http://code.google.com/p/thread-sanitizer/) are >> +projects initially developed by Google Inc. >> +Both tools consist of a compiler module and a run-time library. >> +The sources of the run-time library for these projects are hosted at >> +http://llvm.org/svn/llvm-project/compiler-rt in the following directories: >> + include/sanitizer >> + lib/sanitizer_common >> + lib/interception >> + lib/asan >> + lib/tsan >> + >> +Trivial and urgent fixes (portability, build fixes, etc) may go directly to >> the >> +GCC tree. All non-trivial changes, functionality improvements, etc should go > > Two spaces after . ending a sentence, and etc. instead of etc > >> +through the upstream tree first and then be merged back to the GCC tree. > > Thanks. > > Jakub
Re: [patch] [s390] add multiarch definitions for s390-linux-gnu
Matthias Klose wrote: > 2012-11-14 Matthias Klose > > * config/s390/t-linux64: Add multiarch names in MULTILIB_OSDIRNAMES. This is OK. Thanks, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE ulrich.weig...@de.ibm.com
Re: Sparc ASAN
From: Konstantin Serebryany Date: Wed, 21 Nov 2012 17:39:05 +0400 > Today, kPageSize is used in several places where it is expected to be > a compile-time constant. > Even if it seems like replacing it with GetPageSize() is safe, it > would need very significant testing (including performance testing). > Can we just define kPageSize=1UL<<13 under ifdef __sparc__? > > What are the possible page size values for SPARC? 4K, 8K, 64K, 512K It's not a constant and the library really cannot expect it to be one.
Re: Sparc ASAN
On Wed, Nov 21, 2012 at 7:29 PM, David Miller wrote: > From: Konstantin Serebryany > Date: Wed, 21 Nov 2012 17:39:05 +0400 > >> Today, kPageSize is used in several places where it is expected to be >> a compile-time constant. >> Even if it seems like replacing it with GetPageSize() is safe, it >> would need very significant testing (including performance testing). >> Can we just define kPageSize=1UL<<13 under ifdef __sparc__? >> >> What are the possible page size values for SPARC? > > 4K, 8K, 64K, 512K > > It's not a constant and the library really cannot expect it to be one. How often 64K and 512K are used? If we use kPageSize=8K, will this cover most of the use cases? x86 also supports 2M and 1G pages. asan does not support those and no one complained so far. There are various other things that asan library does not support. --kcc
Re: Sparc ASAN
On Wed, 2012-11-21 at 19:39 +0400, Konstantin Serebryany wrote: > On Wed, Nov 21, 2012 at 7:29 PM, David Miller wrote: > > From: Konstantin Serebryany > > Date: Wed, 21 Nov 2012 17:39:05 +0400 > > > >> Today, kPageSize is used in several places where it is expected to be > >> a compile-time constant. > >> Even if it seems like replacing it with GetPageSize() is safe, it > >> would need very significant testing (including performance testing). > >> Can we just define kPageSize=1UL<<13 under ifdef __sparc__? > >> > >> What are the possible page size values for SPARC? > > > > 4K, 8K, 64K, 512K > > > > It's not a constant and the library really cannot expect it to be one. > > How often 64K and 512K are used? > If we use kPageSize=8K, will this cover most of the use cases? To answer this for PowerPC, most current 64-bit distro kernels are compiled with 64K pages, although some older kernel still out there are compiled with 4K pages. For 32-bit kernels, I believe they usually default to 4K pages. As with SPARC, the kernel can be configured to use any number of different page sizes. An 8K page size won't work for us or a SPARC system with page size above 8K, since the minimum mmap size is a page size, so if you attempt to mmap something smaller than a page size (eg, 8K on a 64K page size system), mmap returns an error. If this stays a constant, you have to err on the large side of the potential page sizes. I agree with David, that this has to be runtime generated value. I'll play with his GetPageSize() suggestion and see whether it works for us. Peter
Re: [PATCH, RFC] Enable libsanitizer on powerpc{,64}
On Wed, 2012-11-21 at 13:46 +0400, Evgeniy Stepanov wrote: > Matching FP or SP also sounds good, and perhaps more reliable than > just popping 2 frames from the top of the stack. Agreed. Can you try my second patch that searches for the frame address we want our backtrace to start with and see if that works for ARM? The nice thing about that patch is that we won't have to play any games with forcing or disabling inlining of any of the ASAN functions which me might have to do if we always pop 2 frames off the stack. It would also be tolerant of adding any number of new function calls in between the current two ASAN function at the top of the backtrace. http://gcc.gnu.org/ml/gcc-patches/2012-11/msg01711.html Bah, ignore that first diff of the LAST_UPDATED file. :( Peter
Re: Sparc ASAN
On Wed, Nov 21, 2012 at 8:05 PM, Peter Bergner wrote: > On Wed, 2012-11-21 at 19:39 +0400, Konstantin Serebryany wrote: >> On Wed, Nov 21, 2012 at 7:29 PM, David Miller wrote: >> > From: Konstantin Serebryany >> > Date: Wed, 21 Nov 2012 17:39:05 +0400 >> > >> >> Today, kPageSize is used in several places where it is expected to be >> >> a compile-time constant. >> >> Even if it seems like replacing it with GetPageSize() is safe, it >> >> would need very significant testing (including performance testing). >> >> Can we just define kPageSize=1UL<<13 under ifdef __sparc__? >> >> >> >> What are the possible page size values for SPARC? >> > >> > 4K, 8K, 64K, 512K >> > >> > It's not a constant and the library really cannot expect it to be one. >> >> How often 64K and 512K are used? >> If we use kPageSize=8K, will this cover most of the use cases? > > To answer this for PowerPC, most current 64-bit distro kernels are > compiled with 64K pages, although some older kernel still out there > are compiled with 4K pages. For 32-bit kernels, I believe they > usually default to 4K pages. As with SPARC, the kernel can be > configured to use any number of different page sizes. > > An 8K page size won't work for us or a SPARC system with page size > above 8K, since the minimum mmap size is a page size, so if you > attempt to mmap something smaller than a page size (eg, 8K on a > 64K page size system), mmap returns an error. If this stays a > constant, you have to err on the large side of the potential > page sizes. > > I agree with David, that this has to be runtime generated value. > I'll play with his GetPageSize() suggestion and see whether it > works for us. We'll need to be very careful with such change (e.g. there are other constants defined using kPageSize, there are other places where it is used in performance critical code). And such change should go only via upstream. Maybe we can solve the problem by changing kMmapGranularity? (On Win32, we have 4k pages but larger kMmapGranularity) Changing kMmapGranularity to a non-constant is much less intrusive. --kcc > > Peter > > > >
Re: [PATCH, RFC] Enable libsanitizer on powerpc{,64}
On Wed, Nov 21, 2012 at 8:16 PM, Peter Bergner wrote: > On Wed, 2012-11-21 at 13:46 +0400, Evgeniy Stepanov wrote: >> Matching FP or SP also sounds good, and perhaps more reliable than >> just popping 2 frames from the top of the stack. > > Agreed. Can you try my second patch that searches for the frame > address we want our backtrace to start with and see if that works > for ARM? The nice thing about that patch is that we won't have > to play any games with forcing or disabling inlining of any of > the ASAN functions which me might have to do if we always pop > 2 frames off the stack. It would also be tolerant of adding > any number of new function calls in between the current two > ASAN function at the top of the backtrace. > > http://gcc.gnu.org/ml/gcc-patches/2012-11/msg01711.html > > Bah, ignore that first diff of the LAST_UPDATED file. :( I'd actually prefer to keep the current code that pops two frames (if it works for you) Evgeniy seems to know how to fix the ARM case. --kcc > > Peter > > >
Re: Reduce complette unrolling & peeling limits
Hi,
here is updated patch. It should get the bounds safe enough to not have effect
on codegen of complette unrolling.
There is IMO no way to cut the walk of loop body w/o affecting codegen in
unrolling for size mode. The condition on unroling to happen is
unrolled_size * 2 / 3 < original_size
The patch makes the function walking body to stop after minimal number of
duplicated insns is large (PARAM_MAX_COMPLETELY_PEELED_INSNS). The formula
above allows unlimited duplication when loop body is large enough. This is
more a bug than feature, so I think it is safe to alter it.
Bootstrapped/regtested x86_64-linux, OK?
Honza
* tree-ssa-loop-ivcanon.c (tree_estimate_loop_size): Add UPPER_BOUND
parameter.
(try_unroll_loop_completely) Update.
Index: tree-ssa-loop-ivcanon.c
===
--- tree-ssa-loop-ivcanon.c (revision 193694)
+++ tree-ssa-loop-ivcanon.c (working copy)
@@ -1,5 +1,5 @@
-/* Induction variable canonicalization.
- Copyright (C) 2004, 2005, 2007, 2008, 2010
+/* Induction variable canonicalization and loop peeling.
+ Copyright (C) 2004, 2005, 2007, 2008, 2010, 2012
Free Software Foundation, Inc.
This file is part of GCC.
@@ -207,10 +210,12 @@ constant_after_peeling (tree op, gimple
iteration of the loop.
EDGE_TO_CANCEL (if non-NULL) is an non-exit edge eliminated in the last
iteration
of loop.
- Return results in SIZE, estimate benefits for complete unrolling exiting by
EXIT. */
+ Return results in SIZE, estimate benefits for complete unrolling exiting by
EXIT.
+ Stop estimating after UPPER_BOUND is met. Return true in this case */
-static void
-tree_estimate_loop_size (struct loop *loop, edge exit, edge edge_to_cancel,
struct loop_size *size)
+static bool
+tree_estimate_loop_size (struct loop *loop, edge exit, edge edge_to_cancel,
struct loop_size *size,
+int upper_bound)
{
basic_block *body = get_loop_body (loop);
gimple_stmt_iterator gsi;
@@ -316,6 +321,12 @@ tree_estimate_loop_size (struct loop *lo
if (likely_eliminated || likely_eliminated_last)
size->last_iteration_eliminated_by_peeling += num;
}
+ if ((size->overall * 3 / 2 - size->eliminated_by_peeling
+ - size->last_iteration_eliminated_by_peeling) > upper_bound)
+ {
+ free (body);
+ return true;
+ }
}
}
while (path.length ())
@@ -357,6 +368,7 @@ tree_estimate_loop_size (struct loop *lo
size->last_iteration_eliminated_by_peeling);
free (body);
+ return false;
}
/* Estimate number of insns of completely unrolled loop.
@@ -699,12 +711,22 @@ try_unroll_loop_completely (struct loop
sbitmap wont_exit;
edge e;
unsigned i;
- vec to_remove = vNULL;
+ bool large;
+ vec to_remove = vNULL;
if (ul == UL_SINGLE_ITER)
return false;
- tree_estimate_loop_size (loop, exit, edge_to_cancel, &size);
+ large = tree_estimate_loop_size
+(loop, exit, edge_to_cancel, &size,
+ PARAM_VALUE (PARAM_MAX_COMPLETELY_PEELED_INSNS));
ninsns = size.overall;
+ if (large)
+ {
+ if (dump_file && (dump_flags & TDF_DETAILS))
+ fprintf (dump_file, "Not unrolling loop %d: it is too large.\n",
+loop->num);
+ return false;
+ }
unr_insns = estimated_unrolled_size (&size, n_unroll);
if (dump_file && (dump_flags & TDF_DETAILS))
Re: Reduce complette unrolling & peeling limits
> > Did you notice that gcc.c-torture/compile/pr43186.c regressed? It now again
> > takes a while to compile, so times out on slow machines:
> > ...
>
> On a 2.5Ghz Core2Duo, compiling the test with revision 192891 (2012-10-28)
> takes a small fraction of a second, while with revision 193270 (2012-11-06)
> it takes ~25s.
>
> However this patch makes gfortran.dg/reassoc_4.f to fail
>
> FAIL: gfortran.dg/reassoc_4.f -O scan-tree-dump-times reassoc1 "[0-9]
> * " 22
>
> After it 22 should be replaced with 16 (thresshold
> max-completely-peeled-insns=138
> gives 16, =139 gives 22).
I would propose the following patch instead. The patch anyway changes the
limits on some
targets, so lets change them on all.
Honza
Index: reassoc_4.f
===
--- reassoc_4.f (revision 193698)
+++ reassoc_4.f (working copy)
@@ -1,7 +1,5 @@
! { dg-do compile }
-! { dg-options "-O3 -ffast-math -fdump-tree-reassoc1" }
-! { dg-additional-options "--param max-completely-peel-times=16" { target
spu-*-* } }
-! { dg-additional-options "--param max-completely-peeled-insns=400" { target
s390*-*-* } }
+! { dg-options "-O3 -ffast-math -fdump-tree-reassoc1 --param
max-completely-peel-times=16 --param max-completely-peeled-insns=400" }
subroutine anisonl(w,vo,anisox,s,ii1,jj1,weight)
integer ii1,jj1,i1,iii1,j1,jjj1,k1,l1,m1,n1
real*8 w(3,3),vo(3,3),anisox(3,3,3,3),s(60,60),weight
>
> Dominique
Re: Sparc ASAN
On Wed, Nov 21, 2012 at 8:21 AM, Konstantin Serebryany wrote: > On Wed, Nov 21, 2012 at 8:05 PM, Peter Bergner wrote: >> On Wed, 2012-11-21 at 19:39 +0400, Konstantin Serebryany wrote: >>> On Wed, Nov 21, 2012 at 7:29 PM, David Miller wrote: >>> > From: Konstantin Serebryany >>> > Date: Wed, 21 Nov 2012 17:39:05 +0400 >>> > >>> >> Today, kPageSize is used in several places where it is expected to be >>> >> a compile-time constant. >>> >> Even if it seems like replacing it with GetPageSize() is safe, it >>> >> would need very significant testing (including performance testing). >>> >> Can we just define kPageSize=1UL<<13 under ifdef __sparc__? >>> >> >>> >> What are the possible page size values for SPARC? >>> > >>> > 4K, 8K, 64K, 512K >>> > >>> > It's not a constant and the library really cannot expect it to be one. >>> >>> How often 64K and 512K are used? >>> If we use kPageSize=8K, will this cover most of the use cases? >> >> To answer this for PowerPC, most current 64-bit distro kernels are >> compiled with 64K pages, although some older kernel still out there >> are compiled with 4K pages. For 32-bit kernels, I believe they >> usually default to 4K pages. As with SPARC, the kernel can be >> configured to use any number of different page sizes. >> >> An 8K page size won't work for us or a SPARC system with page size >> above 8K, since the minimum mmap size is a page size, so if you >> attempt to mmap something smaller than a page size (eg, 8K on a >> 64K page size system), mmap returns an error. If this stays a >> constant, you have to err on the large side of the potential >> page sizes. >> >> I agree with David, that this has to be runtime generated value. >> I'll play with his GetPageSize() suggestion and see whether it >> works for us. > > We'll need to be very careful with such change (e.g. there are other > constants defined using kPageSize, > there are other places where it is used in performance critical code). > And such change should go only via upstream. > > Maybe we can solve the problem by changing kMmapGranularity? (On > Win32, we have 4k pages but larger kMmapGranularity) > Changing kMmapGranularity to a non-constant is much less intrusive. Just to follow up, MIPS64 have the following (selectable at kernel compile time) page sizes: 4k, 8k, 16k, 32k and 64k. So is another target where the page size is not constant just like PPC. Some people use 16k page sizes if they are also going to use huge pages too. Some people use 64k pages if they want good performance without huge pages (though the use of 64k pages might be less of a performance gain with the support of transparent huge pages). Thanks, Andrew > > --kcc > >> >> Peter >> >> >> >>
Re: Sparc ASAN
Andrew Pinski writes: > Just to follow up, MIPS64 have the following (selectable at kernel > compile time) page sizes: > 4k, 8k, 16k, 32k and 64k. So is another target where the page size is > not constant just like PPC. As does ia64 (common page sizes are 16k and 64k). Andreas. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different."
Re: Sparc ASAN
From: Konstantin Serebryany Date: Wed, 21 Nov 2012 19:39:52 +0400 > There are various other things that asan library does not support. I'm trying to understand why making the page size variable is such a difficult endeavour.
Re: [PATCH, RFC] PR 55415 : Pessimistic misalignment from eipa_sra pass
Hi,
On Tue, Nov 20, 2012 at 09:24:20AM -0800, Richard Henderson wrote:
> The get_pointer_alignment function can indicate that it does not know
> what the alignment should be, and it always fills in worst-case values
> for that case. We should not use these worst-case values to "optimize"
> the interface of a function.
>
> At minimum I think something like the following would be good. But
> I'm unsure why we would *ever* want to lower the alignment at a function
> interface. It seems to me that we'd simply want the caller to handle
> copying the data to an aligned location?
>
> What was the use case of this code in the first place?
PR 52402, and not surprisingly, that testcase fails on x86_64-linux
with your patch. Furthermore, misalignment due to MEM_REF offset has
to be accounted for whether we know the alignment of base or not.
I was hoping that we could do something along the lines of
build_ref_for_offset tree-sra.c but that would not work for cases like
the one from PR 52890, comment 7 when there is no dereference in the
caller, we tranform:
D.2537 = &this->surfaces;
sPtr.0 = ggTrain::_ZNK7ggTrainIP9mrSurfaceEixEi.isra.0 (D.2537,
1);
into
D.2537 = &this->surfaces;
D.2554 = MEM[(const struct ggTrain *)D.2537];
sPtr.0 = ggTrain::_ZNK7ggTrainIP9mrSurfaceEixEi.isra.0 (D.2537,
1);
At the moment I hope I'll be able to:
1) Bring back tree_non_aligned_mem_p from 4.6 to be used in
access_precludes_ipa_sra_p. This way, any knowingly misaligned
load in the callee should will not be transferred to the caller, if
there is none.
2) In ipa_modify_call_arguments, be optimistic in like in your patch
except for the case when we are looking at a dereference (i.e. we
are turning a BLK dereference into a smaller scalar type one). In
that case, use its alignment like in build_ref_for_offset.
But I'd like to think about this a bit more. I believe we should ask
for Richi's approval when he comes back and recovers anyway. But this
is now my highest priority (finally).
Thanks,
Martin
>
>
>
> r~
> diff --git a/gcc/ipa-prop.c b/gcc/ipa-prop.c
> index 3150bd6..d117389 100644
> --- a/gcc/ipa-prop.c
> +++ b/gcc/ipa-prop.c
> @@ -2956,15 +2956,17 @@ ipa_modify_call_arguments (struct cgraph_edge *cs,
> gimple stmt,
> unsigned int align;
> unsigned HOST_WIDE_INT misalign;
>
> - get_pointer_alignment_1 (base, &align, &misalign);
> - misalign += (tree_to_double_int (off)
> -.sext (TYPE_PRECISION (TREE_TYPE (off))).low
> -* BITS_PER_UNIT);
> - misalign = misalign & (align - 1);
> - if (misalign != 0)
> - align = (misalign & -misalign);
> - if (align < TYPE_ALIGN (type))
> - type = build_aligned_type (type, align);
> + if (get_pointer_alignment_1 (base, &align, &misalign))
> + {
> + misalign += (tree_to_double_int (off)
> +.sext (TYPE_PRECISION (TREE_TYPE (off))).low
> +* BITS_PER_UNIT);
> + misalign = misalign & (align - 1);
> + if (misalign != 0)
> + align = (misalign & -misalign);
> + if (align < TYPE_ALIGN (type))
> + type = build_aligned_type (type, align);
> + }
> expr = fold_build2_loc (loc, MEM_REF, type, base, off);
> }
> else
Re: Sparc ASAN
On Wed, Nov 21, 2012 at 8:40 PM, David Miller wrote: > From: Konstantin Serebryany > Date: Wed, 21 Nov 2012 19:39:52 +0400 > >> There are various other things that asan library does not support. > > I'm trying to understand why making the page size variable > is such a difficult endeavour. Maybe it's not *that* difficult. Looking at it carefully, the major problem I can see is that some other constants are defined based on this one. Give me a few days to resolve it... http://code.google.com/p/address-sanitizer/issues/detail?id=128
Re: Sparc ASAN
On 11/21/12 16:27, Andrew Pinski wrote: On Wed, Nov 21, 2012 at 8:21 AM, Konstantin Serebryany wrote: On Wed, Nov 21, 2012 at 8:05 PM, Peter Bergner wrote: On Wed, 2012-11-21 at 19:39 +0400, Konstantin Serebryany wrote: On Wed, Nov 21, 2012 at 7:29 PM, David Miller wrote: From: Konstantin Serebryany Date: Wed, 21 Nov 2012 17:39:05 +0400 Today, kPageSize is used in several places where it is expected to be a compile-time constant. Even if it seems like replacing it with GetPageSize() is safe, it would need very significant testing (including performance testing). Can we just define kPageSize=1UL<<13 under ifdef __sparc__? What are the possible page size values for SPARC? 4K, 8K, 64K, 512K It's not a constant and the library really cannot expect it to be one. How often 64K and 512K are used? If we use kPageSize=8K, will this cover most of the use cases? To answer this for PowerPC, most current 64-bit distro kernels are compiled with 64K pages, although some older kernel still out there are compiled with 4K pages. For 32-bit kernels, I believe they usually default to 4K pages. As with SPARC, the kernel can be configured to use any number of different page sizes. An 8K page size won't work for us or a SPARC system with page size above 8K, since the minimum mmap size is a page size, so if you attempt to mmap something smaller than a page size (eg, 8K on a 64K page size system), mmap returns an error. If this stays a constant, you have to err on the large side of the potential page sizes. I agree with David, that this has to be runtime generated value. I'll play with his GetPageSize() suggestion and see whether it works for us. We'll need to be very careful with such change (e.g. there are other constants defined using kPageSize, there are other places where it is used in performance critical code). And such change should go only via upstream. Maybe we can solve the problem by changing kMmapGranularity? (On Win32, we have 4k pages but larger kMmapGranularity) Changing kMmapGranularity to a non-constant is much less intrusive. Just to follow up, MIPS64 have the following (selectable at kernel compile time) page sizes: 4k, 8k, 16k, 32k and 64k. And ... AArch allows for 4k and 64k page sizes, AArch64 currently supports both 4k and 64k page sizes in the Linux kernel, AArch32 (ARM GNU/Linux) currently supports only 4K. I also notice that you've hard coded cache line size. Why is that necessary and what's it used for ? While trying to add support for ARM (AArch32 GNU / Linux) implementation for GCC after-hours but still keep seeing failures on my chromebook running an ubuntu fs on a ChrOS kernel, because the shadow memory apparently overlaps with normal memory. Has anyone else hit this while porting ? Turning off address space randomization doesn't seem to help either. regards, Ramana
Re: [PATCH, RFC] Enable libsanitizer on powerpc{,64}
On Wed, 2012-11-21 at 20:22 +0400, Konstantin Serebryany wrote:
> On Wed, Nov 21, 2012 at 8:16 PM, Peter Bergner wrote:
> > On Wed, 2012-11-21 at 13:46 +0400, Evgeniy Stepanov wrote:
> >> Matching FP or SP also sounds good, and perhaps more reliable than
> >> just popping 2 frames from the top of the stack.
> >
> > Agreed. Can you try my second patch that searches for the frame
> > address we want our backtrace to start with and see if that works
> > for ARM? The nice thing about that patch is that we won't have
> > to play any games with forcing or disabling inlining of any of
> > the ASAN functions which me might have to do if we always pop
> > 2 frames off the stack. It would also be tolerant of adding
> > any number of new function calls in between the current two
> > ASAN function at the top of the backtrace.
> >
> > http://gcc.gnu.org/ml/gcc-patches/2012-11/msg01711.html
> >
> > Bah, ignore that first diff of the LAST_UPDATED file. :(
>
> I'd actually prefer to keep the current code that pops two frames
> (if it works for you)
Well it does work for me, since I wrote it. :) That being said, the
change where I always pop two frames off of the backtrace was more of
a proof of concept that if I can remove those ASAN functions from the
backtrace, do we pass the test case in the testsuite. It did, but I
have to admit that code is extremely fragile. It is dependent not
only on the inlining heuristics of one compiler, but of two compilers!
Not to mention people building debugable compilers with -O0 -fno-inline,
etc. etc. We'd also have to make sure no one in the future adds any
ASAN function calls in between the report function and the GetBackTrace
calls. It just seems like there are so many things that could go wrong,
that something is bound to.
> Evgeniy seems to know how to fix the ARM case.
His fix was to do:
void StackTrace::PopStackFrames(uptr count) {
- CHECK(size > count);
+ CHECK(size >= count);
size -= count;
for (uptr i = 0; i < size; i++) {
trace[i] = trace[i + count];
Basically, that is allowing for us to pop off all of the frames from
the backtrace leaving an empty backtrace. That can't be helpful in
tracking down the address violation, can it? With my patch above,
either we find the frame we want to start our backtrace with, or
it returns the entire backtrace, ASAN functions and all. Isn't that
better from a diagnostic point of view?
That being said, I'd still like to hear from Evgeniy whether my
patch above helps ARM or not.
Peter
Re: Sparc ASAN
On Wed, Nov 21, 2012 at 9:13 PM, Ramana Radhakrishnan wrote: > On 11/21/12 16:27, Andrew Pinski wrote: >> >> On Wed, Nov 21, 2012 at 8:21 AM, Konstantin Serebryany >> wrote: >>> >>> On Wed, Nov 21, 2012 at 8:05 PM, Peter Bergner >>> wrote: On Wed, 2012-11-21 at 19:39 +0400, Konstantin Serebryany wrote: > > On Wed, Nov 21, 2012 at 7:29 PM, David Miller > wrote: >> >> From: Konstantin Serebryany >> Date: Wed, 21 Nov 2012 17:39:05 +0400 >> >>> Today, kPageSize is used in several places where it is expected to be >>> a compile-time constant. >>> Even if it seems like replacing it with GetPageSize() is safe, it >>> would need very significant testing (including performance testing). >>> Can we just define kPageSize=1UL<<13 under ifdef __sparc__? >>> >>> What are the possible page size values for SPARC? >> >> >> 4K, 8K, 64K, 512K >> >> It's not a constant and the library really cannot expect it to be one. > > > How often 64K and 512K are used? > If we use kPageSize=8K, will this cover most of the use cases? To answer this for PowerPC, most current 64-bit distro kernels are compiled with 64K pages, although some older kernel still out there are compiled with 4K pages. For 32-bit kernels, I believe they usually default to 4K pages. As with SPARC, the kernel can be configured to use any number of different page sizes. An 8K page size won't work for us or a SPARC system with page size above 8K, since the minimum mmap size is a page size, so if you attempt to mmap something smaller than a page size (eg, 8K on a 64K page size system), mmap returns an error. If this stays a constant, you have to err on the large side of the potential page sizes. I agree with David, that this has to be runtime generated value. I'll play with his GetPageSize() suggestion and see whether it works for us. >>> >>> >>> We'll need to be very careful with such change (e.g. there are other >>> constants defined using kPageSize, >>> there are other places where it is used in performance critical code). >>> And such change should go only via upstream. >>> >>> Maybe we can solve the problem by changing kMmapGranularity? (On >>> Win32, we have 4k pages but larger kMmapGranularity) >>> Changing kMmapGranularity to a non-constant is much less intrusive. >> >> >> >> Just to follow up, MIPS64 have the following (selectable at kernel >> compile time) page sizes: >> 4k, 8k, 16k, 32k and 64k. > > > > And ... AArch allows for 4k and 64k page sizes, AArch64 currently supports > both 4k and 64k page sizes in the Linux kernel, AArch32 (ARM GNU/Linux) > currently supports only 4K. > > I also notice that you've hard coded cache line size. Why is that necessary > and what's it used for ? They are used to do padding in structures to avoid false sharing. > > While trying to add support for ARM (AArch32 GNU / Linux) implementation for > GCC after-hours but still keep seeing failures on my chromebook running an > ubuntu fs on a ChrOS kernel, because the shadow memory apparently overlaps > with normal memory. Has anyone else hit this while porting ? I've heard someone complain about this recently. glider? Running asan on *huge* binaries in 32-bit address space is a challenge indeed. My suggestion was to link with -pie. --kcc > Turning off > address space randomization doesn't seem to help either. > > regards, > Ramana > >
Re: Sparc ASAN
On Tue, 2012-11-20 at 23:19 -0500, David Miller wrote:
> The address violation detection seems to work properly and the only
> thing that seems to be left are some backtrace/unwind issues. These
> are perhaps similar to the unwind bits that the powerpc folks ran
> into.
David, does the following patch (will have some fuzz since I removed
one ppc only hunk from the patch) fix your backtrace issue? I'll note
you'll have to add "|| defined(__sparc__)" to the #if ... or as
it's probably going to turn out, just replace the whole thing
with a "#if !defined(__i386__) && !defined(__x86_64__)".
Peter
Index: libsanitizer/asan/asan_linux.cc
===
--- libsanitizer/asan/asan_linux.cc (revision 193678)
+++ libsanitizer/asan/asan_linux.cc (working copy)
@@ -134,11 +141,27 @@
#endif
}
+uptr Unwind_GetBP(struct _Unwind_Context *ctx) {
+ return _Unwind_GetCFA(ctx);
+}
+
+struct Unwind_Trace_Info {
+ StackTrace *stack;
+ uptr bp;
+};
+
_Unwind_Reason_Code Unwind_Trace(struct _Unwind_Context *ctx,
void *param) {
- StackTrace *b = (StackTrace*)param;
+ Unwind_Trace_Info *p = (Unwind_Trace_Info *)param;
+ StackTrace *b = p->stack;
+ uptr pc = Unwind_GetIP(ctx);
+ if (Unwind_GetBP(ctx) == p->bp) {
+// We just encountered the frame pointer we want to start
+// our backtrace with, so empty the backtrace before adding
+// this frame to the backtrace.
+b->size = 0;
+ }
CHECK(b->size < b->max_size);
- uptr pc = Unwind_GetIP(ctx);
b->trace[b->size++] = pc;
if (b->size == b->max_size) return UNWIND_STOP;
return UNWIND_CONTINUE;
@@ -149,8 +172,11 @@
stack->trace[0] = pc;
if ((max_s) > 1) {
stack->max_size = max_s;
-#ifdef __arm__
-_Unwind_Backtrace(Unwind_Trace, stack);
+#if defined(__arm__) || defined(__powerpc__) || defined(__powerpc64__)
+Unwind_Trace_Info param;
+param.stack = stack;
+param.bp = bp;
+_Unwind_Backtrace(Unwind_Trace, ¶m);
#else
if (!asan_inited) return;
if (AsanThread *t = asanThreadRegistry().GetCurrent())
Re: [Patch, Fortran] PR 55352: [4.7/4.8 Regression] Erroneous gfortran warning of unused module variable when variable is only used in namelist
Dear Janus, Thanks for the patch - it's OK for trunk and 4.7. Cheers Paul On 19 November 2012 21:39, Janus Weil wrote: > Hi all, > > here is another contribution in trying to reduce the still too large > number of regressions in the Fortran front end (which used to be > basically zero for some time in the past). > > The attached patch is rather straightforward and fixes a bogus > unused-variable warning. I would be grateful for any comments, in > absence of which I will commit the patch to trunk by the end of this > week. > > It was regtested on x86_64-unknown-linux-gnu. Ok for trunk and 4.7? > > Cheers, > Janus > > > > 2012-11-19 Janus Weil > > PR fortran/55352 > * trans-decl.c (generate_local_decl): Don't warn for explicitly imported > but unused module variables which are in a namelist or common block. > > 2012-11-19 Janus Weil > > PR fortran/55352 > * gfortran.dg/namelist_76.f90: New. -- The knack of flying is learning how to throw yourself at the ground and miss. --Hitchhikers Guide to the Galaxy
Re: [patch] [m68k] add multiarch definitions for m68k-linux-gnu
Matthias Klose writes: > 2012-11-14 Matthias Klose > > * config/m68k/t-linux: Define MULTIARCH_DIRNAME for classic m68k. Ok, thanks. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: [PATCH] Change -faddress-sanitizer to -fsanitize=address
Thanks! Done. Committed revision 193702. Regards, Wei. On Tue, Nov 20, 2012 at 11:57 PM, Jakub Jelinek wrote: > On Tue, Nov 20, 2012 at 11:14:27PM -0800, Wei Mi wrote: >> 2012-11-21 Wei Mi >> >> * common.opt: Change faddress-sanitizer to fsanitize=address. >> * toplev.c (process_options): Likewise. >> * gcc.c (LINK_COMMAND_SPEC): Likewise. >> * testsuite/lib/asan-dg.exp >> (check_effective_target_faddress_sanitizer): Likewise. >> (asan_init): Likewise. > > Ok, thanks. > >> * doc/invoke.texi (-fsanitize=[address|thread]): Document. > > Just change [address|thread] to address in the ChangeLog entry. > > Jakub
Re: Sparc ASAN
From: Peter Bergner Date: Wed, 21 Nov 2012 11:28:51 -0600 > On Tue, 2012-11-20 at 23:19 -0500, David Miller wrote: >> The address violation detection seems to work properly and the only >> thing that seems to be left are some backtrace/unwind issues. These >> are perhaps similar to the unwind bits that the powerpc folks ran >> into. > > David, does the following patch (will have some fuzz since I removed > one ppc only hunk from the patch) fix your backtrace issue? I'll note > you'll have to add "|| defined(__sparc__)" to the #if ... or as > it's probably going to turn out, just replace the whole thing > with a "#if !defined(__i386__) && !defined(__x86_64__)". This patch works well but I have some unrelated sanitizer sparc issues to resolve before the testcase will pass properly. Feel free to submit this with the __sparc__ cpp test added, or the !x86 variant, at your discretion.
[libsanitizer] a script to help merging asan from upstream
Hi, A dummy script to help merging asan from upstream. Not 100% complete, but should be enough to complete the current merge. You suggestions on how to improve it (or how to do w/o it) are welcome, but I really wish to do the first merge tomorrow to unblock other folks. Thanks, --kcc merge.patch Description: Binary data
[ARM, PATCH] TARGET_LDRD reject Thumb1 targets
This patch adjusts the definition of TARGET_LDRD to false on Thumb1 targets, as suggested here: http://gcc.gnu.org/ml/gcc-patches/2012-10/msg02048.html No regression on qemu for arm none-eabi with arch=armv5t/armv7-a mode=thumb/arm. Ok for trunk? Thanks, Greta ChangeLog 2012-11-21 Greta Yorsh * config/arm/arm.h (TARGET_LDRD): Reject Thumb1 targets.diff --git a/gcc/config/arm/arm.h b/gcc/config/arm/arm.h index 5f34f2a..1adcf9f 100644 --- a/gcc/config/arm/arm.h +++ b/gcc/config/arm/arm.h @@ -252,7 +252,6 @@ extern void (*arm_lang_output_object_attributes_hook)(void); #define TARGET_BACKTRACE (leaf_function_p () \ ? TARGET_TPCS_LEAF_FRAME \ : TARGET_TPCS_FRAME) -#define TARGET_LDRD(arm_arch5e && ARM_DOUBLEWORD_ALIGN) #define TARGET_AAPCS_BASED \ (arm_abi != ARM_ABI_APCS && arm_abi != ARM_ABI_ATPCS) @@ -269,6 +268,9 @@ extern void (*arm_lang_output_object_attributes_hook)(void); /* Thumb-1 only. */ #define TARGET_THUMB1_ONLY (TARGET_THUMB1 && !arm_arch_notm) +#define TARGET_LDRD(arm_arch5e && ARM_DOUBLEWORD_ALIGN \ + && !TARGET_THUMB1) + /* The following two macros concern the ability to execute coprocessor instructions for VFPv3 or NEON. TARGET_VFP3/TARGET_VFPD32 are currently only ever tested when we know we are generating for VFP hardware; we need
What CPP macro should -fsanitize=address define?
Hi, I am working on ASAN bootstrap support. I need a CPP macro for -fsanitize=address. I am learning toward __SANITIZE_ADDRESS__. Any comments? Thanks. -- H.J.
[patch, pch] Fix pch failure on mips-mti-linux-gnu
While working on PR 55399 (pch broken on mips-mti-linux-gnu) I traced
through the execution of test gcc.dg/pch/common-1.c and in comparing r192714
and r192715 I found that in the earlier version the compiler gets to
pch_open_file (with common-1.h) and does this check:
if (pfile->all_files
&& pfile->all_files->next_file) {
it finds that pfile->all_files->next_file is NULL and continues on in the
routine.
In the new version there is:
if (pfile->all_files
&& pfile->all_files->next_file
&& !pfile->all_files->next_file->implicit_preinclude) {
and here it finds that pfile->all_files->next_file is true but
pfile->all_files->next_file->implicit_preinclude is false so it exits
the routine and this is why the code compiler doesn't find the
preprocessed header file.
Looking at pfile I see that pfile->all_files is pointing at stdc-predef.h
where implicit_preinclude is true but pfile->all_files->next_file is pointing
at common-1.c where implicit_preinclude is false.
My best guess as to why this is happening for me and not other people is that
the order of common-1.c and stdc-predef.h in this linked list is dependent on
how things are put into pfile->file_hash and for some reason stdc-predef.h
shows up before common-1.c for me but not for other people, where they get
common-1.c and then stdc-predef.h.
This patch checks for implicit_preinclude on both pfile->all_files and
pfile->all_files->next_file and it fixes the problem for me. I tested
it on mips-mti-linux-gnu and had no regressions.
OK to checkin?
Steve Ellcey
sell...@mips.com
2012-11-21 Steve Ellcey
PR pch/55399
* files.c (pch_open_file): Fix check for implicit_preinclude.
diff --git a/libcpp/files.c b/libcpp/files.c
index a8288dc..9f84d8c 100644
--- a/libcpp/files.c
+++ b/libcpp/files.c
@@ -295,7 +295,8 @@ pch_open_file (cpp_reader *pfile, _cpp_file *file, bool
*invalid_pch)
file or the command-line it is not a valid use of PCH. */
if (pfile->all_files
&& pfile->all_files->next_file
- && !pfile->all_files->next_file->implicit_preinclude)
+ && !(pfile->all_files->implicit_preinclude
+ || pfile->all_files->next_file->implicit_preinclude))
return false;
flen = strlen (path);
[PATCH][Revisedx4] Enable libsanitizer on darwin
The attached patch imports the missing mach_override/mach_override.h and
mach_override/mach_override.c files from llvm.org's compiler-rt at
r168032 | glider | 2012-11-15 03:32:16 -0500 (Thu, 15 Nov 2012) | 3 lines
[ASan] Add the "lea $imm(%rip),%rax" instruction to mach_override.c
The need for this has been reported by Jack Howarth (howa...@bromo.med.uc.edu)
who's porting ASan-Darwin to GCC
The patch adds darwin to the supported target list in configure.tgt and
defines USING_MACH_OVERRIDE for darwin in configure.ac. The definition of
USING_MACH_OVERRIDE is used in Makefile.am as the test for appending
mach_override/mach_override.c to libinterception_la_SOURCES.
LINK_COMMAND_SPEC_A
in gcc/config/darwin.h is modified to add an entry to handle fsanitize=address
so that the required linkages are used for libasan. The static linkage of
libasan.a
in LINK_COMMAND_SPEC_A is handle separately for -static-libstdc++ (which
requires
libstdc++.a) and the -static, -static-gcc and -static-gfortran cases. Tested on
x86_64-apple-darwin12 for both -m32 and -m64 with the both use-after-free.c
testcase
and...
make -k check RUNTESTFLAGS="asan.exp --target_board=unix'{-m32,-m64}'"
without regressions.
Jack
ps This patch is identical to the prior version (asan_v7.diff) except the
changes to
gcc/config/darwin.h are adjusted for the renaming of the -faddress-sanitizer
option to
-fsanitize=address.
gcc/
2012-11-21 Jack Howarth
* config/darwin.h (LINK_COMMAND_SPEC_A): Deal with -fsanitize=address.
libsanitizer/
2012-11-21 Dodji Seketeli
Jack Howarth
* interception/mach_override/mach_override.c: Migrate from llvm.
* interception/mach_override/mach_override.h: Likewise.
* configure.tgt: Add darwin to supported targets.
* configure.ac: Define USING_MACH_OVERRIDE when on darwin.
* interception/Makefile.am: Compile mach_override.c when
USING_MACH_OVERRIDE defined.
* configure: Regenerated.
* interception/Makefile.in: Likewise.
--- /dev/null 2012-11-16 10:24:58.0 -0500
+++ libsanitizer/interception/mach_override/mach_override.c 2012-11-16
10:26:42.0 -0500
@@ -0,0 +1,970 @@
+/***
+ mach_override.c
+ Copyright (c) 2003-2009 Jonathan 'Wolf' Rentzsch:
+ Some rights reserved:
+
+
***/
+#ifdef __APPLE__
+
+#include "mach_override.h"
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+//#define DEBUG_DISASM 1
+#undef DEBUG_DISASM
+
+/**
+*
+* Constants
+*
+**/
+#pragma mark -
+#pragma mark (Constants)
+
+#if defined(__ppc__) || defined(__POWERPC__)
+
+static
+long kIslandTemplate[] = {
+ 0x9001FFFC, // stw r0,-4(SP)
+ 0x3C00DEAD, // lis r0,0xDEAD
+ 0x6000BEEF, // ori r0,r0,0xBEEF
+ 0x7C0903A6, // mtctr r0
+ 0x8001FFFC, // lwz r0,-4(SP)
+ 0x6000, // nop ; optionally replaced
+ 0x4E800420 // bctr
+};
+
+#define kAddressHi 3
+#define kAddressLo 5
+#define kInstructionHi 10
+#define kInstructionLo 11
+
+#elif defined(__i386__)
+
+#define kOriginalInstructionsSize 16
+
+static
+unsigned char kIslandTemplate[] = {
+ // kOriginalInstructionsSize nop instructions so that we
+ // should have enough space to host original instructions
+ 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90,
+ 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90,
+ // Now the real jump instruction
+ 0xE9, 0xEF, 0xBE, 0xAD, 0xDE
+};
+
+#define kInstructions 0
+#define kJumpAddresskInstructions + kOriginalInstructionsSize + 1
+#elif defined(__x86_64__)
+
+#define kOriginalInstructionsSize 32
+
+#define kJumpAddresskOriginalInstructionsSize + 6
+
+static
+unsigned char kIslandTemplate[] = {
+ // kOriginalInstructionsSize nop instructions so that we
+ // should have enough space to host original instructions
+ 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90,
+ 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90,
+ 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90,
+ 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90,
+ // Now the real jump instruction
+ 0xFF, 0x25, 0x00, 0x00, 0x00, 0x00,
+0x00, 0x00, 0x00, 0x00,
+0x00, 0x00, 0x00, 0x00
+};
+
+#endif
+
+#definekAllocateHigh 1
+#definekAllocateNormal 0
+
+/**
+*
+* Data Types
+*
+**/
+#pragma mark -
+#pragma mark (Da
Re: What CPP macro should -fsanitize=address define?
On Wed, Nov 21, 2012 at 10:42 PM, H.J. Lu wrote: > Hi, > > I am working on ASAN bootstrap support. I need a CPP macro > for -fsanitize=address. I am learning toward __SANITIZE_ADDRESS__. That would be a reasonable option (some background: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55397) --kcc > Any comments? > > Thanks. > > -- > H.J.
Re: [libsanitizer] a script to help merging asan from upstream
Suggestions: 1) make sure current local dir is libsanitizer -- exit if it is not 2) clean up the upstream directory after the merge is done. David On Wed, Nov 21, 2012 at 10:25 AM, Kostya Serebryany wrote: > Hi, > > A dummy script to help merging asan from upstream. > Not 100% complete, but should be enough to complete the current merge. > > You suggestions on how to improve it (or how to do w/o it) are welcome, > but I really wish to do the first merge tomorrow to unblock other folks. > > Thanks, > --kcc
Re: ping - Re: [patch] [ia64] add multiarch definitions for ia64-linux-gnu
On Wed, 2012-11-21 at 03:44 +0100, Matthias Klose wrote: > ping, re-sending to the port maintainers > > Am 15.11.2012 11:57, schrieb Matthias Klose: > > Am 15.11.2012 09:51, schrieb Alexander Monakov: > >> The attached patch includes t-glibc instead of t-linux in config.gcc. > > > > thanks for the pointer. updated patch attached below. OK for ia64. Steve Ellcey sell...@mips.com
Re: [libsanitizer] a script to help merging asan from upstream
Done both.
+fatal() {
+ echo "$1"
+ exit 1;
+}
+
+pwd | grep 'libsanitizer$' || \
+ fatal "Run this script from libsanitizer dir"
+rm -rf upstream
On Wed, Nov 21, 2012 at 10:49 PM, Xinliang David Li wrote:
> Suggestions:
>
> 1) make sure current local dir is libsanitizer -- exit if it is not
> 2) clean up the upstream directory after the merge is done.
>
> David
>
>
> On Wed, Nov 21, 2012 at 10:25 AM, Kostya Serebryany wrote:
>> Hi,
>>
>> A dummy script to help merging asan from upstream.
>> Not 100% complete, but should be enough to complete the current merge.
>>
>> You suggestions on how to improve it (or how to do w/o it) are welcome,
>> but I really wish to do the first merge tomorrow to unblock other folks.
>>
>> Thanks,
>> --kcc
merge.patch
Description: Binary data
Re: [libsanitizer] a script to help merging asan from upstream
How about also documenting this in README.gcc?
David
On Wed, Nov 21, 2012 at 10:56 AM, Kostya Serebryany wrote:
> Done both.
>
>
> +fatal() {
> + echo "$1"
> + exit 1;
> +}
> +
> +pwd | grep 'libsanitizer$' || \
> + fatal "Run this script from libsanitizer dir"
>
>
> +rm -rf upstream
>
>
>
>
>
> On Wed, Nov 21, 2012 at 10:49 PM, Xinliang David Li
> wrote:
>> Suggestions:
>>
>> 1) make sure current local dir is libsanitizer -- exit if it is not
>> 2) clean up the upstream directory after the merge is done.
>>
>> David
>>
>>
>> On Wed, Nov 21, 2012 at 10:25 AM, Kostya Serebryany wrote:
>>> Hi,
>>>
>>> A dummy script to help merging asan from upstream.
>>> Not 100% complete, but should be enough to complete the current merge.
>>>
>>> You suggestions on how to improve it (or how to do w/o it) are welcome,
>>> but I really wish to do the first merge tomorrow to unblock other folks.
>>>
>>> Thanks,
>>> --kcc
Re: Sparc ASAN
While trying to add support for ARM (AArch32 GNU / Linux) implementation for GCC after-hours but still keep seeing failures on my chromebook running an ubuntu fs on a ChrOS kernel, because the shadow memory apparently overlaps with normal memory. Has anyone else hit this while porting ? I've heard someone complain about this recently. glider? Running asan on *huge* binaries in 32-bit address space is a challenge indeed. My suggestion was to link with -pie. No, this was just with one of the tests in the testsuite. So I'm not sure that it's that big to warrant pie. Oh and funnily enough it worked fine from running outside the GCC testsuite harness but fails when running inside it ! I'll try and get more details out later today or tomorrow. regards, Ramana --kcc Turning off address space randomization doesn't seem to help either. regards, Ramana
Re: What CPP macro should -fsanitize=address define?
On Wed, Nov 21, 2012 at 10:47 AM, Konstantin Serebryany wrote: > On Wed, Nov 21, 2012 at 10:42 PM, H.J. Lu wrote: >> Hi, >> >> I am working on ASAN bootstrap support. I need a CPP macro >> for -fsanitize=address. I am learning toward __SANITIZE_ADDRESS__. > > That would be a reasonable option > (some background: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55397) > Here is a patch. OK to install? Thanks. -- H.J. -- 2012-11-21 H.J. Lu PR c/55397 * cppbuiltin.c (define_builtin_macros_for_compilation_flags): Define __SANITIZE_ADDRESS__ for flag_asan. diff --git a/gcc/cppbuiltin.c b/gcc/cppbuiltin.c index 05d82f5..c3ca21a 100644 --- a/gcc/cppbuiltin.c +++ b/gcc/cppbuiltin.c @@ -91,6 +91,9 @@ define_builtin_macros_for_compilation_flags (cpp_reader *pfile) cpp_define_formatted (pfile, "__PIE__=%d", flag_pie); } + if (flag_asan) +cpp_define (pfile, "__SANITIZE_ADDRESS__"); + if (optimize_size) cpp_define (pfile, "__OPTIMIZE_SIZE__"); if (optimize)
[RFA/ARM] Fix PR54974: Thumb literal pools don't handle PC rounding
All, The attached patch fixes PR54974. In Thumb when calculating the PC value for a literal load the value used is the current PC rounded down to the nearest multiple of 4. The ARM backend currently does not take this into account when calculating literal pool placement. The fix is to decrease the pool_range of all insns by 2 when generating Thumb code. There is no need to change neg_pool_range values as rounding down here will reduce the distance of the literal pool. The patch attached to the PR is not sufficient as we don't precisely know the PC when calculating literal pool ranges and so have to be conservative. Whilst going through all the code I found the following, possibly related, issues that I would like some input from the ARM maintainers on (although they have not been touched in this patch): 1) Some Thumb-2 patterns (like thumb2_movhi_insn) have a neg_pool_range of 250 for ldrh, where my reading of the ARMARM says the range is [-4095, 4095] for Thumb-2 (with appropriate rounding). What is the reason for GCC's severe pessimism here? 2) thumb1_zero_extendqisi2 (and other insns) give a Thumb-1 narrow ldrb a pool_range of 32. Surely the pool_range should be 0 (or *) as Thumb-1 doesn't have a ldrb where the base-register can be PC? Tested arm-none-linux-gnueabi cross, and with the testcase attached to the PR. No added testcase in the patch as this code is sensitive to other code generation and so it is not easy to generate a testcase which will reliably test this condition. OK for trunk, 4.7, and 4.6? Thanks, Matt gcc/ChangeLog: 2012-11-21 Matthew Gretton-Dann PR target/54974 * config/arm/arm.md (thumb1_extendhisi2): Reduce Thumb pool_range. (arm_movdi): Likewise. (thumb1_movdi_insn): Likewise. (thumb1_movsi_insn): Likewise. (pic_load_addr_unified): Likewise. (pic_load_addr_32bit): Likewise. (pic_load_addr_thumb1): Likewise. (thumb1_movhf): Likewise. (arm_movsf_soft_insn): Likewise. (thumb1_movsf_soft_insn): Likewise. (movdf_soft_insn): Likewise. (thumb1_movdf_soft_insn): Likewise. * config/arm/neon.md (*neon_mov): Likewise. (*neon_mov): Likwise. * config/arm/thumb2.md: (*thumb2_movsi_insn): Likewise. (*thumb2_movhi_insn): Likewise. (*thumb2_extendqisi_v6): Likewise. (*thumb2_zero_extendqisi_v6): Likewise. (*thumb2_zero_extendqisi2_v6): Likewise. * config/arm/vfp.md: (*thumb2_movsi_vfp): Likewise. (*movdi_vfp): Likewise. (*movdi_vfp_cortexa8): Likewise. (*thumb2_movsf_vfp): Likewise. (*thumb2_movdf_vfp): Likewise. -- Matthew Gretton-Dann Linaro Toolchain Working Group matthew.gretton-d...@linaro.orgdiff --git a/gcc/config/arm/arm.md b/gcc/config/arm/arm.md index 7e92b69..b3822d9 100644 --- a/gcc/config/arm/arm.md +++ b/gcc/config/arm/arm.md @@ -4952,7 +4952,7 @@ (define_insn "thumb1_extendhisi2" (const_int 2) (const_int 4)) (const_int 4)]) (set_attr "type" "alu_shift,load_byte") - (set_attr "pool_range" "*,1020")] + (set_attr "pool_range" "*,1018")] ) ;; This pattern will only be used when ldsh is not available @@ -5359,7 +5359,7 @@ (define_insn "*arm_movdi" (set_attr "type" "*,*,*,load2,store2") (set_attr "arm_pool_range" "*,*,*,1020,*") (set_attr "arm_neg_pool_range" "*,*,*,1004,*") - (set_attr "thumb2_pool_range" "*,*,*,4096,*") + (set_attr "thumb2_pool_range" "*,*,*,4094,*") (set_attr "thumb2_neg_pool_range" "*,*,*,0,*")] ) @@ -5498,7 +5498,7 @@ (define_insn "*thumb1_movdi_insn" [(set_attr "length" "4,4,6,2,2,6,4,4") (set_attr "type" "*,*,*,load2,store2,load2,store2,*") (set_attr "insn" "*,mov,*,*,*,*,*,mov") - (set_attr "pool_range" "*,*,*,*,*,1020,*,*")] + (set_attr "pool_range" "*,*,*,*,*,1018,*,*")] ) (define_expand "movsi" @@ -5668,7 +5668,7 @@ (define_insn "*thumb1_movsi_insn" mov\\t%0, %1" [(set_attr "length" "2,2,4,4,2,2,2,2,2") (set_attr "type" "*,*,*,*,load1,store1,load1,store1,*") - (set_attr "pool_range" "*,*,*,*,*,*,1020,*,*") + (set_attr "pool_range" "*,*,*,*,*,*,1018,*,*") (set_attr "conds" "set,clob,*,*,nocond,nocond,nocond,nocond,nocond")]) (define_split @@ -5776,7 +5776,7 @@ (define_insn_and_split "pic_load_addr_unified" (match_dup 2)] UNSPEC_PIC_BASE))] "operands[3] = TARGET_THUMB ? GEN_INT (4) : GEN_INT (8);" [(set_attr "type" "load1,load1,load1") - (set_attr "pool_range" "4096,4096,1024") + (set_attr "pool_range" "4096,4094,1022") (set_attr "neg_pool_range" "4084,0,0") (set_attr "arch" "a,t2,t1") (set_attr "length" "8,6,4")] @@ -5792,7 +5792,10 @@ (define_insn "pic_load_addr_32bit" "TARGET_32BIT && flag_pic" "ldr%?\\t%0, %1" [(set_attr "type" "load1") - (set_attr "pool_range" "4096") + (set (attr "pool_range") + (
Re: What CPP macro should -fsanitize=address define?
On Wed, Nov 21, 2012 at 11:25:35AM -0800, H.J. Lu wrote: > 2012-11-21 H.J. Lu > > PR c/55397 > * cppbuiltin.c (define_builtin_macros_for_compilation_flags): > Define __SANITIZE_ADDRESS__ for flag_asan. Ok, thanks. > --- a/gcc/cppbuiltin.c > +++ b/gcc/cppbuiltin.c > @@ -91,6 +91,9 @@ define_builtin_macros_for_compilation_flags > (cpp_reader *pfile) >cpp_define_formatted (pfile, "__PIE__=%d", flag_pie); > } > > + if (flag_asan) > +cpp_define (pfile, "__SANITIZE_ADDRESS__"); > + >if (optimize_size) > cpp_define (pfile, "__OPTIMIZE_SIZE__"); >if (optimize) Jakub
Re: What CPP macro should -fsanitize=address define?
On Wed, Nov 21, 2012 at 12:12 PM, Jakub Jelinek wrote:
> On Wed, Nov 21, 2012 at 11:25:35AM -0800, H.J. Lu wrote:
>> 2012-11-21 H.J. Lu
>>
>> PR c/55397
>> * cppbuiltin.c (define_builtin_macros_for_compilation_flags):
>> Define __SANITIZE_ADDRESS__ for flag_asan.
>
> Ok, thanks.
>
>> --- a/gcc/cppbuiltin.c
>> +++ b/gcc/cppbuiltin.c
>> @@ -91,6 +91,9 @@ define_builtin_macros_for_compilation_flags
>> (cpp_reader *pfile)
>>cpp_define_formatted (pfile, "__PIE__=%d", flag_pie);
>> }
>>
>> + if (flag_asan)
>> +cpp_define (pfile, "__SANITIZE_ADDRESS__");
>> +
>>if (optimize_size)
>> cpp_define (pfile, "__OPTIMIZE_SIZE__");
>>if (optimize)
>
> Jakub
Here is a doc patch. OK to install?
Thanks.
--
H.J.
--
2012-11-21 H.J. Lu
* doc/cpp.texi: Document __SANITIZE_ADDRESS__.
diff --git a/gcc/doc/cpp.texi b/gcc/doc/cpp.texi
index c463e7c..682ee9f 100644
--- a/gcc/doc/cpp.texi
+++ b/gcc/doc/cpp.texi
@@ -2352,6 +2352,10 @@ use.
This macro is defined, with value 2, when @option{-fstack-protector-all} is
in use.
+@item __SANITIZE_ADDRESS__
+This macro is defined, with value 1, when @option{-fsanitize=address} is
+in use.
+
@item __TIMESTAMP__
This macro expands to a string constant that describes the date and time
of the last modification of the current source file. The string constant
Re: What CPP macro should -fsanitize=address define?
On Wed, Nov 21, 2012 at 12:21:55PM -0800, H.J. Lu wrote:
> Here is a doc patch. OK to install?
Yes.
> 2012-11-21 H.J. Lu
>
> * doc/cpp.texi: Document __SANITIZE_ADDRESS__.
>
> diff --git a/gcc/doc/cpp.texi b/gcc/doc/cpp.texi
> index c463e7c..682ee9f 100644
> --- a/gcc/doc/cpp.texi
> +++ b/gcc/doc/cpp.texi
> @@ -2352,6 +2352,10 @@ use.
> This macro is defined, with value 2, when @option{-fstack-protector-all} is
> in use.
>
> +@item __SANITIZE_ADDRESS__
> +This macro is defined, with value 1, when @option{-fsanitize=address} is
> +in use.
> +
> @item __TIMESTAMP__
> This macro expands to a string constant that describes the date and time
> of the last modification of the current source file. The string constant
Jakub
Re: Sparc ASAN
From: David Miller Date: Wed, 21 Nov 2012 12:54:17 -0500 (EST) > From: Peter Bergner > Date: Wed, 21 Nov 2012 11:28:51 -0600 > >> On Tue, 2012-11-20 at 23:19 -0500, David Miller wrote: >>> The address violation detection seems to work properly and the only >>> thing that seems to be left are some backtrace/unwind issues. These >>> are perhaps similar to the unwind bits that the powerpc folks ran >>> into. >> >> David, does the following patch (will have some fuzz since I removed >> one ppc only hunk from the patch) fix your backtrace issue? I'll note >> you'll have to add "|| defined(__sparc__)" to the #if ... or as >> it's probably going to turn out, just replace the whole thing >> with a "#if !defined(__i386__) && !defined(__x86_64__)". > > This patch works well but I have some unrelated sanitizer sparc > issues to resolve before the testcase will pass properly. > > Feel free to submit this with the __sparc__ cpp test added, or > the !x86 variant, at your discretion. Actually I looked more closely at this, and the trigger is hit one stack frame too late on sparc. The BP computed in the memcmp() interceptor is the frame pointer %fp, but on sparc that's the CFA of the caller, main() in the case of the memcmp-1.c testcase. So only main() appears in the backtrace. It might be easier to implement this by comparing the PC instead. And it also occurs to me that we probably need to be using __builtin_extract_return_addr() when recording the PC at the error trigger point.
Re: Sparc ASAN
On Wed, Nov 21, 2012 at 03:27:16PM -0500, David Miller wrote: > Actually I looked more closely at this, and the trigger is hit one > stack frame too late on sparc. Are you testing with -fno-builtin-memcmp? Without it the check is done directly in main... Jakub
Re: Sparc ASAN
From: Jakub Jelinek Date: Wed, 21 Nov 2012 21:30:37 +0100 > On Wed, Nov 21, 2012 at 03:27:16PM -0500, David Miller wrote: >> Actually I looked more closely at this, and the trigger is hit one >> stack frame too late on sparc. > > Are you testing with -fno-builtin-memcmp? Without it the check is done > directly in main... I made sure that the error triggered in the ASAN memcmp interceptor, please read the paragraph after the one you are quoting.
[committed] Update gomp_managed_threads in gomp_free_thread (PR libgomp/55411)
Hi! gomp_free_thread wasn't updating gomp_managed_threads count, so if a thread that executed #pragma omp parallel terminated, we might be still using throttled spin count instead of normal one unnecessarily. Tested on x86_64-linux and i686-linux, committed to trunk and 4.7. 2012-11-21 Jakub Jelinek PR libgomp/55411 * team.c (gomp_free_thread): Decrease gomp_managed_threads if pool had any threads_used. --- libgomp/team.c.jj 2011-08-03 18:40:16.0 +0200 +++ libgomp/team.c 2012-11-21 11:21:42.188165545 +0100 @@ -1,4 +1,4 @@ -/* Copyright (C) 2005, 2006, 2007, 2008, 2009, 2011 +/* Copyright (C) 2005, 2006, 2007, 2008, 2009, 2011, 2012 Free Software Foundation, Inc. Contributed by Richard Henderson . @@ -232,6 +232,15 @@ gomp_free_thread (void *arg __attribute_ gomp_barrier_wait (&pool->threads_dock); /* Now it is safe to destroy the barrier and free the pool. */ gomp_barrier_destroy (&pool->threads_dock); + +#ifdef HAVE_SYNC_BUILTINS + __sync_fetch_and_add (&gomp_managed_threads, + 1L - pool->threads_used); +#else + gomp_mutex_lock (&gomp_remaining_threads_lock); + gomp_managed_threads -= pool->threads_used - 1L; + gomp_mutex_unlock (&gomp_remaining_threads_lock); +#endif } free (pool->threads); if (pool->last_team) Jakub
[PATCH] Fix VRP MULT_EXPR handling (PR tree-optimization/54471)
Hi!
If a type has 2 * HWI precision, sizem1 is maximum double_int (all ones)
and thus size = sizem1 + double_int_one overflows into 0. If either min0
or min1 is also zero, we might wrongly canonicalize the range into a signed
one. Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux,
ok for trunk?
2012-11-21 Jakub Jelinek
PR tree-optimization/54471
* tree-vrp.c (extract_range_from_binary_expr_1): For MULT_EXPR,
don't canonicalize range if min2 is zero.
* gcc.dg/tree-ssa/vrp86.c: New test.
* gcc.c-torture/execute/pr54471.c: New test.
--- gcc/tree-vrp.c.jj 2012-11-21 16:00:05.85079 +0100
+++ gcc/tree-vrp.c 2012-11-21 18:24:58.385290035 +0100
@@ -2653,7 +2653,7 @@ extract_range_from_binary_expr_1 (value_
if (TYPE_UNSIGNED (expr_type))
{
double_int min2 = size - min0;
- if (min2.cmp (max0, true) < 0)
+ if (!min2.is_zero () && min2.cmp (max0, true) < 0)
{
min0 = -min2;
max0 -= size;
@@ -2661,7 +2661,7 @@ extract_range_from_binary_expr_1 (value_
}
min2 = size - min1;
- if (min2.cmp (max1, true) < 0)
+ if (!min2.is_zero () && min2.cmp (max1, true) < 0)
{
min1 = -min2;
max1 -= size;
--- gcc/testsuite/gcc.dg/tree-ssa/vrp86.c.jj2012-11-21 18:27:53.389280736
+0100
+++ gcc/testsuite/gcc.dg/tree-ssa/vrp86.c 2012-11-21 18:27:47.0
+0100
@@ -0,0 +1,28 @@
+/* PR tree-optimization/54471 */
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-tree-vrp1" } */
+
+#ifdef __SIZEOF_INT128__
+#define T __int128
+#else
+#define T long long
+#endif
+
+void fn1call (void);
+void fn2call (void);
+
+void
+foo (unsigned T x)
+{
+ if (x > (unsigned T) -3)
+return;
+ unsigned T y = 2 * x;
+ if (y == 42)
+fn1call ();
+ else
+fn2call ();
+}
+
+/* { dg-final { scan-tree-dump "fn1call" "vrp1"} } */
+/* { dg-final { scan-tree-dump "fn2call" "vrp1"} } */
+/* { dg-final { cleanup-tree-dump "vrp1" } } */
--- gcc/testsuite/gcc.c-torture/execute/pr54471.c.jj2012-11-21
18:24:58.386289954 +0100
+++ gcc/testsuite/gcc.c-torture/execute/pr54471.c 2012-11-21
18:24:58.386289954 +0100
@@ -0,0 +1,36 @@
+/* PR tree-optimization/54471 */
+
+#ifdef __SIZEOF_INT128__
+#define T __int128
+#else
+#define T long long
+#endif
+
+extern void abort (void);
+
+__attribute__ ((noinline))
+unsigned T
+foo (T ixi, unsigned ctr)
+{
+ unsigned T irslt = 1;
+ T ix = ixi;
+
+ for (; ctr; ctr--)
+{
+ irslt *= ix;
+ ix *= ix;
+}
+
+ if (irslt != 14348907)
+abort ();
+ return irslt;
+}
+
+int
+main ()
+{
+ unsigned T res;
+
+ res = foo (3, 4);
+ return 0;
+}
Jakub
[PATCH] Use ATTRIBUTE_PACKED in ree.c
Hi!
The PR55430 miscompilation of ree.c by LRA lead me to look at
this structure, which was really meant to be just 2 byte long, but
is unnecessarily 4 byte long. As it only contains 8, 2 and 1 bit bitfields,
it can always (except old alphas) be accessed by 1 byte loads/stores, so
packed attribute doesn't slow things down. Fixed thusly,
bootstrapped/regtested on
x86_64-linux and i686-linux, ok for trunk?
2012-11-21 Jakub Jelinek
* ree.c (struct ext_modified): Add ATTRIBUTE_PACKED.
--- gcc/ree.c.jj2012-11-21 16:00:13.0 +0100
+++ gcc/ree.c 2012-11-21 18:43:27.025706082 +0100
@@ -475,7 +475,7 @@ enum ext_modified_kind
EXT_MODIFIED_SEXT
};
-struct ext_modified
+struct ATTRIBUTE_PACKED ext_modified
{
/* Mode from which ree has zero or sign extended the destination. */
ENUM_BITFIELD(machine_mode) mode : 8;
Jakub
Re: [patch, pch] Fix pch failure on mips-mti-linux-gnu
On Wed, 21 Nov 2012, Steve Ellcey wrote: > 2012-11-21 Steve Ellcey > > PR pch/55399 > * files.c (pch_open_file): Fix check for implicit_preinclude. OK. I had the extra check in a previous version of my implicit preincludes patch, but took it out as it didn't seem to be needed in my final testing. -- Joseph S. Myers jos...@codesourcery.com
[PATCH]: Fix compiler segfault failure in cd_dce pass
In compiling one of the very large C++ source, the compiler hit a segfault in cddce -- the ssa_name of a vuse operand has a null def stmt. The def stmt was a PHI node, and later got removed by the phicprop pass (in eliminate_degenerated_phis because it seems to have zero uses) : .MEM_343 = PHI (...) VUSE (.MEM_343); std::__throw_runtime_error (..) >From the IR dump, it looks normal -- the PHI's def has a real use, but why does it got removed? Closer investigation shows that there is actually no use operand created for MEM_343 and the VUSE is a dangling reference. How did this happen? Here is how it happens: The phi node was created during SSA update after PRE, The make_ssa_name happens to pick up the dead ssa_name MEM_343 just got released because of unreachable code elimination (note that PRE can make condition be folded). After MEM_343 is release, the virtual use in bb 17 becomes dangled ( bb 17 was not deleted together with its predecessor that defines MEM_343 is because of the tail block merging pass in PRE). During post PRE ssa_update, the compiler sees that the tree value is the same '.MEM_343' so it does not bother to recreate the use, thus makes the phi look like dead. (As you can see, the condition to trigger the failure is really really rare, that is why there is no reduced test case for it --- multidelta is crunching for 4 days, and the best it got is still > 50k lines). The following simple patch solve the problem. Bootstrtapped and there is no regression. Ok to install for trunk? Index: tree-into-ssa.c === --- tree-into-ssa.c (revision 193698) +++ tree-into-ssa.c (working copy) @@ -1767,7 +1767,7 @@ maybe_replace_use (use_operand_p use_p) else if (is_old_name (use)) rdef = get_reaching_def (use); - if (rdef && rdef != use) + if (rdef) SET_USE (use_p, rdef); } 2012-11-21 Xinliang David Li * tree-into-ssa.c (make_replace_use): force use replacement in SSA update. David
patch to fix PR55414
The following patch fixes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55414
The patch was successfully bootstrapped on x86/x86-64.
Committed as rev. 193712.
2012-11-21 Vladimir Makarov
PR rtl-optimization/55414
* lra-constraints.c (Index): New function.
(lra_constraints): Check dead equiv init insns.
Index: lra-constraints.c
===
--- lra-constraints.c (revision 193702)
+++ lra-constraints.c (working copy)
@@ -3215,6 +3215,17 @@ multi_block_pseudo_p (int regno)
return false;
}
+/* Return true if LIST contains a deleted insn. */
+static bool
+contains_deleted_insn_p (rtx list)
+{
+ for (; list != NULL_RTX; list = XEXP (list, 1))
+if (NOTE_P (XEXP (list, 0))
+ && NOTE_KIND (XEXP (list, 0)) == NOTE_INSN_DELETED)
+ return true;
+ return false;
+}
+
/* Return true if X contains a pseudo dying in INSN. */
static bool
dead_pseudo_p (rtx x, rtx insn)
@@ -3317,10 +3328,29 @@ lra_constraints (bool first_p)
bool pseudo_p = contains_reg_p (x, false, false);
rtx set, insn;
- /* We don't use DF for compilation speed sake. So it is
- problematic to update live info when we use an
- equivalence containing pseudos in more than one BB. */
- if ((pseudo_p && multi_block_pseudo_p (i))
+ /* After RTL transformation, we can not guarantee that
+ pseudo in the substitution was not reloaded which might
+ make equivalence invalid. For example, in reverse
+ equiv of p0
+
+ p0 <- ...
+ ...
+ equiv_mem <- p0
+
+ the memory address register was reloaded before the 2nd
+ insn. */
+ if ((! first_p && pseudo_p)
+ /* We don't use DF for compilation speed sake. So it
+ is problematic to update live info when we use an
+ equivalence containing pseudos in more than one
+ BB. */
+ || (pseudo_p && multi_block_pseudo_p (i))
+ /* If an init insn was deleted for some reason, cancel
+ the equiv. We could update the equiv insns after
+ transformations including an equiv insn deletion
+ but it is not worthy as such cases are extremely
+ rare. */
+ || contains_deleted_insn_p (ira_reg_equiv[i].init_insns)
/* If it is not a reverse equivalence, we check that a
pseudo in rhs of the init insn is not dying in the
insn. Otherwise, the live info at the beginning of
@@ -3335,19 +3365,6 @@ lra_constraints (bool first_p)
&& (int) REGNO (SET_DEST (set)) == i)
&& init_insn_rhs_dead_pseudo_p (i)))
ira_reg_equiv[i].defined_p = false;
- else if (! first_p && pseudo_p)
- /* After RTL transformation, we can not guarantee that
-pseudo in the substitution was not reloaded which
-might make equivalence invalid. For example, in
-reverse equiv of p0
-
-p0 <- ...
-...
-equiv_mem <- p0
-
-the memory address register was reloaded before the
-2nd insn. */
- ira_reg_equiv[i].defined_p = false;
if (contains_reg_p (x, false, true))
ira_reg_equiv[i].profitable_p = false;
if (get_equiv_substitution (reg) != reg)
Re: [Patch, Fortran] PR 55352: [4.7/4.8 Regression] Erroneous gfortran warning of unused module variable when variable is only used in namelist
> Thanks for the patch - it's OK for trunk and 4.7. Thanks, Paul. Committed to trunk as r193711. I will apply it to the 4.7 branch soon. Cheers, Janus > On 19 November 2012 21:39, Janus Weil wrote: >> Hi all, >> >> here is another contribution in trying to reduce the still too large >> number of regressions in the Fortran front end (which used to be >> basically zero for some time in the past). >> >> The attached patch is rather straightforward and fixes a bogus >> unused-variable warning. I would be grateful for any comments, in >> absence of which I will commit the patch to trunk by the end of this >> week. >> >> It was regtested on x86_64-unknown-linux-gnu. Ok for trunk and 4.7? >> >> Cheers, >> Janus >> >> >> >> 2012-11-19 Janus Weil >> >> PR fortran/55352 >> * trans-decl.c (generate_local_decl): Don't warn for explicitly imported >> but unused module variables which are in a namelist or common block. >> >> 2012-11-19 Janus Weil >> >> PR fortran/55352 >> * gfortran.dg/namelist_76.f90: New. > > > > -- > The knack of flying is learning how to throw yourself at the ground and miss. >--Hitchhikers Guide to the Galaxy
[alpha] Update to new extv/insv patterns
I wrote and tested this before Richard S posted an optabs.c patch
that more or less fixes the problem generically. But since this
is the way we want to go in the long term, and I've already done
the testing, I figured I might as well commit it now.
r~
* config/alpha/alpha.md (extvmisaligndi): Rename from extv; update
mode of operand 1; remove ancient extract_bit_field workaround.
(insvmisaligndi): Rename from insv and update similarly.
(extzvmisaligndi): Rename from extzv and update similarly; split out
(extzvdi): New expander.
diff --git a/gcc/config/alpha/alpha.md b/gcc/config/alpha/alpha.md
index 1aa8a671..97bd258 100644
--- a/gcc/config/alpha/alpha.md
+++ b/gcc/config/alpha/alpha.md
@@ -4636,15 +4636,13 @@
;; Bit field extract patterns which use ext[wlq][lh]
-(define_expand "extv"
+(define_expand "extvmisaligndi"
[(set (match_operand:DI 0 "register_operand")
- (sign_extract:DI (match_operand:QI 1 "memory_operand")
-(match_operand:DI 2 "immediate_operand")
-(match_operand:DI 3 "immediate_operand")))]
+ (sign_extract:DI (match_operand:BLK 1 "memory_operand")
+(match_operand:DI 2 "const_int_operand")
+(match_operand:DI 3 "const_int_operand")))]
""
{
- int ofs;
-
/* We can do 16, 32 and 64 bit fields, if aligned on byte boundaries. */
if (INTVAL (operands[3]) % 8 != 0
|| (INTVAL (operands[2]) != 16
@@ -4652,62 +4650,56 @@
&& INTVAL (operands[2]) != 64))
FAIL;
- /* From mips.md: extract_bit_field doesn't verify that our source
- matches the predicate, so we force it to be a MEM here. */
- if (!MEM_P (operands[1]))
-FAIL;
-
- ofs = INTVAL (operands[3]);
- ofs = ofs / 8;
-
alpha_expand_unaligned_load (operands[0], operands[1],
INTVAL (operands[2]) / 8,
- ofs, 1);
+ INTVAL (operands[3]) / 8, 1);
DONE;
})
-(define_expand "extzv"
+(define_expand "extzvdi"
[(set (match_operand:DI 0 "register_operand")
- (zero_extract:DI (match_operand:DI 1 "nonimmediate_operand")
-(match_operand:DI 2 "immediate_operand")
-(match_operand:DI 3 "immediate_operand")))]
+ (zero_extract:DI (match_operand:DI 1 "register_operand")
+(match_operand:DI 2 "const_int_operand")
+(match_operand:DI 3 "const_int_operand")))]
""
{
/* We can do 8, 16, 32 and 64 bit fields, if aligned on byte boundaries. */
if (INTVAL (operands[3]) % 8 != 0
|| (INTVAL (operands[2]) != 8
- && INTVAL (operands[2]) != 16
+ && INTVAL (operands[2]) != 16
&& INTVAL (operands[2]) != 32
&& INTVAL (operands[2]) != 64))
FAIL;
+})
- if (MEM_P (operands[1]))
-{
- int ofs;
-
- /* Fail 8-bit fields, falling back on a simple byte load. */
- if (INTVAL (operands[2]) == 8)
- FAIL;
-
- ofs = INTVAL (operands[3]);
- ofs = ofs / 8;
+(define_expand "extzvmisaligndi"
+ [(set (match_operand:DI 0 "register_operand")
+ (zero_extract:DI (match_operand:BLK 1 "memory_operand")
+(match_operand:DI 2 "const_int_operand")
+(match_operand:DI 3 "const_int_operand")))]
+ ""
+{
+ /* We can do 16, 32 and 64 bit fields, if aligned on byte boundaries.
+ We fail 8-bit fields, falling back on a simple byte load. */
+ if (INTVAL (operands[3]) % 8 != 0
+ || (INTVAL (operands[2]) != 16
+ && INTVAL (operands[2]) != 32
+ && INTVAL (operands[2]) != 64))
+FAIL;
- alpha_expand_unaligned_load (operands[0], operands[1],
- INTVAL (operands[2]) / 8,
- ofs, 0);
- DONE;
-}
+ alpha_expand_unaligned_load (operands[0], operands[1],
+ INTVAL (operands[2]) / 8,
+ INTVAL (operands[3]) / 8, 0);
+ DONE;
})
-(define_expand "insv"
- [(set (zero_extract:DI (match_operand:QI 0 "memory_operand")
-(match_operand:DI 1 "immediate_operand")
-(match_operand:DI 2 "immediate_operand"))
+(define_expand "insvmisaligndi"
+ [(set (zero_extract:DI (match_operand:BLK 0 "memory_operand")
+(match_operand:DI 1 "const_int_operand")
+(match_operand:DI 2 "const_int_operand"))
(match_operand:DI 3 "register_operand"))]
""
{
- int ofs;
-
/* We can do 16, 32 and 64 bit fields, if aligned on byte boundaries. */
if (INTVAL (operands[2]) % 8 != 0
|| (INTVAL (operands[1]) != 16
@@ -4715,16 +4707,9 @@
&& INTVAL (operands[1]) != 64))
FAIL;
- /* From mips.md: store_bit_field doesn't verify that our source
- matches the predicate, so we force it to be a MEM
Re: ping - Re: [patch] [alpha] add multiarch definitions for alpha-linux-gnu
On 11/21/2012 02:52 PM, Matthias Klose wrote: > http://gcc.gnu.org/ml/gcc-patches/2012-11/msg01172.html Ok. r~
Re: [PATCH] Use ATTRIBUTE_PACKED in ree.c
> 2012-11-21 Jakub Jelinek > > * ree.c (struct ext_modified): Add ATTRIBUTE_PACKED. Are you sure that this will compile with non-GCC compilers? -- Eric Botcazou
Re: Sparc ASAN
On Wed, 2012-11-21 at 15:27 -0500, David Miller wrote: > Actually I looked more closely at this, and the trigger is hit one > stack frame too late on sparc. > > The BP computed in the memcmp() interceptor is the frame pointer > %fp, but on sparc that's the CFA of the caller, main() in the > case of the memcmp-1.c testcase. > > So only main() appears in the backtrace. > > It might be easier to implement this by comparing the PC instead. > > And it also occurs to me that we probably need to be using > __builtin_extract_return_addr() when recording the PC at the > error trigger point. If you have a suggested change/patch that does that, let me know and I can try it out on powerpc to make sure it works for us too. Peter
RFC: Add --with-build-config=bootstrap-asan support
Hi, I added --with-build-config=bootstrap-asan support on hjl/asan branch: http://gcc.gnu.org/git/?p=gcc.git;a=shortlog;h=refs/heads/hjl/asan Any comments? Thanks. -- H.J.
[patch, libquadmath, committed] Another GLIBC update of libquadmath
Committed as Rev. 193716. (I still have to update I/O and rounding, taking Joseph's comment into account.) Tobias
Re: Fwd: [libatomic][patch] Handle -mx32 like -m64
On 11/21/2012 03:23 PM, Matthias Klose wrote: > * configure.tgt (i[3456]86): Handle -mx32 like -m64. Ok. r~
[Patch Ping] Fix problem that hardreg_cprop opportunities are missed on thumb1GCC
> -Original Message- > From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-ow...@gcc.gnu.org] On > Behalf Of Bin Cheng > Sent: Wednesday, October 10, 2012 5:58 PM > To: gcc-patches@gcc.gnu.org > Cc: Ramana Radhakrishnan; Richard Earnshaw; 'Richard Sandiford' > Subject: RE: [PING Updated]: [PATCH GCC/ARM] Fix problem that hardreg_cprop > opportunities are missed on thumb1 > > Ping^2 > > > -Original Message- > > From: gcc-patches-ow...@gcc.gnu.org > > [mailto:gcc-patches-ow...@gcc.gnu.org] > On > > Behalf Of Bin Cheng > > Sent: Monday, October 08, 2012 2:36 PM > > To: gcc-patches@gcc.gnu.org > > Cc: Ramana Radhakrishnan; Richard Earnshaw; 'Richard Sandiford' > > Subject: RE: [PING Updated]: [PATCH GCC/ARM] Fix problem that > hardreg_cprop > > opportunities are missed on thumb1 > > > > Ping. > > > > > -Original Message- > > > From: gcc-patches-ow...@gcc.gnu.org > > > [mailto:gcc-patches-ow...@gcc.gnu.org] > > On > > > Behalf Of Bin Cheng > > > Sent: Tuesday, September 25, 2012 4:00 PM > > > To: 'Richard Sandiford' > > > Cc: Ramana Radhakrishnan; Richard Earnshaw; gcc-patches@gcc.gnu.org > > > Subject: RE: [Updated]: [PATCH GCC/ARM] Fix problem that > > > hardreg_cprop opportunities are missed on thumb1 > > > > > > > > > > -Original Message- > > > > From: Richard Sandiford [mailto:rdsandif...@googlemail.com] > > > > Sent: Wednesday, September 05, 2012 6:09 AM > > > > To: Bin Cheng > > > > Cc: Ramana Radhakrishnan; 'Eric Botcazou'; gcc-patches@gcc.gnu.org > > > > Subject: Re: Ping: [PATCH GCC/ARM] Fix problem that hardreg_cprop > > > > opportunities are missed on thumb1 > > > > > > > Subtraction of zero isn't canonical rtl though. Passes after > > > > peephole2 > > > would > > > > be well within their rights to simplify the expression back to a move. > > > > From that point of view, making the passes recognise (plus X 0) > > > > and (minus > > > X 0) > > > > as special cases would be inconsistent. > > > > > > > > Rather than make the Thumb 1 CC usage implicit in the rtl stream, > > > > and > > > carry > > > > the current state around in cfun->machine, it seems like it would > > > > be > > > better to > > > > get md_reorg to rewrite the instructions into a form that makes > > > > the use of condition codes explicit. > > > > > > > > md_reorg also sounds like a better place in the pipeline than > > > > peephole2 to > > > be > > > > doing this kind of transformation, although I admit I have zero > > > > evidence > > > to > > > > back that up... > > > > > > > > > > Hi Richard, > > > > > > This is the updated patch according to your suggestions. I removed > > > the > > > peephole2 patterns and introduced function thumb1_reorg to rewrite > > > instructions in md_reorg pass. > > > > > > In addition to missed propagation, this patch also detects following > case: > > > mov r5, r0 > > > str r0, [r4] <---miscellaneous irrelevant instructions > > > [cmp r0, 0]<---saved > > > bne .Lxxx > > > > > > Patch tested on arm-none-eabi/cortex-m0, no regressions introduced. > > > > > > Is it OK? > > > > > > Thanks. > > > > > > 2012-09-25 Bin Cheng > > > > > > * config/arm/arm.c (thumb1_reorg): New function. > > > (arm_reorg): Call thumb1_reorg. > > > (thumb1_final_prescan_insn): Record src operand in thumb1_cc_op0. > > > * config/arm/arm.md : Remove peephole2 patterns which rewrites move > > > into subtract of ZERO. > > > > > > Hi, this patch was posted long before, could somebody help me review this? http://gcc.gnu.org/ml/gcc-patches/2012-10/msg00967.html Thanks very much.
Re: [libsanitizer] a script to help merging asan from upstream
Added to README.gcc:
The merges from upstream should be done with the aid of the merge.sh script;
it will also update the file MERGE to contain the upstream revision
we merged with.
On Wed, Nov 21, 2012 at 11:03 PM, Xinliang David Li wrote:
> How about also documenting this in README.gcc?
>
> David
>
> On Wed, Nov 21, 2012 at 10:56 AM, Kostya Serebryany wrote:
>> Done both.
>>
>>
>> +fatal() {
>> + echo "$1"
>> + exit 1;
>> +}
>> +
>> +pwd | grep 'libsanitizer$' || \
>> + fatal "Run this script from libsanitizer dir"
>>
>>
>> +rm -rf upstream
>>
>>
>>
>>
>>
>> On Wed, Nov 21, 2012 at 10:49 PM, Xinliang David Li
>> wrote:
>>> Suggestions:
>>>
>>> 1) make sure current local dir is libsanitizer -- exit if it is not
>>> 2) clean up the upstream directory after the merge is done.
>>>
>>> David
>>>
>>>
>>> On Wed, Nov 21, 2012 at 10:25 AM, Kostya Serebryany wrote:
Hi,
A dummy script to help merging asan from upstream.
Not 100% complete, but should be enough to complete the current merge.
You suggestions on how to improve it (or how to do w/o it) are welcome,
but I really wish to do the first merge tomorrow to unblock other folks.
Thanks,
--kcc
merge.patch
Description: Binary data
Re: [PATCH][Revisedx4] Enable libsanitizer on darwin
Looks good, but I guess we also need to copy the file LICENSE.TXT
--kcc
On Wed, Nov 21, 2012 at 10:44 PM, Jack Howarth wrote:
>The attached patch imports the missing mach_override/mach_override.h and
> mach_override/mach_override.c files from llvm.org's compiler-rt at
>
> r168032 | glider | 2012-11-15 03:32:16 -0500 (Thu, 15 Nov 2012) | 3 lines
>
> [ASan] Add the "lea $imm(%rip),%rax" instruction to mach_override.c
> The need for this has been reported by Jack Howarth
> (howa...@bromo.med.uc.edu) who's porting ASan-Darwin to GCC
>
> The patch adds darwin to the supported target list in configure.tgt and
> defines USING_MACH_OVERRIDE for darwin in configure.ac. The definition of
> USING_MACH_OVERRIDE is used in Makefile.am as the test for appending
> mach_override/mach_override.c to libinterception_la_SOURCES.
> LINK_COMMAND_SPEC_A
> in gcc/config/darwin.h is modified to add an entry to handle fsanitize=address
> so that the required linkages are used for libasan. The static linkage of
> libasan.a
> in LINK_COMMAND_SPEC_A is handle separately for -static-libstdc++ (which
> requires
> libstdc++.a) and the -static, -static-gcc and -static-gfortran cases. Tested
> on
> x86_64-apple-darwin12 for both -m32 and -m64 with the both use-after-free.c
> testcase
> and...
>
> make -k check RUNTESTFLAGS="asan.exp --target_board=unix'{-m32,-m64}'"
>
> without regressions.
> Jack
> ps This patch is identical to the prior version (asan_v7.diff) except the
> changes to
> gcc/config/darwin.h are adjusted for the renaming of the -faddress-sanitizer
> option to
> -fsanitize=address.
>
Re: Sparc ASAN
From: Peter Bergner Date: Wed, 21 Nov 2012 17:46:57 -0600 > If you have a suggested change/patch that does that, let me know > and I can try it out on powerpc to make sure it works for us too. I will try to do so, but I am pretty sure at this point that it will end up being some time early next week.
Re: [patch,avr] Ad PR54222: Move decimal point of signed accum one bit right.
2012/11/21 Georg-Johann Lay : > This patch restores the GCC default layout of HA, SA and DA mode. > > The original fixed point support tried to be binary compatible with > fixed-point > support already provided by some non-FSF ports, but that turned out to result > in wrong code in some situations. > > Reason is that these ports adjusted the signed accum fixed-point modes so that > the decimal point is byte aligned which results in smaller code. > > This means GCC fixed-point engine is not generic enough to handle all mode > adjustments from -modes.md, thus this patch switches the modes to GCC > default. > > There are no new regressions. > > However, I could not drive all the tests I usually do, because my framework to > test arithmetics crashes with PR54814 (spill fail). > > Ok for trunk? > Approved. Denis.
Re: [Patch Ping] Fix problem that hardreg_cprop opportunities are missed on thumb1GCC
On 11/21/2012 06:46 PM, Bin Cheng wrote: -Original Message- From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-ow...@gcc.gnu.org] On Behalf Of Bin Cheng Sent: Wednesday, October 10, 2012 5:58 PM To: gcc-patches@gcc.gnu.org Cc: Ramana Radhakrishnan; Richard Earnshaw; 'Richard Sandiford' Subject: RE: [PING Updated]: [PATCH GCC/ARM] Fix problem that hardreg_cprop opportunities are missed on thumb1 Ping^2 One of the ARM port maintainers should own this. Nick, Richard, Paul or Ramana (though I haven't seen anything from Paul in a while). jeff
