[Bug c/65926] New: MinGW-W64, xmmintrin.h, error: can't convert between vector values of different size

[Bug c/65926] New: MinGW-W64, xmmintrin.h, error: can't convert between vector values of different size

[i.nixman at autistici dot org]

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

            Bug ID: 65926
           Summary: MinGW-W64, xmmintrin.h, error: can't convert between
                    vector values of different size
           Product: gcc
           Version: 5.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: i.nixman at autistici dot org
  Target Milestone: ---

I'm trying to build MinGW-⁠W64(i686-⁠sjlj) based on GCC-⁠5.1.0 and faced with
this errors:
http://pastebin.com/U9Lm8saL

but x86_64-⁠sjlj with the same configuration flags is built successfully.

Configure flags:
--host=i686-w64-mingw32
--build=i686-w64-mingw32
--target=i686-w64-mingw32
--prefix=/mingw32
--with-sysroot=/c/mingw510/i686-510-posix-sjlj-rt_v4-rev0/mingw32
--with-gxx-include-dir=/mingw32/i686-w64-mingw32/include/c++
--enable-shared
--enable-static
--enable-targets=all
--enable-multilib
--enable-languages=ada,c,c++,fortran,objc,obj-c++,lto
--enable-libstdcxx-time=yes
--enable-threads=posix
--enable-libgomp
--enable-libatomic
--enable-lto
--enable-graphite
--enable-checking=release
--enable-fully-dynamic-string
--enable-version-specific-runtime-libs
--enable-sjlj-exceptions
--disable-isl-version-check
--disable-cloog-version-check
--disable-libstdcxx-pch
--disable-libstdcxx-debug
--enable-bootstrap
--disable-rpath
--disable-win32-registry
--disable-nls
--disable-werror
--disable-symvers
--with-gnu-as
--with-gnu-ld
--with-arch-32=i686
--with-arch-64=nocona
--with-tune-32=generic
--with-tune-64=core2
--with-libiconv
--with-system-zlib
--with-gmp=/c/mingw510/prerequisites/i686-w64-mingw32-static
--with-mpfr=/c/mingw510/prerequisites/i686-w64-mingw32-static
--with-mpc=/c/mingw510/prerequisites/i686-w64-mingw32-static
--with-isl=/c/mingw510/prerequisites/i686-w64-mingw32-static
--with-cloog=/c/mingw510/prerequisites/i686-w64-mingw32-static
--enable-cloog-backend=isl

Ideas?
>From gcc-bugs-return-484935-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Apr 29 07:57:33 2015
Return-Path: <gcc-bugs-return-484935-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 54808 invoked by alias); 29 Apr 2015 07:57:33 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 54709 invoked by uid 48); 29 Apr 2015 07:57:28 -0000
From: "ramana at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/65837] [arm-linux-gnueabihf] lto1 target specific builtin not available
Date: Wed, 29 Apr 2015 07:57:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 6.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: ramana at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: prathamesh3492 at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-65837-4-tq592d13cb@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-65837-4@http.gcc.gnu.org/bugzilla/>
References: <bug-65837-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-04/txt/msg02487.txt.bz2
Content-length: 2578

https://gcc.gnu.org/bugzilla/show_bug.cgi?ide837

--- Comment #22 from Ramana Radhakrishnan <ramana at gcc dot gnu.org> ---
(In reply to prathamesh3492 from comment #18)
> Created attachment 35420 [details]
> patch to override default options by options in object file
>
> Hi,
>
> The following untested patch gives preference to option value in object file.
> In run_gcc(),
> options from COLLECT_GCC_OPTIONS which are taken from command line are
> stored in decoded_options.
> options from object file are stored in fdecoded_options.
> so override the option in decoded_options if it is present in
> fdecoded_options.
>
> With the patch this works:
> arm-linux-gnueabihf-gcc test.c -mfpu=neon -flto -c
> arm-linux-gnueabihf-gcc test.o -flto
> only passes -mfpu=neon to lto1
>
> However the patch doesn't work when same option is passed different values
> at compile and link-time:
> arm-linux-gnuebihf-gcc test.c -mfpu=neon -flto -c
> arm-linux-gnueabihf-gcc test.o -mfpu=vfpv3-d16 -flto
>
> In this case, -mfpu=neon is still passed to lto1, since the patch prefers
> option value from object file.
> Without the patch, the option from the command line was given preference.
>
> for both the following cases:
> arm-linux-gnueabihf-gcc test.o -flto
> arm-linux-gnueabihf-gcc test.o -flto -mfpu=vfpv3-d16
>
> COLLECT_GCC_OPTIONS contains "-mfpu=vfpv3-d16", however in the first case it
> isn't explictly passed by user, so passing -mfpu=neon
> would be correct. In the second case, since -mfpu=vfpv3-d16 is passed
> intentionally by user, should it be considered
> as an error - "conflicting options" ?

No, otherwise users will have to rebuild their compilers for different
defaults, thus defeating the whole purpose of having command line options !

>
> Unfortunately, it looks like there is no way to distinguish between options
> defined by default and explicitly passed options from COLLECT_GCC_OPTIONS
> and that's the only way command line options are passed to lto-wrapper from
> the driver. One way would be to modify COLLECT_GCC_OPTIONS in the driver to
> indicate which options were explicitly passed from command line.
> For instance, additionally COLLECT_GCC_OPTIONS would contain
> "-mfpu=vfpv3-d16-explicit" to indiciate that -mfpu=vfpv3-d16 was
> passed from command line and not set by default. In lto-wrapper the options
> could be parsed to check if they have "explicit" suffix and thus distinguish
> between explicit and defualt defined options.
> Does that sound reasonable ? I would be grateful for suggestions.
>
> Thank you,
> Prathamesh