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 ipa/82278] [8 regression] gcc.dg/lto/chkp-ctor-merge fail


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

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hubicka at ucw dot cz,
                   |                            |rguenth at gcc dot gnu.org

--- Comment #3 from Martin Liška <marxin at gcc dot gnu.org> ---
So it's caused by r251333, where we try to redirect following callee:

Z5ctor2v.chkp/14 (ctor2.chkp) @0x155553f4e170
  Type: function definition analyzed
  Visibility: artificial
  References: glob/0 (read)glob/0 (write)
  Referring: 
  Read from file: /tmp/ccsHDute.ltrans0.o
  Function ctor2.chkp/14 is inline copy in
_GLOBAL__I_65535_0_chkp_ctor_merge_0.o/13
  Availability: local
  First run: 0
  Function flags: local only_called_at_startup nonfreeing_fn executed_once
only_called_at_startup
  Called by: _GLOBAL__I_65535_0_chkp_ctor_merge_0.o/13 (inlined) (1.00 per
call) 
  Calls: 

Before the patch it was:

_Z5ctor2v.chkp/5 (ctor2.chkp) @0x155553f4e450
  Type: function definition analyzed
  Visibility: prevailing_def_ironly asm_written artificial
  References: 
  Referring: _Z5ctor2v/2 (chkp)
  Availability: available
  First run: 0
  Function flags: only_called_at_startup nonfreeing_fn executed_once
only_called_at_startup
  Called by: ctor2/2 (1.00 per call) _GLOBAL__I_65535_0_chkp_ctor_merge_0.o/13
(1.00 per call) 
  Calls: 
  Is instrumented version.

Anyway, it's probably for someone how is skilled in MPX. But as I'm reading the
change in r251333, it's very similar
to what I tried here:
https://gcc.gnu.org/ml/gcc-patches/2017-08/msg00926.html

and Honza had problem to select target_option_default_node as it's problematic
for LTO.
Anyway the test-case for PR71991 is currently rejected both w/ and w/o LTO:

$ cat /tmp/inline.c
static inline int __attribute__ ((__always_inline__)) fn1 () { return 0; }
static inline int __attribute__ ((target("inline-all-stringops"))) fn2 () {
return fn1 (); }

int main()
{
  return fn2();
}

$ ./xgcc -B. /tmp/inline.c -O2 -flto
/tmp/inline.c: In function ‘fn2’:
/tmp/inline.c:1:55: error: inlining failed in call to always_inline ‘fn1’:
target specific option mismatch
 static inline int __attribute__ ((__always_inline__)) fn1 () { return 0; }
                                                       ^~~
/tmp/inline.c:2:84: note: called from here
 static inline int __attribute__ ((target("inline-all-stringops"))) fn2 () {
return fn1 (); }
                                                                               
    ^~~~~~
$ ./xgcc -B. /tmp/inline.c -O2
/tmp/inline.c: In function ‘fn2’:
/tmp/inline.c:1:55: error: inlining failed in call to always_inline ‘fn1’:
target specific option mismatch
 static inline int __attribute__ ((__always_inline__)) fn1 () { return 0; }
                                                       ^~~
/tmp/inline.c:2:84: note: called from here
 static inline int __attribute__ ((target("inline-all-stringops"))) fn2 () {
return fn1 (); }

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