Bug 61159 - __builtin_constant_p gives incorrect results with aliases
Summary: __builtin_constant_p gives incorrect results with aliases
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: ipa (show other bugs)
Version: unknown
: P3 normal
Target Milestone: 14.0
Assignee: Rainer Orth
URL: https://gcc.gnu.org/pipermail/gcc-pat...
Keywords: wrong-code
Depends on:
Blocks:
 
Reported: 2014-05-12 18:07 UTC by Rich Felker
Modified: 2024-02-26 09:45 UTC (History)
3 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2016-09-11 00:00:00


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Rich Felker 2014-05-12 18:07:37 UTC
This issue is closely related to #61144, but seems to have appeared earlier. Consider the following test case:

static int dummy = 0;
extern int foo __attribute__((__weak__, __alias__("dummy")));
typedef char check[2*!__builtin_constant_p(dummy)-1];
typedef char check[2*!__builtin_constant_p(foo)-1];

While the static dummy could be considered constant if its address did not leak outside the translation unit, its address DOES leak via the weak alias foo. As long as there is no strong definition for foo in another translation unit, dummy may be externally modified via the alias foo. As for foo, it is external and thus may never be considered constant. Thus, __builtin_constant_p(dummy) and __builtin_constant_p(foo) should both yield zero and the above translation unit should compile successfully.

The results observed vary highly with gcc version. A number of versions were observed giving __builtin_constant_p(dummy)==1, including 4.8.1, but __builtin_constant_p(foo) was more rare, showing up only in 4.9.0 and some really old versions like 4.4.7 (tested via gcc.godbolt.org since I don't have that many gcc versions lying around to test locally).
Comment 1 Rich Felker 2014-05-12 19:40:20 UTC
I should amend this report with further info: __builtin_constant_p is giving different results for dummy and foo depending on whether it's used at file scope or in a function. I've also observed some other really weird behavior from it that I need to summarize and report.
Comment 2 Jan Hubicka 2016-09-11 10:01:56 UTC
I think this has been fixed with last alias reorg, but double-checking and having a testcase would be nice.
Comment 3 Jan Hubicka 2016-09-11 12:15:15 UTC
Fixed.
Comment 4 Jan Hubicka 2016-09-11 12:15:34 UTC
Author: hubicka
Date: Sun Sep 11 12:15:02 2016
New Revision: 240082

URL: https://gcc.gnu.org/viewcvs?rev=240082&root=gcc&view=rev
Log:
	PR ipa/61159
	* compile/pr61159.c: New testcase

Added:
    trunk/gcc/testsuite/gcc.c-torture/compile/pr61159.c
Modified:
    trunk/gcc/testsuite/ChangeLog
Comment 5 Rainer Orth 2016-09-12 12:43:16 UTC
The new testcase FAILs on Solaris/x86 with /bin/as:

FAIL: gcc.c-torture/compile/pr61159.c   -O0  (test for excess errors)

Excess errors:
Assembler: pr61159.c
        "/var/tmp//ccRtFPva.s", line 5 : Cannot set a weak symbol to a common symbol

Input is

        .file   "pr61159.c"
        .local  dummy
        .comm   dummy,4,4
        .weak   foo
        .set    foo,dummy

  Rainer
Comment 6 Martin Liška 2018-11-19 13:06:35 UTC
Can the bug be marked as resolved?
Comment 7 ro@CeBiTec.Uni-Bielefeld.DE 2018-12-07 13:51:15 UTC
> --- Comment #6 from Martin Liška <marxin at gcc dot gnu.org> ---
> Can the bug be marked as resolved?

No, the Solaris/x86 problem persists.
Comment 8 GCC Commits 2024-02-26 09:42:53 UTC
The master branch has been updated by Rainer Orth <ro@gcc.gnu.org>:

https://gcc.gnu.org/g:a25d7d1385087e0f43574064db45f1bc7d52f400

commit r14-9176-ga25d7d1385087e0f43574064db45f1bc7d52f400
Author: Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>
Date:   Mon Feb 26 10:42:04 2024 +0100

    testsuite: xfail gcc.c-torture/compile/pr61159.c on Solaris/x86 with as [PR61159]
    
    gcc.c-torture/compile/pr61159.c currently FAILs on 32 and 64-bit
    Solaris/x86 with the native assembler:
    
    FAIL: gcc.c-torture/compile/pr61159.c   -O0  (test for excess errors)
    FAIL: gcc.c-torture/compile/pr61159.c   -O1  (test for excess errors)
    FAIL: gcc.c-torture/compile/pr61159.c   -O2  (test for excess errors)
    FAIL: gcc.c-torture/compile/pr61159.c   -O2 -flto  (test for excess errors)
    FAIL: gcc.c-torture/compile/pr61159.c   -O2 -flto -flto-partition=none  (test for excess errors)
    FAIL: gcc.c-torture/compile/pr61159.c   -O3 -g  (test for excess errors)
    FAIL: gcc.c-torture/compile/pr61159.c   -Os  (test for excess errors)
    
    Excess errors:
    Assembler: pr61159.c
            "/var/tmp//ccRtFPva.s", line 5 : Cannot set a weak symbol to a common symbol
    
    This is a bug/limitation in the native assembler.  Given that this
    hasn't seen fixes for a long time, this patch xfails the test.
    
    Tested on i386-pc-solaris2.11 (as and gas) and x86_64-pc-linux-gnu.
    
    2024-02-24  Rainer Orth  <ro@CeBiTec.Uni-Bielefeld.DE>
    
            gcc/testsuite:
            PR ipa/61159
            * gcc.c-torture/compile/pr61159.c: xfail on Solaris/x86 with as.
Comment 9 Rainer Orth 2024-02-26 09:45:37 UTC
Test xfail'ed on Solaris/x86 with as for GCC 14.0.1.