[GCC ARM-Embedded-4_7]Back port r193425(improving reger pressure hoisting) from TRUNK
Hi, I back ported r193425 from TRUNK to GCC ARM-Embedded-4_7 branch as r193495. Thanks Backport from mainline r193425 2012-11-12 Bin Cheng bin.ch...@arm.com * gcse.c (struct bb_data): Add new fields, old_pressure, live_in and backup. (get_regno_pressure_class): Add prototype. (update_bb_reg_pressure): New. (should_hoist_expr_to_dom): Add new parameter from. Monitor the change of reg pressure and use it to drive hoisting. (hoist_code): Update LIVE and reg pressure information. (calculate_bb_reg_pressure): Initialize live_in and backup. Backport from mainline r193425 2012-11-12 Bin Cheng bin.ch...@arm.com * gcc.dg/hoist-register-pressure-3.c: New test.
Fix bootstrap on non-ifunc capable targets (i386)
Hi all, this commit: 193486 broke bootstrap on targets which do not have HAVE_GNU_INDIRECT_FUNCTION. Ok to commit? TIA, Andreas Index: config/i386/i386.c === --- config/i386/i386.c (revision 193495) +++ config/i386/i386.c (working copy) @@ -28907,12 +28907,15 @@ struct cgraph_node *node = NULL; struct cgraph_node *default_node = NULL; struct cgraph_function_version_info *node_v = NULL; - struct cgraph_function_version_info *it_v = NULL; struct cgraph_function_version_info *first_v = NULL; tree dispatch_decl = NULL; + +#if defined (ASM_OUTPUT_TYPE_DIRECTIVE) HAVE_GNU_INDIRECT_FUNCTION + struct cgraph_function_version_info *it_v = NULL; struct cgraph_node *dispatcher_node = NULL; struct cgraph_function_version_info *dispatcher_version_info = NULL; +#endif struct cgraph_function_version_info *default_version_info = NULL;
Re: Asan/Tsan Unit/Regression testing (was [asan] Emit GIMPLE direclty, small cleanups)
On Tue, Nov 13, 2012 at 11:13:03AM -0800, Wei Mi wrote:
I migrate a test in the third category. Please help to check whether
it is ok. Then I will migrate the left. The files added are as follows
and attached. (Please forgive I use -fasan in asan.exp because I use
an old repository to try the migration)
I don't like it. While I am nowhere close to be an experienced tcl
hacker, IMHO you copy lots of unneeded cruft, on the other side you are
missing important details (and mudflap was a particularly bad choice
to copy bits from).
Here is my alternative, so far missing any bits to actually run addr2line
on the output and match the backtraces if requested.
With this, tests for C and C++ can be placed in c-c++-common/*.c, C only tests
in gcc.dg/asan/*.c and C++ only tests in g++.dg/asan/*.C.
make check RUNTESTFLAGS='--target_board=unix\{-m32,-m64\} asan.exp'
should run both all C and all C++ tests, with both -m32 and -m64 (and
torture through all standard -O* options e.g. dg-torture.exp cycles
through). dg-options can be left out, -faddress-sanitizer is implied
(would need to be overridden by -fno-address-sanitizer), -fno-builtin-memcmp
is on the example test just if we later on match the backtrace, because
without it memcmp won't appear in the backtrace, just main (as the bug
is caught already there). I've also tweaked the test to 5+argc instead
of 4+argc, I fear that on some embedded targets argc can be 0.
2012-11-14 Jakub Jelinek ja...@redhat.com
* lib/asan-dg.exp: New file.
* gcc.dg/asan/asan.exp: New file.
* g++.dg/dg.exp: Prune also asan tests.
* g++.dg/asan/asan.exp: New file.
* c-c++-common/asan/memcmp-1.c: New test.
--- gcc/testsuite/lib/asan-dg.exp.jj2012-11-14 09:11:13.086054131 +0100
+++ gcc/testsuite/lib/asan-dg.exp 2012-11-14 10:37:18.904032326 +0100
@@ -0,0 +1,88 @@
+# Copyright (C) 2012 Free Software Foundation, Inc.
+
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 3 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with GCC; see the file COPYING3. If not see
+# http://www.gnu.org/licenses/.
+
+load_lib target-libpath.exp
+
+# Return 1 if compilation with -faddress-sanitizer is error-free for trivial
+# code, 0 otherwise.
+
+proc check_effective_target_faddress_sanitizer {} {
+return [check_no_compiler_messages faddress_sanitizer object {
+void foo (void) { }
+} -faddress-sanitizer]
+}
+
+#
+# asan_link_flags -- compute library path and flags to find libasan.
+# (originally from g++.exp)
+#
+
+proc asan_link_flags { paths } {
+global srcdir
+global ld_library_path
+global shlib_ext
+
+set gccpath ${paths}
+set flags
+
+set shlib_ext [get_shlib_extension]
+
+if { $gccpath != } {
+ if { [file exists ${gccpath}/libsanitizer/asan/.libs/libasan.a]
+ || [file exists
${gccpath}/libsanitizer/asan/.libs/libasan.${shlib_ext}] } {
+ append flags -L${gccpath}/libsanitizer/asan/.libs
+ append ld_library_path :${gccpath}/libsanitizer/asan/.libs
+ }
+} else {
+ global tool_root_dir
+
+ set libasan [lookfor_file ${tool_root_dir} libasan]
+ if { $libasan != } {
+ append flags -L${libasan}
+ append ld_library_path :${libasan}
+ }
+}
+
+set_ld_library_path_env_vars
+
+return $flags
+}
+
+#
+# asan_init -- called at the start of each subdir of tests
+#
+
+proc asan_init { args } {
+global TEST_ALWAYS_FLAGS
+global ALWAYS_CXXFLAGS
+global TOOL_OPTIONS
+
+set link_flags
+if ![is_remote host] {
+ if [info exists TOOL_OPTIONS] {
+ set link_flags [asan_link_flags [get_multilibs ${TOOL_OPTIONS}]]
+ } else {
+ set link_flags [asan_link_flags [get_multilibs]]
+ }
+}
+
+if [info exists ALWAYS_CXXFLAGS] {
+ set ALWAYS_CXXFLAGS [concat {ldflags=$link_flags} $ALWAYS_CXXFLAGS]
+ set ALWAYS_CXXFLAGS [concat {additional_flags=-faddress-sanitizer}
$ALWAYS_CXXFLAGS]
+} else {
+ set TEST_ALWAYS_FLAGS $link_flags -faddress-sanitizer
$TEST_ALWAYS_FLAGS
+}
+}
--- gcc/testsuite/gcc.dg/asan/asan.exp.jj 2012-11-14 10:25:31.504713624
+0100
+++ gcc/testsuite/gcc.dg/asan/asan.exp 2012-11-14 10:27:08.109935623 +0100
@@ -0,0 +1,37 @@
+# Copyright (C) 2012 Free Software Foundation, Inc.
+#
+# This file is part of GCC.
+#
+# GCC is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free
Re: [PATCH] PR other/55291: Add support for GCC multilib run-time libraries to libsanitizer
On 2012.11.14 at 00:48 +0100, Paolo Bonzini wrote: Il 14/11/2012 00:43, H.J. Lu ha scritto: This works. Ok, then please test remove install-sh and friends and do autoconf/automake again. If it works, commit the result (I don't care if you make it one or two commits). Then, wait 24 hours for breakages and commit the multilib patch. This doesn't work on my system (with autoconf=2.69 installed) configure.ac:5: error: Please use exactly Autoconf 2.64 instead of 2.69. ../config/override.m4:12: _GCC_AUTOCONF_VERSION_CHECK is expanded from... configure.ac:5: the top level autom4te-2.69: m4 failed with exit status: 1 aclocal-1.11: autom4te failed with exit status: 1 make[2]: *** [/home/markus/gcc/libsanitizer/aclocal.m4] Error 1 make[2]: Leaving directory `/var/tmp/gcc_build_dir/x86_64-pc-linux-gnu/libsanitizer' -- Markus
Re: [PATCH] PR other/55291: Add support for GCC multilib run-time libraries to libsanitizer
On 2012.11.14 at 10:57 +0100, Markus Trippelsdorf wrote: On 2012.11.14 at 00:48 +0100, Paolo Bonzini wrote: Il 14/11/2012 00:43, H.J. Lu ha scritto: This works. Ok, then please test remove install-sh and friends and do autoconf/automake again. If it works, commit the result (I don't care if you make it one or two commits). Then, wait 24 hours for breakages and commit the multilib patch. This doesn't work on my system (with autoconf=2.69 installed) configure.ac:5: error: Please use exactly Autoconf 2.64 instead of 2.69. ../config/override.m4:12: _GCC_AUTOCONF_VERSION_CHECK is expanded from... configure.ac:5: the top level autom4te-2.69: m4 failed with exit status: 1 aclocal-1.11: autom4te failed with exit status: 1 make[2]: *** [/home/markus/gcc/libsanitizer/aclocal.m4] Error 1 make[2]: Leaving directory `/var/tmp/gcc_build_dir/x86_64-pc-linux-gnu/libsanitizer' With the right autotools installed locally, running: ACLOCAL='aclocal -I .. -I ../config' autoreconf -v rm -fr autom4te.cache in gcc/libsanitizer and committing the diff should fix the issue. -- Markus
Re: [PATCH, i386]: AMD bdver3 enablement
On Wed, Nov 14, 2012 at 10:22 AM, Gopalasubramanian, Ganesh
ganesh.gopalasubraman...@amd.com wrote:
sseshuf replaces sselog in some insn patterns, but should be handled in the
same way in *existing* .md files.
Modifications done as per the comments.
1. Sseshuf is added along with sselog in existing md files.
2. sseshuf is handled in a separate pattern in bdver3.md
Bootstrapping and make -k check passes.
Ok for trunk?
2012-11-14 Ganesh Gopalasubramanian ganesh.gopalasubraman...@amd.com
bdver3 Enablement
* gcc/doc/extend.texi: Add details about bdver3.
* gcc/doc/invoke.texi: Add details about bdver3.
* config.gcc (i[34567]86-*-linux* | ...): Add bdver3.
(case ${target}): Add bdver3.
* config/i386/i386.h (TARGET_BDVER3): New definition.
* config/i386/i386.md (define_attr cpu): Add bdver3.
* config/i386/sse.md (sseshuf): New type attribute.
* config/i386/athlon.md (sseshuf):Likewise.
* config/i386/atom.md (sseshuf):Likewise.
* config/i386/ppro.md (sseshuf):Likewise.
* config/i386/bdver1.md (sseshuf):Likewise.
* config/i386/i386.opt (flag_dispatch_scheduler): Add bdver3.
* config/i386/i386-c.c (ix86_target_macros_internal): Add
bdver3 def_and_undef
* config/i386/driver-i386.c (host_detect_local_cpu): Let
-march=native recognize bdver3 processors.
* config/i386/i386.c (struct processor_costs bdver3_cost): New.
(m_BDVER3): New definition.
(m_AMD_MULTIPLE): Includes m_BDVER3.
(initial_ix86_tune_features): Add bdver3 tune.
(processor_target_table): Add bdver3 entry.
(static const char *const cpu_names): Add bdver3 entry.
(software_prefetching_beneficial_p): Add bdver3.
(ix86_option_override_internal): Add bdver3 instruction sets.
(ix86_option_override_internal): Remove XSAVEOPT for bdver1
and bdver2.
(ix86_issue_rate): Add bdver3.
(ix86_adjust_cost): Add bdver3.
(enum target_cpu_default): Add TARGET_CPU_DEFAULT_bdver3.
(enum processor_type): Add PROCESSOR_BDVER3.
* config/i386/bdver3.md: New file describing bdver3 pipelines.
OK for mainline.
Thanks,
Uros.
Re: Fix bootstrap on non-ifunc capable targets (i386)
Hello! this commit: 193486 broke bootstrap on targets which do not have HAVE_GNU_INDIRECT_FUNCTION. Ok to commit? OK, with appropriate ChangeLog entry and if bootstrapped correctly on both, IFUNC and non-IFUNC capable target. Thanks, Uros.
Re: [Bug libstdc++/54075] [4.7.1] unordered_map insert still slower than 4.6.2
Hi, On 11/13/2012 10:40 PM, François Dumont wrote: 2012-11-13 François Dumont fdum...@gcc.gnu.org * include/bits/hashtable_policy.h (_Prime_rehash_policy): Remove automatic shrink. (_Prime_rehash_policy::_M_bkt_for_elements): Do not call _M_next_bkt anymore. (_Prime_rehash_policy::_M_next_bkt): Move usage of _S_growth_factor ... (_Prime_rehash_policy::_M_need_rehash): ... here. * include/bits/hashtable.h (_Hashtable): Adapt. Tested under linux x86_64, normal and debug modes. Patch is Ok with me, please wait another day or two for comments and then apply it. You can also add the performance testcase, of course, note however that ::random isn't a standard C function, thus we shouldn't use it unconditionally, either manage with std::rand from cstdlib or do something completely different (maybe even random since you are writing C++11 code anyway!). I would also recommend extending quite a bit the runtime, 10x would be still completely sensible (but I guess, without using much more memory) Paolo.
Re: Asan/Tsan Unit/Regression testing (was [asan] Emit GIMPLE direclty, small cleanups)
Hi!
And here is an updated patch with start of the symbolizer (just showing
where it can be hooked, the symbolizer returns the output text unmodified right
now). Writing an initial native only version shouldn't be that hard,
I guess one will need something like:
set addr2line_name [find_binutils_prog addr2line]
...
set res [remote_exec host $addr2line_name -f -e $object $address1
$address2]
or so, the bigger problem is with cross testing, I really have no idea where
addr2line should be run, what files need to be copied which way etc.
Anyway, once asan_symbolize actually symbolizes the output, we could use
something like:
/* { dg-output ERROR: AddressSanitizer stack-buffer-overflow.* } */
/* { dg-output #0 0x\[0-9a-f\]+ (in _*(interceptor_|)memcmp
|\[(\])\[^\n\r]*(\n|\r\n|\r) } */
/* { dg-output #1 0x\[0-9a-f\]+ (in _*main|\[(\])\[^\n\r]*(\n|\r\n|\r) }
*/
(this way it will check function names if symbolizer was actually
successful, and just accept #0 0xdeadbeef (foobarbaz.so+0xbeef) style
if it wasn't), but will not accept other function names in the backtrace.
2012-11-14 Jakub Jelinek ja...@redhat.com
* lib/asan-dg.exp: New file.
* gcc.dg/asan/asan.exp: New file.
* g++.dg/dg.exp: Prune also asan tests.
* g++.dg/asan/asan.exp: New file.
* c-c++-common/asan/memcmp-1.c: New test.
--- gcc/testsuite/lib/asan-dg.exp.jj2012-11-14 09:11:13.086054131 +0100
+++ gcc/testsuite/lib/asan-dg.exp 2012-11-14 11:45:40.142061595 +0100
@@ -0,0 +1,111 @@
+# Copyright (C) 2012 Free Software Foundation, Inc.
+
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 3 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with GCC; see the file COPYING3. If not see
+# http://www.gnu.org/licenses/.
+
+load_lib target-libpath.exp
+
+# Return 1 if compilation with -faddress-sanitizer is error-free for trivial
+# code, 0 otherwise.
+
+proc check_effective_target_faddress_sanitizer {} {
+return [check_no_compiler_messages faddress_sanitizer object {
+ void foo (void) { }
+} -faddress-sanitizer]
+}
+
+#
+# asan_link_flags -- compute library path and flags to find libasan.
+# (originally from g++.exp)
+#
+
+proc asan_link_flags { paths } {
+global srcdir
+global ld_library_path
+global shlib_ext
+
+set gccpath ${paths}
+set flags
+
+set shlib_ext [get_shlib_extension]
+
+if { $gccpath != } {
+ if { [file exists ${gccpath}/libsanitizer/asan/.libs/libasan.a]
+ || [file exists
${gccpath}/libsanitizer/asan/.libs/libasan.${shlib_ext}] } {
+ append flags -L${gccpath}/libsanitizer/asan/.libs
+ append ld_library_path :${gccpath}/libsanitizer/asan/.libs
+ }
+} else {
+ global tool_root_dir
+
+ set libasan [lookfor_file ${tool_root_dir} libasan]
+ if { $libasan != } {
+ append flags -L${libasan}
+ append ld_library_path :${libasan}
+ }
+}
+
+set_ld_library_path_env_vars
+
+return $flags
+}
+
+#
+# asan_init -- called at the start of each subdir of tests
+#
+
+proc asan_init { args } {
+global TEST_ALWAYS_FLAGS
+global ALWAYS_CXXFLAGS
+global TOOL_OPTIONS
+
+set link_flags
+if ![is_remote host] {
+ if [info exists TOOL_OPTIONS] {
+ set link_flags [asan_link_flags [get_multilibs ${TOOL_OPTIONS}]]
+ } else {
+ set link_flags [asan_link_flags [get_multilibs]]
+ }
+}
+
+if [info exists ALWAYS_CXXFLAGS] {
+ set ALWAYS_CXXFLAGS [concat {ldflags=$link_flags} $ALWAYS_CXXFLAGS]
+ set ALWAYS_CXXFLAGS [concat {additional_flags=-faddress-sanitizer}
$ALWAYS_CXXFLAGS]
+} else {
+ set TEST_ALWAYS_FLAGS $link_flags -faddress-sanitizer
$TEST_ALWAYS_FLAGS
+}
+}
+
+# Symbolize lines like
+# #2 0xdeadbeef (/some/path/libsanitizer.so.0.0.0+0xbeef)
+# in $output using addr2line to
+# #2 0xdeadbeef in foobar file:123
+proc asan_symbolize { output } {
+return $output
+}
+
+# Replace ${tool}_load with a wrapper so that we can symbolize the output.
+if { [info procs ${tool}_load] != [list] \
+ [info procs saved_asan_${tool}_load] == [list] } {
+rename ${tool}_load saved_asan_${tool}_load
+
+proc ${tool}_load { program args } {
+ global tool
+ set result [eval [list saved_asan_${tool}_load $program] $args]
+ set output [lindex $result 1]
+ set symbolized_output [asan_symbolize $output]
+ set result [list [lindex $result 0] $symbolized_output]
+ return
Re: [PATCH 10/10] Import the asan runtime library into GCC tree
On Mon, Nov 12, 2012 at 10:59 AM, H.J. Lu hjl.to...@gmail.com wrote:
On Mon, Nov 12, 2012 at 3:47 AM, Dodji Seketeli do...@seketeli.org wrote:
Diego Novillo dnovi...@google.com writes:
On 2012-11-02 16:10 , Dodji Seketeli wrote:
* configure.ac: Add libsanitizer to target_libraries.
* Makefile.def: Ditto.
* configure: Regenerate.
* Makefile.in: Regenerate.
* libsanitizer: New directory for asan runtime. Contains an empty
tsan directory.
gcc:
* gcc.c (LINK_COMMAND_SPEC): Add -lasan to link command
if -faddress-sanitizer is on.
OK with Jakub's comments addressed.
References to -fasan in diagnostics should be replaced. But there's
been another flag name change upstream, so let's do it together with
the new flag names.
Done. This also addresses the comment later made by Tobias below:
Tobias Burnus bur...@net-b.de writes:
Other issues:
* Probably fixed on the branch: gcc/gcc.c still has fasan instead of
faddress-sanitizer for the spec:
+%{fasan:-lasan}
Below is a link to the updated patch.
This patch imports the runtime library in the GCC tree, ensures that
-lasan is passed to the linker when -faddress-sanitizer is used and
sets up the build system accordingly.
* configure.ac: Add libsanitizer to target_libraries.
* Makefile.def: Ditto.
* configure: Regenerate.
* Makefile.in: Regenerate.
* libsanitizer: New directory for asan runtime. Contains an empty
tsan directory.
gcc:
* gcc.c (LINK_COMMAND_SPEC): Add -laddress-sanitizer to link command
if -faddress-sanitizer is on.
libsanitizer:
Initial checkin: migrate asan runtime from llvm.
http://people.redhat.com/~dseketel/gcc/patches/0011-Import-the-asan-runtime-library-into-GCC-tree.patch
--
Dodji
I checked in this patch to add libsanitizer generated files.
--
H.J.
---
diff --git a/contrib/ChangeLog b/contrib/ChangeLog
index ef5d6f6..233870d 100644
--- a/contrib/ChangeLog
+++ b/contrib/ChangeLog
@@ -1,3 +1,7 @@
+2012-11-12 H.J. Lu hongjiu...@intel.com
+
+ * gcc_update: Add libsanitizer generated files.
+
2012-11-05 Lawrence Crowl cr...@google.com
* compare_two_ftime_report_sets: New.
diff --git a/contrib/gcc_update b/contrib/gcc_update
index 02897ab..d9c2dfb 100755
--- a/contrib/gcc_update
+++ b/contrib/gcc_update
@@ -149,6 +149,9 @@ libatomic/Makefile.in: libatomic/Makefile.am
libatomic/aclocal.m4
libatomic/testsuite/Makefile.in: libatomic/testsuite/Makefile.am
libatomic/aclocal.m4
libatomic/configure: libatomic/configure.ac libatomic/aclocal.m4
libatomic/auto-config.h.in: libatomic/configure.ac libatomic/aclocal.m4
+libsanitizer/aclocal.m4: libsanitizer/configure.ac
+libsanitizer/Makefile.in: libsanitizer/Makefile.am libsanitizer/aclocal.m4
+libsanitizer/configure: libsanitizer/configure.ac libsanitizer/aclocal.m4
# Top level
Makefile.in: Makefile.tpl Makefile.def
configure: configure.ac config/acx.m4
I checked in this to update libsanitizer generated files.
--
H.J.
--
Index: ChangeLog
===
--- ChangeLog (revision 193496)
+++ ChangeLog (working copy)
@@ -1,3 +1,7 @@
+2012-11-14 H.J. Lu hongjiu...@intel.com
+
+ * gcc_update: Update libsanitizer generated files.
+
2012-11-12 Tobias Burnus bur...@net-b.de
* gcc_update: Add libquadmath generated files.
Index: gcc_update
===
--- gcc_update (revision 193496)
+++ gcc_update (working copy)
@@ -152,9 +152,12 @@
libatomic/testsuite/Makefile.in: libatomic/testsuite/Makefile.am
libatomic/aclocal.m4
libatomic/configure: libatomic/configure.ac libatomic/aclocal.m4
libatomic/auto-config.h.in: libatomic/configure.ac libatomic/aclocal.m4
-libsanitizer/aclocal.m4: libsanitizer/configure.ac
+libsanitizer/aclocal.m4: libsanitizer/configure.ac libsanitizer/acinclude.m4
libsanitizer/Makefile.in: libsanitizer/Makefile.am libsanitizer/aclocal.m4
libsanitizer/configure: libsanitizer/configure.ac libsanitizer/aclocal.m4
+libsanitizer/asan/Makefile.in: libsanitizer/asan/Makefile.am
libsanitizer/aclocal.m4
+libsanitizer/interception/Makefile.in:
libsanitizer/interception/Makefile.am libsanitizer/aclocal.m4
+libsanitizer/sanitizer_common/Makefile.in:
libsanitizer/sanitizer_common/Makefile.am libsanitizer/aclocal.m4
# Top level
Makefile.in: Makefile.tpl Makefile.def
configure: configure.ac config/acx.m4
[PATCH arm/aarch64-4.7] Fix up Changelogs
Some changes had been added to gcc/ChangeLog and gcc/testsuite/Changelog when they should have been recorded in the gcc/Changelog.aarch64 and gcc/testsuite/Changelog.aarch64 files instead. Committed as obvious. Cheers, Ian
Re: [PATCH 10/10] Import the asan runtime library into GCC tree
On Wed, Nov 14, 2012 at 3:11 AM, H.J. Lu hjl.to...@gmail.com wrote:
On Mon, Nov 12, 2012 at 10:59 AM, H.J. Lu hjl.to...@gmail.com wrote:
On Mon, Nov 12, 2012 at 3:47 AM, Dodji Seketeli do...@seketeli.org wrote:
Diego Novillo dnovi...@google.com writes:
On 2012-11-02 16:10 , Dodji Seketeli wrote:
* configure.ac: Add libsanitizer to target_libraries.
* Makefile.def: Ditto.
* configure: Regenerate.
* Makefile.in: Regenerate.
* libsanitizer: New directory for asan runtime. Contains an empty
tsan directory.
gcc:
* gcc.c (LINK_COMMAND_SPEC): Add -lasan to link command
if -faddress-sanitizer is on.
OK with Jakub's comments addressed.
References to -fasan in diagnostics should be replaced. But there's
been another flag name change upstream, so let's do it together with
the new flag names.
Done. This also addresses the comment later made by Tobias below:
Tobias Burnus bur...@net-b.de writes:
Other issues:
* Probably fixed on the branch: gcc/gcc.c still has fasan instead of
faddress-sanitizer for the spec:
+%{fasan:-lasan}
Below is a link to the updated patch.
This patch imports the runtime library in the GCC tree, ensures that
-lasan is passed to the linker when -faddress-sanitizer is used and
sets up the build system accordingly.
* configure.ac: Add libsanitizer to target_libraries.
* Makefile.def: Ditto.
* configure: Regenerate.
* Makefile.in: Regenerate.
* libsanitizer: New directory for asan runtime. Contains an empty
tsan directory.
gcc:
* gcc.c (LINK_COMMAND_SPEC): Add -laddress-sanitizer to link command
if -faddress-sanitizer is on.
libsanitizer:
Initial checkin: migrate asan runtime from llvm.
http://people.redhat.com/~dseketel/gcc/patches/0011-Import-the-asan-runtime-library-into-GCC-tree.patch
I renamed ChangeLog.asan to ChangeLog.
--
H.J.
Re: ASAN merge...
Diego Novillo dnovi...@google.com writes: On Tue, Nov 13, 2012 at 12:07 AM, David Miller da...@davemloft.net wrote: This has broken the build on every Linux target that hasn't added the necessary cpu specific code to asan_linux.cc This should be fixed by Dodji's recent patch. ASAN is not currently ported to any target other than x86/linux, so it should just be completely disabled until the other ports start showing up. Dodji is your patch committed? Yes it is. It was even ironed out by a later patch from Richard Henderson. This should hopefully be fixed now. -- Dodji
Re: [PATCH] PR other/55291: Add support for GCC multilib run-time libraries to libsanitizer
On Tue, Nov 13, 2012 at 3:48 PM, Paolo Bonzini bonz...@gnu.org wrote: Il 14/11/2012 00:43, H.J. Lu ha scritto: This works. Ok, then please test remove install-sh and friends and do autoconf/automake again. If it works, commit the result (I don't care if you make it one or two commits). Then, wait 24 hours for breakages and commit the multilib patch. Paolo GCC target libraries don't set AC_CONFIG_AUX_DIR. I checked in this patch to remove it and fix Makefile.in. -- H.J. --- diff --git a/libsanitizer/ChangeLog b/libsanitizer/ChangeLog index 6074d5b..c67c7f1 100644 --- a/libsanitizer/ChangeLog +++ b/libsanitizer/ChangeLog @@ -1,3 +1,9 @@ +2012-11-14 H.J. Lu hongjiu...@intel.com + + * configure.ac (AC_CONFIG_AUX_DIR): Removed. + * Makefile.in: Regenerated. + * configure: Likewise. + 2012-11-13 H.J. Lu hongjiu...@intel.com PR other/55304 diff --git a/libsanitizer/Makefile.in b/libsanitizer/Makefile.in index 8049a7e..babe91f 100644 --- a/libsanitizer/Makefile.in +++ b/libsanitizer/Makefile.in @@ -38,11 +38,7 @@ DIST_COMMON = $(am__configure_deps) $(srcdir)/../config.guess \ $(srcdir)/../config.sub $(srcdir)/../install-sh \ $(srcdir)/../ltmain.sh $(srcdir)/../missing \ $(srcdir)/../mkinstalldirs $(srcdir)/Makefile.am \ - $(srcdir)/Makefile.in $(top_srcdir)/configure ../ABOUT-NLS \ - ../COPYING ../COPYING.LIB ../ChangeLog ../README ../compile \ - ../config.guess ../config.rpath ../config.sub ../depcomp \ - ../install-sh ../ltmain.sh ../missing ../mkinstalldirs \ - ../ylwrap + $(srcdir)/Makefile.in $(top_srcdir)/configure ChangeLog ACLOCAL_M4 = $(top_srcdir)/aclocal.m4 am__aclocal_m4_deps = $(top_srcdir)/../config/depstand.m4 \ $(top_srcdir)/../config/lead-dot.m4 \ diff --git a/libsanitizer/configure b/libsanitizer/configure index ba6fe67..d69f5a7 100755 --- a/libsanitizer/configure +++ b/libsanitizer/configure @@ -2215,8 +2215,10 @@ ac_compiler_gnu=$ac_cv_c_compiler_gnu +am__api_version='1.11' + ac_aux_dir= -for ac_dir in .. $srcdir/..; do +for ac_dir in $srcdir $srcdir/.. $srcdir/../..; do for ac_t in install-sh install.sh shtool; do if test -f $ac_dir/$ac_t; then ac_aux_dir=$ac_dir @@ -2226,7 +2228,7 @@ for ac_dir in .. $srcdir/..; do done done if test -z $ac_aux_dir; then - as_fn_error cannot find install-sh, install.sh, or shtool in .. \$srcdir\/.. $LINENO 5 + as_fn_error cannot find install-sh, install.sh, or shtool in \$srcdir\ \$srcdir/..\ \$srcdir/../..\ $LINENO 5 fi # These three variables are undocumented and unsupported, @@ -2238,8 +2240,6 @@ ac_config_sub=$SHELL $ac_aux_dir/config.sub # Please don't use this var. ac_configure=$SHELL $ac_aux_dir/configure # Please don't use this var. -am__api_version='1.11' - # Find a good install program. We prefer a C program (faster), # so one script is as good as another. But avoid the broken or # incompatible versions: diff --git a/libsanitizer/configure.ac b/libsanitizer/configure.ac index cd57a69..0b6cdef 100644 --- a/libsanitizer/configure.ac +++ b/libsanitizer/configure.ac @@ -4,7 +4,6 @@ AC_PREREQ([2.64]) AC_INIT(package-unused, version-unused, libsanitizer) AC_CONFIG_SRCDIR([include/sanitizer/common_interface_defs.h]) -AC_CONFIG_AUX_DIR(..) AM_INIT_AUTOMAKE(foreign) # Checks for programs.
Re: [PATCH] Copy libsanitizer from llvm at revision 167890
H.J. Lu hjl.to...@gmail.com writes:
diff --git a/libsanitizer/asan/asan_linux.cc b/libsanitizer/asan/asan_linux.cc
index ea7ee9e..5c52ddc 100644
--- a/libsanitizer/asan/asan_linux.cc
+++ b/libsanitizer/asan/asan_linux.cc
@@ -1,5 +1,7 @@
//===-- asan_linux.cc
-===//
//
+// The LLVM Compiler Infrastructure
+//
// This file is distributed under the University of Illinois Open Source
// License. See LICENSE.TXT for details.
//
@@ -66,20 +68,6 @@ void GetPcSpBp(void *context, uptr *pc, uptr *sp, uptr
*bp) {
*pc = ucontext-uc_mcontext.gregs[REG_EIP];
*bp = ucontext-uc_mcontext.gregs[REG_EBP];
*sp = ucontext-uc_mcontext.gregs[REG_ESP];
-# elif defined(__sparc__)
- ucontext_t *ucontext = (ucontext_t*)context;
- uptr *stk_ptr;
-# if defined (__arch64__)
- *pc = ucontext-uc_mcontext.mc_gregs[MC_PC];
- *sp = ucontext-uc_mcontext.mc_gregs[MC_O6];
- stk_ptr = (uptr *) (*sp + 2047);
- *bp = stk_ptr[15];
-# else
- *pc = ucontext-uc_mcontext.gregs[REG_PC];
- *sp = ucontext-uc_mcontext.gregs[REG_O6];
- stk_ptr = (uptr *) *sp;
- *bp = stk_ptr[15];
-# endif
#else
# error Unsupported arch
#endif
I don't think removing this code is desirable. As discussed, there
needs to be one of the libsanitizer maintainers who takes care of
porting changes from the GCC side to upstream and importing upstream, as
Ian does for libgo.
Btw., is there some kind of libsanitizer porting guide, or is one
supposed to figure this out on one's own?
Rainer
--
-
Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [PATCH] Copy libsanitizer from llvm at revision 167890
On Wed, Nov 14, 2012 at 4:36 AM, Rainer Orth
r...@cebitec.uni-bielefeld.de wrote:
H.J. Lu hjl.to...@gmail.com writes:
diff --git a/libsanitizer/asan/asan_linux.cc
b/libsanitizer/asan/asan_linux.cc
index ea7ee9e..5c52ddc 100644
--- a/libsanitizer/asan/asan_linux.cc
+++ b/libsanitizer/asan/asan_linux.cc
@@ -1,5 +1,7 @@
//===-- asan_linux.cc
-===//
//
+// The LLVM Compiler Infrastructure
+//
// This file is distributed under the University of Illinois Open Source
// License. See LICENSE.TXT for details.
//
@@ -66,20 +68,6 @@ void GetPcSpBp(void *context, uptr *pc, uptr *sp, uptr
*bp) {
*pc = ucontext-uc_mcontext.gregs[REG_EIP];
*bp = ucontext-uc_mcontext.gregs[REG_EBP];
*sp = ucontext-uc_mcontext.gregs[REG_ESP];
-# elif defined(__sparc__)
- ucontext_t *ucontext = (ucontext_t*)context;
- uptr *stk_ptr;
-# if defined (__arch64__)
- *pc = ucontext-uc_mcontext.mc_gregs[MC_PC];
- *sp = ucontext-uc_mcontext.mc_gregs[MC_O6];
- stk_ptr = (uptr *) (*sp + 2047);
- *bp = stk_ptr[15];
-# else
- *pc = ucontext-uc_mcontext.gregs[REG_PC];
- *sp = ucontext-uc_mcontext.gregs[REG_O6];
- stk_ptr = (uptr *) *sp;
- *bp = stk_ptr[15];
-# endif
#else
# error Unsupported arch
#endif
I don't think removing this code is desirable. As discussed, there
needs to be one of the libsanitizer maintainers who takes care of
porting changes from the GCC side to upstream and importing upstream, as
Ian does for libgo.
I think all changes should go upstream first. It was a mistake
to check sparc changes into GCC tree.
Konstantin, can you take a look at
http://gcc.gnu.org/ml/gcc-patches/2012-11/msg00967.html
and get it into upstream?
Thanks.
--
H.J.
Re: [PATCH] Copy libsanitizer from llvm at revision 167890
H.J. Lu hjl.to...@gmail.com writes: I don't think removing this code is desirable. As discussed, there needs to be one of the libsanitizer maintainers who takes care of porting changes from the GCC side to upstream and importing upstream, as Ian does for libgo. I think all changes should go upstream first. It was a mistake to check sparc changes into GCC tree. I disagree, as do others: it is undesirable for gcc maintainers to have to interact with many different upstream communities to get their changes in. This is far better dealt with by the respective subsystem/library maintainers who have links to both communities. Btw., currently there's no libsanitizer maintainer listed in MAINTAINERS. This needs to change. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [PATCH] Copy libsanitizer from llvm at revision 167890
On Wed, Nov 14, 2012 at 4:44 AM, Rainer Orth r...@cebitec.uni-bielefeld.de wrote: H.J. Lu hjl.to...@gmail.com writes: I don't think removing this code is desirable. As discussed, there needs to be one of the libsanitizer maintainers who takes care of porting changes from the GCC side to upstream and importing upstream, as Ian does for libgo. I think all changes should go upstream first. It was a mistake to check sparc changes into GCC tree. I disagree, as do others: it is undesirable for gcc maintainers to have to interact with many different upstream communities to get their changes in. This is far better dealt with by the respective subsystem/library maintainers who have links to both communities. This may work for a mature library. libsanitizer keeps changes. Local changes make it hard to sync with upstream. Btw., currently there's no libsanitizer maintainer listed in MAINTAINERS. This needs to change. That is the real problem. We need a GCC libsanitizer maintainer: 1. He/she must have checkin privilege for upstream. 2. He/she should keep libsanitizer up to date. 3. All GCC libsanitizer changes shared with upstream must be approved by him/her. -- H.J.
Re: [PATCH] Copy libsanitizer from llvm at revision 167890
H.J. Lu hjl.to...@gmail.com writes: I think all changes should go upstream first. It was a mistake to check sparc changes into GCC tree. I disagree, as do others: it is undesirable for gcc maintainers to have to interact with many different upstream communities to get their changes in. This is far better dealt with by the respective subsystem/library maintainers who have links to both communities. This may work for a mature library. libsanitizer keeps changes. Local changes make it hard to sync with upstream. I'm not talking about local changes, just about a liaison to take care of moving changes started on the gcc side upstream. Say you're working on a platform not supported by LLVM (e.g. Solaris, I haven't checked): why should you be forced to deal with them and their infrastructure (mailinglists etc.) to get asan in gcc working on your platform? This is exactly how Ian moves my libgo changes upstream and imports upstream libgo once in a while. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [PATCH] Copy libsanitizer from llvm at revision 167890
On Wed, Nov 14, 2012 at 5:01 AM, Rainer Orth r...@cebitec.uni-bielefeld.de wrote: H.J. Lu hjl.to...@gmail.com writes: I think all changes should go upstream first. It was a mistake to check sparc changes into GCC tree. I disagree, as do others: it is undesirable for gcc maintainers to have to interact with many different upstream communities to get their changes in. This is far better dealt with by the respective subsystem/library maintainers who have links to both communities. This may work for a mature library. libsanitizer keeps changes. Local changes make it hard to sync with upstream. I'm not talking about local changes, just about a liaison to take care of moving changes started on the gcc side upstream. Say you're working on a platform not supported by LLVM (e.g. Solaris, I haven't checked): why should you be forced to deal with them and their infrastructure (mailinglists etc.) to get asan in gcc working on your platform? This is exactly how Ian moves my libgo changes upstream and imports upstream libgo once in a while. We don't have a maintainer is a problem, not go upstream first. I have a patch pending to enable mulltib. But libsanitizer doesn't work on x32 and it doesn't cause bootstrap problem with x32 enabled on Linux/x86-64. As soon as multlib is enabled, my bootstrap will fail since libsanitizer doesn't compile for x32. It has been fixed upstream.Should we apply a local fix or copy from upstream? -- H.J.
Re: [PATCH] Copy libsanitizer from llvm at revision 167890
H.J. Lu hjl.to...@gmail.com writes: We don't have a maintainer is a problem, not go upstream first. Agreed. I've no idea if the SC appointed one when it accepted libsanitizer etc. into GCC. I have a patch pending to enable mulltib. But libsanitizer doesn't work on x32 and it doesn't cause bootstrap problem with x32 enabled on Linux/x86-64. As soon as multlib is enabled, my bootstrap will fail since libsanitizer doesn't compile for x32. It has been fixed upstream.Should we apply a local fix or copy from upstream? I don't care: in similar cases for libgo, Ian applies the patch to the gcc tree at once and at about the same time installs it upstream so it isn't lost with the next import from upstream. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [PATCH, PR 55253] Propagate aggs_contain_variable flag in aggregater IPA-CP
Hi, On Tue, Nov 13, 2012 at 01:08:56PM -0800, Ian Lance Taylor wrote: On Tue, Nov 13, 2012 at 9:03 AM, Martin Jambor mjam...@suse.cz wrote: Index: src/gcc/ipa-cp.c === --- src.orig/gcc/ipa-cp.c +++ src/gcc/ipa-cp.c @@ -1276,6 +1276,8 @@ merge_aggregate_lattices (struct cgraph_ return true; if (src_plats-aggs_bottom) return set_agg_lats_contain_variable (dest_plats); + if (src_plats-aggs_contain_variable) +ret |= set_agg_lats_contain_variable (dest_plats); dst_aglat = dest_plats-aggs; Out of curiousity, why are the lines just above the ones you added not if (src_plats-aggs_bottom) return set_agg_lats_to_bottom (dest_plats); Since IPA-CP started gathering multiple known constant values per lattice and can create specialized clones for just some contexts, our bottom is not the classic bottom from simple constant propagation any more (classic bottom would be contains_variable flag set and no known values). Bottom is a sort of unusable flag, but it does not make other lattices unusable. They should be quite rare, they occur when their function is not local and also not versionable or not clonable, when we accumulated too many known constants in a lattice (so that it still adheres to the definition of lattice, here it really means a lattice bottom) or, in case of propagation of values in aggregates, when there is a (weird) mix of values passed by reference and values passed by value. At the moment, there are in fact no other reasons to create a bottom lattice, though there might be more in the future. If we know there might be more than the listed known values, contains_variable and aggs_contain_variable flags are the way to go. Martin
Re: [PATCH] Copy libsanitizer from llvm at revision 167890
On Wed, Nov 14, 2012 at 04:26:09AM -0800, H.J. Lu wrote: 2012-11-14 H.J. Lu hongjiu...@intel.com * Copied from llvm at revision 167890. diff --git a/libsanitizer/asan/asan_allocator.cc b/libsanitizer/asan/asan_allocator.cc index 3a92802..de37137 100644 --- a/libsanitizer/asan/asan_allocator.cc +++ b/libsanitizer/asan/asan_allocator.cc @@ -1,5 +1,7 @@ //===-- asan_allocator.cc -===// // +// The LLVM Compiler Infrastructure +// I believe all these lines were striped off intentationally, Wei should know better. So we shouldn't reintroduce them. Jakub
Re: ASAN merge...
David Miller da...@davemloft.net writes:
From: Diego Novillo dnovi...@google.com
Date: Tue, 13 Nov 2012 11:21:59 -0500
On Tue, Nov 13, 2012 at 12:07 AM, David Miller da...@davemloft.net wrote:
This has broken the build on every Linux target that hasn't added
the necessary cpu specific code to asan_linux.cc
This should be fixed by Dodji's recent patch. ASAN is not currently
ported to any target other than x86/linux, so it should just be
completely disabled until the other ports start showing up.
Dodji is your patch committed?
So I wasted my time by writing the sparc bits necessary to fix
the build?
I don't think you wasted your time. The work you did is certainly
necessary.
However, it is probably not sufficient because besides the runtime
libsanitizer library, asan needs the target hook asan_shadow_offset() to
be defined for your target. To date, that hook is only defined for x86
in config/i386/i386.c to ix86_asan_shadow_offset. This is the 'offset'
used to compute the address of the shadow memory region for a given
address like in:
shadow = address 3 + offset
That amounts to saying that for x86, the shadow memory is placed at the
bottom of the virtual memory space, as explained at
http://code.google.com/p/address-sanitizer/wiki/AddressSanitizerAlgorithm#Mapping.
I don't know if that mapping would work for sparc, though.
Please leave enabled the platforms that do actually build.
I guess we could do that. That would build libsanitizer, but asan will
still not be available on sparc if the asan_shadow_offset() target hook
is not provided. Is that OK to you?
If it is, then I guess the patch below should do the trick?
diff --git a/libsanitizer/configure.tgt b/libsanitizer/configure.tgt
index ca7ac1f..988312e 100644
--- a/libsanitizer/configure.tgt
+++ b/libsanitizer/configure.tgt
@@ -20,7 +20,7 @@
# Filter out unsupported systems.
case ${target} in
- x86_64-*-linux* | i?86-*-linux*)
+ x86_64-*-linux* | i?86-*-linux* | sparc*-*-linux*)
;;
*)
UNSUPPORTED=1
Cheers.
--
Dodji
Re: [PATCH] Copy libsanitizer from llvm at revision 167890
On Wed, Nov 14, 2012 at 5:25 AM, Jakub Jelinek ja...@redhat.com wrote:
On Wed, Nov 14, 2012 at 04:26:09AM -0800, H.J. Lu wrote:
2012-11-14 H.J. Lu hongjiu...@intel.com
* Copied from llvm at revision 167890.
diff --git a/libsanitizer/asan/asan_allocator.cc
b/libsanitizer/asan/asan_allocator.cc
index 3a92802..de37137 100644
--- a/libsanitizer/asan/asan_allocator.cc
+++ b/libsanitizer/asan/asan_allocator.cc
@@ -1,5 +1,7 @@
//===-- asan_allocator.cc
-===//
//
+// The LLVM Compiler Infrastructure
+//
I believe all these lines were striped off intentationally, Wei should know
better. So we shouldn't reintroduce them.
I withdrew my patch. I am applying this. Instead,
--
H.J.
---
2012-11-14 H.J. Lu hongjiu...@intel.com
PR other/55292
Backport from upstream revision 167883
* sanitizer_common/sanitizer_linux.cc (internal_mmap): Check
__x86_64__ instead of __WORDSIZE.
(internal_filesize): Likwise.
--- a/libsanitizer/sanitizer_common/sanitizer_linux.cc
+++ b/libsanitizer/sanitizer_common/sanitizer_linux.cc
@@ -34,7 +36,7 @@ namespace __sanitizer {
// --- sanitizer_libc.h
void *internal_mmap(void *addr, uptr length, int prot, int flags,
int fd, u64 offset) {
-#if __WORDSIZE == 64
+#if defined __x86_64__
return (void *)syscall(__NR_mmap, addr, length, prot, flags, fd, offset);
#else
return (void *)syscall(__NR_mmap2, addr, length, prot, flags, fd, offset);
@@ -67,7 +69,7 @@ uptr internal_write(fd_t fd, const void *buf, uptr count) {
}
uptr internal_filesize(fd_t fd) {
-#if __WORDSIZE == 64
+#if defined __x86_64__
struct stat st;
if (syscall(__NR_fstat, fd, st))
return -1;
Re: ASAN merge...
On 13/11/12 22:41, Andrew Pinski wrote:
On Tue, Nov 13, 2012 at 2:31 PM, Ramana Radhakrishnan
ramana@googlemail.com wrote:
On 13 Nov 2012, at 21:18, Konstantin Serebryany
konstantin.s.serebry...@gmail.com wrote:
On Tue, Nov 13, 2012 at 8:21 AM, Diego Novillo dnovi...@google.com wrote:
On Tue, Nov 13, 2012 at 12:07 AM, David Miller da...@davemloft.net wrote:
This has broken the build on every Linux target that hasn't added
the necessary cpu specific code to asan_linux.cc
This should be fixed by Dodji's recent patch. ASAN is not currently
ported to any target other than x86/linux, so it should just be
asan run-time (and the LLVM part) works on Mac and on ARM/Linux.
And when you say ARM / Linux, has this been tested on older versions of the
architecture or just v7-a ?
And this arm is really arm32 and not ARM64 :). People need to start
calling it arm32 to make sure they don't get confused between the two
different architectures.
Please please don't get into the habit of calling it ARM32 and ARM64,
you're just sowing confusion; there are good reasons why those names
weren't adopted (some technical, some not) and I'm not about to rehash
them all now. AArch32 and AArch64 aren't that much harder to type and
they are completely unambiguous.
If nothing else, remember that there were arm3 and arm6 chips at one
time, so we have patterns that match arm3* and arm6* to match those CPUs
(because people keep insisting on adding miscellaneous junk at the end
of the CPU field). At all costs we need to avoid getting false matches
in here, or chaos will ensue.
The architecture overall is ARM, the operating states within it are
AArch32 and AArch64. There is no ARM32 and there is no ARM64.
R.
Thanks
Andrew
But I'd suggest not to worry about any platforms other than
x86_{32,64}/Linux until the whole thing
(including tests) is fully integrated.
Ramana
--kcc
completely disabled until the other ports start showing up.
Dodji is your patch committed?
Diego.
[PATCH][ARM][1/2] ARMv8 aarch32 round to integral instructions
Hi all, This patch adds support for the vrint family of instructions in aarch32 (the 32-bit execution state in ARMv8). These are rounding instructions that can be used to implement round to integral functions from the math library such as: trunc, ceil, round, floor, nearbyint, rint. This patch implements the single and double precision variants of these functions. There is only one pattern for them in the machine description because it uses some new iterators to generate the correct variant for each function. The tests for this are coming in a second patch soon. These changes have been tested using AEM for the new functionality. Also, no regressions when testing for ARMv7-a (for which these changes should not have any effect) on qemu. Ok for trunk? Thanks, Kyrill gcc/ChangeLog 2012-11-14 Kyrylo Tkachov kyrylo.tkac...@arm.com * config/arm/arm.h (TARGET_FPU_ARMV8): New macro. * config/arm/arm.md (UNSPEC_VRINTZ, UNSPEC_VRINTP, UNSPEC_VRINTM, UNSPEC_VRINTR, UNSPEC_VRINTX, UNSPEC_VRINTA): New unspecs. (f_rints, f_rintd): New types. * config/arm/iterators.md (VRINT): New int iterator. (F_fma_type): Remove. (vfp_type): New mode attribute. (vfp_double_cond): Likewise. (vrint_pattern, vrint_variant, vrint_predicable): New int attribute. * config/arm/vfp.md (fmaSDF:mode4, *fmsubSDF:mode4, *fnmsubSDF:mode4, *fnmaddSDF:mode4): Use vfp_type iterator instead of F_fma_type. (VRINT:patternSDF:mode2): New pattern.--- a/gcc/config/arm/arm.h +++ b/gcc/config/arm/arm.h @@ -296,6 +296,9 @@ extern void (*arm_lang_output_object_att /* FPU supports fused-multiply-add operations. */ #define TARGET_FMA (TARGET_VFP arm_fpu_desc-rev = 4) +/* FPU is ARMv8 compatible. */ +#define TARGET_FPU_ARMV8 (TARGET_VFP arm_fpu_desc-rev = 8) + /* FPU supports Crypto extensions. */ #define TARGET_CRYPTO (TARGET_VFP arm_fpu_desc-crypto) diff --git a/gcc/config/arm/arm.md b/gcc/config/arm/arm.md index 7e92b69ad861fe90ed409494d451854f30888462.. 100644 --- a/gcc/config/arm/arm.md +++ b/gcc/config/arm/arm.md @@ -111,6 +111,18 @@ (define_c_enum unspec [ UNSPEC_UNALIGNED_STORE ; Same for str/strh. UNSPEC_PIC_UNIFIED; Create a common pic addressing form. UNSPEC_LL; Represent an unpaired load-register-exclusive. + UNSPEC_VRINTZ ; Represent a float to integral float rounding +; towards zero. + UNSPEC_VRINTP ; Represent a float to integral float rounding +; towards +Inf. + UNSPEC_VRINTM ; Represent a float to integral float rounding +; towards -Inf. + UNSPEC_VRINTR ; Represent a float to integral float rounding +; FPSCR rounding mode. + UNSPEC_VRINTX ; Represent a float to integral float rounding +; FPSCR rounding mode and signal inexactness. + UNSPEC_VRINTA ; Represent a float to integral float rounding +; towards nearest, ties away from zero. ]) ;; UNSPEC_VOLATILE Usage: @@ -366,6 +378,8 @@ (define_attr type fmuld,\ fmacs,\ fmacd,\ + f_rints,\ + f_rintd,\ f_flag,\ f_loads,\ f_loadd,\ diff --git a/gcc/config/arm/iterators.md b/gcc/config/arm/iterators.md index 0a34c82974a4b3f65bbd40032c5d33cc862be095.. 100644 --- a/gcc/config/arm/iterators.md +++ b/gcc/config/arm/iterators.md @@ -192,6 +192,13 @@ (define_code_iterator SE [sign_extend ze (define_code_iterator rshifts [ashiftrt lshiftrt]) ;; +;; Int iterators +;; + +(define_int_iterator VRINT [UNSPEC_VRINTZ UNSPEC_VRINTP UNSPEC_VRINTM +UNSPEC_VRINTR UNSPEC_VRINTX UNSPEC_VRINTA]) + +;; ;; Mode attributes ;; @@ -431,9 +438,10 @@ (define_mode_attr qaddsub_suf [(V4UQQ 8 ;; Mode attribute for vshll. (define_mode_attr V_innermode [(V8QI QI) (V4HI HI) (V2SI SI)]) -;; Mode attributes used for fused-multiply-accumulate VFP support +;; Mode attributes used for VFP support. (define_mode_attr F_constraint [(SF t) (DF w)]) -(define_mode_attr F_fma_type [(SF fmacs) (DF fmacd)]) +(define_mode_attr vfp_type [(SF s) (DF d)]) +(define_mode_attr vfp_double_cond [(SF ) (DF TARGET_VFP_DOUBLE)]) ;; ;; Code attributes @@ -457,3 +465,21 @@ (define_code_attr US [(sign_extend s) (define_code_attr shift [(ashiftrt ashr) (lshiftrt lshr)]) (define_code_attr shifttype [(ashiftrt signed) (lshiftrt unsigned)])
[PATCH][ARM][2/2] ARMv8 aarch32 round to integral instructions
Hi all,
This patch adds the new tests for the vrint instructions in aarch32.
It also adds an effective target check to see if we support an ARMv8 VFP and
an add_options
procedure for adding the required options to a testcase if we do.
Ok for trunk?
Thanks,
Kyrill
gcc/testsuite/ChangeLog
2012-11-14 Kyrylo Tkachov kyrylo.tkac...@arm.com
* lib/target-supports.exp (check_effective_target_arm_v8_vfp_ok):
New procedure.
(add_options_for_arm_v8_vfp): New procedure.
* gcc.target/arm/vrintaf32.c: New test.
* gcc.target/arm/vrintaf64.c: Likewise.
* gcc.target/arm/vrintmf32.c: Likewise.
* gcc.target/arm/vrintmf64.c: Likewise.
* gcc.target/arm/vrintpf32.c: Likewise.
* gcc.target/arm/vrintpf64.c: Likewise.
* gcc.target/arm/vrintrf32.c: Likewise.
* gcc.target/arm/vrintrf64.c: Likewise.
* gcc.target/arm/vrintxf32.c: Likewise.
* gcc.target/arm/vrintxf64.c: Likewise.
* gcc.target/arm/vrintzf32.c: Likewise.
* gcc.target/arm/vrintzf64.c: Likewise.diff --git a/gcc/testsuite/gcc.target/arm/vrintaf32.c
b/gcc/testsuite/gcc.target/arm/vrintaf32.c
new file mode 100644
index 000..b05ed9f
--- /dev/null
+++ b/gcc/testsuite/gcc.target/arm/vrintaf32.c
@@ -0,0 +1,12 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target arm_v8_vfp_ok } */
+/* { dg-options -O2 } */
+/* { dg-add-options arm_v8_vfp } */
+
+float
+foo (float x)
+{
+ return __builtin_roundf (x);
+}
+
+/* { dg-final { scan-assembler-times vrinta.f32\ts\[0-9\]+ 1 } } */
diff --git a/gcc/testsuite/gcc.target/arm/vrintaf64.c
b/gcc/testsuite/gcc.target/arm/vrintaf64.c
new file mode 100644
index 000..04a568e
--- /dev/null
+++ b/gcc/testsuite/gcc.target/arm/vrintaf64.c
@@ -0,0 +1,12 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target arm_v8_vfp_ok } */
+/* { dg-options -O2 } */
+/* { dg-add-options arm_v8_vfp } */
+
+double
+foo (double x)
+{
+ return __builtin_round (x);
+}
+
+/* { dg-final { scan-assembler-times vrinta.f64\td\[0-9\]+ 1 } } */
diff --git a/gcc/testsuite/gcc.target/arm/vrintmf32.c
b/gcc/testsuite/gcc.target/arm/vrintmf32.c
new file mode 100644
index 000..2e13ee3
--- /dev/null
+++ b/gcc/testsuite/gcc.target/arm/vrintmf32.c
@@ -0,0 +1,12 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target arm_v8_vfp_ok } */
+/* { dg-options -O2 } */
+/* { dg-add-options arm_v8_vfp } */
+
+float
+foo (float x)
+{
+ return __builtin_floorf (x);
+}
+
+/* { dg-final { scan-assembler-times vrintm.f32\ts\[0-9\]+ 1 } } */
diff --git a/gcc/testsuite/gcc.target/arm/vrintmf64.c
b/gcc/testsuite/gcc.target/arm/vrintmf64.c
new file mode 100644
index 000..4a29234
--- /dev/null
+++ b/gcc/testsuite/gcc.target/arm/vrintmf64.c
@@ -0,0 +1,12 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target arm_v8_vfp_ok } */
+/* { dg-options -O2 } */
+/* { dg-add-options arm_v8_vfp } */
+
+double
+foo (double x)
+{
+ return __builtin_floor (x);
+}
+
+/* { dg-final { scan-assembler-times vrintm.f64\td\[0-9\]+ 1 } } */
diff --git a/gcc/testsuite/gcc.target/arm/vrintpf32.c
b/gcc/testsuite/gcc.target/arm/vrintpf32.c
new file mode 100644
index 000..f936a62
--- /dev/null
+++ b/gcc/testsuite/gcc.target/arm/vrintpf32.c
@@ -0,0 +1,12 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target arm_v8_vfp_ok } */
+/* { dg-options -O2 } */
+/* { dg-add-options arm_v8_vfp } */
+
+float
+foo (float x)
+{
+ return __builtin_ceilf (x);
+}
+
+/* { dg-final { scan-assembler-times vrintp.f32\ts\[0-9\]+ 1 } } */
diff --git a/gcc/testsuite/gcc.target/arm/vrintpf64.c
b/gcc/testsuite/gcc.target/arm/vrintpf64.c
new file mode 100644
index 000..6d2a155
--- /dev/null
+++ b/gcc/testsuite/gcc.target/arm/vrintpf64.c
@@ -0,0 +1,12 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target arm_v8_vfp_ok } */
+/* { dg-options -O2 } */
+/* { dg-add-options arm_v8_vfp } */
+
+double
+foo (double x)
+{
+ return __builtin_ceil (x);
+}
+
+/* { dg-final { scan-assembler-times vrintp.f64\td\[0-9\]+ 1 } } */
diff --git a/gcc/testsuite/gcc.target/arm/vrintrf32.c
b/gcc/testsuite/gcc.target/arm/vrintrf32.c
new file mode 100644
index 000..e6ed0ac
--- /dev/null
+++ b/gcc/testsuite/gcc.target/arm/vrintrf32.c
@@ -0,0 +1,12 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target arm_v8_vfp_ok } */
+/* { dg-options -O2 } */
+/* { dg-add-options arm_v8_vfp } */
+
+float
+foo (float x)
+{
+ return __builtin_nearbyintf (x);
+}
+
+/* { dg-final { scan-assembler-times vrintr.f32\ts\[0-9\]+ 1 } } */
diff --git a/gcc/testsuite/gcc.target/arm/vrintrf64.c
b/gcc/testsuite/gcc.target/arm/vrintrf64.c
new file mode 100644
index 000..43613ff
--- /dev/null
+++ b/gcc/testsuite/gcc.target/arm/vrintrf64.c
@@ -0,0 +1,12 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target arm_v8_vfp_ok } */
+/* { dg-options -O2 } */
+/* { dg-add-options arm_v8_vfp } */
+
+double
+foo (double x)
+{
+ return __builtin_nearbyint (x);
+}
+
+/* { dg-final {
RE: [PATCH][ARM][1/2] ARMv8 aarch32 round to integral instructions
Sorry, the ChangeLog entry for vfp.md in the end should say: (vrint_patternSDF:mode2): New pattern. Instead of (VRINT:patternSDF:mode2): New pattern. -Original Message- From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-ow...@gcc.gnu.org] On Behalf Of Kyrylo Tkachov Sent: 14 November 2012 13:52 To: gcc-patches@gcc.gnu.org Cc: Richard Earnshaw; Ramana Radhakrishnan Subject: [PATCH][ARM][1/2] ARMv8 aarch32 round to integral instructions Hi all, This patch adds support for the vrint family of instructions in aarch32 (the 32-bit execution state in ARMv8). These are rounding instructions that can be used to implement round to integral functions from the math library such as: trunc, ceil, round, floor, nearbyint, rint. This patch implements the single and double precision variants of these functions. There is only one pattern for them in the machine description because it uses some new iterators to generate the correct variant for each function. The tests for this are coming in a second patch soon. These changes have been tested using AEM for the new functionality. Also, no regressions when testing for ARMv7-a (for which these changes should not have any effect) on qemu. Ok for trunk? Thanks, Kyrill gcc/ChangeLog 2012-11-14 Kyrylo Tkachov kyrylo.tkac...@arm.com * config/arm/arm.h (TARGET_FPU_ARMV8): New macro. * config/arm/arm.md (UNSPEC_VRINTZ, UNSPEC_VRINTP, UNSPEC_VRINTM, UNSPEC_VRINTR, UNSPEC_VRINTX, UNSPEC_VRINTA): New unspecs. (f_rints, f_rintd): New types. * config/arm/iterators.md (VRINT): New int iterator. (F_fma_type): Remove. (vfp_type): New mode attribute. (vfp_double_cond): Likewise. (vrint_pattern, vrint_variant, vrint_predicable): New int attribute. * config/arm/vfp.md (fmaSDF:mode4, *fmsubSDF:mode4, *fnmsubSDF:mode4, *fnmaddSDF:mode4): Use vfp_type iterator instead of F_fma_type. (VRINT:patternSDF:mode2): New pattern.
[PATCH} Enable libsanitizer on darwin
The attached patch assumes that mach_override/mach_override.h
and mach_override/mach_override.c has been imported by the libsanitizer
maintainers for use by darwin. The patch adds darwin to the supported
target list in configure.tgt and defines USING_MACH_OVERRIDE for darwin
in configure.ac. The definition of USING_MACH_OVERRIDE is used in
Makefile.am as the test for appending mach_override/mach_override.c
to libinterception_la_SOURCES. Tested on x86_64-apple-darwin12 against
the mach_override/mach_override.h and mach_override/mach_override.c
from llvm compiler-rt 3.2 branch. While there is some noise on the
output of asan...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55289#c14
the functionality of asan appears to be intact. Okay for gcc trunk
after the libsanitizer maintainers import the missing
mach_override/mach_override.h
and mach_override/mach_override.c files?
Jack
ps Note that this patch assumes that both mach_override.h and mach_override.c
reside in a mach_override subdirectory in interception as is the case in the
llvm's compiler-rt.
libsanitizer/
2012-11-14 Jack Howarth howa...@bromo.med.uc.edu
* configure.tgt: Add darwin to supported targets.
* configure.ac: Define USING_MACH_OVERRIDE when on darwin.
* interception/Makefile.am: Compile mach_override.c when
USING_MACH_OVERRIDE defined.
* configure: Regenerated.
* interception/Makefile.in: Likewise.
Index: libsanitizer/interception/Makefile.am
===
--- libsanitizer/interception/Makefile.am (revision 193500)
+++ libsanitizer/interception/Makefile.am (working copy)
@@ -11,7 +11,11 @@ interception_files = \
interception_mac.cc \
interception_win.cc
-libinterception_la_SOURCES = $(interception_files)
+if USING_MACH_OVERRIDE
+libinterception_la_SOURCES = $(interception_files)
mach_override/mach_override.c
+else
+libinterception_la_SOURCES = $(interception_files)
+endif
# Work around what appears to be a GNU make bug handling MAKEFLAGS
# values defined in terms of make variables, as is the case for CC and
Index: libsanitizer/configure.ac
===
--- libsanitizer/configure.ac (revision 193500)
+++ libsanitizer/configure.ac (working copy)
@@ -17,6 +17,12 @@ AM_PROG_LIBTOOL
AC_SUBST(enable_shared)
AC_SUBST(enable_static)
+case $host in
+ *-*-darwin*) MACH_OVERRIDE=true ;;
+ *) MACH_OVERRIDE=false ;;
+esac
+AM_CONDITIONAL(USING_MACH_OVERRIDE, $MACH_OVERRIDE)
+
#AM_ENABLE_MULTILIB(, ..)
target_alias=${target_alias-$host_alias}
AC_SUBST(target_alias)
Index: libsanitizer/configure.tgt
===
--- libsanitizer/configure.tgt (revision 193500)
+++ libsanitizer/configure.tgt (working copy)
@@ -20,7 +20,7 @@
# Filter out unsupported systems.
case ${target} in
- x86_64-*-linux* | i?86-*-linux*)
+ x86_64-*-linux* | i?86-*-linux* | *-*-darwin* )
;;
*)
UNSUPPORTED=1
RE: [RFC PATCH] Masked load/store vectorization
Hi Jakub, I looked through your patch that looks good enough although it likely must be improved to get better vectorization for AVX-2. One general issue is that you introduced a new pass to undo if-conversion leading to one restriction on if-conversion that prohibited to chain the conditions: /* Avoid creating mask loads/stores if we'd need to chain conditions, to make it easier to undo them. */ I assume that you can do it without undo but simply creating a copy of handled loop and restoring/deletion it in case of fail or success (such approach is used by many compilers for software-pipelining loops aka modulo scheduling). Is it difficult to implement in gcc framework or you simply missed it. Also the current implementation is base on if-conversion although predication is more preferable for it and can allow us to vectorize more loop patterns. What is your opinion? Best regards. Yuri.
Re: [PATCH} Enable libsanitizer on darwin
Jack Howarth howa...@bromo.med.uc.edu writes:
Index: libsanitizer/configure.tgt
===
--- libsanitizer/configure.tgt(revision 193500)
+++ libsanitizer/configure.tgt(working copy)
@@ -20,7 +20,7 @@
# Filter out unsupported systems.
case ${target} in
- x86_64-*-linux* | i?86-*-linux*)
+ x86_64-*-linux* | i?86-*-linux* | *-*-darwin* )
;;
*)
UNSUPPORTED=1
Please no: keep the case labels sorted alphabetically by target,
something like
case i?86-*-linux* | x86_64-*-linux*)
;;
case *-*-darwin*)
;;
Although I suppose this is wrong: currently, libsanitizer only supports
x86, not powerpc.
Rainer
--
-
Rainer Orth, Center for Biotechnology, Bielefeld University
[PATCH][Revised] Enable libsanitizer on darwin
The attached patch assumes that mach_override/mach_override.h
and mach_override/mach_override.c has been imported by the libsanitizer
maintainers for use by darwin. The patch adds darwin to the supported
target list in configure.tgt and defines USING_MACH_OVERRIDE for darwin
in configure.ac. The definition of USING_MACH_OVERRIDE is used in
Makefile.am as the test for appending mach_override/mach_override.c
to libinterception_la_SOURCES. Tested on x86_64-apple-darwin12 against
the mach_override/mach_override.h and mach_override/mach_override.c
from llvm compiler-rt 3.2 branch. While there is some noise on the
output of asan...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55289#c14
the functionality of asan appears to be intact. Okay for gcc trunk
after the libsanitizer maintainers import the missing
mach_override/mach_override.h
and mach_override/mach_override.c files?
Jack
ps Note that this patch assumes that both mach_override.h and mach_override.c
reside in a mach_override subdirectory in interception as is the case in the
llvm's compiler-rt.
pps Patch to configure.tgt revised to use a distinct instance for darwin in
the case statement and to limit libsanitizer to i?86 and x86_64 on darwin.
libsanitizer/
2012-11-14 Jack Howarth howa...@bromo.med.uc.edu
* configure.tgt: Add darwin to supported targets.
* configure.ac: Define USING_MACH_OVERRIDE when on darwin.
* interception/Makefile.am: Compile mach_override.c when
USING_MACH_OVERRIDE defined.
* configure: Regenerated.
* interception/Makefile.in: Likewise.
Index: libsanitizer/interception/Makefile.am
===
--- libsanitizer/interception/Makefile.am (revision 193500)
+++ libsanitizer/interception/Makefile.am (working copy)
@@ -11,7 +11,11 @@ interception_files = \
interception_mac.cc \
interception_win.cc
-libinterception_la_SOURCES = $(interception_files)
+if USING_MACH_OVERRIDE
+libinterception_la_SOURCES = $(interception_files)
mach_override/mach_override.c
+else
+libinterception_la_SOURCES = $(interception_files)
+endif
# Work around what appears to be a GNU make bug handling MAKEFLAGS
# values defined in terms of make variables, as is the case for CC and
Index: libsanitizer/configure.ac
===
--- libsanitizer/configure.ac (revision 193500)
+++ libsanitizer/configure.ac (working copy)
@@ -17,6 +17,12 @@ AM_PROG_LIBTOOL
AC_SUBST(enable_shared)
AC_SUBST(enable_static)
+case $host in
+ *-*-darwin*) MACH_OVERRIDE=true ;;
+ *) MACH_OVERRIDE=false ;;
+esac
+AM_CONDITIONAL(USING_MACH_OVERRIDE, $MACH_OVERRIDE)
+
#AM_ENABLE_MULTILIB(, ..)
target_alias=${target_alias-$host_alias}
AC_SUBST(target_alias)
Index: libsanitizer/configure.tgt
===
--- libsanitizer/configure.tgt (revision 193500)
+++ libsanitizer/configure.tgt (working copy)
@@ -22,6 +22,8 @@
case ${target} in
x86_64-*-linux* | i?86-*-linux*)
;;
+ x86_64-*-darwin* | i?86-*-darwin*)
+ ;;
*)
UNSUPPORTED=1
;;
Re: [PATCH] Copy libsanitizer from llvm at revision 167890
Rainer Orth writes: H.J. Lu hjl.to...@gmail.com writes: We don't have a maintainer is a problem, not go upstream first. Agreed. I've no idea if the SC appointed one when it accepted libsanitizer etc. into GCC. Instead of guessing and complaining about the GCC SC, have you two thought of actually looking at the announcement? http://gcc.gnu.org/ml/gcc/2012-11/msg00016.html ASAN refers to both the GCC bits and libsanitizer. The appointed maintainers should have added their names to the GCC MAINTAINERS file. And, H.J, you should not try to merge things that you do not understand. Thanks, David
Re: Fix bootstrap on non-ifunc capable targets (i386)
On 14.11.12 11:51, Uros Bizjak wrote: Hello! this commit: 193486 broke bootstrap on targets which do not have HAVE_GNU_INDIRECT_FUNCTION. Ok to commit? OK, with appropriate ChangeLog entry and if bootstrapped correctly on both, IFUNC and non-IFUNC capable target. Ok, below the foreseen CL. Bootstrap on x86_64-unknown-freebsd10.0 passed, bootstrap on x86_64-unknown-linux-gnu in progress. But passed stage 2 where the break happened on FreeBSD. (unused parameter) Thanks, Andreas 2012-11-14 Andreas Tobler andre...@fgznet.ch * config/i386/i386.c (ix86_get_function_versions_dispatcher): Guard variables with ASM_OUTPUT_TYPE_DIRECTIVE and HAVE_GNU_INDIRECT_FUNCTION where needed.
Re: [PATCH][Revised] Enable libsanitizer on darwin
Hi Jack,
most certainly the functionality of asan is not intact.
The error messages denote that mach_override couldn't parse some of
the function prologues, which means some of ASan interceptors just
won't work.
In order to fix this you need to change the DEBUG definition in
mach_override.c, look at the bytes being parsed and fix the
instruction table in mach_override.c
Please also send a patch to LLVM containing the fix (sending the patch
to the original mach_override repo makes little sense, because we've
forked it long time ago).
HTH,
Alex
On Wed, Nov 14, 2012 at 6:43 PM, Jack Howarth howa...@bromo.med.uc.edu wrote:
The attached patch assumes that mach_override/mach_override.h
and mach_override/mach_override.c has been imported by the libsanitizer
maintainers for use by darwin. The patch adds darwin to the supported
target list in configure.tgt and defines USING_MACH_OVERRIDE for darwin
in configure.ac. The definition of USING_MACH_OVERRIDE is used in
Makefile.am as the test for appending mach_override/mach_override.c
to libinterception_la_SOURCES. Tested on x86_64-apple-darwin12 against
the mach_override/mach_override.h and mach_override/mach_override.c
from llvm compiler-rt 3.2 branch. While there is some noise on the
output of asan...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55289#c14
the functionality of asan appears to be intact. Okay for gcc trunk
after the libsanitizer maintainers import the missing
mach_override/mach_override.h
and mach_override/mach_override.c files?
Jack
ps Note that this patch assumes that both mach_override.h and mach_override.c
reside in a mach_override subdirectory in interception as is the case in the
llvm's compiler-rt.
pps Patch to configure.tgt revised to use a distinct instance for darwin in
the case statement and to limit libsanitizer to i?86 and x86_64 on darwin.
libsanitizer/
2012-11-14 Jack Howarth howa...@bromo.med.uc.edu
* configure.tgt: Add darwin to supported targets.
* configure.ac: Define USING_MACH_OVERRIDE when on darwin.
* interception/Makefile.am: Compile mach_override.c when
USING_MACH_OVERRIDE defined.
* configure: Regenerated.
* interception/Makefile.in: Likewise.
Index: libsanitizer/interception/Makefile.am
===
--- libsanitizer/interception/Makefile.am (revision 193500)
+++ libsanitizer/interception/Makefile.am (working copy)
@@ -11,7 +11,11 @@ interception_files = \
interception_mac.cc \
interception_win.cc
-libinterception_la_SOURCES = $(interception_files)
+if USING_MACH_OVERRIDE
+libinterception_la_SOURCES = $(interception_files)
mach_override/mach_override.c
+else
+libinterception_la_SOURCES = $(interception_files)
+endif
# Work around what appears to be a GNU make bug handling MAKEFLAGS
# values defined in terms of make variables, as is the case for CC and
Index: libsanitizer/configure.ac
===
--- libsanitizer/configure.ac (revision 193500)
+++ libsanitizer/configure.ac (working copy)
@@ -17,6 +17,12 @@ AM_PROG_LIBTOOL
AC_SUBST(enable_shared)
AC_SUBST(enable_static)
+case $host in
+ *-*-darwin*) MACH_OVERRIDE=true ;;
+ *) MACH_OVERRIDE=false ;;
+esac
+AM_CONDITIONAL(USING_MACH_OVERRIDE, $MACH_OVERRIDE)
+
#AM_ENABLE_MULTILIB(, ..)
target_alias=${target_alias-$host_alias}
AC_SUBST(target_alias)
Index: libsanitizer/configure.tgt
===
--- libsanitizer/configure.tgt (revision 193500)
+++ libsanitizer/configure.tgt (working copy)
@@ -22,6 +22,8 @@
case ${target} in
x86_64-*-linux* | i?86-*-linux*)
;;
+ x86_64-*-darwin* | i?86-*-darwin*)
+ ;;
*)
UNSUPPORTED=1
;;
--
Alexander Potapenko
Software Engineer
Google Moscow
Re: [PATCH][Revised] Enable libsanitizer on darwin
Hi Alex, most certainly the functionality of asan is not intact. The error messages denote that mach_override couldn't parse some of the function prologues, which means some of ASan interceptors just won't work. In order to fix this you need to change the DEBUG definition in mach_override.c, look at the bytes being parsed and fix the instruction table in mach_override.c is there some guideline how to port asan to a new OS or CPU? That would certainly be easier than figuring things out on your own one by one. I guess several target and os port maintainers would want to do so in GCC. Thanks. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [PATCH][Revised] Enable libsanitizer on darwin
On Wed, Nov 14, 2012 at 07:00:14PM +0400, Alexander Potapenko wrote:
Hi Jack,
most certainly the functionality of asan is not intact.
The error messages denote that mach_override couldn't parse some of
the function prologues, which means some of ASan interceptors just
won't work.
In order to fix this you need to change the DEBUG definition in
mach_override.c, look at the bytes being parsed and fix the
instruction table in mach_override.c
Please also send a patch to LLVM containing the fix (sending the patch
to the original mach_override repo makes little sense, because we've
forked it long time ago).
HTH,
Alex
Alex,
I have alway done some of this...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55289#c11
It seems to be related to the comments found in mach_override.c...
#elif defined(__x86_64__)
// TODO(glider): disassembling the 0x48, 0x89 sequences is trickier than it's
done below.
// If it stops working, refer to
http://ref.x86asm.net/geek.html#modrm_byte_32_64 to do it
// more accurately.
// Note: 0x48 is in fact the REX.W prefix, but it might be wrong to treat it as
a separate
// instruction.
It is interesting the the same code for mach_override.h/mach_override.c from
llvm-3.2 used under clang 3.2 doesn't trigger this issue.
Jack
On Wed, Nov 14, 2012 at 6:43 PM, Jack Howarth howa...@bromo.med.uc.edu
wrote:
The attached patch assumes that mach_override/mach_override.h
and mach_override/mach_override.c has been imported by the libsanitizer
maintainers for use by darwin. The patch adds darwin to the supported
target list in configure.tgt and defines USING_MACH_OVERRIDE for darwin
in configure.ac. The definition of USING_MACH_OVERRIDE is used in
Makefile.am as the test for appending mach_override/mach_override.c
to libinterception_la_SOURCES. Tested on x86_64-apple-darwin12 against
the mach_override/mach_override.h and mach_override/mach_override.c
from llvm compiler-rt 3.2 branch. While there is some noise on the
output of asan...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55289#c14
the functionality of asan appears to be intact. Okay for gcc trunk
after the libsanitizer maintainers import the missing
mach_override/mach_override.h
and mach_override/mach_override.c files?
Jack
ps Note that this patch assumes that both mach_override.h and
mach_override.c
reside in a mach_override subdirectory in interception as is the case in the
llvm's compiler-rt.
pps Patch to configure.tgt revised to use a distinct instance for darwin in
the case statement and to limit libsanitizer to i?86 and x86_64 on darwin.
libsanitizer/
2012-11-14 Jack Howarth howa...@bromo.med.uc.edu
* configure.tgt: Add darwin to supported targets.
* configure.ac: Define USING_MACH_OVERRIDE when on darwin.
* interception/Makefile.am: Compile mach_override.c when
USING_MACH_OVERRIDE defined.
* configure: Regenerated.
* interception/Makefile.in: Likewise.
Index: libsanitizer/interception/Makefile.am
===
--- libsanitizer/interception/Makefile.am (revision 193500)
+++ libsanitizer/interception/Makefile.am (working copy)
@@ -11,7 +11,11 @@ interception_files = \
interception_mac.cc \
interception_win.cc
-libinterception_la_SOURCES = $(interception_files)
+if USING_MACH_OVERRIDE
+libinterception_la_SOURCES = $(interception_files)
mach_override/mach_override.c
+else
+libinterception_la_SOURCES = $(interception_files)
+endif
# Work around what appears to be a GNU make bug handling MAKEFLAGS
# values defined in terms of make variables, as is the case for CC and
Index: libsanitizer/configure.ac
===
--- libsanitizer/configure.ac (revision 193500)
+++ libsanitizer/configure.ac (working copy)
@@ -17,6 +17,12 @@ AM_PROG_LIBTOOL
AC_SUBST(enable_shared)
AC_SUBST(enable_static)
+case $host in
+ *-*-darwin*) MACH_OVERRIDE=true ;;
+ *) MACH_OVERRIDE=false ;;
+esac
+AM_CONDITIONAL(USING_MACH_OVERRIDE, $MACH_OVERRIDE)
+
#AM_ENABLE_MULTILIB(, ..)
target_alias=${target_alias-$host_alias}
AC_SUBST(target_alias)
Index: libsanitizer/configure.tgt
===
--- libsanitizer/configure.tgt (revision 193500)
+++ libsanitizer/configure.tgt (working copy)
@@ -22,6 +22,8 @@
case ${target} in
x86_64-*-linux* | i?86-*-linux*)
;;
+ x86_64-*-darwin* | i?86-*-darwin*)
+ ;;
*)
UNSUPPORTED=1
;;
--
Alexander Potapenko
Software Engineer
Google Moscow
[PATCH 0/2] Update soft-fp from GLIBC
Folks, libgcc's soft-fp is based on GLIBC's soft-fp. In the patch [1/2] I've brought across the latest bug fixes from GLIBC. These changes include a dependence on relevant targets (aarch64, ia64, i386) providing a definition of FP_TRAPPING_EXCEPTIONS. The patch [2/2] provides an aarch64 definition of FP_TRAPPING_EXCEPTIONS. Would any of the maintainers for IA64 and i386 be able to help out with FP_TRAPPING_EXCEPTION definitions for their targets? The IA64 implementation looks reasonably straight forward and I can post an untested patch if that is helpful. Thanks /Marcus
[PATCH 1/2] Update soft-fp from GLIBC
This patch updates libgcc/soft-fp from GLIBC/soft-fp.
/Marcus
2012-11-14 Marcus Shawcroft marcus.shawcr...@arm.com
* soft-fp: Updated from glibc upstream.diff --git a/libgcc/soft-fp/op-common.h b/libgcc/soft-fp/op-common.h
index b70026f..12fb16e 100644
--- a/libgcc/soft-fp/op-common.h
+++ b/libgcc/soft-fp/op-common.h
@@ -1,5 +1,5 @@
/* Software floating-point emulation. Common operations.
- Copyright (C) 1997,1998,1999,2006,2007 Free Software Foundation, Inc.
+ Copyright (C) 1997,1998,1999,2006,2007,2012 Free Software Foundation, Inc.
This file is part of the GNU C Library.
Contributed by Richard Henderson (r...@cygnus.com),
Jakub Jelinek (j...@ultra.linux.cz),
@@ -134,6 +134,12 @@ do { \
#define _FP_PACK_SEMIRAW(fs, wc, X)\
do {\
_FP_ROUND(wc, X); \
+ if (X##_e == 0 !_FP_FRAC_ZEROP_##wc(X)) \
+ { \
+ if ((FP_CUR_EXCEPTIONS FP_EX_INEXACT) \
+ || (FP_TRAPPING_EXCEPTIONS FP_EX_UNDERFLOW)) \
+ FP_SET_EXCEPTION(FP_EX_UNDERFLOW); \
+ } \
if (_FP_FRAC_HIGH_##fs(X) \
(_FP_OVERFLOW_##fs 1))\
{\
@@ -143,20 +149,15 @@ do {\
_FP_OVERFLOW_SEMIRAW(fs, wc, X); \
}\
_FP_FRAC_SRL_##wc(X, _FP_WORKBITS);\
- if (!_FP_EXP_NORMAL(fs, wc, X) !_FP_FRAC_ZEROP_##wc(X)) \
+ if (X##_e == _FP_EXPMAX_##fs !_FP_FRAC_ZEROP_##wc(X)) \
{\
- if (X##_e == 0) \
- FP_SET_EXCEPTION(FP_EX_UNDERFLOW); \
- else \
+ if (!_FP_KEEPNANFRACP) \
{ \
- if (!_FP_KEEPNANFRACP)\
- { \
- _FP_FRAC_SET_##wc(X, _FP_NANFRAC_##fs); \
- X##_s = _FP_NANSIGN_##fs;\
- } \
- else \
- _FP_FRAC_HIGH_RAW_##fs(X) |= _FP_QNANBIT_##fs; \
+ _FP_FRAC_SET_##wc(X, _FP_NANFRAC_##fs); \
+ X##_s = _FP_NANSIGN_##fs;\
} \
+ else \
+ _FP_FRAC_HIGH_RAW_##fs(X) |= _FP_QNANBIT_##fs; \
}\
} while (0)
@@ -226,13 +227,16 @@ do {\
{ \
X##_e = 1; \
_FP_FRAC_SET_##wc(X, _FP_ZEROFRAC_##wc); \
+ FP_SET_EXCEPTION(FP_EX_INEXACT); \
} \
else \
{ \
X##_e = 0; \
_FP_FRAC_SRL_##wc(X, _FP_WORKBITS); \
- FP_SET_EXCEPTION(FP_EX_UNDERFLOW); \
} \
+ if ((FP_CUR_EXCEPTIONS FP_EX_INEXACT) \
+ || (FP_TRAPPING_EXCEPTIONS FP_EX_UNDERFLOW)) \
+ FP_SET_EXCEPTION(FP_EX_UNDERFLOW); \
} \
else \
{ \
diff --git a/libgcc/soft-fp/soft-fp.h b/libgcc/soft-fp/soft-fp.h
index 46cb1cf..49a8770 100644
--- a/libgcc/soft-fp/soft-fp.h
+++ b/libgcc/soft-fp/soft-fp.h
@@ -128,6 +128,13 @@
#define FP_CLEAR_EXCEPTIONS\
_fex = 0
+#define FP_CUR_EXCEPTIONS\
+ (_fex)
+
+#ifndef FP_TRAPPING_EXCEPTIONS
+#define FP_TRAPPING_EXCEPTIONS 0
+#endif
+
#define _FP_ROUND_NEAREST(wc, X) \
do { \
if ((_FP_FRAC_LOW_##wc(X) 15) != _FP_WORK_ROUND) \
@@ -151,22 +158,24 @@ do { \
#define _FP_ROUND(wc, X) \
do { \
if (_FP_FRAC_LOW_##wc(X) 7) \
- FP_SET_EXCEPTION(FP_EX_INEXACT); \
- switch (FP_ROUNDMODE) \
- { \
- case FP_RND_NEAREST: \
- _FP_ROUND_NEAREST(wc,X); \
- break;\
- case FP_RND_ZERO: \
- _FP_ROUND_ZERO(wc,X); \
- break;\
- case FP_RND_PINF: \
- _FP_ROUND_PINF(wc,X); \
- break;\
- case FP_RND_MINF: \
- _FP_ROUND_MINF(wc,X); \
- break;\
- } \
+ { \
+ FP_SET_EXCEPTION(FP_EX_INEXACT); \
+ switch (FP_ROUNDMODE) \
+ { \
+ case FP_RND_NEAREST: \
+ _FP_ROUND_NEAREST(wc,X); \
+ break;\
+ case FP_RND_ZERO: \
+ _FP_ROUND_ZERO(wc,X); \
+ break;\
+ case FP_RND_PINF: \
+ _FP_ROUND_PINF(wc,X); \
+ break;\
+ case FP_RND_MINF: \
+ _FP_ROUND_MINF(wc,X); \
+ break;\
+ } \
+ } \
} while (0)
#define FP_CLS_NORMAL 0
[PATCH 2/2] Update soft-fp from GLIBC
This patch provides a definition of FP_TRAPPING_EXCEPTION for aarch64. /Marcus 2012-11-14 Marcus Shawcroft marcus.shawcr...@arm.com * config/aarch64/sfp-machine.h (FP_EX_ALL): Define. (FP_EX_SHIFT): Define. (FP_TRAPPING_EXCEPTIONS): Define.diff --git a/libgcc/config/aarch64/sfp-machine.h b/libgcc/config/aarch64/sfp-machine.h index 6c56a92..52b6fb2 100644 --- a/libgcc/config/aarch64/sfp-machine.h +++ b/libgcc/config/aarch64/sfp-machine.h @@ -69,6 +69,10 @@ typedef int __gcc_CMPtype __attribute__ ((mode (__libgcc_cmp_return__))); #define FP_EX_OVERFLOW 0x04 #define FP_EX_UNDERFLOW 0x08 #define FP_EX_INEXACT 0x10 +#define FP_EX_SHIFT 8 +#define FP_EX_ALL \ + (FP_EX_INVALID | FP_EX_DIVZERO | FP_EX_OVERFLOW | FP_EX_UNDERFLOW \ + | FP_EX_INEXACT) void __sfp_handle_exceptions (int); @@ -78,6 +82,8 @@ void __sfp_handle_exceptions (int); __sfp_handle_exceptions (_fex); \ } while (0); +#define FP_TRAPPING_EXCEPTIONS ((_fpcr FP_EX_SHIFT) FP_EX_ALL) + #define FP_RND_NEAREST 0x00 #define FP_RND_PINF 0x40 #define FP_RND_MINF 0x80
Re: [PATCH][Revised] Enable libsanitizer on darwin
On Wed, Nov 14, 2012 at 04:08:06PM +0100, Rainer Orth wrote: Hi Alex, most certainly the functionality of asan is not intact. The error messages denote that mach_override couldn't parse some of the function prologues, which means some of ASan interceptors just won't work. In order to fix this you need to change the DEBUG definition in mach_override.c, look at the bytes being parsed and fix the instruction table in mach_override.c is there some guideline how to port asan to a new OS or CPU? That would certainly be easier than figuring things out on your own one by one. I guess several target and os port maintainers would want to do so in GCC. Thanks. Rainer I am confused on the strategy here. Will the FSF gcc developers be prohibiting the addition of darwin support for libsanitizer until all issues in its operation are resolved? It seems like a chicken and egg situation. I think this should be considered an experimental feature and exposed to as many developers as possible so we can get some help on resolving these issues in mach_override.c. Making it unnecessarily difficult to build this feature doesn't help with that project. Jack -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [PATCH][Revised] Enable libsanitizer on darwin
Jack Howarth howa...@bromo.med.uc.edu writes: I am confused on the strategy here. Will the FSF gcc developers be prohibiting the addition of darwin support for libsanitizer until all issues in its operation are resolved? It seems like a chicken and egg situation. I think this should be considered an experimental feature and exposed to as many developers as possible so we can get some help on resolving these issues in mach_override.c. Making it unnecessarily difficult to build this feature doesn't help with that project. Where do you get this idea? OTOH, I think it makes sense to only install asan patches and enable it once a reasonable subset of its testsuite (once that's in place) works on a target. Until that point, the necessary patches can be kept in mailing list postings for developers working on that stuff (if more than one). Who is served by installing patches for micro steps that maybe allow libasan to compile, but not do anything useful? Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [PATCH][Revised] Enable libsanitizer on darwin
Hi Rainer, The quick answer is no, although the expansion into GCC world may require such a guideline. We've initially implemented ASan on Linux and then ported it to Android (which is very similar to Linux) and Mac (which is very different), so we have little experience with porting yet. I've summarized the differences between Linux and Mac here: https://code.google.com/p/address-sanitizer/wiki/AddressSanitizerForMacImplementationDetails The core things to pay attention at are function wrapping (e.g. dlsym on Linux, mach_override on Mac), hooking the allocations/deallocations in the program, stack unwinding (already done for x86 and ARM), thread creation, early initialization, debug info and symbolization. Maybe something else. In fact if any of these points work on your platform differently than they do on Linux/Mac, you'll have to re-implement those. Regarding mach_override, it's a Mac OS-specific thing that we use because dlsym doesn't reliably override functions (keywords: two-level namespace) This only works on x86/x86_64 and is just a bunch of ad-hoc hacks to hot-patch the library code. Extending the instruction table in mach_override.c is irrelevant to porting, it's just a mean of making it work with some newer libraries provided by Apple. It won't work on any other OS (well, without some refactoring; in fact it's possible to use it on Linux) or any other arch (one could rewrite mach_override.c for ARM, but iOS doesn't allow code patching). I'm working on a replacement for mach_override, which will compile libasan as a dynamic library on Mac OS and preload it before running the program. It's not ready yet, so the easiest thing for GCC will be to add some more instructions to mach_override and stick to it for now. Alex On Wed, Nov 14, 2012 at 7:08 PM, Rainer Orth r...@cebitec.uni-bielefeld.de wrote: Hi Alex, most certainly the functionality of asan is not intact. The error messages denote that mach_override couldn't parse some of the function prologues, which means some of ASan interceptors just won't work. In order to fix this you need to change the DEBUG definition in mach_override.c, look at the bytes being parsed and fix the instruction table in mach_override.c is there some guideline how to port asan to a new OS or CPU? That would certainly be easier than figuring things out on your own one by one. I guess several target and os port maintainers would want to do so in GCC. Thanks. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University -- Alexander Potapenko Software Engineer Google Moscow
Re: [PATCH][Revised] Enable libsanitizer on darwin
Hi Alex, The quick answer is no, although the expansion into GCC world may require such a guideline. We've initially implemented ASan on Linux and then ported it to Android (which is very similar to Linux) and Mac (which is very different), so we have little experience with porting yet. I've summarized the differences between Linux and Mac here: https://code.google.com/p/address-sanitizer/wiki/AddressSanitizerForMacImplementationDetails thanks, that's certainly helpful. I'm primarily interested in porting to Solaris, both SPARC and x86. Several things should be similar to Linux (both being ELF systems), while other areas are certainly different (syscalls implementation etc.). The core things to pay attention at are function wrapping (e.g. dlsym on Linux, mach_override on Mac), hooking the allocations/deallocations in the program, stack unwinding (already done for x86 and ARM), thread creation, early initialization, debug info and symbolization. Maybe something else. In fact if any of these points work on your platform differently than they do on Linux/Mac, you'll have to re-implement those. I'll certainly be looking around. One problem I see with the current code organization is duplication between different platforms: e.g. considerable parts of sanitizer_mac.cc and a new sanitizer_solaris.cc are identical. Perhaps we need more granularity in the future, but that can be decided once an initial port (with duplication to avoid treading on other port's feet) is done. At the same time, we should add infrastructure (like libffi) to only compile target-specific code on the relevant platforms, instead of wrapping every source file in #ifdef __linux__ or similar and extending the conditionals once a new platform is added. Regarding mach_override, it's a Mac OS-specific thing that we use because dlsym doesn't reliably override functions (keywords: two-level namespace) This only works on x86/x86_64 and is just a bunch of ad-hoc hacks to hot-patch the library code. Extending the instruction table in mach_override.c is irrelevant to porting, it's just a mean of making it work with some newer libraries provided by Apple. It won't work on any other OS (well, without some refactoring; in fact it's possible to use it on Linux) or any other arch (one could rewrite mach_override.c for ARM, but iOS doesn't allow code patching). I'm working on a replacement for mach_override, which will compile libasan as a dynamic library on Mac OS and preload it before running the program. It's not ready yet, so the easiest thing for GCC will be to add some more instructions to mach_override and stick to it for now. This hopefully won't be an issue on Solaris where dlsym should work the same as on Linux. Thanks. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [PATCH][Revised] Enable libsanitizer on darwin
On Wed, Nov 14, 2012 at 07:56:18PM +0400, Alexander Potapenko wrote: Hi Rainer, The quick answer is no, although the expansion into GCC world may require such a guideline. We've initially implemented ASan on Linux and then ported it to Android (which is very similar to Linux) and Mac (which is very different), so we have little experience with porting yet. I've summarized the differences between Linux and Mac here: https://code.google.com/p/address-sanitizer/wiki/AddressSanitizerForMacImplementationDetails The core things to pay attention at are function wrapping (e.g. dlsym on Linux, mach_override on Mac), hooking the allocations/deallocations in the program, stack unwinding (already done for x86 and ARM), thread creation, early initialization, debug info and symbolization. Maybe something else. In fact if any of these points work on your platform differently than they do on Linux/Mac, you'll have to re-implement those. Regarding mach_override, it's a Mac OS-specific thing that we use because dlsym doesn't reliably override functions (keywords: two-level namespace) This only works on x86/x86_64 and is just a bunch of ad-hoc hacks to hot-patch the library code. Extending the instruction table in mach_override.c is irrelevant to porting, it's just a mean of making it work with some newer libraries provided by Apple. It won't work on any other OS (well, without some refactoring; in fact it's possible to use it on Linux) or any other arch (one could rewrite mach_override.c for ARM, but iOS doesn't allow code patching). I'm working on a replacement for mach_override, which will compile libasan as a dynamic library on Mac OS and preload it before running the program. It's not ready yet, so the easiest thing for GCC will be to add some more instructions to mach_override and stick to it for now. Alex, Please see... http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55289#c27 So far for all the test cases that I have looked at, the problem seems to be when mach_overrride.c hits the opcodes... 48 8d 5 Can you suggest a patch for that one? It may be the only blocker to asan support on darwin (for x86_64 anyway). Jack Alex On Wed, Nov 14, 2012 at 7:08 PM, Rainer Orth r...@cebitec.uni-bielefeld.de wrote: Hi Alex, most certainly the functionality of asan is not intact. The error messages denote that mach_override couldn't parse some of the function prologues, which means some of ASan interceptors just won't work. In order to fix this you need to change the DEBUG definition in mach_override.c, look at the bytes being parsed and fix the instruction table in mach_override.c is there some guideline how to port asan to a new OS or CPU? That would certainly be easier than figuring things out on your own one by one. I guess several target and os port maintainers would want to do so in GCC. Thanks. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University -- Alexander Potapenko Software Engineer Google Moscow
Regression with [C++11] PR54413 Option for turning off compiler extensions for numeric literals.
From: Ed Smith-Rowland 3dw...@verizon.net Date: Fri, 9 Nov 2012 05:55:16 +0100 libcpp 2012-11-09 Ed Smith-Rowland 3dw...@verizon.net PR c++/54413 * include/cpplib.h (cpp_interpret_float_suffix): Add cpp_reader* arg. (cpp_interpret_int_suffix): Add cpp_reader* arg. * init.c (cpp_create_reader): Iitialize new flags. * expr.c (interpret_float_suffix): Use new flags. (cpp_interpret_float_suffix): Add cpp_reader* arg. (interpret_int_suffix): Use new flags. (cpp_interpret_int_suffix): Add cpp_reader* arg. (cpp_classify_number): Adjust calls to interpret_x_suffix. gcc/c-family 2012-11-09 Ed Smith-Rowland 3dw...@verizon.net PR c++/54413 * c-opts.c (c_common_handle_option): Set new flags. * c.opt: Describe new flags. gcc/cp 2012-11-09 Ed Smith-Rowland 3dw...@verizon.net PR c++/54413 * decl.c (grokfndecl): Adjust calls to interpret_x_suffix. One of these caused PR55325. brgds, H-P
Re: [PATCH] PR other/55291: Add support for GCC multilib run-time libraries to libsanitizer
On Tue, Nov 13, 2012 at 3:48 PM, Paolo Bonzini bonz...@gnu.org wrote:
Il 14/11/2012 00:43, H.J. Lu ha scritto:
This works.
Ok, then please test remove install-sh and friends and do
autoconf/automake again. If it works, commit the result (I don't care
if you make it one or two commits).
Then, wait 24 hours for breakages and commit the multilib patch.
Paolo
This is the multilib patch I will commit later.
--
H.J.
---
2012-11-14 H.J. Lu hongjiu...@intel.com
PR other/55291
* configure.ac (--enable-version-specific-runtime-libs): New option.
(AC_CANONICAL_SYSTEM): New.
(AM_ENABLE_MULTILIB): Moved right after AM_INIT_AUTOMAKE.
(toolexecdir): Support multilib.
(toolexeclibdir): Likewise.
(multilib_arg): New.
* Makefile.in: Regenerated.
* aclocal.m4: Likewise.
* configure: Likewise.
* asan/Makefile.in: Likewise.
* interception/Makefile.in: Likewise.
* sanitizer_common/Makefile.in: Likewise.
diff --git a/libsanitizer/configure.ac b/libsanitizer/configure.ac
index 0b6cdef..27a7f95 100644
--- a/libsanitizer/configure.ac
+++ b/libsanitizer/configure.ac
@@ -4,7 +4,56 @@
AC_PREREQ([2.64])
AC_INIT(package-unused, version-unused, libsanitizer)
AC_CONFIG_SRCDIR([include/sanitizer/common_interface_defs.h])
+
+AC_MSG_CHECKING([for --enable-version-specific-runtime-libs])
+AC_ARG_ENABLE(version-specific-runtime-libs,
+[ --enable-version-specific-runtime-libsSpecify that runtime
libraries should be installed in a compiler-specific directory ],
+[case $enableval in
+ yes) version_specific_libs=yes ;;
+ no) version_specific_libs=no ;;
+ *) AC_MSG_ERROR([Unknown argument to enable/disable
version-specific libs]);;
+ esac],
+[version_specific_libs=no])
+AC_MSG_RESULT($version_specific_libs)
+
+# Do not delete or change the following two lines. For why, see
+# http://gcc.gnu.org/ml/libstdc++/2003-07/msg00451.html
+AC_CANONICAL_SYSTEM
+target_alias=${target_alias-$host_alias}
+AC_SUBST(target_alias)
+
AM_INIT_AUTOMAKE(foreign)
+AM_ENABLE_MULTILIB(, ..)
+
+# Calculate toolexeclibdir
+# Also toolexecdir, though it's only used in toolexeclibdir
+case ${version_specific_libs} in
+ yes)
+# Need the gcc compiler version to know where to install libraries
+# and header files if --enable-version-specific-runtime-libs option
+# is selected.
+toolexecdir='$(libdir)/gcc/$(target_alias)'
+toolexeclibdir='$(toolexecdir)/$(gcc_version)$(MULTISUBDIR)'
+;;
+ no)
+if test -n $with_cross_host
+ test x$with_cross_host != xno; then
+ # Install a library built with a cross compiler in tooldir, not libdir.
+ toolexecdir='$(exec_prefix)/$(target_alias)'
+ toolexeclibdir='$(toolexecdir)/lib'
+else
+ toolexecdir='$(libdir)/gcc-lib/$(target_alias)'
+ toolexeclibdir='$(libdir)'
+fi
+multi_os_directory=`$CC -print-multi-os-directory`
+case $multi_os_directory in
+ .) ;; # Avoid trailing /.
+ *) toolexeclibdir=$toolexeclibdir/$multi_os_directory ;;
+esac
+;;
+esac
+AC_SUBST(toolexecdir)
+AC_SUBST(toolexeclibdir)
# Checks for programs.
AC_PROG_CC
@@ -17,14 +66,11 @@ AM_PROG_LIBTOOL
AC_SUBST(enable_shared)
AC_SUBST(enable_static)
-#AM_ENABLE_MULTILIB(, ..)
-target_alias=${target_alias-$host_alias}
-AC_SUBST(target_alias)
-
-toolexecdir='$(libdir)/gcc-lib/$(target_alias)'
-toolexeclibdir='$(libdir)'
-AC_SUBST(toolexecdir)
-AC_SUBST(toolexeclibdir)
+if test ${multilib} = yes; then
+ multilib_arg=--enable-multilib
+else
+ multilib_arg=
+fi
AC_CONFIG_FILES([Makefile])
[PATCH] asan testsuite (take 3)
On Wed, Nov 14, 2012 at 12:11:13PM +0100, Jakub Jelinek wrote:
Anyway, once asan_symbolize actually symbolizes the output, we could use
something like:
/* { dg-output ERROR: AddressSanitizer stack-buffer-overflow.* } */
/* { dg-output #0 0x\[0-9a-f\]+ (in _*(interceptor_|)memcmp
|\[(\])\[^\n\r]*(\n|\r\n|\r) } */
/* { dg-output #1 0x\[0-9a-f\]+ (in _*main|\[(\])\[^\n\r]*(\n|\r\n|\r)
} */
(this way it will check function names if symbolizer was actually
successful, and just accept #0 0xdeadbeef (foobarbaz.so+0xbeef) style
if it wasn't), but will not accept other function names in the backtrace.
Here it is even with symbolizer, written in (poor) tcl. It will pass even
if e.g. addr2line is replaced by a script that always fails, but if it
succeeds, will fail if the dg-output regexps contain different function name
than what is actually emitted.
Ok for trunk?
2012-11-14 Jakub Jelinek ja...@redhat.com
* lib/asan-dg.exp: New file.
* gcc.dg/asan/asan.exp: New file.
* g++.dg/dg.exp: Prune also asan tests.
* g++.dg/asan/asan.exp: New file.
* c-c++-common/asan/memcmp-1.c: New test.
--- gcc/testsuite/lib/asan-dg.exp.jj2012-11-14 14:31:04.026080021 +0100
+++ gcc/testsuite/lib/asan-dg.exp 2012-11-14 17:01:03.249689063 +0100
@@ -0,0 +1,153 @@
+# Copyright (C) 2012 Free Software Foundation, Inc.
+
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 3 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with GCC; see the file COPYING3. If not see
+# http://www.gnu.org/licenses/.
+
+# Return 1 if compilation with -faddress-sanitizer is error-free for trivial
+# code, 0 otherwise.
+
+proc check_effective_target_faddress_sanitizer {} {
+return [check_no_compiler_messages faddress_sanitizer object {
+ void foo (void) { }
+} -faddress-sanitizer]
+}
+
+#
+# asan_link_flags -- compute library path and flags to find libasan.
+# (originally from g++.exp)
+#
+
+proc asan_link_flags { paths } {
+global srcdir
+global ld_library_path
+global shlib_ext
+
+set gccpath ${paths}
+set flags
+
+set shlib_ext [get_shlib_extension]
+
+if { $gccpath != } {
+ if { [file exists ${gccpath}/libsanitizer/asan/.libs/libasan.a]
+ || [file exists
${gccpath}/libsanitizer/asan/.libs/libasan.${shlib_ext}] } {
+ append flags -L${gccpath}/libsanitizer/asan/.libs
+ append ld_library_path :${gccpath}/libsanitizer/asan/.libs
+ }
+} else {
+ global tool_root_dir
+
+ set libasan [lookfor_file ${tool_root_dir} libasan]
+ if { $libasan != } {
+ append flags -L${libasan}
+ append ld_library_path :${libasan}
+ }
+}
+
+set_ld_library_path_env_vars
+
+return $flags
+}
+
+#
+# asan_init -- called at the start of each subdir of tests
+#
+
+proc asan_init { args } {
+global TEST_ALWAYS_FLAGS
+global ALWAYS_CXXFLAGS
+global TOOL_OPTIONS
+
+set link_flags
+if ![is_remote host] {
+ if [info exists TOOL_OPTIONS] {
+ set link_flags [asan_link_flags [get_multilibs ${TOOL_OPTIONS}]]
+ } else {
+ set link_flags [asan_link_flags [get_multilibs]]
+ }
+}
+
+if [info exists ALWAYS_CXXFLAGS] {
+ set ALWAYS_CXXFLAGS [concat {ldflags=$link_flags} $ALWAYS_CXXFLAGS]
+ set ALWAYS_CXXFLAGS [concat {additional_flags=-faddress-sanitizer -g}
$ALWAYS_CXXFLAGS]
+} else {
+ set TEST_ALWAYS_FLAGS $link_flags -faddress-sanitizer -g
$TEST_ALWAYS_FLAGS
+}
+}
+
+# Symbolize lines like
+# #2 0xdeadbeef (/some/path/libsanitizer.so.0.0.0+0xbeef)
+# in $output using addr2line to
+# #2 0xdeadbeef in foobar file:123
+proc asan_symbolize { output } {
+set addresses [regexp -inline -all -line ^ *#\[0-9\]+ 0x\[0-9a-f\]+
\[(\](\[^)\]+)\[+\](0x\[0-9a-f\]+)\[)\]$ $output]
+if { [llength $addresses] 0 } {
+ set addr2line_name [find_binutils_prog addr2line]
+ set idx 1
+ while { $idx [llength $addresses] } {
+ set key [lindex $addresses $idx]
+ set val [lindex $addresses [expr $idx + 1]]
+ lappend arr($key) $val
+ set idx [expr $idx + 3]
+ }
+ foreach key [array names arr] {
+ set args -f -e $key $arr($key)
+ set status [remote_exec host $addr2line_name $args]
+ if { [lindex $status 0] 0 } continue
+ set addr2line_output [regexp -inline -all -line ^\[^\n\r]*
[lindex $status 1]]
+ set idx 0
+
[C++ Patch] PR 55323
Hi,
in this ICE on illegal what happens is the following:
finish_mem_initializers calls check_for_bare_parameter_packs which
errors out with parameter packs not expanded with ‘...’ and returns
true, thus the former does TREE_VALUE (mem) = error_mark_node.
Eventually, emit_mem_initializers calls expand_aggr_init_1 with this
error_mark_node as 'arguments' which hits the gcc_assert for init !=
error_mark_node.
A safe fix, which passes testing on x86_64-linux, seems just skipping
the error_mark_node. I also considered simply returning, but that would
certainly change the current behavior in terms of warnings produced for
other bases when arguments == NULL_TREE.
Thanks,
Paolo.
/
/cp
2012-11-14 Paolo Carlini paolo.carl...@oracle.com
PR c++/55323
* init.c (emit_mem_initializers): Skip arguments == error_mark_node.
/testsuite
2012-11-14 Paolo Carlini paolo.carl...@oracle.com
PR c++/55323
* g++.dg/cpp0x/vt-55323.C: New.
Index: cp/init.c
===
--- cp/init.c (revision 193495)
+++ cp/init.c (working copy)
@@ -1047,12 +1047,17 @@ emit_mem_initializers (tree mem_inits)
in_base_initializer = 1;
/* Initialize base classes. */
- while (mem_inits
- TREE_CODE (TREE_PURPOSE (mem_inits)) != FIELD_DECL)
+ for (; (mem_inits
+ TREE_CODE (TREE_PURPOSE (mem_inits)) != FIELD_DECL);
+ mem_inits = TREE_CHAIN (mem_inits))
{
tree subobject = TREE_PURPOSE (mem_inits);
tree arguments = TREE_VALUE (mem_inits);
+ /* We will already have issued an error message. */
+ if (arguments == error_mark_node)
+ continue;
+
if (arguments == NULL_TREE)
{
/* If these initializations are taking place in a copy constructor,
@@ -1085,8 +1090,6 @@ emit_mem_initializers (tree mem_inits)
tf_warning_or_error);
expand_cleanup_for_base (subobject, NULL_TREE);
}
-
- mem_inits = TREE_CHAIN (mem_inits);
}
in_base_initializer = 0;
Index: testsuite/g++.dg/cpp0x/vt-55323.C
===
--- testsuite/g++.dg/cpp0x/vt-55323.C (revision 0)
+++ testsuite/g++.dg/cpp0x/vt-55323.C (working copy)
@@ -0,0 +1,12 @@
+// { dg-options -std=c++11 }
+
+struct foo {
+ foo(int a, float b);
+};
+
+struct bar : foo {
+ templatetypename... Args
+ bar(Args... args) : foo(2, args){} // { dg-error parameter packs }
+};
+
+bar b(2,1.);
Re: [PATCH][Revised] Enable libsanitizer on darwin
On Wed, Nov 14, 2012 at 8:09 PM, Rainer Orth r...@cebitec.uni-bielefeld.de wrote: Hi Alex, thanks, that's certainly helpful. I'm primarily interested in porting to Solaris, both SPARC and x86. Several things should be similar to Linux (both being ELF systems), while other areas are certainly different (syscalls implementation etc.). We don't wrap the syscalls in ASan, if you're speaking about that. I'll certainly be looking around. One problem I see with the current code organization is duplication between different platforms: e.g. considerable parts of sanitizer_mac.cc and a new sanitizer_solaris.cc are identical. Perhaps we need more granularity in the future, but that can be decided once an initial port (with duplication to avoid treading on other port's feet) is done. At the same time, we should add infrastructure (like libffi) to only compile target-specific code on the relevant platforms, instead of wrapping every source file in #ifdef __linux__ or similar and extending the conditionals once a new platform is added. Yes, this might be a problem. I also wonder how much Solaris is like FreeBSD, which users are also interested in ASan. -- Alexander Potapenko Software Engineer Google Moscow
Re: [PATCH][Revised] Enable libsanitizer on darwin
I've responded to the bug. Sorry for offtopics unrelated to your original patch. On Wed, Nov 14, 2012 at 8:11 PM, Jack Howarth howa...@bromo.med.uc.edu wrote: On Wed, Nov 14, 2012 at 07:56:18PM +0400, Alexander Potapenko wrote: Hi Rainer, The quick answer is no, although the expansion into GCC world may require such a guideline. We've initially implemented ASan on Linux and then ported it to Android (which is very similar to Linux) and Mac (which is very different), so we have little experience with porting yet. I've summarized the differences between Linux and Mac here: https://code.google.com/p/address-sanitizer/wiki/AddressSanitizerForMacImplementationDetails The core things to pay attention at are function wrapping (e.g. dlsym on Linux, mach_override on Mac), hooking the allocations/deallocations in the program, stack unwinding (already done for x86 and ARM), thread creation, early initialization, debug info and symbolization. Maybe something else. In fact if any of these points work on your platform differently than they do on Linux/Mac, you'll have to re-implement those. Regarding mach_override, it's a Mac OS-specific thing that we use because dlsym doesn't reliably override functions (keywords: two-level namespace) This only works on x86/x86_64 and is just a bunch of ad-hoc hacks to hot-patch the library code. Extending the instruction table in mach_override.c is irrelevant to porting, it's just a mean of making it work with some newer libraries provided by Apple. It won't work on any other OS (well, without some refactoring; in fact it's possible to use it on Linux) or any other arch (one could rewrite mach_override.c for ARM, but iOS doesn't allow code patching). I'm working on a replacement for mach_override, which will compile libasan as a dynamic library on Mac OS and preload it before running the program. It's not ready yet, so the easiest thing for GCC will be to add some more instructions to mach_override and stick to it for now. Alex, Please see... http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55289#c27 So far for all the test cases that I have looked at, the problem seems to be when mach_overrride.c hits the opcodes... 48 8d 5 Can you suggest a patch for that one? It may be the only blocker to asan support on darwin (for x86_64 anyway). Jack Alex On Wed, Nov 14, 2012 at 7:08 PM, Rainer Orth r...@cebitec.uni-bielefeld.de wrote: Hi Alex, most certainly the functionality of asan is not intact. The error messages denote that mach_override couldn't parse some of the function prologues, which means some of ASan interceptors just won't work. In order to fix this you need to change the DEBUG definition in mach_override.c, look at the bytes being parsed and fix the instruction table in mach_override.c is there some guideline how to port asan to a new OS or CPU? That would certainly be easier than figuring things out on your own one by one. I guess several target and os port maintainers would want to do so in GCC. Thanks. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University -- Alexander Potapenko Software Engineer Google Moscow -- Alexander Potapenko Software Engineer Google Moscow
Re: [C++ Patch] PR 55323
On Wed, Nov 14, 2012 at 05:39:12PM +0100, Paolo Carlini wrote: + /* We will already have issued an error message. */ The wording looks unclear. Either we have issued already an error message, or we will issue it. Jakub
Re: [C++ Patch] PR 55323
On 11/14/2012 05:49 PM, Jakub Jelinek wrote: On Wed, Nov 14, 2012 at 05:39:12PM +0100, Paolo Carlini wrote: + /* We will already have issued an error message. */ The wording looks unclear. Either we have issued already an error message, or we will issue it. You are right ;) Consider it amended to: We already have issued an error message.. Paolo.
Re: [PATCH, i386]: Implement post-reload vzeroupper insertion pass
On Sun, Nov 11, 2012 at 9:45 PM, Uros Bizjak ubiz...@gmail.com wrote:
Regarding vzeroupper insertion pass - we will use gcc pass manager to
insert a target-dependant pass directly after reload ...
... like attached patch. The patch inserts vzeroupper pass directly
after reload, so spills from 256bit registers are considered when
processing AVX_U128 entity. The patched gcc reruns mode-switching
pass, so an export of entry function from mode-switching is needed.
2012-11-14 Uros Bizjak ubiz...@gmail.com
Vladimir Yakovlev vladimir.b.yakov...@intel.com
PR target/47440
* config/i386/i386.c (gate_insert_vzeroupper): New function.
(rest_of_handle_insert_vzeroupper): Ditto.
(struct rtl_opt_pass pass_insert_vzeroupper): New.
(ix86_option_override): Register vzeroupper insertion pass here.
(ix86_check_avx256_register): Handle SUBREGs properly.
(ix86_init_machine_status): Remove optimize_mode_switching[AVX_U128]
initialization.
Bootstrapped and regression tested on x86_64-pc-linux-gnu {,-m32} AVX
target and committed to mainline SVN.
Uros.
Index: config/i386/i386.c
===
--- config/i386/i386.c (revision 193502)
+++ config/i386/i386.c (working copy)
@@ -2301,6 +2301,52 @@ static const char *const cpu_names[TARGET_CPU_DEFA
btver2
};
+static bool
+gate_insert_vzeroupper (void)
+{
+ return TARGET_VZEROUPPER;
+}
+
+static unsigned int
+rest_of_handle_insert_vzeroupper (void)
+{
+ int i;
+
+ /* vzeroupper instructions are inserted immediately after reload to
+ account for possible spills from 256bit registers. The pass
+ reuses mode switching infrastructure by re-running mode insertion
+ pass, so disable entities that have already been processed. */
+ for (i = 0; i MAX_386_ENTITIES; i++)
+ix86_optimize_mode_switching[i] = 0;
+
+ ix86_optimize_mode_switching[AVX_U128] = 1;
+
+ /* Call optimize_mode_switching. */
+ pass_mode_switching.pass.execute ();
+ return 0;
+}
+
+struct rtl_opt_pass pass_insert_vzeroupper =
+{
+ {
+ RTL_PASS,
+ vzeroupper,/* name */
+ OPTGROUP_NONE, /* optinfo_flags */
+ gate_insert_vzeroupper, /* gate */
+ rest_of_handle_insert_vzeroupper,/* execute */
+ NULL,/* sub */
+ NULL,/* next */
+ 0, /* static_pass_number */
+ TV_NONE, /* tv_id */
+ 0, /* properties_required */
+ 0, /* properties_provided */
+ 0, /* properties_destroyed */
+ 0, /* todo_flags_start */
+ TODO_df_finish | TODO_verify_rtl_sharing |
+ 0, /* todo_flags_finish */
+ }
+};
+
/* Return true if a red-zone is in use. */
static inline bool
@@ -3705,7 +3751,16 @@ ix86_option_override_internal (bool main_args_p)
static void
ix86_option_override (void)
{
+ static struct register_pass_info insert_vzeroupper_info
+= { pass_insert_vzeroupper.pass, reload,
+ 1, PASS_POS_INSERT_AFTER
+ };
+
ix86_option_override_internal (true);
+
+
+ /* This needs to be done at start up. It's convenient to do it here. */
+ register_pass (insert_vzeroupper_info);
}
/* Update register usage after having seen the compiler flags. */
@@ -14988,10 +15043,15 @@ output_387_binary_op (rtx insn, rtx *operands)
/* Check if a 256bit AVX register is referenced inside of EXP. */
static int
-ix86_check_avx256_register (rtx *exp, void *data ATTRIBUTE_UNUSED)
+ix86_check_avx256_register (rtx *pexp, void *data ATTRIBUTE_UNUSED)
{
- if (REG_P (*exp)
- VALID_AVX256_REG_OR_OI_MODE (GET_MODE (*exp)))
+ rtx exp = *pexp;
+
+ if (GET_CODE (exp) == SUBREG)
+exp = SUBREG_REG (exp);
+
+ if (REG_P (exp)
+ VALID_AVX256_REG_OR_OI_MODE (GET_MODE (exp)))
return 1;
return 0;
@@ -23449,7 +23509,6 @@ ix86_init_machine_status (void)
f = ggc_alloc_cleared_machine_function ();
f-use_fast_prologue_epilogue_nregs = -1;
f-call_abi = ix86_abi;
- f-optimize_mode_switching[AVX_U128] = TARGET_VZEROUPPER;
return f;
}
Re: [PATCH, generic] New RTL primitive: `define_subst'
On Tue, Nov 13, 2012 at 01:03:14PM -0800, Richard Henderson wrote: Note that your indentation is off in places. + while ((start = strchr (end, '')) (end = strchr (end, ''))) Above too when you mention it. Looking at all this, I'm wondering if we shouldn't split out all of this macro/include processing to a separate pass. Perform the preprocessing once, early, leaving the processed result in the build directory. Then run the original/traditional rtl reader on that when running the other rtl manipulation passes. The reason being that it's going to become increasingly hard to figure out if the reason for an error is in the macro processing or in the source md file. Being able to see the macro expansion is going to be important. Of course, another way to get this macro expansion is to leave the macro processing where it is and have another gen program that merely dumps the processed rtl. It wouldn't be run normally, but a makefile target used for debugging would be sufficient. Yeah, one or other way to being able to debug what exactly has been performed during the iterator expansion is certainly desirable for the future. Which brings us to the question of what to do with the patch for 4.8. It's true that you made the deadline for stage1 closure. But there will be no users of this feature, so it begs the question of why we should apply it now. Have you a convincing reason? RM's do you have an opinion here? I'm not against it going in now, it shouldn't be too risky and will allow people to start experimenting with it sooner. It is not the end of the world if it doesn't get applied now on the other side, the gen*.c changes aren't that big and invasive and what would be much harder to maintain longer term are the actual *.md file changes, which aren't being submitted for 4.8. Jakub
Re: ASAN merge...
From: Dodji Seketeli do...@redhat.com Date: Wed, 14 Nov 2012 14:26:40 +0100 I guess we could do that. That would build libsanitizer, but asan will still not be available on sparc if the asan_shadow_offset() target hook is not provided. Is that OK to you? Yes.
Re: [PATCH 0/2] Update soft-fp from GLIBC
On Wed, 14 Nov 2012, Marcus Shawcroft wrote: libgcc's soft-fp is based on GLIBC's soft-fp. In the patch [1/2] I've brought across the latest bug fixes from GLIBC. These changes include a dependence on relevant targets (aarch64, ia64, i386) providing a definition of FP_TRAPPING_EXCEPTIONS. The patch [2/2] provides an aarch64 definition of FP_TRAPPING_EXCEPTIONS. This update is OK. (I don't think it *depends* on the FP_TRAPPING_EXCEPTIONS definitions, it's simply that the __float128 support for those architectures will be more correct when that definition is added.) -- Joseph S. Myers jos...@codesourcery.com
Re: [PATCH, generic] Support printing of escaped curly braces and vertical bar in assembler output
There are two parts to it: the actual print_operand thing, that I say
should be target-specific, since some targets already use those characters
to mean different things; and of course the assembler dialects code needs
to be fixed to not choke on escaped versions of the characters it is
looking for. I say you can do this second thing without special-casing
{ | }, making it more generic and cleaner and simpler.
For the logic to find the end of an alternative, you can simply always
skip over the next char after any percent sign (well, check for end of
string, of course); there is no need to count percent signs.
That would not be a general approach. %% stands for printing percent
sign, so in assembler string {%%} closing curly brace should be
handled as the end of an alternative, though it follows a percent
sign.
The second % is skipped over.
Thanks for the explanation, now I understand it. I fixed the patch
according to your remarks. I removed %| support since we don't
actually need it in i386 right now, it was added for the purpose of
possible generalization.
Updated patch is attached.
ChangeLog:
2012-11-14 Maxim Kuznetsov maks.kuznet...@gmail.com
* final.c (do_assembler_dialects): Don't handle curly braces and
vertical bar escaped by % as dialect delimiters.
* config/i386/i386.c (ix86_print_operand_punct_valid_p): Add '{' and
'}'.
(ix86_print_operand): Handle '{' and '}'.
testsuite/ChangeLog:
2012-11-14 Maxim Kuznetsov maks.kuznet...@gmail.com
* gcc.target/i386/asm-dialect-2.c: New testcase.
--
Maxim Kuznetsov
curly_braces.patch
Description: Binary data
Re: [PATCH][Revised] Enable libsanitizer on darwin
On Nov 14, 2012, at 6:43 AM, Jack Howarth howa...@bromo.med.uc.edu wrote: The attached patch assumes that mach_override/mach_override.h and mach_override/mach_override.c has been imported by the libsanitizer maintainers for use by darwin. So, the patches are a nice start. Since we are in stage3, they need to go in, in a way that is suitable for release. If the feature is expected to work (I think that's true) and if these patches don't yet work well enough (I don't have a take on wether this is the case or not), then as the patches go in, they need to go in with the feature off or disabled. So, I'd like a person that understand s libsanitizer and what we need (what is suitable) for release to approve the patches. If I do, I'd need to understand more than I do. What we don't want, a half implementation that is worse than saying, unsupported. I don't mind if the support isn't complete, yet, what is there works fine.
Re: Using -ffunction-sections and -p
On Sun, Nov 4, 2012 at 9:03 PM, Ian Lance Taylor i...@google.com wrote: On Sun, Nov 4, 2012 at 8:04 PM, Sriraman Tallam tmsri...@google.com wrote: Currently, using -ffunction-sections and -p together results in a warning. I ran into this problem when compiling the kernel. This is discussed in this thread: http://gcc.gnu.org/ml/gcc-help/2008-11/msg00128.html Ian's reply suggests this warning is no longer necessary and can be removed. Is this patch alright to commit with all tests passing: * toplev.c (process_options): Do not warn when -ffunction-sections and -fprofile are used together. In that thread Jeff suggested that this be tested on Solaris and PA. I don't know how to test on PA, but could somebody test the patch on Solaris? Is it reasonable to gate this using a target hook and start allowing this on selected targets? For instance, i386 does not seem to have a problem with this. Thanks, -Sri. Ian
[patch] Performance patch for MIPS conditional move in expr.c
Back in August of 2011, Richard Biener made a change affecting COND_EXPRs
(r178408). As a result of that change the GCC MIPS compiler that used
to promote HImode variables to SImode and then put out SImode variables
and assignments for the conditional move (MIPS doesn't support HImode
conditional moves) started putting out HImode variables and assignments and
the resulting code is slower then it was.
The code that used to look like this:
(insn 23 22 24 3 (set (reg/v:SI 231 [ a2+-2 ]) (zero_extend:SI (subreg:HI
(reg:SI 320) 2))) x.c:11 -1 (nil))
(insn 27 26 28 3 (set (reg/v:SI 233 [ a2+-2 ]) (zero_extend:SI (subreg:HI
(reg:SI 323) 2))) x.c:12 -1 (nil))
IF ()
(insn 30 241 31 4 (set (reg:SI 324) (reg/v:SI 231 [ a2+-2 ])) -1 (nil))
ELSE
(insn 34 242 35 5 (set (reg:SI 324) (reg/v:SI 233 [ a2+-2 ])) -1 (nil))
(insn 36 243 37 6 (set (reg/v:SI 234 [ a2+-2 ]) (reg:SI 324)) -1 (nil))
started outputting HI assignments instead:
(insn 23 22 24 3 (set (reg/v:SI 231 [ a2+-2 ]) (zero_extend:SI (subreg:HI
(reg:SI 320) 2))) x.c:11 -1 (nil))
(insn 27 26 28 3 (set (reg/v:SI 233 [ a2+-2 ]) (zero_extend:SI (subreg:HI
(reg:SI 323) 2))) x.c:12 -1 (nil))
IF ()
(insn 30 241 31 4 (set (reg:HI 324) (subreg/s/u:HI (reg/v:SI 231 [
a2+-2 ]) 2)) -1 (nil))
ELSE
(insn 34 242 35 5 (set (reg:HI 324) (subreg/s/u:HI (reg/v:SI 233 [
a2+-2 ]) 2)) -1 (nil))
(insn 36 243 37 6 (set (reg/v:SI 234 [ a2+-2 ]) (zero_extend:SI (reg:HI 324)))
-1 (nil))
This resulted in an extra 'andi REG,REG,0x' instruction to implement the
final zero_extend instruction and that slowed the code down. This patch
restores the previous behaviour by modifying expand_cond_expr_using_cmove
so that when we need to promote the mode in order to do a conditional move
we use that promoted mode in the temp that we are creating for the conditional
move.
Tested on mips-mti-elf with no regressions.
OK for checkin?
Steve Ellcey
sell...@mips.com
2012-11-14 Steve Ellcey sell...@mips.com
* expr.c (expand_cond_expr_using_cmove): Use promoted mode for temp.
diff --git a/gcc/expr.c b/gcc/expr.c
index cbf3a40..b1b83d0 100644
--- a/gcc/expr.c
+++ b/gcc/expr.c
@@ -7840,15 +7840,17 @@ expand_cond_expr_using_cmove (tree treeop0
ATTRIBUTE_UNUSED,
int unsignedp = TYPE_UNSIGNED (type);
enum machine_mode mode = TYPE_MODE (type);
- temp = assign_temp (type, 0, 1);
-
/* If we cannot do a conditional move on the mode, try doing it
with the promoted mode. */
if (!can_conditionally_move_p (mode))
-mode = promote_mode (type, mode, unsignedp);
-
- if (!can_conditionally_move_p (mode))
-return NULL_RTX;
+{
+ mode = promote_mode (type, mode, unsignedp);
+ if (!can_conditionally_move_p (mode))
+ return NULL_RTX;
+ temp = assign_temp (type, 0, 0); /* Use promoted mode for temp. */
+}
+ else
+temp = assign_temp (type, 0, 1);
start_sequence ();
expand_operands (treeop1, treeop2,
Re: [PATCH] asan testsuite (take 3)
On Nov 14, 2012, at 8:22 AM, Jakub Jelinek ja...@redhat.com wrote:
On Wed, Nov 14, 2012 at 12:11:13PM +0100, Jakub Jelinek wrote:
Anyway, once asan_symbolize actually symbolizes the output, we could use
something like:
/* { dg-output ERROR: AddressSanitizer stack-buffer-overflow.* } */
/* { dg-output #0 0x\[0-9a-f\]+ (in _*(interceptor_|)memcmp
|\[(\])\[^\n\r]*(\n|\r\n|\r) } */
/* { dg-output #1 0x\[0-9a-f\]+ (in _*main|\[(\])\[^\n\r]*(\n|\r\n|\r)
} */
(this way it will check function names if symbolizer was actually
successful, and just accept #0 0xdeadbeef (foobarbaz.so+0xbeef) style
if it wasn't), but will not accept other function names in the backtrace.
Here it is even with symbolizer, written in (poor) tcl. It will pass even
if e.g. addr2line is replaced by a script that always fails, but if it
succeeds, will fail if the dg-output regexps contain different function name
than what is actually emitted.
Ok for trunk?
Ok. If others would like to improve this… :-) feel free to step forward.
Re: [patch] Performance patch for MIPS conditional move in expr.c
On Wed, Nov 14, 2012 at 11:02 AM, Steve Ellcey sell...@mips.com wrote:
Back in August of 2011, Richard Biener made a change affecting COND_EXPRs
(r178408). As a result of that change the GCC MIPS compiler that used
to promote HImode variables to SImode and then put out SImode variables
and assignments for the conditional move (MIPS doesn't support HImode
conditional moves) started putting out HImode variables and assignments and
the resulting code is slower then it was.
The code that used to look like this:
(insn 23 22 24 3 (set (reg/v:SI 231 [ a2+-2 ]) (zero_extend:SI (subreg:HI
(reg:SI 320) 2))) x.c:11 -1 (nil))
(insn 27 26 28 3 (set (reg/v:SI 233 [ a2+-2 ]) (zero_extend:SI (subreg:HI
(reg:SI 323) 2))) x.c:12 -1 (nil))
IF ()
(insn 30 241 31 4 (set (reg:SI 324) (reg/v:SI 231 [ a2+-2 ])) -1
(nil))
ELSE
(insn 34 242 35 5 (set (reg:SI 324) (reg/v:SI 233 [ a2+-2 ])) -1
(nil))
(insn 36 243 37 6 (set (reg/v:SI 234 [ a2+-2 ]) (reg:SI 324)) -1 (nil))
started outputting HI assignments instead:
(insn 23 22 24 3 (set (reg/v:SI 231 [ a2+-2 ]) (zero_extend:SI (subreg:HI
(reg:SI 320) 2))) x.c:11 -1 (nil))
(insn 27 26 28 3 (set (reg/v:SI 233 [ a2+-2 ]) (zero_extend:SI (subreg:HI
(reg:SI 323) 2))) x.c:12 -1 (nil))
IF ()
(insn 30 241 31 4 (set (reg:HI 324) (subreg/s/u:HI (reg/v:SI 231 [
a2+-2 ]) 2)) -1 (nil))
ELSE
(insn 34 242 35 5 (set (reg:HI 324) (subreg/s/u:HI (reg/v:SI 233 [
a2+-2 ]) 2)) -1 (nil))
(insn 36 243 37 6 (set (reg/v:SI 234 [ a2+-2 ]) (zero_extend:SI (reg:HI
324))) -1 (nil))
This resulted in an extra 'andi REG,REG,0x' instruction to implement the
final zero_extend instruction and that slowed the code down. This patch
restores the previous behaviour by modifying expand_cond_expr_using_cmove
so that when we need to promote the mode in order to do a conditional move
we use that promoted mode in the temp that we are creating for the conditional
move.
Tested on mips-mti-elf with no regressions.
OK for checkin?
Do you have a testcase? As I added expand_cond_expr_using_cmove, I
think this is the correct fix.
Thanks,
Andrew Pinski
Steve Ellcey
sell...@mips.com
2012-11-14 Steve Ellcey sell...@mips.com
* expr.c (expand_cond_expr_using_cmove): Use promoted mode for temp.
diff --git a/gcc/expr.c b/gcc/expr.c
index cbf3a40..b1b83d0 100644
--- a/gcc/expr.c
+++ b/gcc/expr.c
@@ -7840,15 +7840,17 @@ expand_cond_expr_using_cmove (tree treeop0
ATTRIBUTE_UNUSED,
int unsignedp = TYPE_UNSIGNED (type);
enum machine_mode mode = TYPE_MODE (type);
- temp = assign_temp (type, 0, 1);
-
/* If we cannot do a conditional move on the mode, try doing it
with the promoted mode. */
if (!can_conditionally_move_p (mode))
-mode = promote_mode (type, mode, unsignedp);
-
- if (!can_conditionally_move_p (mode))
-return NULL_RTX;
+{
+ mode = promote_mode (type, mode, unsignedp);
+ if (!can_conditionally_move_p (mode))
+ return NULL_RTX;
+ temp = assign_temp (type, 0, 0); /* Use promoted mode for temp. */
+}
+ else
+temp = assign_temp (type, 0, 1);
start_sequence ();
expand_operands (treeop1, treeop2,
Re: [patch] Performance patch for MIPS conditional move in expr.c
On Wed, 2012-11-14 at 11:15 -0800, Andrew Pinski wrote:
Do you have a testcase? As I added expand_cond_expr_using_cmove, I
think this is the correct fix.
Thanks,
Andrew Pinski
Here is a cutdown test case that I have been compiling with -O3, if you
compare with and without my patch you will see fewer 'andi' instructions
with 0x are generated after my patch is applied.
Steve Ellcey
sell...@mips.com
unsigned short foo(unsigned short a1, unsigned short a2)
{
unsigned short i, x;
for (i = 0; i 8; i++) {
x = (a1 1) ^ (a2 1);
a1 = 1;
if (x == 1) a2 ^= 0x2006;
a2 = 1;
if (x == 1) a2 |= 0x8800;
elsea2 = 0x77ff;
}
return a2;
}
Re: [PATCH][Revised] Enable libsanitizer on darwin
On Wed, Nov 14, 2012 at 10:54:18AM -0800, Mike Stump wrote: On Nov 14, 2012, at 6:43 AM, Jack Howarth howa...@bromo.med.uc.edu wrote: The attached patch assumes that mach_override/mach_override.h and mach_override/mach_override.c has been imported by the libsanitizer maintainers for use by darwin. So, the patches are a nice start. Since we are in stage3, they need to go in, in a way that is suitable for release. If the feature is expected to work (I think that's true) and if these patches don't yet work well enough (I don't have a take on wether this is the case or not), then as the patches go in, they need to go in with the feature off or disabled. So, I'd like a person that understand s libsanitizer and what we need (what is suitable) for release to approve the patches. If I do, I'd need to understand more than I do. What we don't want, a half implementation that is worse than saying, unsupported. I don't mind if the support isn't complete, yet, what is there works fine. Mike, With Alexander Potapenko's proposed patch for interception/mach_override/mach_override.c... http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55289#c29 the use-after-free test case from http://code.google.com/p/address-sanitizer/wiki/AddressSanitizer now passes without errors on both x86_64-apple-darwin12 and i386-apple-darwin10. So at the moment we don't have any known issues. Hopefully we can get the missing interception/mach_override/mach_override.c and interception/mach_override/mach_override.h files added soon along with the build patch so we can start monitoring libsanitizer for other issues in mach_override.c. Jack
Re: [PATCH] asan testsuite (take 3)
On Wed, Nov 14, 2012 at 11:12:05AM -0800, Mike Stump wrote:
On Nov 14, 2012, at 8:22 AM, Jakub Jelinek ja...@redhat.com wrote:
On Wed, Nov 14, 2012 at 12:11:13PM +0100, Jakub Jelinek wrote:
Anyway, once asan_symbolize actually symbolizes the output, we could use
something like:
/* { dg-output ERROR: AddressSanitizer stack-buffer-overflow.* } */
/* { dg-output #0 0x\[0-9a-f\]+ (in _*(interceptor_|)memcmp
|\[(\])\[^\n\r]*(\n|\r\n|\r) } */
/* { dg-output #1 0x\[0-9a-f\]+ (in
_*main|\[(\])\[^\n\r]*(\n|\r\n|\r) } */
(this way it will check function names if symbolizer was actually
successful, and just accept #0 0xdeadbeef (foobarbaz.so+0xbeef) style
if it wasn't), but will not accept other function names in the backtrace.
Here it is even with symbolizer, written in (poor) tcl. It will pass even
if e.g. addr2line is replaced by a script that always fails, but if it
succeeds, will fail if the dg-output regexps contain different function name
than what is actually emitted.
Ok for trunk?
Ok. If others would like to improve this… :-) feel free to step forward.
FYI, this testcase produces 24 passes in gcc and g++ on x86_64-apple-darwin12
using the proposed fix for mach_override/mach_override.c from comment 28 of
PR55289. So libsanitizer looks in reasonable shape to enable on darwin once
someone imports mach_override/mach_override.c and mach_override/mach_override.h
from llvm and commits the build patch
(http://gcc.gnu.org/ml/gcc-patches/2012-11/msg01119.html).
Jack
Re: [patch] Performance patch for MIPS conditional move in expr.c
On Wed, Nov 14, 2012 at 11:27 AM, Steve Ellcey sell...@mips.com wrote:
On Wed, 2012-11-14 at 11:15 -0800, Andrew Pinski wrote:
Do you have a testcase? As I added expand_cond_expr_using_cmove, I
think this is the correct fix.
Thanks,
Andrew Pinski
Here is a cutdown test case that I have been compiling with -O3, if you
compare with and without my patch you will see fewer 'andi' instructions
with 0x are generated after my patch is applied.
I know exactly where this code comes from; I have looked at the
benchmark as one of the reason why I add expand_cond_expr_using_cmove
in the first place. Anyways you should look into removing
TARGET_PROMOTE_PROTOTYPES because I found that also fixes the problem
mentioned here.
Thanks,
Andrew Pinski
Steve Ellcey
sell...@mips.com
unsigned short foo(unsigned short a1, unsigned short a2)
{
unsigned short i, x;
for (i = 0; i 8; i++) {
x = (a1 1) ^ (a2 1);
a1 = 1;
if (x == 1) a2 ^= 0x2006;
a2 = 1;
if (x == 1) a2 |= 0x8800;
elsea2 = 0x77ff;
}
return a2;
}
Re: Using -ffunction-sections and -p
On Wed, Nov 14, 2012 at 10:58 AM, Sriraman Tallam tmsri...@google.com wrote: On Sun, Nov 4, 2012 at 9:03 PM, Ian Lance Taylor i...@google.com wrote: On Sun, Nov 4, 2012 at 8:04 PM, Sriraman Tallam tmsri...@google.com wrote: Currently, using -ffunction-sections and -p together results in a warning. I ran into this problem when compiling the kernel. This is discussed in this thread: http://gcc.gnu.org/ml/gcc-help/2008-11/msg00128.html Ian's reply suggests this warning is no longer necessary and can be removed. Is this patch alright to commit with all tests passing: * toplev.c (process_options): Do not warn when -ffunction-sections and -fprofile are used together. In that thread Jeff suggested that this be tested on Solaris and PA. I don't know how to test on PA, but could somebody test the patch on Solaris? Is it reasonable to gate this using a target hook and start allowing this on selected targets? For instance, i386 does not seem to have a problem with this. At this point I don't know that any target at all has a problem with this. Given that nobody has stepped forward to test it, let's just remove the code and see if anybody complains. I'll approve the patch unless somebody objects in the next 24 hours. Ian
Re: Using -ffunction-sections and -p
On 11/14/2012 01:00 PM, Ian Lance Taylor wrote: Given that nobody has stepped forward to test it, let's just remove the code and see if anybody complains. I'll approve the patch unless somebody objects in the next 24 hours. I think the target to check would be 32 bit HPUX. -ffunction-sections was largely driven by issues we wanted to resolve on the PA. jeff
Re: [C++ Patch] PR 55323
OK. Jason
C++ PATCH for c++/37276 (lookup/builtin5.C) on aix
This patch fixes the bug in a cross-compiler. I don't remember why I put in that #ifdef in the first place, but it seems incorrect. The other uses of NO_IMPLICIT_EXTERN_C are about allowing () in outdated C headers, which is unrelated. commit b34937b905aa25542da7d6ee3d71db2a1413ddbf Author: Jason Merrill ja...@redhat.com Date: Wed Nov 14 15:10:25 2012 -0500 PR c++/37276 * decl.c (decls_match): Remove #ifdef around earlier fix. diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c index 115c567..045e99b 100644 --- a/gcc/cp/decl.c +++ b/gcc/cp/decl.c @@ -1017,13 +1017,11 @@ decls_match (tree newdecl, tree olddecl) DECL_EXTERN_C_P (olddecl))) return 0; -#ifdef NO_IMPLICIT_EXTERN_C /* A new declaration doesn't match a built-in one unless it is also extern C. */ if (DECL_IS_BUILTIN (olddecl) DECL_EXTERN_C_P (olddecl) !DECL_EXTERN_C_P (newdecl)) return 0; -#endif if (TREE_CODE (f1) != TREE_CODE (f2)) return 0;
Re: Using -ffunction-sections and -p
On Wed, Nov 14, 2012 at 12:04 PM, Jeff Law l...@redhat.com wrote: On 11/14/2012 01:00 PM, Ian Lance Taylor wrote: Given that nobody has stepped forward to test it, let's just remove the code and see if anybody complains. I'll approve the patch unless somebody objects in the next 24 hours. I think the target to check would be 32 bit HPUX. -ffunction-sections was largely driven by issues we wanted to resolve on the PA. Does anybody still have access to a 32-bit HPUX machine? Ian
Re: [ping] Re: [patch v2] support for multiarch systems
On Sun, Nov 4, 2012 at 7:45 AM, Matthias Klose d...@ubuntu.com wrote: now testing the attached patch. + when 1 is passed, +- the multiarch path specified with + -imultiarch, when 2 is passed. */ s/when 1 is passed/when set to 1/ Same for 2. This is OK with that change. Thanks and sorry for the delay in review. Ian
Re: [PATCH] Copy libsanitizer from llvm at revision 167890
(Adding ASAN maintainers to the CC) On Wed, Nov 14, 2012 at 7:55 AM, H.J. Lu hjl.to...@gmail.com wrote: On Wed, Nov 14, 2012 at 4:44 AM, Rainer Orth Btw., currently there's no libsanitizer maintainer listed in MAINTAINERS. This needs to change. That is the real problem. We need a GCC libsanitizer maintainer We already have FOUR. Kostya, Jakub, Dmitry and Dodji. Folks, please update MAINTAINERS to avoid confusion. Thanks. Diego.
Re: [C++ Patch] for c++/54537
hi,
2012/9/19 Paolo Carlini paolo.carl...@oracle.com:
Hi Fabien,
On 09/19/2012 07:29 PM, Fabien Chêne wrote:
But I'm afraid this is still not completely correct, because if the user
code has a using std::pow in the global namespace and then and include
tr1/cmath the latter drags again in namespace std::tr1 the overloads
pow
(*, int) which we don't want there... gr
I'll add a testcase for this, if you agree.
Sure, if you like (the never ending story of std::pow between C++99 and
C++11, I'm still meeting people missing the (*, int) overloads ;)
You know what? All in all, I think we can go with your original idea of
just
removing the overload for (double, double): what I didn't realize the
first
time I saw the idea is that we have anyway the templatized pow which
forwards to std::pow. Thus, I suppose things should work pretty well. But
please add a big comment before the commented out overload. And let's see
if
over the next months somebody complaints, otherwise, I think it will be
enough for TR1, at this point.
Thanks for your patience!!!
It seems reasonable, I'll update the patch soon with the comment that
you suggest.
Thanks! (if you feel lazy about the comment, just add a couple of URLs to
the front-end issue and to this discussion, it's more than enough to
understand what's going on)
My apologize to come back after such a delay. The patch is almost
ready, I was just wondering if we could add the specialization
template inline double pow(double __x, double __y) { return
std::pow(__x, __y); } (in tr1/math.h)
instead of relying on the generic version, it passes testing as well.
I doubt that it will change something, but perhaps it could be the
case for unoptimized builds, I don't know (and I didn't take the time
to check). Anyway, I find it a bit unusual, so just take it as a
suggestion.
I'll submit the patch with the version that you prefer.
(sorry for the duplicated message, not sure what gmail is playing at
wrt html mail format)
--
Fabien
Re: [C++ Patch] for c++/54537
Hi,
On 11/14/2012 10:04 PM, Fabien Chêne wrote:
My apologize to come back after such a delay. The patch is almost
ready, I was just wondering if we could add the specialization
template inline double pow(double __x, double __y) { return
std::pow(__x, __y); } (in tr1/math.h) instead of relying on the
generic version, it passes testing as well. I doubt that it will
change something, but perhaps it could be the case for unoptimized
builds, I don't know (and I didn't take the time to check). Anyway, I
find it a bit unusual, so just take it as a suggestion. I'll submit
the patch with the version that you prefer.
Since we came to the conclusion that removing the overload for (double,
double) worked, let's just do that and be done with it. Then we have a
few months before the release to make sure that we aren't regressing,
safe enough for this legacy TR1 stuff, IMO.
Paolo.
Re: [C++ Patch] for c++/54537
I'll just note that another solution would be to change non-template forwarding pows to be extern C declarations. But it sounds like you folks have this issue in hand. Jason
Re: [Bug libstdc++/54075] [4.7.1] unordered_map insert still slower than 4.6.2
On 11/13/2012 11:53 PM, Paolo Carlini wrote: Regarding performance, I have done a small evolution of the 54075.cc test proposed last time. It is now checking performance with and without cache of hash code. Result is: 54075.cc std::unordered_set 30 Foo insertions without cache 9r9u0s 13765616mem0pf 54075.cc std::unordered_set 30 Foo insertions with cache 14r 13u0s 18562064mem0pf 54075.cc std::tr1::unordered_set 30 Foo insertions without cache 9r8u1s 13765616mem0pf 54075.cc std::tr1::unordered_set 30 Foo insertions with cache 14r 13u0s 18561952mem0pf So the difference of performance in this case only seems to come from caching the hash code or not. In reported use case default behavior of std::unordered_set is to cache hash codes and std::tr1::unordered_set not to cache it. We should perhaps review default behavior regarding caching the hash code. Perhaps cache it if the hash functor can throw and not cache it otherwise, not easy to find out what's best to do. Ah good. I think we finally have nailed the core performance issue. And, as it turns out, I'm a bit confused about the logic we have in place now for the defaults: can you please summarize what we are doing and which are the trade offs (leaving out the technicalities having to do with the final types)? We do not cache if the following conditions are all met: - key type is an integral - hash functor is empty and not final - hash functor doesn't throw As you can see we cache in most of the cases. I think the most interesting are three: 1- std::hashint 2- std::hashstd::string 3- user_defined_hashxxx which cannot throw In the first we should normally not cache; in the second, from a performance point of view (from the exception safety point of view we could do both, because std::hashstd::string doesn't throw anyway) it would be better to cache; the third case is rather tricky, because, like the case of std::string, from the exception safety point of view we could do both, thus it's purely a performance issue. Do I understand correctly that currently we handle 2- and 3- above in the same way, thus we cache? yes, because types are not integral. It seems to me that whereas that kind of default makes a lot of sense for std::string, doesn't necessarily make sense for everything else, and it seems to me that such kind of default makes a suboptimal use of the knowledge we have via __is_noexcept_hash that the functor doesn't throw. That seems instead a sort of user-hint to not cache! Given the unfortunate situation that the user has no way to explicitly pick a behavior when instantiating the container, we can imagine that he can anyway provide a strong if indirect hint by decorating or not with noexcept the call operator. We could even document that as part of our implementation defined behavior. How does it sound? Do we have a way to figure out what other implementations are doing? Outside std::hash, it should be pretty easy to instantiate with a special functor which internally keeps a counter... if we have evidence that the other best implementations don't cache for 3- we should definitely do the same. To summarize my intuitions are (again, leaving out the final technicalities) a- std::hash specializations for scalar types - no cache b- std::hash specialization for std::string (or maybe everything else, for simplicity) - cache c- user defined functor - cache or not basing on __is_noexcept_hash I don't understand why we would make a distinction between std::hash specialization and user defined functor, especially because hash specialization can throw. I like the idea of caching based on noexcept as its the only way users can tweak this behavior. Of course it will mean that we will need to check for std::string explicitly. François
Re: [C++ Patch] for c++/54537
2012/11/14 Paolo Carlini paolo.carl...@oracle.com: [...] Since we came to the conclusion that removing the overload for (double, double) worked, let's just do that and be done with it. Then we have a few months before the release to make sure that we aren't regressing, safe enough for this legacy TR1 stuff, IMO. Good, here is the patch then, bootstrapped and tested x86_64-unknown-linux-gnu without regressions on a old tree. I plan to perform an additional testing before committing anyway. 2012-11-14 Fabien Chêne fab...@gcc.gnu.org PR c++/54537 * cp-tree.h: Check OVL_USED with OVERLOAD_CHECK. * name-lookup.c (do_nonmember_using_decl): Make sure we have an OVERLOAD before calling OVL_USED. Call diagnose_name_conflict instead of issuing an error without mentioning the conflicting declaration. 2012-11-14 Fabien Chêne fab...@gcc.gnu.org PR c++/54537 * g++.dg/overload/using3.C: New. * g++.dg/overload/using2.C: Adjust. * g++.dg/lookup/using9.C: Likewise. 2012-11-14 Fabien Chêne fab...@gcc.gnu.org PR c++/54537 * include/tr1/cmath: Remove pow(double,double) overload, remove a duplicated comment about DR 550. Add a comment to explain the issue. * testsuite/tr1/8_c_compatibility/cmath/pow_cmath.cc: New. -- Fabien 54537.patch Description: Binary data
Re: [patch] Performance patch for MIPS conditional move in expr.c
On Wed, 2012-11-14 at 12:00 -0800, Andrew Pinski wrote: I know exactly where this code comes from; I have looked at the benchmark as one of the reason why I add expand_cond_expr_using_cmove in the first place. Anyways you should look into removing TARGET_PROMOTE_PROTOTYPES because I found that also fixes the problem mentioned here. Thanks, Andrew Pinski Removing TARGET_PROMOTE_PROTOTYPES looks interesting but I don't know if it is possible for compatibility reasons. I am still looking at my example though, I see GCC doing: andi$5,$5,0x1 xori$5,$5,0x1 movz$2,$4,$5 When it should just do: andi$5,$5,0x1 movn$2,$4,$5 Steve Ellcey sell...@mips.com
[PATCH, libstdc++]: Adjust expected mangling for 128bit long double targets
Hello!
Attached patch adjusts expected demangling strings of
testsuite/26_numerics/complex/abi_tag.cc for 128bit long-double
targets.
2012-11-14 Uros Bizjak ubiz...@gmail.com
* testsuite/26_numerics/complex/abi_tag.cc: Adjust expected
demangling for 128bit long-double targets.
Tested on alphaev68-pc-linux-gnu (128bit long double target) and
x86_64-pc-linux-gnu.
OK for mainline?
Uros.
Index: testsuite/26_numerics/complex/abi_tag.cc
===
--- testsuite/26_numerics/complex/abi_tag.cc(revision 193502)
+++ testsuite/26_numerics/complex/abi_tag.cc(working copy)
@@ -8,7 +8,7 @@
float (std::complexfloat::*p1)() const = std::complexfloat::real;
// { dg-final { scan-assembler _ZNKSt7complexIdE4realB5cxx11Ev } }
double (std::complexdouble::*p2)() const = std::complexdouble::real;
-// { dg-final { scan-assembler _ZNKSt7complexIeE4realB5cxx11Ev } }
+// { dg-final { scan-assembler _ZNKSt7complexI\[eg\]E4realB5cxx11Ev } }
long double (std::complexlong double::*p3)() const
= std::complexlong double::real;
// { dg-final { scan-assembler _ZNKSt7complexIiE4realB5cxx11Ev } }
@@ -18,7 +18,7 @@
float (std::complexfloat::*p5)() const = std::complexfloat::imag;
// { dg-final { scan-assembler _ZNKSt7complexIdE4imagB5cxx11Ev } }
double (std::complexdouble::*p6)() const = std::complexdouble::imag;
-// { dg-final { scan-assembler _ZNKSt7complexIeE4imagB5cxx11Ev } }
+// { dg-final { scan-assembler _ZNKSt7complexI\[eg\]E4imagB5cxx11Ev } }
long double (std::complexlong double::*p7)() const
= std::complexlong double::imag;
// { dg-final { scan-assembler _ZNKSt7complexIiE4imagB5cxx11Ev } }
Re: [patch] Performance patch for MIPS conditional move in expr.c
On Wed, Nov 14, 2012 at 1:45 PM, Steve Ellcey sell...@mips.com wrote: On Wed, 2012-11-14 at 12:00 -0800, Andrew Pinski wrote: I know exactly where this code comes from; I have looked at the benchmark as one of the reason why I add expand_cond_expr_using_cmove in the first place. Anyways you should look into removing TARGET_PROMOTE_PROTOTYPES because I found that also fixes the problem mentioned here. Thanks, Andrew Pinski Removing TARGET_PROMOTE_PROTOTYPES looks interesting but I don't know if it is possible for compatibility reasons. I am still looking at my example though, I see GCC doing: andi$5,$5,0x1 xori$5,$5,0x1 movz$2,$4,$5 When it should just do: andi$5,$5,0x1 movn$2,$4,$5 Yes I have a few patches for improving this case. I have not submitted them yet though. Attached is the assembly I get from a 4.7 toolchain with all of the changes I have internally applied; this is for n32 (though o32 produces the exact same code in this case). I will try to post some more in the next coming weeks. Thanks, Andrew Pinski Steve Ellcey sell...@mips.com n32.s Description: Binary data
Re: [PATCH, libstdc++]: Adjust expected mangling for 128bit long double targets
On 11/14/2012 10:45 PM, Uros Bizjak wrote: Hello! Attached patch adjusts expected demangling strings of testsuite/26_numerics/complex/abi_tag.cc for 128bit long-double targets. 2012-11-14 Uros Bizjak ubiz...@gmail.com * testsuite/26_numerics/complex/abi_tag.cc: Adjust expected demangling for 128bit long-double targets. Tested on alphaev68-pc-linux-gnu (128bit long double target) and x86_64-pc-linux-gnu. OK for mainline? Ok. Thanks, Paolo.
Re: [patch] Performance patch for MIPS conditional move in expr.c
On Wed, Nov 14, 2012 at 1:51 PM, Andrew Pinski
andrew.pin...@caviumnetworks.com wrote:
On Wed, Nov 14, 2012 at 1:45 PM, Steve Ellcey sell...@mips.com wrote:
On Wed, 2012-11-14 at 12:00 -0800, Andrew Pinski wrote:
I know exactly where this code comes from; I have looked at the
benchmark as one of the reason why I add expand_cond_expr_using_cmove
in the first place. Anyways you should look into removing
TARGET_PROMOTE_PROTOTYPES because I found that also fixes the problem
mentioned here.
Thanks,
Andrew Pinski
Removing TARGET_PROMOTE_PROTOTYPES looks interesting but I don't know if
it is possible for compatibility reasons. I am still looking at my
example though, I see GCC doing:
andi$5,$5,0x1
xori$5,$5,0x1
movz$2,$4,$5
When it should just do:
andi$5,$5,0x1
movn$2,$4,$5
Yes I have a few patches for improving this case. I have not
submitted them yet though.
Attached is the assembly I get from a 4.7 toolchain with all of the
changes I have internally applied; this is for n32 (though o32
produces the exact same code in this case). I will try to post some
more in the next coming weeks.
Removing Richard B. from the CC list since this is now a MIPS specific
change (the original patch is still needed though).
Here is the patch which should improve the above case. I have not
tested it on the trunk yet but it applies there.
Basically the *movGPR:mode_on_GPR2:mode_ne pattern is the one
which is needed in this case. The other two changes are done for
64bit comparisons.
Thanks,
Andrew Pinski
Thanks,
Andrew Pinski
Steve Ellcey
sell...@mips.com
commit 8ca1e58de404bbe82b93bc240ef28c68c681243d
Author: Andrew Pinski apin...@cavium.com
Date: Thu Jul 26 18:09:34 2012 -0700
2012-07-26 Andrew Pinski apin...@cavium.com
Bug #3261
* config/mips/mips.md (*movGPR:mode_on_MOVECC:mode):
Remove mode check from comparisons.
(*movSCALARF:mode_on_MOVECC:mode): Likewise.
(*movGPR:mode_on_GPR2:mode_ne): New pattern to match
when (ne A 0) can be just A.
* testsuite/gcc.target/mips/movcc-4.c: New testcase.
diff --git a/gcc/config/mips/mips.md b/gcc/config/mips/mips.md
index 0dff58e..a1e9568 100644
--- a/gcc/config/mips/mips.md
+++ b/gcc/config/mips/mips.md
@@ -6765,7 +6765,7 @@
(define_insn *movGPR:mode_on_MOVECC:mode
[(set (match_operand:GPR 0 register_operand =d,d)
(if_then_else:GPR
-(match_operator:MOVECC 4 equality_operator
+(match_operator 4 equality_operator
[(match_operand:MOVECC 1 register_operand
MOVECC:reg,MOVECC:reg)
(const_int 0)])
(match_operand:GPR 2 reg_or_0_operand dJ,0)
@@ -6777,10 +6777,23 @@
[(set_attr type condmove)
(set_attr mode GPR:MODE)])
+(define_insn *movGPR:mode_on_GPR2:mode_ne
+ [(set (match_operand:GPR 0 register_operand =d,d)
+ (if_then_else:GPR
+(match_operand:GPR2 1 register_operand GPR2:reg,GPR2:reg)
+(match_operand:GPR 2 reg_or_0_operand dJ,0)
+(match_operand:GPR 3 reg_or_0_operand 0,dJ)))]
+ ISA_HAS_CONDMOVE
+ @
+movn\t%0,%z2,%1
+movz\t%0,%z3,%1
+ [(set_attr type condmove)
+ (set_attr mode GPR:MODE)])
+
(define_insn *movSCALARF:mode_on_MOVECC:mode
[(set (match_operand:SCALARF 0 register_operand =f,f)
(if_then_else:SCALARF
-(match_operator:MOVECC 4 equality_operator
+(match_operator 4 equality_operator
[(match_operand:MOVECC 1 register_operand
MOVECC:reg,MOVECC:reg)
(const_int 0)])
(match_operand:SCALARF 2 register_operand f,0)
diff --git a/gcc/testsuite/gcc.target/mips/movcc-4.c
b/gcc/testsuite/gcc.target/mips/movcc-4.c
new file mode 100644
index 000..d364a52
--- /dev/null
+++ b/gcc/testsuite/gcc.target/mips/movcc-4.c
@@ -0,0 +1,13 @@
+/* { dg-options -O2 isa=4 } */
+/* { dg-final { scan-assembler-times movz\t|movn\t 1 } } */
+/* { dg-final { scan-assembler-not bbit0\t|bbit1\t } } */
+/* { dg-final { scan-assembler-not xori\t|xor\t } } */
+
+NOMIPS16 int f(int a, int b, int c)
+{
+ int d = a0x1;
+ if (d==1)
+return b;
+ return c;
+}
+
[patch] [alpha] add multiarch definitions for alpha-linux-gnu
The following patch adds the multiarch definitions for alpha-linux-gnu. Tested
using a Debian/Ubuntu package build. Ok for the trunk?
Matthias
2012-11-14 Matthias Klose d...@ubuntu.com
* config/alpha/t-linux: New file; define MULTIARCH_DIRNAME.
* config.gcc alpha*-*-linux* (tmake_file): Include alpha/t-linux.
Index: config/alpha/t-linux
===
--- config/alpha/t-linux (revision 0)
+++ config/alpha/t-linux (revision 0)
@@ -0,0 +1 @@
+MULTIARCH_DIRNAME = $(call if_multiarch,alpha-linux-gnu)
Index: config.gcc
===
--- config.gcc (revision 193508)
+++ config.gcc (working copy)
@@ -831,6 +831,7 @@
;;
alpha*-*-linux*)
tm_file=elfos.h ${tm_file} alpha/elf.h alpha/linux.h alpha/linux-elf.h glibc-stdint.h
+ tmake_file=${tmake_file} alpha/t-linux
extra_options=${extra_options} alpha/elf.opt
;;
alpha*-*-freebsd*)
Re: [patch, mips] Fix for PR 54619, GCC aborting with -O -mips16
On 21/09/12 03:40, Sandra Loosemore wrote:
Re:
I think tree-ssa-loop-ivopts is simply
asking for the wrong thing, and needs to be changed. As I say,
Sandra had some fixes in this area.
This patch:
http://gcc.gnu.org/ml/gcc-patches/2012-06/msg00319.html
Sadly, that patch has fallen off the bottom of my priority list (some
legal wrangling halted all work on the Hexagon port that was the
motivating example for it), and meanwhile it's become bit-rotten due to
Bill Schmidt's work that touched on the ivopts code as well. If someone
else would like to adopt this patch, please do!
I agree that it is just plain dumb for ivopts to be trying to precompute
address costs for modes that are not even valid.
Zdenek,
this patch prevents ivopts from passing VOIDmode to address_cost.
The patch fixes a buildbreaker in newlib for mips16. I've confirmed that I can
do a full mips build with newlib with this patch.
I've bootstrapped and reg-tested this patch on x86_64.
OK for trunk (without the assert)?
Thanks,
- Tom
2012-11-14 Tom de Vries t...@codesourcery.com
* tree-ssa-loop-ivopts.c (get_use_type): New function.
(get_computation_at): Use get_use_type.
(get_computation_cost_at): Declare and set mem_mode. Use mem_mode.
Index: gcc/rtlanal.c
===
--- gcc/rtlanal.c (revision 193478)
+++ gcc/rtlanal.c (working copy)
@@ -3840,6 +3840,8 @@ address_cost (rtx x, enum machine_mode m
of push instruction. It is not worthwhile to complicate writing
of the target hook by such cases. */
+ gcc_assert (mode != VOIDmode);
+
if (!memory_address_addr_space_p (mode, x, as))
return 1000;
Index: gcc/tree-ssa-loop-ivopts.c
===
--- gcc/tree-ssa-loop-ivopts.c (revision 193478)
+++ gcc/tree-ssa-loop-ivopts.c (working copy)
@@ -3009,6 +3009,28 @@ get_computation_aff (struct loop *loop,
return true;
}
+/* Return the type of USE. */
+
+static tree
+get_use_type (struct iv_use *use)
+{
+ tree base_type = TREE_TYPE (use-iv-base);
+ tree type;
+
+ if (use-type == USE_ADDRESS)
+{
+ /* The base_type may be a void pointer. Create a pointer type based on
+ the mem_ref instead. */
+ type = build_pointer_type (TREE_TYPE (*use-op_p));
+ gcc_assert (TYPE_ADDR_SPACE (TREE_TYPE (type))
+ == TYPE_ADDR_SPACE (TREE_TYPE (base_type)));
+}
+ else
+type = base_type;
+
+ return type;
+}
+
/* Determines the expression by that USE is expressed from induction variable
CAND at statement AT in LOOP. The computation is unshared. */
@@ -3017,7 +3039,7 @@ get_computation_at (struct loop *loop,
struct iv_use *use, struct iv_cand *cand, gimple at)
{
aff_tree aff;
- tree type = TREE_TYPE (use-iv-base);
+ tree type = get_use_type (use);
if (!get_computation_aff (loop, use, cand, at, aff))
return NULL_TREE;
@@ -3934,6 +3956,9 @@ get_computation_cost_at (struct ivopts_d
comp_cost cost;
double_int rat;
bool speed = optimize_bb_for_speed_p (gimple_bb (at));
+ enum machine_mode mem_mode = (address_p
+? TYPE_MODE (TREE_TYPE (*use-op_p))
+: VOIDmode);
*depends_on = NULL;
@@ -4041,7 +4066,7 @@ get_computation_cost_at (struct ivopts_d
else if (address_p
!POINTER_TYPE_P (ctype)
multiplier_allowed_in_address_p
- (ratio, TYPE_MODE (TREE_TYPE (utype)),
+ (ratio, mem_mode,
TYPE_ADDR_SPACE (TREE_TYPE (utype
{
cbase
@@ -4085,7 +4110,7 @@ get_computation_cost_at (struct ivopts_d
return add_costs (cost,
get_address_cost (symbol_present, var_present,
offset, ratio, cstepi,
- TYPE_MODE (TREE_TYPE (utype)),
+ mem_mode,
TYPE_ADDR_SPACE (TREE_TYPE (utype)),
speed, stmt_is_after_inc,
can_autoinc));
[patch] [arm] add multiarch definitions for arm-linux-gnueabi
The following patch adds the multiarch definitions for arm-linux-gnu. Tested using a Debian/Ubuntu package build. Ok for the trunk? Matthias 2012-11-14 Matthias Klose d...@ubuntu.com * config/arm/t-linux-eabi: Define MULTIARCH_DIRNAME for linux target. Index: config/arm/t-linux-eabi === --- config/arm/t-linux-eabi (revision 193508) +++ config/arm/t-linux-eabi (working copy) @@ -24,3 +24,6 @@ #MULTILIB_OPTIONS += mcpu=fa606te/mcpu=fa626te/mcpu=fmp626/mcpu=fa726te #MULTILIB_DIRNAMES+= fa606te fa626te fmp626 fa726te #MULTILIB_EXCEPTIONS += *mthumb/*mcpu=fa606te *mthumb/*mcpu=fa626te *mthumb/*mcpu=fmp626 *mthumb/*mcpu=fa726te* + +ARM_EB = $(if $(findstring TARGET_BIG_ENDIAN_DEFAULT=1, $(tm_defines)),eb) +MULTIARCH_DIRNAME = $(call if_multiarch,arm$(ARM_EB)-linux-gnueabi$(if $(filter hard,$(with_float)),hf))
[patch] [ia64] add multiarch definitions for ia64-linux-gnu
The following patch adds the multiarch definitions for ia64-linux-gnu. Tested
using a Debian/Ubuntu package build. Ok for the trunk?
Matthias
2012-11-14 Matthias Klose d...@ubuntu.com
* config/ia64/t-linux: New file; define MULTIARCH_DIRNAME.
* config.gcc ia64*-*-linux* (tmake_file): Include ia64/t-linux.
Index: config/ia64/t-linux
===
--- config/ia64/t-linux (revision 0)
+++ config/ia64/t-linux (revision 0)
@@ -0,0 +1 @@
+MULTIARCH_DIRNAME = $(call if_multiarch,ia64-linux-gnu)
Index: config.gcc
===
--- config.gcc (revision 193508)
+++ config.gcc (working copy)
@@ -1550,7 +1553,7 @@
;;
ia64*-*-linux*)
tm_file=${tm_file} dbxelf.h elfos.h gnu-user.h linux.h glibc-stdint.h ia64/sysv4.h ia64/linux.h
- tmake_file=${tmake_file} ia64/t-ia64 t-libunwind
+ tmake_file=${tmake_file} ia64/t-ia64 ia64/t-glibc t-libunwind
target_cpu_default=MASK_GNU_AS|MASK_GNU_LD
;;
ia64*-*-hpux*)
[patch] [m68k] add multiarch definitions for m68k-linux-gnu
The following patch adds the multiarch definitions for m68k-linux-gnu. Tested using a Debian/Ubuntu package build. Ok for the trunk? Here, I'm unsure if the definition needs to be further constrained. Matthias 2012-11-14 Matthias Klose d...@ubuntu.com * config/m68k/t-linux: Define MULTIARCH_DIRNAME. Index: config/m68k/t-linux === --- config/m68k/t-linux (revision 193508) +++ config/m68k/t-linux (working copy) @@ -19,6 +19,8 @@ # Only include multilibs for 680x0 and ColdFire CPUs with an MMU. M68K_MLIB_CPU += ((CPU ~ ^m680) || (CPU ~ ^mcf)) (FLAGS ~ FL_MMU) +MULTIARCH_DIRNAME = $(call if_multiarch,m68k-linux-gnu) + # This rule uses MULTILIB_MATCHES to generate a definition of # SYSROOT_SUFFIX_SPEC. sysroot-suffix.h: $(srcdir)/config/m68k/print-sysroot-suffix.sh
[patch] [mips] add multiarch definitions for mips-linux-gnu
The following patch adds the multiarch definitions for mips-linux-gnu. Tested using a Debian/Ubuntu package build. Ok for the trunk? Matthias 2012-11-14 Matthias Klose d...@ubuntu.com * config/mips/t-linux64: Add multiarch names in MULTILIB_OSDIRNAMES. Index: config/mips/t-linux64 === --- config/mips/t-linux64 (revision 193508) +++ config/mips/t-linux64 (working copy) @@ -18,4 +18,9 @@ MULTILIB_OPTIONS = mabi=n32/mabi=32/mabi=64 MULTILIB_DIRNAMES = n32 32 64 -MULTILIB_OSDIRNAMES = ../lib32 ../lib ../lib64 +MIPS_EL = $(if $(filter %el, $(firstword $(subst -, ,$(target,el) +MIPS_SOFT = $(if $(strip $(filter MASK_SOFT_FLOAT_ABI, $(target_cpu_default)) $(filter soft, $(with_float))),soft) +MULTILIB_OSDIRNAMES = \ + ../lib32$(call if_multiarch,:mips64$(MIPS_EL)-linux-gnuabin32$(MIPS_SOFT)) \ + ../lib$(call if_multiarch,:mips$(MIPS_EL)-linux-gnu$(MIPS_SOFT)) \ + ../lib64$(call if_multiarch,:mips64$(MIPS_EL)-linux-gnuabi64$(MIPS_SOFT))
[patch] [hppa] add multiarch definitions for hppa-linux-gnu
The following patch adds the multiarch definitions for hppa-linux-gnu. Tested
using a Debian/Ubuntu package build. Ok for the trunk?
Matthias
2012-11-14 Matthias Klose d...@ubuntu.com
* config/pa/t-linux: New file; define MULTIARCH_DIRNAME.
* config.gcc hppa*64*-*-linux*, hppa*-*-linux* (tmake_file):
Include pa/t-linux.
Index: config/pa/t-linux
===
--- config/pa/t-linux (revision 0)
+++ config/pa/t-linux (revision 0)
@@ -0,0 +1 @@
+MULTIARCH_DIRNAME = $(call if_multiarch,hppa-linux-gnu)
Index: config.gcc
===
--- config.gcc (revision 193508)
+++ config.gcc (working copy)
@@ -1047,6 +1048,7 @@
tm_file=pa/pa64-start.h ${tm_file} dbxelf.h elfos.h gnu-user.h linux.h \
glibc-stdint.h pa/pa-linux.h pa/pa64-regs.h pa/pa-64.h \
pa/pa64-linux.h
+ tmake_file=${tmake_file} pa/t-linux
gas=yes gnu_ld=yes
need_64bit_hwint=yes
;;
@@ -1054,6 +1056,7 @@
target_cpu_default=MASK_PA_11|MASK_NO_SPACE_REGS
tm_file=${tm_file} dbxelf.h elfos.h gnu-user.h linux.h glibc-stdint.h pa/pa-linux.h \
pa/pa32-regs.h pa/pa32-linux.h
+ tmake_file=${tmake_file} pa/t-linux
;;
hppa*-*-openbsd*)
target_cpu_default=MASK_PA_11
[patch] [powerpc] add multiarch definitions for powerpc-linux-gnu
The following patch adds the multiarch definitions for -linux-gnu. Tested using
a Debian/Ubuntu package build. Ok for the trunk?
Matthias
2012-11-14 Matthias Klose d...@ubuntu.com
* config/rs6000/t-linux64: Add multiarch names in MULTILIB_OSDIRNAMES.
* config/rs6000/t-linux: New file; define MULTIARCH_DIRNAME.
* config/rs6000/t-spe: Define MULTIARCH_DIRNAME.
* config.gcc powerpc-*-linux* | powerpc64-*-linux* (tmake_file):
Include rs6000/t-linux for 32bit non-biarch configurations.
Index: config/rs6000/t-linux64
===
--- config/rs6000/t-linux64 (revision 193508)
+++ config/rs6000/t-linux64 (working copy)
@@ -29,4 +29,5 @@
MULTILIB_OPTIONS= m64/m32
MULTILIB_DIRNAMES = 64 32
MULTILIB_EXTRA_OPTS = fPIC
-MULTILIB_OSDIRNAMES = ../lib64 $(if $(wildcard $(shell echo $(SYSTEM_HEADER_DIR))/../../usr/lib32),../lib32,../lib)
+MULTILIB_OSDIRNAMES = ../lib64$(call if_multiarch,:powerpc64-linux-gnu)
+MULTILIB_OSDIRNAMES+= $(if $(wildcard $(shell echo $(SYSTEM_HEADER_DIR))/../../usr/lib32),../lib32,../lib)$(call if_multiarch,:powerpc-linux-gnu)
Index: config/rs6000/t-spe
===
--- config/rs6000/t-spe (revision 193508)
+++ config/rs6000/t-spe (working copy)
@@ -71,3 +71,6 @@
mabi=altivec/mlittle \
maltivec/mlittle \
maltivec/mabi=altivec/mlittle
+
+MULTIARCH_DIRNAME = powerpc-linux-gnuspe$(if $(findstring rs6000/e500-double.h, $(tm_file)),,v1)
+
Index: config/rs6000/t-linux
===
--- config/rs6000/t-linux (revision 0)
+++ config/rs6000/t-linux (revision 0)
@@ -0,0 +1 @@
+MULTIARCH_DIRNAME = powerpc-linux-gnu
Index: config.gcc
===
--- config.gcc (revision 193508)
+++ config.gcc (working copy)
@@ -2057,6 +2060,7 @@
;;
*)
tm_file=${tm_file} rs6000/linux.h glibc-stdint.h
+ tmake_file=$tmake_file rs6000/t-linux
;;
esac
case ${target} in
[patch] [s390] add multiarch definitions for s390-linux-gnu
The following patch adds the multiarch definitions for s390-linux-gnu. Tested using a Debian/Ubuntu package build. Ok for the trunk? Matthias 2012-11-14 Matthias Klose d...@ubuntu.com * config/s390/t-linux64: Add multiarch names in MULTILIB_OSDIRNAMES. Index: config/s390/t-linux64 === --- config/s390/t-linux64 (revision 193508) +++ config/s390/t-linux64 (working copy) @@ -7,4 +7,5 @@ MULTILIB_OPTIONS = m64/m31 MULTILIB_DIRNAMES = 64 32 -MULTILIB_OSDIRNAMES = ../lib64 $(if $(wildcard $(shell echo $(SYSTEM_HEADER_DIR))/../../usr/lib32),../lib32,../lib) +MULTILIB_OSDIRNAMES = ../lib64$(call if_multiarch,:s390x-linux-gnu) +MULTILIB_OSDIRNAMES += $(if $(wildcard $(shell echo $(SYSTEM_HEADER_DIR))/../../usr/lib32),../lib32,../lib)$(call if_multiarch,:s390-linux-gnu)
[patch] [sparc] add multiarch definitions for sparc-linux-gnu
The following patch adds the multiarch definitions for sparc-linux-gnu. Tested
using a Debian/Ubuntu package build. Ok for the trunk?
Matthias
2012-11-14 Matthias Klose d...@ubuntu.com
* config/sparc/t-linux64: Add multiarch names in MULTILIB_OSDIRNAMES.
* config/sparc/t-linux: New file; define MULTIARCH_DIRNAME.
* config.gcc sparc-*-linux* (tmake_file): Include sparc/t-linux
for 32bit non-biarch configurations.
Index: config/sparc/t-linux
===
--- config/sparc/t-linux (revision 0)
+++ config/sparc/t-linux (revision 0)
@@ -0,0 +1 @@
+MULTIARCH_DIRNAME = $(call if_multiarch,sparc-linux-gnu)
Index: config/sparc/t-linux64
===
--- config/sparc/t-linux64 (revision 193508)
+++ config/sparc/t-linux64 (working copy)
@@ -26,4 +26,5 @@
MULTILIB_OPTIONS = m64/m32
MULTILIB_DIRNAMES = 64 32
-MULTILIB_OSDIRNAMES = ../lib64 $(if $(wildcard $(shell echo $(SYSTEM_HEADER_DIR))/../../usr/lib32),../lib32,../lib)
+MULTILIB_OSDIRNAMES = ../lib64$(call if_multiarch,:sparc64-linux-gnu)
+MULTILIB_OSDIRNAMES += $(if $(wildcard $(shell echo $(SYSTEM_HEADER_DIR))/../../usr/lib32),../lib32,../lib)$(call if_multiarch,:sparc-linux-gnu)
Index: config.gcc
===
--- config.gcc (revision 193508)
+++ config.gcc (working copy)
@@ -2422,6 +2426,7 @@
tmake_file=${tmake_file} sparc/t-linux64
else
tm_file=${tm_file} sparc/linux.h
+ tmake_file=${tmake_file} sparc/t-linux
fi
;;
sparc-*-netbsdelf*)
Re: [patch] [sparc] add multiarch definitions for sparc-linux-gnu
From: Matthias Klose d...@ubuntu.com Date: Wed, 14 Nov 2012 23:36:17 +0100 The following patch adds the multiarch definitions for sparc-linux-gnu. Tested using a Debian/Ubuntu package build. Ok for the trunk? I'm fine with this.
Re: [patch] [m68k] add multiarch definitions for m68k-linux-gnu
On Wed, 14 Nov 2012, Matthias Klose wrote: The following patch adds the multiarch definitions for m68k-linux-gnu. Tested using a Debian/Ubuntu package build. Ok for the trunk? Here, I'm unsure if the definition needs to be further constrained. Classix m68k and ColdFire need different multiarch names; you need to avoid using a name for one on a compiler configured for the other. (I think any configuration will always be --with-arch=m68k or --with-arch=cf so you should only need to consider M68K_ARCH rather than having per-multilib settings.) -- Joseph S. Myers jos...@codesourcery.com
Re: Using -ffunction-sections and -p
On 11/14/2012 01:32 PM, Ian Lance Taylor wrote: On Wed, Nov 14, 2012 at 12:04 PM, Jeff Law l...@redhat.com wrote: On 11/14/2012 01:00 PM, Ian Lance Taylor wrote: Given that nobody has stepped forward to test it, let's just remove the code and see if anybody complains. I'll approve the patch unless somebody objects in the next 24 hours. I think the target to check would be 32 bit HPUX. -ffunction-sections was largely driven by issues we wanted to resolve on the PA. Does anybody still have access to a 32-bit HPUX machine? :-) I've got one gathering dust downstairs... If David doesn't have one anymore, I'll fire up mine up and see what I can find... jeff
Re: [patch] [powerpc] add multiarch definitions for powerpc-linux-gnu
Your t-linux setting fails to allow for the possibility of the compiler being configured to default to soft-float (whether --with-float=soft, or --with-cpu etc. for a CPU that implies soft-float). soft-float (only supported for 32-bit) is ABI-incompatible with hard-float and needs its own multiarch name. -- Joseph S. Myers jos...@codesourcery.com
Re: [Bug libstdc++/54075] [4.7.1] unordered_map insert still slower than 4.6.2
Hi, On 11/14/2012 10:27 PM, François Dumont wrote: We do not cache if the following conditions are all met: - key type is an integral - hash functor is empty and not final - hash functor doesn't throw Can somebody remind me why *exactly* we have a condition having to do with the empty-ness of the functor? I don't really understand it (and it's always tricky vs final). Otherwise I think we are coming to the conclusion that we could simply keep only the last condition possibly with the string (and wstring, etc) special cases for std::hash specializations + documentation explaining that the user can direct the behavior wrt caching via noexcept on the call operator. Paolo.
