On Mon, 4 Jun 2012, Manuel López-Ibáñez wrote:
> Well, the CPP macros could be translated to builtin calls and
> evaluated by the middle-end during or after gimplification. Then the
> FE would be really independent of the back-end. Sounds crazy?
Integer constant expressions from C standard header
On Wed, Jun 6, 2012 at 8:55 AM, David Edelsohn wrote:
> On Tue, Jun 5, 2012 at 9:56 AM, Steven Bosscher wrote:
>
>>> BSS was a later addition and there is no ".bss" pseudo-op directive,
>>> unlike the ".comm" directive. There only is the BSS storage class.
>>
>> Do you know where I could find doc
On Wed, Jun 6, 2012 at 10:07 PM, Iain Sandoe wrote:
> Hi Steven,
> The attached patch survives normal and lto bootstrap on i686-darwin9 and
> x86_64-darwin10.
> No regressions for ObjC or Obj-C++.
> Otherwise, lightly tested, but appears to solve PR 48109 on the way.
>
> changes:
>
> o [minor] t
Hi Steven,
On 5 Jun 2012, at 21:23, 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
On Tue, Jun 5, 2012 at 9:56 AM, Steven Bosscher wrote:
>> BSS was a later addition and there is no ".bss" pseudo-op directive,
>> unlike the ".comm" directive. There only is the BSS storage class.
>
> Do you know where I could find documentation for how to write out
> something with BSS storage c
> 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
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 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/
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 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 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
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
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 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
> 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 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
> ... 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/docs/base_doc/DOCUMENTATION/V50A_ACRO_SUP/OBJSPE
>C.PDF). Did
On 06/04/2012 06:35 PM, Steven Bosscher wrote:
That leaves pdp11, vax, and non-ELF cris as the only targets without
.bss support. AFAICT, that is :-)
It's not clear to me what configuration pdp11 is still supported in.
I think maybe vax-openbsd is a.out, not sure.
cris seems to be ELF-only.
On Mon, Jun 4, 2012 at 11:08 PM, Eric Botcazou wrote:
>> Hmm, Mach-O does have BSS.
>
> OK, bad memory, this was for Tru64.
Could it be that there is a bug in the way .bss section selection
works? Looking through the documentation, it seems actually rather
hard to miss the .bss section:
@defmac
On Mon, Jun 4, 2012 at 11:08 PM, Eric Botcazou wrote:
>> Hmm, Mach-O does have BSS.
>
> OK, bad memory, this was for Tru64.
... 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 me
> Hmm, Mach-O does have BSS.
OK, bad memory, this was for Tru64.
--
Eric Botcazou
On 06/04/2012 04:54 PM, Eric Botcazou wrote:
It's not necessary for XCOFF. I think it was only useful for a.out,
which doesn't support .bss.
No, the 2004 change wasn't for an a.out target, but most probably Mach-O.
Hmm, Mach-O does have BSS.
Jason
> It's not necessary for XCOFF. I think it was only useful for a.out,
> which doesn't support .bss.
No, the 2004 change wasn't for an a.out target, but most probably Mach-O.
--
Eric Botcazou
> What I don't understand, is whether this is still something GNAT has
> to support, or whether this code can be deprecated/removed.
Yes, we still need it on platforms for which have_global_bss_p is false.
In Ada, it's very easy to declare huge objects and we don't want them to take
space in the
On Mon, Jun 4, 2012 at 10:04 PM, David Edelsohn wrote:
> On Mon, Jun 4, 2012 at 3:53 PM, Steven Bosscher wrote:
>
>> What I don't understand, is whether this is still something GNAT has
>> to support, or whether this code can be deprecated/removed. And I ask
>> for your help because you are one o
On 06/04/2012 04:04 PM, David Edelsohn wrote:
Is this feature necessary for non-ELF file formats, such as AIX XCOFF?
It's not necessary for XCOFF. I think it was only useful for a.out,
which doesn't support .bss.
Jason
On Mon, Jun 4, 2012 at 3:53 PM, Steven Bosscher wrote:
> What I don't understand, is whether this is still something GNAT has
> to support, or whether this code can be deprecated/removed. And I ask
> for your help because you are one of the people who worked on this
> so-many-years ago
> (http://
On Mon, Jun 4, 2012 at 7:20 PM, Eric Botcazou wrote:
>> The code for the case in Ada is this:
>>
>> /* Ada doesn't feature Fortran-like COMMON variables so we shouldn't
>> try to fiddle with DECL_COMMON. However, on platforms that don't
>> support global BSS sections, uninitialized gl
> The code for the case in Ada is this:
>
> /* Ada doesn't feature Fortran-like COMMON variables so we shouldn't
> try to fiddle with DECL_COMMON. However, on platforms that don't
> support global BSS sections, uninitialized global variables would
> go in DATA instead, thus increa
On 06/04/2012 10:47 AM, Richard Guenther wrote:
On Mon, Jun 4, 2012 at 4:39 PM, Steven Bosscher wrote:
Jason, is this flag something that we could deprecate for GCC 4.7 and remove?
The docs say the flag is not useful these days as BSS is widely available.
Right. So yes, go ahead.
Jason
On Mon, Jun 4, 2012 at 4:58 PM, Manuel López-Ibáñez
wrote:
>> Yes, that would be the ideal case. But some target dependencies are
>> inevitable, e.g. the target CPP macros. What I'd like to see
>> eventually, is that targetm will be split up in front end and
>> middle/back end specific parts.
>
>
On Mon, Jun 4, 2012 at 4:55 PM, Richard Guenther
wrote:
>> I mean make the whole "write #ident" a target hook.
>
> Another possibility would be to generate a toplevel asm at this point ...
Yes, that might work, I'll try that. Thanks for the ideas and suggestions!
Ciao!
Steven
On 4 June 2012 16:49, Steven Bosscher wrote:
> On Mon, Jun 4, 2012 at 4:47 PM, Richard Guenther
> wrote:
>> OTOH, I suppose including target.h from the FEs is against what you
>> want to achieve, too.
>
> Yes, that would be the ideal case. But some target dependencies are
> inevitable, e.g. the t
On Mon, Jun 4, 2012 at 4:52 PM, Richard Guenther
wrote:
>>> I suppose make ASM_OUTPUT_IDENT a target hook instead.
>>
>> This doesn't really help: You'd now have a target hook called from the
>> front end that writes to asm_out_file. I want front ends to stop
>> writing to asm_out_file at all.
>
>
On Mon, Jun 4, 2012 at 4:52 PM, Richard Guenther
wrote:
> On Mon, Jun 4, 2012 at 4:50 PM, Steven Bosscher wrote:
>> On Mon, Jun 4, 2012 at 3:34 PM, Richard Guenther
>> wrote:
first_global_object_name:
ada/gcc-interface/trans.c: first_global_object_name = ggc_strdup
(IDENTIFIER_PO
On Mon, Jun 4, 2012 at 4:50 PM, Steven Bosscher wrote:
> On Mon, Jun 4, 2012 at 3:34 PM, Richard Guenther
> wrote:
>>> first_global_object_name:
>>> ada/gcc-interface/trans.c: first_global_object_name = ggc_strdup
>>> (IDENTIFIER_POINTER (t));
>>> ada/gcc-interface/utils.c: ASM_FORMAT_PRIVA
On Mon, Jun 4, 2012 at 3:34 PM, Richard Guenther
wrote:
>> first_global_object_name:
>> ada/gcc-interface/trans.c: first_global_object_name = ggc_strdup
>> (IDENTIFIER_POINTER (t));
>> ada/gcc-interface/utils.c: ASM_FORMAT_PRIVATE_NAME (label,
>> first_global_object_name, 0);
>>
>> This come
On Mon, Jun 4, 2012 at 4:47 PM, Richard Guenther
wrote:
> OTOH, I suppose including target.h from the FEs is against what you
> want to achieve, too.
Yes, that would be the ideal case. But some target dependencies are
inevitable, e.g. the target CPP macros. What I'd like to see
eventually, is tha
On Mon, Jun 4, 2012 at 4:39 PM, Steven Bosscher wrote:
> On Mon, Jun 4, 2012 at 3:34 PM, Richard Guenther
> wrote:
>>> have_global_bss_p:
>>> cp/decl.c: && !have_global_bss_p ())
>>> ada/gcc-interface/utils.c: && !have_global_bss_p ())
>>>
>>> I don't even know what this is. Help welcom
On Mon, Jun 4, 2012 at 3:34 PM, Richard Guenther
wrote:
>> have_global_bss_p:
>> cp/decl.c: && !have_global_bss_p ())
>> ada/gcc-interface/utils.c: && !have_global_bss_p ())
>>
>> I don't even know what this is. Help welcome. :-)
>
> Looks like premature optimization to me, better done i
On Mon, Jun 4, 2012 at 2:40 PM, Steven Bosscher wrote:
> Hello,
>
> In a perfect world, front ends would not be writing out anything to
> the assembler output. GCC is not part of this perfect world, at least
> not yet. It should be possible, with a little help from front-end
> maintainers, especia
> "Steven" == Steven Bosscher writes:
[...]
Steven> java/class.c: switch_to_section (get_section (buf, flags, NULL));
Steven> java/class.c: switch_to_section (get_section (buf, flags, NULL));
Steven> I am not sure how to fix this. I think it could be fixed by having a
Steven> versio
On Mon, Jun 4, 2012 at 2:40 PM, Steven Bosscher wrote:
> asm_out_file for PCH:
> c-family/c-pch.c:#include "output.h" /* for asm_out_file */
> c-family/c-pch.c: fprintf (asm_out_file, "%s ", ASM_COMMENT_START);
> c-family/c-pch.c: c_common_print_pch_checksum (asm_out_file);
> c-family/c-
Hello,
In a perfect world, front ends would not be writing out anything to
the assembler output. GCC is not part of this perfect world, at least
not yet. It should be possible, with a little help from front-end
maintainers, especially for Ada and ObjC and someone knowledgeable of
PCH, to enforce a
44 matches
Mail list logo
