Re: [PATCH] microblaze: microblaze.md: Use 'SI' instead of 'VOID' for operand 1 of 'call_value_intern'
After check the details, I guess, we need: - Cross compile and install glibc with raw microblaze cross-compiler, - Then compile new microblaze cross compiler with glibc. - Then make check the new microblaze cross compiler with glibc. And it seems, we also need 'LinkScr.ld' for ldscript, could you share it to me, thanks. set_board_info ldscript -T/home/eager/Xilinx/dg/microblaze_0/LinkScr.ld At present, I am just analyzing how to cross compile microblaze glibc, welcome any ideas, suggestions or completions. Thanks. On 09/21/2014 12:41 AM, Chen Gang wrote: Thank you very much for your quickly response, I shall continue try. Thanks. On 09/21/2014 12:31 AM, Michael Eager wrote: On 09/20/14 08:52, Chen Gang wrote: Thank you very much for your attachments, it is very useful to me! I tried testsuite for microblaze cross target on x86_64 host, it says OK (echo $? == 0), but I am not quite sure about it (I still doubt that my configuration is incorrect), please help check, thanks. Welcome to the joys of DejaGNU. Configuration can be confusing. As you can see, the return code is not useful. dejagnu configuration: cp xmd.exp /usr/local/share/dejagnu/config/ cp microblaze-xilinx-gdb.exp /usr/local/share/dejagn/baseboards/ vi microblaze-xilinx-gdb.exp s/mc_gcc/microblaze\-gchen\-linux\-gcc/g gcc operation: ../gcc/configure --target=microblaze-gchen-linux --disable-nls --enable-languages=c --disable-threads --disable-shared \ --without-headers --disable-libssp --disable-libquadmath --disable-libgomp --disable-libatomic make make -k check-gcc RUNTESTFLAGS=--target_board=microblaze-xilinx-gdb/-mno-xl-soft-mul/-mxl-barrel-shift/-mcpu=v6.00.a Check whether these compiler options are being passed to mb-gcc. There is a line in my microblaze-xilinx-gdb.exp which sets CFLAGS: set_board_info cflags -mcpu=v4.00.b -mno-xl-soft-mul -mxl-barrel-shift This is likely overriding any options passed to runtest. Make sure that the options match the features of your target board. You might not need any options for your initial tests. Make sure that the correct flags are being passed to the linker. Add -v or -v -v to RUNTESTFLAGS so that the gcc.log file gives useful info. You might want to limit the number of tests run until you get problems worked out: make check-gcc RUNTESTFLAGS=execute.exp -v -v --target_board=microblaze-xilinx-gdb This will run only the gcc.c-torture/execute/execute.exp tests. gcc result: === gcc Summary === # of expected passes 48408 # of unexpected failures 17253 # of unexpected successes 1 # of expected failures97 # of unresolved testcases 16570 # of unsupported tests1854 /upstream/build-gcc/gcc/xgcc version 5.0.0 20140920 (experimental) (GCC) Look at gcc.sum and gcc.log to find out what is causing the large number of unexpected failures. A large number of unresolved test cases often means that the compiler returned an error. -- Chen Gang Open share and attitude like air water and life which God blessed
[PATCH] glibc/sysdeps/microblaze/bits/atomic.h: Avoid include recursion to cause compiling break
The related definitions are in 'atomic.h', which also need include
'lowlevellock.h', which also need the related functions in 'atomic.h'.
The related configuration:
../glibc/configure --prefix /upstream/release/ \
--target=microblaze-linux-gnu --with-headers=/upstream/release/kernel \
--host=microblaze-linux-gnu
[root@localhost build-glibc]# cat configparms
CC=/usr/local/bin/microblaze-gchen-linux-gcc
BUILD_CC=gcc
LD=/usr/local/bin/microblaze-gchen-linux-ld
NM=/usr/local/bin/microblaze-gchen-linux-nm
AS=/usr/local/bin/microblaze-gchen-linux-as
AR=/usr/local/bin/microblaze-gchen-linux-ar
RANLIB=/usr/local/bin/microblaze-gchen-linux-ranlib
The related error:
/usr/local/bin/microblaze-gchen-linux-gcc assert.c -c -std=gnu99
-fgnu89-inline -O2 -Wall -Winline -Wundef -Wwrite-strings
-fmerge-all-constants -frounding-math -g -Wstrict-prototypes
-Werror=implicit-function-declaration
-DFATAL_PREPARE_INCLUDE='fatal-prepare.h' -I../include
-I/upstream/build-glibc/assert -I/upstream/build-glibc
-I../sysdeps/unix/sysv/linux/microblaze -I../sysdeps/microblaze/nptl
-I../sysdeps/unix/sysv/linux -I../sysdeps/nptl -I../sysdeps/pthread
-I../sysdeps/gnu -I../sysdeps/unix/inet -I../sysdeps/unix/sysv
-I../sysdeps/unix -I../sysdeps/posix -I../sysdeps/microblaze
-I../sysdeps/wordsize-32 -I../sysdeps/ieee754/flt-32
-I../sysdeps/ieee754/dbl-64 -I../sysdeps/ieee754 -I../sysdeps/generic -I..
-I../libio -I. -nostdinc -isystem
/usr/lib/gcc/x86_64-redhat-linux/4.8.3/include -isystem
/upstream/release/kernel -D_LIBC_REENTRANT -include ../include/libc-symbols.h
-o /upstream/build-glibc/assert/assert.o -MD -MP -MF /upstream/build-gl
i
bc/assert/assert.o.dt -MT /upstream/build-glibc/assert/assert.o
In file included from ../nptl/descr.h:30:0,
from ../sysdeps/microblaze/nptl/tls.h:54,
from ../include/errno.h:27,
from ../sysdeps/unix/sysv/linux/microblaze/sysdep.h:27,
from ../sysdeps/microblaze/bits/atomic.h:20,
from ../include/atomic.h:50,
from assert.c:19:
../sysdeps/unix/sysv/linux/microblaze/lowlevellock.h: In function
'__lll_cond_lock':
../sysdeps/unix/sysv/linux/microblaze/lowlevellock.h:208:27: error: implicit
declaration of function 'atomic_exchange_acq'
[-Werror=implicit-function-declaration]
if (__builtin_expect (atomic_exchange_acq (futex, 2), 0))
^
../sysdeps/unix/sysv/linux/microblaze/lowlevellock.h: In function
'__lll_timedlock':
../sysdeps/unix/sysv/linux/microblaze/lowlevellock.h:226:25: error: implicit
declaration of function 'atomic_compare_and_exchange_val_acq'
[-Werror=implicit-function-declaration]
if (__builtin_expect (atomic_compare_and_exchange_val_acq (futex, 1, 0),
0) != 0)
^
../sysdeps/unix/sysv/linux/microblaze/lowlevellock.h: In function
'__lll_robust_timedlock':
../sysdeps/unix/sysv/linux/microblaze/lowlevellock.h:238:25: error: implicit
declaration of function 'atomic_compare_and_exchange_bool_acq'
[-Werror=implicit-function-declaration]
if (__builtin_expect (atomic_compare_and_exchange_bool_acq (futex, id, 0),
0))
^
cc1: some warnings being treated as errors
Signed-off-by: Chen Gang gang.chen.5...@gmail.com
---
sysdeps/microblaze/bits/atomic.h | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/sysdeps/microblaze/bits/atomic.h b/sysdeps/microblaze/bits/atomic.h
index 77004a0..c8d8d9c 100644
--- a/sysdeps/microblaze/bits/atomic.h
+++ b/sysdeps/microblaze/bits/atomic.h
@@ -17,7 +17,6 @@
http://www.gnu.org/licenses/. */
#include stdint.h
-#include sysdep.h
typedef int8_t atomic8_t;
@@ -267,3 +266,13 @@ typedef uintmax_t uatomic_max_t;
})
#define atomic_decrement(mem) ({ atomic_decrement_val (mem); (void) 0; })
+
+#define atomic_compare_and_exchange_bool_acq(mem, newval, oldval) \
+ ({ /* Cannot use __oldval here, because macros later in this file might \
+call this macro with __oldval argument. */ \
+ __typeof (oldval) __atg3_old = (oldval); \
+ atomic_compare_and_exchange_val_acq (mem, newval, __atg3_old)\
+ != __atg3_old; \
+ })
+
+#include sysdep.h
--
1.9.3
Re: [PATCH] microblaze: microblaze.md: Use 'SI' instead of 'VOID' for operand 1 of 'call_value_intern'
On 09/21/2014 02:24 PM, Chen Gang wrote: After check the details, I guess, we need: - Cross compile and install glibc with raw microblaze cross-compiler, After fix a compiling break bug for microblaze glibc, I succeed building microblaze glibc with microblaze raw cross compiler, with latest Linux upstream kernel header for microblaze (copy manually), under x86_64 host. I have sent related patch for glibc mailing list, and continue the next below, hope I can succeed. :-) thanks. - Then compile new microblaze cross compiler with glibc. - Then make check the new microblaze cross compiler with glibc. And it seems, we also need 'LinkScr.ld' for ldscript, could you share it to me, thanks. set_board_info ldscript -T/home/eager/Xilinx/dg/microblaze_0/LinkScr.ld At present, I am just analyzing how to cross compile microblaze glibc, welcome any ideas, suggestions or completions. Thanks. On 09/21/2014 12:41 AM, Chen Gang wrote: Thank you very much for your quickly response, I shall continue try. Thanks. On 09/21/2014 12:31 AM, Michael Eager wrote: On 09/20/14 08:52, Chen Gang wrote: Thank you very much for your attachments, it is very useful to me! I tried testsuite for microblaze cross target on x86_64 host, it says OK (echo $? == 0), but I am not quite sure about it (I still doubt that my configuration is incorrect), please help check, thanks. Welcome to the joys of DejaGNU. Configuration can be confusing. As you can see, the return code is not useful. dejagnu configuration: cp xmd.exp /usr/local/share/dejagnu/config/ cp microblaze-xilinx-gdb.exp /usr/local/share/dejagn/baseboards/ vi microblaze-xilinx-gdb.exp s/mc_gcc/microblaze\-gchen\-linux\-gcc/g gcc operation: ../gcc/configure --target=microblaze-gchen-linux --disable-nls --enable-languages=c --disable-threads --disable-shared \ --without-headers --disable-libssp --disable-libquadmath --disable-libgomp --disable-libatomic make make -k check-gcc RUNTESTFLAGS=--target_board=microblaze-xilinx-gdb/-mno-xl-soft-mul/-mxl-barrel-shift/-mcpu=v6.00.a Check whether these compiler options are being passed to mb-gcc. There is a line in my microblaze-xilinx-gdb.exp which sets CFLAGS: set_board_info cflags -mcpu=v4.00.b -mno-xl-soft-mul -mxl-barrel-shift This is likely overriding any options passed to runtest. Make sure that the options match the features of your target board. You might not need any options for your initial tests. Make sure that the correct flags are being passed to the linker. Add -v or -v -v to RUNTESTFLAGS so that the gcc.log file gives useful info. You might want to limit the number of tests run until you get problems worked out: make check-gcc RUNTESTFLAGS=execute.exp -v -v --target_board=microblaze-xilinx-gdb This will run only the gcc.c-torture/execute/execute.exp tests. gcc result: === gcc Summary === # of expected passes 48408 # of unexpected failures 17253 # of unexpected successes 1 # of expected failures97 # of unresolved testcases 16570 # of unsupported tests1854 /upstream/build-gcc/gcc/xgcc version 5.0.0 20140920 (experimental) (GCC) Look at gcc.sum and gcc.log to find out what is causing the large number of unexpected failures. A large number of unresolved test cases often means that the compiler returned an error. -- Chen Gang Open share and attitude like air water and life which God blessed
Re: [PATCH] Make all gcc.dg/guality/const-volatile.c subtests PASS under LTO.
On September 21, 2014 12:06:24 AM CEST, Mark Wielaard m...@redhat.com wrote:
Some subtests were reported as UNSUPPORTED when running under LTO.
That was just because the relevant variables were optimized out.
Mark those variables as used. Now const-volatile reports 192 PASS.
OK.
Ideally with early debug we can report optimized out and still print the
correct types even with LTO and no used attribute. It might be worth opening a
bug for that (if it doesn't exist already) and noting there the tests we could
fix again.
Thanks,
Richard.
gcc/testsuite/ChangeLog
* gcc.dg/guality/const-volatile.c (i): Mark as used.
(ci): Likewise.
(pci): Likewise.
(pvi): Likewise.
(pcvi): Likewise.
(cip): Likewise.
(foo): Likewise.
(cfoo): Likewise.
---
gcc/testsuite/gcc.dg/guality/const-volatile.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/gcc/testsuite/gcc.dg/guality/const-volatile.c
b/gcc/testsuite/gcc.dg/guality/const-volatile.c
index eb45ae5..d657f48 100644
--- a/gcc/testsuite/gcc.dg/guality/const-volatile.c
+++ b/gcc/testsuite/gcc.dg/guality/const-volatile.c
@@ -2,17 +2,17 @@
/* { dg-do run } */
/* { dg-options -g } */
-int i;
-const int ci;
+int i __attribute__((used));
+const int ci __attribute__((used));
volatile int vi;
const volatile int cvi;
int *pi __attribute__((used));
-const int *pci;
-volatile int *pvi;
-const volatile int *pcvi;
+const int *pci __attribute__((used));
+volatile int *pvi __attribute__((used));
+const volatile int *pcvi __attribute__((used));
-int * const cip;
+int * const cip __attribute__((used));
int * volatile vip;
int * const volatile cvip;
@@ -38,8 +38,8 @@ struct bar
};
struct bar bar __attribute__((used));
-struct foo foo;
-const struct foo cfoo;
+struct foo foo __attribute__((used));
+const struct foo cfoo __attribute__((used));
volatile struct foo vfoo;
const volatile struct foo cvfoo;
Re: [PATCH] remove duplicated lines in gcc/fortran/resolve.c
AFAICT the lines 11200-11222 in gcc/fortran/resolve.c are a copy of the lines 11176-11198. The duplicates were introduced by revision 126468, an unrelated patch, after the original commit of the code as 126466. It looks like a svn/patch mishap. The following patch removes the duplicated lines. OK for the trunk? You didn’t say if it was regtested. OK if it was (one can never be too sure!) Thanks, FX
Re: Speedup int_bit_from_pos
On September 20, 2014 6:07:52 PM CEST, Jan Hubicka hubi...@ucw.cz wrote:
On 09/19/14 22:04, Jan Hubicka wrote:
Hi,
int_bit_position is used by ipa-devirt's type walking code. It is
currently a bottleneck
since I introduced speculation into contextes (I plan to solve this
by changing the
way i cache results). But this patch seems to make sense anyway: we
do not need to go
through folding:
tree
bit_from_pos (tree offset, tree bitpos)
{
if (TREE_CODE (offset) == PLUS_EXPR)
offset = size_binop (PLUS_EXPR,
fold_convert (bitsizetype, TREE_OPERAND
(offset, 0)),
fold_convert (bitsizetype, TREE_OPERAND
(offset, 1)));
else
offset = fold_convert (bitsizetype, offset);
return size_binop (PLUS_EXPR, bitpos,
size_binop (MULT_EXPR, offset,
bitsize_unit_node));
}
Because all the code cares only about constant offsets, we do not
need to go through fold_convert,
because all the codes go via int_bit_position that already expects
result to be host wide int,
it seems to make sense to implement quick path for that.
Bootstrap/regtest x86_64 in progress, OK?
Honza
* stor-layout.c (int_bit_from_pos): New function.
* stor-layout.h (int_bit_from_pos): Declare.
* tree.c (int_bit_from_pos): Use it.
Just as a note to anyone else that peeks at this code, tree_to_shwi
will verify the nodes are constant during a checking build.
I'd consider a different name for the function that somehow
indicates the inputs are constants.
jeff
Please consider an assert or other checking code to ensure that
OFFSET and BITPOS are constants. Oh, I see that tree_to_shwi will
get that checking when it
Jeff
Yep, tree_to_shwi will check it. The old code did generic expression
folding and
called tree_to_shwi on result, so the only difference is that old code
will accept
unfolded expressions that miraculously folds into constant. I think it
is bug to
have those in IL especially on places we do not expect variable
offsets.
Based on that observation, I think we can also drop handling of
PLUS_EXPR in this case
as follows.
Concerning the function, it has documented in toplevel comment that
parameter must
be constant or it crashes, so I think it is fine. Conerning name, I am
open for renaming,
but we have those int_* variants in quite few copies, so I can do that
incrementally
(see int_byte_position and related functions in stor layout).
I am testing the following simplified (and inline) variant.
Perhaps we could do similar stuff for other int_* accessors even if
they do not
sit on hot paths in my test, just for the sake of code size.
Please omit static from inline functions.
Also one notable difference with your patches is that the fits hwi is now not
tested on the result but on the result input which, multiplied by 8, might not
fit a hwi now. So please use wide-ints here (the to_offset flavor).
Richard.
Honza
Index: tree.c
===
--- tree.c (revision 215421)
+++ tree.c (working copy)
@@ -2831,16 +2831,6 @@ bit_position (const_tree field)
return bit_from_pos (DECL_FIELD_OFFSET (field),
DECL_FIELD_BIT_OFFSET (field));
}
-
-/* Likewise, but return as an integer. It must be representable in
- that way (since it could be a signed value, we don't have the
- option of returning -1 like int_size_in_byte can. */
-
-HOST_WIDE_INT
-int_bit_position (const_tree field)
-{
- return tree_to_shwi (bit_position (field));
-}
/* Return the byte position of FIELD, in bytes from the start of the
record.
This is a tree of type sizetype. */
Index: tree.h
===
--- tree.h (revision 215421)
+++ tree.h (working copy)
@@ -3877,10 +3877,20 @@ extern tree size_in_bytes (const_tree);
extern HOST_WIDE_INT int_size_in_bytes (const_tree);
extern HOST_WIDE_INT max_int_size_in_bytes (const_tree);
extern tree bit_position (const_tree);
-extern HOST_WIDE_INT int_bit_position (const_tree);
extern tree byte_position (const_tree);
extern HOST_WIDE_INT int_byte_position (const_tree);
+/* Like bit_position, but return as an integer. It must be
representable in
+ that way (since it could be a signed value, we don't have the
+ option of returning -1 like int_size_in_byte can. */
+
+static inline HOST_WIDE_INT int_bit_position (const_tree field)
+{
+ return tree_to_shwi (DECL_FIELD_OFFSET (field)) * BITS_PER_UNIT
+ + tree_to_shwi (DECL_FIELD_BIT_OFFSET (field));
+}
+
+
#define sizetype sizetype_tab[(int) stk_sizetype]
#define bitsizetype sizetype_tab[(int) stk_bitsizetype]
#define ssizetype sizetype_tab[(int) stk_ssizetype]
Re: [PATCH, libffi, alpha]: Use FFI_ASSERT in ffi_closure_osf_inner
On Sat, Sep 20, 2014 at 12:04 PM, Anthony Green gr...@moxielogic.com wrote: [replying to an ancient post here..] Uros Bizjak ubiz...@gmail.com writes: Hello! Attached patch fixes libgo reflect test failure with libffi closures. The gccgo compiler started to use FFI closures recently; the compiler passes ffi_type_void for structures with zero members. Why not just pass an FFI_TYPE_STRUCT with zero members? ffi_call form src/alpha/ffi.c allows FFI_TYPE_VOID arguments in non-debug mode through the default: case, but ffi_closure_osf_inner aborts with this type of argument. The patch changes the default case in ffi_closure_osf_inner from abort to FFI_ASSERT, an this way synchronizes argument handling in both cases. 2014-07-21 Uros Bizjak ubiz...@gmail.com * src/alpha/ffi.c: Do not include stdlib.h. (ffi_closure_osf_inner) default: Use FFI_ASSERT instead of abort. Patch was tested with libffi testsuite on alphaev6-linux-gnu. Additionally, the patch fixed reflect test from the libgo testsuite and go.test/test/recover.go test from the gcc testsuite. Why not add an FFI_TYPE_VOID case so it doesn't ever abort if that's expected behaviour? The default case is there to catch unexpected values. The patch just equalizes handling of unknown arguments to ffi_call. Also, the approach is the same as for x86_64 and i386 - these targets doesn't abort for unknown arguments. There is no problem in adding handling of FFI_TYPE_VOID to both functions, if this is the preferred solution. Uros.
Re: [PATCH, i386, Pointer Bounds Checker 33/x] MPX ABI
On Fri, Sep 19, 2014 at 9:55 AM, Ilya Enkovich enkovich@gmail.com wrote:
Here is an updated version of this patch.
Thanks,
Ilya
--
2014-09-19 Ilya Enkovich ilya.enkov...@intel.com
* config/i386/i386.c (ix86_option_override_internal): Do not
support x32 with MPX.
is not available.
(init_cumulative_args): Init stdarg, bnd_regno, bnds_in_bt
and force_bnd_pass.
(function_arg_advance_32): Return number of used integer
registers.
(function_arg_advance_64): Likewise.
(function_arg_advance_ms_64): Likewise.
(ix86_function_arg_advance): Handle pointer bounds.
(ix86_function_arg): Likewise.
(ix86_function_value_regno_p): Mark fisrt bounds registers as
possible function value.
(ix86_function_value_1): Handle pointer bounds type/mode
(ix86_return_in_memory): Likewise.
(ix86_print_operand): Analyse insn to decide abounfbnd prefix.
(ix86_expand_call): Generate returned bounds.
(ix86_bnd_prefixed_insn_p): Check if we have instrumented call
or function.
* config/i386/i386.h (ix86_args): Add bnd_regno, bnds_in_bt,
force_bnd_pass and stdarg fields.
* config/i386/i386.md (UNSPEC_BNDRET): New.
(*call_value): Add returned bounds.
(*sibcall_value): Likewise.
(*call_value_rex64_ms_sysv): Likewise.
(*call_value_pop): Likewise.
(*sibcall_value_pop): Likewise.
* config/i386/predicates.md (call_rex64_ms_sysv_operation): Adjust
to changed call patterns.
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index 4a58190..da7ffa8 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -3712,6 +3712,9 @@ ix86_option_override_internal (bool main_args_p,
if (TARGET_X32 (opts-x_ix86_isa_flags OPTION_MASK_ISA_MPX))
error (Intel MPX does not support x32);
+ if (TARGET_X32 (ix86_isa_flags OPTION_MASK_ISA_MPX))
+error (Intel MPX does not support x32);
+
if (!strcmp (opts-x_ix86_arch_string, generic))
error (generic CPU can be used only for %stune=%s %s,
prefix, suffix, sw);
@@ -6198,10 +6201,15 @@ init_cumulative_args (CUMULATIVE_ARGS *cum, /*
Argument info to initialize */
FIXME: once typesytem is fixed, we won't need this code anymore. */
if (i i-local i-can_change_signature)
fntype = TREE_TYPE (fndecl);
+ cum-stdarg = fntype ? stdarg_p (fntype) : false;
No need for fntype check, stdarg_p already checks its argument, please
see tree.c.
cum-maybe_vaarg = (fntype
? (!prototype_p (fntype) || stdarg_p (fntype))
: !libname);
+ cum-bnd_regno = FIRST_BND_REG;
+ cum-bnds_in_bt = 0;
+ cum-force_bnd_pass = 0;
+
if (!TARGET_64BIT)
{
/* If there are variable arguments, then we won't pass anything
@@ -7136,13 +7144,17 @@ construct_container (enum machine_mode mode, enum
machine_mode orig_mode,
/* Update the data in CUM to advance over an argument of mode MODE
and data type TYPE. (TYPE is null for libcalls where that information
- may not be available.) */
+ may not be available.)
-static void
+ Return a number of integer regsiters advanced over. */
+
+static int
function_arg_advance_32 (CUMULATIVE_ARGS *cum, enum machine_mode mode,
const_tree type, HOST_WIDE_INT bytes,
HOST_WIDE_INT words)
{
+ int res = 0;
+
switch (mode)
{
default:
@@ -7160,7 +7172,8 @@ function_arg_advance_32 (CUMULATIVE_ARGS *cum, enum
machine_mode mode,
cum-words += words;
cum-nregs -= words;
cum-regno += words;
-
+ if (cum-nregs = 0)
+ res = words;
if (cum-nregs = 0)
{
cum-nregs = 0;
@@ -7231,9 +7244,11 @@ function_arg_advance_32 (CUMULATIVE_ARGS *cum, enum
machine_mode mode,
}
break;
}
+
+ return res;
}
-static void
+static int
function_arg_advance_64 (CUMULATIVE_ARGS *cum, enum machine_mode mode,
const_tree type, HOST_WIDE_INT words, bool named)
{
@@ -7242,7 +7257,7 @@ function_arg_advance_64 (CUMULATIVE_ARGS *cum, enum
machine_mode mode,
/* Unnamed 512 and 256bit vector mode parameters are passed on stack. */
if (!named (VALID_AVX512F_REG_MODE (mode)
|| VALID_AVX256_REG_MODE (mode)))
-return;
+return 0;
if (!examine_argument (mode, type, 0, int_nregs, sse_nregs)
sse_nregs = cum-sse_nregs int_nregs = cum-nregs)
@@ -7251,16 +7266,18 @@ function_arg_advance_64 (CUMULATIVE_ARGS *cum, enum
machine_mode mode,
cum-sse_nregs -= sse_nregs;
cum-regno += int_nregs;
cum-sse_regno += sse_nregs;
+ return int_nregs;
}
else
{
int align = ix86_function_arg_boundary (mode, type) / BITS_PER_WORD;
cum-words
Re: [GOOGLE] Fix LIPO COMDAT fixup and gcov-tool interactions
On 09/13/14 00:31, Teresa Johnson wrote: This patch addresses issues when running gcov-tool after performing COMDAT fixup during dyn-ipa. Functions that were previously all zero counts are marked, and the counts are discarded when being read in by gcov-tool before recalculating module groups and summary info. I'm not sure I understand the design here. A few years ago I modified the gcov data structures to cope with comdat, but failed to get the compiler side changed to utilize that (without breaking firefox builds). You'll see each function record (struct gcov_fn_info) has: const struct gcov_info *key; /* comdat key */ the intent is that that points to the gcov_info object of the object file containing the live version of the function. I couldn't quite get this to work though -- it involves emitting a function's gcov_fn_info decl in the same comdat group as the function itself. You'll see the checking of gfi_ptr-key != gi_ptr in libgcov-driver.c. Are you making use of this machinery, or inventing new machinery? nathan
Re: [Patch sh] Fixup use of constraints in define_split
On Fri, 2014-09-19 at 13:59 +0100, James Greenhalgh wrote: Hi, After https://gcc.gnu.org/ml/gcc-patches/2014-09/msg01615.html we error on the use of constraints in define_splits, define_expands and define_peephole2s. These are never looked at by the compiler, and so have no reason to be set. I expect there will be more fallout as Jan's auto-builder makes its way through ports I haven't tested, I'll fix those up as they come up. These are build failures, and the fixes are obvious, but I don't know my way around these ports, so I'd like an explicit maintainer ack. For testing, I've just checked that the build error is resolved. In principal, these are not functional changes as the constraints are not looked at. OK? OK for trunk. Cheers, Oleg
Re: Speedup int_bit_from_pos
Please omit static from inline functions. Yep, I suppose we want to drop static in all inlines? I can make patch for that. Also one notable difference with your patches is that the fits hwi is now not tested on the result but on the result input which, multiplied by 8, might not fit a hwi now. So please use wide-ints here (the to_offset flavor). The function must always suceed (so user promise it will fit in HWI) and for performance reasons I would rather not go into wide int by defualt, but I can do that with checking enabled. Honza
[PATCH, i386]: Properly generate clobbered regs in ms-sysv function call
Hello!
While reviewing MPX patches, I noticed that gcc generates clobbers in
the ms-sysv function call as part of the call insn pattern. The
documentation recommends to generate clobbers inside the expr_list,
and this is what the patch implements.
The patch further removes now unneeded specialized call patterns and
related predicate.
The following test:
--cut here--
extern void
__attribute__ ((sysv_abi))
bar (void);
void foo (void)
{
bar ();
}
--cut here--
generates exactly the same register save/restore code (when compiled
with -O2 -mabi=ms) as gcc-4.8.3 or gcc-4.9.1, the only difference is
expected:
#(call_insn:TI 5 21 40 2 (parallel [
#(call (mem:QI (symbol_ref:DI (bar) [flags 0x41]
function_decl 0x7f3899ac9000 bar) [0 bar S1 A8])
#(const_int 0 [0]))
#(unspec [
#(const_int 0 [0])
#] UNSPEC_MS_TO_SYSV_CALL)
#(clobber (reg:TI 27 xmm6))
#(clobber (reg:TI 28 xmm7))
#(clobber (reg:TI 45 xmm8))
#(clobber (reg:TI 46 xmm9))
#(clobber (reg:TI 47 xmm10))
#(clobber (reg:TI 48 xmm11))
#(clobber (reg:TI 49 xmm12))
#(clobber (reg:TI 50 xmm13))
#(clobber (reg:TI 51 xmm14))
#(clobber (reg:TI 52 xmm15))
#(clobber (reg:DI 4 si))
#(clobber (reg:DI 5 di))
#]) msabi.c:7 657 {*call_rex64_ms_sysv}
# (nil)
#(nil))
callbar# 5*call_rex64_ms_sysv[length = 6]
vs. (gcc-5.0.0):
#(call_insn:TI 5 22 41 2 (call (mem:QI (symbol_ref:DI (bar) [flags
0x41] function_decl 0x7fd08e8f26c0 bar) [0 bar S1 A8])
#(const_int 0 [0])) msabi.c:7 652 {*call}
# (expr_list:REG_CALL_DECL (symbol_ref:DI (bar) [flags 0x41]
function_decl 0x7fd08e8f26c0 bar)
#(nil))
#(expr_list (clobber (reg:TI 52 xmm15))
#(expr_list (clobber (reg:TI 51 xmm14))
#(expr_list (clobber (reg:TI 50 xmm13))
#(expr_list (clobber (reg:TI 49 xmm12))
#(expr_list (clobber (reg:TI 48 xmm11))
#(expr_list (clobber (reg:TI 47 xmm10))
#(expr_list (clobber (reg:TI 46 xmm9))
#(expr_list (clobber (reg:TI 45 xmm8))
#(expr_list (clobber (reg:TI 28 xmm7))
#(expr_list (clobber (reg:TI 27 xmm6))
#(expr_list (clobber (reg:DI 5 di))
#(expr_list (clobber
(reg:DI 4 si))
#(nil))
callbar# 5*call[length = 5]
2014-09-21 Uros Bizjak ubiz...@gmail.com
* config/i386/i386.c (ix86_expand_call): Generate MS-SYSV extra
clobbered registers using clobber_reg. Remove UNSPEC decoration.
* config/i386/i386.md (unspec) UNSPEC_MS_TO_SYSV_CALL: Remove.
(*call_rex64_ms_sysv): Remove.
(*call_value_rex64_ms_sysv): Ditto.
* config/i386/predicates.md (call_rex64_ms_sysv_operation): Remove.
testsuite/ChangeLog:
2014-09-21 Uros Bizjak ubiz...@gmail.com
* gcc.target/i386/avx-vzeroupper-16.c (dg-final): Remove check
for call_value_rex64_ms_sysv.
* gcc.target/i386/avx-vzeroupper-17.c (dg-final): Ditto.
* gcc.target/i386/avx-vzeroupper-18.c (dg-final): Remove check
for call_rex64_ms_sysv.
The patch was bootstrapped and regression tested on
x86_64-pc-linux-gnu {,-m32} and was committed to mainline SVN.
Uros.
Index: config/i386/i386.c
===
--- config/i386/i386.c (revision 215427)
+++ config/i386/i386.c (working copy)
@@ -24865,9 +24865,7 @@ ix86_expand_call (rtx retval, rtx fnaddr, rtx call
rtx callarg2,
rtx pop, bool sibcall)
{
- unsigned int const cregs_size
-= ARRAY_SIZE (x86_64_ms_sysv_extra_clobbered_registers);
- rtx vec[3 + cregs_size];
+ rtx vec[3];
rtx use = NULL, call;
unsigned int vec_len = 0;
@@ -24930,18 +24928,16 @@ ix86_expand_call (rtx retval, rtx fnaddr, rtx call
if (TARGET_64BIT_MS_ABI
(!callarg2 || INTVAL (callarg2) != -2))
{
- unsigned i;
+ int const cregs_size
+ = ARRAY_SIZE (x86_64_ms_sysv_extra_clobbered_registers);
+ int i;
- vec[vec_len++] = gen_rtx_UNSPEC (VOIDmode, gen_rtvec (1, const0_rtx),
- UNSPEC_MS_TO_SYSV_CALL);
-
for (i = 0; i cregs_size; i++)
{
int regno = x86_64_ms_sysv_extra_clobbered_registers[i];
enum machine_mode mode = SSE_REGNO_P (regno) ? TImode : DImode;
- vec[vec_len++]
- = gen_rtx_CLOBBER (VOIDmode, gen_rtx_REG (mode, regno));
+ clobber_reg (use, gen_rtx_REG (mode, regno));
}
}
Index: config/i386/i386.md
===
---
Re: [PATCH, i386, Pointer Bounds Checker 33/x] MPX ABI
On Sun, Sep 21, 2014 at 2:34 PM, Uros Bizjak ubiz...@gmail.com wrote:
On Fri, Sep 19, 2014 at 9:55 AM, Ilya Enkovich enkovich@gmail.com wrote:
Here is an updated version of this patch.
Thanks,
Ilya
--
2014-09-19 Ilya Enkovich ilya.enkov...@intel.com
* config/i386/i386.c (ix86_option_override_internal): Do not
support x32 with MPX.
is not available.
(init_cumulative_args): Init stdarg, bnd_regno, bnds_in_bt
and force_bnd_pass.
(function_arg_advance_32): Return number of used integer
registers.
(function_arg_advance_64): Likewise.
(function_arg_advance_ms_64): Likewise.
(ix86_function_arg_advance): Handle pointer bounds.
(ix86_function_arg): Likewise.
(ix86_function_value_regno_p): Mark fisrt bounds registers as
possible function value.
(ix86_function_value_1): Handle pointer bounds type/mode
(ix86_return_in_memory): Likewise.
(ix86_print_operand): Analyse insn to decide abounfbnd prefix.
(ix86_expand_call): Generate returned bounds.
(ix86_bnd_prefixed_insn_p): Check if we have instrumented call
or function.
* config/i386/i386.h (ix86_args): Add bnd_regno, bnds_in_bt,
force_bnd_pass and stdarg fields.
* config/i386/i386.md (UNSPEC_BNDRET): New.
(*call_value): Add returned bounds.
(*sibcall_value): Likewise.
(*call_value_rex64_ms_sysv): Likewise.
(*call_value_pop): Likewise.
(*sibcall_value_pop): Likewise.
* config/i386/predicates.md (call_rex64_ms_sysv_operation): Adjust
to changed call patterns.
@@ -11604,6 +11609,8 @@
[(set (match_operand 0)
(call (mem:QI (match_operand:DI 1 call_insn_operand rBwBz))
(match_operand 2)))
+ (set (reg:BND64 BND0_REG) (unspec [(reg:BND64 BND0_REG)]
UNSPEC_BNDRET))
+ (set (reg:BND64 BND1_REG) (unspec [(reg:BND64 BND1_REG)]
UNSPEC_BNDRET))
(unspec [(const_int 0)] UNSPEC_MS_TO_SYSV_CALL)])]
TARGET_64BIT !SIBLING_CALL_P (insn)
* return ix86_output_call_insn (insn, operands[1]);
This pattern has been removed [1] ...
--- a/gcc/config/i386/predicates.md
+++ b/gcc/config/i386/predicates.md
@@ -631,14 +631,17 @@
(match_code parallel)
{
unsigned creg_size = ARRAY_SIZE
(x86_64_ms_sysv_extra_clobbered_registers);
+ unsigned adop = GET_CODE (XVECEXP (op, 0, 0)) == SET
+ ? 4
+ : 2;
unsigned i;
- if ((unsigned) XVECLEN (op, 0) != creg_size + 2)
+ if ((unsigned) XVECLEN (op, 0) != creg_size + adop)
return false;
for (i = 0; i creg_size; i++)
{
- rtx elt = XVECEXP (op, 0, i+2);
+ rtx elt = XVECEXP (op, 0, i+adop);
enum machine_mode mode;
unsigned regno;
... and the part above has been killed as well.
[1] https://gcc.gnu.org/ml/gcc-patches/2014-09/msg01739.html
Uros.
Re: [PATCH, i386, Pointer Bounds Checker 34/x] Vararg functions support
Hello!
This patch introduces initialization of incoming bounds for vararg function
on i386 target.
Bootstrapped and tested on linux-x86_64.
Thanks,
Ilya
--
gcc/
2014-06-11 Ilya Enkovich ilya.enkov...@intel.com
* config/i386/i386.c (ix86_setup_incoming_varargs): New.
(ix86_va_start): Initialize bounds for pointers in va_list.
(TARGET_SETUP_INCOMING_VARARG_BOUNDS): New.
OK with a couple of smallchanges below.
Thanks,
Uros.
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index a67e6e7..c520f26 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -8456,6 +8456,72 @@ ix86_setup_incoming_varargs (cumulative_args_t cum_v,
enum machine_mode mode,
setup_incoming_varargs_64 (next_cum);
}
+static void
+ix86_setup_incoming_vararg_bounds (cumulative_args_t cum_v,
+ enum machine_mode mode,
+ tree type,
+ int *pretend_size ATTRIBUTE_UNUSED,
+ int no_rtl)
+{
+ CUMULATIVE_ARGS *cum = get_cumulative_args (cum_v);
+ CUMULATIVE_ARGS next_cum;
+ tree fntype;
+ rtx save_area;
+ int bnd_reg, i, max;
+
+ gcc_assert (!no_rtl);
+
Please add a comment for following condition.
+ if (!TARGET_64BIT)
+return;
+
+ fntype = TREE_TYPE (current_function_decl);
+
+ /* For varargs, we do not want to skip the dummy va_dcl argument.
+ For stdargs, we do want to skip the last named argument. */
+ next_cum = *cum;
+ if (stdarg_p (fntype))
+ix86_function_arg_advance (pack_cumulative_args (next_cum), mode, type,
+ true);
+ if (cum-call_abi == MS_ABI)
+return;
Put this early exit at the top of the function.
+ save_area = frame_pointer_rtx;
+
+ max = cum-regno + cfun-va_list_gpr_size / UNITS_PER_WORD;
+ if (max X86_64_REGPARM_MAX)
+max = X86_64_REGPARM_MAX;
+
+ bnd_reg = cum-bnd_regno + cum-force_bnd_pass;
+ if (chkp_function_instrumented_p (current_function_decl))
+for (i = cum-regno; i max; i++)
+ {
+ rtx addr = plus_constant (Pmode, save_area, i * UNITS_PER_WORD);
+ rtx reg = gen_rtx_REG (DImode,
+ x86_64_int_parameter_registers[i]);
+ rtx ptr = reg;
+ rtx bounds;
+
+ if (bnd_reg = LAST_BND_REG)
+ bounds = gen_rtx_REG (BNDmode, bnd_reg);
+ else
+ {
+ rtx ldx_addr = plus_constant (Pmode, arg_pointer_rtx,
+ (LAST_BND_REG - bnd_reg) * 8);
No magic constants!
+ bounds = gen_reg_rtx (BNDmode);
+ emit_insn (TARGET_64BIT
+ ? gen_bnd64_ldx (bounds, ldx_addr, ptr)
+ : gen_bnd32_ldx (bounds, ldx_addr, ptr));
+ }
+
+ emit_insn (TARGET_64BIT
+ ? gen_bnd64_stx (addr, ptr, bounds)
+ : gen_bnd32_stx (addr, ptr, bounds));
Please check BNDmode instead of TARGET_64BIT.
+ bnd_reg++;
+ }
+}
+
+
/* Checks if TYPE is of kind va_list char *. */
static bool
@@ -8478,7 +8544,7 @@ ix86_va_start (tree valist, rtx nextarg)
{
HOST_WIDE_INT words, n_gpr, n_fpr;
tree f_gpr, f_fpr, f_ovf, f_sav;
- tree gpr, fpr, ovf, sav, t;
+ tree gpr, fpr, ovf, sav, t, t1;
tree type;
rtx ovf_rtx;
@@ -8529,6 +8595,13 @@ ix86_va_start (tree valist, rtx nextarg)
crtl-args.arg_offset_rtx,
NULL_RTX, 0, OPTAB_LIB_WIDEN);
convert_move (va_r, next, 0);
+
+ /* Store zero bounds for va_list. */
+ if (chkp_function_instrumented_p (current_function_decl))
+ chkp_expand_bounds_reset_for_mem (valist,
+ make_tree (TREE_TYPE (valist),
+next));
+
}
return;
}
@@ -8582,10 +8655,15 @@ ix86_va_start (tree valist, rtx nextarg)
t = make_tree (type, ovf_rtx);
if (words != 0)
t = fold_build_pointer_plus_hwi (t, words * UNITS_PER_WORD);
+ t1 = t;
t = build2 (MODIFY_EXPR, type, ovf, t);
TREE_SIDE_EFFECTS (t) = 1;
expand_expr (t, const0_rtx, VOIDmode, EXPAND_NORMAL);
+ /* Store zero bounds for overflow area pointer. */
+ if (chkp_function_instrumented_p (current_function_decl))
+chkp_expand_bounds_reset_for_mem (ovf, t1);
Can you please move this above to avoid another temporary (t1)?
if (ix86_varargs_gpr_size || ix86_varargs_fpr_size)
{
/* Find the register save area.
@@ -8594,9 +8672,14 @@ ix86_va_start (tree valist, rtx nextarg)
t = make_tree (type, frame_pointer_rtx);
if (!ix86_varargs_gpr_size)
t = fold_build_pointer_plus_hwi (t, -8 * X86_64_REGPARM_MAX);
+ t1 = t;
t = build2 (MODIFY_EXPR, type, sav, t);
TREE_SIDE_EFFECTS (t) = 1;
Re: [PATCH 1/9] rs6000: Change how we model the carry bit
On Sat, Sep 20, 2014 at 2:23 PM, Segher Boessenkool seg...@kernel.crashing.org wrote: Make the carry bit non-allocatable (i.e., of class NO_REGS). It will only ever be assigned to explicitly by machine patterns. Let it have mode SI or DI (if compiling for 64-bit), even though it only ever contains 0 or 1, so that the patterns will be simpler, and combine will have an easier time and more opportunities. Do not allow CA as input_operand; we have no patterns for moving CA around (such patterns would be quite expensive). Allow taking a subreg of CA; this happens e.g. for sraw in 64-bit mode. 2014-09-20 Segher Boessenkool seg...@kernel.crashing.org * config/rs6000/predicates.md (ca_operand): Allow subregs. (input_operand): Do not allow ca_operand. * config/rs6000/rs6000.c (rs6000_hard_regno_mode_ok): For the carry bit, allow SImode and Pmode. (rs6000_init_hard_regno_mode_ok): Make the carry bit class NO_REGS. Okay. Thanks, David
Re: [PATCH 2/9] rs6000: Handle rtx cost of NE
On Sat, Sep 20, 2014 at 2:23 PM, Segher Boessenkool seg...@kernel.crashing.org wrote: Currently NE isn't handled at all. Handle it the same as EQ, LTU, GTU. 2014-09-20 Segher Boessenkool seg...@kernel.crashing.org * config/rs6000/rs6000.c (rs6000_rtx_costs) NE: New. Okay. Thanks, David
Re: [PATCH 3/9] rs6000: Clean up one_cmplmode2
On Sat, Sep 20, 2014 at 2:23 PM, Segher Boessenkool seg...@kernel.crashing.org wrote: Just the usual tidying. Also use the not extended mnemonic instead of the nor that translates to. 2014-09-20 Segher Boessenkool seg...@kernel.crashing.org * config/rs6000/rs6000.md (*one_cmplmode2): Generate not insn. (two anonymous define_insn and two define_split): Delete. (*one_cmplmode2_dot, *one_cmplmode2_dot2): New. Okay. Thanks, David
Re: [PATCH 5/9] rs6000: Clean up boolmode3
On Sat, Sep 20, 2014 at 2:23 PM, Segher Boessenkool seg...@kernel.crashing.org wrote: Use a new code iterator to handle IOR, XOR. Also, we can now fold the AND patterns together with the boolean_or_operator patterns. 2014-09-20 Segher Boessenkool seg...@kernel.crashing.org * config/rs6000/rs6000.md (iorxor): New code_iterator. (iorxor): New code_attr. (IORXOR): New code_attr. (*andmode3, *andmode3_dot, *andmode3_dot2): Delete. (iormode3, xormode3): Delete. (iorxormode3): New. (splitter for big integer ior, xor): New. (*boolmode3): Move. Also handle AND. (*boolmode3_dot, *boolmode3_dot2): Also handle AND. (splitter for big integer ior, xor): Delete. Okay. Thanks, David
Re: [PATCH 4/9] rs6000: Clean up negmode2
On Sat, Sep 20, 2014 at 2:23 PM, Segher Boessenkool seg...@kernel.crashing.org wrote: 2014-09-20 Segher Boessenkool seg...@kernel.crashing.org * config/rs6000/rs6000.md (*negmode2_internal): Delete. (two anonymous define_insn and two define_split): Delete. (*negmode2, *negmode2_dot, *negmode2_dot2): New. Okay. Thanks, David
Re: [PATCH 6/9] rs6000: Clean up submode3
On Sat, Sep 20, 2014 at 2:23 PM, Segher Boessenkool seg...@kernel.crashing.org wrote: The instruction patterns are now called subf, with the corresponding operand order, to be less confusing. I tried using the sub extended mnemonics instead but that only made things way, way worse. Do not allow an integer as second operand of submode3; expand doesn't use it. Only strlensi used it, fix that. For an integer first operand, now use a separate insn submode3_imm, which clobbers the carry (it is subfic after all). ctz, ffz, plus_ltu, plus_gtu need changes for that (the latter two will be removed later). 2014-09-20 Segher Boessenkool seg...@kernel.crashing.org * config/rs6000/rs6000.md (strlensi): Don't use subsi3 with a constant, use addsi3 directly. (three anonymous define_insn, two define_split): Delete. (submode3): Move. Do not allow constant second operand. Generate different insn for constant first operand. (*subfmode3, *subfmode3_dot, *subfmode3_dot2): New. (subfmode3_imm): New. (ctzmode2, ffsmode2): Clobber CA_REGNO where required. (*plus_ltumode): Only handle registers. (*plus_ltumode_1): New. Handle integer third operand. (*plus_gtumode): Only handle registers. (*plus_gtumode_1): New. Handle integer third operand. Okay. Thanks, David
Re: [PATCH 7/9] rs6000: Clean up ctz, ffs, popcount, parity
On Sat, Sep 20, 2014 at 2:23 PM, Segher Boessenkool seg...@kernel.crashing.org wrote: 2014-09-20 Segher Boessenkool seg...@kernel.crashing.org * config/rs6000/rs6000.md (ctzmode2, ffsmode2, popcountmode2, popcntbmode2, popcntdmode2, paritymode2, paritymode2_cmpb): Tidy. Okay. Thanks, David
Re: [PATCH 8/9] rs6000: Clean up sra[wd]
On Sat, Sep 20, 2014 at 2:23 PM, Segher Boessenkool seg...@kernel.crashing.org wrote: 2014-09-20 Segher Boessenkool seg...@kernel.crashing.org * config/rs6000/rs6000.md (ashrmode3, *ashrmode3, *ashrsi3_64, *ashrmode3_dot, *ashrmode3_dot2): Clobber CA_REGNO. (floatdisf2_internal2): Ditto. (ashrdi3_no_power): Ditto. Fix formatting. Okay. Thanks, David
Re: [PATCH 9/9] rs6000: Clean up sra[wd]i;addze
On Sat, Sep 20, 2014 at 2:23 PM, Segher Boessenkool seg...@kernel.crashing.org wrote: Also change type compare to two for the dot forms. 2014-09-20 Segher Boessenkool seg...@kernel.crashing.org * config/rs6000/rs6000.md (divmode3): Fix comment. Use a different insn for divides by integer powers of two. (divmode3_sra, *divmode3_sra_dot, *divmode3_sra_dot2): New. (modmode3): Fix formatting. (three anonymous define_insn and two define_split): Delete. Okay. Thanks, David
Re: [GOOGLE] Fix LIPO COMDAT fixup and gcov-tool interactions
On Sun, Sep 21, 2014 at 5:48 AM, Nathan Sidwell nat...@acm.org wrote: On 09/13/14 00:31, Teresa Johnson wrote: This patch addresses issues when running gcov-tool after performing COMDAT fixup during dyn-ipa. Functions that were previously all zero counts are marked, and the counts are discarded when being read in by gcov-tool before recalculating module groups and summary info. I'm not sure I understand the design here. A few years ago I modified the gcov data structures to cope with comdat, but failed to get the compiler side changed to utilize that (without breaking firefox builds). You'll see each function record (struct gcov_fn_info) has: const struct gcov_info *key; /* comdat key */ the intent is that that points to the gcov_info object of the object file containing the live version of the function. I couldn't quite get this to work though -- it involves emitting a function's gcov_fn_info decl in the same comdat group as the function itself. Another problem is that comdat functions may have different CFGs due to different early inline decisions. Comdatting gcov counters can lead to problems in profile use. Not comdatting profile counters have another advantage -- it allows context sensitive profiling for comdat function inline instances (IPA-inline). You'll see the checking of gfi_ptr-key != gi_ptr in libgcov-driver.c. Are you making use of this machinery, or inventing new machinery? Teresa's method is a different machinery -- it tries to propagate profile data from the selected comdat copy + inline instance copies to comdat copies with zero counts. David nathan
Re: [PATCH] microblaze: microblaze.md: Use 'SI' instead of 'VOID' for operand 1 of 'call_value_intern'
On 09/20/14 23:24, Chen Gang wrote: And it seems, we also need 'LinkScr.ld' for ldscript, could you share it to me, thanks. set_board_info ldscript -T/home/eager/Xilinx/dg/microblaze_0/LinkScr.ld Hi Chen -- The DejaGNU configuration I provided is for a bare-metal environment. If you are testing in a Linux environment, the tool chain you uses should provide a default linker script which matches your hardware's memory layout. You should not need to provide a separate linker script. -- Michael Eagerea...@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: [Patch, AArch64] Enable Address sanitizer and UB sanitizer
On 17 September 2014 12:48, Marcus Shawcroft marcus.shawcr...@gmail.com wrote:
On 9 September 2014 13:08, Christophe Lyon christophe.l...@linaro.org wrote:
On 9 September 2014 12:03, pins...@gmail.com wrote:
On Sep 9, 2014, at 2:50 AM, Marcus Shawcroft marcus.shawcr...@gmail.com
wrote:
+static unsigned HOST_WIDE_INT
+aarch64_asan_shadow_offset (void)
+{
+ return (HOST_WIDE_INT_1 36);
+}
+
Looking around various other ports I see magic numbers including 29,
41, 44 Help me understand why 36 is the right choice for aarch64?
Also why 36? What is the min virtual address space aarch64 Linux kernel
supports with 4k pages and 3 level page table? Also does this need to
conditionalized on lp64? Since I am about to post glibc patches turning on
address sanitizer breaks that.
The address space is 2^39 according to /proc/self/maps:
[...]
The shadow offset is obtained by dividing this value by 8 - 2^36.
Note that this value has to match kAArch64_ShadowOffset64 as defined
in libsanitizer/asan/asan_mapping.h.
I do expect a followup patch to support ilp32, but I wouldn't post a
patch which I haven't tested.
Presumably for ILP32 the shadow offset should be 129 and we will
need to make both asan_mapping.h and aarch64_asan_shadow_offset
conditional.
Indeed. We'll do that once Andrew has committed all his IPL32 patches (glibc).
This patch for LP64 is OK.
I will commit it once the libsanitizer runtime has been updated to at
least r209641 otherwise GCC will fail to build for AArch64.
Thanks
/Marcus
Re: [PATCH] microblaze: microblaze.md: Use 'SI' instead of 'VOID' for operand 1 of 'call_value_intern'
On 09/21/14 03:46, Chen Gang wrote: Excuse me, I want to consult one thing: I installed raw microblaze cross compiler, binutils and glibc into one directory (/upstream/release), and try to build a Hello world C program for microblaze under x86_64 host. I guess it is OK, but I am not quite sure about it (I use raw compiler, and have to point out /upstream/release/lib/ld.so.1 explicitly, and receive a warning related with 'ld'). Is it really OK? can I still use raw compiler for our testsuite? Is 'LinkScr.ld' for ldscript related with current case? [root@localhost test]# /upstream/release/bin/microblaze-gchen-linux-gcc -nostdinc -c -o test.o test.c [root@localhost test]# /upstream/release/bin/microblaze-gchen-linux-ld -o test test.o /upstream/release/lib/ld.so.1 -lc -L/upstream/release/lib /upstream/release/bin/microblaze-gchen-linux-ld: warning: cannot find entry symbol _start; defaulting to 1180 Generally, you should use gcc to link programs, not ld. gcc is a driver which will select the appropriate libraries and support routines (such as crt0.o, which contains _start) and pass them to the linker. -- Michael Eagerea...@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: [patch] libstdc++/29988 Rb_Tree reuse allocated nodes
On 30/07/14 23:39 +0200, François Dumont wrote:
On 16/06/2014 22:23, François Dumont wrote:
Hi
Here is another proposal taking into account your remarks except
the one below.
In fact I had no problem with lambda, I just needed to store them
in a variable, lambda do not need to be made mutable.
You could also change _M_copy's _NodeGen parameter to _NodeGen for
C++11 mode, then you don't need to use lvalues for the lambdas. I
looks as though _M_copy is the only function affected, as the other
functions with a _NodeGen template parameter are passed lvalues
anyway.
That's not important though, just passing lvalues works OK too.
On 11/06/2014 14:02, Jonathan Wakely wrote:
@@ -514,11 +651,11 @@
{ return this-_M_impl._M_header._M_right; }
_Link_type
- _M_begin() _GLIBCXX_NOEXCEPT
+ _M_begin() const _GLIBCXX_NOEXCEPT
{ return
static_cast_Link_type(this-_M_impl._M_header._M_parent); }
What's the purpose of this change?
Although it can be 'const' it is consistent with the usual
begin()/end() functions that the functions returning a mutable iterator
are non-const and the functions returning a constant iterator are const.
I'm still concerned about this part, especially as _M_end() isn't made
const!
_Const_Link_type
- _M_begin() const _GLIBCXX_NOEXCEPT
+ _M_cbegin() const _GLIBCXX_NOEXCEPT
{
return static_cast_Const_Link_type
(this-_M_impl._M_header._M_parent);
@@ -529,7 +666,7 @@
{ return
reinterpret_cast_Link_type(this-_M_impl._M_header); }
_Const_Link_type
- _M_end() const _GLIBCXX_NOEXCEPT
+ _M_cend() const _GLIBCXX_NOEXCEPT
{ return
reinterpret_cast_Const_Link_type(this-_M_impl._M_header); }
static const_reference
I'm not very comfortable with this renaming.
Having consistent _M_begin() functions allows using them in template
code that doesn't care if it's using the const or non-const version.
I try to revert this part and so remember why I did it in the first
place.
I needed to change _M_copy signature to:
_Link_type
_M_copy(_Link_type __x, _Link_type __p)
because I now use this method to also move the elements of the
data structure, I cannot move from a _Const_Like_type so I change
first parameter to _Link_type. I see that there are some code
duplications to deal with _Const_Link_type and _Link_type in 2
different part of the code but I didn't want to duplicate again here
and simply made _M_copy more flexible by taking a _Link_type rather
than a _Const_Link_type.
I don't really see interest of the existing code duplications so I
prefer to not do the same and write the code only once.
There are alternatives to duplicating the code. _M_copy could be:
templatetypename _Ptr, typename _NodeGen
_Link_type
_M_copy(_Ptr, _Link_type, _NodeGen);
I've been experimenting with a patch that does this instead:
_M_root() = _M_copy(__x._M_begin(), _M_end(),
[__an](const value_type __val) {
auto __nc_val = const_castvalue_type(__val);
return __an(std::move_if_noexcept(__nc_val));
});
I'm not very happy about having to use a const_cast, but then I'm also
not very happy having a function called _M_copy which takes a
non-const pointer because it might alter the thing it's copying.
At least with the const_cast the _M_copy function is logically doing a
non-modifying copy, but the caller can decide to pass in a lambda that
moves instead of copying, if it knows that it's OK to modify the
source object (because it's known to have been an rvalue).
protected:
- templatetypename _Key_compare,
- bool _Is_pod_comparator = __is_pod(_Key_compare)
+ templatetypename _Key_compare
struct _Rb_tree_impl : public _Node_allocator
I don't think we should remove this parameter, it alters the mangled
name for _Rb_tree_impl symbols, which means users can get two
different symbols in their program and the linker will keep both.
It's redundant, but doesn't actually cause any harm. Maybe just rename
the parameter to _Unused or something, but leave it there, with the
same default argument.
Profile mode maintenance patch
Hi Here is the promise major patch for the profile mode. Here are the most important modifications. Now instance of profiling structs are kept as pointers in the containers themselves. It has an impact on the container ABI but it greatly enhance performances as we do not need to move through a search in an unordered container which also imply a lock during this research. I have even been able to remove those unordered containers eventually just keeping a counter of allocated bytes to know if we should stop creating new profiling structs. I get rid of the re-entrancy mechanism. The only reason for it was a potential hook in the memory allocator potentially creating new profiling structs and so long forever. I prefer to put it just where it is necessary that is to say when we first allocate memory for profiling which is then we create the back-trace. I wonder if we shouldn't emit a #error when trying to activate profiling mode without backtrace feature cause in this case we simply won't collect anything. I finalize ordered to unordered profiling by adding the missing __iterator_tracker on the ordered containers (map, multimap, set, multiset). I clean all useless stuff like __stack_info_base class. I fixed many memory leak and added a cleanup at exit of the application. Profiling of containers is reseted as soon as one of the following operations occur: copy assignment, move assignment, initialization from an initialization list, clear. I have added usage of atomic operations to maintain some counters that might be updated from different threads. Do not hesitate to review those closely. Especially __objects_byte_size which I am using in profiler_trace.h without atomic operation, is it fine ? With all those modifications I have been able to run all testsuite in profile mode with success. Ok to commit ? François profile.patch.bz2 Description: application/bzip
Re: [Bug libstdc++/62313] Data race in debug iterators
On 10/09/14 22:55 +0200, François Dumont wrote:
Hi
Here is a proposal to fix this data race issue.
I finally generalized bitset approach to fix it by inheriting from
the normal iterator first and then the _Safe_iterator_base type. None
of the libstdc++ iterator types are final so it is fine. Surprisingly,
despite inheritance being private gcc got confused between
_Safe_iterator_base _M_next and forward_list _M_next so I need to
adapt some code to make usage of _Safe_iterator_base _M_next explicit.
Access control in C++ is not related to visibility, name lookup still
finds private members, but it is an error to use them.
I also consider any operator where normal iterator is being
modified while the safe iterator is linked to the list of iterators.
This is necessary to make sure that thread sanatizer won't consider a
race condition. I didn't touch to bitset::reference because list
references are only access on bitset destruction which is clearly not
an operation allowed to do while playing with references in another
thread.
Do you see any way to check for this problem in the testsuite ? Is
there a thread sanitizer we could use ?
GCC's -fsanitize=thread option, although using it in the testsuite
would need something like dg-require-tsan so the test doesn't run on
platforms where it doesn't work, or if GCC was built without
libsanitizer.
Have you run some tests using -fsanitize=thread, even if they are not
in the testsuite?
Index: include/debug/safe_iterator.h
===
--- include/debug/safe_iterator.h (revision 215134)
+++ include/debug/safe_iterator.h (working copy)
@@ -109,16 +109,21 @@
* %_Safe_iterator has member functions for iterator invalidation,
* attaching/detaching the iterator from sequences, and querying
* the iterator's state.
+ *
+ * Note that _Iterator must rely first in the type memory layout so that it
I can't parse this ... maybe _Iterator must be the first base class ?
+ * gets initialized before the iterator is being attached to the container
s/container/container's/
+ * list of iterators and it is being dettached before _Iterator get
s/dettached/detached/
+ * destroy. Otherwise it would result in a data race.
s/destroy/destroyed/
*/
templatetypename _Iterator, typename _Sequence
-class _Safe_iterator : public _Safe_iterator_base
+class _Safe_iterator
+: private _Iterator,
+ public _Safe_iterator_base
{
- typedef _Safe_iterator _Self;
+ typedef _Iterator _Ite_base;
Please rename this to _Iter_base, iter is a more conventional
abbreviation than ite
@@ -388,28 +433,27 @@
/**
* @brief Return the underlying iterator
*/
- _Iterator
- base() const _GLIBCXX_NOEXCEPT { return _M_current; }
+ _Iterator
+ base() _GLIBCXX_NOEXCEPT { return *this; }
+ const _Iterator
+ base() const _GLIBCXX_NOEXCEPT { return *this; }
I suppose base() doesn't need to be uglified to _M_base, because all
the containers already use std::reverse_iterator which uses the name
base.
Index: include/debug/safe_local_iterator.h
===
--- include/debug/safe_local_iterator.h (revision 215134)
+++ include/debug/safe_local_iterator.h (working copy)
@@ -49,15 +49,15 @@
* the iterator's state.
*/
templatetypename _Iterator, typename _Sequence
-class _Safe_local_iterator : public _Safe_local_iterator_base
+class _Safe_local_iterator
+: private _Iterator
+, public _Safe_local_iterator_base
{
- typedef _Safe_local_iterator _Self;
+ typedef _Iterator _Ite_base;
Same renaming here please, to _Iter_base.
Apart from those minor adjustments I think this looks good, but I'd
like to know that it has been tested with -fsanitize=thread, even if
only lightly tested.
Re: [RFA 2/2]: --enable-explicit-exception-frame-registration compatibility option
From: Jeff Law l...@redhat.com
Date: Fri, 19 Sep 2014 08:29:16 +0200
On 09/12/14 11:51, Hans-Peter Nilsson wrote:
Ping! http://gcc.gnu.org/ml/gcc-patches/2014-09/msg00403.html
libgcc:
* crtstuff.c [EH_FRAME_SECTION_NAME !USE_PT_GNU_EH_FRAME]:
Sanity-check USE_EH_FRAME_REGISTRY_ALWAYS against
EH_FRAME_SECTION_NAME, emit error if unsane.
(USE_EH_FRAME_REGISTRY): Let USE_EH_FRAME_REGISTRY_ALWAYS
override USE_PT_GNU_EH_FRAME.
* Makefile.in (FORCE_EXPLICIT_EH_REGISTRY): New
variable for substituted force_explicit_eh_registry.
(CRTSTUFF_CFLAGS): Add FORCE_EXPLICIT_EH_REGISTRY.
* configure.ac (explicit-exception-frame-registration):
New AC_ARG_ENABLE.
* configure: Regenerate.
OK.
jeff
Thanks! JFTR, here's the boring rebase needed as per jsm28's
s/EH_FRAME_SECTION_NAME/_LIBGCC_EH_FRAME_SECTION_NAME_/g.
I started a native build on x86_64-linux and
--explicit-exception-frame-registration with this patch and
observed it build the first-stage libstdc++.so and inspected the
result and crtbegin.o as a sanity-check, as I can't trust myself
not to typo. :)
libgcc:
* crtstuff.c (USE_EH_FRAME_REGISTRY): Let USE_EH_FRAME_REGISTRY_ALWAYS
override USE_PT_GNU_EH_FRAME.
[__LIBGCC_EH_FRAME_SECTION_NAME__ !USE_PT_GNU_EH_FRAME]: Sanity-
check USE_EH_FRAME_REGISTRY_ALWAYS against
__LIBGCC_EH_FRAME_SECTION_NAME__, emit error if unsane.
* Makefile.in (FORCE_EXPLICIT_EH_REGISTRY): New
variable for substituted force_explicit_eh_registry.
(CRTSTUFF_CFLAGS): Add FORCE_EXPLICIT_EH_REGISTRY.
* configure.ac (explicit-exception-frame-registration):
New AC_ARG_ENABLE.
* configure: Regenerate.
Index: libgcc/Makefile.in
===
--- libgcc/Makefile.in (revision 215439)
+++ libgcc/Makefile.in (working copy)
@@ -50,6 +50,8 @@ target_noncanonical = @target_noncanonic
# The rules for compiling them should be in the t-* file for the machine.
EXTRA_PARTS = @extra_parts@
+FORCE_EXPLICIT_EH_REGISTRY = @force_explicit_eh_registry@
+
extra-parts = libgcc-extra-parts
# Multilib support variables.
@@ -283,7 +285,7 @@ INTERNAL_CFLAGS = $(CFLAGS) $(LIBGCC2_CF
CRTSTUFF_CFLAGS = -O2 $(GCC_CFLAGS) $(INCLUDES) $(MULTILIB_CFLAGS) -g0 \
-finhibit-size-directive -fno-inline -fno-exceptions \
-fno-zero-initialized-in-bss -fno-toplevel-reorder -fno-tree-vectorize \
- -fbuilding-libgcc -fno-stack-protector \
+ -fbuilding-libgcc -fno-stack-protector $(FORCE_EXPLICIT_EH_REGISTRY) \
$(INHIBIT_LIBC_CFLAGS)
# Extra flags to use when compiling crt{begin,end}.o.
Index: libgcc/configure.ac
===
--- libgcc/configure.ac (revision 215439)
+++ libgcc/configure.ac (working copy)
@@ -262,6 +262,22 @@ no)
;;
esac
+AC_ARG_ENABLE([explicit-exception-frame-registration],
+ [AC_HELP_STRING([--enable-explicit-exception-frame-registration],
+ [register exception tables explicitly at module start, for use
+ e.g. for compatibility with installations without PT_GNU_EH_FRAME
support])],
+[
+force_explicit_eh_registry=
+if test $enable_explicit_exception_frame_registration = yes; then
+ if test $enable_sjlj_exceptions = yes; then
+AC_MSG_ERROR([Can't enable both of --enable-sjlj-exceptions
+ and --enable-explicit-exception-frame-registration])
+ fi
+ force_explicit_eh_registry=-DUSE_EH_FRAME_REGISTRY_ALWAYS
+fi
+])
+AC_SUBST([force_explicit_eh_registry])
+
AC_LIB_PROG_LD_GNU
AC_MSG_CHECKING([for thread model used by GCC])
Index: libgcc/crtstuff.c
===
--- libgcc/crtstuff.c (revision 215439)
+++ libgcc/crtstuff.c (working copy)
@@ -131,7 +131,12 @@ call_ ## FUNC (void)
\
# define USE_PT_GNU_EH_FRAME
#endif
-#if defined(__LIBGCC_EH_FRAME_SECTION_NAME__) !defined(USE_PT_GNU_EH_FRAME)
+#ifdef USE_EH_FRAME_REGISTRY_ALWAYS
+# ifndef __LIBGCC_EH_FRAME_SECTION_NAME__
+# error Can't use explicit exception-frame-registration without
__LIBGCC_EH_FRAME_SECTION_NAME__
+# endif
+#endif
+#if defined(__LIBGCC_EH_FRAME_SECTION_NAME__)
(!defined(USE_PT_GNU_EH_FRAME) || defined(USE_EH_FRAME_REGISTRY_ALWAYS))
# define USE_EH_FRAME_REGISTRY
#endif
#if defined(__LIBGCC_EH_FRAME_SECTION_NAME__) \
RE: [PATCH, ira] Ignore some conflict cost
-Original Message- From: Marek Polacek [mailto:pola...@redhat.com] Sent: Wednesday, September 17, 2014 5:29 PM To: Zhenqiang Chen Cc: gcc-patches@gcc.gnu.org Subject: Re: [PATCH, ira] Ignore some conflict cost On Wed, Sep 17, 2014 at 05:18:27PM +0800, Zhenqiang Chen wrote: Hi, When assign_hard_reg, we always check_hard_reg_p, which has code if (! TEST_HARD_REG_BIT (profitable_regs, hard_regno)) return false; i.e. If a hard_regno is not in profitable_regs, we can not allocate it to the ira_allocno_t A. So the conflict on a hard_regno, which does not belong to the profitable_regs, can be ignored. Please refer https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63210 for the detail of the test case. Bootstrap and no make check regression on X86-64 and ARM Chromebook. NO spec2k performance regression on X86-64 and ARM Chromebook. CSiBE code size is 0.01% better for ARM Cortex-M0. Note that your MUA malformed the patch, so it can't be easily applied. Thanks for the comments. Resend it as an attachment. -Zhenqiang ira-conflict-costs.patch Description: Binary data
Move dwarf2 frame tables to read-only section for AIX
Hi,
The following patch moves dwarf2 exception frame tables to read-only
memory so they can be properly shared by multiple processes on AIX.
There are two main mechanisms to register frame tables:
- EH_FRAME_SECTION_NAME puts the frames in a specially named section,
which are then registered by crtstuff.c
- EH_FRAME_IN_DATA_SECTION assigns special labels to the frames, these
labels are then located by collect2.c and loaded by generated code.
The AIX linker doesn't meet the requirements of EH_FRAME_SECTION_NAME,
and the other option EH_FRAME_IN_DATA_SECTION defaults to the
read-write data section.
I altered the dwarf2 frame and exception table generation so the
decision on whether to use a read-only or read-write section is an
independent decision from how the frame tables are registered.
I renamed EH_FRAME_IN_DATA_SECTION to EH_FRAME_THROUGH_COLLECT2, as it
now supports read-only, has slightly changed semantics, and I think
this name better reflects what it currently does rather than what it
historically did.
The spu port may see frame tables for executables move to read-only
memory. I assume this will work and is beneficial. Alternately
#define EH_TABLES_CAN_BE_READ_ONLY 0 should make it see no semantic
changes.
I believe I have an OK for the AIX changes:
https://gcc.gnu.org/ml/gcc-patches/2014-09/msg01305.html.
Can I please have a review for the dwarf2 changes?
Thanks,
Andrew
2014-09-22 Andrew Dixie andr...@gentrack.com
Move exception tables to read-only memory on AIX.
* dwarf2asm.c (dw2_asm_output_encoded_addr_rtx): Add call to
ASM_OUTPUT_DWARF_DATAREL.
* dwarf2out.c (switch_to_eh_frame_section): Use a read-only section
even if EH_FRAME_SECTION_NAME is undefined. Add call to
EH_FRAME_THROUGH_COLLECT2.
* except.c (switch_to_exception_section): Use a read-only section
even if EH_FRAME_SECTION_NAME is undefined.
* collect2.c (write_c_file_stat): Provide dbase on AIX.
(scan_prog_file): Don't output __dso_handle nor __gcc_unwind_dbase.
* config/rs6000/aix.h (ASM_PREFERRED_EH_DATA_FORMAT): define.
(EH_TABLES_CAN_BE_READ_ONLY): define.
(ASM_OUTPUT_DWARF_PCREL): define.
(ASM_OUTPUT_DWARF_DATAREL): define.
(EH_FRAME_IN_DATA_SECTION): undefine.
(EH_FRAME_THROUGH_COLLECT2): define.
* config/rs6000/rs6000-aix.c: new file.
(rs6000_aix_asm_output_dwarf_pcrel): new function.
(rs6000_aix_asm_output_dwarf_datarel): new function.
* config/rs6000/rs6000.c (rs6000_xcoff_asm_init_sections): remove
assignment of exception_section.
diff -rupN orig/gcc-4.10-20140706/gcc/doc/tm.texi
gcc-4.10-20140706/gcc/doc/tm.texi
--- orig/gcc-4.10-20140706/gcc/doc/tm.texi 2014-07-03
01:03:14.0 +1200
+++ gcc-4.10-20140706/gcc/doc/tm.texi 2014-09-19 21:53:11.593386708 +1200
@@ -8780,14 +8780,15 @@ You should define this symbol if your ta
unwind information and the default definition does not work.
@end defmac
-@defmac EH_FRAME_IN_DATA_SECTION
-If defined, DWARF 2 frame unwind information will be placed in the
-data section even though the target supports named sections. This
-might be necessary, for instance, if the system linker does garbage
-collection and sections cannot be marked as not to be collected.
-
-Do not define this macro unless @code{TARGET_ASM_NAMED_SECTION} is
-also defined.
+@defmac EH_FRAME_THROUGH_COLLECT2
+If defined, DWARF 2 frame unwind information will identified by
+specially named labels. The collect2 process will locate these
+labels and generate code to register the frames.
+
+This might be necessary, for instance, if the system linker will not
+place the frames in-between the sentinals from @file{crtstuff.c},
+or if the system linker does garbage collection and sections cannot
+be marked as not to be collected.
@end defmac
@defmac EH_TABLES_CAN_BE_READ_ONLY
@@ -9400,6 +9401,11 @@ A C statement to issue assembly directiv
reference to the given @var{label}, using an integer of the given @var{size}.
@end defmac
+@defmac ASM_OUTPUT_DWARF_DATAREL (@var{stream}, @var{size}, @var{label})
+A C statement to issue assembly directives that create a reference to the
+given @var{label} relative to the dbase, using an integer of the
given @var{size}.
+@end defmac
+
@defmac ASM_OUTPUT_DWARF_TABLE_REF (@var{label})
A C statement to issue assembly directives that create a reference to
the DWARF table identifier @var{label} from the current section. This
diff -rupN orig/gcc-4.10-20140706/gcc/doc/tm.texi.in
gcc-4.10-20140706/gcc/doc/tm.texi.in
--- orig/gcc-4.10-20140706/gcc/doc/tm.texi.in 2014-06-06
13:04:22.0 +1200
+++ gcc-4.10-20140706/gcc/doc/tm.texi.in2014-09-19
21:22:37.062429084 +1200
@@ -6515,14 +6515,15 @@ You should define this symbol if your ta
unwind information and the default definition does not work.
@end defmac
-@defmac EH_FRAME_IN_DATA_SECTION
-If defined, DWARF 2 frame unwind information will be placed in the
Re: [PATCH] microblaze: microblaze.md: Use 'SI' instead of 'VOID' for operand 1 of 'call_value_intern'
On 9/22/14 2:03, Michael Eager wrote: On 09/20/14 23:24, Chen Gang wrote: And it seems, we also need 'LinkScr.ld' for ldscript, could you share it to me, thanks. set_board_info ldscript -T/home/eager/Xilinx/dg/microblaze_0/LinkScr.ld Hi Chen -- The DejaGNU configuration I provided is for a bare-metal environment. If you are testing in a Linux environment, the tool chain you uses should provide a default linker script which matches your hardware's memory layout. You should not need to provide a separate linker script. OK, thanks, I shall try to find the default linker script for it. Thanks -- Chen Gang Open, share, and attitude like air, water, and life which God blessed
Re: [PATCH] microblaze: microblaze.md: Use 'SI' instead of 'VOID' for operand 1 of 'call_value_intern'
On 9/22/14 2:09, Michael Eager wrote: On 09/21/14 03:46, Chen Gang wrote: Excuse me, I want to consult one thing: I installed raw microblaze cross compiler, binutils and glibc into one directory (/upstream/release), and try to build a Hello world C program for microblaze under x86_64 host. I guess it is OK, but I am not quite sure about it (I use raw compiler, and have to point out /upstream/release/lib/ld.so.1 explicitly, and receive a warning related with 'ld'). Is it really OK? can I still use raw compiler for our testsuite? Is 'LinkScr.ld' for ldscript related with current case? [root@localhost test]# /upstream/release/bin/microblaze-gchen-linux-gcc -nostdinc -c -o test.o test.c [root@localhost test]# /upstream/release/bin/microblaze-gchen-linux-ld -o test test.o /upstream/release/lib/ld.so.1 -lc -L/upstream/release/lib /upstream/release/bin/microblaze-gchen-linux-ld: warning: cannot find entry symbol _start; defaulting to 1180 Generally, you should use gcc to link programs, not ld. gcc is a driver which will select the appropriate libraries and support routines (such as crt0.o, which contains _start) and pass them to the linker. OK, thanks. When gcc, it misses the root directory for crt1.o and crtn.o: e.g. /lib/ld.so.1, crt1.o, crtn.o when gcc -v, but we need /upstream/ release/lib/ld.so.1, /upstream/lib/crt1.o, /upstream/libcrtn.o. I guess, we need additional flag to mark the default system link path for gcc. But after check the all parameters of gcc, I can not find (-L is for normal library linkage, but not for crt1.o and crtn.o). I shall continue trying for it, and hope I can finish within this month. Welcome any ideas, suggestions or completions. Thanks. -- Chen Gang Open, share, and attitude like air, water, and life which God blessed
