On Tue, Jun 5, 2012 at 7:57 AM, Eric Botcazou wrote:
>> ... which has been deprecated for GCC 4.7 (see
>> http://gcc.gnu.org/gcc-4.7/changes.html). Support for Tru64 has
>> already been removed on trunk. Tru64 was ECOFF, right? That means that
>> Tru64 also has BSS
>> (http://h30097.www3.hp.com/do
The GCC 4.7 branch is now frozen for creating a first release candidate
of the GCC 4.7.1 release.
All changes need explicit release manager approval until the final
release of GCC 4.7.1 which should happen roughly one week after
the release candidate if no issues show up with it.
Previous Repo
> Part of the problem why it isn't put there by gcc 4.7 because the
> initializer is not a bss_initializer_p initializer. And this is
> because GNAT explicitly disables this in misc.c:
>
> /* Initialize options structure OPTS. */
>
> static void
> gnat_init_options_struct (struct gcc_options *opts
On Tue, Jun 5, 2012 at 1:07 PM, Eric Botcazou wrote:
>> Part of the problem why it isn't put there by gcc 4.7 because the
>> initializer is not a bss_initializer_p initializer. And this is
>> because GNAT explicitly disables this in misc.c:
>>
>> /* Initialize options structure OPTS. */
>>
>> sta
On Tue, Jun 5, 2012 at 7:07 AM, Eric Botcazou wrote:
>> The same happens for rs6000-ibm-aix6.1, which also doesn't have
>> BSS_SECTION_ASM_OP, even though there should be BSS support for XCOFF
>> (http://pic.dhe.ibm.com/infocenter/aix/v6r1/index.jsp?topic=%2Fcom.ibm.aix.
>>files%2Fdoc%2Faixfiles%
On Tue, Jun 5, 2012 at 3:47 PM, David Edelsohn wrote:
> On Tue, Jun 5, 2012 at 7:07 AM, Eric Botcazou wrote:
>
>>> The same happens for rs6000-ibm-aix6.1, which also doesn't have
>>> BSS_SECTION_ASM_OP, even though there should be BSS support for XCOFF
>>> (http://pic.dhe.ibm.com/infocenter/aix/v
Hi Steven,
On 4 Jun 2012, at 13:40, Steven Bosscher wrote:
>
> asm_out_file for NEXT runtime ABI v01:
> objc/objc-next-runtime-abi-01.c:#include "output.h" /* for asm_out_file */
> objc/objc-next-runtime-abi-01.c: ASM_DECLARE_UNRESOLVED_REFERENCE
> (asm_out_file, string);
> objc/objc-next-runtim
A couple of merge conflicts this time.
Tested on x86_64.
Diego.
This is the beta release of binutils 2.22.52.0.4 for Linux, which is
based on binutils 2012 0604 in CVS on sourceware.org plus various
changes. It is purely for Linux.
All relevant patches in patches have been applied to the source tree.
You can take a look at patches/README to see what have been
On Tue, Jun 5, 2012 at 4:15 PM, Iain Sandoe wrote:
> As it happens, the code should be as well-tested as for V1 as V2 ABI -
> since it is conventional to test ObjC/NeXT at m32(V1) and m64(V2) [[and
> also the GNU runtime (on Darwin)]].
>
> So whilst Darwin is not as well-tested as linux, at least
Hi Steven,
On 5 Jun 2012, at 19:01, Steven Bosscher wrote:
> On Tue, Jun 5, 2012 at 4:15 PM, Iain Sandoe wrote:
>> As it happens, the code should be as well-tested as for V1 as V2 ABI -
>> since it is conventional to test ObjC/NeXT at m32(V1) and m64(V2) [[and
>> also the GNU runtime (on Darwin)
On Tue, Jun 5, 2012 at 8:55 PM, Iain Sandoe wrote:
> I would welcome a simple solution if one is available, although I don't quite
> see what you have in mind at present.
This is what I have in mind. Untested, but it shows the idea. What do
you think of this?
Ciao!
Steven
gcc/
* config/
On Jun 5, 2012, at 1:23 PM, Steven Bosscher wrote:
> On Tue, Jun 5, 2012 at 8:55 PM, Iain Sandoe wrote:
>> I would welcome a simple solution if one is available, although I don't
>> quite see what you have in mind at present.
>
> This is what I have in mind. Untested, but it shows the idea. What
On Fri, 25 May 2012, DJ Delorie wrote:
> If I apply this patch, which checks for duplicate hard registers within
> -fira-share-save-slots, the following *-elf targets fail due to the assert:
>
> bfin cris m32c rl78 rx sh sh64 v850
Oop. An no clue as to what's wrong.
Can you pretty please m
On 06/05/2012 07:59 PM, Hans-Peter Nilsson wrote:
On Fri, 25 May 2012, DJ Delorie wrote:
If I apply this patch, which checks for duplicate hard registers within
-fira-share-save-slots, the following *-elf targets fail due to the assert:
bfin cris m32c rl78 rx sh sh64 v850
Oop. An no
> BSS was a later addition and there is no ".bss" pseudo-op directive,
> unlike the ".comm" directive. There only is the BSS storage class.
OK, thanks, this looks similar to the Tru64 situation.
--
Eric Botcazou
16 matches
Mail list logo
