Re: [patch] disable libmpx x32 multilib builds
On Wed, Mar 11, 2015 at 7:37 AM, Matthias Klose d...@ubuntu.com wrote:
current trunk fails to build on x86*-linux, when configured for x32 multilibs
because libmpx doesn't support these. Disable them.
ok for the trunk?
* Disable libmpx x32 multilib builds.
--- a/config-ml.in
+++ b/config-ml.in
@@ -102,6 +102,7 @@
Makefile=${ac_file-Makefile}
ml_config_shell=${CONFIG_SHELL-/bin/sh}
ml_realsrcdir=${srcdir}
+ml_srcbase=`basename $ml_realsrcdir`
# Scan all the arguments and set all the ones we need.
@@ -220,6 +221,10 @@
if [ ${dir} = . ]; then
true
else
+# libmpx is not supported on x32
+if [ ${ml_srcbase}-${dir} = libmpx-x32 ]; then
+ continue
+fi
if [ -z ${multidirs} ]; then
multidirs=${dir}
else
This is incorrect. Ilya and I are working on a proper fix.
--
H.J.
Re: [PATCH] Fix thunk expansion (PR ipa/64896)
Hi,
PR ipa/65236
* cgraphunit.c (cgraph_node::expand_thunk): Enable return slot
opt.
This bugfix adds ipa-icf-6.C test which failed on 4.9 branch as
ipa-icf is not backported on that branch. Is the bugfix still
relevant and we can dropped the testcase ?
PR ipa/64813
* cgraphunit.c (cgraph_node::expand_thunk): Do not create
a return value for call to a function that is noreturn.
PR ipa/63595
* cgraphunit.c (cgraph_node::expand_thunk): DECL_BY_REFERENCE
is correctly handled for thunks created by IPA ICF.
PR ipa/63587
* cgraphunit.c (cgraph_node::expand_thunk): Only VAR_DECLs are put
to local declarations.
* function.c (add_local_decl): Implementation moved from header
file, assert introduced for tree type.
* function.h: Likewise.
Here is the two patches that backport PR ipa/63587 and PR ipa/64813
fixes in 4.9 branch. The 2 others introduce test cases that check
ipa-icf pass dumps, so I'm not sure if the code has to be backported.
bootstrapped/regtested on x86_64 and cross-compiled/regtested on
aarch64-linux-gnu
arm-linux-gnueabihf
armeb-linux-gnueabihf
i686-linux-gnu
Ok for 4.9 ?
Thanks
Yvan
- PR 63587 -
gcc/
2015-03-11 Yvan Roux yvan.r...@linaro.org
Backport from trunk r216841.
2014-10-29 Martin Liska mli...@suse.cz
PR ipa/63587
* cgraphunit.c (cgraph_node::expand_thunk): Only VAR_DECLs are put
to local declarations.
* function.c (add_local_decl): Implementation moved from header
file, assert introduced for tree type.
* function.h: Likewise.
gcc/testsuite/
2015-03-11 Yvan Roux yvan.r...@linaro.org
Backport from trunk r216841.
2014-10-29 Martin Liska mli...@suse.cz
PR ipa/63587
* g++.dg/ipa/pr63587-1.C: New test.
* g++.dg/ipa/pr63587-2.C: New test.
- PR 64813 -
2015-03-11 Yvan Roux yvan.r...@linaro.org
Backport from trunk r220616.
2015-02-11 Martin Liska mli...@suse.cz
PR ipa/64813
* cgraphunit.c (cgraph_node::expand_thunk): Do not create
a return value for call to a function that is noreturn.
diff --git a/gcc/cgraphunit.c b/gcc/cgraphunit.c
index 130fc0d..27016ad 100644
--- a/gcc/cgraphunit.c
+++ b/gcc/cgraphunit.c
@@ -1575,7 +1575,9 @@ expand_thunk (struct cgraph_node *node, bool output_asm_thunks)
if (aggregate_value_p (resdecl, TREE_TYPE (thunk_fndecl)))
{
restmp = resdecl;
- add_local_decl (cfun, restmp);
+
+ if (TREE_CODE (restmp) == VAR_DECL)
+ add_local_decl (cfun, restmp);
BLOCK_VARS (DECL_INITIAL (current_function_decl)) = restmp;
}
else
diff --git a/gcc/function.c b/gcc/function.c
index 1a8682b..b377667 100644
--- a/gcc/function.c
+++ b/gcc/function.c
@@ -7193,6 +7193,15 @@ match_asm_constraints_1 (rtx insn, rtx *p_sets, int noutputs)
df_insn_rescan (insn);
}
+/* Add the decl D to the local_decls list of FUN. */
+
+void
+add_local_decl (struct function *fun, tree d)
+{
+ gcc_assert (TREE_CODE (d) == VAR_DECL);
+ vec_safe_push (fun-local_decls, d);
+}
+
static unsigned
rest_of_match_asm_constraints (void)
{
diff --git a/gcc/function.h b/gcc/function.h
index 38a0fc4..fd4639c 100644
--- a/gcc/function.h
+++ b/gcc/function.h
@@ -674,11 +674,7 @@ struct GTY(()) function {
/* Add the decl D to the local_decls list of FUN. */
-static inline void
-add_local_decl (struct function *fun, tree d)
-{
- vec_safe_push (fun-local_decls, d);
-}
+void add_local_decl (struct function *fun, tree d);
#define FOR_EACH_LOCAL_DECL(FUN, I, D) \
FOR_EACH_VEC_SAFE_ELT_REVERSE ((FUN)-local_decls, I, D)
diff --git a/gcc/testsuite/g++.dg/ipa/pr63587-1.C b/gcc/testsuite/g++.dg/ipa/pr63587-1.C
new file mode 100644
index 000..cbf872e
--- /dev/null
+++ b/gcc/testsuite/g++.dg/ipa/pr63587-1.C
@@ -0,0 +1,92 @@
+// PR ipa/63587
+// { dg-do compile { target c++11 } }
+// { dg-options -O2 -fno-strict-aliasing }
+
+template class struct A
+{
+};
+template typename struct B
+{
+ template typename struct C;
+};
+class D;
+template typename class F;
+struct G
+{
+ void operator()(const D , D);
+};
+class D
+{
+public:
+ D (int);
+};
+struct H
+{
+ H (int);
+};
+template typename _Key, typename, typename, typename _Compare, typename
+class I
+{
+ typedef _Key key_type;
+ template typename _Key_compare struct J
+ {
+_Key_compare _M_key_compare;
+ };
+ J_Compare _M_impl;
+
+public:
+ Aint _M_get_insert_unique_pos (const key_type );
+ Aint _M_get_insert_hint_unique_pos (H );
+ template typename... _Args int _M_emplace_hint_unique (H, _Args ...);
+};
+template typename _Key, typename _Tp, typename _Compare = G,
+ typename _Alloc = FA_Tp
+class K
+{
+ typedef _Key key_type;
+ typedef _Key value_type;
+ typedef typename B_Alloc::template Cvalue_type _Pair_alloc_type;
+ Ikey_type, value_type, int, _Compare, _Pair_alloc_type _M_t;
+
+public:
+ void operator[](key_type)
+ {
+
Re: [PATCH] PR target/65240, Fix Power{7,8} insn constraint issue with -O3 -ffast-math
On Thu, Mar 5, 2015 at 3:06 PM, Michael Meissner meiss...@linux.vnet.ibm.com wrote: This patch fixes PR 65240, which was a latent bug that was introduced when I added the -mupper-regs support to the PowerPC compiler. In the PowerPC compiler, if you use -ffast-math, the compiler allows floating point constants in move RTLs until register allocation time, in order to allow the optimizations that replace division by a constant with multiplication by the reciprocal. If the register being loaded up is a traditional Altivec register, the load will fail, since there is no D-FORM (register+offset) addressing mode for the traditional altivec registers. I had had a define_split to try and handle this situation, but it didn't work all of the time. I rewrote the insns, so there is an UNSPEC in it to prevent over optimization. I have done bootstrap builds and make check's on both a big endian power7 system, and a little endian power8 system with no regressions in the tests. I have also built both power7 and power8 spec 2006 (v5) versions, and Spec built. I have run the Spec floating point tests on a power7 box, and all of the tests performed about at the same speed as before the bug fix was done, with the exception of gromacs, which is 4% faster with the fix. Looking at the static instruction counts, the big change is to fold the addi instruction into the load of the constant if it is loading the value to a traditional floating point register (previously, it would load up the constant with addis/addi and then do an indirect load). I do see other instructions change, including a few more floating point loads, but with the exception of gromacs, most of the changes are in the noise level. Is this ok to install into the trunk? At present, it is not needed for GCC 4.9, since that branch does not have the -mupper-regs support. [gcc] 2015-03-05 Michael Meissner meiss...@linux.vnet.ibm.com PR target/65240 * config/rs6000/rs6000.md (UNSPEC_FUSION_FP_CONSTANT): New unspec. (Vsx_load): New mode attribute to give appropriate VSX load instruction. (move floating point constant define_split): Use an UNSPEC to make sure that the load of the constant is kept as a memory address, instead of being converted back into a move of the constant. (load_mode_constant): Likewise. [gcc/testsuite] 2015-03-05 Michael Meissner meiss...@linux.vnet.ibm.com PR target/65240 * gcc.target/powerpc/pr65240.c: New test. I am concerned with the create_TOC_reference use for TARGET_TOC. Has this been tested with big endian -mcmodel=small? Thanks, David
Re: [PATCH, TSAN] Fix a crash in ScopedReport::AddThread
OK On Wed, Mar 11, 2015 at 5:41 PM, Bernd Edlinger bernd.edlin...@hotmail.de wrote: Hi Jakub, with my OPC UA Server, I observe a reproducible crash in ScopedReport::AddThread: tctx==NULL in if ((u32)rep_-threads[i]-id == tctx-tid). Apparently, Dmitry has already fixed that in the obvious way. So we should cherry pick these two changes from LLVM: 224508 and 224755 See attachment. Builds cleanly and fixes the problem for me. OK for trunk? Thanks Bernd.
[PATCH] Fix regression caused by PR65310 fix
This fixes a vectorizer testcase regression on powerpc where SRA drops alignment info unnecessarily. Bootstrapped and tested on x86_64-unknown-linux-gnu, applied. Richard. 2015-03-11 Richard Biener rguent...@suse.de PR tree-optimization/65310 * tree-sra.c (build_ref_for_offset): Also preserve larger alignment. Index: gcc/tree-sra.c === --- gcc/tree-sra.c (revision 221324) +++ gcc/tree-sra.c (working copy) @@ -1597,7 +1597,7 @@ build_ref_for_offset (location_t loc, tr misalign = (misalign + offset) (align - 1); if (misalign != 0) align = (misalign -misalign); - if (align TYPE_ALIGN (exp_type)) + if (align != TYPE_ALIGN (exp_type)) exp_type = build_aligned_type (exp_type, align); mem_ref = fold_build2_loc (loc, MEM_REF, exp_type, base, off);
Re: [PATCH] PR target/65242, Fix powerpc abort in gen_add2_insn
Jeff, I completely agree. The example exposed a problematic alternative in the pattern and I would like to fix a latent problem, in addition to Mike's patch. Thanks, David On Wed, Mar 11, 2015 at 12:05 PM, Jeff Law l...@redhat.com wrote: On 03/11/15 08:44, David Edelsohn wrote: On Mon, Mar 9, 2015 at 7:30 PM, Michael Meissner meiss...@linux.vnet.ibm.com wrote: This bug was one I unfortunately introduced with the -mupper-regs support. If the reload pass needed to reload a PLUS operation (for example, due to using odd address with the LD/STD instructions), it would go through all of the registers you could load DImode into, and see if it is a preferred register class. This lead the compiler to believe it could do integer arithmetic in the floating point registers. This patch fixes the problem, by not allowing PLUS to be reloaded into FPR registers. I have done bootstraps and make checks on both a big endian Power7 and a little endian Power8 system, and there were no regressions. Is the patch ok to apply? I do not believe it needs to be back ported to GCC 4.9 since the -mupper-regs changes are not installed currently on that branch. [gcc] 2015-03-09 Michael Meissner meiss...@linux.vnet.ibm.com PR target/65242 * config/rs6000/rs6000.c (rs6000_preferred_reload_class): Do not allow reloads of PLUS in floating point/VSX registers. [gcc/testsuite] 2015-03-09 Michael Meissner meiss...@linux.vnet.ibm.com PR target/65242 * g++.dg/pr65242.C: New test. This is okay. What about Jeff Law's Bugzilla comment #6 to change ?m to !m in the movdi_internal64 pattern? That also seems reasonable. It doesn't matter much to me either way as long as it gets fixed :-) Avoiding floating point registers via preferred reload class is a valid approach. My only concern then would be cases where we have similar looking arithmetic and even though we no longer prefer the FP classes, we still end up selecting that problematical alternative -- say perhaps because the pseudos in question have many other uses where FP regs make sense. I know we could get into those kind of situations on the PA because of the weird way in which integer multiplies were implemented (FP unit, using FP regs) -- which could occur even when using '?' to disparage those alternatives. I'm not familiar enough with PPC implementations to know if we can get into that same situation with that port. Jeff
Re: [patch] disable libmpx x32 multilib builds
2015-03-11 18:59 GMT+03:00 H.J. Lu hjl.to...@gmail.com:
On Wed, Mar 11, 2015 at 7:37 AM, Matthias Klose d...@ubuntu.com wrote:
current trunk fails to build on x86*-linux, when configured for x32 multilibs
because libmpx doesn't support these. Disable them.
ok for the trunk?
* Disable libmpx x32 multilib builds.
--- a/config-ml.in
+++ b/config-ml.in
@@ -102,6 +102,7 @@
Makefile=${ac_file-Makefile}
ml_config_shell=${CONFIG_SHELL-/bin/sh}
ml_realsrcdir=${srcdir}
+ml_srcbase=`basename $ml_realsrcdir`
# Scan all the arguments and set all the ones we need.
@@ -220,6 +221,10 @@
if [ ${dir} = . ]; then
true
else
+# libmpx is not supported on x32
+if [ ${ml_srcbase}-${dir} = libmpx-x32 ]; then
+ continue
+fi
if [ -z ${multidirs} ]; then
multidirs=${dir}
else
This is incorrect. Ilya and I are working on a proper fix.
--
H.J.
Current libmpx configure has a check for x32 but it doesn't work due
to square brackets removed from the test by autoconf. Will test this
patch:
diff --git a/libmpx/configure.ac b/libmpx/configure.ac
index 4669525..fe0d3f2 100644
--- a/libmpx/configure.ac
+++ b/libmpx/configure.ac
@@ -28,7 +28,7 @@ GCC_LIBSTDCXX_RAW_CXX_FLAGS
# See if supported.
unset LIBMPX_SUPPORTED
AC_MSG_CHECKING([for target support for Intel MPX runtime library])
-echo int i[sizeof (void *) == 4 ? 1 : -1] = { __x86_64__ }; conftest.c
+echo int i[[sizeof (void *) == 4 ? 1 : -1]] = { __x86_64__ }; conftest.c
if AC_TRY_COMMAND([${CC} ${CFLAGS} -c -o conftest.o conftest.c
1AS_MESSAGE_LOG_FD])
then
LIBMPX_SUPPORTED=no
Thanks,
Ilya
Re: [PATCH/AARCH64] Add missing definition of crypto instruction on cortex-a57.md
On Wed, Mar 11, 2015 at 04:24:07PM +, Ramana Radhakrishnan wrote: Attached patch as text. 2015-03-11 Junmo Park junmoz.p...@samsung.com * config/arm/cortex-a57.md (cortex_a57_crypto_simple): Add crypto_sha256_fast. (cortex_a57_crypto_complex): Add crypto_sha256_slow. Ok to commit to trunk? OK, Thanks Sebastian. As far as I can see, this patch still hasn't made it to gcc-patches. Could you please send a copy (or a commit revision number), for those of us interested? (Though I can guess what it looks like from the ChangeLog Ramana forwarded, and I'm sure it will be OK) Thanks, James
[PATCH][RFA] [PR rtl-optimization/64317] Enhance postreload-gcse.c to eliminate more redundant loads
64317 is a P2 regression related to making the PIC register a pseudo register on the x86 port. Basically post-LRA we still have some redundant loads of the PIC register from memory (it's spilled to memory as other objects are more profitable to keep in registers). But of the set of ~10 actual loads, we really only need ~5. The basic problem is that LRA and the basic postreload optimizers effectively forget everything they know when they encounter a block that starts with a label -- even if that block is only reachable from one predecessor. ie, these routines work on a subset of EBBs, but not maximal EBBs. The first thought was to have LRA clean this up since this is largely an issue with cross-block inheritance of values. Unfortunately Vlad has indicated that handling maximal EBBs is nontrivial in LRA. I also investigated extending the simple EBB oriented optimizer in postreload.c to handle this case. But it turns out that cselib really isn't suited to a scoped hash table, which would be the natural way to handle this. So I killed that idea. That leaves postreload-gcse and if you look at the incoming RTL you'd think that postreload-gcse would handle this just fine. Unfortunately, postreload-gcse is badly mis-named. Specifically it does no dataflow analysis of available expressions!! There may be some benefit in full dataflow analysis in postreload-gcse.c. But we can get most of the benefits with a relatively simple change. Specifically if we're unable to find the expression we want in the given block, see if the block has a single predecessor. If the expression is available in that predecessor and transparent through the current block, then the expression is still available at the end of the current block. That was enough to fix the PR. But after instrumentation I was discouraged by the fact that postreload-gcse does virtually nothing on x86. It's unable to find a single available load to put in its hash tables on an x86, x86_64 or ppc64 bootstrap. Though many are found during testsuite runs. Digging further into the history of postreload-gcse indicated the postreload-gcse.c work was primarily tested on ppc using spec. My first attempts compiling spec with the instrumented compiler didn't produce anything useful either. On a whim, I tried again with -O3 -funroll loops, then suddenly postreload-gcse.c got reasonably active. Across a subset of spec2k, compiling with -O3 -funroll-loops, this patch enables about a 2X improvement in loads eliminated (ppc64). On a ppc64 -O3 -funroll-loops bootstrap of GCC I see 4142 loads eliminated with this patch and 2739 loads eliminated without. A notable improvement. Even with -O2 -funroll-loops, there's nothing interesting happening on x86_64. Probably because it's not a load-store architecture. Anyway, the question in my mind is whether or not we want to put this in during stage4. The patch itself is medium sized, but mostly mechanical in nature. It's been bootstrapped on x86. It's been bootstrapped and regression tested on x86_64. It's been bootstrapped and regression tested with -O3 -funroll-loops on ppc64 (configured with --disable-werror). OK for the trunk or wait for stage1? I'm happy to go with the release manager's opinions on this. Jeff diff --git a/gcc/ChangeLog b/gcc/ChangeLog index 28979d5..91863be 100644 --- a/gcc/ChangeLog +++ b/gcc/ChangeLog @@ -1,3 +1,34 @@ +2015-03-11 Jeff Law l...@redhat.com + + PR rtl-optimization/64317 + * Makefile.in (OBJS): Add gcse-common.c + * gcse.c: Include gcse-common.h + (struct modify_pair_s): Move structure definition to gcse-common.h + (compute_transp): Move function to gcse-common.c. + (canon_list_insert): Similarly. + (record_last_mem_set_info): Break out some code and put it into + gcse-common.c. Call into the new common code. + (compute_local_properties): Pass additional arguments to compute_transp. + * postreload-gcse.c: Include gcse-common.h and df.h + (modify_mem_list_set, blocks_with_calls): New variables. + (modify_mem_list, canon_modify_mem_list, transp): Likewise. + (get_bb_avail_insn): Pass in the expression index too. + (alloc_mem): Allocate memory for the new bitmaps and lists. + (free_mem): Free memory for the new bitmaps and lists. + (insert_expr_in_table): Record a bitmap index for each entry we + add to the table. + (record_last_mem_set_info): Call into common code in gcse-common.c. + (get_bb_avail_insn): If no available insn was found in the requested + BB. If BB has a single predecessor, see if the expression is + transparent in BB and available in that single predecessor. + (compute_expr_transp): New wrapper for compute_transp. + (eliminate_partially_redundant_load): Pass expression's bitmap_index + to get_bb_avail_insn. Compute next_pred_bb_end a bit later. +
Re: [C++ Patch] PR 65323
On 03/06/2015 03:36 AM, Paolo Carlini wrote: this is a regression about duplicate warnings with -Wzero-as-null-pointer-constant. The regression is rather old, affects 4_8-branch too, and started when check_default_argument got a perform_implicit_conversion_flags call which warns a first time, then maybe_warn_zero_as_null_pointer_constant as called by check_default_argument itself warns a second time. The latter call is even older, dates back to c++/52718, I think we can now safely remove it and keep on returning nullptr_node to avoid warning later still at the call sites (that was the point of c++/52718). Tested x86_64-linux. Do we need this special handling at all? When I remove that whole 'if' block I still only get one warning from the 52718 testcase. Jason
No libstdc++ for nvptx
Hi!
I committed the following in r221362:
commit 5121139d0e8b22290fc9e752b07752d8a1b70182
Author: tschwinge tschwinge@138bc75d-0d04-0410-961f-82ee72b054a4
Date: Wed Mar 11 21:42:50 2015 +
No libstdc++ for nvptx.
The C++ front end insists to link against libstdc++ -- which we don't build:
$ build-gcc/gcc/testsuite/g++/g++.log grep -o 'error opening
[^[:cntrl:]]*' | sort | uniq -c
2 error opening libasan.a
2 error opening libssp.a
12075 error opening libstdc++.a
Based on GCC trunk r220892:
=== g++ Summary ===
# of expected passes[-63221-]{+68841+}
# of unexpected failures[-11751-]{+8764+}
# of unexpected successes 6
# of expected failures [-246-]{+249+}
# of unresolved testcases [-5950-]{+3353+}
# of unsupported tests [-4160-]{+4143+}
gcc/
* config/nvptx/nvptx.h (LIBSTDCXX): Define to gcc.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@221362
138bc75d-0d04-0410-961f-82ee72b054a4
---
gcc/ChangeLog|4
gcc/config/nvptx/nvptx.h |4
2 files changed, 8 insertions(+)
diff --git gcc/ChangeLog gcc/ChangeLog
index 28979d5..e474fc8 100644
--- gcc/ChangeLog
+++ gcc/ChangeLog
@@ -1,3 +1,7 @@
+2015-03-11 Thomas Schwinge tho...@codesourcery.com
+
+ * config/nvptx/nvptx.h (LIBSTDCXX): Define to gcc.
+
2015-03-11 Marek Polacek pola...@redhat.com
PR tree-optimization/65388
diff --git gcc/config/nvptx/nvptx.h gcc/config/nvptx/nvptx.h
index e74d16f..e4e58dd 100644
--- gcc/config/nvptx/nvptx.h
+++ gcc/config/nvptx/nvptx.h
@@ -366,4 +366,8 @@ struct GTY(()) machine_function
#define FUNCTION_MODE QImode
#define HAS_INIT_SECTION 1
+/* The C++ front end insists to link against libstdc++ -- which we don't build.
+ Tell it to instead link against the innocuous libgcc. */
+#define LIBSTDCXX gcc
+
#endif /* GCC_NVPTX_H */
Grüße,
Thomas
pgpnA1eL3zWv7.pgp
Description: PGP signature
Re: RFC: Building a minimal libgfortran for nvptx
Hi!
On Fri, 14 Nov 2014 18:08:32 +0100, Bernd Schmidt ber...@codesourcery.com
wrote:
New patch below, [...]
... got committed. I now committed the following in r221363:
commit 83ba0e65833dd081db921f8c2b3277316590753c
Author: tschwinge tschwinge@138bc75d-0d04-0410-961f-82ee72b054a4
Date: Wed Mar 11 21:42:56 2015 +
libgfortran LIBGFOR_MINIMAL enhancements.
Based on GCC trunk r220892, for nvptx-none:
=== gfortran Summary ===
# of expected passes[-31320-]{+32117+}
# of unexpected failures[-7222-]{+6821+}
# of expected failures 78
# of unresolved testcases [-6441-]{+6158+}
# of untested testcases [-432-]{+391+}
# of unsupported tests 639
libgfortran/
* caf/single.c (caf_runtime_error): Revert 2014-11-28 changes.
* runtime/minimal.c (STRERR_MAXSZ): Don't define.
(runtime_error_at, sys_abort): Bring more in line with the
non-LIBGFOR_MINIMAL code.
(runtime_warning_at, internal_error): New functions.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@221363
138bc75d-0d04-0410-961f-82ee72b054a4
---
libgfortran/ChangeLog |8 ++
libgfortran/caf/single.c |3 +--
libgfortran/runtime/minimal.c | 58 ++---
3 files changed, 64 insertions(+), 5 deletions(-)
diff --git libgfortran/ChangeLog libgfortran/ChangeLog
index 97ee01b..5b201d2 100644
--- libgfortran/ChangeLog
+++ libgfortran/ChangeLog
@@ -1,3 +1,11 @@
+2015-03-11 Thomas Schwinge tho...@codesourcery.com
+
+ * caf/single.c (caf_runtime_error): Revert 2014-11-28 changes.
+ * runtime/minimal.c (STRERR_MAXSZ): Don't define.
+ (runtime_error_at, sys_abort): Bring more in line with the
+ non-LIBGFOR_MINIMAL code.
+ (runtime_warning_at, internal_error): New functions.
+
2015-03-11 Janne Blomqvist j...@gcc.gnu.org
PR libfortran/65200
diff --git libgfortran/caf/single.c libgfortran/caf/single.c
index daef281..6c58286 100644
--- libgfortran/caf/single.c
+++ libgfortran/caf/single.c
@@ -48,14 +48,13 @@ caf_static_t *caf_static_list = NULL;
static void
caf_runtime_error (const char *message, ...)
{
-#ifndef LIBGFOR_MINIMAL
va_list ap;
fprintf (stderr, Fortran runtime error: );
va_start (ap, message);
vfprintf (stderr, message, ap);
va_end (ap);
fprintf (stderr, \n);
-#endif
+
/* FIXME: Shutdown the Fortran RTL to flush the buffer. PR 43849. */
exit (EXIT_FAILURE);
}
diff --git libgfortran/runtime/minimal.c libgfortran/runtime/minimal.c
index 7ef4647..72a134a 100644
--- libgfortran/runtime/minimal.c
+++ libgfortran/runtime/minimal.c
@@ -73,7 +73,10 @@ recursion_check (void)
magic = MAGIC;
}
-#define STRERR_MAXSZ 256
+
+/* os_error()-- Operating system error. We get a message from the
+ * operating system, show it and leave. Some operating system errors
+ * are caught and processed by the library. If not, we come here. */
void
os_error (const char *message)
@@ -85,6 +88,10 @@ os_error (const char *message)
}
iexport(os_error);
+
+/* void runtime_error()-- These are errors associated with an
+ * invalid fortran program. */
+
void
runtime_error (const char *message, ...)
{
@@ -109,7 +116,8 @@ runtime_error_at (const char *where, const char *message,
...)
va_list ap;
recursion_check ();
- printf (Fortran runtime error: );
+ printf (%s, where);
+ printf (\nFortran runtime error: );
va_start (ap, message);
vprintf (message, ap);
va_end (ap);
@@ -118,6 +126,43 @@ runtime_error_at (const char *where, const char *message,
...)
}
iexport(runtime_error_at);
+
+void
+runtime_warning_at (const char *where, const char *message, ...)
+{
+ va_list ap;
+
+ printf (%s, where);
+ printf (\nFortran runtime warning: );
+ va_start (ap, message);
+ vprintf (message, ap);
+ va_end (ap);
+ printf (\n);
+}
+iexport(runtime_warning_at);
+
+
+/* void internal_error()-- These are this-can't-happen errors
+ * that indicate something deeply wrong. */
+
+void
+internal_error (st_parameter_common *cmp, const char *message)
+{
+ recursion_check ();
+ printf (Internal Error: );
+ printf (%s, message);
+ printf (\n);
+
+ /* This function call is here to get the main.o object file included
+ when linking statically. This works because error.o is supposed to
+ be always linked in (and the function call is in internal_error
+ because hopefully it doesn't happen too often). */
+ stupid_function_name_for_static_linking();
+
+ exit (3);
+}
+
+
/* Return the full path of the executable. */
char *
full_exe_path (void)
@@ -153,6 +198,13 @@ get_args (int *argc, char ***argv)
void
sys_abort (void)
{
- printf (Abort called.\n);
+ /* If backtracing is enabled, print backtrace and disable signal
+ handler for ABRT. */
+ if (options.backtrace == 1
+ || (options.backtrace == -1
[PATCH] Fix __has_{cpp_}attribute with -traditional-cpp (PR preprocessor/65238)
Hi!
__has_{cpp_,}attribute builtin macros are effectively function-like macros
taking one argument (and the ISO preprocessor expands macros in the argument
which is IMHO desirable), but the traditional preprocessor has been crashing
on them or reporting errors.
As the hook uses cpp_get_token and thus the ISO preprocessor, we need to set
up things such that the argument and ()s around it are already preprocessed
and ready to be reparsed by the ISO preprocessor (this is similar to how
e.g. #if/#elif and various other directives are handled).
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2015-03-11 Jakub Jelinek ja...@redhat.com
PR preprocessor/65238
* internal.h (_cpp_scan_out_logical_line): Add third argument.
* directives.c (prepare_directive_trad): Pass false to it.
* traditional.c (_cpp_read_logical_line_trad,
_cpp_create_trad_definition): Likewise.
(struct fun_macro): Add paramc field.
(fun_like_macro): New function.
(maybe_start_funlike): Handle NODE_BUILTIN macros. Initialize
macro-paramc field.
(save_argument): Use macro-paramc instead of
macro-node-value.macro-paramc.
(push_replacement_text): Formatting fix.
(recursive_macro): Use fun_like_macro helper.
(_cpp_scan_out_logical_line): Likewise. Add BUILTIN_MACRO_ARG
argument. Initialize fmacro.paramc field. Handle builtin
function-like macros.
* c-c++-common/cpp/pr65238-1.c: New test.
* gcc.dg/cpp/pr65238-2.c: New test.
* gcc.dg/cpp/trad/pr65238-3.c: New test.
* gcc.dg/cpp/trad/pr65238-4.c: New test.
--- libcpp/internal.h.jj2015-02-03 10:33:59.0 +0100
+++ libcpp/internal.h 2015-03-11 14:11:13.410854083 +0100
@@ -708,7 +708,7 @@ extern void _cpp_preprocess_dir_only (cp
const struct _cpp_dir_only_callbacks *);
/* In traditional.c. */
-extern bool _cpp_scan_out_logical_line (cpp_reader *, cpp_macro *);
+extern bool _cpp_scan_out_logical_line (cpp_reader *, cpp_macro *, bool);
extern bool _cpp_read_logical_line_trad (cpp_reader *);
extern void _cpp_overlay_buffer (cpp_reader *pfile, const unsigned char *,
size_t);
--- libcpp/directives.c.jj 2015-01-23 19:18:20.0 +0100
+++ libcpp/directives.c 2015-03-11 14:11:34.742511193 +0100
@@ -346,7 +346,7 @@ prepare_directive_trad (cpp_reader *pfil
if (no_expand)
pfile-state.prevent_expansion++;
- _cpp_scan_out_logical_line (pfile, NULL);
+ _cpp_scan_out_logical_line (pfile, NULL, false);
if (no_expand)
pfile-state.prevent_expansion--;
--- libcpp/traditional.c.jj 2015-03-10 16:37:11.418949471 +0100
+++ libcpp/traditional.c2015-03-11 16:19:05.598475497 +0100
@@ -62,6 +62,9 @@ struct fun_macro
/* The line the macro name appeared on. */
source_location line;
+ /* Number of parameters. */
+ unsigned int paramc;
+
/* Zero-based index of argument being currently lexed. */
unsigned int argc;
};
@@ -304,24 +307,41 @@ _cpp_read_logical_line_trad (cpp_reader
if (pfile-buffer-need_line !_cpp_get_fresh_line (pfile))
return false;
}
- while (!_cpp_scan_out_logical_line (pfile, NULL) || pfile-state.skipping);
+ while (!_cpp_scan_out_logical_line (pfile, NULL, false)
+|| pfile-state.skipping);
return pfile-buffer != NULL;
}
+/* Return true if NODE is a fun_like macro. */
+static inline bool
+fun_like_macro (cpp_hashnode *node)
+{
+ if (node-flags NODE_BUILTIN)
+return node-value.builtin == BT_HAS_ATTRIBUTE;
+ else
+return node-value.macro-fun_like;
+}
+
/* Set up state for finding the opening '(' of a function-like
macro. */
static void
-maybe_start_funlike (cpp_reader *pfile, cpp_hashnode *node, const uchar
*start, struct fun_macro *macro)
+maybe_start_funlike (cpp_reader *pfile, cpp_hashnode *node, const uchar *start,
+struct fun_macro *macro)
{
- unsigned int n = node-value.macro-paramc + 1;
+ unsigned int n;
+ if (node-flags NODE_BUILTIN)
+n = 1;
+ else
+n = node-value.macro-paramc;
if (macro-buff)
_cpp_release_buff (pfile, macro-buff);
- macro-buff = _cpp_get_buff (pfile, n * sizeof (size_t));
+ macro-buff = _cpp_get_buff (pfile, (n + 1) * sizeof (size_t));
macro-args = (size_t *) BUFF_FRONT (macro-buff);
macro-node = node;
macro-offset = start - pfile-out.base;
+ macro-paramc = n;
macro-argc = 0;
}
@@ -330,7 +350,7 @@ static void
save_argument (struct fun_macro *macro, size_t offset)
{
macro-argc++;
- if (macro-argc = macro-node-value.macro-paramc)
+ if (macro-argc = macro-paramc)
macro-args[macro-argc] = offset;
}
@@ -340,9 +360,13 @@ save_argument (struct fun_macro *macro,
If MACRO is non-NULL, then we are scanning the replacement list of
MACRO, and we call save_replacement_text() every time we meet an
-
Re: [patch,avr]: Part3 and 4: Fix various problems with specs and specs file generation.
2015-03-10 18:02 GMT+03:00 Georg-Johann Lay a...@gjlay.de: This is just a small addendum to the option and specs handling: - Document new avr-gcc command options - Change -march= to -mmcu= in some test cases - Add comfigure test to detect whether gas supports -mrmw and --mlink-relax. - Use result of these tests in specs generatio, i.e. omit respective options if they are not supported. Ok to apply? Two issues remain: - The tests that add -mmcu= to the command options will fail because there must not be more than one -mmcu=. Supporting several, incompatible MCUs makes no sense (same for incompatible -march + -mmcu which was the case). In 4.9 this works per accident with unspecified definitions for built-in macros or when the options differ in default settings, for example. - Spaces in the installation path are not supported. It's possible to recover from spaces in -specs= by escaping them in spec function device-specs-file. However this is almost impossible for the device library without changing gcc.c which can use convert_white_space() as needed. Adding more than one escape level is not possible because the '\' would be interpreted as part of the path. Johann gcc/ PR target/65296 * configure.ac [avr]: Check as for options -mrmw, --mlink-relax. * configure: Regenerate. * config.in: Regenerate. * config/avr/gen-avr-mmcu-specs.c (config.h): Include it. (*asm_relax): Only define spec if HAVE_AS_AVR_MLINK_RELAX_OPTION. (*asm_rmw): Only define spec if HAVE_AS_AVR_MRMW_OPTION. gcc/ PR target/65296 * doc/invoke.texi (AVR Options) [-mrmw]: Document it. [-mn-flash]: Document it. [__AVR_DEVICE_NAME__]: Document it. [__ARV_ARCH__]: Document avrtiny. gcc/testsuite/ PR target/65296 * gcc.target/avr/tiny-memx: Use -mmcu instead of -march. * gcc.target/avr/tiny-caller-save.c: Same. gcc/ PR target/65296 * configure.ac [avr]: Check as for option -mrmw. * configure: Regenerate. * config.in: Regenerate. * config/avr/driver-avr.c (avr_device_to_as): Don't add -mrmw to assembler options if not HAVE_AS_AVR_MRMW_OPTION. Approved. Denis.
[PATCH] Fix some memory leaks
Hi! Valgrind reported some memory leaks. record_builtin_type calls just get_identifier on the name, and get_identifier never uses the original string for storage, it always allocates it on its own, so using xstrdup as get_identifier argument leaks the memory. Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? 2015-03-11 Jakub Jelinek ja...@redhat.com * c-parser.c (c_parse_init): Don't call xstrdup on get_identifier argument. * c-common.c (c_common_nodes_and_builtins): Don't call xstrdup on record_builtin_type argument. --- gcc/c/c-parser.c.jj 2015-02-11 14:39:50.0 +0100 +++ gcc/c/c-parser.c2015-03-11 16:08:50.282377367 +0100 @@ -139,7 +139,7 @@ c_parse_init (void) /* We always create the symbols but they aren't always supported. */ char name[50]; sprintf (name, __int%d, int_n_data[i].bitsize); - id = get_identifier (xstrdup (name)); + id = get_identifier (name); C_SET_RID_CODE (id, RID_FIRST_INT_N + i); C_IS_RESERVED_WORD (id) = 1; } --- gcc/c-family/c-common.c.jj 2015-03-10 07:37:56.0 +0100 +++ gcc/c-family/c-common.c 2015-03-11 16:11:07.311171401 +0100 @@ -5458,11 +5458,10 @@ c_common_nodes_and_builtins (void) char name[25]; sprintf (name, __int%d, int_n_data[i].bitsize); - record_builtin_type ((enum rid)(RID_FIRST_INT_N + i), xstrdup (name), + record_builtin_type ((enum rid)(RID_FIRST_INT_N + i), name, int_n_trees[i].signed_type); sprintf (name, __int%d unsigned, int_n_data[i].bitsize); - record_builtin_type (RID_MAX, xstrdup (name), - int_n_trees[i].unsigned_type); + record_builtin_type (RID_MAX, name, int_n_trees[i].unsigned_type); } if (c_dialect_cxx ()) Jakub
Re: [PATCH] Fix typo in tail merging (PR tree-optimization/65388)
On March 11, 2015 2:32:18 PM CET, Marek Polacek pola...@redhat.com wrote:
This patch fixes a pretty obvious typo: we couldn't possibly want to
test
whether a variable equals itself. PR c/54979 is an RFE for a warning
that
would detect such cases.
Bootstrapped/regtested on x86_64-linux, ok for active branches?
Ok
Thanks,
Richard.
2015-03-11 Marek Polacek pola...@redhat.com
PR tree-optimization/65388
* tree-ssa-tail-merge.c (same_succ_def::equal): Fix typo in
comparison.
--- gcc/tree-ssa-tail-merge.c
+++ gcc/tree-ssa-tail-merge.c
@@ -587,7 +587,7 @@ same_succ_def::equal (const value_type *e1, const
compare_type *e2)
if (!inverse_flags (e1, e2))
{
for (i = 0; i e1-succ_flags.length (); ++i)
- if (e1-succ_flags[i] != e1-succ_flags[i])
+ if (e1-succ_flags[i] != e2-succ_flags[i])
return 0;
}
Re: [wwwdocs] Document __has_attribute in /gcc-5/changes.html
On 11/03/15 19:14 +0100, Jakub Jelinek wrote: On Wed, Mar 11, 2015 at 06:09:11PM +, Jonathan Wakely wrote: This is a slightly-modified version of Ed's patch from https://gcc.gnu.org/ml/gcc-patches/2015-01/msg02357.html which I plan to commit to CVS tomorrow. Index: changes.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-5/changes.html,v retrieving revision 1.88 diff -u -r1.88 changes.html --- changes.html10 Mar 2015 17:34:36 - 1.88 +++ changes.html11 Mar 2015 18:06:52 - @@ -189,6 +189,29 @@ of the standard directive code#include/code and the extension code#include_next/code respectively. /li +liA new built-in function to detect the existence of an attribute, Can you please instead write built-in function-like macro? Yep, revised patch attached. Index: changes.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-5/changes.html,v retrieving revision 1.88 diff -u -r1.88 changes.html --- changes.html 10 Mar 2015 17:34:36 - 1.88 +++ changes.html 11 Mar 2015 18:41:25 - @@ -189,6 +189,30 @@ of the standard directive code#include/code and the extension code#include_next/code respectively. /li +liA new built-in function-like macro to detect the existence of an + attribute, code__has_attribute/code, has been added. + The equivalent built-in macro code__has_cpp_attribute/code was + added to C++ to support + a href=http://isocpp.org/std/standing-documents/sd-6-sg10-feature-test-recommendations; + Feature-testing recommendations for C++/a. + The macro code__has_attribute/code is added to all C-like + languages as an extension: +blockquotepre +int +#ifdef __has_attribute +# if __has_attribute(__noinline__) + __attribute__((__noinline__)) +# endif +#endif +foo(int x); +/pre/blockquote + If an attribute exists a nonzero constant integer is returned. + For standardized C++ attributes a date is returned, otherwise the + constant returned is 1. + The has_attribute macros will add underscores to an attribute name + if necessary to resolve the name. + For C++11 and onwards the attribute may be scoped. +/li liA new set of built-in functions for arithmetics with overflow checking has been added: code__builtin_add_overflow/code, code__builtin_sub_overflow/code and code__builtin_mul_overflow/code
Re: [PATCH] Fix some memory leaks
On March 11, 2015 8:04:25 PM CET, Jakub Jelinek ja...@redhat.com wrote: Hi! Valgrind reported some memory leaks. record_builtin_type calls just get_identifier on the name, and get_identifier never uses the original string for storage, it always allocates it on its own, so using xstrdup as get_identifier argument leaks the memory. Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? OK. Thanks, Richard. 2015-03-11 Jakub Jelinek ja...@redhat.com * c-parser.c (c_parse_init): Don't call xstrdup on get_identifier argument. * c-common.c (c_common_nodes_and_builtins): Don't call xstrdup on record_builtin_type argument. --- gcc/c/c-parser.c.jj2015-02-11 14:39:50.0 +0100 +++ gcc/c/c-parser.c 2015-03-11 16:08:50.282377367 +0100 @@ -139,7 +139,7 @@ c_parse_init (void) /* We always create the symbols but they aren't always supported. */ char name[50]; sprintf (name, __int%d, int_n_data[i].bitsize); - id = get_identifier (xstrdup (name)); + id = get_identifier (name); C_SET_RID_CODE (id, RID_FIRST_INT_N + i); C_IS_RESERVED_WORD (id) = 1; } --- gcc/c-family/c-common.c.jj 2015-03-10 07:37:56.0 +0100 +++ gcc/c-family/c-common.c2015-03-11 16:11:07.311171401 +0100 @@ -5458,11 +5458,10 @@ c_common_nodes_and_builtins (void) char name[25]; sprintf (name, __int%d, int_n_data[i].bitsize); - record_builtin_type ((enum rid)(RID_FIRST_INT_N + i), xstrdup (name), + record_builtin_type ((enum rid)(RID_FIRST_INT_N + i), name, int_n_trees[i].signed_type); sprintf (name, __int%d unsigned, int_n_data[i].bitsize); - record_builtin_type (RID_MAX, xstrdup (name), - int_n_trees[i].unsigned_type); + record_builtin_type (RID_MAX, name, int_n_trees[i].unsigned_type); } if (c_dialect_cxx ()) Jakub
[wwwdocs] Document __has_attribute in /gcc-5/changes.html
This is a slightly-modified version of Ed's patch from https://gcc.gnu.org/ml/gcc-patches/2015-01/msg02357.html which I plan to commit to CVS tomorrow. Index: changes.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-5/changes.html,v retrieving revision 1.88 diff -u -r1.88 changes.html --- changes.html 10 Mar 2015 17:34:36 - 1.88 +++ changes.html 11 Mar 2015 18:06:52 - @@ -189,6 +189,29 @@ of the standard directive code#include/code and the extension code#include_next/code respectively. /li +liA new built-in function to detect the existence of an attribute, + code__has_attribute/code, has been added. The equivalent built-in + function code__has_cpp_attribute/code was added to C++ to support + a href=http://isocpp.org/std/standing-documents/sd-6-sg10-feature-test-recommendations; + Feature-testing recommendations for C++/a. + The function code__has_attribute/code is added to all C-like + languages as an extension: +blockquotepre +int +#ifdef __has_attribute +# if __has_attribute(__noinline__) + __attribute__((__noinline__)) +# endif +#endif +foo(int x); +/pre/blockquote + If an attribute exists a nonzero constant integer is returned. + For standardized C++ attributes a date is returned, otherwise the + constant returned is 1. + The has_attribute macros will add underscores to an attribute name + if necessary to resolve the name. + For C++11 and onwards the attribute may be scoped. +/li liA new set of built-in functions for arithmetics with overflow checking has been added: code__builtin_add_overflow/code, code__builtin_sub_overflow/code and code__builtin_mul_overflow/code
Re: [PATCH] optionally disable global check
On Fri, Mar 06, 2015 at 05:23:47PM +0300, Marat Zakirov wrote:
Hi all!
Currently !ASAN_GLOBALS disables red-zones for global variables but keeps
their checks. This simple patch disables these checks too.
I've noticed
UNRESOLVED: c-c++-common/asan/no-asan-check-glob.c -O0 scan-tree-dump-times
asan1 ASAN_CHECK 0
UNRESOLVED: c-c++-common/asan/no-asan-check-glob.c -O2 -flto
-fuse-linker-plugin -fno-fat-lto-objects scan-tree-dump-times asan1
ASAN_CHECK 0
in my last build, fixed thusly, committed as obvious:
2015-03-11 Jakub Jelinek ja...@redhat.com
* c-c++-common/asan/no-asan-check-glob.c: Add -ffat-lto-objects
to dg-options, fix up dg-skip-if.
--- gcc/testsuite/c-c++-common/asan/no-asan-check-glob.c.jj 2015-03-11
20:17:46.0 +0100
+++ gcc/testsuite/c-c++-common/asan/no-asan-check-glob.c2015-03-11
20:47:22.010109724 +0100
@@ -1,6 +1,6 @@
-/* { dg-options --param asan-globals=0 -fdump-tree-asan } */
+/* { dg-options --param asan-globals=0 -fdump-tree-asan1 -ffat-lto-objects }
*/
/* { dg-do compile } */
-/* { dg-skip-if { *-*-* } { -O0 } { * } } */
+/* { dg-skip-if { *-*-* } { -O0 } { } } */
extern int a;
Jakub
Re: [wwwdocs] Document __has_attribute in /gcc-5/changes.html
On Wed, Mar 11, 2015 at 06:09:11PM +, Jonathan Wakely wrote: This is a slightly-modified version of Ed's patch from https://gcc.gnu.org/ml/gcc-patches/2015-01/msg02357.html which I plan to commit to CVS tomorrow. Index: changes.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-5/changes.html,v retrieving revision 1.88 diff -u -r1.88 changes.html --- changes.html 10 Mar 2015 17:34:36 - 1.88 +++ changes.html 11 Mar 2015 18:06:52 - @@ -189,6 +189,29 @@ of the standard directive code#include/code and the extension code#include_next/code respectively. /li +liA new built-in function to detect the existence of an attribute, Can you please instead write built-in function-like macro? + code__has_attribute/code, has been added. The equivalent built-in + function code__has_cpp_attribute/code was added to C++ to support + a href=http://isocpp.org/std/standing-documents/sd-6-sg10-feature-test-recommendations; + Feature-testing recommendations for C++/a. + The function code__has_attribute/code is added to all C-like + languages as an extension: +blockquotepre +int +#ifdef __has_attribute +# if __has_attribute(__noinline__) + __attribute__((__noinline__)) +# endif +#endif +foo(int x); +/pre/blockquote + If an attribute exists a nonzero constant integer is returned. + For standardized C++ attributes a date is returned, otherwise the + constant returned is 1. + The has_attribute macros will add underscores to an attribute name + if necessary to resolve the name. + For C++11 and onwards the attribute may be scoped. +/li liA new set of built-in functions for arithmetics with overflow checking has been added: code__builtin_add_overflow/code, code__builtin_sub_overflow/code and code__builtin_mul_overflow/code Jakub
Re: [PATCH] PR target/65240, Fix Power{7,8} insn constraint issue with -O3 -ffast-math
On Wed, Mar 11, 2015 at 6:21 PM, Michael Meissner meiss...@linux.vnet.ibm.com wrote: On Wed, Mar 11, 2015 at 01:02:06PM -0400, David Edelsohn wrote: I am concerned with the create_TOC_reference use for TARGET_TOC. Has this been tested with big endian -mcmodel=small? Yes, that was a problem. Patch coming up soon. Thanks. Can you call rs6000_emit_move_directly? Thanks, David
[PINGv2][PATCH] ASan phase place change
On 03/03/2015 10:36 AM, Marat Zakirov wrote:
On 02/24/2015 03:49 PM, Marat Zakirov wrote:
On 02/20/2015 03:07 PM, Jakub Jelinek wrote:
On Fri, Feb 20, 2015 at 02:59:51PM +0300, Marat Zakirov wrote:
Here is simple patch that moves asan phase just behind sanopt for all
O0/O1/O2/O3 modes which gives +7% on x86 SPEC2006 (ref dataset).
Regression testing and sanitized GCC bootstrapping were
successfully done.
This isn't a regression, so I think it isn't appropriate for stage 4.
I bet the difference is mainly vectorization. I believe the right
change is to teach the vectorizer about the ASAN_CHECK internal call
instead.
Jakub
Jakub,
I reproduced +28% for 433.milk with -fno-tree-vectorize on ref
data. Are there some other GCC vectorization options? And why do you
think that performance difference caused only by vectorization? As an
example In llvm loop hoisting suffers from early asan phase
http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-December/046332.html.
--Marat
gcc/ChangeLog:
2015-02-20 Marat Zakirov m.zaki...@samsung.com
* asan.c (make_pass_asan_O0): Pass remove.
* passes.def: Change place for ASan pass.
* tree-pass.h: Passes remove.
* tsan.c (make_pass_tsan_O0): Pass remove.
gcc/testsuite/ChangeLog:
2015-02-20 Marat Zakirov m.zaki...@samsung.com
* c-c++-common/asan/inc.c: Fix option.
diff --git a/gcc/asan.c b/gcc/asan.c
index b7c2b11..001d79e 100644
--- a/gcc/asan.c
+++ b/gcc/asan.c
@@ -2796,40 +2796,4 @@ make_pass_asan (gcc::context *ctxt)
return new pass_asan (ctxt);
}
-namespace {
-
-const pass_data pass_data_asan_O0 =
-{
- GIMPLE_PASS, /* type */
- asan0, /* name */
- OPTGROUP_NONE, /* optinfo_flags */
- TV_NONE, /* tv_id */
- ( PROP_ssa | PROP_cfg | PROP_gimple_leh ), /* properties_required */
- 0, /* properties_provided */
- 0, /* properties_destroyed */
- 0, /* todo_flags_start */
- TODO_update_ssa, /* todo_flags_finish */
-};
-
-class pass_asan_O0 : public gimple_opt_pass
-{
-public:
- pass_asan_O0 (gcc::context *ctxt)
-: gimple_opt_pass (pass_data_asan_O0, ctxt)
- {}
-
- /* opt_pass methods: */
- virtual bool gate (function *) { return !optimize gate_asan (); }
- virtual unsigned int execute (function *) { return asan_instrument (); }
-
-}; // class pass_asan_O0
-
-} // anon namespace
-
-gimple_opt_pass *
-make_pass_asan_O0 (gcc::context *ctxt)
-{
- return new pass_asan_O0 (ctxt);
-}
-
#include gt-asan.h
diff --git a/gcc/passes.def b/gcc/passes.def
index 2bc5dcd..398d8dc 100644
--- a/gcc/passes.def
+++ b/gcc/passes.def
@@ -214,8 +214,6 @@ along with GCC; see the file COPYING3. If not see
NEXT_PASS (pass_split_crit_edges);
NEXT_PASS (pass_pre);
NEXT_PASS (pass_sink_code);
- NEXT_PASS (pass_asan);
- NEXT_PASS (pass_tsan);
/* Pass group that runs when 1) enabled, 2) there are loops
in the function. Make sure to run pass_fix_loops before
to discover/remove loops before running the gate function
@@ -344,8 +342,8 @@ along with GCC; see the file COPYING3. If not see
NEXT_PASS (pass_vtable_verify);
NEXT_PASS (pass_lower_vector);
NEXT_PASS (pass_lower_complex_O0);
- NEXT_PASS (pass_asan_O0);
- NEXT_PASS (pass_tsan_O0);
+ NEXT_PASS (pass_asan);
+ NEXT_PASS (pass_tsan);
NEXT_PASS (pass_sanopt);
NEXT_PASS (pass_cleanup_eh);
NEXT_PASS (pass_lower_resx);
diff --git a/gcc/testsuite/c-c++-common/asan/inc.c b/gcc/testsuite/c-c++-common/asan/inc.c
index 36cc3d8..8c38150 100644
--- a/gcc/testsuite/c-c++-common/asan/inc.c
+++ b/gcc/testsuite/c-c++-common/asan/inc.c
@@ -1,4 +1,4 @@
-/* { dg-options -fdump-tree-asan0 } */
+/* { dg-options -fdump-tree-asan } */
/* { dg-do compile } */
/* { dg-skip-if { *-*-* } { * } { -O0 } } */
@@ -16,6 +16,6 @@ main ()
return 0;
}
-/* { dg-final { scan-tree-dump-times ASAN_ 1 asan0 } } */
-/* { dg-final { scan-tree-dump ASAN_CHECK \\(.*, 4\\); asan0 } } */
-/* { dg-final { cleanup-tree-dump asan0 } } */
+/* { dg-final { scan-tree-dump-times ASAN_ 1 asan } } */
+/* { dg-final { scan-tree-dump ASAN_CHECK \\(.*, 4\\); asan } } */
+/* { dg-final { cleanup-tree-dump asan } } */
diff --git a/gcc/tree-pass.h b/gcc/tree-pass.h
index b59ae7a..50cbf85 100644
--- a/gcc/tree-pass.h
+++ b/gcc/tree-pass.h
@@ -339,9 +339,7 @@ extern simple_ipa_opt_pass *make_pass_ipa_chkp_produce_thunks (gcc::context *ctx
extern gimple_opt_pass *make_pass_chkp (gcc::context *ctxt);
extern gimple_opt_pass *make_pass_chkp_opt (gcc::context *ctxt);
extern gimple_opt_pass *make_pass_asan (gcc::context *ctxt);
-extern gimple_opt_pass *make_pass_asan_O0 (gcc::context *ctxt);
extern gimple_opt_pass *make_pass_tsan (gcc::context *ctxt);
-extern gimple_opt_pass *make_pass_tsan_O0 (gcc::context *ctxt);
extern gimple_opt_pass *make_pass_lower_cf (gcc::context *ctxt);
extern gimple_opt_pass *make_pass_refactor_eh (gcc::context *ctxt);
extern gimple_opt_pass *make_pass_lower_eh (gcc::context *ctxt);
diff --git a/gcc/tsan.c b/gcc/tsan.c
index ae89d5f..a9dca1f 100644
Re: [PATCH ] IRA: Speed up setup_left_conflict_sizes_p
On Wed, Mar 11, 2015 at 3:39 AM, Zhouyi Zhou zhouzho...@gmail.com wrote:
From: Zhouyi Zhou yizhouz...@ict.ac.cn
In function setup_left_conflict_sizes_p, left conflict subnodes sizes
are computed in a down-to-up fashion through the regnodes foreast.
Speed up the process from prevent node itself to involve in this
computation.
Please use gcc_checking_assert()s.
Bootstrap and regtest scheduled on x86_64 GNU/Linux
Signed-off-by: Zhouyi Zhou yizhouz...@ict.ac.cn
---
gcc/ChangeLog |5 +
gcc/ira-color.c |8 +++-
2 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index b77fb5e..7688eda 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,8 @@
+2015-03-11 Zhouyi Zhou yizhouz...@ict.ac.cn
+
+ * ira-color.c (setup_left_conflict_sizes_p): Prevent node itself
+ from computing left conflict subnodes size.
+
2015-03-10 Jakub Jelinek ja...@redhat.com
PR target/65368
diff --git a/gcc/ira-color.c b/gcc/ira-color.c
index ff1fe8a..3e5c33a 100644
--- a/gcc/ira-color.c
+++ b/gcc/ira-color.c
@@ -938,7 +938,7 @@ setup_left_conflict_sizes_p (ira_allocno_t a)
subnodes[i].left_conflict_subnodes_size = 0;
}
start = node_preorder_num * allocno_hard_regs_nodes_num;
- for (i = data-hard_regs_subnodes_num - 1; i = 0; i--)
+ for (i = data-hard_regs_subnodes_num - 1; i 0; i--)
{
int size, parent_i;
allocno_hard_regs_node_t parent;
@@ -948,12 +948,10 @@ setup_left_conflict_sizes_p (ira_allocno_t a)
- subnodes[i].left_conflict_subnodes_size,
subnodes[i].left_conflict_size));
parent = allocno_hard_regs_nodes[i + node_preorder_num]-parent;
- if (parent == NULL)
- continue;
+ gcc_assert (parent);
parent_i
= allocno_hard_regs_subnode_index[start + parent-preorder_num];
- if (parent_i 0)
- continue;
+ gcc_assert (parent_i = 0);
subnodes[parent_i].left_conflict_subnodes_size += size;
}
left_conflict_subnodes_size = subnodes[0].left_conflict_subnodes_size;
--
1.7.10.4
Re: [PATCH] Backport ubsan fix to 4.9
On Tue, 10 Mar 2015, Marek Polacek wrote:
I'd like to backport the following patch that suppresses bogus ubsan errors.
I had to tweak the testcase a bit since 4.9 doesn't know
-fno-sanitize-recover.
Bootstrapped/regtested on x86_64-linux, ok for 4.9?
Ok.
Thanks,
Richard.
2015-03-10 Marek Polacek pola...@redhat.com
Backported from mainline
2014-12-04 Marek Polacek pola...@redhat.com
PR middle-end/56917
* fold-const.c (fold_unary_loc): Perform the negation in A's type
when transforming ~ (A - 1) or ~ (A + -1) to -A.
* c-c++-common/ubsan/pr56917.c: New test.
--- gcc/fold-const.c
+++ gcc/fold-const.c
@@ -8324,9 +8324,14 @@ fold_unary_loc (location_t loc, enum tree_code code,
tree type, tree op0)
integer_onep (TREE_OPERAND (arg0, 1)))
|| (TREE_CODE (arg0) == PLUS_EXPR
integer_all_onesp (TREE_OPERAND (arg0, 1)
- return fold_build1_loc (loc, NEGATE_EXPR, type,
- fold_convert_loc (loc, type,
- TREE_OPERAND (arg0, 0)));
+ {
+ /* Perform the negation in ARG0's type and only then convert
+ to TYPE as to avoid introducing undefined behavior. */
+ tree t = fold_build1_loc (loc, NEGATE_EXPR,
+ TREE_TYPE (TREE_OPERAND (arg0, 0)),
+ TREE_OPERAND (arg0, 0));
+ return fold_convert_loc (loc, type, t);
+ }
/* Convert ~(X ^ Y) to ~X ^ Y or X ^ ~Y if ~X or ~Y simplify. */
else if (TREE_CODE (arg0) == BIT_XOR_EXPR
(tem = fold_unary_loc (loc, BIT_NOT_EXPR, type,
--- gcc/testsuite/c-c++-common/ubsan/pr56917.c
+++ gcc/testsuite/c-c++-common/ubsan/pr56917.c
@@ -0,0 +1,43 @@
+/* PR middle-end/56917 */
+/* { dg-do run } */
+/* { dg-options -fsanitize=undefined } */
+
+#include stdio.h
+
+#define INT_MIN (-__INT_MAX__ - 1)
+#define LONG_MIN (-__LONG_MAX__ - 1L)
+#define LLONG_MIN (-__LONG_LONG_MAX__ - 1LL)
+
+int __attribute__ ((noinline,noclone))
+fn1 (unsigned int u)
+{
+ return (-(int) (u - 1U)) - 1;
+}
+
+long __attribute__ ((noinline,noclone))
+fn2 (unsigned long int ul)
+{
+ return (-(long) (ul - 1UL)) - 1L;
+}
+
+long long __attribute__ ((noinline,noclone))
+fn3 (unsigned long long int ull)
+{
+ return (-(long long) (ull - 1ULL)) - 1LL;
+}
+
+int
+main (void)
+{
+ fputs (UBSAN TEST START\n, stderr);
+
+ if (fn1 (__INT_MAX__ + 1U) != INT_MIN
+ || fn2 (__LONG_MAX__ + 1UL) != LONG_MIN
+ || fn3 (__LONG_LONG_MAX__ + 1ULL) != LLONG_MIN)
+__builtin_abort ();
+
+ fputs (UBSAN TEST END\n, stderr);
+ return 0;
+}
+
+/* { dg-output UBSAN TEST START(\n|\r\n|\r)UBSAN TEST END } */
Marek
--
Richard Biener rguent...@suse.de
SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Jennifer Guild,
Dilip Upmanyu, Graham Norton HRB 21284 (AG Nuernberg)
Re: [PINGv2][PATCH] ASan phase place change
On 03/11/2015 10:43 AM, Marat Zakirov wrote: On 03/03/2015 10:36 AM, Marat Zakirov wrote: On 02/24/2015 03:49 PM, Marat Zakirov wrote: On 02/20/2015 03:07 PM, Jakub Jelinek wrote: On Fri, Feb 20, 2015 at 02:59:51PM +0300, Marat Zakirov wrote: Here is simple patch that moves asan phase just behind sanopt for all O0/O1/O2/O3 modes which gives +7% on x86 SPEC2006 (ref dataset). Regression testing and sanitized GCC bootstrapping were successfully done. This isn't a regression, so I think it isn't appropriate for stage 4. I bet the difference is mainly vectorization. I believe the right change is to teach the vectorizer about the ASAN_CHECK internal call instead. Jakub Jakub, I reproduced +28% for 433.milk with -fno-tree-vectorize on ref data. Are there some other GCC vectorization options? And why do you think that performance difference caused only by vectorization? As an example In llvm loop hoisting suffers from early asan phase http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-December/046332.html. I think it would help if we could analyze where performance improvements are coming from. You can check Max's presentation for inspiration (http://www.youtube.com/watch?v=qTDBHJsWDHw). -Y
[PATCH] Fix typo in tail merging (PR tree-optimization/65388)
This patch fixes a pretty obvious typo: we couldn't possibly want to test
whether a variable equals itself. PR c/54979 is an RFE for a warning that
would detect such cases.
Bootstrapped/regtested on x86_64-linux, ok for active branches?
2015-03-11 Marek Polacek pola...@redhat.com
PR tree-optimization/65388
* tree-ssa-tail-merge.c (same_succ_def::equal): Fix typo in comparison.
--- gcc/tree-ssa-tail-merge.c
+++ gcc/tree-ssa-tail-merge.c
@@ -587,7 +587,7 @@ same_succ_def::equal (const value_type *e1, const
compare_type *e2)
if (!inverse_flags (e1, e2))
{
for (i = 0; i e1-succ_flags.length (); ++i)
- if (e1-succ_flags[i] != e1-succ_flags[i])
+ if (e1-succ_flags[i] != e2-succ_flags[i])
return 0;
}
Re: [patch] Optimize empty class copies within a C++ return statement
On 03/10/2015 09:45 PM, Aldy Hernandez wrote: + gimplify_expr (TREE_OPERAND (*expr_p, 0), pre_p, post_p, ... + *expr_p = TREE_OPERAND (*expr_p, 0); Can't you use op0 here, since you're about to throw away the MODIFY_EXPR? OK either way. Jason
[PATCH V2] IRA: Speed up setup_left_conflict_sizes_p
From: Zhouyi Zhou zhouzho...@gmail.com
In function setup_left_conflict_sizes_p, left conflict subnodes sizes
are computed in a bottom-to-up fashion through the regnodes foreast.
Speed up the process from prevent node itself to involve in this
computation.
I have no write access to GCC SVN repository, if it OK, can you commit
for me?
(Thanks Richard for reviewing)
Bootstrap and regtest scheduled on x86_64 GNU/Linux
Signed-off-by: Zhouyi Zhou yizhouz...@ict.ac.cn
---
gcc/ChangeLog |5 +
gcc/ira-color.c |8 +++-
2 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 53f582b..a495dfc 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,8 @@
+2015-03-12 Zhouyi Zhou yizhouz...@ict.ac.cn
+
+ * ira-color.c (setup_left_conflict_sizes_p): Prevent node itself
+ from computing left conflict subnodes size.
+
2015-03-10 Jan Hubicka hubi...@ucw.cz
* cgraph.c (cgraph_node::release_body): Free function_in_decl_state.
diff --git a/gcc/ira-color.c b/gcc/ira-color.c
index ff1fe8a..d2d5102 100644
--- a/gcc/ira-color.c
+++ b/gcc/ira-color.c
@@ -938,7 +938,7 @@ setup_left_conflict_sizes_p (ira_allocno_t a)
subnodes[i].left_conflict_subnodes_size = 0;
}
start = node_preorder_num * allocno_hard_regs_nodes_num;
- for (i = data-hard_regs_subnodes_num - 1; i = 0; i--)
+ for (i = data-hard_regs_subnodes_num - 1; i 0; i--)
{
int size, parent_i;
allocno_hard_regs_node_t parent;
@@ -948,12 +948,10 @@ setup_left_conflict_sizes_p (ira_allocno_t a)
- subnodes[i].left_conflict_subnodes_size,
subnodes[i].left_conflict_size));
parent = allocno_hard_regs_nodes[i + node_preorder_num]-parent;
- if (parent == NULL)
- continue;
+ gcc_checking_assert(parent);
parent_i
= allocno_hard_regs_subnode_index[start + parent-preorder_num];
- if (parent_i 0)
- continue;
+ gcc_checking_assert(parent_i = 0);
subnodes[parent_i].left_conflict_subnodes_size += size;
}
left_conflict_subnodes_size = subnodes[0].left_conflict_subnodes_size;
--
1.7.10.4
[testsuite, committed] require fpic support for g++.dg/ipa/pr64146.C
I noticed that g++.dg/ipa/pr64146.C was FAILing on nios2-elf because
this target doesn't support -fpic; the ABI defines the PIC relocations
for GNU/Linux only, so -fpic gives a sorry in the bare-metal toolchain.
From reading the PR, my understanding is that the bug is specific to
PIC and the behavior being tested for in the testcase is also specific
to PIC, so I think the attached patch to skip the test if PIC isn't
supported qualifies as obvious, and I've checked it in.
-Sandra
2015-03-11 Sandra Loosemore san...@codesourcery.com
gcc/testsuite/
* g++.dg/ipa/pr64146.C: Require fpic support.
Index: gcc/testsuite/g++.dg/ipa/pr64146.C
===
--- gcc/testsuite/g++.dg/ipa/pr64146.C (revision 221276)
+++ gcc/testsuite/g++.dg/ipa/pr64146.C (working copy)
@@ -1,5 +1,6 @@
/* { dg-do compile } */
/* { dg-require-alias } */
+/* { dg-require-effective-target fpic } */
/* { dg-options -fpic -fdump-ipa-icf-details -fipa-icf } */
extern C const char*
Re: [PATCH] PR target/65240, Fix Power{7,8} insn constraint issue with -O3 -ffast-math
On Wed, Mar 11, 2015 at 01:02:06PM -0400, David Edelsohn wrote: I am concerned with the create_TOC_reference use for TARGET_TOC. Has this been tested with big endian -mcmodel=small? Yes, that was a problem. Patch coming up soon. Thanks. -- Michael Meissner, IBM IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA email: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797
Re: [PATCH, TSAN] Fix a crash in ScopedReport::AddThread
On Wed, Mar 11, 2015 at 03:41:27PM +0100, Bernd Edlinger wrote: Hi Jakub, with my OPC UA Server, I observe a reproducible crash in ScopedReport::AddThread: tctx==NULL in if ((u32)rep_-threads[i]-id == tctx-tid). Apparently, Dmitry has already fixed that in the obvious way. So we should cherry pick these two changes from LLVM: 224508 and 224755 See attachment. Builds cleanly and fixes the problem for me. OK for trunk? Ok. Jakub
Re: [PATCH] PR target/65242, Fix powerpc abort in gen_add2_insn
On Mon, Mar 9, 2015 at 7:30 PM, Michael Meissner meiss...@linux.vnet.ibm.com wrote: This bug was one I unfortunately introduced with the -mupper-regs support. If the reload pass needed to reload a PLUS operation (for example, due to using odd address with the LD/STD instructions), it would go through all of the registers you could load DImode into, and see if it is a preferred register class. This lead the compiler to believe it could do integer arithmetic in the floating point registers. This patch fixes the problem, by not allowing PLUS to be reloaded into FPR registers. I have done bootstraps and make checks on both a big endian Power7 and a little endian Power8 system, and there were no regressions. Is the patch ok to apply? I do not believe it needs to be back ported to GCC 4.9 since the -mupper-regs changes are not installed currently on that branch. [gcc] 2015-03-09 Michael Meissner meiss...@linux.vnet.ibm.com PR target/65242 * config/rs6000/rs6000.c (rs6000_preferred_reload_class): Do not allow reloads of PLUS in floating point/VSX registers. [gcc/testsuite] 2015-03-09 Michael Meissner meiss...@linux.vnet.ibm.com PR target/65242 * g++.dg/pr65242.C: New test. This is okay. What about Jeff Law's Bugzilla comment #6 to change ?m to !m in the movdi_internal64 pattern? That also seems reasonable. Thanks, David
