[PATCH] [ping] Use single shared memory block pool for all pool allocators
Hi, all.
I'm pinging this patch: https://gcc.gnu.org/ml/gcc-patches/2015-08/msg00030.html
And adding some more changes to it (they are not complete yet - so they are more
like an RFC).
In this patch I also try to make obstacks use the same block pool as object
pools. This seems rather easy to implement because obstacks already have
obstack_chunk_alloc/obstack_chunk_free callbacks, and they are easily replaced.
I also change the default chunk size to memory_block_pool::block_size. This
still works for object sizes greater than memory_block_pool::block_size: in this
case I simply call xmalloc to allocate the requested chunk, and the deallocation
function uses obstack chunk header to determine chunk's size (and depending on
it calls either free or memory_block_pool::remove).
The result is visible on the profile. For example, for tramp3d build
_obstack_begin is the top caller of xmalloc (it constitutes 107 ms into xmalloc
self time, which is 375 ms - according to one of my runs). After applying the
patch it is gone from profile.
This patch adds new files virtual-memory.h and virtual-memory.cc, which
currently contain memory_block_pool class and related obstack functions (I plan
to factor out part of ggc-page.c into this file in order to use
mmap/VirtualAlloc directly, hence the name "virtual-memory"). Currently this
file is linked into libcommon, and this seems somewhat wrong to me, because the
driver and other command line tools don't use all memory management machinery of
the compiler proper. But obstacks are used by diagnostics.c and this file is
already in libcommon, so there is probably no easy way to make it use xmalloc
instead of memory_block_pool::allocate. A possible solution is to create an
additional file with definitions of mempool_obstack_chunk_alloc/free and use it
for generators and drivers (or somehow make mempool_obstack_chunk_alloc alias to
malloc). Do you have any suggestions, how this could be done in a better way?
Another problem is headers. I included "virtual-memory.h" into coretypes.h,
because it defines a macro gcc_obstack_init, which now uses functions from
virtual-memory.h. Alternatively I could just declare those functions in
coretypes.h. Would that be better?
--
Regards,
Mikhail Maltsev
diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index c1cb4ce..1b4198d 100644
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -1516,7 +1516,7 @@ OBJS = \
# Objects in libcommon.a, potentially used by all host binaries and with
# no target dependencies.
OBJS-libcommon = diagnostic.o diagnostic-color.o pretty-print.o intl.o \
- vec.o input.o version.o hash-table.o ggc-none.o
+ vec.o input.o version.o hash-table.o ggc-none.o virtual-memory.o
# Objects in libcommon-target.a, used by drivers and by the core
# compiler and containing target-dependent code.
diff --git a/gcc/alloc-pool.c b/gcc/alloc-pool.c
index f8c1351..7e25915 100644
--- a/gcc/alloc-pool.c
+++ b/gcc/alloc-pool.c
@@ -35,25 +35,3 @@ dump_alloc_pool_statistics (void)
pool_allocator_usage.dump (ALLOC_POOL_ORIGIN);
}
-
-/* Global singleton-like instance. */
-memory_block_pool memory_block_pool::instance;
-
-memory_block_pool::memory_block_pool () : m_blocks (NULL) {}
-
-memory_block_pool::~memory_block_pool ()
-{
- release ();
-}
-
-/* Free all memory allocated by memory_block_pool. */
-void
-memory_block_pool::release ()
-{
- while (m_blocks)
-{
- block_list *next = m_blocks->m_next;
- XDELETEVEC (m_blocks);
- m_blocks = next;
-}
-}
diff --git a/gcc/alloc-pool.h b/gcc/alloc-pool.h
index dccc41a..eccdf0d 100644
--- a/gcc/alloc-pool.h
+++ b/gcc/alloc-pool.h
@@ -20,6 +20,7 @@ along with GCC; see the file COPYING3. If not see
#ifndef ALLOC_POOL_H
#define ALLOC_POOL_H
+#include "virtual-memory.h"
extern void dump_alloc_pool_statistics (void);
@@ -95,55 +96,6 @@ struct pool_usage: public mem_usage
extern mem_alloc_description pool_allocator_usage;
-/* Shared pool which allows other memory pools to reuse each others' allocated
- memory blocks instead of calling free/malloc again. */
-class memory_block_pool
-{
-public:
- /* Blocks have fixed size. This is necessary for sharing. */
- static const size_t block_size = 64 * 1024;
-
- memory_block_pool ();
- ~memory_block_pool ();
-
- static inline void *allocate () ATTRIBUTE_MALLOC;
- static inline void remove (void *);
- void release ();
-
-private:
- /* memory_block_pool singleton instance, defined in alloc-pool.c. */
- static memory_block_pool instance;
-
- struct block_list
- {
-block_list *m_next;
- };
-
- /* Free list. */
- block_list *m_blocks;
-};
-
-/* Allocate single block. Reuse previously returned block, if possible. */
-inline void *
-memory_block_pool::allocate ()
-{
- if (instance.m_blocks == NULL)
-return XNEWVEC (char, block_size);
-
- void *result = instance.m_blocks;
- instance.m_blocks = instance.m_blocks->m_next;
- return result;
-}
-
-/* Return UNCAST_BLOCK to pool. */
-inline void
-memo
Re: [PR16107] Convert cos (-x) into cos (x)
Hi Marc Glisse, Thanks for pointing out the error. That "div" is not supposed to be there. Exact pattern is:- > * match.pd (coss (op @0) : New simplifier. However, the exact pattern is present in the sources and a typo has been introduced in the ChangeLog. Sorry for the mistake. Thanks, Naveen From: Marc Glisse Sent: Monday, August 17, 2015 10:35 AM To: Hurugalawadi, Naveen Cc: gcc-patches@gcc.gnu.org Subject: Re: [PR16107] Convert cos (-x) into cos (x) On Fri, 7 Aug 2015, Hurugalawadi, Naveen wrote: > gcc/ChangeLog: > * match.pd (COS (negate @0) : New simplifier. Please fix ChangeLog so it is well-parenthesized, the committed version is even worse: > * match.pd (div (coss (op @0) : New simplifier. What is this "div" about? Thanks, -- Marc Glisse
Move some flag_unsafe_math_optimizations using simplify and match
Hi,
Please find attached the modified patch as per the comments.
Tested the patch on AArch64 and X86 without any regressions.
The other hunks of the earlier patch have been removed as per the earlier
comments due to failure in regressions.
Investigated those issues and found that its because of Double and Float
patterns.
Could not deduce why the double and float patterns FAIL though.
>> fold_builtin_cos/cosh can be reduced to constant folding, thus
>> remove their fold_strip_sign_nops () path.
Had removed them but the double and float patterns does not generate the
optimizations and hence had to retain them
Please let me know why the double and float patterns are failing.
I could work on those and try to move all other patterns using
"simplify and match".
The testcase for these pattern optimizations are present.
Please let me know whether we would need a separate check so that I
can add them.
Thanks,
Naveen
ChangeLog
2015-08-17 Naveen H.S
PR middle-end/16107
* fold-const.c (fold_binary_loc) : Move Optimize tan(x)*cos(x) as
sin(x) to match.pd.
Move Optimize x*pow(x,c) as pow(x,c+1) to match.pd.
Move Optimize pow(x,c)*x as pow(x,c+1) to match.pd.
Move Optimize sin(x)/cos(x) as tan(x) to match.pd.
Move Optimize cos(x)/sin(x) as 1.0/tan(x) to match.pd.
Move Optimize sin(x)/tan(x) as cos(x) to match.pd.
Move Optimize tan(x)/sin(x) as 1.0/cos(x) to match.pd.
Move Optimize pow(x,c)/x as pow(x,c-1) to match.pd.
Move Optimize x/pow(y,z) into x*pow(y,-z) to match.pd.
* match.pd (SIN ) : New Operator.
(TAN) : New Operator.
(mult:c (SQRT (SQRT@1 @0)) @1) : New simplifier.
(mult (POW:s @0 @1) (POW:s @2 @1))
(mult:c (TAN:s @0) (COS:s @0))
(mult:c @0 (POW @0 @1))
(rdiv (SIN:s @0) (COS:s @0))
(rdiv (COS:s @0) (SIN:s @0))
(rdiv (SIN:s @0) (TAN:s @0))
(rdiv (TAN:s @0) (SIN:s @0))
(rdiv (POW @0 @1) @0)
(rdiv @0 (SQRT (rdiv @1 @2)))
(rdiv @0 (POW @1 @2))diff --git a/gcc/fold-const.c b/gcc/fold-const.c
index 6c65fe1..c0399ca 100644
--- a/gcc/fold-const.c
+++ b/gcc/fold-const.c
@@ -10008,67 +10008,6 @@ fold_binary_loc (location_t loc,
}
}
- /* Optimize tan(x)*cos(x) as sin(x). */
- if (((fcode0 == BUILT_IN_TAN && fcode1 == BUILT_IN_COS)
- || (fcode0 == BUILT_IN_TANF && fcode1 == BUILT_IN_COSF)
- || (fcode0 == BUILT_IN_TANL && fcode1 == BUILT_IN_COSL)
- || (fcode0 == BUILT_IN_COS && fcode1 == BUILT_IN_TAN)
- || (fcode0 == BUILT_IN_COSF && fcode1 == BUILT_IN_TANF)
- || (fcode0 == BUILT_IN_COSL && fcode1 == BUILT_IN_TANL))
- && operand_equal_p (CALL_EXPR_ARG (arg0, 0),
- CALL_EXPR_ARG (arg1, 0), 0))
- {
- tree sinfn = mathfn_built_in (type, BUILT_IN_SIN);
-
- if (sinfn != NULL_TREE)
- return build_call_expr_loc (loc, sinfn, 1,
- CALL_EXPR_ARG (arg0, 0));
- }
-
- /* Optimize x*pow(x,c) as pow(x,c+1). */
- if (fcode1 == BUILT_IN_POW
- || fcode1 == BUILT_IN_POWF
- || fcode1 == BUILT_IN_POWL)
- {
- tree arg10 = CALL_EXPR_ARG (arg1, 0);
- tree arg11 = CALL_EXPR_ARG (arg1, 1);
- if (TREE_CODE (arg11) == REAL_CST
- && !TREE_OVERFLOW (arg11)
- && operand_equal_p (arg0, arg10, 0))
- {
- tree powfn = TREE_OPERAND (CALL_EXPR_FN (arg1), 0);
- REAL_VALUE_TYPE c;
- tree arg;
-
- c = TREE_REAL_CST (arg11);
- real_arithmetic (&c, PLUS_EXPR, &c, &dconst1);
- arg = build_real (type, c);
- return build_call_expr_loc (loc, powfn, 2, arg0, arg);
- }
- }
-
- /* Optimize pow(x,c)*x as pow(x,c+1). */
- if (fcode0 == BUILT_IN_POW
- || fcode0 == BUILT_IN_POWF
- || fcode0 == BUILT_IN_POWL)
- {
- tree arg00 = CALL_EXPR_ARG (arg0, 0);
- tree arg01 = CALL_EXPR_ARG (arg0, 1);
- if (TREE_CODE (arg01) == REAL_CST
- && !TREE_OVERFLOW (arg01)
- && operand_equal_p (arg1, arg00, 0))
- {
- tree powfn = TREE_OPERAND (CALL_EXPR_FN (arg0), 0);
- REAL_VALUE_TYPE c;
- tree arg;
-
- c = TREE_REAL_CST (arg01);
- real_arithmetic (&c, PLUS_EXPR, &c, &dconst1);
- arg = build_real (type, c);
- return build_call_expr_loc (loc, powfn, 2, arg1, arg);
- }
- }
-
/* Canonicalize x*x as pow(x,2.0), which is expanded as x*x. */
if (!in_gimple_form
&& optimize
@@ -10481,107 +10420,8 @@ fold_binary_loc (location_t loc,
if (flag_unsafe_math_optimizations)
{
- enum built_in_function fcode0 = builtin_mathfn_code (arg0);
enum built_in_function fcode1 = builtin_mathfn_code (arg1);
- /* Optimize sin(x)/cos(x) as tan(x). */
- if (((fcode0 == BUILT_IN_SIN && fcode1 == BUILT_IN_COS)
- || (fcode0 == BUILT_IN_SINF && fcode1 == BUILT_IN_COSF)
- || (fcode0 == BUILT_IN_SINL && fcode1 == BUILT_IN_COSL))
- && operand_equal_p (CALL_EXPR_ARG (arg0, 0),
- CA
Re: [PR16107] Convert cos (-x) into cos (x)
On Fri, 7 Aug 2015, Hurugalawadi, Naveen wrote: gcc/ChangeLog: * match.pd (COS (negate @0) : New simplifier. Please fix ChangeLog so it is well-parenthesized, the committed version is even worse: * match.pd (div (coss (op @0) : New simplifier. What is this "div" about? Thanks, -- Marc Glisse
Re: [PR64164] drop copyrename, integrate into expand
On Aug 16, 2015, Andreas Schwab wrote: > Alexandre Oliva writes: >> On Aug 15, 2015, Andreas Schwab wrote: >> >>> FAIL: gcc.target/aarch64/target_attr_crypto_ice_1.c (internal compiler >>> error) >> >>> In file included from >>> /opt/gcc/gcc-20150815/gcc/testsuite/gcc.target/aarch64/target_attr_crypto_ice_1.c:4:0: >> >> Are you sure this is a regression introduced by my patch? > Yes, it reintroduces the ICE. Ugh. I see this testcase was introduced very recently, so presumably it wasn't present in the tree that James Greenhalgh tested and confirmed there were no regressions. The hack in aarch64-builtins.c looks risky IMHO. Changing the mode of a decl after RTL is assigned to it (or to its SSA partitions) seems fishy. The assert is doing just what it was supposed to do. The only surprise to me is that it didn't catch this unexpected and unsupported change before. Presumably if we just dropped the assert in expand_expr_real_1, this case would work just fine, although the unsignedp bit would be meaningless and thus confusing, since the subreg isn't about a promotion, but about reflecting the mode change that was made from under us. May I suggest that you guys find (or introduce) other means to change the layout and mode of the decl *before* RTL is assigned to the params? I think this would save us a ton of trouble down the road. Just think how much trouble you'd get if the different modes had different calling conventions, alignment requirements, valid register assignments, or anything that might make coalescing their SSA names with those of other variables invalid. -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer
Re: [PR64164] drop copyrename, integrate into expand
On Aug 16, 2015, Andreas Schwab wrote:
> On m68k:
> FAIL: gcc.c-torture/execute/20050316-1.c -O0 execution test
> FAIL: gcc.c-torture/execute/20050316-2.c -O0 execution test
> FAIL: gcc.c-torture/execute/20050316-3.c -O0 execution test
> FAIL: gcc.c-torture/execute/simd-4.c -O0 execution test
> FAIL: gcc.c-torture/execute/simd-6.c -O0 execution test
> FAIL: gcc.dg/compat/vector-1 c_compat_x_tst.o-c_compat_y_tst.o execute
Thanks. Interesting. This exposes a more general situation than the
one I covered with the byref params: the general case does not require
the params to be passed by reference, but rather that the params require
a stack address that, if determined by cfgexpand, will cause them to be
computed too late for assign_parms' use. The following patch appears to
fix the problem, applying the same logic of limited coalescing and
deferred address assignment to all params that can't live in pseudos,
and extending assign_parms' remaining case of copying incoming params to
new stack slots to fill in the blank address with that of the
newly-allocated stack slot.
Would you be so kind as to give it a spin on a m68k native? TIA,
diff --git a/gcc/cfgexpand.c b/gcc/cfgexpand.c
index 0bc20f6..56571ce 100644
--- a/gcc/cfgexpand.c
+++ b/gcc/cfgexpand.c
@@ -172,17 +172,23 @@ leader_merge (tree cur, tree next)
return cur;
}
-/* Return true if VAR is a PARM_DECL or a RESULT_DECL of type BLKmode.
+/* Return true if VAR is a PARM_DECL or a RESULT_DECL that ought to be
+ assigned to a stack slot. We can't have expand_one_ssa_partition
+ choose their address: the pseudo holding the address would be set
+ up too late for assign_params to copy the parameter if needed.
+
Such parameters are likely passed as a pointer to the value, rather
than as a value, and so we must not coalesce them, nor allocate
stack space for them before determining the calling conventions for
- them. For their SSA_NAMEs, expand_one_ssa_partition emits RTL as
- MEMs with pc_rtx as the address, and then it replaces the pc_rtx
- with NULL so as to make sure the MEM is not used before it is
- adjusted in assign_parm_setup_reg. */
+ them.
+
+ For their SSA_NAMEs, expand_one_ssa_partition emits RTL as MEMs
+ with pc_rtx as the address, and then it replaces the pc_rtx with
+ NULL so as to make sure the MEM is not used before it is adjusted
+ in assign_parm_setup_reg. */
bool
-parm_maybe_byref_p (tree var)
+parm_in_stack_slot_p (tree var)
{
if (!var || VAR_P (var))
return false;
@@ -190,7 +196,7 @@ parm_maybe_byref_p (tree var)
gcc_assert (TREE_CODE (var) == PARM_DECL
|| TREE_CODE (var) == RESULT_DECL);
- return TYPE_MODE (TREE_TYPE (var)) == BLKmode;
+ return !use_register_for_decl (var);
}
/* Return the partition of the default SSA_DEF for decl VAR. */
@@ -1343,13 +1349,15 @@ expand_one_ssa_partition (tree var)
if (!use_register_for_decl (var))
{
- if (parm_maybe_byref_p (SSA_NAME_VAR (var))
+ /* We can't risk having the parm assigned to a MEM location
+whose address references a pseudo, for the pseudo will only
+be set up after arguments are copied to the stack slot. */
+ if (parm_in_stack_slot_p (SSA_NAME_VAR (var))
&& ssa_default_def_partition (SSA_NAME_VAR (var)) == part)
{
expand_one_stack_var_at (var, pc_rtx, 0, 0);
rtx x = SA.partition_to_pseudo[part];
gcc_assert (GET_CODE (x) == MEM);
- gcc_assert (GET_MODE (x) == BLKmode);
gcc_assert (XEXP (x, 0) == pc_rtx);
/* Reset the address, so that any attempt to use it will
ICE. It will be adjusted in assign_parm_setup_reg. */
diff --git a/gcc/cfgexpand.h b/gcc/cfgexpand.h
index 987cf356..d168672 100644
--- a/gcc/cfgexpand.h
+++ b/gcc/cfgexpand.h
@@ -22,7 +22,7 @@ along with GCC; see the file COPYING3. If not see
extern tree gimple_assign_rhs_to_tree (gimple);
extern HOST_WIDE_INT estimated_stack_frame_size (struct cgraph_node *);
-extern bool parm_maybe_byref_p (tree);
+extern bool parm_in_stack_slot_p (tree);
extern rtx get_rtl_for_parm_ssa_default_def (tree var);
diff --git a/gcc/function.c b/gcc/function.c
index 715c19f..eccd8c6 100644
--- a/gcc/function.c
+++ b/gcc/function.c
@@ -2934,6 +2934,16 @@ assign_parm_setup_block_p (struct assign_parm_data_one
*data)
return false;
}
+static bool
+parm_in_unassigned_mem_p (tree decl, rtx from_expand)
+{
+ bool result = MEM_P (from_expand) && !XEXP (from_expand, 0);
+
+ gcc_assert (result == parm_in_stack_slot_p (decl));
+
+ return result;
+}
+
/* A subroutine of assign_parms. Arrange for the parameter to be
present and valid in DATA->STACK_RTL. */
@@ -2956,8 +2966,7 @@ assign_parm_setup_block (struct assign_parm_data_all *all,
{
DECL_ALIGN (parm) = MAX (DECL_ALIGN (parm), BITS_PER_WORD);
rtx from_expand = rtl_for_parm (all, parm);
- if (from_expand && (!parm_maybe_byre
c-family/c-pretty-print.c - fix for 'restrict' quliafiers
While reviewing some code, I noticed that the logic for
pretty-printing 'restrict' qualifiers is likely missing a
statement that sets 'previous'.
OK to commit?
2015-08-l6 Gary Funck
* c-pretty-print.c (pp_c_cv_qualifiers):
Set 'previous' for restrict qualifiers.
Index: c-pretty-print.c
===
--- c-pretty-print.c(revision 226928)
+++ c-pretty-print.c(working copy)
@@ -207,16 +207,17 @@ pp_c_cv_qualifiers (c_pretty_printer *pp
}
if (qualifiers & TYPE_QUAL_RESTRICT)
{
if (previous)
pp_c_whitespace (pp);
pp_c_ws_string (pp, (flag_isoc99 && !c_dialect_cxx ()
? "restrict" : "__restrict__"));
+ previous = true;
}
}
/* Pretty-print T using the type-cast notation '( type-name )'. */
static void
pp_c_type_cast (c_pretty_printer *pp, tree t)
{
Re: RFC: [PATCH] PR target/67215: -fno-plt needs improvements for x86
On Sun, Aug 16, 2015 at 12:39 PM, H.J. Lu wrote:
> On Sun, Aug 16, 2015 at 12:24 PM, Alexander Monakov
> wrote:
>
>>> + if (!TARGET_64BIT
>>> + || (ix86_cmodel == CM_LARGE_PIC
>>> + && DEFAULT_ABI != MS_ABI))
>>> + {
>>> + use_reg (&use, gen_rtx_REG (Pmode,
>>> + REAL_PIC_OFFSET_TABLE_REGNUM));
>>> + if (ix86_use_pseudo_pic_reg ())
>>> + emit_move_insn (gen_rtx_REG (Pmode,
>>> +
>>> REAL_PIC_OFFSET_TABLE_REGNUM),
>>> + pic_offset_table_rtx);
>>> + }
>>> + }
>>> + else if (!TARGET_PECOFF && !TARGET_MACHO)
>>> + {
>>> + if (TARGET_64BIT)
>>> + {
>>> + fnaddr = gen_rtx_UNSPEC (Pmode,
>>> +gen_rtvec (1, addr),
>>> +UNSPEC_GOTPCREL);
>>> + fnaddr = gen_rtx_CONST (Pmode, fnaddr);
>>> + }
>>> + else
>>> + {
>>> + fnaddr = gen_rtx_UNSPEC (Pmode, gen_rtvec (1, addr),
>>> +UNSPEC_GOT);
>>> + fnaddr = gen_rtx_CONST (Pmode, fnaddr);
>>> + fnaddr = gen_rtx_PLUS (Pmode, pic_offset_table_rtx,
>>> + fnaddr);
>>> + }
>>> + fnaddr = gen_const_mem (Pmode, fnaddr);
>>> + if (GET_MODE (fnaddr) != word_mode)
>>> + fnaddr = gen_rtx_ZERO_EXTEND (word_mode, fnaddr);
>>> + fnaddr = gen_rtx_MEM (QImode, fnaddr);
>>> + }
>>> }
>>> }
>>>
>>> @@ -25686,9 +25715,13 @@ ix86_expand_call (rtx retval, rtx fnaddr, rtx
>>> callarg1,
>>>&& GET_CODE (XEXP (fnaddr, 0)) == SYMBOL_REF
>>>&& !local_symbolic_operand (XEXP (fnaddr, 0), VOIDmode))
>>> fnaddr = gen_rtx_MEM (QImode, construct_plt_address (XEXP (fnaddr,
>>> 0)));
>>> - else if (sibcall
>>> -? !sibcall_insn_operand (XEXP (fnaddr, 0), word_mode)
>>> -: !call_insn_operand (XEXP (fnaddr, 0), word_mode))
>>> + else if (!(TARGET_X32
>>> + && MEM_P (fnaddr)
>>> + && GET_CODE (XEXP (fnaddr, 0)) == ZERO_EXTEND
>>> + && GOT_memory_operand (XEXP (XEXP (fnaddr, 0), 0), Pmode))
>>> +&& (sibcall
>>> +? !sibcall_insn_operand (XEXP (fnaddr, 0), word_mode)
>>> +: !call_insn_operand (XEXP (fnaddr, 0), word_mode)))
>>> {
>>>fnaddr = convert_to_mode (word_mode, XEXP (fnaddr, 0), 1);
>>>fnaddr = gen_rtx_MEM (QImode, copy_to_mode_reg (word_mode, fnaddr));
>>
>> Perhaps add a comment that GOT slots are 64-bit on x32?
>>
>
> Good idea. I will update my patch.
>
How about this?
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index bf8a21d..216dee6 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -25690,6 +25690,10 @@ ix86_expand_call (rtx retval, rtx fnaddr, rtx callarg1,
fnaddr);
}
fnaddr = gen_const_mem (Pmode, fnaddr);
+ /* Pmode may not be the same as word_mode for x32, which
+ doesn't support indirect branch va 32-bit memory slot.
+ Since x32 GOT slot is 64 bit with zero upper 32 bits,
+ indirect branch via x32 GOT slot is OK. */
if (GET_MODE (fnaddr) != word_mode)
fnaddr = gen_rtx_ZERO_EXTEND (word_mode, fnaddr);
fnaddr = gen_rtx_MEM (QImode, fnaddr);
@@ -25715,7 +25719,9 @@ ix86_expand_call (rtx retval, rtx fnaddr, rtx callarg1,
&& GET_CODE (XEXP (fnaddr, 0)) == SYMBOL_REF
&& !local_symbolic_operand (XEXP (fnaddr, 0), VOIDmode))
fnaddr = gen_rtx_MEM (QImode, construct_plt_address (XEXP (fnaddr, 0)));
- else if (!(TARGET_X32
+ /* Since x32 GOT slot is 64 bit with zero upper 32 bits, indirect
+ branch via x32 GOT slot is OK. */
+ else if (!(Pmode != word_mode
&& MEM_P (fnaddr)
&& GET_CODE (XEXP (fnaddr, 0)) == ZERO_EXTEND
&& GOT_memory_operand (XEXP (XEXP (fnaddr, 0), 0), Pmode))
--
H.J.
[fortran,committed] Fix quad-prec NORM2 by creating missing decl for quad-prec BUILT_IN_SQRT
BUILT_IN_SQRT is a bit special in the Fortran front-end, because it’s part of our math built-ins which map one-to-one to Fortran intrinsics (and get special treatment for that), but it is only a built-in we call directly in the front-end when emitting code for NORM2. I didn’t realize this corner case when I first implemented quad-prec in the front-end (now several years ago!). Yet, the fix is simple. Regtested on x86_64-apple-darwin14. Fixes PR 54656 (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54656). Committed as revision 226929. sqrt_quad.diff Description: Binary data
Re: RFC: [PATCH] PR target/67215: -fno-plt needs improvements for x86
On Sun, Aug 16, 2015 at 12:24 PM, Alexander Monakov wrote:
> On Sun, 16 Aug 2015, H.J. Lu wrote:
>
>> prepare_call_address in calls.c is the wrong place to handle -fno-plt.
>> We shoudn't force function address into register and hope that load
>> function address via GOT and indirect call via register will be folded
>> into indirect call via GOT, which doesn't always happen.
>
> When the address load initially exists separately from the indirect call, the
> load can be scheduled or be subject to loop invariant motion. What is your
> reason to have them fused right from the start?
>
> In PR 67215, when you asked for an -O1 testcase, the reporter responded with a
> case that demonstrates loop invariant motion on the call address. Why should
> that be avoided? (I think it shouldn't, at least not generally)
Load it into a register avoids one load. But using a register for it
is bad for x86 which has few registers. Change
call foo@PLT
to
call *foo@GOT
to avoid one extra direct branch to PLT is always good for both x86
and x86-64.
>> Allso non-PIC
>> case can only be handled in backend. Instead, backend should expand
>> external function call into indirect call via GOT for -fno-plt.
>>
>> This patch reverts -fno-plt in prepare_call_address and handles it in
>> ix86_expand_call. Other backends may need similar changes to support
>> -fno-plt. Alternately, we can introduce a target hook to indicate
>> whether an external function should be called via register for -fno-plt
>> so that i386 backend can disable it in prepare_call_address.
>>
>> Any comments?
>
> Initially my patch was x86-only, but then I opted for the generic calls.c
> change, expecting that it would work fine in a machine-independent manner
> (which didn't work out, as ARM and AArch64 experience demonstrated). My
Nor for PR 67215 on x86.
> initial i386 backend patch was much smaller:
>
> diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
> index 3263656..cd5f246 100644
> --- a/gcc/config/i386/i386.c
> +++ b/gcc/config/i386/i386.c
> @@ -25577,15 +25578,23 @@ ix86_expand_call (rtx retval, rtx fnaddr, rtx
> callarg1,
>/* Static functions and indirect calls don't need the pic register. */
>if (flag_pic
> && (!TARGET_64BIT
> + || !flag_plt
> || (ix86_cmodel == CM_LARGE_PIC
> && DEFAULT_ABI != MS_ABI))
> && GET_CODE (XEXP (fnaddr, 0)) == SYMBOL_REF
> && ! SYMBOL_REF_LOCAL_P (XEXP (fnaddr, 0)))
> {
> - use_reg (&use, gen_rtx_REG (Pmode, REAL_PIC_OFFSET_TABLE_REGNUM));
> - if (ix86_use_pseudo_pic_reg ())
> - emit_move_insn (gen_rtx_REG (Pmode, REAL_PIC_OFFSET_TABLE_REGNUM),
> - pic_offset_table_rtx);
> + if (flag_plt)
> + {
> + use_reg (&use, gen_rtx_REG (Pmode,
> REAL_PIC_OFFSET_TABLE_REGNUM));
> + if (ix86_use_pseudo_pic_reg ())
> + emit_move_insn (gen_rtx_REG (Pmode,
> +REAL_PIC_OFFSET_TABLE_REGNUM),
> + pic_offset_table_rtx);
> + }
> + else
> + fnaddr = gen_rtx_MEM (QImode,
> + legitimize_pic_address (XEXP (fnaddr, 0),
> 0));
> }
> }
>
> (it doesn't apply to current trunk and doesn't handle all cases your patch
> handles, but at least it shows how do achieve the goal for "unfused" codegen)
But the fused indirect call is what we want for x86.
> Couple more comments on your patch below.
>
>> diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
>> index 4a0986c..bf8a21d 100644
>> --- a/gcc/config/i386/i386.c
>> +++ b/gcc/config/i386/i386.c
>> @@ -25650,21 +25650,50 @@ ix86_expand_call (rtx retval, rtx fnaddr, rtx
>> callarg1,
>>/* Static functions and indirect calls don't need the pic register.
>> Also,
>>check if PLT was explicitly avoided via no-plt or "noplt" attribute,
>> making
>>it an indirect call. */
>> + rtx addr = XEXP (fnaddr, 0);
>>if (flag_pic
>> - && (!TARGET_64BIT
>> - || (ix86_cmodel == CM_LARGE_PIC
>> - && DEFAULT_ABI != MS_ABI))
>> - && GET_CODE (XEXP (fnaddr, 0)) == SYMBOL_REF
>> - && !SYMBOL_REF_LOCAL_P (XEXP (fnaddr, 0))
>> - && flag_plt
>> - && (SYMBOL_REF_DECL ((XEXP (fnaddr, 0))) == NULL_TREE
>> - || !lookup_attribute ("noplt",
>> - DECL_ATTRIBUTES (SYMBOL_REF_DECL (XEXP (fnaddr, 0))
>> + && GET_CODE (addr) == SYMBOL_REF
>> + && !SYMBOL_REF_LOCAL_P (addr))
>> {
>> - use_reg (&use, gen_rtx_REG (Pmode, REAL_PIC_OFFSET_TABLE_REGNUM));
>> - if (ix86_use_pseudo_pic_reg ())
>> - emit_move_insn (gen_rtx_REG (Pmode, REAL_PIC_OFFSET_TABLE_REGNUM),
>> - pic_offset_table_rtx);
>> + if (flag_plt
>> + && (SYMBOL_REF_DECL (addr) == NULL_TREE
>> +
Re: RFC: [PATCH] PR target/67215: -fno-plt needs improvements for x86
On Sun, 16 Aug 2015, H.J. Lu wrote:
> prepare_call_address in calls.c is the wrong place to handle -fno-plt.
> We shoudn't force function address into register and hope that load
> function address via GOT and indirect call via register will be folded
> into indirect call via GOT, which doesn't always happen.
When the address load initially exists separately from the indirect call, the
load can be scheduled or be subject to loop invariant motion. What is your
reason to have them fused right from the start?
In PR 67215, when you asked for an -O1 testcase, the reporter responded with a
case that demonstrates loop invariant motion on the call address. Why should
that be avoided? (I think it shouldn't, at least not generally)
> Allso non-PIC
> case can only be handled in backend. Instead, backend should expand
> external function call into indirect call via GOT for -fno-plt.
>
> This patch reverts -fno-plt in prepare_call_address and handles it in
> ix86_expand_call. Other backends may need similar changes to support
> -fno-plt. Alternately, we can introduce a target hook to indicate
> whether an external function should be called via register for -fno-plt
> so that i386 backend can disable it in prepare_call_address.
>
> Any comments?
Initially my patch was x86-only, but then I opted for the generic calls.c
change, expecting that it would work fine in a machine-independent manner
(which didn't work out, as ARM and AArch64 experience demonstrated). My
initial i386 backend patch was much smaller:
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index 3263656..cd5f246 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -25577,15 +25578,23 @@ ix86_expand_call (rtx retval, rtx fnaddr, rtx
callarg1,
/* Static functions and indirect calls don't need the pic register. */
if (flag_pic
&& (!TARGET_64BIT
+ || !flag_plt
|| (ix86_cmodel == CM_LARGE_PIC
&& DEFAULT_ABI != MS_ABI))
&& GET_CODE (XEXP (fnaddr, 0)) == SYMBOL_REF
&& ! SYMBOL_REF_LOCAL_P (XEXP (fnaddr, 0)))
{
- use_reg (&use, gen_rtx_REG (Pmode, REAL_PIC_OFFSET_TABLE_REGNUM));
- if (ix86_use_pseudo_pic_reg ())
- emit_move_insn (gen_rtx_REG (Pmode, REAL_PIC_OFFSET_TABLE_REGNUM),
- pic_offset_table_rtx);
+ if (flag_plt)
+ {
+ use_reg (&use, gen_rtx_REG (Pmode, REAL_PIC_OFFSET_TABLE_REGNUM));
+ if (ix86_use_pseudo_pic_reg ())
+ emit_move_insn (gen_rtx_REG (Pmode,
+REAL_PIC_OFFSET_TABLE_REGNUM),
+ pic_offset_table_rtx);
+ }
+ else
+ fnaddr = gen_rtx_MEM (QImode,
+ legitimize_pic_address (XEXP (fnaddr, 0), 0));
}
}
(it doesn't apply to current trunk and doesn't handle all cases your patch
handles, but at least it shows how do achieve the goal for "unfused" codegen)
Couple more comments on your patch below.
> diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
> index 4a0986c..bf8a21d 100644
> --- a/gcc/config/i386/i386.c
> +++ b/gcc/config/i386/i386.c
> @@ -25650,21 +25650,50 @@ ix86_expand_call (rtx retval, rtx fnaddr, rtx
> callarg1,
>/* Static functions and indirect calls don't need the pic register.
> Also,
>check if PLT was explicitly avoided via no-plt or "noplt" attribute,
> making
>it an indirect call. */
> + rtx addr = XEXP (fnaddr, 0);
>if (flag_pic
> - && (!TARGET_64BIT
> - || (ix86_cmodel == CM_LARGE_PIC
> - && DEFAULT_ABI != MS_ABI))
> - && GET_CODE (XEXP (fnaddr, 0)) == SYMBOL_REF
> - && !SYMBOL_REF_LOCAL_P (XEXP (fnaddr, 0))
> - && flag_plt
> - && (SYMBOL_REF_DECL ((XEXP (fnaddr, 0))) == NULL_TREE
> - || !lookup_attribute ("noplt",
> - DECL_ATTRIBUTES (SYMBOL_REF_DECL (XEXP (fnaddr, 0))
> + && GET_CODE (addr) == SYMBOL_REF
> + && !SYMBOL_REF_LOCAL_P (addr))
> {
> - use_reg (&use, gen_rtx_REG (Pmode, REAL_PIC_OFFSET_TABLE_REGNUM));
> - if (ix86_use_pseudo_pic_reg ())
> - emit_move_insn (gen_rtx_REG (Pmode, REAL_PIC_OFFSET_TABLE_REGNUM),
> - pic_offset_table_rtx);
> + if (flag_plt
> + && (SYMBOL_REF_DECL (addr) == NULL_TREE
> + || !lookup_attribute ("noplt",
> + DECL_ATTRIBUTES (SYMBOL_REF_DECL
> (addr)
> + {
Under what circumstances can SYMBOL_REF_DECL be NULL here? For libcalls?
(I realize that your patch doesn't change the treatment; I just want to know)
> + if (!TARGET_64BIT
> + || (ix86_cmodel == CM_LARGE_PIC
> + && DEFAULT_ABI != MS_ABI))
> + {
> + use_reg (&use, gen_rtx_REG (Pmode,
> +
Re: arm memcpy of aligned data
On Jun 15, 2015, at 7:30 AM, Kyrill Tkachov wrote:
>
> On 29/05/15 11:15, Kyrill Tkachov wrote:
>> On 29/05/15 10:08, Kyrill Tkachov wrote:
>>> Hi Mike,
>>>
>>> On 28/05/15 22:15, Mike Stump wrote:
So, the arm memcpy code of aligned data isn’t as good as it can be.
void *memcpy(void *dest, const void *src, unsigned int n);
void foo(char *dst, int i) {
memcpy (dst, &i, sizeof (i));
}
generates horrible code, but, it we are willing to notice the src or the
destination are aligned, we can do much better:
$ ./cc1 -fschedule-fusion -fdump-tree-all-all -da -march=armv7ve
-mcpu=cortex-m4 -fomit-frame-pointer -quiet -O2 /tmp/t.c -o t.s
$ cat t.s
[ … ]
foo:
@ args = 0, pretend = 0, frame = 4
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
sub sp, sp, #4
str r1, [r0]@ unaligned
add sp, sp, #4
>>> I think there's something to do with cpu tuning here as well.
>> That being said, I do think this is a good idea.
>> I'll give it a test.
>
> The patch passes bootstrap and testing ok and I've seen it
> improve codegen in a few places in SPEC.
> I've added a testcase all marked up.
>
> Mike, I'll commit the attached patch in 24 hours unless somebody objects.
Was this ever applied?
Re: [PATCH][2/2] Make SCCVN use conditional equivalences
On Wed, Aug 12, 2015 at 7:23 AM, Richard Biener wrote: > On Wed, 12 Aug 2015, Richard Biener wrote: > >> >> This brings FRE/PRE up to the same level as DOM in being able to >> remove redundant conditionals. It does so by inserting temporary >> conditional expressions proved to be true on single predecessor >> edges. >> >> I've had to do a lot of testcase adjustments, thus the patch is >> now re-bootstrapping / testing on x86_64-unknown-linux-gnu. > > I've applied with a slight change, trimming down the number of > equivalences recorded (basically only record anything off > conditions not already optimized to go either way). > > Bootstrapped and tested on x86_64-unknown-linux-gnu, applied. > > Richard. > > 2015-08-12 Richard Biener > > * tree-ssa-sccvn.c (vn_nary_op_compute_hash): Also canonicalize > comparison operand order and commutative ternary op operand order. > (sccvn_dom_walker::cond_stack): New state to track temporary > expressions. > (sccvn_dom_walker::after_dom_children): Remove tempoary expressions > no longer valid. > (sccvn_dom_walker::record_cond): Add a single temporary conditional > expression. > (sccvn_dom_walker::record_conds): Add a temporary conditional > expressions and all related expressions also true/false. > (sccvn_dom_walker::before_dom_children): Record temporary > expressions based on the controlling condition of a single > predecessor. When trying to simplify a conditional statement > lookup expressions we might have inserted earlier. > This caused: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67241 H.J.
RFC: [PATCH] PR target/67215: -fno-plt needs improvements for x86
prepare_call_address in calls.c is the wrong place to handle -fno-plt.
We shoudn't force function address into register and hope that load
function address via GOT and indirect call via register will be folded
into indirect call via GOT, which doesn't always happen. Allso non-PIC
case can only be handled in backend. Instead, backend should expand
external function call into indirect call via GOT for -fno-plt.
This patch reverts -fno-plt in prepare_call_address and handles it in
ix86_expand_call. Other backends may need similar changes to support
-fno-plt. Alternately, we can introduce a target hook to indicate
whether an external function should be called via register for -fno-plt
so that i386 backend can disable it in prepare_call_address.
Any comments?
H.J.
--
gcc/
PR target/67215
* calls.c (prepare_call_address): Don't handle -fno-plt here.
* config/i386/i386.c (ix86_expand_call): Generate indirect call
via GOT for -fno-plt. Support indirect call via GOT for x32.
gcc/testsuite/
PR target/67215
* gcc.target/i386/pr67215-1.c: New test.
* gcc.target/i386/pr67215-2.c: Likewise.
---
gcc/calls.c | 12 --
gcc/config/i386/i386.c| 65 +++
gcc/testsuite/gcc.target/i386/pr67215-1.c | 20 ++
gcc/testsuite/gcc.target/i386/pr67215-2.c | 20 ++
4 files changed, 89 insertions(+), 28 deletions(-)
create mode 100644 gcc/testsuite/gcc.target/i386/pr67215-1.c
create mode 100644 gcc/testsuite/gcc.target/i386/pr67215-2.c
diff --git a/gcc/calls.c b/gcc/calls.c
index 5636725..7cce9be 100644
--- a/gcc/calls.c
+++ b/gcc/calls.c
@@ -203,18 +203,6 @@ prepare_call_address (tree fndecl_or_type, rtx funexp, rtx
static_chain_value,
&& targetm.small_register_classes_for_mode_p (FUNCTION_MODE))
? force_not_mem (memory_address (FUNCTION_MODE, funexp))
: memory_address (FUNCTION_MODE, funexp));
- else if (flag_pic
- && fndecl_or_type
- && TREE_CODE (fndecl_or_type) == FUNCTION_DECL
- && (!flag_plt
- || lookup_attribute ("noplt", DECL_ATTRIBUTES (fndecl_or_type)))
- && !targetm.binds_local_p (fndecl_or_type))
-{
- /* This is done only for PIC code. There is no easy interface to force
the
-function address into GOT for non-PIC case. non-PIC case needs to be
-handled specially by the backend. */
- funexp = force_reg (Pmode, funexp);
-}
else if (! sibcallp)
{
if (!NO_FUNCTION_CSE && optimize && ! flag_no_function_cse)
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index 4a0986c..bf8a21d 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -25650,21 +25650,50 @@ ix86_expand_call (rtx retval, rtx fnaddr, rtx
callarg1,
/* Static functions and indirect calls don't need the pic register.
Also,
check if PLT was explicitly avoided via no-plt or "noplt" attribute,
making
it an indirect call. */
+ rtx addr = XEXP (fnaddr, 0);
if (flag_pic
- && (!TARGET_64BIT
- || (ix86_cmodel == CM_LARGE_PIC
- && DEFAULT_ABI != MS_ABI))
- && GET_CODE (XEXP (fnaddr, 0)) == SYMBOL_REF
- && !SYMBOL_REF_LOCAL_P (XEXP (fnaddr, 0))
- && flag_plt
- && (SYMBOL_REF_DECL ((XEXP (fnaddr, 0))) == NULL_TREE
- || !lookup_attribute ("noplt",
-DECL_ATTRIBUTES (SYMBOL_REF_DECL (XEXP (fnaddr, 0))
+ && GET_CODE (addr) == SYMBOL_REF
+ && !SYMBOL_REF_LOCAL_P (addr))
{
- use_reg (&use, gen_rtx_REG (Pmode, REAL_PIC_OFFSET_TABLE_REGNUM));
- if (ix86_use_pseudo_pic_reg ())
- emit_move_insn (gen_rtx_REG (Pmode, REAL_PIC_OFFSET_TABLE_REGNUM),
- pic_offset_table_rtx);
+ if (flag_plt
+ && (SYMBOL_REF_DECL (addr) == NULL_TREE
+ || !lookup_attribute ("noplt",
+ DECL_ATTRIBUTES (SYMBOL_REF_DECL
(addr)
+ {
+ if (!TARGET_64BIT
+ || (ix86_cmodel == CM_LARGE_PIC
+ && DEFAULT_ABI != MS_ABI))
+ {
+ use_reg (&use, gen_rtx_REG (Pmode,
+ REAL_PIC_OFFSET_TABLE_REGNUM));
+ if (ix86_use_pseudo_pic_reg ())
+ emit_move_insn (gen_rtx_REG (Pmode,
+REAL_PIC_OFFSET_TABLE_REGNUM),
+ pic_offset_table_rtx);
+ }
+ }
+ else if (!TARGET_PECOFF && !TARGET_MACHO)
+ {
+ if (TARGET_64BIT)
+ {
+ fnaddr = gen_rtx_UNSPEC (Pmode,
+ gen_rtvec (1, addr),
+ UNSPEC_GOTPCREL);
+ f
New Danish PO file for 'gcc' (version 5.2.0)
Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'gcc' has been submitted by the Danish team of translators. The file is available at: http://translationproject.org/latest/gcc/da.po (This file, 'gcc-5.2.0.da.po', has just now been sent to you in a separate email.) All other PO files for your package are available in: http://translationproject.org/latest/gcc/ Please consider including all of these in your next release, whether official or a pretest. Whenever you have a new distribution with a new version number ready, containing a newer POT file, please send the URL of that distribution tarball to the address below. The tarball may be just a pretest or a snapshot, it does not even have to compile. It is just used by the translators when they need some extra translation context. The following HTML page has been updated: http://translationproject.org/domain/gcc.html If any question arises, please contact the translation coordinator. Thank you for all your work, The Translation Project robot, in the name of your translation coordinator.
Re: [PATCH] [PING] [PR libitm/61164] Remove redefinition of glibc internal macro __always_inline
On Thu, 2015-06-11 at 14:36 +0300, Gleb Fotengauer-Malinovskiy wrote: > On Fri, May 15, 2015 at 03:04:27PM +0200, Torvald Riegel wrote: > > On Wed, 2015-05-06 at 17:54 +0300, Gleb Fotengauer-Malinovskiy wrote: > > > 2015-05-06 Gleb Fotengauer-Malinovskiy > > > > > > PR libitm/61164 > > > * local_atomic (__always_inline): Rename to... > > > (__libitm_always_inline): ... this. > > > > OK. Thanks. > > You are welcome. > > It seems still not applied, AFAICS. I forgot to ask you at Cauldron whether you have completed a copyright assignment agreement? I don't think this is small enough to be a trivial patch.
[fortran,committed] Make BUILT_IN_SIGNBIT type-generic
Attached patch, committed as revision 226924, adjusts slightly the front-end’s handling of floating-point built-ins, notably making BUILT_IN_SIGNBIT type-generic. This generates better code for IEEE_IS_NEGATIVE and IEEE_COPY_SIGN functions, through direct expansion by the compiler rather than libquadmath function call signbitq(). Regtested on x86_64-apple-darwin14, covered by existing testcases in gfortran.dg/ieee/. FX PS: I figured, since few gfortran maintainers appear to be around right now, and I’m probably the one who knows that area best, I’d commit it directly rather than ask for review, even though it’s not a trivial patch. fp_builtins.diff Description: Binary data
Re: [PR64164] drop copyrename, integrate into expand
On m68k: FAIL: gcc.c-torture/execute/20050316-1.c -O0 execution test FAIL: gcc.c-torture/execute/20050316-2.c -O0 execution test FAIL: gcc.c-torture/execute/20050316-3.c -O0 execution test FAIL: gcc.c-torture/execute/simd-4.c -O0 execution test FAIL: gcc.c-torture/execute/simd-6.c -O0 execution test FAIL: gcc.dg/compat/vector-1 c_compat_x_tst.o-c_compat_y_tst.o execute --- 20050316-1.s-good +++ 20050316-1.s-bad @@ -15,8 +15,17 @@ .type test2, @function test2: link.w %fp,#0 - move.l 8(%fp),%d0 - move.l 12(%fp),%d1 + move.l 8(%fp),(%a0) + move.l 12(%fp),4(%a0) + lea (-16,%sp),%sp + move.l %sp,%d0 + addq.l #7,%d0 + lsr.l #3,%d0 + move.l %d0,%d1 + lsl.l #3,%d1 + move.l %d1,%a0 + move.l (%a0),%d0 + move.l 4(%a0),%d1 move.l %d1,%d0 unlk %fp rts @@ -37,8 +46,9 @@ .globl test4 .type test4, @function test4: - link.w %fp,#0 - move.l 8(%fp),%d0 + link.w %fp,#-4 + move.l 8(%fp),-4(%fp) + move.l -4(%fp),%d0 move.l %d0,%d1 smi %d0 extb.l %d0 @@ -54,8 +64,17 @@ .type test5, @function test5: link.w %fp,#0 - move.l 8(%fp),%a0 - move.l 12(%fp),%a1 + move.l 8(%fp),(%a0) + move.l 12(%fp),4(%a0) + lea (-16,%sp),%sp + move.l %sp,%d0 + addq.l #7,%d0 + lsr.l #3,%d0 + move.l %d0,%d1 + lsl.l #3,%d1 + move.l %d1,%a0 + move.l 4(%a0),%a1 + move.l (%a0),%a0 move.l %a0,%d0 move.l %a1,%d1 unlk %fp 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: [PR64164] drop copyrename, integrate into expand
On Aug 15, 2015, Andreas Schwab wrote: > FAIL: gcc.target/aarch64/target_attr_crypto_ice_1.c (internal compiler error) > In file included from > /opt/gcc/gcc-20150815/gcc/testsuite/gcc.target/aarch64/target_attr_crypto_ice_1.c:4:0: Are you sure this is a regression introduced by my patch? The comments at the top of this file seem to indicate it is a known problem in the expansion of the crypto builtin, which is precisely what we see in the backtrace? If it is indeed a regression, would you please provide me with a preprocessed testcase so that I can look into it without a native environment? Thanks in advance, -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer
[fortran,committed] Document behavior of I/O on symbolic links
Committed attached patch as rev. 226923 to document the behavior of gfortran
when opening & closing symbolic links.
Clearing up some of the old libgfortran PRs...
FX
Index: ChangeLog
===
--- ChangeLog (revision 226922)
+++ ChangeLog (working copy)
@@ -1,3 +1,8 @@
+2015-08-16 Francois-Xavier Coudert
+
+ PR fortran/41387
+ * gfortran.texi: New section "File operations on symbolic links".
+
2015-08-08 Francois-Xavier Coudert
PR fortran/67059
Index: gfortran.texi
===
--- gfortran.texi (revision 226894)
+++ gfortran.texi (working copy)
@@ -1140,6 +1140,7 @@ might in some way or another become visi
* Thread-safety of the runtime library::
* Data consistency and durability::
* Files opened without an explicit ACTION= specifier::
+* File operations on symbolic links::
@end menu
@@ -1345,6 +1346,33 @@ processor dependent. GNU Fortran behave
@end enumerate
+@node File operations on symbolic links
+@section File operations on symbolic links
+@cindex file, symbolic link
+
+This section documents the behavior of GNU Fortran for file operations on
+symbolic links, on systems that support them.
+
+@itemize
+
+@item Results of INQUIRE statements of the ``inquire by file'' form will
+relate to the target of the symbolic link. For example,
+@code{INQUIRE(FILE="foo",EXIST=ex)} will set @var{ex} to @var{.true.} if
+@var{foo} is a symbolic link pointing to an existing file, and @var{.false.}
+if @var{foo} points to an non-existing file (``dangling'' symbolic link).
+
+@item Using the @code{OPEN} statement with a @code{STATUS="NEW"} specifier
+on a symbolic link will result in an error condition, whether the symbolic
+link points to an existing target or is dangling.
+
+@item If a symbolic link was connected, using the @code{CLOSE} statement
+with a @code{STATUS="DELETE"} specifier will cause the symbolic link itself
+to be deleted, not its target.
+
+@end itemize
+
+
+
@c -
@c Extensions
@c -
