This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug target/60607] -march=native command line option handling breaks LTO option machinery


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60607

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|                            |x86_64-*-*, i?86-*-*
             Status|UNCONFIRMED                 |NEW
           Keywords|                            |lto
   Last reconfirmed|                            |2014-03-21
          Component|lto                         |target
     Ever confirmed|0                           |1
            Summary|Missing lto command line    |-march=native command line
                   |option handling causes      |option handling breaks LTO
                   |build failures              |option machinery
           Severity|enhancement                 |normal

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
The issue is that -march=native "explodes" to explicit set options, including
negative ones such as -mno-sse4.1.  That's bad, as we now have conflicting
options for bar.o and foo.o which we merge like

          /* Do what the old LTO code did - collect exactly one option
             setting per OPT code, we pick the first we encounter.
             ???  This doesn't make too much sense, but when it doesn't
             then we should complain.  */

I think this option exploding done by -march=native is simply broken.

At least exploding to full positive _and_ negative lists is.  Either we
have a separate option for each target feature - then we don't need the
-mno-xxx stuff, or we don't - then we need to fix that.

Note that the plan for the future is to no longer "merge" any target options
for link-time but use target attributes more aggressively.  The current code
merely tries to make the link-step succeed somehow, not follow what the
user intended with setting specific target options on specific TUs.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]