On Sun, 3 Jun 2012, H.J. Lu wrote:
> On Wed, May 30, 2012 at 6:08 AM, Richard Guenther wrote:
> >
> > Status
> > ==
> >
> > The GCC 4.7 branch is in regression and documentation fixes only state.
> >
> > A release candidate for GCC 4.7.1 is scheduled for the beginning of
> > next week. This
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
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-
> "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:
> 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
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 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 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 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: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 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: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 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: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 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 1:44 AM, Richard Sandiford
wrote:
> Klaus Pedersen writes:
[...]
>> My original fix, that use sane cost for the ACC_REGS: gpr_acc_cost_3.patch
>
> Why sane? Transfers from and (especially) to HI and LO really are
> expensive on many processors. Obviously it'd be nice at s
On Wed, 2012-05-30 at 14:27 -0400, David Edelsohn wrote:
> On Wed, May 30, 2012 at 1:39 PM, Steve Ellcey wrote:
> >
>
> > My question is: When checking the value of TARGET_SYNCI is there anyway
> > to tell if the flag was set explicitly by the user or implicitly by
> > the compiler? The reason I
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
> 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 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
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 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 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
> 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
> 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
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
> Hmm, Mach-O does have BSS.
OK, bad memory, this was for Tru64.
--
Eric Botcazou
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
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 3 June 2012 17:06, i-love-spam wrote:
> I'm writing some optimized functions for gcc-arm in a library that obuses
> shorts. So the problem I have is that in extremely many places resutls of my
> optimized functions are needlessly sign or zero extended. That is, gcc adds
> UXTH or SXTH opcode
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 12-05-31 10:28 , Joseph S. Myers wrote:
That is however installed testing with a complete source tree available
(but not a build tree); I don't know exactly what is needed from outside
the testsuite/ directory (but see
libstdc++-v3/testsuite/lib/libstdc++.exp:libstdc++_init for what happens
d
> ... 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
33 matches
Mail list logo
