[Bug tree-optimization/83195] [8 regression] pr82929.c scan for "Merging successful" fail

jakub at gcc dot gnu.org gcc-bugzilla@gcc.gnu.org
Tue Nov 28 15:33:00 GMT 2017


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83195

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
That is because arm is cheating:
proc check_effective_target_non_strict_align {} {

    # On ARM, the default is to use STRICT_ALIGNMENT, but there
    # are interfaces defined for misaligned access and thus
    # depending on the architecture levels unaligned access is
    # available.
    if [istarget "arm*-*-*"] {
        return [check_effective_target_arm_unaligned]
    }

    return [check_no_compiler_messages non_strict_align assembly {
        char *y;
        typedef char __attribute__ ((__aligned__(__BIGGEST_ALIGNMENT__))) c;
        c *z;
        void foo(void) { z = (c *) y; }
    } "-Wcast-align"]
}

proc check_effective_target_store_merge { } {
    if { [is-effective-target non_strict_align ] && [is-effective-target
int32plus] } {
        return 1
    }

    return 0
}

The testcase really cares about:
  bool allow_unaligned_store
    = !STRICT_ALIGNMENT && PARAM_VALUE (PARAM_STORE_MERGING_ALLOW_UNALIGNED);
  bool allow_unaligned_load = allow_unaligned_store;
If that is not true, then in this case the optimization is not beneficial.

Is this the only store merging testcase that fails on arm?
I'd prefer not to add __builtin_assume_aligned and similar to the testcase so
that it tests the !STRICT_ALIGNMENT behavior (perhaps we can have another one
with that builtin), so do I need to uglify by using { target { store_merge && {
! arm*-*-* } } } ?


More information about the Gcc-bugs mailing list