Re: [PATCH, ARM] attribute target (thumb,arm) [0/6]
Hi Ramana, On 11/27/2014 11:36 AM, Ramana Radhakrishnan wrote: On Wed, Nov 19, 2014 at 2:54 PM, Christian Bruel wrote: On 11/19/2014 03:18 PM, Ramana Radhakrishnan wrote: On Wed, Nov 19, 2014 at 1:24 PM, Christian Bruel wrote: I think I missed the stage3, Anyway would it be OK for stage1 when it reopens ? Since you submitted this well during stage1 and given that these patches address comments from earlier in the review process we should aim to get these in for 5.0. If at some point during the review process it looks risky and there needs to be significant rework we can always stop. It's on the list of patches to be reviewed and I will find some dedicated time later this week to set down and review / play with the patches in an attempt to move this forward as it is a reasonably large chunk of work. Thanks, also I forgot to mention that you need https://gcc.gnu.org/ml/gcc-patches/2014-10/msg01231.html to play with the attribute. Will be part of the same shot. Isn't that Ok'd for committing ? Why then isn't it applied ? yes it was, it is in my single changeset with the attribute target since itś the only way to trigger the issue. Cheers Christian Ramana Christian Thanks for continuing to work on these patches and addressing the earlier review comments. regards Ramana Christian
[Patch ARM] Add entry for march=armv8-a+crc in t-aprofile.
Hi, An internal user reported that -march=armv8-a+crc wasn't allowing the driver to pick up the right multilib for an arm-none-eabi toolchain configured with --with-multilib-list=aprofile. Without this patch on arm-none-eabi with --with-multilib-list=aprofile prints. $)./xgcc -S -O2 -march=armv8-a+crc -mfpu=neon -mfloat-abi=softfp -print-multi-directory /tmp/tst.c . $) with this patch $>./xgcc -S -O2 -march=armv8-a+crc -mfpu=neon -mfloat-abi=softfp -print-multi-directory /tmp/tst.c v7-a/simdv1/softfp Applied to trunk after simple cross build and test on arm-none-eabi. I intend to backport the same to the 4.9 branch as the issue exists there too and this is just in the configury and build of the baremetal toolchain. regards Ramana 2014-11-28 Ramana Radhakrishnan * config/arm/t-aprofile (MULTILIB_MATCHES): New entry for -march=armv8-a+crc. diff --git a/gcc/config/arm/t-aprofile b/gcc/config/arm/t-aprofile index ff9e2e1..86741e6 100644 --- a/gcc/config/arm/t-aprofile +++ b/gcc/config/arm/t-aprofile @@ -88,6 +88,9 @@ MULTILIB_MATCHES += march?armv8-a=mcpu?cortex-a53 MULTILIB_MATCHES += march?armv8-a=mcpu?cortex-a57 MULTILIB_MATCHES += march?armv8-a=mcpu?cortex-a57.cortex-a53 +# Arch Matches +MULTILIB_MATCHES += march?armv8-a=march?armv8-a+crc + # FPU matches MULTILIB_MATCHES += mfpu?vfpv3-d16=mfpu?vfpv3 MULTILIB_MATCHES += mfpu?vfpv3-d16=mfpu?vfpv3-fp16
Re: [PATCH 6/n] OpenMP 4.0 offloading infrastructure: option handling
On Fri, 28 Nov 2014, Ilya Verbin wrote:
> On 11 Oct 18:49, Ilya Verbin wrote:
> > (run_gcc): Outline options handling into the new functions:
> > find_and_merge_options, append_compiler_options, append_linker_options.
> > ...
> > @@ -625,18 +893,13 @@ run_gcc (unsigned argc, char *argv[])
> >/* Look at saved options in the IL files. */
> >for (i = 1; i < argc; ++i)
> > {
> > ...
> > + have_lto
> > + = find_and_merge_options (fd, file_offset, LTO_SECTION_NAME_PREFIX,
> > + &fdecoded_options, &fdecoded_options_count,
> > + collect_gcc);
> > + have_offload
> > + = find_and_merge_options (fd, file_offset, OFFLOAD_SECTION_NAME_PREFIX,
> > + &offload_fdecoded_options,
> > + &offload_fdecoded_options_count, collect_gcc);
> >close (fd);
> > }
>
> I found a bug here, have_{lto,offload} must be set if at least one file
> contains
> lto/offload sections, but currently they are overwritten by the last file.
> Fix is bootstrapped and regtested on x86_64-linux. OK for trunk?
Ok.
Thanks,
Richard.
>
> gcc/
> * lto-wrapper.c (run_gcc): Set have_lto and have_offload if at least one
> file contains sections with LTO and offload IR, respectively.
>
>
> diff --git a/gcc/lto-wrapper.c b/gcc/lto-wrapper.c
> index 9a540b4..0f69457 100644
> --- a/gcc/lto-wrapper.c
> +++ b/gcc/lto-wrapper.c
> @@ -921,13 +921,14 @@ run_gcc (unsigned argc, char *argv[])
> continue;
>
>have_lto
> - = find_and_merge_options (fd, file_offset, LTO_SECTION_NAME_PREFIX,
> - &fdecoded_options, &fdecoded_options_count,
> - collect_gcc);
> + |= find_and_merge_options (fd, file_offset, LTO_SECTION_NAME_PREFIX,
> +&fdecoded_options, &fdecoded_options_count,
> +collect_gcc);
>have_offload
> - = find_and_merge_options (fd, file_offset, OFFLOAD_SECTION_NAME_PREFIX,
> - &offload_fdecoded_options,
> - &offload_fdecoded_options_count, collect_gcc);
> + |= find_and_merge_options (fd, file_offset, OFFLOAD_SECTION_NAME_PREFIX,
> +&offload_fdecoded_options,
> +&offload_fdecoded_options_count,
> +collect_gcc);
>close (fd);
> }
>
>
> -- Ilya
>
>
--
Richard Biener
SUSE LINUX GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendoerffer, HRB 21284
(AG Nuernberg)
Maxfeldstrasse 5, 90409 Nuernberg, Germany
Re: [PATCH][OpenMP] Fix named critical sections inside target functions
On Fri, Nov 28, 2014 at 02:52:11AM +0300, Ilya Verbin wrote: > On 21 Nov 21:36, Jakub Jelinek wrote: > > On Fri, Nov 21, 2014 at 11:19:26PM +0300, Ilya Verbin wrote: > > > '#pragma omp critical (name)' can be placed in the function, marked > > > with '#pragma omp declare target', in this case the corresponding node > > > should be marked as offloadable too. > > > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? > > > > Please add a testcase for this. > > Here is the testcase, based on critical-2.c, ok for trunk? > > > gcc/ > * omp-low.c (lower_omp_critical): Mark critical sections > inside target functions as offloadable. > > libgomp/ > * testsuite/libgomp.c/target-critical-1.c: New test. Ok, thanks. Jakub
Re: [PATCH][PR63661]Add a test case for trunk.
On Thu, Nov 27, 2014 at 5:32 PM, Renlin Li wrote: > Hi all, > > PR63661 is effectively fixed by my previous patch here: > https://gcc.gnu.org/ml/gcc-patches/2014-11/msg02253.html > > This patch add a test case for it. > > Okay for trunk? Ok. Thanks, RIchard. > gcc/testsuite/ChangeLog: > > 2014-11-27 Renlin Li > > PR target/63661 > * gcc.target/i386/pr63661.c: New.
[PATCH] [AArch64, NEON] Improve vpmaxX & vpminX intrinsics
Hi,
This patch converts vpmaxX & vpminX intrinsics to use builtin functions
instead of the previous inline assembly syntax.
Regtested with aarch64-linux-gnu on QEMU. Also passed the glorious testsuite
of Christophe Lyon.
OK for the trunk?
Index: gcc/ChangeLog
===
--- gcc/ChangeLog (revision 218128)
+++ gcc/ChangeLog (working copy)
@@ -1,3 +1,19 @@
+2014-11-28 Felix Yang
+
+ * config/aarch64/aarch64-simd.md (aarch64_p): New
+ pattern.
+ * config/aarch64/aarch64-simd-builtins.def (smaxp, sminp, umaxp,
+ uminp, smax_nanp, smin_nanp): New builtins.
+ * config/aarch64/arm_neon.h (vpmax_s8, vpmax_s16, vpmax_s32,
+ vpmax_u8, vpmax_u16, vpmax_u32, vpmaxq_s8, vpmaxq_s16, vpmaxq_s32,
+ vpmaxq_u8, vpmaxq_u16, vpmaxq_u32, vpmax_f32, vpmaxq_f32, vpmaxq_f64,
+ vpmaxqd_f64, vpmaxs_f32, vpmaxnm_f32, vpmaxnmq_f32, vpmaxnmq_f64,
+ vpmaxnmqd_f64, vpmaxnms_f32, vpmin_s8, vpmin_s16, vpmin_s32, vpmin_u8,
+ vpmin_u16, vpmin_u32, vpminq_s8, vpminq_s16, vpminq_s32, vpminq_u8,
+ vpminq_u16, vpminq_u32, vpmin_f32, vpminq_f32, vpminq_f64, vpminqd_f64,
+ vpmins_f32, vpminnm_f32, vpminnmq_f32, vpminnmq_f64, vpminnmqd_f64,
+ vpminnms_f32): Rewrite using builtin functions.
+
2014-11-27 Richard Biener
PR middle-end/64088
Index: gcc/config/aarch64/arm_neon.h
===
--- gcc/config/aarch64/arm_neon.h (revision 218128)
+++ gcc/config/aarch64/arm_neon.h (working copy)
@@ -8975,491 +8975,7 @@ vpadds_f32 (float32x2_t a)
return result;
}
-__extension__ static __inline float32x2_t __attribute__ ((__always_inline__))
-vpmax_f32 (float32x2_t a, float32x2_t b)
-{
- float32x2_t result;
- __asm__ ("fmaxp %0.2s, %1.2s, %2.2s"
- : "=w"(result)
- : "w"(a), "w"(b)
- : /* No clobbers */);
- return result;
-}
-
-__extension__ static __inline int8x8_t __attribute__ ((__always_inline__))
-vpmax_s8 (int8x8_t a, int8x8_t b)
-{
- int8x8_t result;
- __asm__ ("smaxp %0.8b, %1.8b, %2.8b"
- : "=w"(result)
- : "w"(a), "w"(b)
- : /* No clobbers */);
- return result;
-}
-
__extension__ static __inline int16x4_t __attribute__ ((__always_inline__))
-vpmax_s16 (int16x4_t a, int16x4_t b)
-{
- int16x4_t result;
- __asm__ ("smaxp %0.4h, %1.4h, %2.4h"
- : "=w"(result)
- : "w"(a), "w"(b)
- : /* No clobbers */);
- return result;
-}
-
-__extension__ static __inline int32x2_t __attribute__ ((__always_inline__))
-vpmax_s32 (int32x2_t a, int32x2_t b)
-{
- int32x2_t result;
- __asm__ ("smaxp %0.2s, %1.2s, %2.2s"
- : "=w"(result)
- : "w"(a), "w"(b)
- : /* No clobbers */);
- return result;
-}
-
-__extension__ static __inline uint8x8_t __attribute__ ((__always_inline__))
-vpmax_u8 (uint8x8_t a, uint8x8_t b)
-{
- uint8x8_t result;
- __asm__ ("umaxp %0.8b, %1.8b, %2.8b"
- : "=w"(result)
- : "w"(a), "w"(b)
- : /* No clobbers */);
- return result;
-}
-
-__extension__ static __inline uint16x4_t __attribute__ ((__always_inline__))
-vpmax_u16 (uint16x4_t a, uint16x4_t b)
-{
- uint16x4_t result;
- __asm__ ("umaxp %0.4h, %1.4h, %2.4h"
- : "=w"(result)
- : "w"(a), "w"(b)
- : /* No clobbers */);
- return result;
-}
-
-__extension__ static __inline uint32x2_t __attribute__ ((__always_inline__))
-vpmax_u32 (uint32x2_t a, uint32x2_t b)
-{
- uint32x2_t result;
- __asm__ ("umaxp %0.2s, %1.2s, %2.2s"
- : "=w"(result)
- : "w"(a), "w"(b)
- : /* No clobbers */);
- return result;
-}
-
-__extension__ static __inline float32x2_t __attribute__ ((__always_inline__))
-vpmaxnm_f32 (float32x2_t a, float32x2_t b)
-{
- float32x2_t result;
- __asm__ ("fmaxnmp %0.2s,%1.2s,%2.2s"
- : "=w"(result)
- : "w"(a), "w"(b)
- : /* No clobbers */);
- return result;
-}
-
-__extension__ static __inline float32x4_t __attribute__ ((__always_inline__))
-vpmaxnmq_f32 (float32x4_t a, float32x4_t b)
-{
- float32x4_t result;
- __asm__ ("fmaxnmp %0.4s,%1.4s,%2.4s"
- : "=w"(result)
- : "w"(a), "w"(b)
- : /* No clobbers */);
- return result;
-}
-
-__extension__ static __inline float64x2_t __attribute__ ((__always_inline__))
-vpmaxnmq_f64 (float64x2_t a, float64x2_t b)
-{
- float64x2_t result;
- __asm__ ("fmaxnmp %0.2d,%1.2d,%2.2d"
- : "=w"(result)
- : "w"(a), "w"(b)
- : /* No clobbers */);
- return result;
-}
-
-__extension__ static __inline float64_t __attribute__ ((__always_inline__))
-vpmaxnmqd_f64 (float64x2_t a)
-{
- float64_t result;
- __asm__ ("fmaxnmp %d0,%1.2d"
- : "=w"(result)
- : "w"(a)
- : /* No clobbers */);
- return result;
-}
-
-__extension__ static __inline float32_t __attribute__ ((__always_inline__))
-vpma
Re: [PATCH 8/9] Negative numbers added for sreal class.
On Thu, Nov 27, 2014 at 6:08 PM, Martin Liška wrote:
> On 11/21/2014 04:21 PM, Martin Liška wrote:
>>
>> On 11/21/2014 04:02 PM, Richard Biener wrote:
>>>
>>> On Fri, Nov 21, 2014 at 3:39 PM, Martin Liška wrote:
>>>
Hello.
Ok, this is simplified, one can use sreal a = 12345 and it works ;)
> that's a new API, right? There is no max () and I think that using
> LONG_MIN here is asking for trouble (host dependence). The
> comment in the file says the max should be
> sreal (SREAL_MAX_SIG, SREAL_MAX_EXP) and the min
> sreal (-SREAL_MAX_SIG, SREAL_MAX_EXP)?
>
Sure, sreal can store much bigger(smaller) numbers :)
> Where do you need sreal::to_double? The host shouldn't perform
> double calculations so it can be only for dumping? In which case
> the user should have used sreal::dump (), maybe with extra
> arguments.
>
That new function was request from Honza, only for debugging purpose.
I agree that dump should this kind of job.
If no other problem, I will run tests once more and commit it.
Thanks,
Martin
>>>
>>>
>>> -#define SREAL_MAX_EXP (INT_MAX / 4)
>>> +#define SREAL_MAX_EXP (INT_MAX / 8)
>>>
>>> this change doesn't look necessary anymore?
>>>
>>> Btw, it's also odd that...
>>>
>>> #define SREAL_PART_BITS 32
>>> ...
>>> #define SREAL_MIN_SIG ((uint64_t) 1 << (SREAL_PART_BITS - 1))
>>> #define SREAL_MAX_SIG (((uint64_t) 1 << SREAL_PART_BITS) - 1)
>>>
>>> thus all m_sig values fit in 32bits but we still use a uint64_t m_sig ...
>>> (the implementation uses 64bit for internal computations, but still
>>> the storage is wasteful?)
>>>
>>> Of course the way normalize() works requires that storage to be
>>> 64bits to store unnormalized values.
>>>
>>> I'd say ok with the SREAL_MAX_EXP change reverted.
>>>
>>
>> Hi.
>>
>> You are right, this change was done because I used one bit for m_negative
>> (bitfield), not needed any more.
>>
>> Final version attached.
>>
>> Thank you,
>> Martin
>>
>>> Thanks,
>>> Richard.
>>>
>>>
> Otherwise looks good to me and sorry for not noticing the above
> earlier.
>
> Thanks,
> Richard.
>
>> Thanks,
>> Martin
>>
>>
};
extern void debug (sreal &ref);
@@ -76,12 +133,12 @@ inline sreal &operator+= (sreal &a, const sreal
&b)
inline sreal &operator-= (sreal &a, const sreal &b)
{
-return a = a - b;
+ return a = a - b;
}
inline sreal &operator/= (sreal &a, const sreal &b)
{
-return a = a / b;
+ return a = a / b;
}
inline sreal &operator*= (sreal &a, const sreal &b)
--
2.1.2
>>
>>
>
> Hello.
>
> After IRC discussions, I decided to give sreal another refactoring where I
> use int64_t for m_sig.
>
> This approach looks much easier and straightforward. I would like to
> ask folk for comments?
I think you want to exclude LONG_MIN (how do you know that LONG_MIN
is min(int64_t)?) as a valid value for m_sig - after all SREAL_MIN_SIG
makes it symmetric. Or simply use abs_hwi at
+ int64_t s = m_sig < 0 ? -1 : 1;
+ uint64_t sig = m_sig == LONG_MIN ? LONG_MAX : std::abs (m_sig);
-#define SREAL_MIN_SIG ((uint64_t) 1 << (SREAL_PART_BITS - 1))
-#define SREAL_MAX_SIG (((uint64_t) 1 << SREAL_PART_BITS) - 1)
+#define SREAL_MIN_SIG ((uint64_t) 1 << (SREAL_PART_BITS - 2))
+#define SREAL_MAX_SIG (((uint64_t) 1 << (SREAL_PART_BITS - 1)) - 1)
shouldn't this also be -2 in the last line?
That is, you effectively use the MSB as a sign bit?
Btw, a further change would be to make m_sig 'signed int', matching
the "real" storage requirements according to SREAL_PART_BITS.
This would of course still require temporaries used for computation
to be 64bits and it would require normalization to work on the
temporaries. But then we'd get down to 8 bytes storage ...
Richard.
> I am able to run profiled bootstrap on x86_64-linux-pc and ppc64-linux-pc
> and new regression is introduced.
>
> Thanks,
> Martin
>
>
[patch] small fixes for post-reload compare elimination pass
Hi,
this patch fixes a few glitches in the post-reload compare elimination pass,
most notably the slightly disturbing opening comment:
This pass assumes:
[...]
(1) All comparison patterns are represented as
[(set (reg:CC) (compare:CC (reg) (immediate)))]
the mode mismatch in before_dom_children:
rtx x, flags = gen_rtx_REG (src_mode, targetm.flags_regnum);
/* Generate new comparison for substitution. */
x = gen_rtx_COMPARE (new_mode, XEXP (src, 0), XEXP (src, 1));
x = gen_rtx_SET (VOIDmode, flags, x);
and the direct tests on flag_non_call_exceptions:
if (flag_non_call_exceptions)
eh_note = find_reg_note (insn, REG_EH_REGION, NULL);
[...]
/* Take care that it's in the same EH region. */
if (flag_non_call_exceptions
&& !rtx_equal_p (eh_note, last_cmp->eh_note))
goto dont_delete;
It also factors out the comparison logic in before_dom_children to avoid the
series of gotos.
Tested on a private port we're about to submit, OK for the mainline?
2014-11-28 Eric Botcazou
* compare-elim.c: Fix head comment.
(conforming_compare): Remove redundant test.
(can_eliminate_compare): New function extracted from...
(before_dom_children): ...here. Use it, replace direct uses of
flag_non_call_exceptions and tidy up.
(maybe_select_cc_mode): Tidy up.
--
Eric BotcazouIndex: compare-elim.c
===
--- compare-elim.c (revision 218133)
+++ compare-elim.c (working copy)
@@ -35,7 +35,7 @@ along with GCC; see the file COPYING3.
(1) All comparison patterns are represented as
- [(set (reg:CC) (compare:CC (reg) (immediate)))]
+ [(set (reg:CC) (compare:CC (reg) (reg_or_immediate)))]
(2) All insn patterns that modify the flags are represented as
@@ -157,7 +157,6 @@ conforming_compare (rtx_insn *insn)
return NULL;
if (REG_P (XEXP (src, 0))
- && REG_P (XEXP (src, 0))
&& (REG_P (XEXP (src, 1)) || CONSTANT_P (XEXP (src, 1
return src;
@@ -266,6 +265,45 @@ public:
virtual void before_dom_children (basic_block);
};
+/* Return true if conforming COMPARE with EH_NOTE is redundant with comparison
+ CMP and can thus be eliminated. */
+
+static bool
+can_eliminate_compare (rtx compare, rtx eh_note, struct comparison *cmp)
+{
+ /* Take care that it's in the same EH region. */
+ if (cfun->can_throw_non_call_exceptions
+ && !rtx_equal_p (eh_note, cmp->eh_note))
+return false;
+
+ /* Make sure the compare is redundant with the previous. */
+ if (!rtx_equal_p (XEXP (compare, 0), cmp->in_a)
+ || !rtx_equal_p (XEXP (compare, 1), cmp->in_b))
+return false;
+
+ /* New mode must be compatible with the previous compare mode. */
+ enum machine_mode new_mode
+= targetm.cc_modes_compatible (GET_MODE (compare), cmp->orig_mode);
+
+ if (new_mode == VOIDmode)
+return false;
+
+ if (cmp->orig_mode != new_mode)
+{
+ /* Generate new comparison for substitution. */
+ rtx flags = gen_rtx_REG (new_mode, targetm.flags_regnum);
+ rtx x = gen_rtx_COMPARE (new_mode, cmp->in_a, cmp->in_b);
+ x = gen_rtx_SET (VOIDmode, flags, x);
+
+ if (!validate_change (cmp->insn, &PATTERN (cmp->insn), x, false))
+ return false;
+
+ cmp->orig_mode = new_mode;
+}
+
+ return true;
+}
+
/* Identify comparison instructions within BB. If the flags from the last
compare in the BB is live at the end of the block, install the compare
in BB->AUX. Called via dom_walker.walk (). */
@@ -317,62 +355,26 @@ find_comparison_dom_walker::before_dom_c
src = conforming_compare (insn);
if (src)
{
- machine_mode src_mode = GET_MODE (src);
rtx eh_note = NULL;
- if (flag_non_call_exceptions)
+ if (cfun->can_throw_non_call_exceptions)
eh_note = find_reg_note (insn, REG_EH_REGION, NULL);
- if (!last_cmp_valid)
- goto dont_delete;
-
- /* Take care that it's in the same EH region. */
- if (flag_non_call_exceptions
- && !rtx_equal_p (eh_note, last_cmp->eh_note))
- goto dont_delete;
-
- /* Make sure the compare is redundant with the previous. */
- if (!rtx_equal_p (last_cmp->in_a, XEXP (src, 0))
- || !rtx_equal_p (last_cmp->in_b, XEXP (src, 1)))
- goto dont_delete;
-
- /* New mode must be compatible with the previous compare mode. */
- {
- machine_mode new_mode
- = targetm.cc_modes_compatible (last_cmp->orig_mode, src_mode);
- if (new_mode == VOIDmode)
- goto dont_delete;
-
- if (new_mode != last_cmp->orig_mode)
- {
- rtx x, flags = gen_rtx_REG (src_mode, targetm.flags_regnum);
-
- /* Generate new comparison for substitution. */
- x = gen_rtx_COMPARE (new_mode, XEXP (src, 0), XEXP (src, 1));
- x = gen_rtx_SET (VOIDmode, flags, x);
-
- if (!validate_change (last_cmp->insn,
- &PATTERN (la
Re: [PATCH] Fix regressions in libgomp testsuite: set flag_fat_lto_objects for offload
On Fri, Nov 28, 2014 at 12:45 AM, Ilya Verbin wrote:
> On 27 Nov 16:00, Richard Biener wrote:
>> On Thu, Nov 27, 2014 at 2:31 PM, Ilya Verbin wrote:
>> > On 25 Nov 10:51, Richard Biener wrote:
>> >> In the patch adding flag_generate_offload sounds like a good solution,
>> >> I didn't like emitting fat LTO objects unconditionally just because we
>> >> offload.
>> >
>> > Here is updated patch. Bootstrap and make check passed on i686-linux and
>> > x86_64-linux. Tests with offloading also passed with trunk binutils.
>> > OK for trunk?
>>
>> If it also works without the new __gnu_offload symbol then I'd prefer
>> to re-use __gnu_LTO here.
>>
>> Ok with that change.
>
> Do you mean a patch like this? Yes, it also works.
> Bootstrap and make check passed. OK?
Yes - thanks.
Richard.
> -- Ilya
>
>
> gcc/
> * cgraphunit.c (ipa_passes): Handle flag_generate_offload.
> (symbol_table::compile): Set flag_generate_offload if there is
> something
> to offload.
> * common.opt (flag_generate_offload): New Variable declaration.
> * dwarf2out.c (dwarf2out_finish): Handle flag_generate_offload.
> * ipa-inline-analysis.c (inline_generate_summary): Do not skip if
> flag_generate_offload is set.
> * lto-streamer.c (gate_lto_out): Handle flag_generate_offload.
> * passes.c (ipa_write_summaries): Do not skip if flag_generate_offload
> is set.
> * toplev.c (compile_file): Emit LTO marker if offload info has been
> previously emitted. Do not emit lto_slim marker if
> flag_generate_offload is without flag_generate_lto.
> * tree.c (free_lang_data): Do not skip if flag_generate_offload is
> set.
>
>
> diff --git a/gcc/cgraphunit.c b/gcc/cgraphunit.c
> index 2fd99a7..fed1a3e 100644
> --- a/gcc/cgraphunit.c
> +++ b/gcc/cgraphunit.c
> @@ -2075,7 +2075,7 @@ ipa_passes (void)
> }
>
>/* Some targets need to handle LTO assembler output specially. */
> - if (flag_generate_lto)
> + if (flag_generate_lto || flag_generate_offload)
> targetm.asm_out.lto_start ();
>
>if (!in_lto_p)
> @@ -2092,7 +2092,7 @@ ipa_passes (void)
> }
> }
>
> - if (flag_generate_lto)
> + if (flag_generate_lto || flag_generate_offload)
> targetm.asm_out.lto_end ();
>
>if (!flag_ltrans && (in_lto_p || !flag_lto || flag_fat_lto_objects))
> @@ -2176,10 +2176,10 @@ symbol_table::compile (void)
>
>/* Offloading requires LTO infrastructure. */
>if (!in_lto_p && g->have_offload)
> -flag_generate_lto = 1;
> +flag_generate_offload = 1;
>
>/* If LTO is enabled, initialize the streamer hooks needed by GIMPLE. */
> - if (flag_generate_lto)
> + if (flag_generate_lto || flag_generate_offload)
> lto_streamer_hooks_init ();
>
>/* Don't run the IPA passes if there was any error or sorry messages. */
> diff --git a/gcc/common.opt b/gcc/common.opt
> index 41c8d4e..752d939 100644
> --- a/gcc/common.opt
> +++ b/gcc/common.opt
> @@ -67,6 +67,10 @@ int *param_values
> Variable
> int flag_generate_lto
>
> +; Nonzero if we should write GIMPLE bytecode for offload compilation.
> +Variable
> +int flag_generate_offload = 0
> +
> ; True to warn about any objects definitions whose size is larger
> ; than N bytes. Also want about function definitions whose returned
> ; values are larger than N bytes, where N is 'larger_than_size'.
> diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
> index 25f0e7d..4ee3102 100644
> --- a/gcc/dwarf2out.c
> +++ b/gcc/dwarf2out.c
> @@ -24420,7 +24420,8 @@ dwarf2out_finish (const char *filename)
>/* When generating LTO bytecode we can not generate new assembler
> names at this point and all important decls got theirs via
> free-lang-data. */
> - if ((!flag_generate_lto || DECL_ASSEMBLER_NAME_SET_P (decl))
> + if (((!flag_generate_lto && !flag_generate_offload)
> + || DECL_ASSEMBLER_NAME_SET_P (decl))
> && DECL_ASSEMBLER_NAME (decl) != DECL_NAME (decl))
> {
> add_linkage_attr (node->die, decl);
> diff --git a/gcc/ipa-inline-analysis.c b/gcc/ipa-inline-analysis.c
> index 2f2993c..9d62722 100644
> --- a/gcc/ipa-inline-analysis.c
> +++ b/gcc/ipa-inline-analysis.c
> @@ -4031,7 +4031,7 @@ inline_generate_summary (void)
>
>/* When not optimizing, do not bother to analyze. Inlining is still done
> because edge redirection needs to happen there. */
> - if (!optimize && !flag_generate_lto && !flag_wpa)
> + if (!optimize && !flag_generate_lto && !flag_generate_offload && !flag_wpa)
> return;
>
>function_insertion_hook_holder =
> diff --git a/gcc/lto-streamer.c b/gcc/lto-streamer.c
> index e8347dc..af20330 100644
> --- a/gcc/lto-streamer.c
> +++ b/gcc/lto-streamer.c
> @@ -328,7 +328,7 @@ lto_streamer_init (void)
> bool
> gate_lto_out (void)
> {
> - return ((flag_generate_lto || in_lto_p)
> + return ((flag_generate_lto || flag_generate_offload || in_lto_p)
> /* Don't both
Re: [PATCH][ARM] Add Cortex-A17 support
On 27/11/14 23:53, Gerald Pfeifer wrote: On Thursday 2014-11-27 11:09, Kyrill Tkachov wrote: Thanks for the review. The invoke.texi changes were posted and approved at https://gcc.gnu.org/ml/gcc-patches/2014-11/msg02683.html and I'm attaching the proposed changes.html patch. Looks good. Note that once you have "has been added" and once "was added". Looking at the current changes.html I see "has been added" appears 13 times in contrast to "was added", which appears only once. So I'll use has been added to keep consistent. Thanks, Kyrill I _think_ the former may be more appropriate, but let's one of our native speakers comment in case. Gerald
Re: [RFC diagnostics/fortran] Move gfc_warning (buffered) to the common diagnostics machinery
Tobias Burnus wrote: > Actually, I wonder whether that can lead to printing an error message > multiple times. This already occurs, see pr44978. Dominique
[RFC] Wrong "current" pointers with bitmap_ior and bitmap_ior_and_compl
Hi,
I've got odd ICEs with some bitmap operations when working on
sh-lra branch.
bitmap_ior and bitmap_ior_and_compl are the bitmap operations
for DST = A | B and DST = A | (B & ~KILL) respectively. It
looks they could make bitmaps with the wrong "current" pointer.
One small example is
DST: [(bit 0, bit 127), indx=0] <-> [(bit 151), indx=1] -> 0
A: [(bit 141), indx=1] -> 0
B: [(bit 142), indx=1] -> 0
where assuming that BITMAP_ELEMENT_ALL_BITS is 128.
In this case, bitmap_ior makes DST into the list
[(bit 141, bit 142), indx=1] <-> [(bit 151), indx=1] -> 0
and unlinks the second element with bitmap_elt_clear_from.
If the "current" pointer of DST pointed the 2nd element,
the current pointer points the element freed from the list:
DST: [(bit 141, bit 142), indx=1] -> 0
DST->current: [(bit 151), indx=1]
even after bitmap_elt_clear_from done.
bitmap_elt_clear_from has the code to fix the current pointer
for the correct list of which elements have strictly ascending
indx values. It doesn't work for the above list because its
elements have the same indx.
It seems that bitmap_and, bitmap_and_compl and bitmap_xor have
the line to avoid this issue already. The patch below adds
the same line to bitmap_ior and bitmap_ior_and_compl.
The patch is tested on i686-pc-linux-gnu with bootstrap and
the top level "make -k check".
Regards,
kaz
--
* bitmap.c (bitmap_ior): Reset the current pointer before calling
bitmap_elt_clear_from.
(bitmap_ior_and_compl): Likewise.
diff --git a/bitmap.c b/bitmap.c
index 8f7f306..ace6aea 100644
--- a/bitmap.c
+++ b/bitmap.c
@@ -1595,6 +1595,8 @@ bitmap_ior (bitmap dst, const_bitmap a, const_bitmap b)
if (dst_elt)
{
changed = true;
+ /* Ensure that dst->current is valid. */
+ dst->current = dst->first;
bitmap_elt_clear_from (dst, dst_elt);
}
gcc_checking_assert (!dst->current == !dst->first);
@@ -1951,6 +1953,8 @@ bitmap_ior_and_compl (bitmap dst, const_bitmap a,
const_bitmap b, const_bitmap k
if (dst_elt)
{
changed = true;
+ /* Ensure that dst->current is valid. */
+ dst->current = dst->first;
bitmap_elt_clear_from (dst, dst_elt);
}
gcc_checking_assert (!dst->current == !dst->first);
Re: PR 13631 Problems in messages
On 27/11/14 23:19 +0100, François Dumont wrote:
Hi
Here is a revisited version. I finally go without compiling in
C++11 as I prefer to use __builtin_alloca instead of using
std::unique_ptr and heap memory. I also realized that I could use
codecvt::max_length to know the max number of multibytes.
Tested under Linux x86_64 with all locales installed. There are
some failures but not coming from this patch, will surely be the
subject of another mail.
2014-11-28 François Dumont
DR libstdc++/13631
* include/bits/codecvt.h (__get_c_locale): New.
* config/locale/gnu/messages_member.h, messages_member.cc: Prefer
dgettext usage to gettext to allow usage of several catalogs at the
same time. Add an internal cache to make catalog names to catalog ids.
s/make/map/
Add charset management.
* testsuite/22_locale/messages/13631.cc: New.
* testsuite/22_locale/messages/members/char/2.cc: Use also fr_FR locale
for charset conversion to get the expected accentuated character.
"accented"
Do we need any abi tag ? Do we need to wait ?
I'll be posting my patch today, with ABI changes to the existing facets.
I'm not sure if this needs to be tagged though, you haven't added any
members or virtual functions to std::messages. The previously inline
functions were exported from the library already, because
messages and messages are explicitly instantiated.
I think with a few adjustments this can safely be applied to trunk
soon.
Index: config/locale/gnu/messages_members.cc
===
--- config/locale/gnu/messages_members.cc (revision 218027)
+++ config/locale/gnu/messages_members.cc (working copy)
@@ -31,54 +31,272 @@
#include
#include
+#include
+#include
+
+#include
+
+namespace
+{
+ using namespace std;
+
+ class Catalogs
+ {
+ public:
+typedef messages_base::catalog catalog_id;
+
+struct catalog_info
+{
+ catalog_info()
+ { }
+
+ catalog_info(catalog_id __id, const char* __domain, locale __loc)
+ : _M_id(__id), _M_domain(__domain), _M_locale(__loc)
+ { }
+
I don't really like that this type doesn't own _M_domain and it has to
be freed by Catalog, but without a move constructor (which requires
C++11) it would be awkward to set _M_domain=0 after copy constructing
a new catalog_info.
So it's OK like this.
+ catalog_id _M_id;
+ const char* _M_domain;
+ locale _M_locale;
+};
+
+typedef pair result_type;
+
+Catalogs() : _M_counter(0), _M_nb_entry(0) { }
+
+~Catalogs()
+{
+ if (_M_nb_entry)
+ {
+ for (size_t i = 0; i != _M_nb_entry; ++i)
+ delete[] _M_map[i]._M_domain;
+ delete[] _M_map;
+ }
+}
+
+catalog_id
+_M_add(const string& __domain, locale __l)
+{
+ __gnu_cxx::__scoped_lock lock(_M_mutex);
+
+ catalog_info* __new_map = new catalog_info[_M_nb_entry + 1];
I wonder if we should grow this array by more than one element at a
time.
+ __try
+ {
+ copy(_M_map, _M_map + _M_nb_entry, __new_map);
+ char* __domain_copy = new char[__domain.size() + 1];
+ __domain.copy(__domain_copy, __domain.size());
+ __domain_copy[__domain.size()] = 0;
+ __new_map[_M_nb_entry] = catalog_info(_M_counter, __domain_copy, __l);
+ }
+ __catch(...)
+ {
+ delete[] __new_map;
+ __throw_exception_again;
+ }
+
+ // The counter is not likely to roll unless catalogs keep on being
+ // open/close which is consider as an application mistake for the moment.
"opened/closed which is considered"
I think it's fine to say you can't have more than 2^31 open message
catalogs, but we should for numeric_limits::max() before
doing anything and return -1 to say it couldn't be opened.
+ catalog_id __cat = _M_counter++;
+ delete[] _M_map;
+ _M_map = __new_map;
+ ++_M_nb_entry;
+
+ return __cat;
+}
+
+void
+_M_erase(catalog_id __c)
+{
+ __gnu_cxx::__scoped_lock lock(_M_mutex);
+
+ catalog_info* __entry =
+ lower_bound(_M_map, _M_map + _M_nb_entry, __c, _Comp());
+ if (__entry == _M_map + _M_nb_entry || __entry->_M_id != __c)
+ return;
+
+ catalog_info* __new_map =
+ _M_nb_entry > 1 ? new catalog_info[_M_nb_entry - 1] : 0;
Is it really necessary to shrink the map again?
I would expect that opening and closing several message catalogs in
succession would not need to keep reallocating the map.
You're also creating, copying and destroying std::locale objects every
time you reallocate the map, which generates a small storm of atomic
operations on the reference counts for the locales.
One option would be to create an array of char and fill it with
std::copy_uninitialized instead of std::copy. Or just use std::vector.
+ copy(__entry + 1, _M_map + _M_nb_entry,
+ copy(_M_map, __entry, __new_map));
+
+
[patch testsuite gcc.dg]: Turn of ms-extensions for mingw target
Hi,
this patch turns off ms-extensions for mingw-targets to match
diagnostics checked in testcases.
Ok for apply?
Kai
ChangeLog
2014-11-28 Kai Tietz
* gcc.dg/anon-struct-1.c:
* gcc.dg/anon-struct-11.c:
* gcc.dg/anon-struct-2.c:
* gcc.dg/c11-anon-struct-2.c:
* gcc.dg/c11-anon-struct-3.c:
Index: gcc.dg/anon-struct-1.c
===
--- gcc.dg/anon-struct-1.c(Revision 218142)
+++ gcc.dg/anon-struct-1.c(Arbeitskopie)
@@ -1,4 +1,5 @@
/* { dg-options "-std=iso9899:1990 -pedantic" } */
+/* { dg-additional-options "-fno-ms-extensions" { target *-*-mingw* } } */
/* In strict ISO C mode, we don't recognize the anonymous struct/union
extension or any Microsoft extensions. */
Index: gcc.dg/anon-struct-11.c
===
--- gcc.dg/anon-struct-11.c(Revision 218142)
+++ gcc.dg/anon-struct-11.c(Arbeitskopie)
@@ -3,6 +3,7 @@
/* No special options--in particular, turn off the default
-pedantic-errors option. */
/* { dg-options "" } */
+/* { dg-additional-options "-fno-ms-extensions" { target *-*-mingw* } } */
/* When not using -fplan9-extensions, we don't support automatic
conversion of pointer types, and we don't support referring to a
Index: gcc.dg/anon-struct-2.c
===
--- gcc.dg/anon-struct-2.c(Revision 218142)
+++ gcc.dg/anon-struct-2.c(Arbeitskopie)
@@ -1,4 +1,5 @@
/* { dg-options "-std=gnu89" } */
+/* { dg-additional-options "-fno-ms-extensions" { target *-*-mingw* } } */
/* In GNU C mode, we recognize the anonymous struct/union extension,
but not Microsoft extensions. */
Index: gcc.dg/c11-anon-struct-2.c
===
--- gcc.dg/c11-anon-struct-2.c(Revision 218142)
+++ gcc.dg/c11-anon-struct-2.c(Arbeitskopie)
@@ -2,6 +2,7 @@
cases. */
/* { dg-do compile } */
/* { dg-options "-std=c11 -pedantic-errors" } */
+/* { dg-additional-options "-fno-ms-extensions" { target *-*-mingw* } } */
typedef struct s0
{
Index: gcc.dg/c11-anon-struct-3.c
===
--- gcc.dg/c11-anon-struct-3.c(Revision 218142)
+++ gcc.dg/c11-anon-struct-3.c(Arbeitskopie)
@@ -2,6 +2,7 @@
cases: typedefs disallowed by N1549. */
/* { dg-do compile } */
/* { dg-options "-std=c11 -pedantic-errors" } */
+/* { dg-additional-options "-fno-ms-extensions" { target *-*-mingw* } } */
typedef struct
{
Re: PR 13631 Problems in messages
On 28/11/14 10:49 +, Jonathan Wakely wrote: I think it's fine to say you can't have more than 2^31 open message catalogs, but we should for numeric_limits::max() before ... but we should *check* for ... doing anything and return -1 to say it couldn't be opened.
[patch testsuite g++]: Fixes for mingw-targets
Hi, this patch fixes for mingw-targets some LP assumptions, adjusts for some testcases that ms-extensions is turned off for diagnostics, and turns on pedantic for some testcase to match expected diagnostics. Ok for apply? Kai ChangeLog 2014-11-28 Kai Tietz * g++.dg/abi/mangle13.C: Disable ms-extensions for mingw-targets. * g++.dg/abi/mangle15.C: Likewise. * g++.dg/cpp0x/access02.C: Likewise. * g++.dg/cpp0x/auto20.C: Likewise. * g++.dg/cpp0x/decltype31.C: Likewise. * g++.dg/cpp0x/decltype50.C: Likewise. * g++.dg/cpp0x/lambda/lambda-eh2.C: Likewise. * g++.dg/cpp0x/lambda/lambda-this11.C: Likewise. * g++.dg/cpp0x/ref-qual10.C: Likewise. * g++.dg/cpp0x/sfinae50.C: Likewise. * g++.dg/cpp0x/static_assert9.C: Likewise. * g++.dg/cpp0x/variadic159.C: Likewise. * g++.dg/cpp0x/vt-55542.C: Likewise. * g++.dg/dfp/mangle-1.C: Likewise. * g++.dg/dfp/mangle-2.C: Likewise. * g++.dg/expr/bound-mem-fun.C: Likewise. * g++.dg/expr/pmf-1.C: Likewise. * g++.dg/expr/ptrmem5.C: Likewise. * g++.dg/ext/uow-3.C: Likewise. * g++.dg/ext/uow-4.C: Likewise. * g++.dg/init/ptrmem3.C: Likewise. * g++.dg/lookup/anon7.C: Likewise. * g++.dg/lookup/name-clash7.C: Likewise. * g++.dg/lookup/redecl1.C: Likewise. * g++.dg/opt/pmf1.C: Likewise. * g++.dg/other/error24.C: Likewise. * g++.dg/other/error34.C: Likewise. * g++.dg/other/i386-1.C: Likewise. * g++.dg/other/pr34435.C: Likewise. * g++.dg/other/ptrmem8.C: Likewise. * g++.dg/overload/pmf2.C: Likewise. * g++.dg/parse/error43.C: Likewise. * g++.dg/parse/error45.C: Likewise. * g++.dg/parse/template5.C: Likewise. * g++.dg/pr54442.C: Likewise. * g++.dg/rtti/typeid8.C: Likewise. * g++.dg/template/access28.C: Likewise. * g++.dg/template/anonunion1.C: Likewise. * g++.dg/template/conv1.C: Likewise. * g++.dg/template/crash106.C: Likewise. * g++.dg/template/crash112.C: Likewise. * g++.dg/template/crash37.C: Likewise. * g++.dg/template/crash51.C: Likewise. * g++.dg/template/crash72.C: Likewise. * g++.dg/template/dependent-args1.C: Likewise. * g++.dg/template/dependent-expr5.C: Likewise. * g++.dg/template/dtor6.C: Likewise. * g++.dg/template/non-dependent11.C: Likewise. * g++.dg/template/non-dependent9.C: Likewise. * g++.dg/template/overload10.C: Likewise. * g++.dg/template/overload5.C: Likewise. * g++.dg/template/overload6.C: Likewise. * g++.dg/template/ptrmem20.C: Likewise. * g++.dg/template/ptrmem3.C: Likewise. * g++.dg/template/ptrmem5.C: Likewise. * g++.dg/template/ptrmem8.C: Likewise. * g++.dg/template/sfinae26.C: Likewise. * g++.dg/template/template-id-4.C: Likewise. * g++.dg/torture/pr58252.C: Likewise. * g++.dg/torture/pr58555.C: Likewise. * g++.dg/warn/changes-meaning.C: Likewise. * g++.dg/warn/multiple-overflow-warn-1.C: Likewise. * g++.dg/warn/multiple-overflow-warn-3.C: Likewise. * g++.dg/warn/overflow-warn-1.C: Likewise. * g++.dg/warn/overflow-warn-3.C: Likewise. * g++.dg/warn/pmf1.C: Likewise. * g++.dg/warn/skip-1.C: Likewise. * g++.dg/warn/skip-2.C: Likewise. * g++.old-deja/g++.brendan/operators4.C: Likewise. * g++.old-deja/g++.brendan/prepost1.C: Likewise. * g++.old-deja/g++.brendan/ptrmem4.C: Likewise. * g++.old-deja/g++.bugs/900213_03.C: Likewise. * g++.old-deja/g++.bugs/900220_01.C: Likewise. * g++.old-deja/g++.jason/member.C: Likewise. * g++.old-deja/g++.jason/pmf2.C: Likewise. * g++.old-deja/g++.jason/pmf5.C: Likewise. * g++.old-deja/g++.jason/pmf6.C: Likewise. * g++.old-deja/g++.jason/scoping8.C: Likewise. * g++.old-deja/g++.jason/synth7.C: Likewise. * g++.old-deja/g++.jason/typeid1.C: Likewise. * g++.old-deja/g++.law/arm16.C: Likewise. * g++.old-deja/g++.law/operators9.C: Likewise. * g++.old-deja/g++.mike/net31.C: Likewise. * g++.old-deja/g++.mike/net36.C: Likewise. * g++.old-deja/g++.mike/p0.C: Likewise. * g++.old-deja/g++.mike/p646.C: Likewise. * g++.old-deja/g++.mike/pmf3.C: Likewise. * g++.old-deja/g++.oliva/overload1.C: Likewise. * g++.old-deja/g++.other/decl6.C: Likewise. * g++.old-deja/g++.other/lookup4.C: Likewise. * g++.old-deja/g++.other/overload1.C: Likewise. * g++.old-deja/g++.other/overload8.C: Likewise. * g++.old-deja/g++.other/pmf2.C: Likewise. * g++.old-deja/g++.other/pmf3.C: Likewise. * g++.old-deja/g++.other/pmf7.C: Likewise. * g++.old-deja/g++.other/ptrmem7.C: Likewise. * g++.old-deja/g++.pt/crash18.C: Likewise. * g++.old-deja/g++.pt/crash57.C: Likewise. * g++.old-deja/g++.pt/memtemp94.C: Likewise. * g++.old-deja/g++.pt/overload10.C: Likewise. * g++.old-deja/g++.pt/ptrmem1.C: Likewise. * g++.old-deja/g++.pt/ptrmem10.C: Likewise. * g++.old-deja/g++.pt/ptrmem4.C: Likewise. * g++.old-deja/g++.robertl/eb131.C: Likewise. * g++.old-deja/g++.ro
[patch g++.dg]: Disable some weak-tests for mingw-targets
Hi,
this patch skips some test, which are trying to test non-existing
weak-variant for mingw-targets.
ChangeLog
2014-11-28 Kai Tietz
* g++.dg/abi/anon2.C: Skip for mingw targets.
* g++.dg/abi/anon3.C: Likewise.
* g++.dg/abi/thunk5.C: Likewise.
* g++.dg/abi/rtti1.C: Likewise.
Ok for apply?
Regards,
Kai
Index: g++.dg/abi/anon2.C
===
--- g++.dg/abi/anon2.C(Revision 218142)
+++ g++.dg/abi/anon2.C(Arbeitskopie)
@@ -1,5 +1,6 @@
// PR c++/55877
// { dg-require-weak "" }
+// { dg-skip-if "requires unsupported weak in pe-coff" { *-*-mingw* } }
namespace N1 {
typedef struct {
Index: g++.dg/abi/rtti1.C
===
--- g++.dg/abi/rtti1.C(Revision 218142)
+++ g++.dg/abi/rtti1.C(Arbeitskopie)
@@ -1,3 +1,4 @@
+// { dg-skip-if "unsupported for pe-coff" { *-*-mingw* } }
// Test that we don't emit the type_info for a polymorphic class other than
// with the vtable.
Index: g++.dg/abi/thunk5.C
===
--- g++.dg/abi/thunk5.C(Revision 218142)
+++ g++.dg/abi/thunk5.C(Arbeitskopie)
@@ -1,6 +1,7 @@
// PR c++/35067
// The thunks should be weak even on targets without one-only support.
// { dg-require-weak "" }
+// { dg-skip-if "requires unsupported weak in pe-coff" { *-*-mingw* } }
// { dg-final { scan-assembler "weak.*ZTv" } }
struct A
Index: g++.dg/abi/anon3.C
===
--- g++.dg/abi/anon3.C(Revision 218142)
+++ g++.dg/abi/anon3.C(Arbeitskopie)
@@ -1,4 +1,5 @@
// { dg-require-weak "" }
+// { dg-skip-if "requires unsupported weak in pe-coff" { *-*-mingw* } }
typedef struct {
// { dg-final { scan-assembler ".weak\(_definition\)?\[
\t\]_?_ZN4Heya4blahEv" } }
Re: [patch testsuite gcc.dg]: Turn of ms-extensions for mingw target
Hi Kai, > 2014-11-28 Kai Tietz > > * gcc.dg/anon-struct-1.c: > * gcc.dg/anon-struct-11.c: > * gcc.dg/anon-struct-2.c: > * gcc.dg/c11-anon-struct-2.c: > * gcc.dg/c11-anon-struct-3.c: those are not exactly useful ChangeLog entries ;-) Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [patch testsuite g++]: Fixes for mingw-targets
Hi Kai, > 2014-11-28 Kai Tietz > > * g++.dg/abi/mangle13.C: Disable > ms-extensions for mingw-targets. just a nit: why break this line way before 72/80 charackters? Several more of those useless linebreaks below. And no dash in mingw targets; better yet use *-*-mingw* instead of paraphrasing the affected targets. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [patch g++.dg]: Disable some weak-tests for mingw-targets
Hi Kai, > this patch skips some test, which are trying to test non-existing > weak-variant for mingw-targets. why is this necessary when most (all?) of those tests already have dg-require-weak? If there's some property of weak variables that PE-COFF lacks, I'd rather have a new effective-target keyword that tests for this. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [Bug target/63661] [4.9/5 Regression] -O2 miscompiles with -mtune=nehalem or corei7
On Fri, Nov 28, 2014 at 11:19:18AM +, renlin at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63661 > > --- Comment #25 from renlin at gcc dot gnu.org --- > Author: renlin > Date: Fri Nov 28 11:18:47 2014 > New Revision: 218144 > > URL: https://gcc.gnu.org/viewcvs?rev=218144&root=gcc&view=rev > Log: > Use native tune. nehalem is not able to triggle the issue in trunk any more. > > 2014-11-28 Renlin Li > > PR target/63661 > * gcc.target/i386/pr63661.c: Use native tune. > > Modified: > trunk/gcc/testsuite/ChangeLog > trunk/gcc/testsuite/gcc.target/i386/pr63661.c This is wrong. That will mean the test will do something different for different testers. If it reproduces for you with -mtune=native, just find out what that -mtune=native is for you (use -v) and try the specific option instead. Jakub
Re: [PATCH][PR63661]Add a test case for trunk.
On 28/11/14 09:20, Richard Biener wrote: On Thu, Nov 27, 2014 at 5:32 PM, Renlin Li wrote: Hi all, PR63661 is effectively fixed by my previous patch here: https://gcc.gnu.org/ml/gcc-patches/2014-11/msg02253.html This patch add a test case for it. Okay for trunk? Ok. Thanks, RIchard. gcc/testsuite/ChangeLog: 2014-11-27 Renlin Li PR target/63661 * gcc.target/i386/pr63661.c: New. Committed with minor change. Use native tune. nehalem is not able to trigger the issue in trunk any more. Sorry for the noise. Regards, Renlin
Re: [PATCH] Extend shift permutations on power of 2 cases
Hi,
After fixing PR60451 (pack scheme instead of pshufb) general power of
2 permutations become more profitable.
So I'd like to revert the changes keeping algorithm live or implement
new hook to use best algorithm/size for particular -mtune.
Below is reverting patch. Bootstrap and make check passed.
Is it ok?
2014-11-28 Evgeny Stupachenko
gcc/testsuite
* gcc.target/i386/pr52252-atom-1.c: Delete.
gcc/
* tree-vect-data-refs.c (vect_transform_grouped_load): Limit shift
permutations to loads group of size 3.
diff --git a/gcc/testsuite/gcc.target/i386/pr52252-atom-1.c
b/gcc/testsuite/gcc.target/i386/pr52252-atom-1.c
deleted file mode 100644
index 020e983..000
--- a/gcc/testsuite/gcc.target/i386/pr52252-atom-1.c
+++ /dev/null
@@ -1,22 +0,0 @@
-/* { dg-do compile } */
-/* { dg-require-effective-target ssse3 } */
-/* { dg-options "-O2 -ftree-vectorize -mssse3 -mtune=slm" } */
-#define byte unsigned char
-
-void
-pair_mul_sum(byte *in, byte *out, int size)
-{
- int j;
- for(j = 0; j < size; j++)
-{
- byte a = in[0];
- byte b = in[1];
- byte c = in[2];
- byte d = in[3];
- out[0] = (byte)(a * b) + (byte)(b * c) + (byte)(c * d) + (byte)(d * a);
- in += 4;
- out += 1;
-}
-}
-
-/* { dg-final { scan-assembler "perm2i128|palignr" } } */
diff --git a/gcc/tree-vect-data-refs.c b/gcc/tree-vect-data-refs.c
index 35d0e0f..8451bda 100644
--- a/gcc/tree-vect-data-refs.c
+++ b/gcc/tree-vect-data-refs.c
@@ -5617,6 +5617,7 @@ vect_transform_grouped_load (gimple stmt,
vec dr_chain, int size,
get chain for loads group using vect_shift_permute_load_chain. */
mode = TYPE_MODE (STMT_VINFO_VECTYPE (vinfo_for_stmt (stmt)));
if (targetm.sched.reassociation_width (VEC_PERM_EXPR, mode) > 1
+ || exact_log2 (size) != -1
|| !vect_shift_permute_load_chain (dr_chain, size, stmt,
gsi, &result_chain))
vect_permute_load_chain (dr_chain, size, stmt, gsi, &result_chain);
On Wed, Nov 12, 2014 at 4:16 PM, Uros Bizjak wrote:
> On Wed, Nov 12, 2014 at 2:15 PM, Evgeny Stupachenko
> wrote:
>> To avoid misunderstanding.
>> I haven't yet committed this obvious fix.
>> Is it ok?
>
> If it is obvious, then it doesn't need an approval.
>
> So, OK.
>
> Thanks,
> Uros.
Re: [RFC] Wrong "current" pointers with bitmap_ior and bitmap_ior_and_compl
On Fri, Nov 28, 2014 at 11:37 AM, Kaz Kojima wrote:
> Hi,
>
> I've got odd ICEs with some bitmap operations when working on
> sh-lra branch.
> bitmap_ior and bitmap_ior_and_compl are the bitmap operations
> for DST = A | B and DST = A | (B & ~KILL) respectively. It
> looks they could make bitmaps with the wrong "current" pointer.
> One small example is
>
> DST: [(bit 0, bit 127), indx=0] <-> [(bit 151), indx=1] -> 0
> A: [(bit 141), indx=1] -> 0
> B: [(bit 142), indx=1] -> 0
>
> where assuming that BITMAP_ELEMENT_ALL_BITS is 128.
> In this case, bitmap_ior makes DST into the list
>
> [(bit 141, bit 142), indx=1] <-> [(bit 151), indx=1] -> 0
>
> and unlinks the second element with bitmap_elt_clear_from.
> If the "current" pointer of DST pointed the 2nd element,
> the current pointer points the element freed from the list:
>
> DST: [(bit 141, bit 142), indx=1] -> 0
> DST->current: [(bit 151), indx=1]
>
> even after bitmap_elt_clear_from done.
> bitmap_elt_clear_from has the code to fix the current pointer
> for the correct list of which elements have strictly ascending
> indx values. It doesn't work for the above list because its
> elements have the same indx.
> It seems that bitmap_and, bitmap_and_compl and bitmap_xor have
> the line to avoid this issue already. The patch below adds
> the same line to bitmap_ior and bitmap_ior_and_compl.
> The patch is tested on i686-pc-linux-gnu with bootstrap and
> the top level "make -k check".
Huh? Wasn't this fixed by Mike a few weeks ago?
Richard.
> Regards,
> kaz
> --
> * bitmap.c (bitmap_ior): Reset the current pointer before calling
> bitmap_elt_clear_from.
> (bitmap_ior_and_compl): Likewise.
>
> diff --git a/bitmap.c b/bitmap.c
> index 8f7f306..ace6aea 100644
> --- a/bitmap.c
> +++ b/bitmap.c
> @@ -1595,6 +1595,8 @@ bitmap_ior (bitmap dst, const_bitmap a, const_bitmap b)
>if (dst_elt)
> {
>changed = true;
> + /* Ensure that dst->current is valid. */
> + dst->current = dst->first;
>bitmap_elt_clear_from (dst, dst_elt);
> }
>gcc_checking_assert (!dst->current == !dst->first);
> @@ -1951,6 +1953,8 @@ bitmap_ior_and_compl (bitmap dst, const_bitmap a,
> const_bitmap b, const_bitmap k
>if (dst_elt)
> {
>changed = true;
> + /* Ensure that dst->current is valid. */
> + dst->current = dst->first;
>bitmap_elt_clear_from (dst, dst_elt);
> }
>gcc_checking_assert (!dst->current == !dst->first);
Re: [PATCH] Extend shift permutations on power of 2 cases
On Fri, Nov 28, 2014 at 12:33 PM, Evgeny Stupachenko wrote:
> Hi,
>
> After fixing PR60451 (pack scheme instead of pshufb) general power of
> 2 permutations become more profitable.
> So I'd like to revert the changes keeping algorithm live or implement
> new hook to use best algorithm/size for particular -mtune.
>
> Below is reverting patch. Bootstrap and make check passed.
> Is it ok?
Ok.
Thanks,
Richard.
> 2014-11-28 Evgeny Stupachenko
>
> gcc/testsuite
> * gcc.target/i386/pr52252-atom-1.c: Delete.
>
> gcc/
> * tree-vect-data-refs.c (vect_transform_grouped_load): Limit shift
> permutations to loads group of size 3.
>
> diff --git a/gcc/testsuite/gcc.target/i386/pr52252-atom-1.c
> b/gcc/testsuite/gcc.target/i386/pr52252-atom-1.c
> deleted file mode 100644
> index 020e983..000
> --- a/gcc/testsuite/gcc.target/i386/pr52252-atom-1.c
> +++ /dev/null
> @@ -1,22 +0,0 @@
> -/* { dg-do compile } */
> -/* { dg-require-effective-target ssse3 } */
> -/* { dg-options "-O2 -ftree-vectorize -mssse3 -mtune=slm" } */
> -#define byte unsigned char
> -
> -void
> -pair_mul_sum(byte *in, byte *out, int size)
> -{
> - int j;
> - for(j = 0; j < size; j++)
> -{
> - byte a = in[0];
> - byte b = in[1];
> - byte c = in[2];
> - byte d = in[3];
> - out[0] = (byte)(a * b) + (byte)(b * c) + (byte)(c * d) + (byte)(d * a);
> - in += 4;
> - out += 1;
> -}
> -}
> -
> -/* { dg-final { scan-assembler "perm2i128|palignr" } } */
> diff --git a/gcc/tree-vect-data-refs.c b/gcc/tree-vect-data-refs.c
> index 35d0e0f..8451bda 100644
> --- a/gcc/tree-vect-data-refs.c
> +++ b/gcc/tree-vect-data-refs.c
> @@ -5617,6 +5617,7 @@ vect_transform_grouped_load (gimple stmt,
> vec dr_chain, int size,
> get chain for loads group using vect_shift_permute_load_chain. */
>mode = TYPE_MODE (STMT_VINFO_VECTYPE (vinfo_for_stmt (stmt)));
>if (targetm.sched.reassociation_width (VEC_PERM_EXPR, mode) > 1
> + || exact_log2 (size) != -1
>|| !vect_shift_permute_load_chain (dr_chain, size, stmt,
> gsi, &result_chain))
> vect_permute_load_chain (dr_chain, size, stmt, gsi, &result_chain);
>
> On Wed, Nov 12, 2014 at 4:16 PM, Uros Bizjak wrote:
>> On Wed, Nov 12, 2014 at 2:15 PM, Evgeny Stupachenko
>> wrote:
>>> To avoid misunderstanding.
>>> I haven't yet committed this obvious fix.
>>> Is it ok?
>>
>> If it is obvious, then it doesn't need an approval.
>>
>> So, OK.
>>
>> Thanks,
>> Uros.
Re: [RFC] Wrong "current" pointers with bitmap_ior and bitmap_ior_and_compl
Richard Biener wrote: > Huh? Wasn't this fixed by Mike a few weeks ago? Ugh. I've missed that thread. Sorry for the noise. Regards, kaz
Re: [patch g++.dg]: Disable some weak-tests for mingw-targets
2014-11-28 12:21 GMT+01:00 Rainer Orth : > Hi Kai, > >> this patch skips some test, which are trying to test non-existing >> weak-variant for mingw-targets. > > why is this necessary when most (all?) of those tests already have > dg-require-weak? If there's some property of weak variables that > PE-COFF lacks, I'd rather have a new effective-target keyword that tests > for this. > > Rainer As pe-coff indeed has some weak support in linker, but not that expected by those tests. So in general it would be wrong to disable weak completely, nevertheless are those tests not working for pe-coff mingw targets. Kai
Re: [PATCH 2/3] Extended if-conversion
On Wed, Nov 12, 2014 at 2:35 PM, Yuri Rumyantsev wrote:
> Hi All,
>
> Here is the second patch related to extended predication.
> Few comments which explain a main goal of design.
>
> 1. I don't want to insert any critical edge splitting since it may
> lead to less efficient binaries.
> 2. One special case of extended PHI node predication was introduced
> when #arguments is more than 2 but only two arguments are different
> and one argument has the only occurrence. For such PHI conditional
> scalar reduction is applied.
> This is correspondent to the following statement:
> if (q1 && q2 && q3) var++
> New function phi_has_two_different_args was introduced to detect such phi.
> 3. Original algorithm for PHI predication used assumption that at
> least one incoming edge for blocks containing PHI is not critical - it
> guarantees that all computations related to predicate of normal edge
> are already inserted above this block and
> code related to PHI predication can be inserted at the beginning of
> block. But this is not true for critical edges for which predicate
> computations are in the block where code for phi predication must be
> inserted. So new function find_insertion_point is introduced which is
> simply found out the last statement in block defining predicates
> correspondent to all incoming edges and insert phi predication code
> after it (with some minor exceptions).
Unfortunately the patch doesn't apply for me - I get
patch: malformed patch at line 505: @@ -1720,6 +2075,8 @@
predicate_all_scalar_phis (struct loop *loop)
a few remarks nevertheless. I don't see how we need both
predicate_extended_scalar_phi and predicate_arbitrary_scalar_phi.
Couldn't we simply sort an array of (edge, value) pairs after value
and handle equal values specially in predicate_extended_scalar_phi?
That would even make PHI more optimal.
I don't understand the need for find_insertion_point. All SSA names
required for the predicates are defined upward - and the complex CFG
is squashed to a single basic-block, thus the defs will dominate the
inserted code if you insert after labels just like for the other case.
Or what am I missing? ("flattening" of the basic-blocks of course needs
to happen in dominator order - but I guess that happens already?)
I'd like the extended PHI handling to be enablable by a flag even
for !force-vectorization - I've seen cases with 3 PHI args multiple
times that would have been nice to vectorize. I suggest to
add -ftree-loop-if-convert-aggressive for this. We can do this as
followup, but please rename the local flag_force_vectorize flag
to something less looking like a flag, like simply 'aggressive'.
Otherwise patch 2 looks ok to me.
Richard.
> ChangeLog:
>
> 2014-10-24 Yuri Rumyantsev
>
> * tree-if-conv.c (ifcvt_can_use_mask_load_store): Use
> FLAG_FORCE_VECTORIZE instead of loop flag.
> (if_convertible_bb_p): Allow bb has more than 2 predecessors if
> FLAG_FORCE_VECTORIZE is true.
> (if_convertible_bb_p): Delete check that bb has at least one
> non-critical incoming edge.
> (phi_has_two_different_args): New function.
> (is_cond_scalar_reduction): Add argument EXTENDED to choose access
> to phi arguments. Invoke phi_has_two_different_args to get phi
> arguments if EXTENDED is true. Change check that block
> containing reduction statement candidate is predecessor
> of phi-block since phi may have more than two arguments.
> (convert_scalar_cond_reduction): Add argument BEFORE to insert
> statement before/after gsi point.
> (predicate_scalar_phi): Add argument false (which means non-extended
> predication) to call of is_cond_scalar_reduction. Add argument
> true (which correspondent to argument BEFORE) to call of
> convert_scalar_cond_reduction.
> (get_predicate_for_edge): New function.
> (predicate_arbitrary_scalar_phi): New function.
> (predicate_extended_scalar_phi): New function.
> (find_insertion_point): New function.
> (predicate_all_scalar_phis): Add two boolean variables EXTENDED and
> BEFORE. Initialize EXTENDED to true if BB containing phi has more
> than 2 predecessors or both incoming edges are critical. Invoke
> find_phi_replacement_condition and predicate_scalar_phi or
> find_insertion_point and predicate_extended_scalar_phi depending on
> EXTENDED value.
> (insert_gimplified_predicates): Add check that non-predicated block
> may have statements to insert. Insert predicate of BB just after label
> if FLAG_FORCE_VECTORIZE is true.
> (tree_if_conversion): Add initialization of FLAG_FORCE_VECTORIZE which
> is copy of inner or outer loop field force_vectorize.
Re: [patch testsuite gcc.dg]: Turn of ms-extensions for mingw target
2014-11-28 12:14 GMT+01:00 Rainer Orth : > Hi Kai, > >> 2014-11-28 Kai Tietz >> >> * gcc.dg/anon-struct-1.c: >> * gcc.dg/anon-struct-11.c: >> * gcc.dg/anon-struct-2.c: >> * gcc.dg/c11-anon-struct-2.c: >> * gcc.dg/c11-anon-struct-3.c: > > those are not exactly useful ChangeLog entries ;-) > > Rainer Sorry, missed that ... I had them prior together with other patch ... Statement would be: Disable ms-extensions for mingw-targets. ... Kai
Re: [patch testsuite g++]: Fixes for mingw-targets
2014-11-28 12:17 GMT+01:00 Rainer Orth : > Hi Kai, > >> 2014-11-28 Kai Tietz >> >> * g++.dg/abi/mangle13.C: Disable >> ms-extensions for mingw-targets. > > just a nit: why break this line way before 72/80 charackters? Several > more of those useless linebreaks below. And no dash in mingw targets; > better yet use *-*-mingw* instead of paraphrasing the affected targets. > > Rainer None specific. I just wanted to avoid to have just mingw-targets in one line, but I can reformat ChangeLog, if patch itself is ok. Kai
Re: [patch testsuite gcc.dg]: Turn of ms-extensions for mingw target
Kai Tietz writes: > 2014-11-28 12:14 GMT+01:00 Rainer Orth : >> Hi Kai, >> >>> 2014-11-28 Kai Tietz >>> >>> * gcc.dg/anon-struct-1.c: >>> * gcc.dg/anon-struct-11.c: >>> * gcc.dg/anon-struct-2.c: >>> * gcc.dg/c11-anon-struct-2.c: >>> * gcc.dg/c11-anon-struct-3.c: >> >> those are not exactly useful ChangeLog entries ;-) >> >> Rainer > > Sorry, missed that ... I had them prior together with other patch ... > Statement would be: Disable ms-extensions for mingw-targets. ... ... and again, here holds what I said elsewhere: better use Disable ms-extensions for *-*-mingw*. which is more accurate/descriptive. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [patch g++.dg]: Disable some weak-tests for mingw-targets
Hi Kai, > 2014-11-28 12:21 GMT+01:00 Rainer Orth : >> Hi Kai, >> >>> this patch skips some test, which are trying to test non-existing >>> weak-variant for mingw-targets. >> >> why is this necessary when most (all?) of those tests already have >> dg-require-weak? If there's some property of weak variables that >> PE-COFF lacks, I'd rather have a new effective-target keyword that tests >> for this. >> >> Rainer > > As pe-coff indeed has some weak support in linker, but not that > expected by those tests. So in general it would be wrong to disable > weak completely, nevertheless are those tests not working for pe-coff > mingw targets. that's not at all what I'm saying: I'm asking for a *new, different* effective-target keyword capturing what those tests require, but PE-COFF/mingw is missing. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [PATCH 3/3] extended if-conversion
On Wed, Nov 12, 2014 at 2:54 PM, Yuri Rumyantsev wrote:
> Hi All,
>
> Here is the last part of patch which is related to vectorization
> improvements, namely
>
> 1. New sub-phase is added which delete dead predicate computations
> (such code can prevent loop vectorization since dead computation are
> not part of bool pattern tree). It is invoked only under
> FLAG_FORCE_VECTORIZE.
> 2. New sub-phase is added to provide single uses in tree correspondent
> to bool pattern (it takes place when the same predicate is used for
> PHI-node predication and predicated memory access through 'mask'). To
> do it some code replication is used. It is invoked only under
> FLAG_FORCE_VECTORIZE.
> 3. I added simple optimization for predicate_mem_writes - do not
> generate new mask if it has been produced for given size.
> 4. simple change was made in fold_build_cond_expr to simplify
> predicate of kind r != 0 where r has boolean type to simply 'r' which
> is accepted by bool pattern recognition.
Ick :/
In ifcvt_split_def_stmt I wonder why you copy the use_stmt as well?
>From the description it sounds like you want to copy def only.
Then,
+ /* Change one use of var to lhs. */
+ FOR_EACH_IMM_USE_FAST (use_p, imm_iter, var)
+{
+ use_stmt = USE_STMT (use_p);
+ break;
+}
I would think this should be simply
SET_USE (use_p, lhs);
break;
in stead of copying the stmt, adding it and then removing the "old".
What am I missing?
The "retry" code also looks odd - why do you walk the BB multiple
times instead of just doing sth like
while (!has_single_use (lhs))
{
gimple copy = ifcvt_split_def_stmt (def_stmt);
ifcvt_walk_pattern_tree (copy);
}
thus returning the copy you create and re-process it (the copy should
now have a single-use).
I think it would be nice to re-use some utility from tree-vect-patterns.c
for stmt_is_root_of_bool_pattern.
+/* Delete redundant statements produced by predication which prevents
+ loop vectorization. */
+
+static void
+ifcvt_local_dce (basic_block bb)
+{
...
+ /* Propagate liveness through arguments of live stmt. */
+ while (worklist.length () > 0)
+{
+ stmt = worklist.pop ();
+ code = gimple_code (stmt);
+ if (gimple_code (stmt) == GIMPLE_PHI)
+ {
+ for (i = 0; i < gimple_phi_num_args (stmt); i++)
+ {
+ tree arg = PHI_ARG_DEF (stmt, i);
+ if (TREE_CODE (arg) == SSA_NAME)
You can use FOR_EACH_PHI_OR_STMT_USE (but watch out for
non-SSA name "uses" then).
+ /* Delete dead statements. */
+ for (gsi = gsi_start_bb (bb); !gsi_end_p (gsi); gsi_next (&gsi))
+{
+ gimple_stmt_iterator stmt_it;
+
+ stmt = gsi_stmt (gsi);
+ if (gimple_plf (stmt, GF_PLF_2))
+ {
+ gimple_set_plf (stmt, GF_PLF_2, false);
+ continue;
no need to clear pass-local flags. You can't assume they are
not set at the start of your pass.
+ stmt_it = gsi_for_stmt (stmt);
err - simply use 'gsi' and do the gsi_next () only in the case of
GF_PLF_2.
The patchset doesn't seem to have any testcases - I'd like to see
some that exercise all cases you add handling for.
Richard.
> ChangeLog:
>
> 2014-11-12 Yuri Rumyantsev
>
> * tree-if-conv.c (fold_build_cond_expr): Add conversion COND to
> SSA_NAME if it is comparison r != 0 and r has boolean type.
> (predicate_mem_writes): Introduce mask_vec to save mask correspondent
> to given size. Do not generate new mask if it exists for given size.
> (ifcvt_split_def_stmt): New function.
> (ifcvt_walk_pattern_tree): New function.
> (stmt_is_root_of_bool_pattern): New function.
> (ifcvt_repair_bool_pattern): New function.
> (ifcvt_local_dce): New function.
> (tree_if_conversion): Add calls of ifcvt_local_dce and
> ifcvt_repair_bool_pattern if FLAG_FORCE_VECTORIZE is true.
[committed] 4.9 backports
Hi!
I've backported a few patches of mine to 4.9 branch,
bootstrapped/regtested on x86_64-linux and i686-linux,
committed to 4.9 branch.
Jakub
2014-11-28 Jakub Jelinek
Backported from mainline
2014-10-31 Jakub Jelinek
PR rtl-optimization/63659
* ree.c (update_reg_equal_equiv_notes): New function.
(combine_set_extension, transform_ifelse): Use it.
* gcc.c-torture/execute/pr63659.c: New test.
--- gcc/ree.c (revision 216984)
+++ gcc/ree.c (revision 216985)
@@ -261,6 +261,50 @@ typedef struct ext_cand
static int max_insn_uid;
+/* Update or remove REG_EQUAL or REG_EQUIV notes for INSN. */
+
+static bool
+update_reg_equal_equiv_notes (rtx insn, enum machine_mode new_mode,
+ enum machine_mode old_mode, enum rtx_code code)
+{
+ rtx *loc = ®_NOTES (insn);
+ while (*loc)
+{
+ enum reg_note kind = REG_NOTE_KIND (*loc);
+ if (kind == REG_EQUAL || kind == REG_EQUIV)
+ {
+ rtx orig_src = XEXP (*loc, 0);
+ /* Update equivalency constants. Recall that RTL constants are
+sign-extended. */
+ if (GET_CODE (orig_src) == CONST_INT
+ && HOST_BITS_PER_WIDE_INT >= GET_MODE_BITSIZE (new_mode))
+ {
+ if (INTVAL (orig_src) >= 0 || code == SIGN_EXTEND)
+ /* Nothing needed. */;
+ else
+ {
+ /* Zero-extend the negative constant by masking out the
+bits outside the source mode. */
+ rtx new_const_int
+ = gen_int_mode (INTVAL (orig_src)
+ & GET_MODE_MASK (old_mode),
+ new_mode);
+ if (!validate_change (insn, &XEXP (*loc, 0),
+ new_const_int, true))
+ return false;
+ }
+ loc = &XEXP (*loc, 1);
+ }
+ /* Drop all other notes, they assume a wrong mode. */
+ else if (!validate_change (insn, loc, XEXP (*loc, 1), true))
+ return false;
+ }
+ else
+ loc = &XEXP (*loc, 1);
+}
+ return true;
+}
+
/* Given a insn (CURR_INSN), an extension candidate for removal (CAND)
and a pointer to the SET rtx (ORIG_SET) that needs to be modified,
this code modifies the SET rtx to a new SET rtx that extends the
@@ -282,6 +326,7 @@ static bool
combine_set_extension (ext_cand *cand, rtx curr_insn, rtx *orig_set)
{
rtx orig_src = SET_SRC (*orig_set);
+ enum machine_mode orig_mode = GET_MODE (SET_DEST (*orig_set));
rtx new_set;
rtx cand_pat = PATTERN (cand->insn);
@@ -318,9 +363,8 @@ combine_set_extension (ext_cand *cand, r
{
/* Zero-extend the negative constant by masking out the bits outside
the source mode. */
- enum machine_mode src_mode = GET_MODE (SET_DEST (*orig_set));
rtx new_const_int
- = gen_int_mode (INTVAL (orig_src) & GET_MODE_MASK (src_mode),
+ = gen_int_mode (INTVAL (orig_src) & GET_MODE_MASK (orig_mode),
GET_MODE (new_reg));
new_set = gen_rtx_SET (VOIDmode, new_reg, new_const_int);
}
@@ -359,7 +403,9 @@ combine_set_extension (ext_cand *cand, r
/* This change is a part of a group of changes. Hence,
validate_change will not try to commit the change. */
- if (validate_change (curr_insn, orig_set, new_set, true))
+ if (validate_change (curr_insn, orig_set, new_set, true)
+ && update_reg_equal_equiv_notes (curr_insn, cand->mode, orig_mode,
+ cand->code))
{
if (dump_file)
{
@@ -409,7 +455,9 @@ transform_ifelse (ext_cand *cand, rtx de
ifexpr = gen_rtx_IF_THEN_ELSE (cand->mode, cond, map_srcreg, map_srcreg2);
new_set = gen_rtx_SET (VOIDmode, map_dstreg, ifexpr);
- if (validate_change (def_insn, &PATTERN (def_insn), new_set, true))
+ if (validate_change (def_insn, &PATTERN (def_insn), new_set, true)
+ && update_reg_equal_equiv_notes (def_insn, cand->mode, GET_MODE (dstreg),
+ cand->code))
{
if (dump_file)
{
--- gcc/testsuite/gcc.c-torture/execute/pr63659.c (revision 0)
+++ gcc/testsuite/gcc.c-torture/execute/pr63659.c (revision 216985)
@@ -0,0 +1,29 @@
+/* PR rtl-optimization/63659 */
+
+int a, b, c, *d = &b, g, h, i;
+unsigned char e;
+char f;
+
+int
+main ()
+{
+ while (a)
+{
+ for (a = 0; a; a++)
+ for (; c; c++)
+ ;
+ if (i)
+ break;
+}
+
+ char j = c, k = -1, l;
+ l = g = j >> h;
+ f = l == 0 ? k : k % l;
+ e = 0 ? 0 : f;
+ *d = e;
+
+ if (b != 255)
+__builtin_abort ();
+
+ return 0;
+}
2014-11-28 Jakub Jelinek
Backported from mainline
2014-11-19 Jakub Jelinek
PR sanitizer/63913
* ubsan.c: Include tree-eh.h.
(instrument_bool_enum_load):
Re: [Bug target/63661] [4.9/5 Regression] -O2 miscompiles with -mtune=nehalem or corei7
On Fri, Nov 28, 2014 at 3:23 AM, Jakub Jelinek wrote:
> On Fri, Nov 28, 2014 at 11:19:18AM +, renlin at gcc dot gnu.org wrote:
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63661
>>
>> --- Comment #25 from renlin at gcc dot gnu.org ---
>> Author: renlin
>> Date: Fri Nov 28 11:18:47 2014
>> New Revision: 218144
>>
>> URL: https://gcc.gnu.org/viewcvs?rev=218144&root=gcc&view=rev
>> Log:
>> Use native tune. nehalem is not able to triggle the issue in trunk any more.
>>
>> 2014-11-28 Renlin Li
>>
>> PR target/63661
>> * gcc.target/i386/pr63661.c: Use native tune.
>>
>> Modified:
>> trunk/gcc/testsuite/ChangeLog
>> trunk/gcc/testsuite/gcc.target/i386/pr63661.c
>
> This is wrong. That will mean the test will do something different
> for different testers. If it reproduces for you with
> -mtune=native, just find out what that -mtune=native is for you
> (use -v) and try the specific option instead.
>
> Jakub
I checked in this patch to use -mtune=nehalem. Verified
on Linux/x86-64 with -m32 and -m64. When I reverted r217783,
the modified test failed.
--
H.J.
---
Index: ChangeLog
===
--- ChangeLog (revision 218156)
+++ ChangeLog (working copy)
@@ -1,3 +1,10 @@
+2014-11-28 H.J. Lu
+
+ * gcc.target/i386/pr63661.c: Replace -mtune=native with
+ -mtune=nehalem.
+ (foo): Replace "!=" with delta.
+ (main): Remove __builtin_printf.
+
2014-11-28 Renlin Li
PR target/63661
Index: gcc.target/i386/pr63661.c
===
--- gcc.target/i386/pr63661.c (revision 218156)
+++ gcc.target/i386/pr63661.c (working copy)
@@ -1,7 +1,7 @@
/* PR target/63661 */
/* { dg-do run } */
/* { dg-require-effective-target fpic } */
-/* { dg-options "-mtune=native -fPIC -O2" } */
+/* { dg-options "-mtune=nehalem -fPIC -O2" } */
static void __attribute__((noinline,noclone,hot))
foo (double a, double q, double *ff, double *gx, int e, int ni)
@@ -11,11 +11,15 @@
double n;
unsigned long long o;
} punner;
+ double d;
punner.n = q;
__builtin_printf("B: 0x%016llx %g\n", punner.o, q);
- if(q != 5)
+ d = q - 5;
+ if(d < 0)
+d = -d;
+ if (d > 0.1)
__builtin_abort();
}
@@ -71,7 +75,6 @@
{
double c[1000];
- __builtin_printf("A: 0x%016llx\n", (unsigned long long)c);
bar (1, 5.0, c);
return 0;
}
[PATCH] Fix regexps in avx512* tests
Hello, This patch is according to this input: https://gcc.gnu.org/ml/gcc-patches/2014-10/msg02441.html Furthermore, the following regexps were fixed in order to make more precise assembler scanning. The endings like (?:\n|\[\ \t\]+#) are used in ICC which may generate comments. Please have a look. Is it ok for trunk? Thanks, Petr 2014-11-28 Petr Murzin gcc/testsuite/ * gcc.target/i386/avx512bw-kunpckdq-1.c: Fix regexps for assembler scanning. * gcc.target/i386/avx512bw-kunpckwd-1.c: Ditto. * gcc.target/i386/avx512bw-vdbpsadbw-1.c: Ditto. * gcc.target/i386/avx512bw-vmovdqu16-1.c: Ditto. * gcc.target/i386/avx512bw-vmovdqu8-1.c: Ditto. * gcc.target/i386/avx512bw-vpabsb-1.c: Ditto. * gcc.target/i386/avx512bw-vpabsw-1.c: Ditto. * gcc.target/i386/avx512bw-vpackssdw-1.c: Ditto. * gcc.target/i386/avx512bw-vpacksswb-1.c: Ditto. * gcc.target/i386/avx512bw-vpackusdw-1.c: Ditto. * gcc.target/i386/avx512bw-vpackuswb-1.c: Ditto. * gcc.target/i386/avx512bw-vpaddb-1.c: Ditto. * gcc.target/i386/avx512bw-vpaddsb-1.c: Ditto. * gcc.target/i386/avx512bw-vpaddsw-1.c: Ditto. * gcc.target/i386/avx512bw-vpaddusb-1.c: Ditto. * gcc.target/i386/avx512bw-vpaddusw-1.c: Ditto. * gcc.target/i386/avx512bw-vpaddw-1.c: Ditto. * gcc.target/i386/avx512bw-vpalignr-1.c: Ditto. * gcc.target/i386/avx512bw-vpavgb-1.c: Ditto. * gcc.target/i386/avx512bw-vpavgw-1.c: Ditto. * gcc.target/i386/avx512bw-vpblendmb-1.c: Ditto. * gcc.target/i386/avx512bw-vpblendmw-1.c: Ditto. * gcc.target/i386/avx512bw-vpbroadcastb-1.c: Ditto. * gcc.target/i386/avx512bw-vpbroadcastw-1.c: Ditto. * gcc.target/i386/avx512bw-vpcmpb-1.c: Ditto. * gcc.target/i386/avx512bw-vpcmpeqb-1.c: Ditto. * gcc.target/i386/avx512bw-vpcmpequb-1.c: Ditto. * gcc.target/i386/avx512bw-vpcmpequw-1.c: Ditto. * gcc.target/i386/avx512bw-vpcmpeqw-1.c: Ditto. * gcc.target/i386/avx512bw-vpcmpgeb-1.c: Ditto. * gcc.target/i386/avx512bw-vpcmpgeub-1.c: Ditto. * gcc.target/i386/avx512bw-vpcmpgeuw-1.c: Ditto. * gcc.target/i386/avx512bw-vpcmpgew-1.c: Ditto. * gcc.target/i386/avx512bw-vpcmpgtb-1.c: Ditto. * gcc.target/i386/avx512bw-vpcmpgtub-1.c: Ditto. * gcc.target/i386/avx512bw-vpcmpgtuw-1.c: Ditto. * gcc.target/i386/avx512bw-vpcmpgtw-1.c: Ditto. * gcc.target/i386/avx512bw-vpcmpleb-1.c: Ditto. * gcc.target/i386/avx512bw-vpcmpleub-1.c: Ditto. * gcc.target/i386/avx512bw-vpcmpleuw-1.c: Ditto. * gcc.target/i386/avx512bw-vpcmplew-1.c: Ditto. * gcc.target/i386/avx512bw-vpcmpltb-1.c: Ditto. * gcc.target/i386/avx512bw-vpcmpltub-1.c: Ditto. * gcc.target/i386/avx512bw-vpcmpltuw-1.c: Ditto. * gcc.target/i386/avx512bw-vpcmpltw-1.c: Ditto. * gcc.target/i386/avx512bw-vpcmpneqb-1.c: Ditto. * gcc.target/i386/avx512bw-vpcmpnequb-1.c: Ditto. * gcc.target/i386/avx512bw-vpcmpnequw-1.c: Ditto. * gcc.target/i386/avx512bw-vpcmpneqw-1.c: Ditto. * gcc.target/i386/avx512bw-vpcmpub-1.c: Ditto. * gcc.target/i386/avx512bw-vpcmpuw-1.c: Ditto. * gcc.target/i386/avx512bw-vpcmpw-1.c: Ditto. * gcc.target/i386/avx512bw-vpermi2w-1.c: Ditto. * gcc.target/i386/avx512bw-vpermt2w-1.c: Ditto. * gcc.target/i386/avx512bw-vpermw-1.c: Ditto. * gcc.target/i386/avx512bw-vpmaddubsw-1.c: Ditto. * gcc.target/i386/avx512bw-vpmaddwd-1.c: Ditto. * gcc.target/i386/avx512bw-vpmaxsb-1.c: Ditto. * gcc.target/i386/avx512bw-vpmaxsw-1.c: Ditto. * gcc.target/i386/avx512bw-vpmaxub-1.c: Ditto. * gcc.target/i386/avx512bw-vpmaxuw-1.c: Ditto. * gcc.target/i386/avx512bw-vpminsb-1.c: Ditto. * gcc.target/i386/avx512bw-vpminsw-1.c: Ditto. * gcc.target/i386/avx512bw-vpminub-1.c: Ditto. * gcc.target/i386/avx512bw-vpminuw-1.c: Ditto. * gcc.target/i386/avx512bw-vpmovb2m-1.c: Ditto. * gcc.target/i386/avx512bw-vpmovm2b-1.c: Ditto. * gcc.target/i386/avx512bw-vpmovm2w-1.c: Ditto. * gcc.target/i386/avx512bw-vpmovswb-1.c: Ditto. * gcc.target/i386/avx512bw-vpmovsxbw-1.c: Ditto. * gcc.target/i386/avx512bw-vpmovuswb-1.c: Ditto. * gcc.target/i386/avx512bw-vpmovw2m-1.c: Ditto. * gcc.target/i386/avx512bw-vpmovwb-1.c: Ditto. * gcc.target/i386/avx512bw-vpmovzxbw-1.c: Ditto. * gcc.target/i386/avx512bw-vpmulhrsw-1.c: Ditto. * gcc.target/i386/avx512bw-vpmulhuw-1.c: Ditto. * gcc.target/i386/avx512bw-vpmulhw-1.c: Ditto. * gcc.target/i386/avx512bw-vpmullw-1.c: Ditto. * gcc.target/i386/avx512bw-vpshufb-1.c: Ditto. * gcc.target/i386/avx512bw-vpshufhw-1.c: Ditto. * gcc.target/i386/avx512bw-vpshuflw-1.c: Ditto. * gcc.target/i386/avx512bw-vpslldq-1.c: Ditto. * gcc.target/i386/avx512bw-vpsllvw-1.c: Ditto. * gcc.target/i386/avx512bw-vpsllw-1.c: Ditto. * gcc.target/i386/avx512bw-vpsllwi-1.c: Ditto. * gcc.target/i386/avx512bw-vpsravw-1.c: Ditto. * gcc.target/i386/avx512bw-vpsraw-1.c: Ditto. * gcc.target/i386/avx512bw-vpsrawi-1.c: Ditto. * gcc.target/i386/avx512bw-vpsrldq-1.c: Ditto. * gcc.target/i386/avx512bw-vpsrlvw-1.c: Ditto. * gcc.target/i386/avx512bw-vpsrlw-1.c: Ditto. * gcc.target/i386/avx512bw-vpsrlwi-1.c: Ditto. * gcc.target/i386/avx512bw-vpsubb-1.c: Ditto. * gcc.target/i386/avx512bw-vpsubsb-1.c: Ditto. * gcc.target/i386/avx512bw-vpsubsw-1.c: Ditto. * gcc.target/i386/avx512bw-vpsubusb-1.c: Ditto.
RE: [PATCH] Improve spillcost of literal pool loads
> Jeff Law wrote:
> Do you have a testcase that shows the expected improvements from this
> change? It's OK if it's specific to a target.
>
> Have you bootstrapped and regression tested this change?
>
> With a test for the testsuite and assuming it passes bootstrap and
> regression testing, this will almost certainly be OK.
I've added a test, see below. It bootstraps OK on AArch64 and the only
difference in the regression tests after the patch is the one extra pass.
OK for commit?
---
gcc/ira-costs.c | 5 ++---
gcc/testsuite/gcc.target/aarch64/remat1.c | 19 +++
2 files changed, 21 insertions(+), 3 deletions(-)
create mode 100644 gcc/testsuite/gcc.target/aarch64/remat1.c
diff --git a/gcc/ira-costs.c b/gcc/ira-costs.c
index 122815b..95d266e 100644
--- a/gcc/ira-costs.c
+++ b/gcc/ira-costs.c
@@ -1462,12 +1462,11 @@ scan_one_insn (rtx_insn *insn)
&& ((MEM_P (XEXP (note, 0))
&& !side_effects_p (SET_SRC (set)))
|| (CONSTANT_P (XEXP (note, 0))
- && targetm.legitimate_constant_p (GET_MODE (SET_DEST (set)),
- XEXP (note, 0))
+ && (! flag_pic || LEGITIMATE_PIC_OPERAND_P (XEXP (note, 0)))
&& REG_N_SETS (REGNO (SET_DEST (set))) == 1))
&& general_operand (SET_SRC (set), GET_MODE (SET_SRC (set
{
- enum reg_class cl = GENERAL_REGS;
+ enum reg_class cl = ALL_REGS;
rtx reg = SET_DEST (set);
int num = COST_INDEX (REGNO (reg));
diff --git a/gcc/testsuite/gcc.target/aarch64/remat1.c
b/gcc/testsuite/gcc.target/aarch64/remat1.c
new file mode 100644
index 000..f020709
--- /dev/null
+++ b/gcc/testsuite/gcc.target/aarch64/remat1.c
@@ -0,0 +1,19 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fomit-frame-pointer -fcaller-saves -ffixed-d8 -ffixed-d9
-ffixed-d10
-ffixed-d11 -ffixed-d12 -ffixed-d13 -ffixed-d14 -ffixed-d15" } */
+
+/* Under high register pressure FP immediates should be rematerialized
+ as literal loads rather than being caller-saved to the stack. */
+
+void g (void);
+
+float
+f (float x)
+{
+ x += 3.1f;
+ g ();
+ x *= 3.1f;
+ return x;
+}
+
+/* { dg-final { scan-assembler-times "ldr\ts\[0-9]+, .LC0" 2 } } */
+
--
1.9.1
Re: [C++ PATCH] Detect UB in shifts in constexpr functions
On 11/27/2014 09:26 AM, Marek Polacek wrote: On Wed, Nov 26, 2014 at 11:56:26AM -0500, Jason Merrill wrote: Please give diagnostics explaining what's wrong with the shift rather than the generic "is not a constant expression". Done. I was thinking even more detailed: one diagnostic for negative count, one diagnostic for count larger than the precision of the lhs, and then a third for overflow. + tree t = build_int_cst (unsigned_type_node, uprec - 1); + t = fold_build2 (MINUS_EXPR, unsigned_type_node, t, rhs); + tree ulhs = fold_convert (unsigned_type_for (lhstype), lhs); + t = fold_build2 (RSHIFT_EXPR, TREE_TYPE (ulhs), ulhs, t); + if (tree_int_cst_lt (integer_one_node, t)) This could also use a comment explaining the logic. + /* For signed x << y the following: +(unsigned) x >> ((prec (lhs) - 1) - y) +if > 1, is undefined. */ I meant briefly explaining where that formula comes from. Jason
Re: [PATCH] -fsanitize=vptr instrumentation (take 2)
On Wed, Nov 26, 2014 at 11:18:11AM -0500, Jason Merrill wrote:
> On 10/28/2014 08:44 AM, Jakub Jelinek wrote:
> >+cp_ubsan_check_member_access_r (tree *stmt_p, int *walk_subtrees, void
> >*data)
>
> This function needs a longer comment about exactly what forms it's trying to
> instrument.
Ok, will do.
> >+ /* T t; t.foo (); doesn't need instrumentation, if the type is known. */
> >+ if (is_addr
> >+ && TREE_CODE (op) == ADDR_EXPR
> >+ && DECL_P (TREE_OPERAND (op, 0))
> >+ && same_type_p (type,
> >+ TYPE_MAIN_VARIANT (TREE_TYPE (TREE_OPERAND (op, 0)
> >+return NULL_TREE;
>
> How do we know the decl's vptr hasn't been clobbered? This seems like one
> of the optimizations we decided to drop.
Yeah, will try to remove this hunk and see what it changes.
> >+ if (TREE_CODE (base) == COMPONENT_REF
> >+ && DECL_ARTIFICIAL (TREE_OPERAND (base, 1)))
> >+{
> >+ tree base2 = TREE_OPERAND (base, 0);
> >+ while (TREE_CODE (base2) == COMPONENT_REF
> >+ || TREE_CODE (base2) == ARRAY_REF
> >+ || TREE_CODE (base2) == ARRAY_RANGE_REF)
> >+base2 = TREE_OPERAND (base2, 0);
> >+ if (TREE_CODE (base2) != INDIRECT_REF
> >+ && TREE_CODE (base2) != MEM_REF)
> >+return;
> >+}
> >+ else if (TREE_CODE (base) != INDIRECT_REF
> >+ && TREE_CODE (base) != MEM_REF)
> >+return;
>
> Why do you look through ARRAY_REF here? An element of an array is its own
> complete object.
That had to do with only instrumenting dereferences surrounded by handled
components, but not accesses to decls (so p->x gets instrumented but
q.x for VAR_DECL q is not). If we want to instrument that, then I'll need
to tweak the member access instrumentation some more.
Today I found that the C++14 constexpr changes unfortunately mean I have to
make bigger changes, so I'm rewriting it to use UBSAN_VPTR internal calls
and only lower that during sanopt (and will try to optimize clearly
unnecessary checks at that point to offset from the FE instrumenting more
- if the optimizers can prove virtual table of the object has not been
changed since dominating UBSAN_VPTR, we don't need to instrument it again.
Jakub
Re: [PATCH, ifcvt] Fix PR63917
On Sun, Nov 23, 2014 at 7:47 PM, Zhenqiang Chen wrote:
>
>> -Original Message-
>> From: Richard Henderson [mailto:r...@redhat.com]
>> Sent: Friday, November 21, 2014 2:27 AM
>> To: Zhenqiang Chen; gcc-patches@gcc.gnu.org
>> Subject: Re: [PATCH, ifcvt] Fix PR63917
>>
>> On 11/20/2014 10:48 AM, Zhenqiang Chen wrote:
>> > +/* Check X clobber CC reg or not. */
>> > +
>> > +static bool
>> > +clobber_cc_p (rtx x)
>> > +{
>> > + RTX_CODE code = GET_CODE (x);
>> > + int i;
>> > +
>> > + if (code == CLOBBER
>> > + && REG_P (XEXP (x, 0))
>> > + && (GET_MODE_CLASS (GET_MODE (XEXP (x, 0))) == MODE_CC))
>> > +return TRUE;
>> > + else if (code == PARALLEL)
>> > +for (i = 0; i < XVECLEN (x, 0); i++)
>> > + if (clobber_cc_p (XVECEXP (x, 0, i)))
>> > + return TRUE;
>> > + return FALSE;
>> > +}
>>
>> Why would you need something like this when modified_between_p or one
>> of its kin ought to do the job?
>
> Thanks for the comments. Patch is updated to use set_of.
>
> And it is also enhanced to make sure that the new generated insns can not
> clobber CC.
>
> Bootstrap and no make check regression on X86-64 and IA32.
>
> OK for trunk?
>
> Thanks!
> -Zhenqiang
>
> ChangeLog:
> 2014-11-24 Zhenqiang Chen
>
> PR rtl-optimization/63917
> * ifcvt.c (cc_in_cond): New function.
> (end_ifcvt_sequence): Make sure new generated insns do not clobber
> CC.
> (noce_process_if_block, check_cond_move_block): Check CC references.
>
> testsuite/ChangeLog:
> 2014-11-24 Zhenqiang Chen
>
> * gcc.dg/pr63917.c: New test.
>
> diff --git a/gcc/ifcvt.c b/gcc/ifcvt.c
> index 21f08c2..1acd0ff 100644
> --- a/gcc/ifcvt.c
> +++ b/gcc/ifcvt.c
> @@ -1016,6 +1016,18 @@ noce_emit_move_insn (rtx x, rtx y)
>0, 0, outmode, y);
> }
>
> +/* Return the CC reg if it is used in COND. */
> +
> +static rtx
> +cc_in_cond (rtx cond)
> +{
> + if ((HAVE_cbranchcc4) && cond
> + && (GET_MODE_CLASS (GET_MODE (XEXP (cond, 0))) == MODE_CC))
> +return XEXP (cond, 0);
> +
> + return NULL_RTX;
> +}
> +
> /* Return sequence of instructions generated by if conversion. This
> function calls end_sequence() to end the current stream, ensures
> that are instructions are unshared, recognizable non-jump insns.
> @@ -1026,6 +1038,7 @@ end_ifcvt_sequence (struct noce_if_info *if_info)
> {
>rtx_insn *insn;
>rtx_insn *seq = get_insns ();
> + rtx cc = cc_in_cond (if_info->cond);
>
>set_used_flags (if_info->x);
>set_used_flags (if_info->cond);
> @@ -1040,7 +1053,9 @@ end_ifcvt_sequence (struct noce_if_info *if_info)
> allows proper placement of required clobbers. */
>for (insn = seq; insn; insn = NEXT_INSN (insn))
> if (JUMP_P (insn)
> - || recog_memoized (insn) == -1)
> + || recog_memoized (insn) == -1
> + /* Make sure new generated code does not clobber CC. */
> + || (cc && set_of (cc, insn)))
>return NULL;
>
>return seq;
> @@ -2544,6 +2559,7 @@ noce_process_if_block (struct noce_if_info *if_info)
>rtx_insn *insn_a, *insn_b;
>rtx set_a, set_b;
>rtx orig_x, x, a, b;
> + rtx cc;
>
>/* We're looking for patterns of the form
>
> @@ -2655,6 +2671,13 @@ noce_process_if_block (struct noce_if_info *if_info)
>if_info->a = a;
>if_info->b = b;
>
> + /* Skip it if the instruction to be moved might clobber CC. */
> + cc = cc_in_cond (cond);
> + if (cc)
> +if (set_of (cc, insn_a)
> + || (insn_b && set_of (XEXP (cond, 0), insn_b)))
> + return FALSE;
> +
>/* Try optimizations in some approximation of a useful order. */
>/* ??? Should first look to see if X is live incoming at all. If it
> isn't, we don't need anything but an unconditional set. */
> @@ -2811,6 +2834,7 @@ check_cond_move_block (basic_block bb,
>rtx cond)
> {
>rtx_insn *insn;
> + rtx cc = cc_in_cond (cond);
>
> /* We can only handle simple jumps at the end of the basic block.
>It is almost impossible to update the CFG otherwise. */
> @@ -2868,6 +2892,10 @@ check_cond_move_block (basic_block bb,
> && modified_between_p (src, insn, NEXT_INSN (BB_END (bb
> return FALSE;
>
> + /* Skip it if the instruction to be moved might clobber CC. */
> + if (cc && set_of (cc, insn))
> + return FALSE;
> +
>vals->put (dest, src);
>
>regs->safe_push (dest);
> diff --git a/gcc/testsuite/gcc.dg/pr63917.c b/gcc/testsuite/gcc.dg/pr63917.c
> new file mode 100644
> index 000..422b15d
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/pr63917.c
It should be pr64007.c.
> @@ -0,0 +1,45 @@
> +/* { dg-options " -O3 " } */
You need
/* { dg-do run } */
since it is a run-time test.
> +
> +int d, i;
> +
> +struct S
> +{
> + int f0;
> +} *b, c, e, h, **g = &b;
> +
> +static struct S *f = &e;
> +
> +int
> +fn1 (int p)
> +{
> + int a = 0;
> + return a || p < 0 || p >= 2 || 1 >> p;
> +}
> +
> +int
> +main ()
> +{
> + in
[PATCH, contrib] Reduce check_GNU_style noise
Currently check_GNU_style.sh gives the error "There should be exactly one space
between function name and parentheses." for the following kind of lines:
tab[(int) idx]
This patch changes the check to only warn if there is 0 of 2+ space(s) between
a alphanumeric character and an opening parenthesis, rather than 2+ space or
anything else than a single space (which also was redundant).
With the change, above lines are now not warned about but other incorrect lines
are still reported.
ChangeLog entry is as follows:
*** contrib/ChangeLog ***
2014-11-28 Thomas Preud'homme
* check_GNU_style.sh: Warn for incorrect number of space in function
call only if 0 or 2+ spaces found.
diff --git a/contrib/check_GNU_style.sh b/contrib/check_GNU_style.sh
index ef8fdda..5f90190 100755
--- a/contrib/check_GNU_style.sh
+++ b/contrib/check_GNU_style.sh
@@ -113,7 +113,7 @@ g 'Sentences should end with a dot. Dot, space, space, end
of the comment.' \
'[[:alnum:]][[:blank:]]*\*/' $*
vg 'There should be exactly one space between function name and parentheses.' \
-'\#define' '[[:alnum:]]([^[:blank:]]|[[:blank:]]{2,})\(' $*
+'\#define' '[[:alnum:]]([[:blank:]]{2,})?\(' $*
g 'There should be no space before closing parentheses.' \
'[[:graph:]][[:blank:]]+\)' $*
Is this ok for trunk?
Best regards,
Thomas
Re: [PATCH] Fix regexps in avx512* tests
On Fri, Nov 28, 2014 at 2:54 PM, Petr Murzin wrote:
> Hello,
> This patch is according to this input:
> https://gcc.gnu.org/ml/gcc-patches/2014-10/msg02441.html
> Furthermore, the following regexps were fixed in order to make more
> precise assembler scanning. The endings like (?:\n|\[\ \t\]+#) are
> used in ICC which may generate comments. Please have a look. Is it ok
> for trunk?
Please use "\[ \\t\]" consistently, you have different scan string
"\[\ \t\]" in the added ending in:
\[ \\t\]+\[^\{\n\]*%k\[0-7\](?:\n|\[\ \t\]+#)
I'm not that familiar with ICC endings, but I guess they are OK with
the above change.
> Thanks,
> Petr
>
> 2014-11-28 Petr Murzin
>
> gcc/testsuite/
>
> * gcc.target/i386/avx512bw-kunpckdq-1.c: Fix regexps for assembler scanning.
> * gcc.target/i386/avx512bw-kunpckwd-1.c: Ditto.
> * gcc.target/i386/avx512bw-vdbpsadbw-1.c: Ditto.
> * gcc.target/i386/avx512bw-vmovdqu16-1.c: Ditto.
> * gcc.target/i386/avx512bw-vmovdqu8-1.c: Ditto.
> * gcc.target/i386/avx512bw-vpabsb-1.c: Ditto.
> * gcc.target/i386/avx512bw-vpabsw-1.c: Ditto.
> * gcc.target/i386/avx512bw-vpackssdw-1.c: Ditto.
> * gcc.target/i386/avx512bw-vpacksswb-1.c: Ditto.
> * gcc.target/i386/avx512bw-vpackusdw-1.c: Ditto.
> * gcc.target/i386/avx512bw-vpackuswb-1.c: Ditto.
> * gcc.target/i386/avx512bw-vpaddb-1.c: Ditto.
> * gcc.target/i386/avx512bw-vpaddsb-1.c: Ditto.
> * gcc.target/i386/avx512bw-vpaddsw-1.c: Ditto.
> * gcc.target/i386/avx512bw-vpaddusb-1.c: Ditto.
> * gcc.target/i386/avx512bw-vpaddusw-1.c: Ditto.
> * gcc.target/i386/avx512bw-vpaddw-1.c: Ditto.
> * gcc.target/i386/avx512bw-vpalignr-1.c: Ditto.
> * gcc.target/i386/avx512bw-vpavgb-1.c: Ditto.
> * gcc.target/i386/avx512bw-vpavgw-1.c: Ditto.
> * gcc.target/i386/avx512bw-vpblendmb-1.c: Ditto.
> * gcc.target/i386/avx512bw-vpblendmw-1.c: Ditto.
> * gcc.target/i386/avx512bw-vpbroadcastb-1.c: Ditto.
> * gcc.target/i386/avx512bw-vpbroadcastw-1.c: Ditto.
> * gcc.target/i386/avx512bw-vpcmpb-1.c: Ditto.
> * gcc.target/i386/avx512bw-vpcmpeqb-1.c: Ditto.
> * gcc.target/i386/avx512bw-vpcmpequb-1.c: Ditto.
> * gcc.target/i386/avx512bw-vpcmpequw-1.c: Ditto.
> * gcc.target/i386/avx512bw-vpcmpeqw-1.c: Ditto.
> * gcc.target/i386/avx512bw-vpcmpgeb-1.c: Ditto.
> * gcc.target/i386/avx512bw-vpcmpgeub-1.c: Ditto.
> * gcc.target/i386/avx512bw-vpcmpgeuw-1.c: Ditto.
> * gcc.target/i386/avx512bw-vpcmpgew-1.c: Ditto.
> * gcc.target/i386/avx512bw-vpcmpgtb-1.c: Ditto.
> * gcc.target/i386/avx512bw-vpcmpgtub-1.c: Ditto.
> * gcc.target/i386/avx512bw-vpcmpgtuw-1.c: Ditto.
> * gcc.target/i386/avx512bw-vpcmpgtw-1.c: Ditto.
> * gcc.target/i386/avx512bw-vpcmpleb-1.c: Ditto.
> * gcc.target/i386/avx512bw-vpcmpleub-1.c: Ditto.
> * gcc.target/i386/avx512bw-vpcmpleuw-1.c: Ditto.
> * gcc.target/i386/avx512bw-vpcmplew-1.c: Ditto.
> * gcc.target/i386/avx512bw-vpcmpltb-1.c: Ditto.
> * gcc.target/i386/avx512bw-vpcmpltub-1.c: Ditto.
> * gcc.target/i386/avx512bw-vpcmpltuw-1.c: Ditto.
> * gcc.target/i386/avx512bw-vpcmpltw-1.c: Ditto.
> * gcc.target/i386/avx512bw-vpcmpneqb-1.c: Ditto.
> * gcc.target/i386/avx512bw-vpcmpnequb-1.c: Ditto.
> * gcc.target/i386/avx512bw-vpcmpnequw-1.c: Ditto.
> * gcc.target/i386/avx512bw-vpcmpneqw-1.c: Ditto.
> * gcc.target/i386/avx512bw-vpcmpub-1.c: Ditto.
> * gcc.target/i386/avx512bw-vpcmpuw-1.c: Ditto.
> * gcc.target/i386/avx512bw-vpcmpw-1.c: Ditto.
> * gcc.target/i386/avx512bw-vpermi2w-1.c: Ditto.
> * gcc.target/i386/avx512bw-vpermt2w-1.c: Ditto.
> * gcc.target/i386/avx512bw-vpermw-1.c: Ditto.
> * gcc.target/i386/avx512bw-vpmaddubsw-1.c: Ditto.
> * gcc.target/i386/avx512bw-vpmaddwd-1.c: Ditto.
> * gcc.target/i386/avx512bw-vpmaxsb-1.c: Ditto.
> * gcc.target/i386/avx512bw-vpmaxsw-1.c: Ditto.
> * gcc.target/i386/avx512bw-vpmaxub-1.c: Ditto.
> * gcc.target/i386/avx512bw-vpmaxuw-1.c: Ditto.
> * gcc.target/i386/avx512bw-vpminsb-1.c: Ditto.
> * gcc.target/i386/avx512bw-vpminsw-1.c: Ditto.
> * gcc.target/i386/avx512bw-vpminub-1.c: Ditto.
> * gcc.target/i386/avx512bw-vpminuw-1.c: Ditto.
> * gcc.target/i386/avx512bw-vpmovb2m-1.c: Ditto.
> * gcc.target/i386/avx512bw-vpmovm2b-1.c: Ditto.
> * gcc.target/i386/avx512bw-vpmovm2w-1.c: Ditto.
> * gcc.target/i386/avx512bw-vpmovswb-1.c: Ditto.
> * gcc.target/i386/avx512bw-vpmovsxbw-1.c: Ditto.
> * gcc.target/i386/avx512bw-vpmovuswb-1.c: Ditto.
> * gcc.target/i386/avx512bw-vpmovw2m-1.c: Ditto.
> * gcc.target/i386/avx512bw-vpmovwb-1.c: Ditto.
> * gcc.target/i386/avx512bw-vpmovzxbw-1.c: Ditto.
> * gcc.target/i386/avx512bw-vpmulhrsw-1.c: Ditto.
> * gcc.target/i386/avx512bw-vpmulhuw-1.c: Ditto.
> * gcc.target/i386/avx512bw-vpmulhw-1.c: Ditto.
> * gcc.target/i386/avx512bw-vpmullw-1.c: Ditto.
> * gcc.target/i386/avx512bw-vpshufb-1.c: Ditto.
> * gcc.target/i386/avx512bw-vpshufhw-1.c: Ditto.
> * gcc.target/i386/avx512bw-vpshuflw-1.c: Ditto.
> * gcc.target/i386/avx512bw-vpslldq-1.c: Ditto.
> * gcc.target/i386/avx512bw-vpsllvw-1.c: Ditto.
> * gcc.target/i386/avx512bw-vpsllw-1.c: Ditto.
> * gcc.target/i386/avx512bw-vpsllwi-1.c: Ditto.
> * gcc.target/i386/avx512bw
Re: [PATCH x86] Update options for avx512 testsuite.
Hello! > As discussed for AVX512F submission, using -D in dg-options, > should be replaced with parts of the testcase itself. Patch below > does that. > Ok for trunk? > > P. S. > As patch itself is hard to review, this was done by sed like this: > > sed -i 's/ -DAVX512IFMA//g' ../gcc/testsuite/gcc.target/i386/avx512* > ... > sed -i 's/#define AVX512F_LEN 256/#define AVX512VL\n#define AVX512F_LEN256/g' > ../gcc/testsuite/gcc.target/i386/avx512vl-* > ... Looking into a couple of cases, it looks OK. Thanks, Uros.
Re: [patch] New std::string implementation
Here's the next version of the std::string rework, this time with
57.1428% more locale facets!
The problem is that there are several facet types that use std::string
in their public interfaces and as the parameters (or worse, as return
types) of virtual functions. It's not possible to overload the
functions to take either the old std::string or the new std::string
because that would add virtual functions to the vtable which is an ABI
change (and you can't overload on return type anyway). The facets are
used deep in the guts of locales and iostreams so need to remain
compatible.
My solution is to add a second version of each affected facet, with
one version using the old ABI and one using the new, but with
otherwise the same behaviour. When a piece of code says
std::use_facet>(someLocale) they get a reference to
the locale's std::collate facet with the same ABI as is in
effect at the call site.
The difficult part is that users can replace a facet to customise
behaviour, so if they replace the old ABI version of
std::collate I need to also replace the new ABI version of the
same facet, using a shim that has the same behaviour as the
user-defined facet (which is achieved by the shim just forwarding to
the user's facet, and converting between std::string representations).
I've also had to add a new virtual function to std::error_category so
you can call error_category::message() (which returns a std::string)
in the context of either ABI. Adding the virtual grows the size of the
vtable in a type that's been exported from libstdc++.so since 4.4.0 so
I moved std::error_category to src/c++11/compatibility-c++0x.cc and
added a new std::_V2::error_category in the same inline namespace used
for a similar switcheroo on std::condition_variable_any
With these changes the entire libstdc++ testsuite passes when using
either ABI, confirming that the library still exports everything
needed for existing code (compiled with GCC <5) to keep working, but
also contains everything for new code (GCC 5+) to work.
Tested x86_64-linux with:
--target_board=unix\{-m32,\}\{,-D_GLIBCXX_USE_CXX11_ABI=0\}
Also tested on powerpc64-linux (where this patch doesn't actually
bootstrap due to PR 63573, there's a patch in the PR that's needed)
and i686-linux.
The Python pretty printers for std::string fail with the new ABI. I'm
not sure why, I think GDB is failing to distinguish between the two
types of std::string. That will only require changes to the python
code though.
patch.txt.bz2
Description: BZip2 compressed data
Re: [C++ PATCH] Allow void type as a literal type in C++14
Ping.
On Fri, Nov 21, 2014 at 06:55:51PM +0100, Marek Polacek wrote:
> I noticed that C++14 [basic.types] says that "a type is a literal type
> if it is: void, [...]". Yet our literal_type_p doesn't consider void
> type as a literal type. The following is an attempt to fix that along
> with a testcase. It seems that void was only added in C++14, so check
> for cxx14 as well.
>
> Bootstrapped/regtested on ppc64-linux, ok for trunk?
>
> 2014-11-21 Marek Polacek
>
> * constexpr.c (literal_type_p): Return true for void type in C++14.
>
> * g++.dg/cpp0x/constexpr-function2.C: Limit dg-error to C++11.
> * g++.dg/cpp0x/constexpr-neg1.C: Likewise.
> * g++.dg/cpp1y/constexpr-void1.C: New test.
>
> diff --git gcc/cp/constexpr.c gcc/cp/constexpr.c
> index 2678223..0a258cf 100644
> --- gcc/cp/constexpr.c
> +++ gcc/cp/constexpr.c
> @@ -59,7 +59,8 @@ literal_type_p (tree t)
> {
>if (SCALAR_TYPE_P (t)
>|| TREE_CODE (t) == VECTOR_TYPE
> - || TREE_CODE (t) == REFERENCE_TYPE)
> + || TREE_CODE (t) == REFERENCE_TYPE
> + || (VOID_TYPE_P (t) && cxx_dialect >= cxx14))
> return true;
>if (CLASS_TYPE_P (t))
> {
> diff --git gcc/testsuite/g++.dg/cpp0x/constexpr-function2.C
> gcc/testsuite/g++.dg/cpp0x/constexpr-function2.C
> index 8c51c9d..95ee244 100644
> --- gcc/testsuite/g++.dg/cpp0x/constexpr-function2.C
> +++ gcc/testsuite/g++.dg/cpp0x/constexpr-function2.C
> @@ -23,7 +23,7 @@ constexpr int area = squarei(side); // { dg-error
> "side|argument" }
> int next(constexpr int x) // { dg-error "parameter" }
> { return x + 1; }
>
> -constexpr void f(int x) // { dg-error "return type .void" }
> +constexpr void f(int x) // { dg-error "return type .void" "" { target
> c++11_only } }
> { /* ... */ }
>
> constexpr int prev(int x)
> diff --git gcc/testsuite/g++.dg/cpp0x/constexpr-neg1.C
> gcc/testsuite/g++.dg/cpp0x/constexpr-neg1.C
> index 35f5e8e..dfa1d6b 100644
> --- gcc/testsuite/g++.dg/cpp0x/constexpr-neg1.C
> +++ gcc/testsuite/g++.dg/cpp0x/constexpr-neg1.C
> @@ -29,7 +29,7 @@ int next(constexpr int x) { // { dg-error "parameter" }
> extern constexpr int memsz; // { dg-error "definition" }
>
> // error: return type is void
> -constexpr void f(int x) // { dg-error "void" }
> +constexpr void f(int x) // { dg-error "void" "" { target
> c++11_only } }
> { /* ... */ }
> // error: use of decrement
> constexpr int prev(int x)
> diff --git gcc/testsuite/g++.dg/cpp1y/constexpr-void1.C
> gcc/testsuite/g++.dg/cpp1y/constexpr-void1.C
> index e69de29..10ef5bc 100644
> --- gcc/testsuite/g++.dg/cpp1y/constexpr-void1.C
> +++ gcc/testsuite/g++.dg/cpp1y/constexpr-void1.C
> @@ -0,0 +1,13 @@
> +// { dg-do compile { target c++14 } }
> +
> +struct S
> +{
> + int i = 20;
> +
> + constexpr void
> + foo (void)
> + {
> +if (i > 20)
> + __builtin_abort ();
> + }
> +};
>
> Marek
Marek
[PATCH PR63941]
Hi All, Here is a simple fix for PR 63941 - wrong assertion for dominating bb which may have true predicate. I deleted it and add setting of non-true predicate for join bb. After this fix test-case is compiled successfully. Bootstrap and regression testing did not show any new failures. Is it OK for trunk? gcc/ChangeLog 2014-11-28 Yuri Rumyantsev PR tree-optimization/63941 * tree-if-conv.c (add_to_predicate_list): Delete wrong assertion that DOM_BB has non-true predicate, conditionally set non-true predicate for BB. gcc/testsuite/ChangeLog * gcc.dg/torture/pr63941.c: New test. patch Description: Binary data
patch to fix PR64087
The following patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64087
The patch was bootstrapped and tested on x86-64.
Committed as rev. 218162.
2014-11-28 Vladimir Makarov
PR rtl-optimization/64087
* lra-lives.c (process_bb_lives): Add debug output.
(lra_create_live_ranges): Don't remove dead insn on the second
call of lra_create_live_ranges_1.
2014-11-28 Vladimir Makarov
PR rtl-optimization/64087
* gcc.dg/pr64087.c: New.
Index: lra-lives.c
===
--- lra-lives.c (revision 218129)
+++ lra-lives.c (working copy)
@@ -971,14 +971,23 @@ process_bb_lives (basic_block bb, int &c
live_pseudos_num++;
if (! sparseset_bit_p (pseudos_live, j))
{
- live_change_p = TRUE;
+ live_change_p = true;
+ if (lra_dump_file != NULL)
+ fprintf (lra_dump_file,
+" r%d is removed as live at bb%d start\n", j, bb->index);
break;
}
}
- live_change_p
-= (live_change_p
- || sparseset_cardinality (pseudos_live) != live_pseudos_num);
-
+ if (! live_change_p
+ && sparseset_cardinality (pseudos_live) != live_pseudos_num)
+{
+ live_change_p = true;
+ if (lra_dump_file != NULL)
+ EXECUTE_IF_SET_IN_SPARSESET (pseudos_live, j)
+ if (! bitmap_bit_p (df_get_live_in (bb), j))
+ fprintf (lra_dump_file,
+" r%d is added to live at bb%d start\n", j, bb->index);
+}
/* See if we'll need an increment at the end of this basic block.
An increment is needed if the PSEUDOS_LIVE set is not empty,
to make sure the finish points are set up correctly. */
@@ -1322,11 +1331,16 @@ lra_create_live_ranges (bool all_p, bool
if (lra_dump_file != NULL)
fprintf (lra_dump_file, "Live info was changed -- recalculate it\n");
/* Live info was changed on a bb border. It means that some info,
- e.g. about conflict regs, calls crossed may be wrong, live
- ranges. We need this info for allocation. So recalcualate it
- again. */
+ e.g. about conflict regs, calls crossed, and live ranges may be
+ wrong. We need this info for allocation. So recalculate it
+ again but without removing dead insns which can change live info
+ again. Repetitive live range calculations are expensive therefore
+ we stop here as we already have correct info although some
+ improvement in rare cases could be possible on this sub-pass if
+ we do dead insn elimination again (still the improvement may
+ happen later). */
lra_clear_live_ranges ();
- bool res = lra_create_live_ranges_1 (all_p, dead_insn_p);
+ bool res = lra_create_live_ranges_1 (all_p, false);
lra_assert (! res);
}
Index: testsuite/gcc.dg/pr64087.c
===
--- testsuite/gcc.dg/pr64087.c (revision 0)
+++ testsuite/gcc.dg/pr64087.c (working copy)
@@ -0,0 +1,35 @@
+/* PR rtl-optimization/64087 */
+/* { dg-do compile } */
+/* { dg-options "-O3" } */
+
+int printf (const char *, ...);
+
+int a[72], b, c, d, e;
+
+int
+main ()
+{
+ int h;
+ for (b = 0; b < 72; b++)
+{
+ h = 1;
+ if (b)
+ h >>= 1;
+ a[b] = h;
+}
+ for (; e; e++)
+for (c = 0; c < 1;)
+ for (; d;)
+ {
+ printf ("0");
+ int g;
+ for (b = 0; b < 72; b++)
+ {
+ g = 1;
+ if (b)
+ g >>= 1;
+ a[b] = g;
+ }
+ }
+ return 0;
+}
attribute handler oddness in MEP and STORMY16 ports
While going through the attribute tables to sort out separation or trees
and types, I'm seeing a couple of ports with similar handlers that look
a little odd.
the code sequence in the handler looks like:
if (TREE_CODE (*node) != VAR_DECL
&& TREE_CODE (*node) != POINTER_TYPE
&& TREE_CODE (*node) != TYPE_DECL)
{
warning (OPT_Wattributes,
"%<__BELOW100__%> attribute only applies to variables");
*no_add_attrs = true;
}
My question is
a) what is POINTER_TYPE doing in there.. what has that got to do with
applying to variables, and
b) should TYPE_DECL also be there?
I can almost see the argument for b) MAYBE, but then the message
doesn't really make sense. but POINTER_TYPE seems really odd.
so ports that use that message:
avr, bfin, x86: handlers all make sure its *ONLY* a VAR_DECL handled
mep, stormy16 : uses the suspect sequence. My guess is one copied the
other.
In fact, the mep port does have a couple of other handlers that check
for only VAR_DECL associated with that warning.
mep also has another handler for "variable and functions" that looks like:
if (TREE_CODE (*node) != VAR_DECL
&& TREE_CODE (*node) != FUNCTION_DECL
&& TREE_CODE (*node) != METHOD_TYPE
&& TREE_CODE (*node) != POINTER_TYPE
&& TREE_CODE (*node) != TYPE_DECL)
{
warning (0, "%qE attribute only applies to variables and functions",
name);
*no_add = true;
}
Most ports use VAR_DECL and FUNCTION_DECL for this warning. Its odd
that METHOD_TYPE is there, but not FUNCTION_TYPE if types were really
handled...
And finally, also in mep :
if (TREE_CODE (*node) != FUNCTION_DECL
&& TREE_CODE (*node) != METHOD_TYPE)
{
warning (0, "%qE attribute only applies to functions", name);
*no_add = true;
}
It doesn't seem that METHOD_TYPE should be there, unless FUNCTION_TYPE
was also important. It does have other handlers where the check is only
for FUNCTION_DECL *OR* FUNCTION_TYPE, not this odd hybrid. It's the
only port that has this.
If the handlers are ONLY going to deal with decls, the attribute table
ought to have the decl_required flag set as well, which the other ports
do, but these 2 do not.. perhaps because of the existing _TYPE handling...?
Assuming I understand this right, I've attached a patch which covers mep
and stormy16. It corrects those tables and handlers to work the way I
think they are suppose to. They build, but I cant test them... can
some with that ability run them and see if they are correct?
Assuming no one has a counter argument to what I'm saying... Maybe there
is some need for this that I'm just missing :-)
Andrew
* config/mep/mep.c (mep_validate_based_tiny): Only deal with VAR_DECL.
(mep_validate_near_far): Only allow VAR_DECL and FUNCTION_DECL.
(mep_validate_disinterrupt): Only allow FUNCTION_DECL.
(mep_attribute_table): Set decl_required field for some handlers.
* config/stormy16/stormy16.c (xstormy16_attribute_table): Set
decl_required field for below100 handler.
(xstormy16_handle_below100_attribute): Only handle VAR_DECL.
Index: config/mep/mep.c
===
*** config/mep/mep.c (revision 217822)
--- config/mep/mep.c (working copy)
*** static tree
*** 3813,3826
mep_validate_based_tiny (tree *node, tree name, tree args,
int flags ATTRIBUTE_UNUSED, bool *no_add)
{
! if (TREE_CODE (*node) != VAR_DECL
! && TREE_CODE (*node) != POINTER_TYPE
! && TREE_CODE (*node) != TYPE_DECL)
{
warning (0, "%qE attribute only applies to variables", name);
*no_add = true;
}
! else if (args == NULL_TREE && TREE_CODE (*node) == VAR_DECL)
{
if (! (TREE_PUBLIC (*node) || TREE_STATIC (*node)))
{
--- 3813,3824
mep_validate_based_tiny (tree *node, tree name, tree args,
int flags ATTRIBUTE_UNUSED, bool *no_add)
{
! if (TREE_CODE (*node) != VAR_DECL)
{
warning (0, "%qE attribute only applies to variables", name);
*no_add = true;
}
! else if (args == NULL_TREE)
{
if (! (TREE_PUBLIC (*node) || TREE_STATIC (*node)))
{
*** mep_validate_near_far (tree *node, tree
*** 3874,3883
int flags ATTRIBUTE_UNUSED, bool *no_add)
{
if (TREE_CODE (*node) != VAR_DECL
! && TREE_CODE (*node) != FUNCTION_DECL
! && TREE_CODE (*node) != METHOD_TYPE
! && TREE_CODE (*node) != POINTER_TYPE
! && TREE_CODE (*node) != TYPE_DECL)
{
warning (0, "%qE attribute only applies to variables and functions",
name);
--- 3872,3878
int flags ATTRIBUTE_UNUSED, bool *no_add)
{
if (TREE_CODE (*node) != VAR_DECL
! && TREE_CODE (*node) != FUNCTION_DECL)
{
warning (0, "%qE attribute only applies to variables and functions",
name);
*** static tree
*** 3910,3917
mep_
[PATCH] Fix ubsan ICE in the shift instrumentation
I forgot to adjust the C++ part of the shift instrumentation as well.
Bootstrapped/regtested on ppc64-linux, ok for trunk?
2014-11-28 Marek Polacek
* c-ubsan.c (ubsan_instrument_shift): Use op1_utype for MINUS_EXPR
instead of unsigned_type_node.
* c-c++-common/ubsan/shift-8.c: New test.
diff --git gcc/c-family/c-ubsan.c gcc/c-family/c-ubsan.c
index 96afc67..5c039ca 100644
--- gcc/c-family/c-ubsan.c
+++ gcc/c-family/c-ubsan.c
@@ -166,7 +166,7 @@ ubsan_instrument_shift (location_t loc, enum tree_code code,
&& !TYPE_UNSIGNED (TREE_TYPE (op0))
&& (cxx_dialect >= cxx11))
{
- tree x = fold_build2 (MINUS_EXPR, unsigned_type_node, uprecm1,
+ tree x = fold_build2 (MINUS_EXPR, op1_utype, uprecm1,
fold_convert (op1_utype, op1));
tt = fold_convert_loc (loc, unsigned_type_for (type0), op0);
tt = fold_build2 (RSHIFT_EXPR, TREE_TYPE (tt), tt, x);
diff --git gcc/testsuite/c-c++-common/ubsan/shift-8.c
gcc/testsuite/c-c++-common/ubsan/shift-8.c
index e69de29..8717f3f 100644
--- gcc/testsuite/c-c++-common/ubsan/shift-8.c
+++ gcc/testsuite/c-c++-common/ubsan/shift-8.c
@@ -0,0 +1,64 @@
+/* { dg-do compile } */
+/* { dg-options "-fsanitize=undefined" } */
+/* { dg-additional-options "-std=gnu11" { target c } } */
+/* { dg-additional-options "-std=c++11" { target c++ } } */
+
+signed char
+fn1 (signed char x, unsigned long y)
+{
+ return x << y;
+}
+
+short int
+fn2 (short int x, unsigned long y)
+{
+ return x << y;
+}
+
+int
+fn3 (int x, unsigned long y)
+{
+ return x << y;
+}
+
+long int
+fn4 (long int x, unsigned long y)
+{
+ return x << y;
+}
+
+long long int
+fn5 (long long int x, unsigned long y)
+{
+ return x << y;
+}
+
+signed char
+fn6 (signed char x, unsigned long long y)
+{
+ return x << y;
+}
+
+short int
+fn7 (short int x, unsigned long long y)
+{
+ return x << y;
+}
+
+int
+fn8 (int x, unsigned long long y)
+{
+ return x << y;
+}
+
+long int
+fn9 (long int x, unsigned long long y)
+{
+ return x << y;
+}
+
+long long int
+fn10 (long long int x, unsigned long long y)
+{
+ return x << y;
+}
Marek
Re: [PATCH] Fix ubsan ICE in the shift instrumentation
On Fri, Nov 28, 2014 at 04:49:28PM +0100, Marek Polacek wrote:
> I forgot to adjust the C++ part of the shift instrumentation as well.
>
> Bootstrapped/regtested on ppc64-linux, ok for trunk?
>
> 2014-11-28 Marek Polacek
>
> * c-ubsan.c (ubsan_instrument_shift): Use op1_utype for MINUS_EXPR
> instead of unsigned_type_node.
>
> * c-c++-common/ubsan/shift-8.c: New test.
Sure, thanks.
> diff --git gcc/c-family/c-ubsan.c gcc/c-family/c-ubsan.c
> index 96afc67..5c039ca 100644
> --- gcc/c-family/c-ubsan.c
> +++ gcc/c-family/c-ubsan.c
> @@ -166,7 +166,7 @@ ubsan_instrument_shift (location_t loc, enum tree_code
> code,
>&& !TYPE_UNSIGNED (TREE_TYPE (op0))
>&& (cxx_dialect >= cxx11))
> {
> - tree x = fold_build2 (MINUS_EXPR, unsigned_type_node, uprecm1,
> + tree x = fold_build2 (MINUS_EXPR, op1_utype, uprecm1,
> fold_convert (op1_utype, op1));
>tt = fold_convert_loc (loc, unsigned_type_for (type0), op0);
>tt = fold_build2 (RSHIFT_EXPR, TREE_TYPE (tt), tt, x);
> diff --git gcc/testsuite/c-c++-common/ubsan/shift-8.c
> gcc/testsuite/c-c++-common/ubsan/shift-8.c
> index e69de29..8717f3f 100644
> --- gcc/testsuite/c-c++-common/ubsan/shift-8.c
> +++ gcc/testsuite/c-c++-common/ubsan/shift-8.c
> @@ -0,0 +1,64 @@
> +/* { dg-do compile } */
> +/* { dg-options "-fsanitize=undefined" } */
> +/* { dg-additional-options "-std=gnu11" { target c } } */
> +/* { dg-additional-options "-std=c++11" { target c++ } } */
> +
> +signed char
> +fn1 (signed char x, unsigned long y)
> +{
> + return x << y;
> +}
> +
> +short int
> +fn2 (short int x, unsigned long y)
> +{
> + return x << y;
> +}
> +
> +int
> +fn3 (int x, unsigned long y)
> +{
> + return x << y;
> +}
> +
> +long int
> +fn4 (long int x, unsigned long y)
> +{
> + return x << y;
> +}
> +
> +long long int
> +fn5 (long long int x, unsigned long y)
> +{
> + return x << y;
> +}
> +
> +signed char
> +fn6 (signed char x, unsigned long long y)
> +{
> + return x << y;
> +}
> +
> +short int
> +fn7 (short int x, unsigned long long y)
> +{
> + return x << y;
> +}
> +
> +int
> +fn8 (int x, unsigned long long y)
> +{
> + return x << y;
> +}
> +
> +long int
> +fn9 (long int x, unsigned long long y)
> +{
> + return x << y;
> +}
> +
> +long long int
> +fn10 (long long int x, unsigned long long y)
> +{
> + return x << y;
> +}
Jakub
Re: C++ PATCH for middle-end/58624 (thread_local static data member)
On Tue, Aug 26, 2014 at 03:38:43PM -0400, Jason Merrill wrote:
> commit ccf3f3b41516b34d7d564bed1b3f4e3cf270e43a
> Author: Jason Merrill
> Date: Tue Aug 26 13:56:17 2014 -0400
>
> PR c++/58624
> * pt.c (tsubst_decl) [VAR_DECL]: Copy TLS model.
> (tsubst_copy_and_build) [VAR_DECL]: Use TLS wrapper.
> * semantics.c (finish_id_expression): Don't call TLS wrapper in a
> template.
>
> --- /dev/null
> +++ b/gcc/testsuite/g++.dg/tls/thread_local10.C
> @@ -0,0 +1,23 @@
> +// PR c++/58624
> +
> +// { dg-do run { target c++11 } }
> +// { dg-add-options tls }
> +// { dg-require-effective-target tls_runtime }
> +
> +int i;
> +
> +template struct A
> +{
> + static thread_local int s;
> +
> + A () { i = s; }
> +};
> +
> +int f() { return 42; }
> +template thread_local int A::s = f();
> +
> +int main () {
> + A a;
> + if (i != 42)
> +__builtin_abort();
> +}
Note that this has been committed to 4.8 branch too in r216273,
but there this testcase FAILs:
thread_local10.C:11:10: error: ‘thread_local’ does not name a type
static thread_local int s;
^
thread_local10.C: In constructor ‘A< >::A()’:
thread_local10.C:13:14: error: ‘s’ was not declared in this scope
A () { i = s; }
^
thread_local10.C: At global scope:
thread_local10.C:17:23: error: ‘thread_local’ does not name a type
template thread_local int A::s = f();
^
The problem is that something adds -ansi -pedantic-errors after the
-std=c++11, but I couldn't figure out what. Perhaps just use
// { dg-options "" } before dg-add-options?
Jakub
Re: [PATCH diagnostics/fortran] dynamically generate locations from offset + handle %C
Hi Dodji, On 23 October 2014 at 13:11, Dodji Seketeli wrote: > /* If MAP is not the last line map of its set, then the new location >(loc + offset) should be less than the first location encoded by >the next line map of the set. */ which is currently implemented as: if (map != LINEMAPS_LAST_ORDINARY_MAP (set)) linemap_assert (loc + offset < MAP_START_LOCATION (&map[1])); However, this can easily trigger in Fortran, for example, when adding one line adds a new map, the location of the new map is 1 + set->highest_location. If the highest_location corresponds to the start of the previous line (because Fortran does not actually track columns yet with line-maps) then any offset will trigger this. One solution could be to make the new map's start location = set->highest_location + set->max_column_hint, but I'm not sure if there is a more conservative approach. I'm going to propose a patch that changes the asserts to assert only if checking otherwise return loc unchanged. That seems safer than giving a wildly inaccurate location. Cheers, Manuel.
[patch] Fix ICE on unaligned record field
Hi,
the attached Ada testcase triggers an assertion in the RTL expander for the
address operator because the operator has been applied to a non-byte-aligned
record field. The problematic ADDR_EXPR is built by ipa_modify_call_arguments
which has a hole when get_addr_base_and_unit_offset returns NULL_TREE: the
variable offset case is handled but not the non-byte-aligned case, which can
rountinely happen in Ada, hence the proposed fix.
Tested on x86_64-suse-linux, OK for the mainline?
2014-11-28 Eric Botcazou
* ipa-prop.c (ipa_modify_call_arguments): Properly deal with unaligned
aggregate parameters passed by value.
2014-11-28 Eric Botcazou
* gnat.dg/specs/pack12.ads: New test.
--
Eric BotcazouIndex: ipa-prop.c
===
--- ipa-prop.c (revision 218133)
+++ ipa-prop.c (working copy)
@@ -3939,6 +3939,39 @@ ipa_modify_call_arguments (struct cgraph
/* Aggregate arguments can have non-invariant addresses. */
if (!base)
{
+ /* ??? If the original aggregate is passed by value, it may
+ be not aligned on a unit boundary, in which case taking
+ directly its address below is forbidden. Unfortunately
+ get_addr_base_and_unit_offset doesn't differentiate its
+ two failure modes so we need to get our hands dirty. */
+ if (!addrof)
+ {
+ tree offset;
+ HOST_WIDE_INT bitsize, bitpos;
+ machine_mode mode;
+ int unsignedp, volatilep = 0;
+ get_inner_reference (prev_base, &bitsize, &bitpos,
+ &offset, &mode, &unsignedp,
+ &volatilep, false);
+ if (bitpos % BITS_PER_UNIT)
+ {
+ tree tmp
+ = create_tmp_reg (TREE_TYPE (prev_base), NULL);
+ tree *argp
+ = gimple_call_arg_ptr (stmt, adj->base_index);
+ gimple tem = gimple_build_assign (tmp, prev_base);
+ tree vuse = gimple_vuse (stmt);
+ tree new_vdef = copy_ssa_name (vuse, tem);
+ gimple_set_vuse (tem, vuse);
+ gimple_set_vdef (tem, new_vdef);
+ SET_USE (gimple_vuse_op (stmt), new_vdef);
+ /* Insert the temporary ahead of every subsequent
+ adjustment and replace the argument in the call
+ in case it is referenced more than once. */
+ gsi_insert_after (&prev_gsi, tem, GSI_SAME_STMT);
+ *argp = prev_base = tmp;
+ }
+ }
base = build_fold_addr_expr (prev_base);
off = build_int_cst (adj->alias_ptr_type,
adj->offset / BITS_PER_UNIT);
-- { dg-do compile }
-- { dg-options "-O2" }
package Pack12 is
type Rec1 is record
B : Boolean;
N : Natural;
end record;
type Rec2 is record
B : Boolean;
R : Rec1;
end record;
pragma Pack (Rec2);
type Rec3 is tagged record
R : Rec2;
end record;
end Pack12;
Re: [RFC] Wrong "current" pointers with bitmap_ior and bitmap_ior_and_compl
On Nov 28, 2014, at 4:03 AM, Richard Biener wrote: > On Fri, Nov 28, 2014 at 11:37 AM, Kaz Kojima wrote: >> Hi, >> >> I've got odd ICEs with some bitmap operations when working on >> sh-lra branch. >> bitmap_ior and bitmap_ior_and_compl are the bitmap operations >> for DST = A | B and DST = A | (B & ~KILL) respectively. It >> looks they could make bitmaps with the wrong "current" pointer. >> One small example is >> >> DST: [(bit 0, bit 127), indx=0] <-> [(bit 151), indx=1] -> 0 >> A: [(bit 141), indx=1] -> 0 >> B: [(bit 142), indx=1] -> 0 >> >> where assuming that BITMAP_ELEMENT_ALL_BITS is 128. >> In this case, bitmap_ior makes DST into the list >> >> [(bit 141, bit 142), indx=1] <-> [(bit 151), indx=1] -> 0 >> >> and unlinks the second element with bitmap_elt_clear_from. >> If the "current" pointer of DST pointed the 2nd element, >> the current pointer points the element freed from the list: >> >> DST: [(bit 141, bit 142), indx=1] -> 0 >> DST->current: [(bit 151), indx=1] >> >> even after bitmap_elt_clear_from done. >> bitmap_elt_clear_from has the code to fix the current pointer >> for the correct list of which elements have strictly ascending >> indx values. It doesn't work for the above list because its >> elements have the same indx. >> It seems that bitmap_and, bitmap_and_compl and bitmap_xor have >> the line to avoid this issue already. The patch below adds >> the same line to bitmap_ior and bitmap_ior_and_compl. >> The patch is tested on i686-pc-linux-gnu with bootstrap and >> the top level "make -k check". > > Huh? Wasn't this fixed by Mike a few weeks ago? While I had testing on my target, there were plenty of other regressions from trunk intermixed, so I wanted to do a normal bootstrap on Linux which I had not done yet. Kaz, you can check your patch, if the same, pretty sure it is, it has been approved and you can just check your version in, since you have the testing on it. Richard didn't want the extra testing my patch. >>* bitmap.c (bitmap_ior): Reset the current pointer before calling >>bitmap_elt_clear_from. >>(bitmap_ior_and_compl): Likewise.
Re: [PATCH, AARCH64] Fix ICE in CCMP (PR64015)
On 11/26/2014 10:23 AM, Zhenqiang Chen wrote: > /* Check to make sure CC is not clobbered since prepare_operand might > generates copy or mode convertion insns, although no test shows > such insns clobber CC. */ And what do you do if a clobber does happen? With TER enabled, there's every possibility that it might be. > Does such change align with your comments? Not really, no. r~
Re: [patch] New std::string implementation
On 28/11/14 15:24 +, Jonathan Wakely wrote:
Tested x86_64-linux with:
--target_board=unix\{-m32,\}\{,-D_GLIBCXX_USE_CXX11_ABI=0\}
Also tested on powerpc64-linux (where this patch doesn't actually
bootstrap due to PR 63573, there's a patch in the PR that's needed)
and i686-linux.
Oh how silly, the attached patch is needed for powerpc. I had fixed
this once, but must have lost the change on the compile farm machine I
was using and then not committed the fix in my local repo. The
attached patch also includes the PR63573 fix which isn't committed
yet.
I've committed the libstdc++ parts (but not the PR fix) to my repo
now, so it won't get lost again.
diff --git a/gcc/tree-inline.c b/gcc/tree-inline.c
index d4864ae..dd8142e 100644
--- a/gcc/tree-inline.c
+++ b/gcc/tree-inline.c
@@ -1617,8 +1617,12 @@ remap_gimple_stmt (gimple stmt, copy_body_data *id)
/* Clear flags that need revisiting. */
if (gcall *call_stmt = dyn_cast (copy))
- if (gimple_call_tail_p (call_stmt))
- gimple_call_set_tail (call_stmt, false);
+ {
+ if (gimple_call_tail_p (call_stmt))
+ gimple_call_set_tail (call_stmt, false);
+ if (gimple_call_from_thunk_p (call_stmt))
+ gimple_call_set_from_thunk (call_stmt, false);
+ }
/* Remap the region numbers for __builtin_eh_{pointer,filter},
RESX and EH_DISPATCH. */
diff --git a/libstdc++-v3/include/bits/locale_facets.h
b/libstdc++-v3/include/bits/locale_facets.h
index e8f9e67..77838b0 100644
--- a/libstdc++-v3/include/bits/locale_facets.h
+++ b/libstdc++-v3/include/bits/locale_facets.h
@@ -2216,8 +2216,7 @@ _GLIBCXX_BEGIN_NAMESPACE_LDBL
double&) const;
// XXX GLIBCXX_ABI Deprecated
-#if defined _GLIBCXX_LONG_DOUBLE_COMPAT && defined __LONG_DOUBLE_128__ \
- && _GLIBCXX_USE_CXX11_ABI == 0
+#if defined _GLIBCXX_LONG_DOUBLE_COMPAT && defined __LONG_DOUBLE_128__
virtual iter_type
__do_get(iter_type, iter_type, ios_base&, ios_base::iostate&,
double&) const;
@@ -2231,8 +2230,7 @@ _GLIBCXX_BEGIN_NAMESPACE_LDBL
do_get(iter_type, iter_type, ios_base&, ios_base::iostate&, void*&)
const;
// XXX GLIBCXX_ABI Deprecated
-#if defined _GLIBCXX_LONG_DOUBLE_COMPAT && defined __LONG_DOUBLE_128__ \
- && _GLIBCXX_USE_CXX11_ABI == 0
+#if defined _GLIBCXX_LONG_DOUBLE_COMPAT && defined __LONG_DOUBLE_128__
virtual iter_type
do_get(iter_type, iter_type, ios_base&, ios_base::iostate&,
long double&) const;
@@ -2501,8 +2499,7 @@ _GLIBCXX_BEGIN_NAMESPACE_LDBL
do_put(iter_type, ios_base&, char_type, double) const;
// XXX GLIBCXX_ABI Deprecated
-#if defined _GLIBCXX_LONG_DOUBLE_COMPAT && defined __LONG_DOUBLE_128__ \
- && _GLIBCXX_USE_CXX11_ABI == 0
+#if defined _GLIBCXX_LONG_DOUBLE_COMPAT && defined __LONG_DOUBLE_128__
virtual iter_type
__do_put(iter_type, ios_base&, char_type, double) const;
#else
@@ -2514,8 +2511,7 @@ _GLIBCXX_BEGIN_NAMESPACE_LDBL
do_put(iter_type, ios_base&, char_type, const void*) const;
// XXX GLIBCXX_ABI Deprecated
-#if defined _GLIBCXX_LONG_DOUBLE_COMPAT && defined __LONG_DOUBLE_128__ \
- && _GLIBCXX_USE_CXX11_ABI == 0
+#if defined _GLIBCXX_LONG_DOUBLE_COMPAT && defined __LONG_DOUBLE_128__
virtual iter_type
do_put(iter_type, ios_base&, char_type, long double) const;
#endif
diff --git a/libstdc++-v3/include/bits/locale_facets.tcc
b/libstdc++-v3/include/bits/locale_facets.tcc
index 23e87d0..306d3a6 100644
--- a/libstdc++-v3/include/bits/locale_facets.tcc
+++ b/libstdc++-v3/include/bits/locale_facets.tcc
@@ -712,8 +712,7 @@ _GLIBCXX_BEGIN_NAMESPACE_LDBL
return __beg;
}
-#if defined _GLIBCXX_LONG_DOUBLE_COMPAT && defined __LONG_DOUBLE_128__ \
- && _GLIBCXX_USE_CXX11_ABI == 0
+#if defined _GLIBCXX_LONG_DOUBLE_COMPAT && defined __LONG_DOUBLE_128__
template
_InIter
num_get<_CharT, _InIter>::
@@ -1156,8 +1155,7 @@ _GLIBCXX_BEGIN_NAMESPACE_LDBL
do_put(iter_type __s, ios_base& __io, char_type __fill, double __v) const
{ return _M_insert_float(__s, __io, __fill, char(), __v); }
-#if defined _GLIBCXX_LONG_DOUBLE_COMPAT && defined __LONG_DOUBLE_128__ \
- && _GLIBCXX_USE_CXX11_ABI == 0
+#if defined _GLIBCXX_LONG_DOUBLE_COMPAT && defined __LONG_DOUBLE_128__
template
_OutIter
num_put<_CharT, _OutIter>::
[committed] 4.8 backports
Hi!
I've committed following backports to 4.8 branch, after
bootstrapping/regtesting on x86_64-linux and i686-linux.
Jakub
2014-11-28 Jakub Jelinek
Backported from mainline
2014-10-03 Jakub Jelinek
PR libgomp/61200
* omp-low.c (taskreg_contexts): New variable.
(scan_omp_parallel): Push newly created context into taskreg_contexts
vector and move record layout code to finish_taskreg_scan.
(scan_omp_task): Likewise.
(finish_taskreg_scan): New function.
(execute_lower_omp): Call finish_taskreg_scan on all taskreg_contexts
vector elements and release it.
* c-c++-common/gomp/pr61200.c: New test.
* testsuite/libgomp.c/pr61200.c: New test.
--- gcc/omp-low.c (revision 215834)
+++ gcc/omp-low.c (revision 215835)
@@ -128,6 +128,7 @@ static splay_tree all_contexts;
static int taskreg_nesting_level;
struct omp_region *root_omp_region;
static bitmap task_shared_vars;
+static vec taskreg_contexts;
static void scan_omp (gimple_seq *, omp_context *);
static tree scan_omp_1_op (tree *, int *, void *);
@@ -1655,6 +1656,7 @@ scan_omp_parallel (gimple_stmt_iterator
}
ctx = new_omp_context (stmt, outer_ctx);
+ taskreg_contexts.safe_push (ctx);
if (taskreg_nesting_level > 1)
ctx->is_nested = true;
ctx->field_map = splay_tree_new (splay_tree_compare_pointers, 0, 0);
@@ -1674,11 +1676,6 @@ scan_omp_parallel (gimple_stmt_iterator
if (TYPE_FIELDS (ctx->record_type) == NULL)
ctx->record_type = ctx->receiver_decl = NULL;
- else
-{
- layout_type (ctx->record_type);
- fixup_child_record_type (ctx);
-}
}
/* Scan an OpenMP task directive. */
@@ -1689,7 +1686,6 @@ scan_omp_task (gimple_stmt_iterator *gsi
omp_context *ctx;
tree name, t;
gimple stmt = gsi_stmt (*gsi);
- location_t loc = gimple_location (stmt);
/* Ignore task directives with empty bodies. */
if (optimize > 0
@@ -1700,6 +1696,7 @@ scan_omp_task (gimple_stmt_iterator *gsi
}
ctx = new_omp_context (stmt, outer_ctx);
+ taskreg_contexts.safe_push (ctx);
if (taskreg_nesting_level > 1)
ctx->is_nested = true;
ctx->field_map = splay_tree_new (splay_tree_compare_pointers, 0, 0);
@@ -1737,8 +1734,71 @@ scan_omp_task (gimple_stmt_iterator *gsi
t = build_int_cst (long_integer_type_node, 1);
gimple_omp_task_set_arg_align (stmt, t);
}
+}
+
+
+/* If any decls have been made addressable during scan_omp,
+ adjust their fields if needed, and layout record types
+ of parallel/task constructs. */
+
+static void
+finish_taskreg_scan (omp_context *ctx)
+{
+ if (ctx->record_type == NULL_TREE)
+return;
+
+ /* If any task_shared_vars were needed, verify all
+ OMP_CLAUSE_SHARED clauses on GIMPLE_OMP_{PARALLEL,TASK}
+ statements if use_pointer_for_field hasn't changed
+ because of that. If it did, update field types now. */
+ if (task_shared_vars)
+{
+ tree c;
+
+ for (c = gimple_omp_taskreg_clauses (ctx->stmt);
+ c; c = OMP_CLAUSE_CHAIN (c))
+ if (OMP_CLAUSE_CODE (c) == OMP_CLAUSE_SHARED)
+ {
+ tree decl = OMP_CLAUSE_DECL (c);
+
+ /* Global variables don't need to be copied,
+ the receiver side will use them directly. */
+ if (is_global_var (maybe_lookup_decl_in_outer_ctx (decl, ctx)))
+ continue;
+ if (!bitmap_bit_p (task_shared_vars, DECL_UID (decl))
+ || !use_pointer_for_field (decl, ctx))
+ continue;
+ tree field = lookup_field (decl, ctx);
+ if (TREE_CODE (TREE_TYPE (field)) == POINTER_TYPE
+ && TREE_TYPE (TREE_TYPE (field)) == TREE_TYPE (decl))
+ continue;
+ TREE_TYPE (field) = build_pointer_type (TREE_TYPE (decl));
+ TREE_THIS_VOLATILE (field) = 0;
+ DECL_USER_ALIGN (field) = 0;
+ DECL_ALIGN (field) = TYPE_ALIGN (TREE_TYPE (field));
+ if (TYPE_ALIGN (ctx->record_type) < DECL_ALIGN (field))
+ TYPE_ALIGN (ctx->record_type) = DECL_ALIGN (field);
+ if (ctx->srecord_type)
+ {
+ tree sfield = lookup_sfield (decl, ctx);
+ TREE_TYPE (sfield) = TREE_TYPE (field);
+ TREE_THIS_VOLATILE (sfield) = 0;
+ DECL_USER_ALIGN (sfield) = 0;
+ DECL_ALIGN (sfield) = DECL_ALIGN (field);
+ if (TYPE_ALIGN (ctx->srecord_type) < DECL_ALIGN (sfield))
+ TYPE_ALIGN (ctx->srecord_type) = DECL_ALIGN (sfield);
+ }
+ }
+}
+
+ if (gimple_code (ctx->stmt) == GIMPLE_OMP_PARALLEL)
+{
+ layout_type (ctx->record_type);
+ fixup_child_record_type (ctx);
+}
else
{
+ location_t loc = gimple_location (ctx->stmt);
tree *p, vla_fields = NULL_TREE, *q = &vla_fields;
/* Move VLA fields to the end. */
p = &TYPE_FIELDS (ctx->record_type);
@@ -175
[PATCHv5][PING^4] Vimrc config with GNU formatting
On 11/06/2014 01:31 PM, Yury Gribov wrote:
On 10/21/2014 07:24 PM, Yury Gribov wrote:
On 10/13/2014 02:26 PM, Yury Gribov wrote:
On 10/02/2014 09:14 PM, Yury Gribov wrote:
On 09/17/2014 09:08 PM, Yury Gribov wrote:
> On 09/16/2014 08:38 PM, Yury Gribov wrote:
>> Hi all,
>>
>> This is the third version of the patch. A list of changes since
last
>> version:
>> * move config to contrib so that it's _not_ enabled by default
(current
>> score is 2/1 in favor of no Vim config by default)
>> * update Makefile.in to make .local.vimrc if developer asks for it
>> * disable autoformatting for flex files
>> * fix filtering of non-GNU sources (libsanitizer)
>> * added some small fixes in cinoptions based on feedback from
community
>>
>> As noted by Richard, the config does not do a good job of
formatting
>> unbound {} blocks e.g.
>> void
>> foo ()
>> {
>>int x;
>> {
>>// I'm an example of bad bad formatting
>> }
>> }
>> but it seems to be the best we can get with Vim's cindent
>> (and I don't think anyone seriously considers writing a custom
>> indentexpr).
>>
>> Ok to commit?
>
> New vesion with support for another popular local .vimrc plugin.
Hi all,
Here is a new vesion of vimrc patch. Hope I got email settings right
this time.
Changes since v4:
* fixed and enhanced docs
* added support for .lvimrc in Makefile
* minor fixes in cinoptions and formatoptions (reported by Segher)
* removed shiftwidth settings (as it does not really relate to code
formatting)
commit 3f560e9dd16a5e914b6f2ba82edffe13dfde944c
Author: Yury Gribov
Date: Thu Oct 2 15:50:52 2014 +0400
2014-10-02 Laurynas Biveinis
Yury Gribov
Vim config with GNU formatting.
contrib/
* vimrc: New file.
/
* .gitignore: Added .local.vimrc and .lvimrc.
* Makefile.tpl (vimrc, .lvimrc, .local.vimrc): New targets.
* Makefile.in: Regenerate.
diff --git a/.gitignore b/.gitignore
index e9b56be..ab97ac6 100644
--- a/.gitignore
+++ b/.gitignore
@@ -32,6 +32,9 @@ POTFILES
TAGS
TAGS.sub
+.local.vimrc
+.lvimrc
+
.gdbinit
.gdb_history
diff --git a/Makefile.in b/Makefile.in
index d6105b3..f3a34af 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -2384,6 +2384,18 @@ mail-report-with-warnings.log: warning.log
chmod +x $@
echo If you really want to send e-mail, run ./$@ now
+# Local Vim config
+
+$(srcdir)/.local.vimrc:
+ $(LN_S) $(srcdir)/contrib/vimrc $@
+
+$(srcdir)/.lvimrc:
+ $(LN_S) $(srcdir)/contrib/vimrc $@
+
+vimrc: $(srcdir)/.local.vimrc $(srcdir)/.lvimrc
+
+.PHONY: vimrc
+
# Installation targets.
.PHONY: install uninstall
diff --git a/Makefile.tpl b/Makefile.tpl
index f7c7e38..b98930c 100644
--- a/Makefile.tpl
+++ b/Makefile.tpl
@@ -867,6 +867,18 @@ mail-report-with-warnings.log: warning.log
chmod +x $@
echo If you really want to send e-mail, run ./$@ now
+# Local Vim config
+
+$(srcdir)/.local.vimrc:
+ $(LN_S) $(srcdir)/contrib/vimrc $@
+
+$(srcdir)/.lvimrc:
+ $(LN_S) $(srcdir)/contrib/vimrc $@
+
+vimrc: $(srcdir)/.local.vimrc $(srcdir)/.lvimrc
+
+.PHONY: vimrc
+
# Installation targets.
.PHONY: install uninstall
diff --git a/contrib/vimrc b/contrib/vimrc
new file mode 100644
index 000..34e8f35
--- /dev/null
+++ b/contrib/vimrc
@@ -0,0 +1,45 @@
+" Code formatting settings for Vim.
+"
+" To enable this for GCC files by default, you can either source this file
+" in your .vimrc via autocmd:
+" :au BufNewFile,BufReadPost path/to/gcc/* :so path/to/gcc/contrib/vimrc
+" or source the script manually for each newly opened file:
+" :so contrib/vimrc
+" You could also use numerous plugins that enable local vimrc e.g.
+" mbr's localvimrc or thinca's vim-localrc (but note that the latter
+" is much less secure). To install local vimrc config, run
+" $ make vimrc
+" from GCC build folder.
+"
+" Copyright (C) 2014 Free Software Foundation, Inc.
+"
+" This program is free software; you can redistribute it and/or modify
+" it under the terms of the GNU General Public License as published by
+" the Free Software Foundation; either version 3 of the License, or
+" (at your option) any later version.
+"
+" This program is distributed in the hope that it will be useful,
+" but WITHOUT ANY WARRANTY; without even the implied warranty of
+" MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+" GNU General Public License for more details.
+"
+" You should have received a copy of the GNU General Public License
+" along with this program. If not, see
Re: [PATCH] Fix PR64084
On Thu, Nov 27, 2014 at 6:48 AM, Richard Biener wrote: > > Currently the order in which patterns in match.pd match is pretty > random (well, it's deterministic of course). This is bad if there > are multiple possible matches such as in > > z = x + 1; > w = z + 0; > > where we have both z + 0 -> z and (x + 1) + 0 -> x + (1 + 0). > Currently the latter happens to be applied and thus we simplify to > > z = x + 1; > w = x + 1; > > which is bad for propagation engines which only handle constant > or SSA name results (and also either generates redundant code or leaves > dead code). > > Thus the following patch makes sure that if there are multiple > matches possible then the pattern first appearing in match.pd > is chosen. > > This slightly increases the number of instructions executed during > the matching in the worst case but is certainly the best course > of action here (other possibilities are to make the patterns > disjunct by disabling the latter for the + 0 case). At least > it matches how other generated matchers behave. > > Bootstrap and regtest running on x86_64-unknown-linux-gnu. > > Richard. > > 2014-11-27 Richard Biener > > PR middle-end/64084 > * genmatch.c (dt_node::gen_kids_1): New function, split out > from dt_node::gen_kids. > (decision_tree::cmp_node): DT_TRUE are generally not equal. > (decision_tree::find_node): Treat DT_TRUE as barrier for > node CSE on the same level. > (dt_node::append_node): Do not keep DT_TRUE last. > (dt_node::gen_kids): Emit code after each DT_TRUE node seen. This caused: FAIL: gcc.dg/pr37289.c scan-tree-dump original "-\\(long unsigned int\\) x" on x86. -- H.J.
Re: RFC: Building a minimal libgfortran for nvptx
On 11/14/2014 10:28 PM, Tobias Burnus wrote: All in all: Okay when tesing succeeded. I still prefer some words what's excluded (or included) in minimal as comment in configure.ac, but the patch is also okay without. I thought you meant something more than adding a comment. I've added this in the configure script, and committed the patch after testing: # For GPU offloading, not everything in libfortran can be supported. # Currently, the only target that has this problem is nvptx. The # following is a (partial) list of features that are unsupportable on # this particular target: # * Constructors # * alloca # * C library support for I/O, with printf as the one notable exception # * C library support for other features such as signal, environment # variables, time functions I wouldn't worry too much about breaking nvptx by accident, we can surely clean up any such problems should they arise. Bernd
Re: [patch testsuite gcc.dg]: Turn of ms-extensions for mingw target
On Fri, 28 Nov 2014, Kai Tietz wrote: > Hi, > > this patch turns off ms-extensions for mingw-targets to match > diagnostics checked in testcases. > > Ok for apply? For the tests using -std= -pedantic (or -pedantic-errors), are you saying the diagnostics are *different*, or that some constructs (that are invalid in the relevant ISO standard) are *not diagnosed at all*? If the latter, it's a bug in the MinGW port - when a conformance mode is selected, the constructs invalid in that mode must be diagnosed appropriately, independent of the target. You could for example disable ms-extensions if flag_iso, although it might be better to distinguish explicit and implicit ms-extensions and have the (pedantic, only OK because of implicit ms-extensions) case give a pedwarn and then continue with what it would have done with the extension enabled. -- Joseph S. Myers jos...@codesourcery.com
Re: [patch testsuite gcc.dg]: Turn of ms-extensions for mingw target
2014-11-28 18:53 GMT+01:00 Joseph Myers : > On Fri, 28 Nov 2014, Kai Tietz wrote: > >> Hi, >> >> this patch turns off ms-extensions for mingw-targets to match >> diagnostics checked in testcases. >> >> Ok for apply? > > For the tests using -std= -pedantic (or > -pedantic-errors), are you saying the diagnostics are *different*, or that > some constructs (that are invalid in the relevant ISO standard) are *not > diagnosed at all*? If the latter, it's a bug in the MinGW port - when a > conformance mode is selected, the constructs invalid in that mode must be > diagnosed appropriately, independent of the target. You could for example > disable ms-extensions if flag_iso, although it might be better to > distinguish explicit and implicit ms-extensions and have the (pedantic, > only OK because of implicit ms-extensions) case give a pedwarn and then > continue with what it would have done with the extension enabled. > > -- > Joseph S. Myers > jos...@codesourcery.com Some diagnostics are different and some constructs getting allowed with enabled ms-extensions flag. Additionally is the pedantic-flag not automatically set for *-*-mingw* targets. So for enforcing ISO-C++ pedantic checks the *-*-mingw* targets need to have explicit set the -pedantic flag (which is on for some other targets by default). Kai
Re: [patch testsuite gcc.dg]: Turn of ms-extensions for mingw target
On Fri, 28 Nov 2014, Kai Tietz wrote: > Some diagnostics are different and some constructs getting allowed > with enabled ms-extensions flag. Additionally is the pedantic-flag > not automatically set for *-*-mingw* targets. So for enforcing > ISO-C++ pedantic checks the *-*-mingw* targets need to have explicit > set the -pedantic flag (which is on for some other targets by > default). It seems very odd for the default dg-options to vary depending on target - where is that target-dependent default set? But for my main point: -std=c11 -pedantic-errors must diagnose with an error anything where C11 requires a diagnostic. Not "anything where C11 requires a diagnostic, except for certain extensions on MinGW targets". It must not be necessary to add -fno-ms-extensions for such diagnostics; the options for conformance must not depend on the target. So for the cases where the test uses -std= -pedantic/-pedantic-errors, you need to fix the port: the test failures are showing up an actual bug in the port, and the tests are correct as-is. The same principle of course applies to C++ tests, though I didn't examine your changes to those to see if the same issue applies to any of those changes. -- Joseph S. Myers jos...@codesourcery.com
Re: [patch testsuite gcc.dg]: Turn of ms-extensions for mingw target
2014-11-28 19:10 GMT+01:00 Joseph Myers : > On Fri, 28 Nov 2014, Kai Tietz wrote: > >> Some diagnostics are different and some constructs getting allowed >> with enabled ms-extensions flag. Additionally is the pedantic-flag >> not automatically set for *-*-mingw* targets. So for enforcing >> ISO-C++ pedantic checks the *-*-mingw* targets need to have explicit >> set the -pedantic flag (which is on for some other targets by >> default). > > It seems very odd for the default dg-options to vary depending on target - > where is that target-dependent default set? True, I was curious to see this difference too. > But for my main point: -std=c11 -pedantic-errors must diagnose with an > error anything where C11 requires a diagnostic. Not "anything where C11 > requires a diagnostic, except for certain extensions on MinGW targets". > It must not be necessary to add -fno-ms-extensions for such diagnostics; > the options for conformance must not depend on the target. So for the > cases where the test uses -std= > -pedantic/-pedantic-errors, you need to fix the port: the test failures > are showing up an actual bug in the port, and the tests are correct as-is. > The same principle of course applies to C++ tests, though I didn't examine > your changes to those to see if the same issue applies to any of those > changes. How so? That ms-extensions are enabled by default is all the port does. The rest is done in FEs, and indeed the diagnostic here about handling ms-extensions, or on standard-case seems to be buggy. To depend in testsuite on implicit set flags seems to be a bug too. So I can't follow you that it is a port issue. .. Kai Tietz kti...@redhat.com > -- > Joseph S. Myers > jos...@codesourcery.com
[PATCH] Use = NULL default value for {make,copy}_ssa_name and create_tmp_{reg,var{,_raw}} last argument
Hi! As the following patch shows, , NULL) is passed to these 5 functions way too often that forcing everybody to spell it everywhere seems to verbose, leading to formatting issues and making code less readable. Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? As possible follow-up, I wonder if gimple_build_assign_with_ops isn't too long and too verbose either, couldn't we just use overloads of gimple_build_assign instead? Either with the argument order of gimple_build_assign_with_ops, i.e. tree_code, lhs, operands... , or perhaps swap the lhs and tree_code, so lhs, tree_code, operands... In either case, I'd find it to be pretty much unambiguous with the current two operand gimple_build_assign which takes lhs, treeop, the presence of enum tree_code would make it obvious that you are supplying ops for it rather than building it from what is extracted from the tree. Thoughts on that? 2014-11-28 Jakub Jelinek * gimple-expr.h (create_tmp_var_raw, create_tmp_var, create_tmp_reg): Add default NULL value to last argument. * tree-ssanames.h (make_ssa_name, copy_ssa_name): Likewise. * gimple-low.c (lower_builtin_posix_memalign): Remove NULL last argument from create_tmp_var_raw, create_tmp_var, create_tmp_reg, make_ssa_name and copy_ssa_name calls. * tree-ssa-strlen.c (get_string_length): Likewise. * tree-emutls.c (gen_emutls_addr, lower_emutls_1): Likewise. * tree-ssa-phiprop.c (phiprop_insert_phi): Likewise. * tree-vect-slp.c (vect_get_constant_vectors): Likewise. * ipa-prop.c (ipa_modify_call_arguments): Likewise. * tree-ssa-forwprop.c (simplify_rotate): Likewise. * tree-ssa-ccp.c (fold_builtin_alloca_with_align): Likewise. * asan.c (build_shadow_mem_access, maybe_create_ssa_name, maybe_cast_to_ptrmode, asan_expand_check_ifn): Likewise. * tsan.c (instrument_expr, instrument_builtin_call, instrument_func_entry): Likewise. * varpool.c (add_new_static_var): Likewise. * tree-loop-distribution.c (generate_memset_builtin): Likewise. * gimplify.c (internal_get_tmp_var, gimplify_return_expr, gimplify_modify_expr_to_memcpy, gimplify_modify_expr_to_memset, gimplify_init_ctor_eval_range, gimplify_init_constructor, gimplify_omp_atomic, gimplify_expr): Likewise. * gimple-builder.c (build_assign, build_type_cast): Likewise. * tree-vect-loop-manip.c (slpeel_update_phi_nodes_for_guard1, slpeel_update_phi_nodes_for_guard2, slpeel_tree_peel_loop_to_edge, vect_loop_versioning): Likewise. * tree-if-conv.c (version_loop_for_if_conversion): Likewise. * gimple-match-head.c (maybe_push_res_to_seq): Likewise. * tree-vect-patterns.c (vect_handle_widen_op_by_const, vect_recog_widen_mult_pattern, vect_operation_fits_smaller_type, vect_recog_over_widening_pattern): Likewise. * tree-sra.c (build_ref_for_offset, create_access_replacement): Likewise. * tree-cfg.c (make_blocks): Likewise. * tree-eh.c (lower_eh_constructs_2, lower_resx, lower_eh_dispatch): Likewise. * tree-ssa-propagate.c (update_call_from_tree): Likewise. * tree-complex.c (get_component_ssa_name, expand_complex_div_wide): Likewise. * tree-ssa-math-opts.c (build_and_insert_cast): Likewise. * tree-tailcall.c (update_accumulator_with_ops): Likewise. * tree-predcom.c (initialize_root_vars, initialize_root_vars_lm, execute_load_motion, reassociate_to_the_same_stmt): Likewise. * tree-ssa-reassoc.c (build_and_add_sum, optimize_range_tests_to_bit_test, update_ops, maybe_optimize_range_tests, rewrite_expr_tree, linearize_expr, negate_value, repropagate_negates): Likewise. * tree-vect-loop.c (vect_is_simple_reduction_1, vect_create_epilog_for_reduction): Likewise. * ipa-split.c (split_function): Likewise. * tree-inline.c (remap_ssa_name, setup_one_parameter, declare_return_variable, tree_function_versioning): Likewise. * tree-cfgcleanup.c (fixup_noreturn_call): Likewise. * cfgexpand.c (update_alias_info_with_stack_vars, expand_used_vars): Likewise. * tree-ssa-phiopt.c (conditional_replacement, abs_replacement, neg_replacement): Likewise. * gimplify-me.c (force_gimple_operand_1, gimple_regimplify_operands): Likewise. * tree-vrp.c (simplify_truth_ops_using_ranges, simplify_float_conversion_using_ranges, simplify_internal_call_using_ranges): Likewise. * tree-switch-conversion.c (emit_case_bit_tests, build_one_array, build_arrays, gen_def_assigns): Likewise. * gimple-fold.c (gimple_fold_builtin_memory_op, gimple_fold_builtin_strcat, gimple_fold_call, gimple_build): Likewise. * tree-vect-generic.c (expand_vector_divmod, opti
patch to fix PR64061
The following patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64061
The patch was tested and bootstrapped on x86-64.
Committed as rev. 218171.
2014-11-28 Vladimir Makarov
PR target/64061
* lra.c (lra_substitute_pseudo): Ignore constant with int mode for
subreg.
2014-11-28 Vladimir Makarov
PR target/64061
* gcc.target/i386/pr64061.c: New.
Index: lra.c
===
--- lra.c (revision 218129)
+++ lra.c (working copy)
@@ -1806,7 +1806,8 @@ lra_substitute_pseudo (rtx *loc, int old
machine_mode mode = GET_MODE (*loc);
machine_mode inner_mode = GET_MODE (new_reg);
- if (mode != inner_mode)
+ if (mode != inner_mode
+ && ! (CONST_INT_P (new_reg) && SCALAR_INT_MODE_P (mode)))
{
if (GET_MODE_SIZE (mode) >= GET_MODE_SIZE (inner_mode)
|| ! SCALAR_INT_MODE_P (inner_mode))
Index: testsuite/gcc.target/i386/pr64061.c
===
--- testsuite/gcc.target/i386/pr64061.c (revision 0)
+++ testsuite/gcc.target/i386/pr64061.c (working copy)
@@ -0,0 +1,21 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -g -fno-dce -fno-tree-dce" } */
+
+extern void *buf;
+
+extern void bar (void);
+
+int
+foo (int i)
+{
+ int j = 0;
+ if (__builtin_setjmp (buf) == 0)
+{
+ while (1)
+ {
+j = 1;
+ bar ();
+ }
+}
+ return j ? i : 0;
+}
Re: [patch testsuite gcc.dg]: Turn of ms-extensions for mingw target
On Fri, 28 Nov 2014, Kai Tietz wrote: > 2014-11-28 19:10 GMT+01:00 Joseph Myers : > > On Fri, 28 Nov 2014, Kai Tietz wrote: > > > >> Some diagnostics are different and some constructs getting allowed > >> with enabled ms-extensions flag. Additionally is the pedantic-flag > >> not automatically set for *-*-mingw* targets. So for enforcing > >> ISO-C++ pedantic checks the *-*-mingw* targets need to have explicit > >> set the -pedantic flag (which is on for some other targets by > >> default). > > > > It seems very odd for the default dg-options to vary depending on target - > > where is that target-dependent default set? > > True, I was curious to see this difference too. Well, clearly you shouldn't be changing the tests without actually understanding where the problem comes from. As far as I can tell, the -ansi -pedantic-errors default (-pedantic-errors looping over C++ standards for C++) is hardcoded in the relevant .exp files, so there certainly shouldn't be any per-target variation. So if the motivation for any testcase patch was supposed variation in the default, you need to go back and work out what the *real* cause of the difference was, and then reassess the correct fix based on that. > > But for my main point: -std=c11 -pedantic-errors must diagnose with an > > error anything where C11 requires a diagnostic. Not "anything where C11 > > requires a diagnostic, except for certain extensions on MinGW targets". > > It must not be necessary to add -fno-ms-extensions for such diagnostics; > > the options for conformance must not depend on the target. So for the > > cases where the test uses -std= > > -pedantic/-pedantic-errors, you need to fix the port: the test failures > > are showing up an actual bug in the port, and the tests are correct as-is. > > The same principle of course applies to C++ tests, though I didn't examine > > your changes to those to see if the same issue applies to any of those > > changes. > > How so? That ms-extensions are enabled by default is all the port > does. The rest is done in FEs, and indeed the diagnostic here about > handling ms-extensions, or on standard-case seems to be buggy. To > depend in testsuite on implicit set flags seems to be a bug too. > So I can't follow you that it is a port issue. The semantics of -std=c11 -pedantic-errors don't depend on the port. It is documented, target-independent, that those options are sufficient to cause diagnosis of anything for which C11 requires a diagnostic. If you find you need -fno-ms-extensions as well, that's not a bug in the documentation or the testcase, it's a bug in GCC, failing to give a diagnostic for certain code for certain targets even though the standard requires it to do so. The testcase has shown up that GCC is behaving incorrectly - it's done what testcases are meant to do. Rather than making the testcase incorrect to match the bug, you should fix the bug. The very simple fix is to remove the -fms-extensions default as ill-conceived. If you don't want to do that, the next simplest fix is to remove that default if flag_iso, so it doesn't interfere with standards conformance. However, since the purpose of flag_iso is not to cause code to be rejected, a preferable fix would be to take the code in c-decl.c:grokfield that computes "ok" and compute it twice: once with the existing logic, once (computing std_ok, say) with flag_ms_extensions changed to (flag_ms_extensions && global_options_set.x.x_flag_ms_extensions). If ok && !std_ok (i.e. something would only be accepted because of a default -fms-extensions), then do a pedwarn (loc, OPT_pedantic, ...) to diagnose the use of an extension not permitted by ISO C. Something similar should be done in any C++ case where the standard requires a diagnostic but GCC for MinGW target is wrongly failing to give such a diagnostic with -pedantic. -- Joseph S. Myers jos...@codesourcery.com
Re: attribute handler oddness in MEP and STORMY16 ports
btw, a bit of followup...
There were a few other ports that had checks similar to that in their
handlers.. ie in rs6000.c:rs6000_handle_longcall_attribute() and
i386:ix86_handle_cconv_attribute()
if (TREE_CODE (*node) != FUNCTION_TYPE
&& TREE_CODE (*node) != FIELD_DECL
&& TREE_CODE (*node) != TYPE_DECL)
{
warning (OPT_Wattributes, "%qE attribute only applies to
functions",
<>
so perhaps it originated here or in one of the other ports that show
this... The difference is that this attribute has the "type-required"
bit set (unlike the mep and stormy16 ports). If you trace through
decl_attributes() one finds that those 2 DECL cases are actually
impossible to ever see. if a decl is processed and the type_required
bit is set, then the handler is actually called with &TREE_TYPE (node),
so if TYPE_DECL or FIELD_DECL were being used, the handler would only
ever see whatever their actual type is...I've removed those checks
on my x86 box and have no failures.
Andrew
On 11/28/2014 10:46 AM, Andrew MacLeod wrote:
While going through the attribute tables to sort out separation or
trees and types, I'm seeing a couple of ports with similar handlers
that look a little odd.
the code sequence in the handler looks like:
if (TREE_CODE (*node) != VAR_DECL
&& TREE_CODE (*node) != POINTER_TYPE
&& TREE_CODE (*node) != TYPE_DECL)
{
warning (OPT_Wattributes,
"%<__BELOW100__%> attribute only applies to variables");
*no_add_attrs = true;
}
My question is
a) what is POINTER_TYPE doing in there.. what has that got to do with
applying to variables, and
b) should TYPE_DECL also be there?
I can almost see the argument for b) MAYBE, but then the message
doesn't really make sense. but POINTER_TYPE seems really odd.
so ports that use that message:
avr, bfin, x86: handlers all make sure its *ONLY* a VAR_DECL handled
mep, stormy16 : uses the suspect sequence. My guess is one copied the
other.
In fact, the mep port does have a couple of other handlers that check
for only VAR_DECL associated with that warning.
mep also has another handler for "variable and functions" that looks
like:
if (TREE_CODE (*node) != VAR_DECL
&& TREE_CODE (*node) != FUNCTION_DECL
&& TREE_CODE (*node) != METHOD_TYPE
&& TREE_CODE (*node) != POINTER_TYPE
&& TREE_CODE (*node) != TYPE_DECL)
{
warning (0, "%qE attribute only applies to variables and
functions",
name);
*no_add = true;
}
Most ports use VAR_DECL and FUNCTION_DECL for this warning. Its odd
that METHOD_TYPE is there, but not FUNCTION_TYPE if types were really
handled...
And finally, also in mep :
if (TREE_CODE (*node) != FUNCTION_DECL
&& TREE_CODE (*node) != METHOD_TYPE)
{
warning (0, "%qE attribute only applies to functions", name);
*no_add = true;
}
It doesn't seem that METHOD_TYPE should be there, unless FUNCTION_TYPE
was also important. It does have other handlers where the check is
only for FUNCTION_DECL *OR* FUNCTION_TYPE, not this odd hybrid.
It's the only port that has this.
If the handlers are ONLY going to deal with decls, the attribute table
ought to have the decl_required flag set as well, which the other
ports do, but these 2 do not.. perhaps because of the existing _TYPE
handling...?
Assuming I understand this right, I've attached a patch which covers
mep and stormy16. It corrects those tables and handlers to work the
way I think they are suppose to. They build, but I cant test them...
can some with that ability run them and see if they are correct?
Assuming no one has a counter argument to what I'm saying... Maybe
there is some need for this that I'm just missing :-)
Andrew
Re: [RFC] Wrong "current" pointers with bitmap_ior and bitmap_ior_and_compl
Mike Stump wrote:
> While I had testing on my target, there were plenty of other regressions
> from trunk intermixed, so I wanted to do a normal bootstrap on Linux which
> I had not done yet. Kaz, you can check your patch, if the same, pretty
> sure it is, it has been approved and you can just check your version in,
> since you have the testing on it. Richard didn't want the extra testing
> my patch.
I've confirmed that the patches only differ by the extra checking
hunk and committed the patch below with your ChangeLog entry.
Regards,
kaz
--
2014-11-28 Mike Stump
* bitmap.c (bitmap_ior): Zap current as it could be deleted.
(bitmap_ior_and_compl): Likewise.
diff --git a/bitmap.c b/bitmap.c
index 8f7f306..ace6aea 100644
--- a/bitmap.c
+++ b/bitmap.c
@@ -1595,6 +1595,8 @@ bitmap_ior (bitmap dst, const_bitmap a, const_bitmap b)
if (dst_elt)
{
changed = true;
+ /* Ensure that dst->current is valid. */
+ dst->current = dst->first;
bitmap_elt_clear_from (dst, dst_elt);
}
gcc_checking_assert (!dst->current == !dst->first);
@@ -1951,6 +1953,8 @@ bitmap_ior_and_compl (bitmap dst, const_bitmap a,
const_bitmap b, const_bitmap k
if (dst_elt)
{
changed = true;
+ /* Ensure that dst->current is valid. */
+ dst->current = dst->first;
bitmap_elt_clear_from (dst, dst_elt);
}
gcc_checking_assert (!dst->current == !dst->first);
Re: [Patch, option handling] optc-gen.awk - support || in EnabledBy()
On Sun, 23 Nov 2014, Tobias Burnus wrote: > Build on x86-64-gnu-linux with checking that the resulting options.c remains > the same. > OK for the trunk? OK. -- Joseph S. Myers jos...@codesourcery.com
[PATCH] Set stores_off_frame_dead_at_return to false if sibling call
The attached simple change fixes a long standing regression since 4.2. When we have stack arguments and a sibling call, the dse pass deletes stores to the parent's stack frame when we have a sibling call because they are are off frame for the current function. As a result, the sibling call arguments are not passed correctly on PA. The attached change disables this behavior. Tested on hppa2.0w-hp-hpux11.11, hppa64-hp-hpux11.11 and hppa-unknown- linux-gnu. Okay for trunk, 4.9 and 4.8? Dave -- John David Anglin dave.ang...@bell.net 2014-11-28 John David Anglin PR target/55023 * dse.c (scan_insn): Set stores_off_frame_dead_at_return to false if we have a sibling call. Index: dse.c === --- dse.c (revision 217974) +++ dse.c (working copy) @@ -2483,6 +2483,9 @@ insn_info->cannot_delete = true; + if (SIBLING_CALL_P (insn)) + stores_off_frame_dead_at_return = false; + /* Const functions cannot do anything bad i.e. read memory, however, they can read their parameters which may have been pushed onto the stack.
Re: Fwd: g++ off-by-one bug in utf16 conversion
Thanks, I've added a testcase and committed this patch. Bootstrapped
with no regressions on x86_64-unknown-linux-gnu.
libcpp:
2014-11-29 John Schmerge
PR preprocessor/41698
* charset.c (one_utf8_to_utf16): Do not produce surrogate pairs
for 0x.
gcc/testsuite:
2014-11-29 Joseph Myers
PR preprocessor/41698
* gcc/testsuite/g++.dg/cpp/utf16-pr41698-1.C: New test.
Index: gcc/testsuite/g++.dg/cpp/utf16-pr41698-1.C
===
--- gcc/testsuite/g++.dg/cpp/utf16-pr41698-1.C (revision 0)
+++ gcc/testsuite/g++.dg/cpp/utf16-pr41698-1.C (working copy)
@@ -0,0 +1,15 @@
+// PR 41698: off-by-one error in UTF-16 encoding.
+
+// { dg-do run { target c++11 } }
+
+extern "C" void abort (void);
+extern "C" void exit (int);
+
+int
+main ()
+{
+ char16_t s[] = u"\u";
+ if (sizeof s != 2 * sizeof (char16_t) || s[0] != 0x || s[1] != 0)
+abort ();
+ exit (0);
+}
Index: libcpp/charset.c
===
--- libcpp/charset.c(revision 218163)
+++ libcpp/charset.c(working copy)
@@ -353,7 +353,7 @@ one_utf8_to_utf16 (iconv_t bigend, const uchar **i
return EILSEQ;
}
- if (s < 0x)
+ if (s <= 0x)
{
if (*outbytesleftp < 2)
{
--
Joseph S. Myers
jos...@codesourcery.com
[PATCH PR59593] [arm] Backport r217772 & r217826 to 4.8 & 4.9
I've backported this fix to 4.8 & 4.9 branch. These patches have been tested for armeb-none-eabi-gcc/g++ with qemu, and both the test results were ok. --- gcc/ChangeLog.ori 2014-11-28 17:30:43.0 +0800 +++ gcc/ChangeLog 2014-11-28 17:30:55.0 +0800 @@ -1,3 +1,15 @@ +2014-11-28 Felix Yang + Shanyao Chen + +Backport from mainline +2014-11-19 Felix Yang +Shanyao Chen + +PR target/59593 +* config/arm/arm.md (define_attr "arch"): Add v6t2. +(define_attr "arch_enabled"): Add test for the above. +(*movhi_insn_arch4): Add new alternative. + 2014-11-19 Uros Bizjak PR target/63947 --- gcc/config/arm/arm.md.ori 2014-11-28 17:33:12.0 +0800 +++ gcc/config/arm/arm.md 2014-11-29 10:34:28.0 +0800 @@ -92,9 +92,11 @@ ; This can be "a" for ARM, "t" for either of the Thumbs, "32" for ; TARGET_32BIT, "t1" or "t2" to specify a specific Thumb mode. "v6" ; for ARM or Thumb-2 with arm_arch6, and nov6 for ARM without -; arm_arch6. This attribute is used to compute attribute "enabled", -; use type "any" to enable an alternative in all cases. -(define_attr "arch" "any,a,t,32,t1,t2,v6,nov6,onlya8,neon_onlya8,nota8,neon_nota8,iwmmxt,iwmmxt2" +; arm_arch6. "v6t2" for Thumb-2 with arm_arch6. This attribute is +; used to compute attribute "enabled", use type "any" to enable an +; alternative in all cases. + +(define_attr "arch" "any,a,t,32,t1,t2,v6,nov6,v6t2,onlya8,neon_onlya8,nota8,neon_nota8,iwmmxt,iwmmxt2" (const_string "any")) (define_attr "arch_enabled" "no,yes" @@ -129,6 +131,10 @@ (match_test "TARGET_32BIT && !arm_arch6")) (const_string "yes") +(and (eq_attr "arch" "v6t2") + (match_test "TARGET_32BIT && arm_arch6 && arm_arch_thumb2")) +(const_string "yes") + (and (eq_attr "arch" "onlya8") (eq_attr "tune" "cortexa8")) (const_string "yes") @@ -6282,8 +6288,8 @@ ;; Pattern to recognize insn generated default case above (define_insn "*movhi_insn_arch4" - [(set (match_operand:HI 0 "nonimmediate_operand" "=r,r,m,r") - (match_operand:HI 1 "general_operand" "rI,K,r,mi"))] + [(set (match_operand:HI 0 "nonimmediate_operand" "=r,r,r,m,r") + (match_operand:HI 1 "general_operand" "rI,K,n,r,mi"))] "TARGET_ARM && arm_arch4 && (register_operand (operands[0], HImode) @@ -6291,17 +6297,20 @@ "@ mov%?\\t%0, %1\\t%@ movhi mvn%?\\t%0, #%B1\\t%@ movhi + movw%?\\t%0, %L1\\t%@ movhi str%(h%)\\t%1, %0\\t%@ movhi ldr%(h%)\\t%0, %1\\t%@ movhi" [(set_attr "predicable" "yes") - (set_attr "insn" "mov,mvn,*,*") - (set_attr "pool_range" "*,*,*,256") - (set_attr "neg_pool_range" "*,*,*,244") + (set_attr "insn" "mov,mvn,mov,*,*") + (set_attr "pool_range" "*,*,*,*,256") + (set_attr "neg_pool_range" "*,*,*,*,244") + (set_attr "arch" "*,*,v6t2,*,*") (set_attr_alternative "type" [(if_then_else (match_operand 1 "const_int_operand" "") (const_string "simple_alu_imm" ) (const_string "*")) (const_string "simple_alu_imm") + (const_string "simple_alu_imm") (const_string "store1") (const_string "load1")])] ) --- gcc/ChangeLog.ori 2014-11-28 17:20:38.0 +0800 +++ gcc/ChangeLog 2014-11-28 17:21:14.0 +0800 @@ -1,3 +1,15 @@ +2014-11-28 Felix Yang + Shanyao Chen + +Backport from mainline +2014-11-19 Felix Yang +Shanyao Chen + +PR target/59593 +* config/arm/arm.md (define_attr "arch"): Add v6t2. +(define_attr "arch_enabled"): Add test for the above. +(*movhi_insn_arch4): Add new alternative. + 2014-11-26 Richard Biener PR middle-end/63738 --- gcc/config/arm/arm.md.ori 2014-11-28 09:34:21.0 +0800 +++ gcc/config/arm/arm.md 2014-11-29 10:28:13.0 +0800 @@ -125,9 +125,10 @@ ; This can be "a" for ARM, "t" for either of the Thumbs, "32" for ; TARGET_32BIT, "t1" or "t2" to specify a specific Thumb mode. "v6" ; for ARM or Thumb-2 with arm_arch6, and nov6 for ARM without -; arm_arch6. This attribute is used to compute attribute "enabled", -; use type "any" to enable an alternative in all cases. -(define_attr "arch" "any,a,t,32,t1,t2,v6,nov6,neon_for_64bits,avoid_neon_for_64bits,iwmmxt,iwmmxt2" +; arm_arch6. "v6t2" for Thumb-2 with arm_arch6. This attribute is +; used to compute attribute "enabled", use type "any" to enable an +; alternative in all cases. +(define_attr "arch" "any,a,t,32,t1,t2,v6,nov6,v6t2,neon_for_64bits,avoid_neon_for_64bits,iwmmxt,iwmmxt2" (const_string "any")) (define_attr "arch_enabled" "no,yes" @@ -162,6 +163,10 @@ (match_test "TARGET_32BIT && !arm_arch6"))
Re: [PATCH PR59593] [arm] Backport r217772 & r217826 to 4.8 & 4.9
> I've backported this fix to 4.8 & 4.9 branch. > These patches have been tested for armeb-none-eabi-gcc/g++ with qemu, and > both the test results were ok. Looks OK with me. Ramana, is this OK for the 4.8 & 4.9 branches? Thanks.
