[arm-embedded] enable multilib for embedded-4_9-branch
Hi there, I just committed attached patch to enable build multilib for ARM embedded-4_9-branch. BR, Terry 2014-05-12 Terry Guo terry@arm.com * config.gcc (--with-multilib-list): Accept arm embedded cores. * configure.ac (with_multilib_list): Export for being used in arm embedded multilib fragment. * configure: Regenerated. * Makefile.in (with_multilib_list): Import for being used in multilib fragment. * config/arm/t-rmprofile: New multilib fragment for arm embedded cores.Index: gcc/Makefile.in === --- gcc/Makefile.in (revision 210319) +++ gcc/Makefile.in (working copy) @@ -540,6 +540,7 @@ lang_specs_files=@lang_specs_files@ lang_tree_files=@lang_tree_files@ target_cpu_default=@target_cpu_default@ +with_multilib_list=@with_multilib_list@ OBJC_BOEHM_GC=@objc_boehm_gc@ extra_modes_file=@extra_modes_file@ extra_opt_files=@extra_opt_files@ Index: gcc/config/arm/t-rmprofile === --- gcc/config/arm/t-rmprofile (revision 0) +++ gcc/config/arm/t-rmprofile (working copy) @@ -0,0 +1,86 @@ +# A set of predefined MULTILIB which can be used for different ARM targets. +# Via the configure option --with-multilib-list, user can customize the +# final MULTILIB implementation. + +comma := , +space := +space += + +MULTILIB_OPTIONS = mthumb/marm +MULTILIB_DIRNAMES = thumb arm +MULTILIB_OPTIONS += march=armv6s-m/march=armv7-m/march=armv7e-m/march=armv7 +MULTILIB_DIRNAMES += armv6-m armv7-m armv7e-m armv7-ar +MULTILIB_OPTIONS += mfloat-abi=softfp/mfloat-abi=hard +MULTILIB_DIRNAMES += softfp fpu +MULTILIB_OPTIONS += mfpu=fpv4-sp-d16/mfpu=vfpv3-d16 +MULTILIB_DIRNAMES += fpv4-sp-d16 vfpv3-d16 + +MULTILIB_MATCHES = march?armv6s-m=mcpu?cortex-m0 +MULTILIB_MATCHES += march?armv6s-m=mcpu?cortex-m0plus +MULTILIB_MATCHES += march?armv6s-m=mcpu?cortex-m1 +MULTILIB_MATCHES += march?armv6s-m=march?armv6-m +MULTILIB_MATCHES += march?armv7-m=mcpu?cortex-m3 +MULTILIB_MATCHES += march?armv7e-m=mcpu?cortex-m4 +MULTILIB_MATCHES += march?armv7=march?armv7-r +MULTILIB_MATCHES += march?armv7=march?armv7-a +MULTILIB_MATCHES += march?armv7=mcpu?cortex-r4 +MULTILIB_MATCHES += march?armv7=mcpu?cortex-r4f +MULTILIB_MATCHES += march?armv7=mcpu?cortex-r5 +MULTILIB_MATCHES += march?armv7=mcpu?cortex-r7 +MULTILIB_MATCHES += march?armv7=mcpu?cortex-a5 +MULTILIB_MATCHES += march?armv7=mcpu?cortex-a7 +MULTILIB_MATCHES += march?armv7=mcpu?cortex-a8 +MULTILIB_MATCHES += march?armv7=mcpu?cortex-a9 +MULTILIB_MATCHES += march?armv7=mcpu?cortex-a15 +MULTILIB_MATCHES += mfpu?vfpv3-d16=mfpu?vfpv3 +MULTILIB_MATCHES += mfpu?vfpv3-d16=mfpu?vfpv3-fp16 +MULTILIB_MATCHES += mfpu?vfpv3-d16=mfpu?vfpv3-d16-fp16 +MULTILIB_MATCHES += mfpu?vfpv3-d16=mfpu?vfpv3xd +MULTILIB_MATCHES += mfpu?vfpv3-d16=mfpu?vfpv3xd-fp16 +MULTILIB_MATCHES += mfpu?vfpv3-d16=mfpu?vfpv4 +MULTILIB_MATCHES += mfpu?vfpv3-d16=mfpu?vfpv4-d16 +MULTILIB_MATCHES += mfpu?vfpv3-d16=mfpu?neon +MULTILIB_MATCHES += mfpu?vfpv3-d16=mfpu?neon-fp16 +MULTILIB_MATCHES += mfpu?vfpv3-d16=mfpu?neon-vfpv4 + +MULTILIB_EXCEPTIONS = +MULTILIB_REUSE = + +MULTILIB_REQUIRED = mthumb +MULTILIB_REQUIRED += marm +MULTILIB_REQUIRED += mfloat-abi=hard + +MULTILIB_OSDIRNAMES = mthumb=!thumb +MULTILIB_OSDIRNAMES += marm=!arm +MULTILIB_OSDIRNAMES += mfloat-abi.hard=!fpu + +ifneq (,$(findstring armv6-m,$(subst $(comma),$(space),$(with_multilib_list +MULTILIB_REQUIRED += mthumb/march=armv6s-m +MULTILIB_OSDIRNAMES += mthumb/march.armv6s-m=!armv6-m +endif + +ifneq (,$(findstring armv7-m,$(subst $(comma),$(space),$(with_multilib_list +MULTILIB_REQUIRED += mthumb/march=armv7-m +MULTILIB_OSDIRNAMES += mthumb/march.armv7-m=!armv7-m +endif + +ifneq (,$(findstring armv7e-m,$(subst $(comma),$(space),$(with_multilib_list +MULTILIB_REQUIRED += mthumb/march=armv7e-m +MULTILIB_REQUIRED += mthumb/march=armv7e-m/mfloat-abi=softfp/mfpu=fpv4-sp-d16 +MULTILIB_REQUIRED += mthumb/march=armv7e-m/mfloat-abi=hard/mfpu=fpv4-sp-d16 +MULTILIB_OSDIRNAMES += mthumb/march.armv7e-m=!armv7e-m +MULTILIB_OSDIRNAMES += mthumb/march.armv7e-m/mfloat-abi.hard/mfpu.fpv4-sp-d16=!armv7e-m/fpu +MULTILIB_OSDIRNAMES += mthumb/march.armv7e-m/mfloat-abi.softfp/mfpu.fpv4-sp-d16=!armv7e-m/softfp +endif + +ifneq (,$(filter armv7 armv7-r armv7-a,$(subst $(comma),$(space),$(with_multilib_list +MULTILIB_REQUIRED += mthumb/march=armv7 +MULTILIB_REQUIRED += mthumb/march=armv7/mfloat-abi=softfp/mfpu=vfpv3-d16 +MULTILIB_REQUIRED += mthumb/march=armv7/mfloat-abi=hard/mfpu=vfpv3-d16 +MULTILIB_OSDIRNAMES += mthumb/march.armv7=!armv7-ar/thumb +MULTILIB_OSDIRNAMES += mthumb/march.armv7/mfloat-abi.hard/mfpu.vfpv3-d16=!armv7-ar/thumb/fpu +MULTILIB_OSDIRNAMES += mthumb/march.armv7/mfloat-abi.softfp/mfpu.vfpv3-d16=!armv7-ar/thumb/softfp +MULTILIB_REUSE += mthumb/march.armv7=marm/march.armv7 +MULTILIB_REUSE +=
Re: genattrtab error reporting
Ping?
On May 7, 2014, at 2:21 PM, Mike Stump mikest...@comcast.net wrote:
getattrtab looses track of which file the given rtl came from during error
reporting. A port that uses multiple .md files for the port will tend to
list the last .md file processed instead of the correct md file. We preserve
the filename upon read, and during post processing, we reset the filename to
the right context, as we process that context.
Ok?
2014-05-07 Mike Stump mikest...@comcast.net
* genattrtab.c (struct insn_def): Add filename.
(convert_set_attr_alternative): Improve error message.
(check_defs): Ensure read_md_filename is set appropriately.
(gen_insn): Save read_md_filename.
diff --git a/gcc/genattrtab.c b/gcc/genattrtab.c
index 99b1b83..0f14b4d 100644
--- a/gcc/genattrtab.c
+++ b/gcc/genattrtab.c
@@ -139,6 +139,7 @@ struct insn_def
rtx def; /* The DEFINE_... */
int insn_code; /* Instruction number. */
int insn_index; /* Expression number in file, for errors. */
+ const char *filename;/* Filename. */
int lineno; /* Line number. */
int num_alternatives;/* Number of alternatives. */
int vec_idx; /* Index of attribute vector in `def'. */
@@ -1066,7 +1067,8 @@ convert_set_attr_alternative (rtx exp, struct insn_def
*id)
if (XVECLEN (exp, 1) != num_alt)
{
error_with_line (id-lineno,
- bad number of entries in SET_ATTR_ALTERNATIVE);
+ bad number of entries in SET_ATTR_ALTERNATIVE, was %d
expected %d,
+ XVECLEN (exp, 1), num_alt);
return NULL_RTX;
}
@@ -1137,6 +1139,7 @@ check_defs (void)
if (XVEC (id-def, id-vec_idx) == NULL)
continue;
+ read_md_filename = id-filename;
for (i = 0; i XVECLEN (id-def, id-vec_idx); i++)
{
value = XVECEXP (id-def, id-vec_idx, i);
@@ -3280,6 +3283,7 @@ gen_insn (rtx exp, int lineno)
id-next = defs;
defs = id;
id-def = exp;
+ id-filename = read_md_filename;
id-lineno = lineno;
switch (GET_CODE (exp))
RE: [Patch: RL78] Add support for 64-bit doubles
Hi DJ,
Thanks for your review earlier.
It looks OK, it's just the timing is bad. Please remind us after GCC is
back in stage1.
I am reposting this patch with GCC in stage 1.
I would also like to see an explicit initialization for the variable to
guarantee that the
default is 32-bit-doubles, or some other notation that guarantees the
default.
Does the macro ' TARGET_64BIT_DOUBLES ' not guarantee this?
'sizeof' returns length as 4 for doubles for default options and 8 for
-m64bit-doubles.
Is there any other way to do this explicitly?
Also, please note in the reminder that you've tested both options and don't
see any differences in the testsuite results
between them that reflect bugs in DFmode double support. Just because
you've enabled the type doesn't mean it
will work properly.
We have regression tested this for -m32bit-doubles, -m64bit-doubles and default
-msim options and results look OK.
Few additional failures for 64 bit types which were linker errors due to ROM
overflow. These were verified manually
by adjusting the linker script.
Please let me know if any modifications are required. Below patch is identical
to one submitted earlier.
Regards,
Kaushik
2014-05-12 Kaushik Phatak kaushik.pha...@kpit.com
* config/rl78/rl78.h (TARGET_CPU_CPP_BUILTINS): Define
__RL78_64BIT_DOUBLES__ or __RL78_32BIT_DOUBLES__.
(ASM_SPEC): Pass -m64bit-doubles or -m32bit-doubles on
to the assembler.
(DOUBLE_TYPE_SIZE): Use 64 bit if TARGET_64BIT_DOUBLES
is true.
(LIBGCC2_HAS_DF_MODE): Define based on __RL78_32BIT_DOUBLES__.
(LIBGCC2_LONG_DOUBLE_TYPE_SIZE): Use 64 bit is
__RL78_64BIT_DOUBLES__ is defined.
* gcc/config/rl78/rl78.opt (m64bit-doubles): New option.
(m32bit-doubles) Likewise.
* gcc/config/rl78/t-rl78: Add 64-bit-double multilib.
Index: gcc/config/rl78/rl78.h
===
--- gcc/config/rl78/rl78.h (revision 210319)
+++ gcc/config/rl78/rl78.h (working copy)
@@ -23,18 +23,22 @@
#define RL78_MUL_RL78 (rl78_mul_type == MUL_RL78)
#define RL78_MUL_G13 (rl78_mul_type == MUL_G13)
-#define TARGET_CPU_CPP_BUILTINS() \
- do\
-{ \
- builtin_define (__RL78__); \
- builtin_assert (cpu=RL78); \
- if (RL78_MUL_RL78) \
- builtin_define (__RL78_MUL_RL78__); \
- if (RL78_MUL_G13)\
- builtin_define (__RL78_MUL_G13__);\
- if (TARGET_G10) \
- builtin_define (__RL78_G10__);\
-} \
+#define TARGET_CPU_CPP_BUILTINS() \
+ do\
+{ \
+ builtin_define (__RL78__); \
+ builtin_assert (cpu=RL78); \
+ if (RL78_MUL_RL78) \
+ builtin_define (__RL78_MUL_RL78__); \
+ if (RL78_MUL_G13)\
+ builtin_define (__RL78_MUL_G13__);\
+ if (TARGET_G10) \
+ builtin_define (__RL78_G10__);\
+ if (TARGET_64BIT_DOUBLES)\
+builtin_define (__RL78_64BIT_DOUBLES__); \
+ else \
+builtin_define (__RL78_32BIT_DOUBLES__); \
+} \
while (0)
#undef STARTFILE_SPEC
@@ -47,6 +51,8 @@
#define ASM_SPEC \
%{mrelax:-relax} \
%{mg10} \
+%{m64bit-doubles:-m64bit-doubles} \
+%{!m64bit-doubles:-m32bit-doubles} \
#undef LINK_SPEC
@@ -95,11 +101,16 @@
#define LONG_LONG_TYPE_SIZE64
#define FLOAT_TYPE_SIZE32
-#define DOUBLE_TYPE_SIZE 32 /*64*/
+#define DOUBLE_TYPE_SIZE(TARGET_64BIT_DOUBLES ? 64 : 32)
#define LONG_DOUBLE_TYPE_SIZE 64 /*DOUBLE_TYPE_SIZE*/
-#define LIBGCC2_HAS_DF_MODE1
+#ifdef __RL78_32BIT_DOUBLES__
+#define LIBGCC2_HAS_DF_MODE 0
+#define LIBGCC2_LONG_DOUBLE_TYPE_SIZE 32
+#else
+#define LIBGCC2_HAS_DF_MODE 1
#define LIBGCC2_LONG_DOUBLE_TYPE_SIZE 64
+#endif
#define DEFAULT_SIGNED_CHAR0
Index: gcc/config/rl78/rl78.opt
===
--- gcc/config/rl78/rl78.opt(revision 210319)
+++ gcc/config/rl78/rl78.opt(working copy)
@@ -30,6 +30,14 @@
Target RejectNegative Joined Var(rl78_mul_type) Report Tolower
Enum(rl78_mul_types) Init(MUL_NONE)
Select hardware or software multiplication support.
+m64bit-doubles
+Target RejectNegative Mask(64BIT_DOUBLES) Report
+Store doubles in 64 bits.
+
+m32bit-doubles
+Target
Re: [PATCH] Add a couple of dialect and warning options regarding Objective-C instance variable scope
Ping!
On 05/05/2014 10:35 AM, Dimitris Papavasiliou wrote:
Ping!
On 04/28/2014 01:35 PM, Dimitris Papavasiliou wrote:
On 04/25/2014 07:50 PM, Mike Stump wrote:
On Apr 25, 2014, at 9:34 AM, Dimitris Papavasilioudpapa...@gmail.com
wrote:
--Wreturn-type -Wsequence-point -Wshadow @gol
+-Wreturn-type -Wsequence-point -Wshadow -Wshadow-ivar @gol
This has to be -Wno-shadow-ivar, we document the non-default…
+@item -Wshadow-ivar @r{(Objective-C only)}
Likewise.
+ /* Check wheter the local variable hides the instance variable. */
spelling, whether...
Fixed these.
+ a = private; /* { dg-warning hides instance variable { xfail
*-*-* } } */
+ a = protected; /* { dg-warning hides instance variable { xfail
*-*-* } } */
+ a = public; /* { dg-warning hides instance variable { xfail
*-*-* } } */
No, we don’t expect failures. We makes the compiler do what we wants
or it gets the hose again. Then, we expect it to be perfect. If you
won’t want warning, and non are produces, then just remove the /* …
*/, or write /* no warning */.
I've fixed these as per your request. For the record though, this form
of test seems to be fairly common in the test suites as this output
indicates:
dimitris@debian:~/sandbox/gcc-build$ find ../gcc-source/gcc/testsuite/
-name *.c -o -name *.C -o -name *.m | xargs grep xfail \*-\*-\*
| wc -l
354
Many of these seem to be in error or warning messages which are expected
not to show up. In any case if the messages do show up they'll trigger
the excessive messages test so I suppose that's enough.
Also, synth up the ChnageLogs… :-), they are trivial enough.
Done.
And, just pop them all into one patch (cd ..; svn diff), 3 is 3x the
work for me.
Attached.
Once we resolve the 3 warning tests above, this will be ok.
Actually, there were a few more { xfail *-*-* } in the other test cases.
I've removed these as well.
Dimitris
Re: [PATCH, libgfortran] Use -std=gnu11
Janne Blomqvist wrote: the attached patch switches libgfortran C sources to be compiled in gnu11 mode instead of gnu99. Since libgfortran is compiled by the stage 3 compiler, there shouldn't be any bootstrapping issues wrt. older (stage 1) compilers. Ok for trunk? OK. I do not see a real benefit, but it doesn't harm either - and we may indeed use some of the new features in the future. Tobias
Re: [PATCH, libgfortran] PR 61035 Stack overflow in GETCWD
Janne Blomqvist wrote: the attached patch avoids a stack overflow crash due to not trying to create a null-terminated duplicate of the argument char array on the stack. Also, for the common case it avoids an extra allocation and an extra memcpy. Regtested on x86_64-unknown-linux-gnu, Ok for trunk? Looks good to me. Thanks for the patch! Tobias 2014-05-03 Janne Blomqvist j...@gcc.gnu.org PR libfortran/61035 * intrinsics/getcwd.c (getcwd_i4_sub): Avoid potentially large stack allocation, avoid extra copying in the common case.
Re: [Patch, Fortran] Reject OpenMP parallelization for DO CONCURRENT
On Sun, May 11, 2014 at 08:28:12PM +0200, Tobias Burnus wrote: While it would be nice to support !$OMP do for do concurrent loops, the OpenMP spec does not support it, yet. (Syntactically, it is a not a that simple feature as do concurrent can optionally have a MASK=, which has to be evaluated before the loop.) Thus, this patch avoids an ICE by simply rejecting this feature. That's also in line with the other compilers I tried: they either ICE or reject it with an error message. Note: The patch is based on Jakub's OpenMP4 patch (i.e. it uses name instead of the hard-coded !$omp do). Build and regtested on x86-64-gnu-linux. OK for the trunk? (When/if OpenMP4 support is backported, I think this patch should also be included.) Tobias 2014-05-11 Tobias Burnus bur...@net-b.de PR fortran/60127 * openmp.c (resolve_omp_do): Reject do concurrent loops. 2014-05-11 Tobias Burnus bur...@net-b.de PR fortran/60127 * gfortran.dg/gomp/omp_do_concurrent.f90: New. Ok, thanks. Jakub
Re: [patch, Fortran] Fix PR 60834
Thomas Koenig wrote: this contains a straightforward fix for the regression by not trying to do combine array constructors inside association lists. Regression-tested. OK for all affected open branches? OK. Thanks for the patch. (I think only 4.9 and 4.10 are affected - and not 4.8.) Tobias 2014-05-10 Thomas Koenig tkoe...@gcc.gnu.org PR fortran/60834 * frontend-passes.c (in_assoc_list): New variable. (optimize_namespace): Initialize in_assoc_list (combine_array_constructor): Don't try to combine assoc lists. (gfc_code_walker): Keep track of in_assoc_list. 2014-05-10 Thomas Koenig tkoe...@gcc.gnu.org PR fortran/60834 * gfortran.dg/associate_16.f90: New test.
Re: [PING*2][PATCH] Extend mode-switching to support toggle (1/2)
Hello, I'd still wish to ping for the following set of patches. Those changes does not impact other targets than SH4 but, as suggested by Joern, I have hooked the macros and moved the SH4A specific support to the target parts (so a different target can eventually implement other models than dual mode). Patch2 only does very little restructuring but if is not interesting enough for all targets, patch 1 should not be that intrusive. For RTL middle end and (X86, SH, Epiphany) target reviewers, Many thanks, Christian On 04/28/2014 10:08 AM, Christian Bruel wrote: Hello, I'd like to ping the following patches [Hookize mode-switching] http://gcc.gnu.org/ml/gcc-patches/2014-04/msg01003.html [Add new hooks to support toggle and SH4A fpchg instruction] http://gcc.gnu.org/ml/gcc-patches/2014-04/msg01005.html Many thanks
Re: [PING*2][PATCH] Extend mode-switching to support toggle (1/2)
Just saw the Jeff's approval for the RTL part. Sorry for the crossed answers remains the target maintainers. Joern, Kaz ? Many thanks. Christian On 05/12/2014 10:44 AM, Christian Bruel wrote: Hello, I'd still wish to ping for the following set of patches. Those changes does not impact other targets than SH4 but, as suggested by Joern, I have hooked the macros and moved the SH4A specific support to the target parts (so a different target can eventually implement other models than dual mode). Patch2 only does very little restructuring but if is not interesting enough for all targets, patch 1 should not be that intrusive. For RTL middle end and (X86, SH, Epiphany) target reviewers, Many thanks, Christian On 04/28/2014 10:08 AM, Christian Bruel wrote: Hello, I'd like to ping the following patches [Hookize mode-switching] http://gcc.gnu.org/ml/gcc-patches/2014-04/msg01003.html [Add new hooks to support toggle and SH4A fpchg instruction] http://gcc.gnu.org/ml/gcc-patches/2014-04/msg01005.html Many thanks
Re: [PATCH, Pointer Bounds Checker 1/x] Pointer bounds type and mode
2014-05-08 23:28 GMT+04:00 Jeff Law l...@redhat.com: On 05/08/14 02:17, Ilya Enkovich wrote: Right. Richi explicitly wanted the entire set approved before staging in any of the bits. I thought it would be useful to have approved codes in the trunk to reveal some possible problems on earlier stages. It also requires significant effort to keep everything in consistency with the trunk (especially when big refactoring happens) and having some parts committed would be helpful. Will keep it in a branch for now but let me know if you change your mind :) I understand -- my preference would to be go go ahead with the stuff that's already been approved, mostly for the reasons noted above. But with Richi wanting to see it go in as a whole after complete review I think it's best to wait. While we could argue back and forth with Richi, it's not a good use of time. It's in the queue of things to look at, but it's a deep queue at the moment. Thanks for keeping an eye on it! Hope this year we can start sooner and have enough time to make it with no hurry. Agreed. BTW, are you or any colleagues coming to the Cauldron this year in Cambridge? It's often helpful to get together and hash through issues in person. I think most of the core GCC developers will be there. I'm coming and have presentation about MPX (technology itself and how it is used for bounds checker). Don't know how much attention I should give to implementation details. Wold it be useful there? Ilya jeff
Re: [PATCH, Pointer Bounds Checker 1/x] Pointer bounds type and mode
2014-05-09 17:42 GMT+04:00 Jeff Law l...@redhat.com: On 05/09/14 04:36, Richard Biener wrote: On Thu, May 8, 2014 at 9:45 PM, H.J. Lu hjl.to...@gmail.com wrote: On Thu, May 8, 2014 at 12:28 PM, Jeff Law l...@redhat.com wrote: On 05/08/14 02:17, Ilya Enkovich wrote: Right. Richi explicitly wanted the entire set approved before staging in any of the bits. I thought it would be useful to have approved codes in the trunk to reveal some possible problems on earlier stages. It also requires significant effort to keep everything in consistency with the trunk (especially when big refactoring happens) and having some parts committed would be helpful. Will keep it in a branch for now but let me know if you change your mind :) I understand -- my preference would to be go go ahead with the stuff that's already been approved, mostly for the reasons noted above. But with Richi wanting to see it go in as a whole after complete review I think it's best to wait. While we could argue back and forth with Richi, it's not a good use of time. Shouldn't there a git or svn branch for MPX, including run-time library, so that people can take a look at the complete MPX change and try MPX today as NOP? The only extra requirement is MPX enabled binutils. That would indeed be useful. Agreed. The ability to checkout the branch, build it and poke at how it handled certain things would be incredibly helpful. We have such branch and instructions on how to use it on Wiki. It has not been updated for a while though. I'll sync the branch with my working tree. Ilya Jeff
[PING] [PATCH, ARM] Enable shrink-wrap for apcs frame
Ping? OK for trunk?
Thanks!
-Zhenqiang
On 25 March 2014 16:13, Zhenqiang Chen zhenqiang.c...@linaro.org wrote:
Hi
The patch enables shrink-wrap for apcs frame.
Bootstrap and no make check regression in ARM, THUMB1 and THUMB2 modes.
No make check regression with -g/-mapcs/-marm.
Build linux-3.14-rc7 without error.
Is it OK for next stage1?
Thanks!
-Zhenqiang
ChangeLog:
2014-03-25 Zhenqiang Chen zhenqiang.c...@linaro.org
* config/arm/arm.c (arm_option_override): Enable shrink-wrap for
TARGET_APCS_FRAME.
(arm_emit_multi_reg_pop): Set correct dwarf info.
(arm_expand_epilogue_apcs_frame): Add more dwarf info.
testsuite/ChangeLog:
2014-03-25 Zhenqiang Chen zhenqiang.c...@linaro.org
* gcc.target/arm/shrink-wrap-alloca.c: New test case.
* gcc.target/arm/shrink-wrap-sibcall.c: New test case.
diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index 0240cc7..fa86942 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -2811,9 +2811,6 @@ arm_option_override (void)
generate additional returns. */
if (optimize_function_for_size_p (cfun) TARGET_THUMB2)
flag_shrink_wrap = false;
- /* TBD: Dwarf info for apcs frame is not handled yet. */
- if (TARGET_APCS_FRAME)
-flag_shrink_wrap = false;
/* We only support -mslow-flash-data on armv7-m targets. */
if (target_slow_flash_data
@@ -19840,7 +19837,14 @@ arm_emit_multi_reg_pop (unsigned long
saved_regs_mask)
par = emit_insn (par);
REG_NOTES (par) = dwarf;
- if (!return_in_pc)
+
+ if (!emit_update)
+{
+ /* SP is restored from stack. So reset the frame info. */
+ RTX_FRAME_RELATED_P (par) = 1;
+ add_reg_note (par, REG_CFA_DEF_CFA, stack_pointer_rtx);
+}
+ else if (!return_in_pc)
arm_add_cfa_adjust_cfa_note (par, UNITS_PER_WORD * num_regs,
stack_pointer_rtx, stack_pointer_rtx);
}
@@ -27226,6 +27230,9 @@ arm_expand_epilogue_apcs_frame (bool really_return)
REG_NOTES (insn) = alloc_reg_note (REG_CFA_RESTORE,
gen_rtx_REG (SImode, IP_REGNUM),
NULL_RTX);
+ arm_add_cfa_adjust_cfa_note (insn, UNITS_PER_WORD,
+ stack_pointer_rtx,
+ stack_pointer_rtx);
}
if (!really_return || (saved_regs_mask (1 PC_REGNUM)))
diff --git a/gcc/testsuite/gcc.target/arm/shrink-wrap-alloca.c
b/gcc/testsuite/gcc.target/arm/shrink-wrap-alloca.c
new file mode 100644
index 000..318240b
--- /dev/null
+++ b/gcc/testsuite/gcc.target/arm/shrink-wrap-alloca.c
@@ -0,0 +1,11 @@
+/* { dg-do compile } */
+/* { dg-options -O2 -g -mapcs } */
+
+int *p;
+
+void
+test (int a)
+{
+ if (a 0)
+p = __builtin_alloca (4);
+}
diff --git a/gcc/testsuite/gcc.target/arm/shrink-wrap-sibcall.c
b/gcc/testsuite/gcc.target/arm/shrink-wrap-sibcall.c
new file mode 100644
index 000..2efe5d0
--- /dev/null
+++ b/gcc/testsuite/gcc.target/arm/shrink-wrap-sibcall.c
@@ -0,0 +1,26 @@
+/* { dg-do compile } */
+/* { dg-options -O2 -g -mapcs } */
+
+unsigned char a, b, d, f, g;
+
+int test (void);
+
+int
+baz (int c)
+{
+ if (c == 0) return test ();
+ if (b 1)
+{
+ g = 0;
+ int e = (a 0x0f) - (g 0x0f);
+
+ if (!a) b |= 0x80;
+ a = e + test ();
+ f = g/5 + a*3879 + b *2985;
+}
+ else
+ {
+ f = g + a*39879 + b *25;
+ }
+ return test ();
+}
Ping3: [PATCH] PR debug/16063. Add DW_AT_type to DW_TAG_enumeration.
On Mon, 2014-04-28 at 13:17 +0200, Mark Wielaard wrote:
On Tue, 2014-04-22 at 12:31 +0200, Mark Wielaard wrote:
On Mon, 2014-04-14 at 23:19 +0200, Mark Wielaard wrote:
On Fri, 2014-04-11 at 11:03 -0700, Cary Coutant wrote:
The DWARF bits are fine with me.
Thanks. Who can approve the other bits?
You should probably get C and C++ front end approval. I'm not really
sure who needs to review patches in c-family/. Since the part in c/ is
so tiny, maybe all you need is a C++ front end maintainer. Both
Richard Henderson and Jason Merrill are global reviewers, so either of
them could approve the whole thing.
Thanks, I added them to the CC.
When approved should I wait till stage 1 opens before committing?
Yes. The PR you're fixing is an enhancement request, not a regression,
so it needs to wait.
Since stage one just opened up again this seems a good time to re-ask
for approval then :) Rebased patch against current trunk attached.
Ping. Tom already pushed his patches to GDB that take advantage of the
new information if available.
Ping2. Please let me know if I should ping/cc other people to get this
reviewed.
Ping3. Rebased patch to current master attached. DWARF parts approved by
Cary, GDB already contains Tom's code to take advantage of the new
information. Please let me know if I need to take any other steps to get
this in an acceptable state and approved.
Thanks,
Mark
commit 58f1af6ee92a42d796cfd62f6158e2eb9f5969cb
Author: Mark Wielaard m...@redhat.com
Date: Sun Mar 23 12:05:16 2014 +0100
PR debug/16063. Add DW_AT_type to DW_TAG_enumeration.
Add a new lang-hook that provides the underlying base type of an
ENUMERAL_TYPE. Including implementations for C and C++. Use this
enum_underlying_base_type lang-hook in dwarf2out.c to add a DW_AT_type
base type reference to a DW_TAG_enumeration.
gcc/
* dwarf2out.c (gen_enumeration_type_die): Add DW_AT_type if
enum_underlying_base_type defined and DWARF version 3.
* langhooks.h (struct lang_hooks_for_types): Add
enum_underlying_base_type.
* langhooks-def.h (LANG_HOOKS_ENUM_UNDERLYING_BASE_TYPE): New define.
(LANG_HOOKS_FOR_TYPES_INITIALIZER): Add new lang hook.
gcc/c-family/
* c-common.c (c_enum_underlying_base_type): New function.
* c-common.h (c_enum_underlying_base_type): Add declaration.
gcc/c/
* c-objc-common.h (LANG_HOOKS_ENUM_UNDERLYING_BASE_TYPE): Define.
gcc/cp/
* cp-lang.c (cxx_enum_underlying_base_type): New function.
(LANG_HOOKS_ENUM_UNDERLYING_BASE_TYPE): Define.
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index f3cb5f7..567d268 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,13 @@
+2014-03-21 Mark Wielaard m...@redhat.com
+
+ PR debug/16063
+ * dwarf2out.c (gen_enumeration_type_die): Add DW_AT_type if
+ enum_underlying_base_type defined and DWARF version 3.
+ * langhooks.h (struct lang_hooks_for_types): Add
+ enum_underlying_base_type.
+ * langhooks-def.h (LANG_HOOKS_ENUM_UNDERLYING_BASE_TYPE): New define.
+ (LANG_HOOKS_FOR_TYPES_INITIALIZER): Add new lang hook.
+
2014-05-11 Jakub Jelinek ja...@redhat.com
* tree.h (OMP_CLAUSE_LINEAR_STMT): Define.
diff --git a/gcc/c-family/ChangeLog b/gcc/c-family/ChangeLog
index 3a978fa..c5ed7a2 100644
--- a/gcc/c-family/ChangeLog
+++ b/gcc/c-family/ChangeLog
@@ -1,3 +1,9 @@
+2014-03-21 Mark Wielaard m...@redhat.com
+
+ PR debug/16063
+ * c-common.c (c_enum_underlying_base_type): New function.
+ * c-common.h (c_enum_underlying_base_type): Add declaration.
+
2014-05-09 Marek Polacek pola...@redhat.com
PR c/50459
diff --git a/gcc/c-family/c-common.c b/gcc/c-family/c-common.c
index a120b5c..fdc02b4 100644
--- a/gcc/c-family/c-common.c
+++ b/gcc/c-family/c-common.c
@@ -3921,6 +3921,14 @@ c_register_builtin_type (tree type, const char* name)
registered_builtin_types = tree_cons (0, type, registered_builtin_types);
}
+
+/* The C version of the enum_underlying_base_type langhook. */
+tree
+c_enum_underlying_base_type (const_tree type)
+{
+ return c_common_type_for_size (TYPE_PRECISION (type), TYPE_UNSIGNED (type));
+}
+
/* Print an error message for invalid operands to arith operation
CODE with TYPE0 for operand 0, and TYPE1 for operand 1.
diff --git a/gcc/c-family/c-common.h b/gcc/c-family/c-common.h
index d34d2bb..d3d3004 100644
--- a/gcc/c-family/c-common.h
+++ b/gcc/c-family/c-common.h
@@ -833,6 +833,7 @@ extern void c_common_finish (void);
extern void c_common_parse_file (void);
extern alias_set_type c_common_get_alias_set (tree);
extern void c_register_builtin_type (tree, const char*);
+extern tree c_enum_underlying_base_type (const_tree);
extern bool c_promoting_integer_type_p (const_tree);
extern int self_promoting_args_p (const_tree);
extern tree strip_pointer_operator (tree);
diff --git a/gcc/c/ChangeLog b/gcc/c/ChangeLog
index 919b4ff..d2fb777 100644
---
[Patch, avr] Fix PR60991
This trivial patch fixes PR60991 by correcting the constant used to
restore Y in one of the assembler template variants used in avr_out_store_psi.
I've also added a testcase (modified from the original poster's code).
If ok, could someone commit please? I don't have commit access. It would
be great if this was also committed to 4.9 and 4.8 branches as well.
Regards
Senthil
gcc/ChangeLog
2014-05-12 Senthil Kumar Selvaraj senthil_kumar.selva...@atmel.com
PR target/60991
* config/avr/avr.c (avr_out_store_psi): Use correct constant
to restore Y.
gcc/testsuite/ChangeLog
2014-05-12 Senthil Kumar Selvaraj senthil_kumar.selva...@atmel.com
PR target/60991
* gcc.target/avr/pr60991.c: New testcase.
diff --git gcc/config/avr/avr.c gcc/config/avr/avr.c
index 536fe68..fc6c9f6 100644
--- gcc/config/avr/avr.c
+++ gcc/config/avr/avr.c
@@ -3999,7 +3999,7 @@ avr_out_store_psi (rtx insn, rtx *op, int *plen)
std Y+61,%A1CR_TAB
std Y+62,%B1CR_TAB
std Y+63,%C1CR_TAB
-sbiw r28,%o0-60, op, plen, -5);
+sbiw r28,%o0-61, op, plen, -5);
return avr_asm_len (subi r28,lo8(-%o0) CR_TAB
sbci r29,hi8(-%o0) CR_TAB
diff --git gcc/testsuite/gcc.target/avr/pr60991.c
gcc/testsuite/gcc.target/avr/pr60991.c
new file mode 100644
index 000..a09f42a
--- /dev/null
+++ gcc/testsuite/gcc.target/avr/pr60991.c
@@ -0,0 +1,21 @@
+/* { dg-do run } */
+/* { dg-options -O1 } */
+
+/* This testcase (simplified from the original bug report) exposes
+ PR60991. The code generated for writing the __int24 value corrupts
+ the frame pointer if the offset is = 63 + MAX_LD_OFFSET */
+
+#include stdlib.h
+
+int main(void)
+{
+volatile char junk[62];
+junk[0] = 5;
+volatile __int24 staticConfig = 0;
+
+if (junk[0] != 5)
+ abort();
+
+exit(0);
+return 0;
+}
Re: [PATCH 1/7] Fix GTY markup of u2
Hi, On Sat, 10 May 2014, Mike Stump wrote: The rtx u2 field currently uses a desc/tag pair for GTY. This seems unnecessary though, OK to install? Ick. I don’t favor skip. The change feels like a premature optimization that doesn’t net any code gen benefit. I’ll defer to a gty person if they prefer skip. The skip is necessary, otherwise union members of GTY structs are required to have a 'desc' (and their members in turn are required to have a 'tag'). So it's either the skip or the desc/tag pair. The code-gen difference is one empty (but two-cased) switch statement less. Ciao, Michael.
Re: [Patch, avr] Propagate -mrelax gcc driver flag to assembler
Ping!
Regards
Senthil
On Fri, Apr 18, 2014 at 03:22:46PM +0530, Senthil Kumar Selvaraj wrote:
On Sat, Apr 12, 2014 at 06:36:01PM +0200, Georg-Johann Lay wrote:
Senthil Kumar Selvaraj schrieb:
This patch modifies AVR target's ASM spec to pass -mlink-relax to the
assembler if -mrelax is passed to the compiler driver. This was already
being passed on to the linker, this patch merely makes the assembler
also aware of it.
The corresponding patch in binutils to handle the -mlink-relax patch is
already committed in the binutils repo. I'm not sure how to manage a
running a newer gcc with an older version of binutils though - how is this
generally handled?
The right place is gcc/configure.ac and have a macro defined depending on
whether gas supports -mlink-relax.
Same should be done for -mrmw, IMO, for similar reasons, e.g. something like
case $target in
...
avr-*-*)
...
gcc_GAS_CHECK_FEATURE([-mrmw option], gcc_cv_as_avr_mrmw,,
[-mrmw], [.text],,
[AC_DEFINE(HAVE_AS_AVR_MRMW_OPTION, 1,
[Define if your assembler supports -mrmw option.])])
or
gcc_GAS_CHECK_FEATURE([-mrmw option], gcc_cv_as_avr_mrmw,,
[-mrmw], [.text],,,)
if test x$gcc_cv_as_avr_mrmw = xyes; then
AC_DEFINE(HAVE_AS_AVR_MRMW_OPTION, 1,
[Define if your assembler supports the -mrmw option.])
Thanks Johann. The below patch adds the configury check for -mlink-relax,
along with the change to ASM_SPEC to propagate the -mrelax flag. I
modified the original patch a bit to make it easier to handle
conditional additions to SPECs (inspired by the sparc target).
However, the gcc-4_9-branch has already been created...
Yes, but I figured it would be useful anyway - if this eventually gets
backported to 4_9, for example.
If the below patch looks ok, could someone commit please? I don't have
commit access.
Regards
Senthil
gcc/ChangeLog
2014-04-18 Senthil Kumar Selvaraj senthil_kumar.selva...@atmel.com
* config/avr/avr.h: Pass on mlink-relax to assembler.
* configure.ac: Test for mlink-relax support in assembler.
* configure: Regenerate.
diff --git gcc/config/avr/avr.h gcc/config/avr/avr.h
index 78434ec..b4e3eb1 100644
--- gcc/config/avr/avr.h
+++ gcc/config/avr/avr.h
@@ -512,7 +512,28 @@ extern const char *avr_device_to_sp8 (int argc, const
char **argv);
%{!fenforce-eh-specs:-fno-enforce-eh-specs} \
%{!fexceptions:-fno-exceptions}
-#define ASM_SPEC %:device_to_as(%{mmcu=*:%*})
+#ifdef HAVE_AS_RELAX_OPTION
+#define ASM_RELAX_SPEC %{mrelax:-mlink-relax}
+#else
+#define ASM_RELAX_SPEC
+#endif
+
+#define ASM_SPEC %:device_to_as(%{mmcu=*:%*})\
+%(asm_relax)
+
+/* This macro defines names of additional specifications to put in the specs
+ that can be used in various specifications like CC1_SPEC. Its definition
+ is an initializer with a subgrouping for each command option.
+
+ Each subgrouping contains a string constant, that defines the
+ specification name, and a string constant that used by the GCC driver
+ program.
+
+ Do not define this macro if it does not need to do anything. */
+
+#define EXTRA_SPECS \
+ { asm_relax, ASM_RELAX_SPEC }
+
#define LINK_SPEC \
%{mrelax:--relax\
diff --git gcc/configure gcc/configure
index bfb1525..7815038 100755
--- gcc/configure
+++ gcc/configure
@@ -24142,6 +24142,39 @@ $as_echo #define HAVE_AS_JSRDIRECT_RELOCS 1
confdefs.h
fi
;;
+ avr-*-*)
+{ $as_echo $as_me:${as_lineno-$LINENO}: checking assembler for
-mlink-relax option 5
+$as_echo_n checking assembler for -mlink-relax option... 6; }
+if test ${gcc_cv_as_avr_relax+set} = set; then :
+ $as_echo_n (cached) 6
+else
+ gcc_cv_as_avr_relax=no
+ if test x$gcc_cv_as != x; then
+$as_echo '.text' conftest.s
+if { ac_try='$gcc_cv_as $gcc_cv_as_flags -mlink-relax -o conftest.o
conftest.s 5'
+ { { eval echo \\$as_me\:${as_lineno-$LINENO}: \$ac_try\; } 5
+ (eval $ac_try) 25
+ ac_status=$?
+ $as_echo $as_me:${as_lineno-$LINENO}: \$? = $ac_status 5
+ test $ac_status = 0; }; }
+then
+ gcc_cv_as_avr_relax=yes
+else
+ echo configure: failed program was 5
+ cat conftest.s 5
+fi
+rm -f conftest.o conftest.s
+ fi
+fi
+{ $as_echo $as_me:${as_lineno-$LINENO}: result: $gcc_cv_as_avr_relax 5
+$as_echo $gcc_cv_as_avr_relax 6; }
+if test $gcc_cv_as_avr_relax = yes; then
+
+$as_echo #define HAVE_AS_RELAX_OPTION 1 confdefs.h
+
+fi
+ ;;
+
cris-*-*)
{ $as_echo $as_me:${as_lineno-$LINENO}: checking assembler for
-no-mul-bug-abort option 5
$as_echo_n checking assembler for -no-mul-bug-abort option... 6; }
diff --git gcc/configure.ac gcc/configure.ac
index d7cae6c..cfa862d 100644
--- gcc/configure.ac
+++ gcc/configure.ac
@@ -3579,6 +3579,13 @@ case $target in
[Define if your assembler
Re: [patch,arm] Add GCC runtime library exceptions to files that go into libgcc
Am 05/10/2014 02:51 AM, schrieb Ian Lance Taylor: Georg-Johann Lay a...@jlay.de writes: This patch adds GCC Runtime Library Exception to files that go into libgcc because libgcc2.c includes tm.h and libgcc_tm.h. Most of these files contain much code, some used by libgcc, some not. Some potential users of (lib)gcc have objections that missing RLE might infect their target code. Even though I know that this is actually not the case and the FSF is fine with target code linked against libgcc, it's pointless to argue in that direction. At least this is my personal experience with advocates. I am aware that there was effort for better separation of libgcc and GCC, but obviously this separation has not yet been achieved. This this ok for trunk? And is there anything special about license changes w.r.t FSF that I have to take into account? CCed Ian so that someone from the GCC steering committee can have a look. I think this is unnecessary but fine. Thanks. Yes, I know it's not needed... yet it can increase acceptance of GCC. I opened a PR61152 for this so that it's clearer for why the Runtime Exceptions will be added: http://gcc.gnu.org/PR61152 Added two files included by arm.h I missed; is it in order to apply this, too? And is it in order to apply/backport this to the 4.9 branch? From source perspective the changes are trivial enough. Johann PR libgcc/61152 * config/arm/arm-opts.h (License): Add GCC Runtime Library Exception. * config/arm/arm-cores.def (License): Same. Index: gcc/config/arm/arm-cores.def === --- gcc/config/arm/arm-cores.def(revision 210321) +++ gcc/config/arm/arm-cores.def(working copy) @@ -14,6 +14,10 @@ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. + Under Section 7 of GPL version 3, you are granted additional + permissions described in the GCC Runtime Library Exception, version + 3.1, as published by the Free Software Foundation. + 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/. */ Index: gcc/config/arm/arm-opts.h === --- gcc/config/arm/arm-opts.h (revision 210321) +++ gcc/config/arm/arm-opts.h (working copy) @@ -13,6 +13,10 @@ or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. + Under Section 7 of GPL version 3, you are granted additional + permissions described in the GCC Runtime Library Exception, version + 3.1, as published by the Free Software Foundation. + 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/. */
Re: [PATCH 7/7] Move SYMBOL_REF_FLAGS to rtx header
Hi, On Sat, 10 May 2014, Richard Sandiford wrote: @@ -362,6 +362,9 @@ struct GTY((chain_next (RTX_NEXT (%h) /* The INSN_UID of an RTX_INSN-class code. */ int insn_uid; +/* The SYMBOL_REF_FLAGS of a SYMBOL_REF. */ +unsigned int symbol_ref_flags; + In [3/7] you used +/* The ORIGINAL_REGNO of a REG. */ +unsigned original_regno; + Should be consistent. Also I'm idly wondering if the explicit sizing of the fields via a bit-field as originally would be better here or just confusing. I guess unsigned and enums are 32bit for all hosts we care about, but if we ever have one where it's larger the rtx will suddenly contain another hole. Ciao, Michael.
Re: [PING*2][PATCH] Extend mode-switching to support toggle (1/2)
[I'd like to add Oleg to CC list.] Christian Bruel christian.br...@st.com wrote: Just saw the Jeff's approval for the RTL part. Sorry for the crossed answers remains the target maintainers. Joern, Kaz ? SH specific part looks OK to me. Oleg, could you comment on the patch? Regards, kaz
[C++ Patch] Couple of minor fixes
Hi,
almost obvious, I would say. Tested x86_64-linux.
Thanks,
Paolo.
2014-05-12 Paolo Carlini paolo.carl...@oracle.com
* cvt.c (cp_convert_to_pointer): Don't call error_at if
complain tf_error is false.
* decl.c (make_unbound_class_template): Prefer inform for
declared here-type message.
Index: cvt.c
===
--- cvt.c (revision 210320)
+++ cvt.c (working copy)
@@ -198,8 +198,9 @@ cp_convert_to_pointer (tree type, tree expr, tsubs
complain);
}
}
- error_at (loc, cannot convert %qE from type %qT to type %qT,
- expr, intype, type);
+ if (complain tf_error)
+ error_at (loc, cannot convert %qE from type %qT to type %qT,
+ expr, intype, type);
return error_mark_node;
}
Index: decl.c
===
--- decl.c (revision 210320)
+++ decl.c (working copy)
@@ -3491,7 +3491,8 @@ make_unbound_class_template (tree context, tree na
if (complain tf_error)
{
error (template parameters do not match template);
- error (%q+D declared here, tmpl);
+ inform (DECL_SOURCE_LOCATION (tmpl),
+ %qD declared here, tmpl);
}
return error_mark_node;
}
Re: [PATCH 1/7] Fix GTY markup of u2
Michael Matz m...@suse.de writes: Hi, On Sat, 10 May 2014, Mike Stump wrote: The rtx u2 field currently uses a desc/tag pair for GTY. This seems unnecessary though, OK to install? Ick. I don’t favor skip. The change feels like a premature optimization that doesn’t net any code gen benefit. I’ll defer to a gty person if they prefer skip. The skip is necessary, otherwise union members of GTY structs are required to have a 'desc' (and their members in turn are required to have a 'tag'). So it's either the skip or the desc/tag pair. The code-gen difference is one empty (but two-cased) switch statement less. Yeah, but the reason I'm removing the desc/tag pair isn't so much to get rid of that (the compiler should do it for us) but because marking it anything other than skip gives the impression that we want to allow GC pointers in the union. Richard
Re: [PATCH 7/7] Move SYMBOL_REF_FLAGS to rtx header
Michael Matz m...@suse.de writes: Hi, On Sat, 10 May 2014, Richard Sandiford wrote: @@ -362,6 +362,9 @@ struct GTY((chain_next (RTX_NEXT (%h) /* The INSN_UID of an RTX_INSN-class code. */ int insn_uid; +/* The SYMBOL_REF_FLAGS of a SYMBOL_REF. */ +unsigned int symbol_ref_flags; + In [3/7] you used +/* The ORIGINAL_REGNO of a REG. */ +unsigned original_regno; + Should be consistent. Oops, indeed. Will fix them all to use unsigned int if approved. Also I'm idly wondering if the explicit sizing of the fields via a bit-field as originally would be better here or just confusing. I guess unsigned and enums are 32bit for all hosts we care about, but if we ever have one where it's larger the rtx will suddenly contain another hole. But that'll happen anyway, which is why I thought having bitfields was confusing. Since this is a union, you'll always get the full unsigned int regardless of the bitfield size; the bitfield can't be packed with anything else. Thanks, Richard
Re: [PATCH 7/7] Move SYMBOL_REF_FLAGS to rtx header
Hi, On Mon, 12 May 2014, Richard Sandiford wrote: Also I'm idly wondering if the explicit sizing of the fields via a bit-field as originally would be better here or just confusing. I guess unsigned and enums are 32bit for all hosts we care about, but if we ever have one where it's larger the rtx will suddenly contain another hole. But that'll happen anyway, which is why I thought having bitfields was confusing. Since this is a union, you'll always get the full unsigned int regardless of the bitfield size; the bitfield can't be packed with anything else. Hmm, true. Okay, it'd be premature optimization for hosts which don't exist anyway :) Ciao, Michael.
Re: [PING*2][PATCH] Extend mode-switching to support toggle (1/2)
On 12 May 2014 10:06, Christian Bruel christian.br...@st.com wrote: Just saw the Jeff's approval for the RTL part. Sorry for the crossed answers remains the target maintainers. Joern, Kaz ? Many thanks. Christian On 05/12/2014 10:44 AM, Christian Bruel wrote: Hello, I'd still wish to ping for the following set of patches. Those changes does not impact other targets than SH4 but, as suggested by Joern, I have hooked the macros and moved the SH4A specific support to the target parts (so a different target can eventually implement other models than dual mode). Patch2 only does very little restructuring but if is not interesting enough for all targets, patch 1 should not be that intrusive. For RTL middle end and (X86, SH, Epiphany) target reviewers, Many thanks, Christian On 04/28/2014 10:08 AM, Christian Bruel wrote: Hello, I'd like to ping the following patches [Hookize mode-switching] http://gcc.gnu.org/ml/gcc-patches/2014-04/msg01003.html [Add new hooks to support toggle and SH4A fpchg instruction] http://gcc.gnu.org/ml/gcc-patches/2014-04/msg01005.html Sorry, I only saw the first part and thought I' d need to wait till I see the second part - and I somehow missed that. I think the previous known mode should be passed to the TARGET_MODE_EMIT hook - no need to have extra hooks for toggling, and, as I mentioned earlier, fixating on the toggle is actually an SH artifact - other ports have multi-way modes settings that can benefit from knowing the previous mode.
Re: [Patch, avr] Propagate -mrelax gcc driver flag to assembler
Am 04/18/2014 11:52 AM, schrieb Senthil Kumar Selvaraj:
On Sat, Apr 12, 2014 at 06:36:01PM +0200, Georg-Johann Lay wrote:
Senthil Kumar Selvaraj schrieb:
This patch modifies AVR target's ASM spec to pass -mlink-relax to the
assembler if -mrelax is passed to the compiler driver. This was already
being passed on to the linker, this patch merely makes the assembler
also aware of it.
The corresponding patch in binutils to handle the -mlink-relax patch is
already committed in the binutils repo. I'm not sure how to manage a
running a newer gcc with an older version of binutils though - how is this
generally handled?
The right place is gcc/configure.ac and have a macro defined depending on
whether gas supports -mlink-relax.
Same should be done for -mrmw, IMO, for similar reasons, e.g. something like
case $target in
...
avr-*-*)
...
gcc_GAS_CHECK_FEATURE([-mrmw option], gcc_cv_as_avr_mrmw,,
[-mrmw], [.text],,
[AC_DEFINE(HAVE_AS_AVR_MRMW_OPTION, 1,
[Define if your assembler supports -mrmw option.])])
or
gcc_GAS_CHECK_FEATURE([-mrmw option], gcc_cv_as_avr_mrmw,,
[-mrmw], [.text],,,)
if test x$gcc_cv_as_avr_mrmw = xyes; then
AC_DEFINE(HAVE_AS_AVR_MRMW_OPTION, 1,
[Define if your assembler supports the -mrmw option.])
Thanks Johann. The below patch adds the configury check for -mlink-relax,
along with the change to ASM_SPEC to propagate the -mrelax flag. I
modified the original patch a bit to make it easier to handle
conditional additions to SPECs (inspired by the sparc target).
However, the gcc-4_9-branch has already been created...
Yes, but I figured it would be useful anyway - if this eventually gets
backported to 4_9, for example.
If the below patch looks ok, could someone commit please? I don't have
commit access.
Regards
Senthil
gcc/ChangeLog
2014-04-18 Senthil Kumar Selvaraj senthil_kumar.selva...@atmel.com
* config/avr/avr.h: Pass on mlink-relax to assembler.
* configure.ac: Test for mlink-relax support in assembler.
* configure: Regenerate.
diff --git gcc/config/avr/avr.h gcc/config/avr/avr.h
index 78434ec..b4e3eb1 100644
--- gcc/config/avr/avr.h
+++ gcc/config/avr/avr.h
@@ -512,7 +512,28 @@ extern const char *avr_device_to_sp8 (int argc, const char
**argv);
%{!fenforce-eh-specs:-fno-enforce-eh-specs} \
%{!fexceptions:-fno-exceptions}
-#define ASM_SPEC %:device_to_as(%{mmcu=*:%*})
+#ifdef HAVE_AS_RELAX_OPTION
+#define ASM_RELAX_SPEC %{mrelax:-mlink-relax}
+#else
+#define ASM_RELAX_SPEC
+#endif
+
+#define ASM_SPEC %:device_to_as(%{mmcu=*:%*})\
+%(asm_relax)
+
+/* This macro defines names of additional specifications to put in the specs
+ that can be used in various specifications like CC1_SPEC. Its definition
+ is an initializer with a subgrouping for each command option.
+
+ Each subgrouping contains a string constant, that defines the
+ specification name, and a string constant that used by the GCC driver
+ program.
+
+ Do not define this macro if it does not need to do anything. */
+
+#define EXTRA_SPECS \
+ { asm_relax, ASM_RELAX_SPEC }
+
Hi, wouldn't it be easier to add just a line to driver-avr.c:avr_device_to_as ?
#define LINK_SPEC \
%{mrelax:--relax\
diff --git gcc/configure gcc/configure
index bfb1525..7815038 100755
--- gcc/configure
+++ gcc/configure
@@ -24142,6 +24142,39 @@ $as_echo #define HAVE_AS_JSRDIRECT_RELOCS 1
confdefs.h
fi
;;
+ avr-*-*)
+{ $as_echo $as_me:${as_lineno-$LINENO}: checking assembler for -mlink-relax
option 5
+$as_echo_n checking assembler for -mlink-relax option... 6; }
+if test ${gcc_cv_as_avr_relax+set} = set; then :
+ $as_echo_n (cached) 6
+else
+ gcc_cv_as_avr_relax=no
+ if test x$gcc_cv_as != x; then
+$as_echo '.text' conftest.s
+if { ac_try='$gcc_cv_as $gcc_cv_as_flags -mlink-relax -o conftest.o conftest.s
5'
+ { { eval echo \\$as_me\:${as_lineno-$LINENO}: \$ac_try\; } 5
+ (eval $ac_try) 25
+ ac_status=$?
+ $as_echo $as_me:${as_lineno-$LINENO}: \$? = $ac_status 5
+ test $ac_status = 0; }; }
+then
+ gcc_cv_as_avr_relax=yes
+else
+ echo configure: failed program was 5
+ cat conftest.s 5
+fi
+rm -f conftest.o conftest.s
+ fi
+fi
+{ $as_echo $as_me:${as_lineno-$LINENO}: result: $gcc_cv_as_avr_relax 5
+$as_echo $gcc_cv_as_avr_relax 6; }
+if test $gcc_cv_as_avr_relax = yes; then
+
+$as_echo #define HAVE_AS_RELAX_OPTION 1 confdefs.h
+
+fi
+ ;;
+
cris-*-*)
{ $as_echo $as_me:${as_lineno-$LINENO}: checking assembler for -no-mul-bug-abort
option 5
$as_echo_n checking assembler for -no-mul-bug-abort option... 6; }
diff --git gcc/configure.ac gcc/configure.ac
index d7cae6c..cfa862d 100644
--- gcc/configure.ac
+++ gcc/configure.ac
@@ -3579,6 +3579,13 @@ case $target in
[Define if your assembler supports the lituse_jsrdirect relocation.])])
;;
+ avr-*-*)
+gcc_GAS_CHECK_FEATURE([-mlink-relax
Re: [PING*2][PATCH] Extend mode-switching to support toggle (1/2)
On 04/28/2014 10:08 AM, Christian Bruel wrote: Hello, I'd like to ping the following patches [Hookize mode-switching] http://gcc.gnu.org/ml/gcc-patches/2014-04/msg01003.html [Add new hooks to support toggle and SH4A fpchg instruction] http://gcc.gnu.org/ml/gcc-patches/2014-04/msg01005.html Sorry, I only saw the first part and thought I' d need to wait till I see the second part - and I somehow missed that. I think the previous known mode should be passed to the TARGET_MODE_EMIT hook - no need to have extra hooks for toggling, and, as I mentioned earlier, fixating on the toggle is actually an SH artifact - other ports have multi-way modes settings that can benefit from knowing the previous mode. OK I'll change the bool toggle parameter by the previous mode in TARGET_MODE_EMIT and remove the bool XOR hooks in the SH description. Just for my curiosity, which other targets have multi-way toggling support ? I'll commit the first patch as approved and re post the second one. Many thanks, Christian
Re: [PING*2][PATCH] Extend mode-switching to support toggle (1/2)
On 12 May 2014 13:16, Christian Bruel christian.br...@st.com wrote: Just for my curiosity, which other targets have multi-way toggling support ? The epiphany has, sort of: you read a control register, AND and/or OR some mask(s) to the value, and write it back. If we knew the previous mode, we might elide and AND or an OR. I think this is actually quite a common issue.
Re: [patch] gcc fstack-protector-explicit
On Wed, Mar 19, 2014 at 11:09 AM, Jeff Law l...@redhat.com wrote: On 03/19/14 08:06, Marcos Díaz wrote: Well, finally I have the assignment, could you please review this patch? Thanks. I'll take a look once we open up stage1 development again (should be soon as 4.9 is getting close to being ready). jeff Ping!
Re: [PING*2][PATCH] Extend mode-switching to support toggle (1/2)
On 12 May 2014 13:51, Joern Rennecke joern.renne...@embecosm.com wrote: On 12 May 2014 13:16, Christian Bruel christian.br...@st.com wrote: Just for my curiosity, which other targets have multi-way toggling support ? The epiphany has, sort of: you read a control register, AND and/or OR some mask(s) to the value, and write it back. If we knew the previous mode, we might elide and AND or an OR. I think this is actually quite a common issue. P.S.: In some cases, multiple modes input could still be handled if we knew that certain other modes don't appear in the input, so a more powerful interface than providing the previous mode - if known, is to provide a set of potential predecessor modes. The case where we don't know anything then obviously is represented as the full base set. In the mode switching infrastructure, you can just calculate the union of the incoming (potential) mode(s) from each incoming edge.
[PATCH][x86] Support clflushopt, xsaves, xsavec.
Hi, This patch add support for xsavec, xsaves ISA extensions, introduced in [1], and clflushopt introduced in [2]. [1]http://www.intel.com/content/www/us/en/processors/architectures-software-developer-manuals.html [2]http://software.intel.com/en-us/file/319433-018pdf Bootstraps, passes make-check. Ok for trunk? Changelog: 2014-05-12 Ilya Tocar ilya.to...@intel.com * common/config/i386/i386-common.c (OPTION_MASK_ISA_CLFLUSHOPT_SET): Define. (OPTION_MASK_ISA_XSAVES_SET): Ditto. (OPTION_MASK_ISA_XSAVEC_SET): Ditto. (OPTION_MASK_ISA_CLFLUSHOPT_UNSET): Ditto. (OPTION_MASK_ISA_XSAVES_UNSET): Ditto. (OPTION_MASK_ISA_XSAVEC_UNSET): Ditto. (ix86_handle_option): Handle OPT_mxsavec, OPT_mxsaves, OPT_mclflushopt. * config.gcc (i[34567]86-*-*): Add clflushoptintrin.h, xsavecintrin.h, xsavesintrin.h. (x86_64-*-*): Ditto. * config/i386/clflushoptintrin.h: New. * config/i386/xsavecintrin.h: Ditto. * config/i386/xsavesintrin.h: Ditto. * config/i386/cpuid.h (bit_CLFLUSHOPT): Define. (bit_XSAVES): Ditto. (bit_XSAVES): Ditto. * config/i386/driver-i386.c (host_detect_local_cpu): Handle -mclflushopt, -mxsavec, -mxsaves, -mno-xsaves, -mno-xsavec, -mno-clflushopt. * config/i386/i386-c.c (ix86_target_macros_internal): Handle OPTION_MASK_ISA_CLFLUSHOPT, OPTION_MASK_ISA_XSAVEC, OPTION_MASK_ISA_XSAVES. * config/i386/i386.c (ix86_target_string): Handle -mclflushopt, -mxsavec, -mxsaves. (PTA_CLFLUSHOPT) Define. (PTA_XSAVEC): Ditto. (PTA_XSAVES): Ditto. (ix86_option_override_internal): Handle new options. (ix86_valid_target_attribute_inner_p): Ditto. (ix86_builtins): Add IX86_BUILTIN_XSAVEC, IX86_BUILTIN_XSAVEC64, IX86_BUILTIN_XSAVES, IX86_BUILTIN_XRSTORS, IX86_BUILTIN_XSAVES64, IX86_BUILTIN_XRSTORS64, IX86_BUILTIN_CLFLUSHOPT. (bdesc_special_args): Add __builtin_ia32_xsaves, __builtin_ia32_xrstors, __builtin_ia32_xsavec, __builtin_ia32_xsaves64, __builtin_ia32_xrstors64, __builtin_ia32_xsavec64. (ix86_init_mmx_sse_builtins): Add __builtin_ia32_clflushopt. (ix86_expand_builtin): Handle new builtins. * config/i386/i386.h (TARGET_CLFLUSHOPT) Define. (TARGET_CLFLUSHOPT_P): Ditto. (TARGET_XSAVEC): Ditto. (TARGET_XSAVEC_P): Ditto. (TARGET_XSAVES): Ditto. (TARGET_XSAVES_P): Ditto. * config/i386/i386.md (ANY_XSAVE): Add UNSPECV_XSAVEC, UNSPECV_XSAVES. (ANY_XSAVE64) Add UNSPECV_XSAVEC64, UNSPECV_XSAVES64. (attr xsave): Add xsavec, xsavec64, xsaves, xsaves64. (ANY_XRSTOR): New. (ANY_XRSTOR64): Ditto. (xrstor): Ditto. (xrstor): Change into xrstor. (xrstor_rex64): Change into xrstor_rex64. (xrstor64): Change into xrstor64 (clflushopt): New. * config/i386/i386.opt (mclflushopt): New. (mxsavec): Ditto. (mxsaves): Ditto. * config/i386/x86intrin.h: Add clflushoptintrin.h, xsavesintrin.h, xsavecintrin.h. * doc/invoke.texi: Document new options. And for tests: 2014-05-12 Ilya Tocar ilya.to...@intel.com * gcc.target/i386/clflushopt-1.c: New. * gcc.target/i386/xsavec-1.c: Ditto. * gcc.target/i386/xsavec64-1.c: Ditto. * gcc.target/i386/xsaves-1.c: Ditto. * gcc.target/i386/xsaves64-1.c: Ditto. gcc/common/config/i386/i386-common.c | 47 gcc/config.gcc | 6 +- gcc/config/i386/clflushoptintrin.h | 49 gcc/config/i386/cpuid.h | 3 + gcc/config/i386/driver-i386.c| 12 +++- gcc/config/i386/i386-c.c | 6 ++ gcc/config/i386/i386.c | 83 +++- gcc/config/i386/i386.h | 6 ++ gcc/config/i386/i386.md | 64 + gcc/config/i386/i386.opt | 12 gcc/config/i386/x86intrin.h | 6 ++ gcc/config/i386/xsavecintrin.h | 58 +++ gcc/config/i386/xsavesintrin.h | 72 gcc/doc/invoke.texi | 7 +++ gcc/testsuite/gcc.target/i386/clflushopt-1.c | 11 gcc/testsuite/gcc.target/i386/xsavec-1.c | 11 gcc/testsuite/gcc.target/i386/xsavec64-1.c | 11 gcc/testsuite/gcc.target/i386/xsaves-1.c | 13 + gcc/testsuite/gcc.target/i386/xsaves64-1.c | 13 + 19 files changed, 474 insertions(+), 16 deletions(-) create mode 100644 gcc/config/i386/clflushoptintrin.h create mode 100644 gcc/config/i386/xsavecintrin.h create mode 100644 gcc/config/i386/xsavesintrin.h create mode 100644 gcc/testsuite/gcc.target/i386/clflushopt-1.c create mode 100644
[PING] -fuse-caller-save - Collect register usage information
On 26-04-14 14:51, Tom de Vries wrote: Eric, Honza, This patch adds analysis in pass_final to track which hard registers are set or clobbered by the function body, and stores that information in a struct cgraph_node, to be used in the fuse-caller-save optmization. This is the updated version of the previously approved patch submitted here (http://gcc.gnu.org/ml/gcc-patches/2013-03/msg01320.html ). The changes are: - using a new hook call_fusage_contains_non_callee_clobbers, - incorporating minor review comments from Richard Sandiford ( http://gcc.gnu.org/ml/gcc-patches/2014-04/msg01436.html ). As part of the fuse-caller-save patch series, bootstrapped and reg-tested on x86_64, and build and reg-tested on MIPS. Eric, non-cgraph part OK for trunk? Honza, cgraph part OK for trunk? Ping. If this patch is approved and committed, I can commit the other approved fuse-caller-save patches and enable the optimization for MIPS. Thanks, - Tom
Re: [PATCH][x86] Support clflushopt, xsaves, xsavec.
On Mon, May 12, 2014 at 3:25 PM, Ilya Tocar tocarip.in...@gmail.com wrote:
This patch add support for xsavec, xsaves ISA extensions, introduced in
[1], and clflushopt introduced in [2].
[1]http://www.intel.com/content/www/us/en/processors/architectures-software-developer-manuals.html
[2]http://software.intel.com/en-us/file/319433-018pdf
Bootstraps, passes make-check.
Please also add new options to g++.dg/other/i386-{2,3}.C and
gcc.target/i386/sse-{14,15,22,23}.c.
Uros.
Re: [C++ Patch] Couple of minor fixes
Yes, those seem obvious. Jason
Re: [PATCH 1/7] Fix GTY markup of u2
On May 12, 2014, at 3:53 AM, Richard Sandiford rdsandif...@googlemail.com wrote: Yeah, but the reason I'm removing the desc/tag pair isn't so much to get rid of that (the compiler should do it for us) but because marking it anything other than skip gives the impression that we want to allow GC pointers in the union. Yeah, though I might like the generality of being able to do that, I will confess, I don’t think we will ever add a GC pointer, or indeed change the data much in the next 15 years.
Re: [C PATCH] Make attributes accept enum values (PR c/50459)
Marek Polacek pola...@redhat.com writes: On Sun, May 11, 2014 at 09:18:47PM +0200, Rainer Orth wrote: No, that's wrong: avoid hardcoding target lists if at all possible. Besides, it's wrong since it doesn't cover the Solaris (and other non-gld linker) case. Use the init_priority effective-target keyword instead. Also, please check if you can use dg-xfail-if instead: if anything changes, the test turns into an XPASS instead of the change going unnoticed with dg-skip-if. I don't see tests using dg-skip-if and init_priority, so this patch No need for examples: as you can see in doc/sourcebuild.texi, both dg-do and dg-skip-if accept the same selectors. does what we do for other tests using cdtor priorities. 2014-05-11 Marek Polacek pola...@redhat.com * c-c++-common/pr50459.c: Require init_priority target. Ok. Thanks. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [PATCH, PR58066] preferred_stack_boundary update for tls expanded call
Hi Wei,
please teach your mailer not to break/mangle long lines. Thanks.
Here is a patch for the test. It contains two changes:
1. For emutls, there will be an explicit call generated at expand
pass, and no stack adjustment is needed. So add /* {
dg-require-effective-target tls_native } */ in the test.
2. Replace cfi_def_cfa_offset with insn sequence check.
Is it ok?
No, the test FAILs for 32-bit i386-pc-solaris2.11 with Sun as/ld:
FAIL: gcc.target/i386/pr58066.c scan-assembler
sub[^\r\n]*8[^\r\n]*sp.*call[^\r\n]*__tls_get_addr.*sub[^\r\n]*8[^\r\n]*sp.*call[^\r\n]*__tls_get_addr
The TLS code sequence is different here:
subl$8, %esp
lealccc1@tlsgd(,%ebx,1), %eax
callccc1@tlsgdplt
I fear this insn scanning is going to be extremely fragile.
Rainer
--
-
Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [PATCH, PR52252] Vectorization for load/store groups of size 3.
Evgeny Stupachenko evstu...@gmail.com writes:
Patch with fixes attached.
Currently if-structure is as following:
+ if (count == 3)
...
+ else
+ {
+ /* If length is not equal to 3 then only power of 2 is supported.
*/
+ gcc_assert (exact_log2 (count) != -1);
For stores group I've created another mail thread.
[...]
2014-05-06 Evgeny Stupachenko evstu...@gmail.com
PR tree-optimization/52252
* gcc.dg/vect/pr52252-ld.c: Test on loads group of size 3.
This test FAILs on sparc-sun-solaris2.11, both 32 and 64-bit:
FAIL: gcc.dg/vect/pr52252-ld.c scan-tree-dump-times vect vectorized 1 loops 1
FAIL: gcc.dg/vect/pr52252-ld.c -flto -ffat-lto-objects scan-tree-dump-times
vect vectorized 1 loops 1
The dumps have
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.dg/vect/pr52252-ld.c:10:3: note:
not vectorized: relevant stmt not supported: in0_9 = *in_27;
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.dg/vect/pr52252-ld.c:7:1: note:
vectorized 0 loops in function.
Rainer
--
-
Rainer Orth, Center for Biotechnology, Bielefeld University
Re: libsanitizer merge from upstream r208536
Hi,
I see a couple of errors when building for arm-linux-gnueabi (host is
x86_64 Ubuntu 12.04 LTS, host compiler is gcc version 4.6.3
(Ubuntu/Linaro 4.6.3-1ubuntu5)):
1) In file included from
/home/max/workspace/downloads/gcc/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc:164:0:
/home/max/workspace/downloads/gcc/libsanitizer/sanitizer_common/sanitizer_internal_defs.h:253:72:
error: size of array 'assertion_failed__1128' is negative
typedef char IMPL_PASTE(assertion_failed_##_, line)[2*(int)(pred)-1]
^
/home/max/workspace/downloads/gcc/libsanitizer/sanitizer_common/sanitizer_internal_defs.h:247:30:
note: in expansion of macro 'IMPL_COMPILER_ASSERT'
#define COMPILER_CHECK(pred) IMPL_COMPILER_ASSERT(pred, __LINE__)
^
/home/max/workspace/downloads/gcc/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h:1249:3:
note: in expansion of macro 'COMPILER_CHECK'
COMPILER_CHECK(sizeof(__sanitizer_##TYPE) == sizeof(TYPE))
^
/home/max/workspace/downloads/gcc/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc:1128:1:
note: in expansion of macro 'CHECK_TYPE_SIZE'
CHECK_TYPE_SIZE(XDR::xdr_ops);
^
make[4]: *** [sanitizer_platform_limits_posix.lo] Error 1
2)
/home/max/workspace/downloads/gcc/libsanitizer/sanitizer_common/sanitizer_atomic_clang_other.h:54:77:
error: cast from type 'const volatile Type* {aka const volatile unsigned
char*}' to type 'volatile Type* {aka volatile unsigned char*}' casts
away qualifiers [-Werror=cast-qual]
v = __sync_fetch_and_add((typename T::Type
volatile*)a-val_dont_use, 0);
Attached patch seems to help.
-Maxim
diff --git a/libsanitizer/sanitizer_common/sanitizer_atomic_clang_other.h b/libsanitizer/sanitizer_common/sanitizer_atomic_clang_other.h
index 75aa2c8..f2f05a8 100644
--- a/libsanitizer/sanitizer_common/sanitizer_atomic_clang_other.h
+++ b/libsanitizer/sanitizer_common/sanitizer_atomic_clang_other.h
@@ -51,7 +51,7 @@ INLINE typename T::Type atomic_load(
// 64-bit load on 32-bit platform.
// Gross, but simple and reliable.
// Assume that it is not in read-only memory.
-v = __sync_fetch_and_add((typename T::Type volatile*)a-val_dont_use, 0);
+v = __sync_fetch_and_add(const_casttypename T::Type volatile*(a-val_dont_use), 0);
}
return v;
}
diff --git a/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h b/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h
index 97fda51..3ee8e33 100644
--- a/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h
+++ b/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h
@@ -273,10 +273,17 @@ namespace __sanitizer {
#endif
#if SANITIZER_LINUX !SANITIZER_ANDROID
+
+#if defined(__arm__)
+ const unsigned struct_xdr_ops_num_funs = 9;
+#else
+ const unsigned struct_xdr_ops_num_funs = 10;
+#endif
+
struct __sanitizer_XDR {
int x_op;
struct xdr_ops {
- uptr fns[10];
+ uptr fns[struct_xdr_ops_num_funs];
} *x_ops;
uptr x_public;
uptr x_private;
Re: [PATCH 1/7] Fix GTY markup of u2
On 05/10/14 13:58, Richard Sandiford wrote: The rtx u2 field currently uses a desc/tag pair for GTY. This seems unnecessary though, since the field is specifically supposed to be 32 bits wide on 64-bit hosts and so cannot hold a pointer. Tested on x86_64-linux-gnu. OK to install? Thanks, Richard gcc/ * rtl.h (rtx_def): Mark u2 as GTY ((skip)). OK for the trunk. Jeff
Re: libsanitizer merge from upstream r208536
On 05/12/2014 03:20 PM, Konstantin Serebryany wrote: This is the first libsanitizer merge in 4.10 Thanks, Kostya. I see that ASAN_DYNAMIC is not fully supported in libsanitizer Makefiles, I'll work on this once your patch goes in. I also have pending patch for asan-instrumentation-with-call-threshold parameter support in GCC. -Y
Re: [PATCH 2/7] Reduce GENERATOR_FILE ifndefs in print-rtl.c
On 05/10/14 14:00, Richard Sandiford wrote: The print-rtl.c code for '0' fields has a complicated sequence of ifndef GENERATOR_FILEs. None of the '0' data makes sense for generators though, so it seems simpler to wrap the whole case instead. Tested on x86_64-linux-gnu. OK to install? Thanks, Richard gcc/ * print-rtl.c (print_rtx): Guard whole '0' block with ifndef GENERATOR_FILE. OK. Thanks. Jeff
Re: [C PATCH] Make attributes accept enum values (PR c/50459)
On Sun, 11 May 2014, Marek Polacek wrote: FAIL: c-c++-common/pr50459.c -std=gnu++1y (test for excess errors) FAIL: c-c++-common/pr50459.c -Wc++-compat (test for excess errors) The errors are /opt/gcc/work/gcc/testsuite/c-c++-common/pr50459.c:8:1: error: constructor priorities are not supported /opt/gcc/work/gcc/testsuite/c-c++-common/pr50459.c:9:1: error: destructor priorities are not supported Ah. The following untested patch should skip that test on Darwin. Ok? I don't think the whole test should be skipped for that issue; I think the part requiring this feature should be split out into a separate testcase, so that as much as possible is still tested on Darwin. -- Joseph S. Myers jos...@codesourcery.com
Re: [PATCH 3/7] Move ORIGINAL_REGNO to rtx header
On 05/10/14 14:08, Richard Sandiford wrote: ...and reduce the size of REGs by one field. This is still OK for REG-MEM conversion since MEMs only have 2 fields. In some ways it would have been nicer to move REGNO to the header, since we wouldn't then need to fetch the second word of the rtx when checking whether something is a REG and then checking its REGNO. But that's much more complicated and essentially breaks the LISPness of rtxes; see the covering note for more details. Yea, we certainly hit REGNO much more often than ORIGINAL_REGNO, so it'be better to move the former. However, there's still obviously benefit in decreasing the size of a REG by a word. We currently print the ORIGINAL_REGNO twice if there are also REG_ATTRS. I've kept this behaviour in order to ensure that the -da output wasn't changed by the patch series, but I could turn the if into an else if if that seems better. Seems like a fine follow-up item. I was briefly concerned that these objects may not fall into one of the special buckets in the gc-allocator. But after looking at the code for how we initialize the extra_order_size_table we're probably OK. Tested on x86_64-linux-gnu. OK to install? Thanks, Richard gcc/ * rtl.def (REG): Remove middle field. * rtl.h (rtx_def): Add orignal_regno to u2. (ORIGINAL_REGNO): Use it instead of field 1. (REG_ATTRS): Lower field index accordingly. * gengtype.c (adjust_field_rtx_def): Remove handling of ORIGINAL_REGNO. Move REG_ATTRS index down. * print-rtl.c (print_rtx): Move ORIGINAL_REGNO handling to the code that prints the REGNO. This is fine for the trunk. Thanks, Jeff
Re: [PATCH 7/7] Move SYMBOL_REF_FLAGS to rtx header
On 05/12/14 05:00, Richard Sandiford wrote: Michael Matz m...@suse.de writes: Hi, On Sat, 10 May 2014, Richard Sandiford wrote: @@ -362,6 +362,9 @@ struct GTY((chain_next (RTX_NEXT (%h) /* The INSN_UID of an RTX_INSN-class code. */ int insn_uid; +/* The SYMBOL_REF_FLAGS of a SYMBOL_REF. */ +unsigned int symbol_ref_flags; + In [3/7] you used +/* The ORIGINAL_REGNO of a REG. */ +unsigned original_regno; + Should be consistent. Oops, indeed. Will fix them all to use unsigned int if approved. Approved with the consistency fix. jeff
Re: [PATCH 4/7] Move INSN_UID to the rtx header
On 05/10/14 14:12, Richard Sandiford wrote: This is a bit more complicated than REG because INSN_UID is an i field and so is a parameter to the respective gen_rtx_FOOs. However, in all but one case these uids were dummy values; the one exception can simply set the INSN_UID after the call instead. These rtxes also don't matter to genrecog or to the various equality routines, so the move should be safe despite being an i field. Tested on x86_64-linux-gnu. OK to install? Thanks, Richard gcc/ * rtl.def (DEBUG_INSN, INSN, JUMP_INSN, CALL_INSN, JUMP_TABLE_DATA) (BARRIER, CODE_LABEL, NOTE): Remove first i field. * rtl.h (rtx_def): Add insn_uid to u2 field. (RTX_FLAG_CHECK8): Delete in favor of... (RTL_INSN_CHAIN_FLAG_CHECK): ...this new macro. (INSN_DELETED_P): Update accordingly. (INSN_UID): Use u2.insn_uid. (INSN_CHAIN_CODE_P): Define. (PREV_INSN, NEXT_INSN, BLOCK_FOR_INSN, PATTERN, INSN_LOCATION) (INSN_CODE, REG_NOTES, CALL_INSN_FUNCTION_USAGE, CODE_LABEL_NUMBER) (NOTE_DATA, NOTE_DELETED_LABEL_NAME, NOTE_BLOCK, NOTE_EH_HANDLER) (NOTE_BASIC_BLOCK, NOTE_VAR_LOCATION, NOTE_CFI, NOTE_LABEL_NUMBER) (NOTE_KIND, LABEL_NAME, LABEL_NUSES, JUMP_LABEL, LABEL_REFS): Lower indices accordingly. * print-rtl.c (print_rtx): Print INSN_UIDs before the main loop. Update indices for insn-chain rtxes. * gengtype.c (gen_rtx_next): Adjust test for insn-chain rtxes. (adjust_field_rtx_def): Lower '0' indices for all insn-chain rtxes. * emit-rtl.c (gen_label_rtx): Update gen_rtx_LABEL call. * caller-save.c (init_caller_save): Update gen_rtx_INSN calls. * combine.c (try_combine): Likewise. * ira.c (setup_prohibited_mode_move_regs): Likewise. OK. I guess my fingers are going to have to get used to a new way to set conditional breakpoints on uids.. But that's no reason to reject the patch :-) Approved. Thanks. Jeff
Re: [PATCH 5/7] Shrink SCRATCH
On 05/10/14 14:16, Richard Sandiford wrote: SCRATCH has a single 0 field because reload used to turn it directly into a REG. It no longer does (or could do) that since REG has three fields rather than one. This patch therefore updates the comment and removes the field. Tested on x86_64-linux-gnu. OK to install? Thanks, Richard gcc/ * rtl.def (scratch): Fix outdated comment and remove 0 field. * gengtype.c (adjust_field_rtx_def): Update accordingly. Are you sure reload doesn't still do this? Do you have a pointer to when this code was removed? While I would have expected something to break, perhaps the problems are just latent. If you had a pointer which showed this code in reload being removed, I'd approve without hesitation. Jeff
Re: [PATCH 6/7] Move PAT_VAR_LOCATION_STATUS to rtx header
On 05/10/14 14:22, Richard Sandiford wrote: This is the other case (apart from INSN_UID) in which the field being moved is an i. I kept the gen_rtx_VAR_LOCATION interface the same by writing it in C code. As with INSN_UID, removing an i is safe because genrecog and the equality routines don't care about VAR_LOCATIONs. (Equality would only being meaningful if we also checked the decl in the 't' field.) Tested on x86_64-linux-gnu. OK to install? Thanks, Richard gcc/ * rtl.def (VAR_LOCATION): Remove i field. * rtl.h (rtx_def): Add u2.var_location_status. (PAT_VAR_LOCATION_STATUS): Use it. (gen_rtx_VAR_LOCATION): Declare. * gengenrtl.c (excluded_rtx): Add VAR_LOCATION. * emit-rtl.c (gen_rtx_VAR_LOCATION): New function. * var-tracking.c (emit_note_insn_var_location): Remove casts. OK. Jeff
Re: [PATCH] Enable Java on Cygwin-64
Hi, I have the following comment. boehm-gc/ChangeLog: 2014-05-11 Bernd Edlinger bernd.edlin...@hotmail.de Fix current cygwin-64 build problems. * include/gc_config_macros.h (GC_PTHREADS): Use __CYGWIN__ instead of __CYGWIN32__ here. * win32_threads.c (GC_push_all_stacks): Push all X86_64 registers. (GC_get_thread_stack_base): Get the stack base for X86_64. That change is ok. Please don't miss to post the changes also to boehm-gc's ML. In general it is better to splitt patches into seprate patches. To put all in one isn't ease review here. libffi/ChangeLog: 2014-05-11 Bernd Edlinger bernd.edlin...@hotmail.de Fix current cygwin-64 build problems. * src/java_raw_api.c: Remove if !defined(FFI_NO_RAW_API). * src/x86/ffi.c: Add if defined(__CYGWIN__). * src/x86/win64.S (ffi_closure_win64, ffi_call_win64): Added handling for FFI_TYPE_UINT64, FFI_TYPE_POINTER and FFI_TYPE_INT. Added SEH information. Fixed formatting. Patch is ok IMO. Nevertheless this part shall go also to libffi's ML. libgcc/ChangeLog: 2014-05-11 Bernd Edlinger bernd.edlin...@hotmail.de * unwind-seh.c (_Unwind_Backtrace): Uncommented, finished implementation. This part of the patch is ok. Please apply to trunk. libjava/ChangeLog: 2014-05-11 Bernd Edlinger bernd.edlin...@hotmail.de Fix current cygwin-64 build problems. * configure.host: Added handling for x86_64-*-cygwin/mingw. * boehm.cc (_Jv_GCAttachThread, _Jv_GCDetachThread): Don't compile if GC_WIN32_THREADS is defined. * java/lang/natClass.cc (_Jv_InterfaceAssignableFrom): Rename interface to source_interface. This part of the patch looks ok too. As here a libjava-maintainer needs to look into too, you should post this part again to ML with prominent marking libjava in subject line. libjava/classpath/ChangeLog: 2014-05-11 Bernd Edlinger bernd.edlin...@hotmail.de Fix current cygwin-64 build problems. * native/fdlibm/mprec.c (_REENT_CHECK_MP, _REENT_MP_FREELIST, _REENT_MP_P5S, __ULong, __Long): Undefine previous definitions. Same here. Looks ok to me, too. Nevertheless please post it as separate thread to ML. Thanks, Kai
Re: [Patch, avr] Fix PR60991
2014-05-12 14:17 GMT+04:00 Senthil Kumar Selvaraj senthil_kumar.selva...@atmel.com: This trivial patch fixes PR60991 by correcting the constant used to restore Y in one of the assembler template variants used in avr_out_store_psi. I've also added a testcase (modified from the original poster's code). If ok, could someone commit please? I don't have commit access. It would be great if this was also committed to 4.9 and 4.8 branches as well. Committed and backported to 4.9 and 4.8 Denis.
Re: [C PATCH] Make attributes accept enum values (PR c/50459)
Joseph,
I don't think the whole test should be skipped for that issue; I think the
part requiring this feature should be split out into a separate testcase,
so that as much as possible is still tested on Darwin.
Is the following patch
--- ../_clean/gcc/testsuite/c-c++-common/pr50459.c 2014-05-09
10:34:03.0 +0200
+++ gcc/testsuite/c-c++-common/pr50459.c2014-05-12 17:55:04.0
+0200
@@ -5,8 +5,8 @@
enum { A = 128, B = 1 };
void *fn1 (void) __attribute__((assume_aligned (A)));
void *fn2 (void) __attribute__((assume_aligned (A, 4)));
-void fn3 (void) __attribute__((constructor (A)));
-void fn4 (void) __attribute__((destructor (A)));
+void fn3 (void) __attribute__((constructor (A))); /* { dg-error constructor
priorities are not supported { target *-apple-darwin* } } */
+void fn4 (void) __attribute__((destructor (A))); /* { dg-error destructor
priorities are not supported { target *-apple-darwin* } } */
void *fn5 (int) __attribute__((alloc_size (B)));
void *fn6 (int) __attribute__((alloc_align (B)));
void fn7 (const char *, ...) __attribute__ ((sentinel (B)));
what you have in mind?
Dominique
Re: [PATCH] Clean up shrink-wrapping codes
On 05/12/14 02:02, Zhenqiang Chen wrote: Hi, According to Steven and Jeff's comments, the patch cleans up most shrink-wrapping codes from function.c to new added shrink-wrap.c. Changes include: (1) Move functions requires_stack_frame_p, next_block_for_reg, move_insn_for_shrink_wrap, prepare_shrink_wrap and dup_block_and_redirect to shrink-wrap.c (2) Extract 3 functions from function thread_prologue_and_epilogue_insns and move them to shrink-wrap.c. * try_shrink_wrapping * get_unconverted_simple_return * convert_to_simple_return (3) Make emit_return_into_block, active_insn_between, convert_jumps_to_returns, emit_return_for_exit, prepare_shrink_wrap and dup_block_and_redirect global. Bootstap and no make check regression on X86-64. OK for trunk? Thanks! -Zhenqiang ChangeLog: 2014-05-12 Zhenqiang Chen zhenqiang.c...@linaro.org * Makefile.in: add shrink-wrap.o. * function.c (requires_stack_frame_p, next_block_for_reg, move_insn_for_shrink_wrap, prepare_shrink_wrap, dup_block_and_redirect): Move to shrink-wrap.c (thread_prologue_and_epilogue_insns): Extract three code segments to shrink-wrap.c * function.h (emit_return_into_block, active_insn_between, convert_jumps_to_returns, emit_return_for_exit,prepare_shrink_wrap dup_block_and_redirect, try_shrink_wrapping, convert_to_simple_return, get_unconverted_simple_return): New prototypes. * shrink-wrap.c: New file. I know it's a bit of a pain, but can you go ahead and create shrink-wrap.h and put the exported interfaces from shrink-wrap.c into there an include shrink-wrap.h in the appropriate places (.c files, please don't include it in function.h). We're in the middle of trying to clean up the contents of the internal header files and bring some sanity to that mess. We should avoid making more work for those working on that project. Pre-approved with the addition of the new header file and using it in the appropriate .c files. Please post the final version of the patch so that it gets recorded in the archives. Thanks, Jeff
Re: [C PATCH] Make attributes accept enum values (PR c/50459)
On Mon, May 12, 2014 at 06:11:16PM +0200, Dominique Dhumieres wrote:
Joseph,
I don't think the whole test should be skipped for that issue; I think the
part requiring this feature should be split out into a separate testcase,
so that as much as possible is still tested on Darwin.
Is the following patch
--- ../_clean/gcc/testsuite/c-c++-common/pr50459.c2014-05-09
10:34:03.0 +0200
+++ gcc/testsuite/c-c++-common/pr50459.c 2014-05-12 17:55:04.0
+0200
@@ -5,8 +5,8 @@
enum { A = 128, B = 1 };
void *fn1 (void) __attribute__((assume_aligned (A)));
void *fn2 (void) __attribute__((assume_aligned (A, 4)));
-void fn3 (void) __attribute__((constructor (A)));
-void fn4 (void) __attribute__((destructor (A)));
+void fn3 (void) __attribute__((constructor (A))); /* { dg-error constructor
priorities are not supported { target *-apple-darwin* } } */
+void fn4 (void) __attribute__((destructor (A))); /* { dg-error destructor
priorities are not supported { target *-apple-darwin* } } */
void *fn5 (int) __attribute__((alloc_size (B)));
void *fn6 (int) __attribute__((alloc_align (B)));
void fn7 (const char *, ...) __attribute__ ((sentinel (B)));
what you have in mind?
I don't think so, we should split the pr50459.c into two .c files, the first
containing only the cdtor tests and requiring init_priotity targets,
the second one the rest (and not requiring init_priotity targets).
Marek
Re: [patch] fix impliedness of -Wunused-parameter depending on -Wexta option ordering
Am 08.05.2014 23:36, schrieb Joseph S. Myers: On Thu, 8 May 2014, Matthias Klose wrote: This fixes a regression introduced with 4.8, where the option ordering of -Wextra and -Wunused-parameter emits a warning, which is not emitted with 4.7. No regressions with the trunk, the 4.9 and 4.8 branches. Ok to check in for these? OK. I didn't look close enough to the gfortran test results. PR driver/61126 is a fix for the regression introduced with the fix for the above issue. With this patch proposed by Manuel, gfortran.dg/wextra_1.f now passes, and no new regressions seen on the trunk and the branches. Matthias gcc/fortran/ PR driver/61126 * options.c (gfc_handle_option): Don't enable -Wunused-parameter with -Wextra * lang.opt (Wunused-parameter): New. gcc/ PR driver/61126 * opts-global.c (set_default_handlers): Fix order of handlers. Index: gcc/fortran/lang.opt === --- a/src/gcc/fortran/lang.opt (revision 210277) +++ b/src/gcc/fortran/lang.opt (working copy) @@ -301,6 +301,10 @@ Fortran Warning Warn about unused dummy arguments. +Wunused-parameter +LangEnabledBy(Fortran,Wextra) +; Documented in common.opt + Wzerotrip Fortran Warning Warn about zero-trip DO loops Index: gcc/fortran/options.c === --- a/src/gcc/fortran/options.c (revision 210277) +++ b/src/gcc/fortran/options.c (working copy) @@ -674,12 +674,7 @@ break; case OPT_Wextra: - handle_generated_option (global_options, global_options_set, - OPT_Wunused_parameter, NULL, value, - gfc_option_lang_mask (), kind, loc, - handlers, global_dc); set_Wextra (value); - break; case OPT_Wfunction_elimination: Index: gcc/opts-global.c === --- a/src/gcc/opts-global.c (revision 210277) +++ b/src/gcc/opts-global.c (working copy) @@ -273,10 +273,10 @@ handlers-unknown_option_callback = unknown_option_callback; handlers-wrong_lang_callback = complain_wrong_lang; handlers-num_handlers = 3; - handlers-handlers[0].handler = lang_handle_option; - handlers-handlers[0].mask = initial_lang_mask; - handlers-handlers[1].handler = common_handle_option; - handlers-handlers[1].mask = CL_COMMON; + handlers-handlers[0].handler = common_handle_option; + handlers-handlers[0].mask = CL_COMMON; + handlers-handlers[1].handler = lang_handle_option; + handlers-handlers[1].mask = initial_lang_mask; handlers-handlers[2].handler = target_handle_option; handlers-handlers[2].mask = CL_TARGET; }
Re: libsanitizer merge from upstream r208536
Thanks! May I ask you to contribute the patch upstream?
https://code.google.com/p/address-sanitizer/wiki/HowToContribute
On Mon, May 12, 2014 at 7:19 PM, Maxim Ostapenko
m.ostape...@partner.samsung.com wrote:
Hi,
I see a couple of errors when building for arm-linux-gnueabi (host is x86_64
Ubuntu 12.04 LTS, host compiler is gcc version 4.6.3 (Ubuntu/Linaro
4.6.3-1ubuntu5)):
1) In file included from
/home/max/workspace/downloads/gcc/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc:164:0:
/home/max/workspace/downloads/gcc/libsanitizer/sanitizer_common/sanitizer_internal_defs.h:253:72:
error: size of array 'assertion_failed__1128' is negative
typedef char IMPL_PASTE(assertion_failed_##_, line)[2*(int)(pred)-1]
^
/home/max/workspace/downloads/gcc/libsanitizer/sanitizer_common/sanitizer_internal_defs.h:247:30:
note: in expansion of macro 'IMPL_COMPILER_ASSERT'
#define COMPILER_CHECK(pred) IMPL_COMPILER_ASSERT(pred, __LINE__)
^
/home/max/workspace/downloads/gcc/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h:1249:3:
note: in expansion of macro 'COMPILER_CHECK'
COMPILER_CHECK(sizeof(__sanitizer_##TYPE) == sizeof(TYPE))
^
/home/max/workspace/downloads/gcc/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc:1128:1:
note: in expansion of macro 'CHECK_TYPE_SIZE'
CHECK_TYPE_SIZE(XDR::xdr_ops);
^
make[4]: *** [sanitizer_platform_limits_posix.lo] Error 1
2)
/home/max/workspace/downloads/gcc/libsanitizer/sanitizer_common/sanitizer_atomic_clang_other.h:54:77:
error: cast from type 'const volatile Type* {aka const volatile unsigned
char*}' to type 'volatile Type* {aka volatile unsigned char*}' casts away
qualifiers [-Werror=cast-qual]
v = __sync_fetch_and_add((typename T::Type volatile*)a-val_dont_use,
0);
Attached patch seems to help.
-Maxim
Re: libsanitizer merge from upstream r208536
On Mon, May 12, 2014 at 7:36 PM, Yury Gribov y.gri...@samsung.com wrote: On 05/12/2014 03:20 PM, Konstantin Serebryany wrote: This is the first libsanitizer merge in 4.10 Thanks, Kostya. I see that ASAN_DYNAMIC is not fully supported in libsanitizer Makefiles, Generally, I prefer to minimize the changes in the build files and put as much logic into the source as possible. Didn't http://llvm.org/viewvc/llvm-project?view=revisionrevision=208530 help? I'll work on this once your patch goes in. Good! I also have pending patch for asan-instrumentation-with-call-threshold parameter support in GCC. -Y
Re: genattrtab error reporting
On 05/12/14 01:15, Mike Stump wrote: 2014-05-07 Mike Stumpmikest...@comcast.net * genattrtab.c (struct insn_def): Add filename. (convert_set_attr_alternative): Improve error message. (check_defs): Ensure read_md_filename is set appropriately. (gen_insn): Save read_md_filename. OK for the trunk. Jeff
Re: [DOC Patch] Remove reference to deleted macro
On 05/11/14 18:40, David Wohlferd wrote: I don't have permissions to commit this patch, but I do have a release on file with the FSF. Problem description: The existing docs make reference to a macro which is described below. However, this is the final sentence in the section; there is no below. Turns out the macro was deleted a long time ago (June 2012) in revision 188983 (pr33190), leaving this perplexing sentence behind. ChangeLog: 2014-05-11 David Wohlferd d...@limegreensocks.com * doc/tm.texi: Remove reference to deleted macro. * doc/tm.texi.in: Likewise. Thanks. Installed. jeff
Re: [PATCH] Add a couple of dialect and warning options regarding Objective-C instance variable scope
On Apr 28, 2014, at 3:35 AM, Dimitris Papavasiliou dpapa...@gmail.com wrote:
+ a = private;/* { dg-warning hides instance variable { xfail
*-*-* } } */
+ a = protected; /* { dg-warning hides instance variable { xfail
*-*-* } } */
+ a = public; /* { dg-warning hides instance variable { xfail
*-*-* } } */
No, we don’t expect failures. We makes the compiler do what we wants or it
gets the hose again. Then, we expect it to be perfect. If you won’t want
warning, and non are produces, then just remove the /* … */, or write /* no
warning */.
I've fixed these as per your request. For the record though, this form of
test seems to be fairly common in the test suites as this output indicates:
dimitris@debian:~/sandbox/gcc-build$ find ../gcc-source/gcc/testsuite/ -name
*.c -o -name *.C -o -name *.m | xargs grep xfail \*-\*-\* | wc -l
354
Many of these seem to be in error or warning messages which are expected not
to show up. In any case if the messages do show up they'll trigger the
excessive messages test so I suppose that's enough.
Once we resolve the 3 warning tests above, this will be ok.
Actually, there were a few more { xfail *-*-* } in the other test cases.
I've removed these as well.
So, let’s make sure we’re on the same page…
Take shadow-2.m for example, before you said:
+ a = private;/* { dg-warning hides instance variable { xfail *-*-* }
} */
and now you say:
+ a = private;/* No warning. */
So, the first question is, what do we _want_ in the end here? Warning or no
warning? And what do we actually do now, warn or not?
If in the end, we want a warning, then the previous form is the right
eventually form. If we don’t want a warning, then the second is correct,
though, there is another form that is not unreasonable:
i += [Base class_func1]; /* { dg-bogus invalid receiver type } */
this says that we used to generate a warning (or an error message), but that
was wrong, and we no longer want to expect a warning, and that the bug has been
fixed and that no warning is generated.
I think we are on the same page, just wanted to make sure...
Re: PR61140: check the phi is unique in value_replacement
On 05/11/14 04:03, Marc Glisse wrote: On Sat, 10 May 2014, Andrew Pinski wrote: On Sat, May 10, 2014 at 3:53 PM, Marc Glisse marc.gli...@inria.fr wrote: Hello, in my recent phiopt patch enhancing value_replacement to optimize x!=0?x+y:y, I forgot to check that there is no other PHI (not sure how I managed to miss that since I copy-pasted the line just below the test). If there are other phi nodes (with different arguments for those 2 branches), it would be possible to replace the phi argument and stop there (as value_replacement does for its other transformation). However, I am chosing to punt. The cost analysis would be different, and I wrote the transformation assuming that this single-phi test was already done higher in the function. I think we should have some good cost analysis because for this testcase, we should be able to get only one conditional move but right now with punting we don't. That's true. But note that the transformation is already very limited (gives up if there is a second statement in the middle bb, even a simple cast), so I would like to first quickly get the wrong-code regression out of the way, and we can make improvements afterwards (though we can of course start discussing them now). It seems like if there is only 1 extra non-singleton phi (in addition to the one we are transforming) and the target supports conditional move for this type and the direct branch has proba 50%, with the other restrictions already in place, we could go ahead. How does that sound? Not too specialized? If there are many phis, conditional moves are out, the branch will stay, and unless the edge to the operation has a very high proba, it doesn't seem like a good idea to pull the operation out of the branch. Your call based on what you see from a codegen standpoint. Having been burned before with these kinds of transformations, I tend to be a bit conservative :-) If you decide to keep things as-is, the patch is fine. If you want to extend to handle the additional case, please repost for review. Thanks, jeff
Re: [PATCH 7/7] Move SYMBOL_REF_FLAGS to rtx header
On 05/10/14 14:24, Richard Sandiford wrote: Very much like the code to move ORIGINAL_REGNO, but with a few more knock-on changes. I handled the printing by dumping the flags immediately before the SYMBOL_REF_DATA. Tested on x86_64-linux-gnu. OK to install? Thanks, Richard gcc/ * rtl.def (SYMBOL_REF): Remove middle 0 field. * rtl.h (block_symbol): Reduce number of fields to 2. (rtx_def): Add u2.symbol_ref_flags. (SYMBOL_REF_FLAGS): Use it. (SYMBOL_REF_DATA, SET_SYMBOL_REF_DECL, SYMBOL_REF_DECL) (SET_SYMBOL_REF_CONSTANT, SYMBOL_REF_CONSTANT): Lower index. * gengtype.c (adjust_field_rtx_def): Remove SYMBOL_REF_FLAGS handling. Lower index of SYMBOL_REF_DATA. * print-rtl.c (print_rtx): Lower index for SYMBOL_REF_DATA. Print SYMBOL_REF_FLAGS at the same time. * genattrtab.c (attr_rtx_1): Only initialize 1 0 SYMBOL_REF field. OK for the trunk. jeff
Re: libsanitizer merge from upstream r208536
On 05/12/2014 08:16 PM, Konstantin Serebryany wrote: Thanks! May I ask you to contribute the patch upstream? https://code.google.com/p/address-sanitizer/wiki/HowToContribute Note that we wouldn't be able to repro in upstream because * ARM isn't supported * LLVM won't build with gcc 4.6 anyway -Y
[PATCH, AArch64] Implement HARD_REGNO_CALLER_SAVE_MODE
Currently, on AArch64, when a caller-save register is saved/restored,
GCC is accessing the maximum size of the hard register.
So an SImode integer (4 bytes) value is being stored as DImode (8 bytes)
because the int registers are 8 bytes wide, and an SFmode float (4 bytes)
and DFmode double (8 bytes) are being stored as TImode (16 bytes) to
capture the full 128-bits of the vector register.
This patch corrects this, by implementing the HARD_REGNO_CALLER_SAVE_MODE
hook, which is called by LRA to determine the minimise size it might need
to save/restore.
Tested on GCC regression suite and verified impact on a number of examples.
OK for trunk?
Cheers,
Ian
2014-05-12 Ian Bolton ian.bol...@arm.com
* config/aarch64/aarch64-protos.h
(aarch64_hard_regno_caller_save_mode): New prototype.
* config/aarch64/aarch64.c (aarch64_hard_regno_caller_save_mode):
New function.
* config/aarch64/aarch64.h (HARD_REGNO_CALLER_SAVE_MODE): New macro.diff --git a/gcc/config/aarch64/aarch64-protos.h
b/gcc/config/aarch64/aarch64-protos.h
index 04cbc78..7cf7d9f 100644
--- a/gcc/config/aarch64/aarch64-protos.h
+++ b/gcc/config/aarch64/aarch64-protos.h
@@ -202,6 +202,8 @@ enum aarch64_symbol_type aarch64_classify_symbol (rtx,
enum aarch64_symbol_type aarch64_classify_tls_symbol (rtx);
enum reg_class aarch64_regno_regclass (unsigned);
int aarch64_asm_preferred_eh_data_format (int, int);
+enum machine_mode aarch64_hard_regno_caller_save_mode (unsigned, unsigned,
+ enum machine_mode);
int aarch64_hard_regno_mode_ok (unsigned, enum machine_mode);
int aarch64_hard_regno_nregs (unsigned, enum machine_mode);
int aarch64_simd_attr_length_move (rtx);
diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index 8655f04..c2cc81b 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -424,6 +424,24 @@ aarch64_hard_regno_mode_ok (unsigned regno, enum
machine_mode mode)
return 0;
}
+/* Implement HARD_REGNO_CALLER_SAVE_MODE. */
+enum machine_mode
+aarch64_hard_regno_caller_save_mode (unsigned regno, unsigned nregs,
+enum machine_mode mode)
+{
+ /* Handle modes that fit within single registers. */
+ if (nregs == 1 GET_MODE_SIZE (mode) = 16)
+{
+ if (GET_MODE_SIZE (mode) = 4)
+return mode;
+ else
+return SImode;
+}
+ /* Fall back to generic for multi-reg and very large modes. */
+ else
+return choose_hard_reg_mode (regno, nregs, false);
+}
+
/* Return true if calls to DECL should be treated as
long-calls (ie called via a register). */
static bool
diff --git a/gcc/config/aarch64/aarch64.h b/gcc/config/aarch64/aarch64.h
index c9b30d0..0574593 100644
--- a/gcc/config/aarch64/aarch64.h
+++ b/gcc/config/aarch64/aarch64.h
@@ -824,6 +824,11 @@ do {
\
#define SHIFT_COUNT_TRUNCATED !TARGET_SIMD
+/* Choose appropriate mode for caller saves, so we do the minimum
+ required size of load/store. */
+#define HARD_REGNO_CALLER_SAVE_MODE(REGNO, NREGS, MODE) \
+ aarch64_hard_regno_caller_save_mode ((REGNO), (NREGS), (MODE))
+
/* Callee only saves lower 64-bits of a 128-bit register. Tell the
compiler the callee clobbers the top 64-bits when restoring the
bottom 64-bits. */
Re: [PATCH 5/7] Shrink SCRATCH
Jeff Law l...@redhat.com writes:
On 05/10/14 14:16, Richard Sandiford wrote:
SCRATCH has a single 0 field because reload used to turn it directly
into a REG. It no longer does (or could do) that since REG has three
fields rather than one. This patch therefore updates the comment and
removes the field.
Tested on x86_64-linux-gnu. OK to install?
Thanks,
Richard
gcc/
* rtl.def (scratch): Fix outdated comment and remove 0 field.
* gengtype.c (adjust_field_rtx_def): Update accordingly.
Are you sure reload doesn't still do this? Do you have a pointer to
when this code was removed?
The rtl.def SCRATCH entry predates the repository (1991) and I couldn't
see anything in the initial versions of reload.c or reload1.c that set
the code to a REG. local-alloc.c had:
if (qty_scratch_rtx[q])
{
if (GET_CODE (qty_scratch_rtx[q]) == REG)
abort ();
PUT_CODE (qty_scratch_rtx[q], REG);
REGNO (qty_scratch_rtx[q]) = qty_phys_reg[q];
but that was removed by:
Wed Oct 22 00:34:12 1997 Jeffrey A Law (l...@cygnus.com)
* local-alloc.c (block_alloc): Don't lose if two SCRATCH expressions
are shared.
(Disappointed that you don't remember what you did in 97. :-))
I couldn't see anything in global.c that would set the code to a REG.
No current calls to PUT_CODE would do that either.
REG became bigger than SCRATCH with:
Thu Jun 25 15:08:16 1998 Mark Mitchell m...@markmitchell.com
* invoke.texi (-fstrict-aliasing): Document.
* rtl.texi (MEM_ALIAS_SET): Document.
Thanks,
Richard
Re: [patch] Remove shadow variable
Hi! On Fri, 9 May 2014 18:07:52 +0200, Jakub Jelinek ja...@redhat.com wrote: On Fri, May 09, 2014 at 11:03:35AM -0500, James Norris wrote: Removed three occurrences of a shadow variable. Bootstrapped and tested on x86-64-unknown-linux-gnu. 2014-05-09 James Norris jnor...@codesourcery.com Jim, note that once you get to commit this, the date will need to be updated to that day's current date. * omp-low.c (expand_parallel_call): Remove shadow variable. (expand_omp_taskreg): Likewise. Indent by a tab instead of four spaces. GNU ChangeLog policy; http://www.gnu.org/prep/standards/html_node/Change-Logs.html. Ok. Jim does not yet have commit access/a sourceware account. He's covered by the general Mentor Graphics/CodeSourcery copyright assignment. Jim, please request an account per http://gcc.gnu.org/svnwrite.html, and on https://sourceware.org/cgi-bin/pdw/ps_form.cgi put in one of us as approver. Grüße, Thomas pgpUzMroDZL07.pgp Description: PGP signature
Re: libsanitizer merge from upstream r208536
* ARM isn't supported I meant ARM-Linux. -Y
Re: libsanitizer merge from upstream r208536
On 05/12/2014 08:18 PM, Konstantin Serebryany wrote: Didn'thttp://llvm.org/viewvc/llvm-project?view=revisionrevision=208530 help? Ah true, I missed the fact that you define PIC in libsanitizer/configure. -Y
Re: Contributing new gcc targets: i386-*-dragonfly and x86-64-*-dragonfly
On 05/09/14 01:14, John Marino wrote: On 5/9/2014 07:26, Jeff Law wrote: On 05/03/14 01:11, John Marino wrote: In config.gcc: +no | gnat | single) + # Let these non-posix thread selections fall through if requested Support for gnat as a thread model was removed in 2011. So I think you need to remove that case. I realized that the gnat thread mechanism had been removed a couple of days ago, but I didn't want to invalidate the ongoing review since it was a not really an issue. I'll make the change now. This hunk was obviously created when it did exist. No problem. configure.ac: + *-*-dragonfly* | *-*-freebsd*) +if grep dl_iterate_phdr $target_header_dir/sys/link_elf.h /dev/null 21; then + gcc_cv_target_dl_iterate_phdr=yes +else + gcc_cv_target_dl_iterate_phdr=no +fi +;; Presumably you intended to change freebsd* here. Just want a confirmation. I haven't worked on the *bsd platforms in about 20 years, so I have no idea if this is right for them in general. Yes, this is intentional. This is why I also did a full testsuite on FreeBSD as well as DragonFly to prove that still worked. OK. Just wanted to be sure. As I mentioned, it's been a *long* time since I did anything with the *bsd ports. NetBSD and OpenBSD would be handled similarly when the time comes, but they would need to grep a different header. I see you have a dragonfly-stdint.h. Is there a particular reason why you can't use the freebsd-stdint.h? I didn't check every type, but a quick glance makes me think they ought to be equivalent. Similarly for dragonfly.opt. And there is already precedent for each system to have its own files: freebsd.opt freebsd-stdint.h openbsd.opt openbsd-stdint.h netbsd.opt ( The dragonfly-stdint.h is cleaner than freebsd-stdint.h as well. Yea, there's always a bit of a natural tension between having this kind of stuff duplicated vs sharing when their contents are common. I lean towards the latter in this case for a variety of reasons. While similar due to heritage, and also due to a conscious effort to keep the userland compatible where a difference isn't specifically needed, DragonFly is not FreeBSD. We've had a challenge with software that consider them to be equivalent in every aspect. I certainly understand having done similar stuff in the past. Sometimes changes are made against a FreeBSD file that is not valid for DragonFly, so even if they are equivalent today they may not be in the future. We prefer separate configuration files like NetBSD and OpenBSD have in general. Right and this is the most important counter-argument to sharing. They're compatible today, but will they be tomorrow? It sounds like Dragonfly has a bit of a mandate to be different than FreeBSD, so there's probably more than the usual chance this stuff could diverge in the future. by the way config/dragonfly.h and config/i386/dragonfly.h are significantly different that FreeBSD counterparts. And we eliminated the equivalent of config/i386/freebsd64.h by combining it's functionality into config/i386/dragonfly.h. There are also platform-specific differences there so there is no question that DragonFly needs its own header files. I saw that when scanning dragfonfly.h and freebsd.h to see how much commonality there was between them. I'm going to trust the unwind code works and isn't duplicating something from somewhere else that ought to instead be shared. Not only is it not duplicated, FreeBSD needs its own, different version (FreeBSD is currently missing unwind functionality). I have the patch and that's a separate submission (out of scope for DragonFly target creation). Believe me, if there is one thing you would not want to duplicate, it's MD support code. FYI NetBSD and OpenBSD are missing this functionality too. So it basically looks good. Can you fix the config.gcc nit and determine if we can (and should) share files with freebsd. Repost after those fixes and we should be ready to go. 1) Patch updated online as requested 2) At this exact point in time, we probably can share the files 3) I might debate that we should share the files - that would imply reviewing the existing counterpart files for NetBSD and OpenBSD and combining when equivalent. Let's go ahead and keep the files separate. We can always go back and combine them at a later date if we see the need. So with that in mind, the patch is good to go with the gnat thread stuff removed. Do you have write access, or do you you need someone to commit the change for you? Jeff
Re: [PATCH 5/7] Shrink SCRATCH
On 05/12/14 10:37, Richard Sandiford wrote:
The rtl.def SCRATCH entry predates the repository (1991) and I couldn't
see anything in the initial versions of reload.c or reload1.c that set
the code to a REG. local-alloc.c had:
if (qty_scratch_rtx[q])
{
if (GET_CODE (qty_scratch_rtx[q]) == REG)
abort ();
PUT_CODE (qty_scratch_rtx[q], REG);
REGNO (qty_scratch_rtx[q]) = qty_phys_reg[q];
but that was removed by:
Wed Oct 22 00:34:12 1997 Jeffrey A Law (l...@cygnus.com)
* local-alloc.c (block_alloc): Don't lose if two SCRATCH expressions
are shared.
(Disappointed that you don't remember what you did in 97. :-))
:-) '97 to '99 were, umm, busy.
I couldn't see anything in global.c that would set the code to a REG.
No current calls to PUT_CODE would do that either.
REG became bigger than SCRATCH with:
Thu Jun 25 15:08:16 1998 Mark Mitchell m...@markmitchell.com
* invoke.texi (-fstrict-aliasing): Document.
* rtl.texi (MEM_ALIAS_SET): Document.
OK. Concerns addressed. Go ahead with the change.
Thanks for the detective work! :-)
jeff
Re: Contributing new gcc targets: i386-*-dragonfly and x86-64-*-dragonfly
On 5/12/2014 18:59, Jeff Law wrote: On 05/09/14 01:14, John Marino wrote: 1) Patch updated online as requested 2) At this exact point in time, we probably can share the files 3) I might debate that we should share the files - that would imply reviewing the existing counterpart files for NetBSD and OpenBSD and combining when equivalent. Let's go ahead and keep the files separate. We can always go back and combine them at a later date if we see the need. So with that in mind, the patch is good to go with the gnat thread stuff removed. Do you have write access, or do you you need someone to commit the change for you? Thanks, Jeff! I do not have write access, but jwakely has graciously offered to commit this patchset when it achieves approval, so I guess he's on deck! John
Re: [PATCH 33/89] Use more concrete types for various gimple statements
On 04/21/14 10:57, David Malcolm wrote: gcc/ * cgraphunit.c (thunk_adjust): Strengthen local stmt from gimple to gimple_assign. * gimple-ssa-isolate-paths.c (insert_trap_and_remove_trailing_statements): Strengthen local new_stmt from gimple to gimple_call. * gimple-ssa-strength-reduction.c (replace_mult_candidate): Strengthen local copy_stmt from gimple to gimple_assign. (create_add_on_incoming_edge): Likewise, for new_stmt. (insert_initializers): Likewise, for init_stmt. (introduce_cast_before_cand): Likewise, for cast_stmt. (replace_one_candidate): Likewise, for copy_stmt and cast_stmt. * gimplify.c (build_stack_save_restore): Require gimple_calls rather than plain gimples. (gimplify_bind_expr): Strengthen locals stack_save and stack_restore from gimple to gimple_call. Strengthen gs to gimple_try. (gimplify_switch_expr): Strengthen local gimple_switch from gimple to gimple_switch, and new_default to gimple_label. (gimplify_cond_expr): Strengthen local gimple_cond from gimple to gimple_cond. (gimplify_init_constructor): Strengthen local init from gimple to gimple_assign. (gimplify_cleanup_point_expr): Strengthen local gtry from gimple to gimple_try. (gimple_push_cleanup): Strengthen locals ffalse and ftrue from gimple to gimple_assign. * tree-eh.c (do_goto_redirection): Strengthen local to gimple_goto. (emit_post_landing_pad): Strengthen local to gimple_label. * tree-outof-ssa.c (insert_backedge_copies): Strengthen local stmt from gimple to gimple_assign. * tree-parloops.c (take_address_of): Likewise. * tree-predcom.c (replace_ref_with): Likewise, for new_stmt. (initialize_root_vars_lm): Likewise, for init_stmt. (reassociate_to_the_same_stmt): Likewise, for new_stmt and tmp_stmt. * tree-profile.c (gimple_gen_edge_profiler): Likewise, for stmt1, stmt2, stmt3. (gimple_gen_ic_profiler): Likewise. (gimple_gen_ic_func_profiler): Strengthen local stmt1 from gimple to gimple_call, and stmt2 to gimple_assign. * tree-scalar-evolution.c (scev_const_prop): Strengthen local ass from gimple to gimple_assign. * tree-sra.c (build_ref_for_offset): Likewise for stmt. (generate_subtree_copies): Likewise; also strengthen ds to gimple_debug. (init_subtree_with_zero): Likewise. (sra_modify_expr): Likewise. (load_assign_lhs_subreplacements): Likewise. (sra_modify_assign): Strengthen ds to gimple_debug. (sra_ipa_reset_debug_stmts): Likewise for def_temp. * tree-ssa-ccp.c (insert_clobber_before_stack_restore): Strengthen local clobber_stmt from gimple to gimple_assign. * tree-ssa-dce.c (remove_dead_stmt): Strengthen note to gimple_debug. * tree-ssa-dom.c (record_equivalences_from_stmt): Strengthen local new_stmt from gimple to gimple_assign. (optimize_stmt): Likewise. * tree-ssa-forwprop.c (simplify_bitwise_binary): Likewise for 4 declarations of newop. (simplify_rotate): Likewise for g. * tree-ssa-loop-im.c (rewrite_reciprocal): Likewise for 3 locals. (rewrite_bittest): Likewise for stmt and stmt2. (move_computations_dom_walker::before_dom_children): Likewise for new_stmt. (execute_sm): Likewise for load and store. * tree-ssa-loop-ivcanon.c (remove_exits_and_undefined_stmts): Strengthen local stmt from gimple to gimple_call. (unloop_loops): Likewise. * tree-ssa-loop-ivopts.c (rewrite_use_nonlinear_expr): Strengthen local ass from gimple to gimple_assign. (remove_unused_ivs): Strengthen def_temp to gimple_debug. * tree-ssa-loop-manip.c (rewrite_phi_with_iv): Strengthen local stmt from gimple to gimple_assign. * tree-ssa-loop-prefetch.c (issue_prefetch_ref): Strengthen local prefetch from gimple to gimple_call. * tree-ssa-math-opts.c (insert_reciprocals): Strengthen local new_stmt from gimple to gimple_assign. (powi_as_mults_1): Likewise for mult_stmt. (powi_as_mults): Likewise for div_stmt. (build_and_insert_binop): Likewise for stmt. (build_and_insert_cast): Likewise. (execute_cse_sincos): Likewise for stmt and various decls of new_stmt. (execute_optimize_bswap): Likewise for two decls of convert_stmt. (convert_mult_to_fma): Likewise for fma_stmt. * tree-ssa-phiopt.c (conditional_replacement): Likewise for new_stmt. (abs_replacement): Likewise. * tree-ssa-phiprop.c (phiprop_insert_phi): Likewise for tmp. * tree-ssa-pre.c (create_expression_by_pieces): Likewise for newstmt. (eliminate_insert):
Re: Contributing new gcc targets: i386-*-dragonfly and x86-64-*-dragonfly
On 05/12/14 11:10, John Marino wrote: On 5/12/2014 18:59, Jeff Law wrote: On 05/09/14 01:14, John Marino wrote: 1) Patch updated online as requested 2) At this exact point in time, we probably can share the files 3) I might debate that we should share the files - that would imply reviewing the existing counterpart files for NetBSD and OpenBSD and combining when equivalent. Let's go ahead and keep the files separate. We can always go back and combine them at a later date if we see the need. So with that in mind, the patch is good to go with the gnat thread stuff removed. Do you have write access, or do you you need someone to commit the change for you? Thanks, Jeff! I do not have write access, but jwakely has graciously offered to commit this patchset when it achieves approval, so I guess he's on deck! OK. It's Jon's :-) Jeff
Re: [PATCH 35/89] Introduce gimple_omp_atomic_store
On 04/21/14 10:57, David Malcolm wrote: gcc/ * coretypes.h (gimple_omp_atomic_store): New typedef. (const_gimple_omp_atomic_store): New typedef. * gimple-pretty-print.c (dump_gimple_omp_atomic_store): Require a gimple_omp_atomic_store rather than a plain gimple. (pp_gimple_stmt_1): Add checked cast to gimple_omp_atomic_store within GIMPLE_OMP_ATOMIC_STORE case of switch statement. * gimple-walk.c (walk_gimple_op): Likewise. * gimple.c (gimple_build_omp_atomic_store): Return a gimple_omp_atomic_store rather than a plain gimple. * gimple.h (gimple_statement_base::as_a_gimple_omp_atomic_store): New. (gimple_build_omp_atomic_store): Return a gimple_omp_atomic_store rather than a plain gimple. (gimple_omp_atomic_store_set_val): Require a gimple_omp_atomic_store rather than a plain gimple. (gimple_omp_atomic_store_val_ptr): Likewise. (gimple_omp_atomic_store_val): Require a const_gimple_omp_atomic_store rather than a plain const_gimple. * gimplify.c (gimplify_omp_atomic): Strengthen locals loadstmt and storestmt from gimple to gimple_omp_atomic_load loadstmt and gimple_omp_atomic_store storestmt respectively. * omp-low.c (expand_omp_atomic): Strengthen local store from gimple to gimple_omp_atomic_store. OK with expected changes due to renaming/updates to const handling. Please repost the final patch for archival purposes.
Re: [PATCH 40/89] tree-cfg.c: Make verify_gimple_call require a gimple_call
On 04/21/14 10:57, David Malcolm wrote: gcc/ * tree-cfg.c (verify_gimple_call): Require a gimple_call rather than a plain gimple. (verify_gimple_stmt): Add checked cast to gimple_call within GIMPLE_CALL case of switch statement. OK when prerequisites have gone in. jeff
Re: [PATCH 41/89] Introduce gimple_omp_task
On 04/21/14 10:57, David Malcolm wrote: gcc/ * coretypes.h (gimple_omp_task): New typedef. (const_gimple_omp_task): New typedef. * gimple.h (gimple_statement_base::as_a_gimple_omp_task): New. (gimple_build_omp_task): Return a gimple_omp_task rather than a plain gimple. * gimple-pretty-print.c (dump_gimple_omp_task): Require a gimple_omp_task rather than a plain gimple. (pp_gimple_stmt_1): Add checked cast to gimple_omp_task within GIMPLE_OMP_TASK case of switch statement. * gimple.c (gimple_build_omp_task): Return a gimple_omp_task rather than a plain gimple. * omp-low.c (finalize_task_copyfn): Require a gimple_omp_task rather than a plain gimple. (delete_omp_context): Add checked cast to gimple_omp_task. (scan_omp_task): Strengthen local stmt from gimple to gimple_omp_task. (expand_task_call): Require a gimple_omp_task rather than a plain gimple. (expand_omp_taskreg): Add checked cast to gimple_omp_task. (create_task_copyfn): Require a gimple_omp_task rather than a plain gimple. (lower_omp_taskreg): Add checked cast to gimple_omp_task. OK with expected changes due to renaming/updates to const handling. Please repost the final patch for archival purposes. Thanks, Jeff
Re: [PATCH 42/89] Introduce gimple_omp_single
On 04/21/14 10:57, David Malcolm wrote: gcc/ * coretypes.h (gimple_omp_single): New typedef. (const_gimple_omp_single): New typedef. * gimple.h (gimple_statement_base::as_a_gimple_omp_single): New. (gimple_build_omp_single): Return a gimple_omp_single rather than a plain gimple. (gimple_omp_single_set_clauses): Require a gimple_omp_single rather than a plain gimple. * gimple-pretty-print.c (dump_gimple_omp_single): Require a gimple_omp_single rather than a plain gimple. (pp_gimple_stmt_1): Add checked cast to gimple_omp_single within GIMPLE_OMP_SINGLE case of switch statement. * gimple.c (gimple_build_omp_single): Return a gimple_omp_single rather than a plain gimple. * omp-low.c (scan_omp_single): Require a gimple_omp_single rather than a plain gimple. (scan_omp_1_stmt): Add checked cast to gimple_omp_single within GIMPLE_OMP_SINGLE case of switch statement. (lower_omp_single_simple): Require a gimple_omp_single rather than a plain gimple. (lower_omp_single_copy): Likewise. (lower_omp_single): Strengthen local single_stmt from gimple to gimple_omp_single. OK with expected changes due to renaming/updates to const handling. Please repost the final patch for archival purposes. Jeff
Re: [PATCH 44/89] Introduce gimple_omp_teams
On 04/21/14 10:57, David Malcolm wrote: gcc/ * coretypes.h (gimple_omp_teams): New typedef. (const_gimple_omp_teams): New typedef. * gimple.h (gimple_statement_base::as_a_gimple_omp_teams): New. (gimple_build_omp_teams): Return a gimple_omp_teams rather than a plain gimple. (gimple_omp_teams_set_clauses): Require a gimple_omp_teams rather than a plain gimple. * gimple-pretty-print.c (dump_gimple_omp_teams): Require a gimple_omp_teams rather than a plain gimple. (pp_gimple_stmt_1): Add checked cast to gimple_omp_teams within GIMPLE_OMP_TEAMS case of switch statement. * gimple.c (gimple_build_omp_teams): Return a gimple_omp_teams rather than a plain gimple. * omp-low.c (scan_omp_teams): Likewise. (scan_omp_1_stmt): Add checked cast to gimple_omp_teams within GIMPLE_OMP_TEAMS case of switch statement. (lower_omp_teams): Strengthen local teams_stmt from gimple to gimple_omp_teams. OK with expected changes due to renaming/updates to const handling. Please repost the final patch for archival purposes. Jeff
Re: [PATCH 37/89] Introduce gimple_omp_critical
On 04/21/14 10:57, David Malcolm wrote: gcc/ * coretypes.h (gimple_omp_critical): New typedef. (const_gimple_omp_critical): New typedef. * gimple-pretty-print.c (dump_gimple_omp_critical): Require a gimple_omp_critical rather than a plain gimple. (pp_gimple_stmt_1): Add a checked cast to gimple_omp_critical within GIMPLE_OMP_CRITICAL case of switch statement. * gimple-walk.c (walk_gimple_op): Likewise. * gimple.c (gimple_build_omp_critical): Return a gimple_omp_critical rather than a plain gimple. (gimple_copy): Add checked casts to gimple_omp_critical within GIMPLE_OMP_CRITICAL case of switch statement. * gimple.h (gimple_statement_base::as_a_gimple_omp_critical): New. (gimple_statement_base::dyn_cast_gimple_omp_critical): New. (gimple_debug): Likewise. (gimple_build_omp_critical): Return a gimple_omp_critical rather than a plain gimple. (gimple_omp_critical_name): Require a const_gimple_omp_critical rather than a plain const_gimple. (gimple_omp_critical_name_ptr): Require a gimple_omp_critical rather than a plain gimple. (gimple_omp_critical_set_name): Likewise. * omp-low.c (check_omp_nesting_restrictions): Add a checked cast to gimple_omp_critical within GIMPLE_OMP_CRITICAL case of switch statement, introducing a new local other_crit for type-safety. (lower_omp_critical): Strengthen local stmt to gimple_omp_critical. * tree-inline.c (remap_gimple_stmt): Add a checked cast to gimple_omp_critical within GIMPLE_OMP_CRITICAL case of switch statement. OK with expected changes due to renaming/updates to const handling. Please repost the final patch for archival purposes. Thanks, Jeff
Re: [PATCH 34/89] Introduce gimple_omp_atomic_load
On 04/21/14 10:57, David Malcolm wrote: gcc/ * coretypes.h (gimple_omp_atomic_load): New typedef. (const_gimple_omp_atomic_load): New typedef. * gimple-pretty-print.c (dump_gimple_omp_atomic_load): Require a gimple_omp_atomic_load rather than a plain gimple. (pp_gimple_stmt_1): Add a checked cast to gimple_omp_atomic_load within GIMPLE_OMP_ATOMIC_LOAD case of switch statement. * gimple-walk.c (walk_gimple_op): Likewise, introducing a new local. * gimple.c (gimple_build_omp_atomic_load): Return a gimple_omp_atomic_load rather than a plain gimple. * gimple.h (gimple_statement_base::as_a_gimple_omp_atomic_load): New. (gimple_build_omp_atomic_load): Return a gimple_omp_atomic_load rather than a plain gimple. (gimple_omp_atomic_load_set_lhs): Require a gimple_omp_atomic_load rather than a plain gimple. (gimple_omp_atomic_load_lhs_ptr): Likewise. (gimple_omp_atomic_load_set_rhs): Likewise. (gimple_omp_atomic_load_rhs_ptr): Likewise. (gimple_omp_atomic_load_lhs): Require a const_gimple_omp_atomic_load rather than a plain const_gimple. (gimple_omp_atomic_load_rhs): Likewise. * gimplify-me.c (gimple_regimplify_operands): Add a checked cast to gimple_omp_atomic_load within GIMPLE_OMP_ATOMIC_LOAD case of switch statement. * omp-low.c (expand_omp_atomic): Strengthen type of local load from gimple to gimple_omp_atomic_load. (lower_omp_1): Add a checked cast to gimple_omp_atomic_load within GIMPLE_OMP_ATOMIC_LOAD case of switch statement. OK with expected changes due to renaming/updates to const handling. Please repost the final patch for archival purposes. Jeff
Re: [PATCH 50/89] Make gimple_phi_arg_set_location require a gimple_phi
On 04/21/14 10:57, David Malcolm wrote: gcc/ * gimple.h (gimple_phi_arg_set_location): Require a gimple_phi rather than a plain gimple. OK once prerequisites have gone in. jeff
Re: [PATCH 47/89] omp-low.c: Use more concrete types of gimple statement for various locals
On 04/21/14 10:57, David Malcolm wrote: gcc/ * omp-low.c (finalize_task_copyfn): Strengthen local bind from plain gimple to gimple_bind. (lower_rec_input_clauses): Strengthen local g from plain gimple to gimple_assign. (lower_lastprivate_clauses): Likewise for stmt to gimple_cond and g to gimple_call. (expand_omp_for_init_vars): Likewise, for two decls of stmt to gimple_assign. (expand_omp_atomic_pipeline): Likewise for one decl of stmt. (expand_omp_atomic_mutex): Likewise. (lower_omp_master): Likewise for x to gimple_call. (lower_omp_ordered): Likewise. OK once prerequisites have gone in. jeff
Re: [PATCH 53/89] More gimple_phi
On 04/21/14 10:57, David Malcolm wrote: gcc/ * gimple.h (gimple_phi_set_result): Require a gimple_phi rather than a plain gimple. (gimple_phi_set_arg): Likewise. * tree-outof-ssa.c (remove_gimple_phi_args): Likewise; add a checked cast to gimple_phi. * tree-sra.c (replace_removed_params_ssa_names): Add a checked cast to gimple_phi. Ok once prerequisites have gone in. jeff
Re: [PATCH 58/89] Make gimple_label_set_label require a gimple_label
On 04/21/14 10:57, David Malcolm wrote: gcc/ * gimple.h (gimple_label_set_label): Require a gimple_label. OK once prerequisites have gone in. jeff \
Re: [PATCH 60/89] Concretize gimple_catch_types
On 04/21/14 10:57, David Malcolm wrote: gcc/ * gimple.h (gimple_catch_types): Require a const_gimple_catch rather than a const_gimple. --- OK once prerequisites have gone in. jeff
Re: [PATCH 59/89] Make gimple_goto_set_dest require a gimple_goto
On 04/21/14 10:57, David Malcolm wrote: gcc/ * gimple.h (gimple_goto_set_dest): Require a gimple_goto. * tree-cfg.c (factor_computed_gotos): Add checked cast to gimple_goto. (cleanup_dead_labels): Likewise. OK once prerequisites have gone in. jeff
Re: [PATCH 61/89] Concretize gimple_call_use_set and gimple_call_clobber_set
On 04/21/14 10:57, David Malcolm wrote: gcc/ * gimple.h (gimple_call_use_set): Require a gimple_call. (gimple_call_clobber_set): Likewise. OK once prerequisites have gone in. jeff
Re: [PATCH 64/89] Concretize gimple_try_set_catch_is_cleanup
On 04/21/14 10:57, David Malcolm wrote: gcc/ * gimple.h (gimple_try_set_catch_is_cleanup): Require a gimple_try. * gimplify.c (gimplify_expr): Convert local try_ from a gimple to a gimple_try. OK after prerequisites have gone in. jeff
Re: [PATCH 46/89] tree-parloops.c: Use gimple_phi in various places
On 04/21/14 10:57, David Malcolm wrote: gcc/ * tree-parloops.c (reduction_info::keep_res): Strengthen field from plain gimple to gimple_phi. (transform_to_exit_first_loop): Strengthen locals phi, nphi to gimple_phi. Eliminate early decl of gimple_stmt_iterator gsi in favor of more tightly scoped gimple_phi_iterators, and a final later decl as a gimple_stmt_iterator. --- OK once prerequisites have gone in. Thanks, Jeff
Re: [PATCH 45/89] Introduce gimple_omp_sections
On 04/21/14 10:57, David Malcolm wrote: gcc/ * coretypes.h (gimple_omp_sections): New typedef. (const_gimple_omp_sections): New typedef. * gimple-pretty-print.c (dump_gimple_omp_sections): Require a gimple_omp_sections rather than a plain gimple. (pp_gimple_stmt_1): Add checked cast to gimple_omp_sections within GIMPLE_OMP_SECTIONS case of switch statement. * gimple.c (gimple_build_omp_sections): Return a gimple_omp_sections rather than a plain gimple. * gimple.h (gimple_statement_base::as_a_gimple_omp_sections): New. (gimple_build_omp_sections): Return a gimple_omp_sections rather than a plain gimple. * omp-low.c (scan_omp_sections): Require a gimple_omp_sections rather than a plain gimple. (scan_omp_1_stmt): Add checked cast to gimple_omp_sections within GIMPLE_OMP_SECTIONS case of switch statement. (expand_omp_sections): Strengthen local sections_stmt from gimple to gimple_omp_sections. (lower_omp_sections): Likewise for stmt. OK with expected changes due to renaming/updates to const handling. Please repost the final patch for archival purposes. Jeff
Re: [PATCH 54/89] Make gimple_call_return_slot_opt_p require a gimple_call.
On 04/21/14 10:57, David Malcolm wrote: gcc/ * gimple.h (gimple_call_return_slot_opt_p): Require a gimple_call rather than a plain gimple. * gimple-walk.c (walk_stmt_load_store_addr_ops): Convert usage of is_gimple_call to dyn_cast_gimple_call, introducing a new local call_stmt. * trans-mem.c (expand_call_tm): Split local stmt, strengthening from plain gimple to a gimple_call, and introducing new local gimple_assign assign_stmt. * tree-inline.c (expand_call_inline): Convert check of code against GIMPLE_CALL to dyn_cast_gimple_call, introducing a new local call_stmt. OK once prerequisites have gone in. jeff
Re: [PATCH 43/89] Introduce gimple_omp_target
On 04/21/14 10:57, David Malcolm wrote: gcc/ * coretypes.h (gimple_omp_target): New typedef. (const_gimple_omp_target): New typedef. * gimple.h (gimple_statement_base::as_a_gimple_omp_target): New. (gimple_build_omp_target): Return a gimple_omp_target rather than a plain gimple. (gimple_omp_target_set_clauses): Require a gimple_omp_target rather than a plain gimple. (gimple_omp_target_set_kind): Likewise. (gimple_omp_target_child_fn_ptr): Likewise. (gimple_omp_target_set_child_fn): Likewise. (gimple_omp_target_data_arg_ptr): Likewise. (gimple_omp_target_set_data_arg): Likewise. (gimple_omp_target_child_fn): Require a const_gimple_omp_target rather than a plain const_gimple. (gimple_omp_target_data_arg): Likewise. * gimple-pretty-print.c (dump_gimple_omp_target): Require a gimple_omp_target rather than a plain gimple. (pp_gimple_stmt_1): Add checked cast to gimple_omp_target within GIMPLE_OMP_TARGET case of switch statement. * gimple.c (gimple_build_omp_target): Return a gimple_omp_target rather than a plain gimple. * gimplify.c (gimplify_omp_target_update): Strengthen local stmt from gimple to gimple_omp_target. * omp-low.c (scan_omp_target): Require a gimple_omp_target rather than a plain gimple. (scan_omp_1_stmt): Add checked cast to gimple_omp_target within GIMPLE_OMP_TARGET case of switch statement. (expand_omp_target): Strengthen local entry_stmt from gimple to gimple_omp_target. (lower_omp_target): Likewise for stmt. OK with expected changes due to renaming/updates to const handling. Please repost the final patch for archival purposes. Jeff
Re: [PATCH, PR58066] preferred_stack_boundary update for tls expanded call
Here is a patch for the test. It contains two changes:
1. For emutls, there will be an explicit call generated at expand
pass, and no stack adjustment is needed. So add /* {
dg-require-effective-target tls_native } */ in the test.
2. Replace cfi_def_cfa_offset with insn sequence check.
Is it ok?
No, the test FAILs for 32-bit i386-pc-solaris2.11 with Sun as/ld:
FAIL: gcc.target/i386/pr58066.c scan-assembler
sub[^\r\n]*8[^\r\n]*sp.*call[^\r\n]*__tls_get_addr.*sub[^\r\n]*8[^\r\n]*sp.*call[^\r\n]*__tls_get_addr
The TLS code sequence is different here:
subl$8, %esp
lealccc1@tlsgd(,%ebx,1), %eax
callccc1@tlsgdplt
I fear this insn scanning is going to be extremely fragile.
Rainer
Thanks for trying the testcase. rtl scanning will be slightly better
than assembly scanning. So how about this one?
Thanks,
Wei.
Index: testsuite/gcc.target/i386/pr58066.c
===
--- testsuite/gcc.target/i386/pr58066.c (revision 210222)
+++ testsuite/gcc.target/i386/pr58066.c (working copy)
@@ -1,5 +1,6 @@
/* { dg-do compile } */
-/* { dg-options -fPIC -O2 } */
+/* { dg-require-effective-target tls_native } */
+/* { dg-options -fPIC -fomit-frame-pointer -O2 -fdump-rtl-final } */
/* Check whether the stack frame starting addresses of tls expanded calls
in foo and goo are 16bytes aligned. */
@@ -15,4 +16,6 @@ void* goo()
return ccc2;
}
-/* { dg-final { scan-assembler-times .cfi_def_cfa_offset 16 2 } } */
+/* { dg-final { scan-rtl-dump Function
foo.*set\[^\r\n\]*sp\\)\[\r\n\]\[^\r\n\]*plus\[^\r\n\]*sp\\)\[\r\n\]\[^\r\n\]*const_int
-8.*UNSPEC_TLS.*Function goo final } } */
+/* { dg-final { scan-rtl-dump Function
goo.*set\[^\r\n\]*sp\\)\[\r\n\]\[^\r\n\]*plus\[^\r\n\]*sp\\)\[\r\n\]\[^\r\n\]*const_int
-8.*UNSPEC_TLS final } } */
+/* { dg-final { cleanup-rtl-dump final } } */
Re: [PATCH 38/89] Introduce gimple_omp_for
On 04/21/14 10:57, David Malcolm wrote: gcc/ * coretypes.h (gimple_omp_for): New. (const_gimple_omp_for): New. * gimple.h (gimple_statement_base::as_a_gimple_omp_for): New. (gimple_statement_base::dyn_cast_gimple_omp_for): New. (gimple_build_omp_for): Return a gimple_omp_for rather than a plain gimple. (gimple_omp_for_set_kind): Require a gimple_omp_for rather than a plain gimple. (gimple_omp_for_set_combined_p): Likewise. (gimple_omp_for_set_combined_into_p): Likewise. * gimple-pretty-print.c (dump_gimple_omp_for): Require a gimple_omp_for rather than a plain gimple. (pp_gimple_stmt_1): Add a checked cast to gimple_omp_for in GIMPLE_OMP_FOR case of switch statement. * gimple.c (gimple_build_omp_for): Return a gimple_omp_for rather than a plain gimple. (gimple_copy): Add a checked cast to gimple_omp_for and a new local. * gimplify.c (gimplify_omp_for): Strengthen local gfor from gimple to gimple_omp_for. * omp-low.c (omp_for_data::for_stmt): Strengthen field from gimple to gimple_omp_for. (extract_omp_for_data): Require a gimple_omp_for rather than a plain gimple. (workshare_safe_to_combine_p): Add a checked cast to gimple_omp_for. (get_ws_args_for): Convert check of code against GIMPLE_OMP_FOR with a dyn_cast_gimple_omp_for and a new local. (scan_omp_parallel): Add a checked cast to gimple_omp_for and a new local. (scan_omp_for): Require a gimple_omp_for rather than a plain gimple. (scan_omp_1_stmt): Add a checked cast to gimple_omp_for in GIMPLE_OMP_FOR case of switch statement. (expand_omp_for): Add a checked cast to gimple_omp_for. (lower_omp_for): Strengthen local stmt from gimple to gimple_omp_for. * tree-nested.c (walk_gimple_omp_for): Require a gimple_omp_for rather than a plain gimple. (convert_nonlocal_reference_stmt): Add a checked cast to gimple_omp_for in GIMPLE_OMP_FOR case of switch statement. (convert_local_reference_stmt): Likewise. * tree-parloops.c (create_parallel_loop): Strengthen local for_stmt from gimple to gimple_omp_for. --- OK with expected changes due to renaming/updates to const handling. Please repost the final patch for archival purposes. Jeff
Re: [PATCH 36/89] Introduce gimple_omp_continue
On 04/21/14 10:57, David Malcolm wrote: gcc/ * coretypes.h (gimple_omp_continue): New typedef. (const_gimple_omp_continue): New typedef. * gimple.h (gimple_statement_base::as_a_gimple_omp_continue): New. (gimple_build_omp_continue): Return a gimple_omp_continue rather than a plain gimple. (gimple_omp_continue_control_def): Require a const_gimple_omp_continue rather than a plain const_gimple. (gimple_omp_continue_control_use): Likewise. (gimple_omp_continue_control_def_ptr): Require a gimple_omp_continue rather than a plain gimple. (gimple_omp_continue_set_control_def): Likewise. (gimple_omp_continue_control_use_ptr): Likewise. (gimple_omp_continue_set_control_use): Likewise. * gimple-pretty-print.c (dump_gimple_omp_continue): Require a gimple_omp_continue rather than a plain gimple. (pp_gimple_stmt_1): Add a checked cast to gimple_omp_continue within GIMPLE_OMP_CONTINUE case of switch statement. * gimple-walk.c (walk_gimple_op): Likewise, adding a new local. * gimple.c (gimple_build_omp_continue): Return a gimple_omp_continue rather than a plain gimple. * omp-low.c (gimple_build_cond_empty): Return a gimple_cond rather than a plain gimple. (expand_omp_for_generic): Split local stmt into assign_stmt, cont_stmt, cond_stmt, call_stmt of types gimple_assign, gimple_omp_continue, gimple_cond, gimple_call respectively. (expand_omp_for_static_nochunk): Likewise, splitting into two cond_stmt decls. assign_stmt, cont_stmt (expand_omp_for_static_chunk): Likewise, splitting into cond_stmt, assign_stmt, cont_stmt. (expand_omp_sections): Strengthen local cont from gimple to gimple_omp_continue. OK with expected changes due to renaming/updates to const handling. Please repost the final patch for archival purposes. THanks, Jeff
Re: [PATCH 39/89] Introduce gimple_omp_parallel
On 04/21/14 10:57, David Malcolm wrote: gcc/ * coretypes.h (gimple_omp_parallel): New typedef. (const_gimple_omp_parallel): New typedef. * cgraphbuild.c (build_cgraph_edges): Convert check of code against GIMPLE_OMP_PARALLEL to a dyn_cast_gimple_omp_parallel and new local. * gimple-pretty-print.c (dump_gimple_omp_parallel): Require a gimple_omp_parallel rather than a plain gimple. (pp_gimple_stmt_1): Add a checked cast to gimple_omp_parallel within GIMPLE_OMP_PARALLEL case of switch statement. * gimple-walk.c (walk_gimple_op): Likewise, introducing a local. * gimple.c (gimple_build_omp_parallel): Return a gimple_omp_parallel rather than a plain gimple. (gimple_copy): Add checked casts to gimple_omp_parallel within GIMPLE_OMP_PARALLEL case of switch statement, introducing locals. * gimple.h (gimple_statement_base::as_a_gimple_omp_parallel): New. (gimple_statement_base::dyn_cast_gimple_omp_parallel): New. (gimple_build_omp_parallel): Return a gimple_omp_parallel rather than a plain gimple. (gimple_omp_parallel_clauses_ptr): Require a gimple_omp_parallel rather than a plain gimple. (gimple_omp_parallel_set_clauses): Likewise. (gimple_omp_parallel_data_arg_ptr): Likewise. (gimple_omp_parallel_set_data_arg): Likewise. (gimple_omp_parallel_child_fn_ptr): Likewise. (gimple_omp_parallel_set_child_fn): Likewise. (gimple_omp_parallel_child_fn): Require a const_gimple_omp_parallel rather than a plain const_gimple. (gimple_omp_parallel_data_arg): Likewise. * omp-low.c (scan_omp_parallel): Strengthen local stmt from gimple to gimple_omp_parallel. (expand_parallel_call): Require a gimple_omp_parallel for entry_stmt rather than a plain gimple. (remove_exit_barrier): Strengthen local parallel_stmt from gimple to gimple_omp_parallel. (expand_omp_taskreg): Add checked cast to gimple_omp_parallel. * tree-inline.c (remap_gimple_stmt): Add a checked cast to gimple_omp_parallel within GIMPLE_OMP_PARALLEL case of switch statement, introducing local. --- OK with expected changes due to renaming/updates to const handling. Please repost the final patch for archival purposes. jeff
Re: [PATCH 48/89] Make gimple_phi_arg_def_ptr and gimple_phi_arg_has_location require a gimple_phi
On 04/21/14 10:57, David Malcolm wrote: gcc/ * gimple.h (gimple_phi_arg_def_ptr): Require a gimple_phi rather than a plain gimple. (gimple_phi_arg_has_location): Likewise. * gimple-streamer-in.c (input_phi): Return a gimple_phi rather than a plain gimple. * gimple-streamer-out.c (output_phi): Require a gimple_phi rather than a plain gimple. (output_bb): Convert iteration to a gimple_phi_iterator, and local phi to gimple_phi. * omp-low.c (expand_omp_for_static_chunk): Convert iterator psi to a gimple_phi_iterator; convert locals phi and nphi to be gimple_phi. * tree-cfg.c (gimple_duplicate_sese_tail): Likewise for psi and phi. (move_block_to_fn): Introduce new gimple_phi_iterator psi, using it in place of gsi where necessary. Convert phi to be a gimple_phi. * tree-cfgcleanup.c (remove_forwarder_block): Likewise. * tree-vect-loop-manip.c (vect_loop_versioning): Convert gsi to a gimple_phi_iterator, and orig_phi and new_phi to be gimple_phi. * tree.c (find_decls_types_in_node): Introduce new gimple_phi_iterator psi, using it in place of si where necessary. Convert phi to be a gimple_phi. OK once prerequisites have gone in. Thanks, Jeff
Re: [PATCH 54/89] Make gimple_call_return_slot_opt_p require a gimple_call.
On 04/21/14 10:57, David Malcolm wrote: gcc/ * gimple.h (gimple_call_return_slot_opt_p): Require a gimple_call rather than a plain gimple. * gimple-walk.c (walk_stmt_load_store_addr_ops): Convert usage of is_gimple_call to dyn_cast_gimple_call, introducing a new local call_stmt. * trans-mem.c (expand_call_tm): Split local stmt, strengthening from plain gimple to a gimple_call, and introducing new local gimple_assign assign_stmt. * tree-inline.c (expand_call_inline): Convert check of code against GIMPLE_CALL to dyn_cast_gimple_call, introducing a new local call_stmt. OK once prerequisites have gone in. Jeff
Re: [PATCH 63/89] Concretize gimple_eh_filter_set_types and gimple_eh_filter_set_failure
On 04/21/14 10:57, David Malcolm wrote: gcc/ * gimple.h (gimple_eh_filter_set_types): Require a gimple_eh_filter. (gimple_eh_filter_set_failure): Likewise. * gimple.c (gimple_copy): Add checked casts to gimple_eh_filter within GIMPLE_EH_FILTER case. --- OK once prerequisites have gone in. jeff
Re: [PATCH 65/89] Concretize three gimple_try_set_ accessors
On 04/21/14 10:57, David Malcolm wrote: gcc/ * gimple.c (gimple_copy): Add checked casts to gimple_try. * gimple.h (gimple_statement_base::dyn_cast_gimple_try): New. (gimple_try_set_kind): Require a gimple_try. (gimple_try_set_eval): Likewise. (gimple_try_set_cleanup): Likewise. * tree-eh.c (optimize_double_finally): Require a pair of gimple_try statements. (refactor_eh_r): Convert code comparisons to dynamic casts. --- OK once prerequisites have gone in. Jeff
Re: [PATCH 65/89] Concretize three gimple_try_set_ accessors
On 04/21/14 10:57, David Malcolm wrote: gcc/ * gimple.c (gimple_copy): Add checked casts to gimple_try. * gimple.h (gimple_statement_base::dyn_cast_gimple_try): New. (gimple_try_set_kind): Require a gimple_try. (gimple_try_set_eval): Likewise. (gimple_try_set_cleanup): Likewise. * tree-eh.c (optimize_double_finally): Require a pair of gimple_try statements. (refactor_eh_r): Convert code comparisons to dynamic casts. OK once prerequisites have gone in. jeff
