Bug 20297 - #pragma GCC visibility isn't properly handled for builtin functions
Summary: #pragma GCC visibility isn't properly handled for builtin functions
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: middle-end (show other bugs)
Version: 4.0.0
: P2 normal
Target Milestone: ---
Assignee: Jason Merrill
URL:
Keywords: visibility
Depends on:
Blocks: 32434
  Show dependency treegraph
 
Reported: 2005-03-03 00:02 UTC by H.J. Lu
Modified: 2007-06-20 20:53 UTC (History)
11 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2006-03-22 03:33:13


Attachments
A testcase (576 bytes, application/octet-stream)
2005-03-03 00:05 UTC, H.J. Lu
Details
New patch (628 bytes, patch)
2005-06-06 07:48 UTC, Michael Matz
Details | Diff
Failure even with the latest patch (37.76 KB, text/plain)
2005-09-13 16:34 UTC, Benjamin Smedberg
Details

Note You need to log in before you can comment on or make changes to this bug.
Description H.J. Lu 2005-03-03 00:02:15 UTC
When "#pragma GCC visibility push" is used on builtin functions, it may
not be properly handled if "#pragma GCC visibility pop" is missing.
Comment 1 H.J. Lu 2005-03-03 00:05:32 UTC
Created attachment 8315 [details]
A testcase

/export/build/gnu/gcc-4.0/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc-4.0/build-x86_64-linux/gcc/ -O2 -fPIC	-c -o foo.o
foo.c
/export/build/gnu/gcc-4.0/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc-4.0/build-x86_64-linux/gcc/ -o libfoo.so -shared foo.o
foo.o: In function `foo':
foo.c:(.text+0x5): undefined reference to `memcpy'
/usr/local/bin/ld: foo.o: relocation R_X86_64_PC32 against `memcpy' can not be
used when making a shared object; recompile with -fPIC
/usr/local/bin/ld: final link failed: Bad value
collect2: ld returned 1 exit status
make: *** [libfoo.so] Error 1

The problem is gcc mishandles

#pragma GCC visibility push(hidden)
#pragma GCC visibility push(default)
typedef long unsigned int size_t;
extern void *memcpy (void *, const void *, size_t);
#pragma GCC visibility pop

and thinks memcpy is hidden. It only happens to builtin functions. When
memcpy is renamed to bar, gcc is OK.
Comment 2 Matthew Daniel 2005-03-03 19:03:30 UTC
In case anyone is curious, this causes the Mozilla HEAD build to fail [at least
with gcc 3.4.3 20050124 and GNU ld 2.15.95 20050302 on x86_64] during link on
two separate occasions, once with nsprpub and once with libmozjs.so. Removing
the use of "#pragma GCC visibility" statements causes the source to build and
link as expected.
Comment 3 Andrew Pinski 2005-03-03 19:06:10 UTC
(In reply to comment #2)
> In case anyone is curious, this causes the Mozilla HEAD build to fail [at least
> with gcc 3.4.3 20050124 and GNU ld 2.15.95 20050302 on x86_64] during link on
> two separate occasions, once with nsprpub and once with libmozjs.so. Removing
> the use of "#pragma GCC visibility" statements causes the source to build and
> link as expected.
It cannot be causing a non modified gcc 3.4.3 to fail as 3.4.3 does not include this pragma at all, it is 
only included with 4.0.0 and above.
Comment 4 H.J. Lu 2005-03-03 19:11:46 UTC
A patch is posted at

http://gcc.gnu.org/ml/gcc-patches/2005-03/msg00248.html

FYI, gcc 3.4 from RH does include this pragma.
Comment 5 Matthew Daniel 2005-03-03 19:19:12 UTC
$ gcc --version
gcc (GCC) 3.4.3 20050124 (Red Hat 3.4.3-17)

I stand corrected, Fedora Core 3 must be back-porting some of that
functionality. Should I open a bug with them pointing to this, or is it just
water under the bridge now?
Comment 6 H.J. Lu 2005-03-03 19:25:23 UTC
RH bug is at

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=150157
Comment 7 Pawel Sikora 2005-05-26 14:40:29 UTC
(In reply to comment #4) 
> A patch is posted at 
>  
> http://gcc.gnu.org/ml/gcc-patches/2005-03/msg00248.html 
>  
> FYI, gcc 3.4 from RH does include this pragma. 
 
this patch ices gcc-4.1-20050522 bootstrap. 
 
../../gcc/libgcc2.c: In function '__absvsi2':  
../../gcc/libgcc2.c:215: internal compiler error: tree check: expected class 
'declaration', have 'expression' (call_expr) in expand_builtin, at  
builtins.c:6260  
 
Comment 8 Michael Matz 2005-06-06 07:48:38 UTC
Created attachment 9035 [details]
New patch

This fixes a problem in HJs patch (which doesn't look at the fndecl
of the builtin, but at the call_expr).
Comment 9 Benjamin Smedberg 2005-09-09 20:51:00 UTC
I can confirm that attachment 9035 [details] fixes the mozilla compile issues with GCC
4.0/4.0.1/trunk.
Comment 10 Benjamin Smedberg 2005-09-13 16:34:14 UTC
Created attachment 9720 [details]
Failure even with the latest patch

I'm wrong. attachment 9035 [details] fixes the compile errors in the main mozilla tree,
but does not fix the errors in NSPR. Attached is the preprocessed source that's
failing. This was compiled with

 -pipe -ansi -Wall -pthread -g -fno-inline -fPIC
Comment 11 Simon Strandman 2005-10-18 12:21:10 UTC
I'm using gcc 4.0.2 with patches for gcc pr19664, pr20297 and pr19520. The testcase from this bug passes without problems. Still firefox beta2 and current CVS fails to build. I talked to the mozilla guys and they asked me to report it here. Any ideas what might be wrong?

x86_64-pc-linux-gnu-gcc -DGENTOO_NSPLUGINS_DIR=\"/usr/lib64/nsplugins\"
-DGENTOO_NSBROWSER_PLUGINS_DIR=\"/usr/lib64/nsbrowser/plugins\"   -W -Wno-unused
-Wpointer-arith -Wcast-align -Wno-long-long -march=athlon64 -pipe -fPIC
-Wno-return-type -w -pthread -pipe  -DNDEBUG -DTRIMMED -ffunction-sections -Os
-fPIC -shared -Wl,-h -Wl,libmozjs.so -Wl,-R/usr/lib64/mozilla-firefox -o
libmozjs.so  jsapi.o jsarena.o jsarray.o jsatom.o jsbool.o jscntxt.o jsdate.o
jsdbgapi.o jsdhash.o jsdtoa.o jsemit.o jsexn.o jsfun.o jsgc.o jshash.o
jsinterp.o jslock.o jslog2.o jslong.o jsmath.o jsnum.o jsobj.o jsopcode.o
jsparse.o jsprf.o jsregexp.o jsscan.o jsscope.o jsscript.o jsstr.o jsutil.o
jsxdrapi.o jsxml.o prmjtime.o    -Wl,-O1  -Wl,-R/usr/lib64/mozilla-firefox   -lm
-ldl -L../../dist/lib -lplds4 -lplc4 -lnspr4 -lpthread -ldl -ldl -lm
/usr/lib/gcc/x86_64-pc-linux-gnu/4.0.2/../../../../x86_64-pc-linux-gnu/bin/ld:
warning: creating a DT_TEXTREL in object.
/usr/lib/gcc/x86_64-pc-linux-gnu/4.0.2/../../../../x86_64-pc-linux-gnu/bin/ld:
jsapi.o: relocation R_X86_64_PC32 against `memcpy@@GLIBC_2.2.5' can not be used
when making a shared object; recompile with -fPIC
/usr/lib/gcc/x86_64-pc-linux-gnu/4.0.2/../../../../x86_64-pc-linux-gnu/bin/ld:
final link failed: Bad value
collect2: ld returned 1 exit status
gmake[3]: *** [libmozjs.so] Error 1
gmake[3]: Leaving directory
`/var/tmp/portage/mozilla-firefox-9999/work/mozilla/js/src'
gmake[2]: *** [libs] Error 2
gmake[2]: Leaving directory `/var/tmp/portage/mozilla-firefox-9999/work/mozilla/js'
gmake[1]: *** [tier_2] Error 2
gmake[1]: Leaving directory `/var/tmp/portage/mozilla-firefox-9999/work/mozilla'
make: *** [default] Error 2

The 9999 version means that it's a CVS build in gentoo.

Binutils is version 2.16.1 and glibc is 2.3.5.
Comment 12 Zac Bowling 2005-12-05 05:38:03 UTC
I'm not sure, but I'm getting this bug as well, but it maybe out of date. 

On the last part about the mozilla bail out, if you add this to your mozconfig it might get it to build correctly.

ac_cv_visibility_pragma=no
Comment 13 bero 2006-01-27 12:24:09 UTC
Still seeing this problem w/ current 4.1 branch
Comment 14 Jason Merrill 2006-03-22 04:20:56 UTC
Subject: Bug 20297

Author: jason
Date: Wed Mar 22 04:20:52 2006
New Revision: 112270

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112270
Log:
        PR middle-end/20297
        * expr.c (init_block_move_fn): Force default visibility.
        (init_block_clear_fn): Likewise.
        * builtins.c (expand_builtin_fork_or_exec): Likewise.
        * targhooks.c (default_external_stack_protect_fail): Likewise.

Added:
    trunk/gcc/testsuite/gcc.dg/visibility-11.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/builtins.c
    trunk/gcc/expr.c
    trunk/gcc/targhooks.c

Comment 15 Jason Merrill 2006-03-22 04:22:44 UTC
Subject: Bug 20297

Author: jason
Date: Wed Mar 22 04:22:40 2006
New Revision: 112271

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112271
Log:
        PR middle-end/20297
        * expr.c (init_block_move_fn): Force default visibility.
        (init_block_clear_fn): Likewise.
        * builtins.c (expand_builtin_fork_or_exec): Likewise.
        * targhooks.c (default_external_stack_protect_fail): Likewise.

Modified:
    branches/gcc-4_1-branch/gcc/ChangeLog
    branches/gcc-4_1-branch/gcc/builtins.c
    branches/gcc-4_1-branch/gcc/expr.c
    branches/gcc-4_1-branch/gcc/targhooks.c

Comment 16 Jason Merrill 2006-03-22 04:23:13 UTC
Subject: Bug 20297

Author: jason
Date: Wed Mar 22 04:23:10 2006
New Revision: 112272

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112272
Log:
        PR middle-end/20297
        * expr.c (init_block_move_fn): Force default visibility.
        (init_block_clear_fn): Likewise.
        * builtins.c (expand_builtin_fork_or_exec): Likewise.
        * targhooks.c (default_external_stack_protect_fail): Likewise.

Added:
    branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/visibility-11.c

Comment 17 Jason Merrill 2006-03-22 04:50:36 UTC
Subject: Bug 20297

Author: jason
Date: Wed Mar 22 04:50:31 2006
New Revision: 112273

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112273
Log:
        PR middle-end/20297
        * expr.c (init_block_move_fn): Force default visibility.
        (init_block_clear_fn): Likewise.
        * builtins.c (expand_builtin_fork_or_exec): Likewise.

Modified:
    branches/gcc-4_0-branch/gcc/ChangeLog
    branches/gcc-4_0-branch/gcc/builtins.c
    branches/gcc-4_0-branch/gcc/expr.c

Comment 18 Jason Merrill 2006-03-22 04:55:21 UTC
Subject: Bug 20297

Author: jason
Date: Wed Mar 22 04:55:18 2006
New Revision: 112274

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112274
Log:
        PR middle-end/20297
        * expr.c (init_block_move_fn): Force default visibility.
        (init_block_clear_fn): Likewise.

Modified:
    branches/redhat/gcc-3_4-branch/gcc/ChangeLog
    branches/redhat/gcc-3_4-branch/gcc/expr.c

Comment 19 Jason Merrill 2006-06-23 01:05:39 UTC
fixed a while back