On Fri, Apr 17, 2015 at 5:36 AM, H.J. Lu wrote:
> On Fri, Apr 17, 2015 at 4:59 AM, Jakub Jelinek wrote:
>> On Fri, Apr 17, 2015 at 04:48:48AM -0700, H.J. Lu wrote:
>>> > I don't like it. Nonshared libgcc is libgcc.a, period. No sense in
>>> > creating yet another library for that.
>>> > So, IMH
On 11/05/15 14:05, Jakub Jelinek wrote:
> On Mon, May 11, 2015 at 01:39:17PM +0100, Szabolcs Nagy wrote:
>> fyi, musl loader loads libstdc++ just fine because it has no
>
> But will it load any shared library that uses any of the 26 (if I count well
> on x86_64) @ symbols from libstdc++.so.6?
i
On Mon, May 11, 2015 at 12:31:51PM +0200, Jakub Jelinek wrote:
> On Mon, May 11, 2015 at 11:20:15AM +0100, Szabolcs Nagy wrote:
> >
> >
> > On 09/05/15 19:57, Szabolcs Nagy wrote:
> > > * H.J. Lu [2015-05-09 10:41:41 -0700]:
> > >> There are
> > >>
> > >> 4: 2b70 806 FUNCG
On Mon, May 11, 2015 at 01:39:17PM +0100, Szabolcs Nagy wrote:
> fyi, musl loader loads libstdc++ just fine because it has no
But will it load any shared library that uses any of the 26 (if I count well
on x86_64) @ symbols from libstdc++.so.6?
readelf -Ws /lib64/libstdc++.so.6 | grep '@' | grep -
On 11/05/15 11:31, Jakub Jelinek wrote:
> On Mon, May 11, 2015 at 11:20:15AM +0100, Szabolcs Nagy wrote:
>>> i think it might be enough to add __cpu_indicator_init_local
>>> as an alias to __cpu_indicator_init in libgcc.a and then use
>>> the *_local symbol from the ifunc resolver, that way no new
On Mon, May 11, 2015 at 11:20:15AM +0100, Szabolcs Nagy wrote:
>
>
> On 09/05/15 19:57, Szabolcs Nagy wrote:
> > * H.J. Lu [2015-05-09 10:41:41 -0700]:
> >> There are
> >>
> >> 4: 2b70 806 FUNCGLOBAL DEFAULT 12
> >> __cpu_indicator_init@GCC_4.8.0
> >> 38: 002
On 09/05/15 19:57, Szabolcs Nagy wrote:
> * H.J. Lu [2015-05-09 10:41:41 -0700]:
>> There are
>>
>> 4: 2b70 806 FUNCGLOBAL DEFAULT 12
>> __cpu_indicator_init@GCC_4.8.0
>> 38: 002153d016 OBJECT GLOBAL DEFAULT 25
>> __cpu_model@GCC_4.8.0
>>
>> and
>>
>>
On Sat, May 09, 2015 at 03:36:01PM -0400, Rich Felker wrote:
> Could you clarify the reasoning for why libgcc is using this hack with
> a reference to an 'obsolete' symbol version rather than just
> visibility?
Obviously for ABI compatibility reasons. Older programs could be relying on
the symbol
On Sat, May 09, 2015 at 10:41:41AM -0700, H.J. Lu wrote:
> On Sat, May 9, 2015 at 7:31 AM, Szabolcs Nagy wrote:
> > * H.J. Lu [2015-04-17 05:36:30 -0700]:
> >> On Fri, Apr 17, 2015 at 4:59 AM, Jakub Jelinek wrote:
> >> > On Fri, Apr 17, 2015 at 04:48:48AM -0700, H.J. Lu wrote:
> >> >> > I don't
* H.J. Lu [2015-05-09 10:41:41 -0700]:
> On Sat, May 9, 2015 at 7:31 AM, Szabolcs Nagy wrote:
> >
> > The symbol versioning hack for __cpu_model and __cpu_indicator_init
> > makes them invisible to the musl dynamic linker so their relocation
> > fails with 'symbol not found' error.
> > (affects a
On Sat, May 9, 2015 at 7:31 AM, Szabolcs Nagy wrote:
> * H.J. Lu [2015-04-17 05:36:30 -0700]:
>> On Fri, Apr 17, 2015 at 4:59 AM, Jakub Jelinek wrote:
>> > On Fri, Apr 17, 2015 at 04:48:48AM -0700, H.J. Lu wrote:
>> >> > I don't like it. Nonshared libgcc is libgcc.a, period. No sense in
>> >>
* H.J. Lu [2015-04-17 05:36:30 -0700]:
> On Fri, Apr 17, 2015 at 4:59 AM, Jakub Jelinek wrote:
> > On Fri, Apr 17, 2015 at 04:48:48AM -0700, H.J. Lu wrote:
> >> > I don't like it. Nonshared libgcc is libgcc.a, period. No sense in
> >> > creating yet another library for that.
> >> > So, IMHO bey
On Fri, May 8, 2015 at 4:00 PM, Rich Felker wrote:
> On Fri, Apr 17, 2015 at 05:36:30AM -0700, H.J. Lu wrote:
>> On Fri, Apr 17, 2015@4:59 AM, Jakub Jelinek wrote:
>> > On Fri, Apr 17, 2015 at 04:48:48AM -0700, H.J. Lu wrote:
>> >> > I don't like it. Nonshared libgcc is libgcc.a, period. No sen
On Fri, Apr 17, 2015 at 05:36:30AM -0700, H.J. Lu wrote:
> On Fri, Apr 17, 2015@4:59 AM, Jakub Jelinek wrote:
> > On Fri, Apr 17, 2015 at 04:48:48AM -0700, H.J. Lu wrote:
> >> > I don't like it. Nonshared libgcc is libgcc.a, period. No sense in
> >> > creating yet another library for that.
> >>
On Fri, Apr 17, 2015 at 05:36:30AM -0700, H.J. Lu wrote:
> This patch works for me. OK for trunk?
>
> gcc/testsuite/
>
> PR target/65612
> * g++.dg/ext/mv18.C: New test.
> * g++.dg/ext/mv19.C: Likewise.
> * g++.dg/ext/mv20.C: Likewise.
> * g++.dg/ext/mv21.C: Likewise.
> * g++.dg/ext/mv22.C: Like
On Fri, Apr 17, 2015 at 4:59 AM, Jakub Jelinek wrote:
> On Fri, Apr 17, 2015 at 04:48:48AM -0700, H.J. Lu wrote:
>> > I don't like it. Nonshared libgcc is libgcc.a, period. No sense in
>> > creating yet another library for that.
>> > So, IMHO beyond making the __cpu* entrypoints compat symbols o
On Apr 17, 2015, at 1:05 AM, Uros Bizjak wrote:
> On Thu, Apr 16, 2015 at 6:28 PM, Mike Stump wrote:
>> On Apr 14, 2015, at 8:07 AM, H.J. Lu wrote:
I can confirm that the most current patch bootstraps on
x86_64-apple-darwin14 and that all of the new tests show up as
unsupported in
On Fri, Apr 17, 2015 at 04:48:48AM -0700, H.J. Lu wrote:
> > I don't like it. Nonshared libgcc is libgcc.a, period. No sense in
> > creating yet another library for that.
> > So, IMHO beyond making the __cpu* entrypoints compat symbols only (@ instead
> > of @@ symbol versions) the right fix is s
On Fri, Apr 17, 2015 at 4:37 AM, Jakub Jelinek wrote:
> On Fri, Apr 17, 2015 at 01:04:20PM +0200, Uros Bizjak wrote:
>> On Fri, Apr 17, 2015 at 12:36 PM, H.J. Lu wrote:
>>
>> > I can confirm that the most current patch bootstraps on
>> > x86_64-apple-darwin14 and that all of the new tests
On Fri, Apr 17, 2015 at 01:04:20PM +0200, Uros Bizjak wrote:
> On Fri, Apr 17, 2015 at 12:36 PM, H.J. Lu wrote:
>
> > I can confirm that the most current patch bootstraps on
> > x86_64-apple-darwin14 and that all of the new tests show up as
> > unsupported in the test suite.
> >
On Fri, Apr 17, 2015 at 1:04 PM, Uros Bizjak wrote:
> On Fri, Apr 17, 2015 at 12:36 PM, H.J. Lu wrote:
>
>> I can confirm that the most current patch bootstraps on
>> x86_64-apple-darwin14 and that all of the new tests show up as
>> unsupported in the test suite.
>> Jack
On Fri, Apr 17, 2015 at 12:36 PM, H.J. Lu wrote:
> I can confirm that the most current patch bootstraps on
> x86_64-apple-darwin14 and that all of the new tests show up as
> unsupported in the test suite.
> Jack
I am re-posting this patch. OK for trunk?
>>>
>>>
On Fri, Apr 17, 2015 at 1:05 AM, Uros Bizjak wrote:
> On Thu, Apr 16, 2015 at 6:28 PM, Mike Stump wrote:
>> On Apr 14, 2015, at 8:07 AM, H.J. Lu wrote:
I can confirm that the most current patch bootstraps on
x86_64-apple-darwin14 and that all of the new tests show up as
unsupporte
On Thu, Apr 16, 2015 at 6:28 PM, Mike Stump wrote:
> On Apr 14, 2015, at 8:07 AM, H.J. Lu wrote:
>>> I can confirm that the most current patch bootstraps on
>>> x86_64-apple-darwin14 and that all of the new tests show up as
>>> unsupported in the test suite.
>>> Jack
>>
>> I am re-postin
On Apr 14, 2015, at 8:07 AM, H.J. Lu wrote:
>> I can confirm that the most current patch bootstraps on
>> x86_64-apple-darwin14 and that all of the new tests show up as
>> unsupported in the test suite.
>> Jack
>
> I am re-posting this patch. OK for trunk?
If Jack is happy, I’m happy.
On Tue, Mar 31, 2015 at 11:33 AM, Jack Howarth wrote:
> On Tue, Mar 31, 2015 at 1:00 PM, H.J. Lu wrote:
>> On Tue, Mar 31, 2015 at 9:39 AM, Jack Howarth
>> wrote:
>>> On Tue, Mar 31, 2015 at 12:14 PM, H.J. Lu wrote:
On Tue, Mar 31, 2015 at 9:09 AM, Jack Howarth
wrote:
> H.J.,
>
On Tue, Mar 31, 2015 at 1:00 PM, H.J. Lu wrote:
> On Tue, Mar 31, 2015 at 9:39 AM, Jack Howarth
> wrote:
>> On Tue, Mar 31, 2015 at 12:14 PM, H.J. Lu wrote:
>>> On Tue, Mar 31, 2015 at 9:09 AM, Jack Howarth
>>> wrote:
H.J.,
Did you attach the correct version of the patch? I don'
On Tue, Mar 31, 2015 at 9:39 AM, Jack Howarth wrote:
> On Tue, Mar 31, 2015 at 12:14 PM, H.J. Lu wrote:
>> On Tue, Mar 31, 2015 at 9:09 AM, Jack Howarth
>> wrote:
>>> H.J.,
>>> Did you attach the correct version of the patch? I don't see
>>> anything conditional on linux.
>>> Ja
On Tue, Mar 31, 2015 at 12:14 PM, H.J. Lu wrote:
> On Tue, Mar 31, 2015 at 9:09 AM, Jack Howarth
> wrote:
>> H.J.,
>> Did you attach the correct version of the patch? I don't see
>> anything conditional on linux.
>> Jack
>
> My patch will build and install libgcc_nonshared.a for
On Tue, Mar 31, 2015 at 9:09 AM, Jack Howarth wrote:
> H.J.,
> Did you attach the correct version of the patch? I don't see
> anything conditional on linux.
> Jack
My patch will build and install libgcc_nonshared.a for all targets. If you
don't link against it, nothing is changed
H.J.,
Did you attach the correct version of the patch? I don't see
anything conditional on linux.
Jack
On Tue, Mar 31, 2015 at 11:58 AM, H.J. Lu wrote:
> On Tue, Mar 31, 2015 at 7:25 AM, Jack Howarth
> wrote:
>> H.J.,
>> While the latest patch fails to bootstrap on x86_64-a
On Tue, Mar 31, 2015 at 7:25 AM, Jack Howarth wrote:
> H.J.,
> While the latest patch fails to bootstrap on x86_64-apple-darwin14...
>
> _restore_x86_fp_state in os-unix-sysdep.o
> _sysdep_save_fp_ctrl_state in os-unix-sysdep.o
> ld: symbol(s) not found for architecture x86_64
> c
H.J.,
While the latest patch fails to bootstrap on x86_64-apple-darwin14...
make[2]: Entering directory
'/sw/src/fink.build/gcc5-5.0.0-1/darwin_objdir/x86_64-apple-darwin14.3.0/libcilkrts'
/bin/sh ./libtool --tag=CXX --mode=link
/sw/src/fink.build/gcc5-5.0.0-1/darwin_objdir/./gcc/xg++
-B/sw
On Mon, Mar 30, 2015 at 10:38 PM, Jakub Jelinek wrote:
> On Mon, Mar 30, 2015 at 07:08:00PM -0700, H.J. Lu wrote:
>> --- a/gcc/gcc.c
>> +++ b/gcc/gcc.c
>> @@ -1566,11 +1566,13 @@ init_spec (void)
>> if (in_sep && *p == '-' && strncmp (p, "-lgcc", 5) == 0)
>> {
>> init_gcc_s
Jakub Jelinek writes:
>> @@ -424,3 +424,8 @@ __cpu_indicator_init (void)
>>
>>return 0;
>> }
>> +
>> +#if defined SHARED && !defined _WIN32
>> +__asm__ (".symver __cpu_indicator_init, __cpu_indicator_init@GCC_4.8.0");
>> +__asm__ (".symver __cpu_model, __cpu_model@GCC_4.8.0");
>> +#endif
>
On Mon, Mar 30, 2015 at 07:08:00PM -0700, H.J. Lu wrote:
> --- a/gcc/gcc.c
> +++ b/gcc/gcc.c
> @@ -1566,11 +1566,13 @@ init_spec (void)
> if (in_sep && *p == '-' && strncmp (p, "-lgcc", 5) == 0)
> {
> init_gcc_specs (&obstack,
> + "-lgcc_nonshared "
>
On Mon, Mar 30, 2015 at 8:09 PM, Jack Howarth wrote:
> H.J.,
>This still breaks the darwin bootstrap but differently.
>
> ar rc libgcc_eh.a $objects
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib:
> file: libgcc_eh.a(unwind-sjlj.o) has no symbo
On Mon, Mar 30, 2015 at 10:42 PM, H.J. Lu wrote:
> On Mon, Mar 30, 2015 at 7:08 PM, H.J. Lu wrote:
>> On Mon, Mar 30, 2015 at 5:53 PM, Jack Howarth
>> wrote:
>>> HJ,
>>> This patch breaks the bootstrap on targets like darwin which
>>> don't build libgcc_nonshared.a...
>>>
>>> if test -z "$
H.J.,
This still breaks the darwin bootstrap but differently.
ar rc libgcc_eh.a $objects
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib:
file: libgcc_eh.a(unwind-sjlj.o) has no symbols
ranlib libgcc_eh.a
/Applications/Xcode.app/Contents/Developer/
On Mon, Mar 30, 2015 at 7:08 PM, H.J. Lu wrote:
> On Mon, Mar 30, 2015 at 5:53 PM, Jack Howarth
> wrote:
>> HJ,
>> This patch breaks the bootstrap on targets like darwin which
>> don't build libgcc_nonshared.a...
>>
>> if test -z "$objects"; then \
>> echo 'int __libgcc_eh_dummy;' > eh_du
On Mon, Mar 30, 2015 at 5:53 PM, Jack Howarth wrote:
> HJ,
> This patch breaks the bootstrap on targets like darwin which
> don't build libgcc_nonshared.a...
>
> if test -z "$objects"; then \
> echo 'int __libgcc_eh_dummy;' > eh_dummy.c; \
> /sw/src/fink.build/gcc5-5.0.0-1/darwin_objdir/.
HJ,
This patch breaks the bootstrap on targets like darwin which
don't build libgcc_nonshared.a...
if test -z "$objects"; then \
echo 'int __libgcc_eh_dummy;' > eh_dummy.c; \
/sw/src/fink.build/gcc5-5.0.0-1/darwin_objdir/./gcc/xgcc
-B/sw/src/fink.build/gcc5-5.0.0-1/darwin_objdir/./gcc/
-B
On Sun, Mar 29, 2015 at 7:40 PM, H.J. Lu wrote:
> On Sun, Mar 29, 2015 at 7:34 PM, H.J. Lu wrote:
>> On Sun, Mar 29, 2015 at 7:25 PM, H.J. Lu wrote:
>>> We shouldn't call external function, __cpu_indicator_init, while an object
>>> is being relocated since its .got.plt section hasn't been update
On Sun, Mar 29, 2015 at 7:34 PM, H.J. Lu wrote:
> On Sun, Mar 29, 2015 at 7:25 PM, H.J. Lu wrote:
>> We shouldn't call external function, __cpu_indicator_init, while an object
>> is being relocated since its .got.plt section hasn't been updated. It
>> works for non-PIE since no update on .got.pl
On Sun, Mar 29, 2015 at 7:25 PM, H.J. Lu wrote:
> We shouldn't call external function, __cpu_indicator_init, while an object
> is being relocated since its .got.plt section hasn't been updated. It
> works for non-PIE since no update on .got.plt section is required. This
> patch hides __cpu_indic
We shouldn't call external function, __cpu_indicator_init, while an object
is being relocated since its .got.plt section hasn't been updated. It
works for non-PIE since no update on .got.plt section is required. This
patch hides __cpu_indicator_init/__cpu_model from linker to force linker
to reso
46 matches
Mail list logo
