Re: [patch, build] Restore bootstrap in building libcc1 on darwin
10-days ping This restores bootstrap on a secondary target, target maintainer is OK with it. I think I need build maintainers approval, so please review. > when the freshly built g++ is used, we need to pass the appropriate -B > options. As I understand it, the appropriate place for that is in the > toplevel configure.ac, where we already pass down the respective -L options. > Indeed, the attached patch restores bootstrap on x86_64-apple-darwin14 with > gcc as system compiler (and doesn’t break the bootstrap with clang as system > compiler). > > OK to commit? > > FX > > > > PS: HJ, the reason only don’t see this on Linux is that only Darwin (AFAIK) > plays spec tricks with static-libstdc++ (in gcc/config/darwin.h) libcc1.ChangeLog Description: Binary data libcc1.diff Description: Binary data
Re: pointer math vs named address spaces
On Wed, Dec 3, 2014 at 11:34 PM, DJ Delorie wrote:
>
> If a target (rl78-elf in my case) has a named address space larger
> than the generic address space (__far in my case), why is pointer math
> in that named address space still truncated to sizetype?
>
> N1275 recognizes that named address spaces might be a different size
> than the generic address space, but I didn't see anything that
> required such truncation.
>
>
> volatile char __far * ptr1;
> volatile char __far * ptr2;
> uint32_t sival;
>
> foo()
> {
> ptr2 = ptr1 + sival;
> }
>
> foo ()
> {
> volatile char * ptr2.5;
> sizetype D.2252;
> long unsigned int sival.4;
> volatile char * ptr1.3;
> sizetype _3;
>
> ;; basic block 2, loop depth 0
> ;;pred: ENTRY
> ptr1.3_1 = ptr1;
> sival.4_2 = sival;
> _3 = (sizetype) sival.4_2;<--- why this truncation?
> ptr2.5_4 = ptr1.3_1 + _3;
> ptr2 = ptr2.5_4;
> return;
> ;;succ: EXIT
>
> }
Apart from what Joseph already said using 'sizetype' in the middle-end
for sizes and offsets is really really deep-rooted into the compiler.
What you see above is one aspect - POINTER_PLUS_EXPR offsets
are forced to have sizetype type. But you'd also see it in the inability
to create larger than sizetype objects (DECL_SIZE_UNITs type).
So for the middle-end part I'd suggest you make sure that sizetype
covers the largest pointer-mode precision your target offers. That of course
doesn't fix what Joseph pointed out - that the user will still run into issues
when writing C programs or when using the C runtime (I suppose TR 18037
doesn't specify alternate memcpy for different address spaces?)
Richard.
Re: [patch, build] Restore bootstrap in building libcc1 on darwin
FX writes: > 10-days ping > This restores bootstrap on a secondary target, target maintainer is OK with > it. I think I need build maintainers approval, so please review. While in my testing, 64-bit Mac OS X 10.10.1 (x86_64-apple-darwin14.0.0) now bootstraps, but 32-bit (i386-apple-darwin14.0.0) does not: ld: illegal text-relocation to 'anon' in ../libiberty/pic/libiberty.a(regex.o) from '_byte_common_op_match_null_string_p' in ../libiberty/pic/libiberty.a(regex.o) for architecture i386 collect2: error: ld returned 1 exit status make[3]: *** [libcc1.la] Error 1 make[2]: *** [all] Error 2 make[1]: *** [all-libcc1] Error 2 I couldn't find a corresponding reloc in otool -rv output, though. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [patch, build] Restore bootstrap in building libcc1 on darwin
> While in my testing, 64-bit Mac OS X 10.10.1 (x86_64-apple-darwin14.0.0) > now bootstraps, but 32-bit (i386-apple-darwin14.0.0) does not: Is it due to my patch, or pre-existing bootstrap failure? How do you configure this 32-bit compiler? target/build/host/CFLAGS/CXXFLAGS/etc FX
Re: [patch, build] Restore bootstrap in building libcc1 on darwin
Hi Rainer,
On 4 Dec 2014, at 13:32, Rainer Orth wrote:
> FX writes:
>
>> 10-days ping
>> This restores bootstrap on a secondary target, target maintainer is OK with
>> it. I think I need build maintainers approval, so please review.
>
> While in my testing, 64-bit Mac OS X 10.10.1 (x86_64-apple-darwin14.0.0)
> now bootstraps, but 32-bit (i386-apple-darwin14.0.0) does not:
>
> ld: illegal text-relocation to 'anon' in
> ../libiberty/pic/libiberty.a(regex.o) from
> '_byte_common_op_match_null_string_p' in
> ../libiberty/pic/libiberty.a(regex.o) for architecture i386
> collect2: error: ld returned 1 exit status
> make[3]: *** [libcc1.la] Error 1
> make[2]: *** [all] Error 2
> make[1]: *** [all-libcc1] Error 2
For {i?86,ppc}-darwin* (i.e. m32 hosts) the PIC libiberty library is being
incorrectly built.
The default BOOT_CFLAGS are: -O2 -g -mdynamic-no-pic
the libiberty pic build appends: -fno-common (and not even -fPIC) [NB -fPIC
_won't_ override -mdynamic-no-pic, so that's not a simple way out]
This means that the PIC library is being built with non-pic relocs.
I have a local hack to allow build to proceed on m32-host-darwin (which I can
send to you if you would like it) - however, it's not really a suitable patch
for trunk... and I've not had time recently to try and fix this.
If you would like to raise a PR for this, I can append the analysis there.
cheers
Iain
Re: [patch, build] Restore bootstrap in building libcc1 on darwin
FX writes: >> While in my testing, 64-bit Mac OS X 10.10.1 (x86_64-apple-darwin14.0.0) >> now bootstraps, but 32-bit (i386-apple-darwin14.0.0) does not: > > Is it due to my patch, or pre-existing bootstrap failure? I can't tell: before your patch, 32-bit bootstrap was broken due to PR bootstrap/63966 for quite some time. > How do you configure this 32-bit compiler? > target/build/host/CFLAGS/CXXFLAGS/etc --target=i386-apple-darwin14.0.0 --build=i386-apple-darwin14.0.0 --host=i386-apple-darwin14.0.0 --enable-languages=all,ada,obj-c++ Bootstrap compiler is gcc 4.9.1 (patched for 10.10 support) CC='gcc -m32' CXX='g++ -m32' Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [patch, build] Restore bootstrap in building libcc1 on darwin
On Thu, Dec 4, 2014 at 2:43 PM, Iain Sandoe wrote:
> Hi Rainer,
>
> On 4 Dec 2014, at 13:32, Rainer Orth wrote:
>
>> FX writes:
>>
>>> 10-days ping
>>> This restores bootstrap on a secondary target, target maintainer is OK with
>>> it. I think I need build maintainers approval, so please review.
>>
>> While in my testing, 64-bit Mac OS X 10.10.1 (x86_64-apple-darwin14.0.0)
>> now bootstraps, but 32-bit (i386-apple-darwin14.0.0) does not:
>>
>> ld: illegal text-relocation to 'anon' in
>> ../libiberty/pic/libiberty.a(regex.o) from
>> '_byte_common_op_match_null_string_p' in
>> ../libiberty/pic/libiberty.a(regex.o) for architecture i386
>> collect2: error: ld returned 1 exit status
>> make[3]: *** [libcc1.la] Error 1
>> make[2]: *** [all] Error 2
>> make[1]: *** [all-libcc1] Error 2
>
> For {i?86,ppc}-darwin* (i.e. m32 hosts) the PIC libiberty library is being
> incorrectly built.
>
> The default BOOT_CFLAGS are: -O2 -g -mdynamic-no-pic
> the libiberty pic build appends: -fno-common (and not even -fPIC) [NB -fPIC
> _won't_ override -mdynamic-no-pic, so that's not a simple way out]
>
> This means that the PIC library is being built with non-pic relocs.
>
> I have a local hack to allow build to proceed on m32-host-darwin (which I can
> send to you if you would like it) - however, it's not really a suitable patch
> for trunk... and I've not had time recently to try and fix this.
>
> If you would like to raise a PR for this, I can append the analysis there.
The libiberty PIC build shouldn't use BOOT_CFLAGS. How does
lto-plugin get around being built for the host but as a shared library?
Richard.
> cheers
> Iain
>
Re: [patch, build] Restore bootstrap in building libcc1 on darwin
On Thu, Dec 4, 2014 at 2:47 PM, Richard Biener
wrote:
> On Thu, Dec 4, 2014 at 2:43 PM, Iain Sandoe wrote:
>> Hi Rainer,
>>
>> On 4 Dec 2014, at 13:32, Rainer Orth wrote:
>>
>>> FX writes:
>>>
10-days ping
This restores bootstrap on a secondary target, target maintainer is OK with
it. I think I need build maintainers approval, so please review.
>>>
>>> While in my testing, 64-bit Mac OS X 10.10.1 (x86_64-apple-darwin14.0.0)
>>> now bootstraps, but 32-bit (i386-apple-darwin14.0.0) does not:
>>>
>>> ld: illegal text-relocation to 'anon' in
>>> ../libiberty/pic/libiberty.a(regex.o) from
>>> '_byte_common_op_match_null_string_p' in
>>> ../libiberty/pic/libiberty.a(regex.o) for architecture i386
>>> collect2: error: ld returned 1 exit status
>>> make[3]: *** [libcc1.la] Error 1
>>> make[2]: *** [all] Error 2
>>> make[1]: *** [all-libcc1] Error 2
>>
>> For {i?86,ppc}-darwin* (i.e. m32 hosts) the PIC libiberty library is being
>> incorrectly built.
>>
>> The default BOOT_CFLAGS are: -O2 -g -mdynamic-no-pic
>> the libiberty pic build appends: -fno-common (and not even -fPIC) [NB -fPIC
>> _won't_ override -mdynamic-no-pic, so that's not a simple way out]
>>
>> This means that the PIC library is being built with non-pic relocs.
>>
>> I have a local hack to allow build to proceed on m32-host-darwin (which I
>> can send to you if you would like it) - however, it's not really a suitable
>> patch for trunk... and I've not had time recently to try and fix this.
>>
>> If you would like to raise a PR for this, I can append the analysis there.
>
> The libiberty PIC build shouldn't use BOOT_CFLAGS. How does
> lto-plugin get around being built for the host but as a shared library?
That is, the mistake is probably adding -mdynamic-no-pic to BOOT_CFLAGS
rather than in more contained places when building files for the host
_binaries_.
Richard.
> Richard.
>
>> cheers
>> Iain
>>
Re: [patch, build] Restore bootstrap in building libcc1 on darwin
> The default BOOT_CFLAGS are: -O2 -g -mdynamic-no-pic > the libiberty pic build appends: -fno-common (and not even -fPIC) [NB -fPIC > _won't_ override -mdynamic-no-pic, so that's not a simple way out] > This means that the PIC library is being built with non-pic relocs. config/mh-darwin says that -mdynamic-no-pic is there because it “speeds compiles by 3-5%”. I don’t think we care about speed when the bootstrap fails, so can we remove it altogether? FX darwin.diff Description: Binary data
Re: [patch, build] Restore bootstrap in building libcc1 on darwin
On Thu, Dec 4, 2014 at 2:48 PM, Richard Biener
wrote:
> On Thu, Dec 4, 2014 at 2:47 PM, Richard Biener
> wrote:
>> On Thu, Dec 4, 2014 at 2:43 PM, Iain Sandoe wrote:
>>> Hi Rainer,
>>>
>>> On 4 Dec 2014, at 13:32, Rainer Orth wrote:
>>>
FX writes:
> 10-days ping
> This restores bootstrap on a secondary target, target maintainer is OK
> with
> it. I think I need build maintainers approval, so please review.
While in my testing, 64-bit Mac OS X 10.10.1 (x86_64-apple-darwin14.0.0)
now bootstraps, but 32-bit (i386-apple-darwin14.0.0) does not:
ld: illegal text-relocation to 'anon' in
../libiberty/pic/libiberty.a(regex.o) from
'_byte_common_op_match_null_string_p' in
../libiberty/pic/libiberty.a(regex.o) for architecture i386
collect2: error: ld returned 1 exit status
make[3]: *** [libcc1.la] Error 1
make[2]: *** [all] Error 2
make[1]: *** [all-libcc1] Error 2
>>>
>>> For {i?86,ppc}-darwin* (i.e. m32 hosts) the PIC libiberty library is being
>>> incorrectly built.
>>>
>>> The default BOOT_CFLAGS are: -O2 -g -mdynamic-no-pic
>>> the libiberty pic build appends: -fno-common (and not even -fPIC) [NB -fPIC
>>> _won't_ override -mdynamic-no-pic, so that's not a simple way out]
>>>
>>> This means that the PIC library is being built with non-pic relocs.
>>>
>>> I have a local hack to allow build to proceed on m32-host-darwin (which I
>>> can send to you if you would like it) - however, it's not really a suitable
>>> patch for trunk... and I've not had time recently to try and fix this.
>>>
>>> If you would like to raise a PR for this, I can append the analysis there.
>>
>> The libiberty PIC build shouldn't use BOOT_CFLAGS. How does
>> lto-plugin get around being built for the host but as a shared library?
>
> That is, the mistake is probably adding -mdynamic-no-pic to BOOT_CFLAGS
> rather than in more contained places when building files for the host
> _binaries_.
Where T_CFLAGS should have been used?
Richard.
> Richard.
>
>> Richard.
>>
>>> cheers
>>> Iain
>>>
Re: [patch, build] Restore bootstrap in building libcc1 on darwin
On Thu, Dec 4, 2014 at 2:52 PM, FX wrote: >> The default BOOT_CFLAGS are: -O2 -g -mdynamic-no-pic >> the libiberty pic build appends: -fno-common (and not even -fPIC) [NB -fPIC >> _won't_ override -mdynamic-no-pic, so that's not a simple way out] >> This means that the PIC library is being built with non-pic relocs. > > config/mh-darwin says that -mdynamic-no-pic is there because it “speeds > compiles by 3-5%”. I don’t think we care about speed when the bootstrap > fails, so can we remove it altogether? Can you try adding it as T_CFLAGS += -mdynamic-no-pic in gcc/config/t-tarwin instead? > FX > >
Re: [patch, build] Restore bootstrap in building libcc1 on darwin
> Can you try adding it as > > T_CFLAGS += -mdynamic-no-pic > > in gcc/config/t-tarwin instead? Nope, doing so fails to link libgcc_s.dylib: /Users/fx/devel/gcc/i/./gcc/xgcc -B/Users/fx/devel/gcc/i/./gcc/ -B/Users/fx/devel/gcc/i2/i386-apple-darwin14.0.0/bin/ -B/Users/fx/devel/gcc/i2/i386-apple-darwin14.0.0/lib/ -isystem /Users/fx/devel/gcc/i2/i386-apple-darwin14.0.0/include -isystem /Users/fx/devel/gcc/i2/i386-apple-darwin14.0.0/sys-include-O2 -g -O2 -DIN_GCC-mdynamic-no-pic -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -pipe -fno-common -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -dynamiclib -nodefaultlibs -install_name /Users/fx/devel/gcc/i2/lib/libgcc_s.1.dylib -single_module -o ./libgcc_s.dylib -Wl,-exported_symbols_list,libgcc.map -compatibility_version 1 -current_version 1.0 -g -O2 -B./ _muldi3_s.o _negdi2_s.o _lshrdi3_s.o _ashldi3_s.o _ashrdi3_s.o _cmpdi2_s.o _ucmpdi2_s.o _clear_cache_s.o _trampoline_s.o __main_s.o _absvsi2_s.o _absvdi2_s.o _addvsi3_s.o _addvdi3_s.o _subvsi3_s.o _subvdi3_s.o _mulvsi3_s.o _mulvdi3_s.o _negvsi2_s.o _negvdi2_s.o _ctors_s.o _ffssi2_s.o _ffsdi2_s.o _clz_s.o _clzsi2_s.o _clzdi2_s.o _ctzsi2_s.o _ctzdi2_s.o _popcount_tab_s.o _popcountsi2_s.o _popcountdi2_s.o _paritysi2_s.o _paritydi2_s.o _powisf2_s.o _powidf2_s.o _powixf2_s.o _powitf2_s.o _mulsc3_s.o _muldc3_s.o _mulxc3_s.o _multc3_s.o _divsc3_s.o _divdc3_s.o _divxc3_s.o _divtc3_s.o _bswapsi2_s.o _bswapdi2_s.o _clrsbsi2_s.o _clrsbdi2_s.o _fixunssfsi_s.o _fixunsdfsi_s.o _fixunsxfsi_s.o _fixsfdi_s.o _fixdfdi_s.o _fixxfdi_s.o _fixunssfdi_s.o _fixunsdfdi_s.o _fixunsxfdi_s.o _floatdisf_s.o _floatdidf_s.o _floatdixf_s.o _floatundisf_s.o _floatundidf_s.o _floatundixf_s.o _fixsfti_s.o _fixdfti_s.o _fixxfti_s.o _fixtfti_s.o _fixunssfti_s.o _fixunsdfti_s.o _fixunsxfti_s.o _fixunstfti_s.o _floattisf_s.o _floattidf_s.o _floattixf_s.o _floattitf_s.o _floatuntisf_s.o _floatuntidf_s.o _floatuntixf_s.o _floatuntitf_s.o _divdi3_s.o _moddi3_s.o _udivdi3_s.o _umoddi3_s.o _udiv_w_sdiv_s.o _udivmoddi4_s.o darwin-64_s.o cpuinfo_s.o tf-signs_s.o sfp-exceptions_s.o addtf3_s.o divtf3_s.o eqtf2_s.o getf2_s.o letf2_s.o multf3_s.o negtf2_s.o subtf3_s.o unordtf2_s.o fixtfsi_s.o fixunstfsi_s.o floatsitf_s.o floatunsitf_s.o fixtfdi_s.o fixunstfdi_s.o floatditf_s.o floatunditf_s.o extendsftf2_s.o extenddftf2_s.o extendxftf2_s.o trunctfsf2_s.o trunctfdf2_s.o trunctfxf2_s.o enable-execute-stack_s.o unwind-dw2_s.o unwind-dw2-fde-darwin_s.o unwind-sjlj_s.o unwind-c_s.o emutls_s.o libgcc.a -lc ld: warning: could not create compact unwind for __Unwind_RaiseException: does not use EBP or ESP based frame ld: warning: could not create compact unwind for __Unwind_ForcedUnwind: does not use EBP or ESP based frame ld: warning: could not create compact unwind for __Unwind_Resume: does not use EBP or ESP based frame ld: warning: could not create compact unwind for __Unwind_Resume_or_Rethrow: does not use EBP or ESP based frame ld: illegal text-relocation to '4-byte-literal' in _powisf2_s.o from '___powisf2' in _powisf2_s.o for architecture i386 collect2: error: ld returned 1 exit status make[3]: *** [libgcc_s.dylib] Error 1 make[2]: *** [all-stage1-target-libgcc] Error 2 make[1]: *** [stage1-bubble] Error 2 make: *** [all] Error 2
Re: [patch, build] Restore bootstrap in building libcc1 on darwin
On 4 Dec 2014, at 15:24, FX wrote: >> Can you try adding it as >> >> T_CFLAGS += -mdynamic-no-pic >> >> in gcc/config/t-tarwin instead? > -mdynamic-no-pic should be used to build *host* executable stuff for m32 darwin. It is not suitable for building shared libraries (hence the problem with building the PIC version of libiberty) and won't work for the target libaries for similar reasons. If you want a "quick fix", sure remove it from the boot cflags - but it's hiding a real issue which is that the pic build of libiberty does not cater for the possibility that the non-pic flags cannot simply be overridden by the pic ones. Of course, it's possible what darwin is the only affected target - but I'd not want to swear to that. Iain
gcc-4.8-20141204 is now available
Snapshot gcc-4.8-20141204 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.8-20141204/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.8 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_8-branch revision 218405 You'll find: gcc-4.8-20141204.tar.bz2 Complete GCC MD5=b8edb29ed4f124ce976f2996040ef0f3 SHA1=9cd03bf58bca9a0182ddd6dc29cfbab8bbf4e695 Diffs from 4.8-20141127 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.8 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
