Bug 72794 - [7 regression] CF on spec2000/176.gcc after r238862.
Summary: [7 regression] CF on spec2000/176.gcc after r238862.
Status: RESOLVED INVALID
Alias: None
Product: gcc
Classification: Unclassified
Component: c (show other bugs)
Version: 7.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-08-03 16:02 UTC by Yuri Rumyantsev
Modified: 2016-08-04 12:38 UTC (History)
0 users

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Yuri Rumyantsev 2016-08-03 16:02:11 UTC
We noticed that after this commit benchmark is failed with message:
/tmp/cchqWD0Q.ltrans0.ltrans.o: In function `yylex':
<artificial>:(.text+0x566e): undefined reference to `is_reserved_word'
/tmp/cchqWD0Q.ltrans8.ltrans.o: In function `compile_file':
<artificial>:(.text+0xb1fe): undefined reference to `is_reserved_word'
<artificial>:(.text+0xb22b): undefined reference to `is_reserved_word'
<artificial>:(.text+0xb248): undefined reference to `is_reserved_word'
<artificial>:(.text+0xb265): undefined reference to `is_reserved_word'

i.e. function is_reserved_word with attribute "inline" was deleted but its calls were not inlined. To reproduce bench spec must be compiled with
-Ofast -funroll-loops -flto -static  -DSPEC_CPU2000_LP64 options.
I did not try to prepare test-case to reproduce since assume that spec2000 suite is available.
Comment 1 Andrew Pinski 2016-08-03 16:08:34 UTC
Can you try with -std=gnu90 and see if that fixes the issue.
Comment 2 Yuri Rumyantsev 2016-08-03 16:32:37 UTC
Yes, this option cures CF. Does it mean that we must compile spec2000
with this flag?

2016-08-03 19:08 GMT+03:00 pinskia at gcc dot gnu.org
<gcc-bugzilla@gcc.gnu.org>:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72794
>
> --- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
> Can you try with -std=gnu90 and see if that fixes the issue.
>
> --
> You are receiving this mail because:
> You reported the bug.
Comment 3 Andrew Pinski 2016-08-03 16:43:33 UTC
(In reply to Yuri Rumyantsev from comment #2)
> Yes, this option cures CF. Does it mean that we must compile spec2000
> with this flag?

Yes and it should be considered a portability flag.

Basically GNU90 and ISO C99 inline behave slightly different which is why you are seeing this.
Comment 4 Yuri Rumyantsev 2016-08-04 09:25:33 UTC
I assume that there is still issue in lto part of compiler - even if
we ignore "inline" attribute we (lto) must not delete such functions
from binaries. So this bug must be forwarded to lto phase.

2016-08-03 19:43 GMT+03:00 pinskia at gcc dot gnu.org
<gcc-bugzilla@gcc.gnu.org>:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72794
>
> Andrew Pinski <pinskia at gcc dot gnu.org> changed:
>
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>              Status|UNCONFIRMED                 |RESOLVED
>          Resolution|---                         |INVALID
>
> --- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
> (In reply to Yuri Rumyantsev from comment #2)
>> Yes, this option cures CF. Does it mean that we must compile spec2000
>> with this flag?
>
> Yes and it should be considered a portability flag.
>
> Basically GNU90 and ISO C99 inline behave slightly different which is why you
> are seeing this.
>
> --
> You are receiving this mail because:
> You reported the bug.
Comment 5 Richard Biener 2016-08-04 11:08:23 UTC
No, it's not a bug in the LTO phase - C99 inline simply does _not_ emit a out-of-line copy.  You have to add a extern declaration to force that.
Comment 6 Yuri Rumyantsev 2016-08-04 12:38:16 UTC
Thanks for clarification.
This bug can be closed as user misunderstanding.

2016-08-04 14:08 GMT+03:00 rguenth at gcc dot gnu.org
<gcc-bugzilla@gcc.gnu.org>:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72794
>
> --- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
> No, it's not a bug in the LTO phase - C99 inline simply does _not_ emit a
> out-of-line copy.  You have to add a extern declaration to force that.
>
> --
> You are receiving this mail because:
> You reported the bug.