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 lto/81686] New: LTO hardcodes identity host to target charset mapping


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

            Bug ID: 81686
           Summary: LTO hardcodes identity host to target charset mapping
           Product: gcc
           Version: 8.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: lto
          Assignee: unassigned at gcc dot gnu.org
          Reporter: jakub at gcc dot gnu.org
                CC: marxin at gcc dot gnu.org
  Target Milestone: ---

As mentioned in http://gcc.gnu.org/ml/gcc-patches/2017-08/msg00260.html
jakub> how does lang_hooks.to_target_charset work for LTO?
jakub> does it mean LTO can be used only if the host and target charset are the
same?
richi> no idea, does it?
richi> shouldn't all translation be done early?
jakub> gimple-fold.c, gimple-ssa-sprintf.c and various other passes use it all
the time
jakub> say to find out what the target '%' character is etc.
richi> so why's that a langhook?
richi> isn't that part of the C "ABI"?
jakub> because we use libcpp for it right now
richi> and...?
jakub> I think libcpp isn't linked in for non-C/Fortran
richi> well, then that has to be fixed (or the code moved into a more common
place)
jakub> anyway, no plans to do anything here, just a reaction to Prathamesh's
patch
richi> can you file a tracking PR?  Just paste above discussion
richi> I suppose LTO doesn't have this langhook so it "works" (conservatively
not doing the transform)
jakub> I suppose if we add a langhook that would give iconv conversion pair or
something, then we could remember that pair somewhere in the LTO bytestream,
and use iconv directly in the middle-end
richi> there's no reason LTO can do that iconv conversion itself
richi> OTOH what about different TUs with different exec charset?
jakub> just error or sorry?
richi> I guess so
jakub> or, avoid all optimizations where we need that
jakub> perhaps short term we could do the same - document a magic return from
the to_charset language hook and let LTO return it for all chars
jakub> then just avoid the optimizations
jakub> or, just record in LTO if the target charset is ASCII compatible (and
host too)
jakub> and if both are ASCII compatible, optimize, otherwise punt

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