Re: GCC 4.7.1 Status Report (2012-05-30)
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 is a good time to verify regression status for > > your favorite target and to consider to flush your pending 4.7-branch > > patches list. > > > > As usual the number of bugs is slowly increasing. Still many serious > > bugs have been fixed. > > > > > > Quality Data > > > > > > Priority # Change from Last Report > > --- --- > > P1 0 > > P2 85 + 19 > > P3 5 - 8 > > --- --- > > Total 90 + 11 > > > > > > Previous Report > > === > > > > http://gcc.gnu.org/ml/gcc/2012-03/msg00345.html > > > > The next report will be sent by me when announcing the release > > candidate. > > Can we fix > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53539 > > for GCC 4.7.1? It does not look like it is fixed for trunk even. Would be applicable for 4.7.1 or 4.7.2, too. Richard.
[RFH] Uses of output.h in the front ends
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 rule that a front end must not #include output.h.
A part of the compiler that writes to the assembler output has to
include output.h or use one of the functions prototyped there.
Therefore I have tried to remove #includes of output.h last week. I am
stuck on 9 files that still have to include output.h for the following
symbols:
1. assemble_string
2. get_section
3. switch_to_section
4. have_global_bss_p
5. first_global_object_name
6. asm_out_file
The uses of these symbols are in the following files:
assemble_string / get_section / switch_to_section:
go/go-backend.c: assemble_string (bytes, size);
go/go-backend.c: sec = get_section (GO_EXPORT_SECTION_NAME,
SECTION_DEBUG, NULL);
go/go-backend.c: switch_to_section (sec);
java/class.c: switch_to_section (get_section (buf, flags, NULL));
java/class.c: switch_to_section (get_section (buf, flags, NULL));
I am not sure how to fix this. I think it could be fixed by having a
version of build_constant_desc that puts the data in a specific
section while wrapping up global variables in varasm. The above code
means that these front ends do not work (and maybe are not supposed to
work) with LTO. That is something that IMHO should be documented
somewhere.
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. :-)
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 comes from here:
/* Declare the name of the compilation unit as the first global
name in order to make the middle-end fully deterministic. */
t = create_concat_name (Defining_Entity (Unit (gnat_root)), NULL);
first_global_object_name = ggc_strdup (IDENTIFIER_POINTER (t));
Only the Ada front end has code like this. The other front ends set
first_global_object_name via notice_global_symbol (which is called
from varpool_finalize_decl and a few other places). It seems like a
good idea to me, to make first_global_object_name deterministic.
Perhaps it should be set to the top level translation unit by all
front ends? That would also simplify notice_global_symbol and prevent
it from accessing/creating DECL_RTL early.
user_label_prefix:
c-family/c-cppbuiltin.c: builtin_define_with_value
("__USER_LABEL_PREFIX__", user_label_prefix, 0);
Because user_label_prefix is defined in toplev.c, I think its global
decl should be moved from output.h to toplev.h.
asm_out_file for ASM_OUTPUT_IDENT:
c-family/c-lex.c:#include "output.h" /* for asm_out_file */
c-family/c-lex.c: ASM_OUTPUT_IDENT (asm_out_file, (const char
*) cstr.text);
ada/gcc-interface/trans.c: (asm_out_file,
I am not sure how to fix this. Maybe also write this out via a version
of build_constant_desc that puts the data in a specific section (that
would be required for MIPS' version of ASM_OUTPUT_IDENT).
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-pch.c: fputc ('\n', asm_out_file);
c-family/c-pch.c: asm_file_startpos = ftell (asm_out_file);
c-family/c-pch.c: asm_file_end = ftell (asm_out_file);
c-family/c-pch.c: if (fseek (asm_out_file, asm_file_startpos, SEEK_SET) != 0)
c-family/c-pch.c: if (fread (buf, size, 1, asm_out_file) != 1)
c-family/c-pch.c: if (fseek (asm_out_file, 0, SEEK_END) != 0)
c-family/c-pch.c: || fwrite (buf, size, 1, asm_out_file) != 1)
c-family/c-pch.c:asm_out_file. */
I do not understand this at all. In what way does PCH have anything to
do with writing out to asm_out_file?!
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-runtime-abi-01.c: ASM_DECLARE_CLASS_REFERENCE
(asm_out_file, buf);
This seems to imply that LTO doesn't work with LTO. The functions that
use asm_out_file are handle_next_class_ref and handle_next_impent,
which both only output something for darwin, and are only called via
called from objc_generate_v1_next_metadata for ABI v1. This code is
probably not tested very well, because this is for the 32-bits
ObjC-v2.0 ABI on Darwin, whereas the default 32-bits ABI is ObjC-v1.0
The code that invokes these functions is this:
/* Dump the class references. This forces the appropriate classes
to be linked into the exe
Re: [RFH] Uses of output.h in the front ends
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-pch.c: fputc ('\n', asm_out_file);
> c-family/c-pch.c: asm_file_startpos = ftell (asm_out_file);
> c-family/c-pch.c: asm_file_end = ftell (asm_out_file);
> c-family/c-pch.c: if (fseek (asm_out_file, asm_file_startpos, SEEK_SET) != 0)
> c-family/c-pch.c: if (fread (buf, size, 1, asm_out_file) != 1)
> c-family/c-pch.c: if (fseek (asm_out_file, 0, SEEK_END) != 0)
> c-family/c-pch.c: || fwrite (buf, size, 1, asm_out_file) != 1)
> c-family/c-pch.c: asm_out_file. */
>
> I do not understand this at all. In what way does PCH have anything to
> do with writing out to asm_out_file?!
FWIW, the following patchlet passes bootstrap and testing of pch.exp:
Index: c-pch.c
===
--- c-pch.c (revision 188177)
+++ c-pch.c (working copy)
@@ -188,6 +188,7 @@ c_common_write_pch (void)
asm_file_end = ftell (asm_out_file);
h.asm_size = asm_file_end - asm_file_startpos;
+ gcc_assert (! h.asm_size);
if (fwrite (&h, sizeof (h), 1, pch_outfile) != 1)
fatal_error ("can%'t write %s: %m", pch_file);
Could it be that this is just a relic of the pre-unit-at-a-time days?
Ciao!
Steven
Re: [RFH] Uses of output.h in the front ends
> "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> version of build_constant_desc that puts the data in a specific Steven> section while wrapping up global variables in varasm. In this particular case I'm not sure why switch_to_section is needed. The code is also setting DECL_SECTION_NAME -- is that not enough? It seems to be enough elsewhere in the same file ... see emit_register_classes_in_jcr_section further down. Tom
Re: [RFH] Uses of output.h in the front ends
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, especially for Ada and ObjC and someone knowledgeable of
> PCH, to enforce a rule that a front end must not #include output.h.
>
> A part of the compiler that writes to the assembler output has to
> include output.h or use one of the functions prototyped there.
> Therefore I have tried to remove #includes of output.h last week. I am
> stuck on 9 files that still have to include output.h for the following
> symbols:
>
> 1. assemble_string
> 2. get_section
> 3. switch_to_section
> 4. have_global_bss_p
> 5. first_global_object_name
> 6. asm_out_file
>
> The uses of these symbols are in the following files:
>
> assemble_string / get_section / switch_to_section:
> go/go-backend.c: assemble_string (bytes, size);
> go/go-backend.c: sec = get_section (GO_EXPORT_SECTION_NAME,
> SECTION_DEBUG, NULL);
> go/go-backend.c: switch_to_section (sec);
> java/class.c: switch_to_section (get_section (buf, flags, NULL));
> java/class.c: switch_to_section (get_section (buf, flags, NULL));
>
> I am not sure how to fix this. I think it could be fixed by having a
> version of build_constant_desc that puts the data in a specific
> section while wrapping up global variables in varasm. The above code
> means that these front ends do not work (and maybe are not supposed to
> work) with LTO. That is something that IMHO should be documented
> somewhere.
Don't we have attribute((section("..."))) anyways, so a mechanism for this
already?
>
> 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 in varpool_finalize_decl?
> 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 comes from here:
>
> /* Declare the name of the compilation unit as the first global
> name in order to make the middle-end fully deterministic. */
> t = create_concat_name (Defining_Entity (Unit (gnat_root)), NULL);
> first_global_object_name = ggc_strdup (IDENTIFIER_POINTER (t));
>
> Only the Ada front end has code like this. The other front ends set
> first_global_object_name via notice_global_symbol (which is called
> from varpool_finalize_decl and a few other places). It seems like a
> good idea to me, to make first_global_object_name deterministic.
> Perhaps it should be set to the top level translation unit by all
> front ends? That would also simplify notice_global_symbol and prevent
> it from accessing/creating DECL_RTL early.
>
>
> user_label_prefix:
> c-family/c-cppbuiltin.c: builtin_define_with_value
> ("__USER_LABEL_PREFIX__", user_label_prefix, 0);
>
> Because user_label_prefix is defined in toplev.c, I think its global
> decl should be moved from output.h to toplev.h.
Sounds reasonable.
>
> asm_out_file for ASM_OUTPUT_IDENT:
> c-family/c-lex.c:#include "output.h" /* for asm_out_file */
> c-family/c-lex.c: ASM_OUTPUT_IDENT (asm_out_file, (const char
> *) cstr.text);
> ada/gcc-interface/trans.c: (asm_out_file,
>
> I am not sure how to fix this. Maybe also write this out via a version
> of build_constant_desc that puts the data in a specific section (that
> would be required for MIPS' version of ASM_OUTPUT_IDENT).
Hm. The docs for -fno-ident say
@item -fno-ident
@opindex fno-ident
Ignore the @samp{#ident} directive.
And the CPP docs:
@findex #ident
@findex #sccs
The @samp{#ident} directive takes one argument, a string constant. On
some systems, that string constant is copied into a special segment of
the object file. On other systems, the directive is ignored. The
@samp{#sccs} directive is a synonym for @samp{#ident}.
I suppose make ASM_OUTPUT_IDENT a target hook instead.
Richard.
>
> a@item -fno-ident
@opindex fno-ident
Ignore the @samp{#ident} directive.
sm_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-pch.c: fputc ('\n', asm_out_file);
> c-family/c-pch.c: asm_file_startpos = ftell (asm_out_file);
> c-family/c-pch.c: asm_file_end = ftell (asm_out_file);
> c-family/c-pch.c: if (fseek (asm_out_file, asm_file_startpos, SEEK_SET) != 0)
> c-family/c-pch.c: if (fread (buf, size, 1, asm_out_file) != 1)
> c-family/c-pch.c: if (fseek (asm_out_file, 0, SEEK_END) != 0)
> c-family/c-pch.c: || fwrite (buf, size, 1, asm_out_file) != 1)
> c-family/c-pch.c: asm_out_f
Re: [RFH] Uses of output.h in the front ends
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 in varpool_finalize_decl? I thought so, too, but if you look at the code, then there are comments explaining what these uses of have_global_bss_p are for. The case in g++ depends on flag_conserve_space and that is a c-family specific flag. This is the only use, btw. Here's the code: /* Tell the back end to use or not use .common as appropriate. If we say -fconserve-space, we want this to save .data space, at the expense of wrong semantics. If we say -fno-conserve-space, we want this to produce errors about redefs; to do this we force variables into the data segment. */ if (flag_conserve_space && TREE_CODE (decl) == VAR_DECL && TREE_PUBLIC (decl) && !DECL_THREAD_LOCAL_P (decl) && !have_global_bss_p ()) DECL_COMMON (decl) = 1; Note the "at the expense of wrong semantics", egad! The -fconserve-space flag was introduced at r11952 by mrs. That revision was done on May 7, 1996, with commit comment: "86th Cygnus<->FSF quick merge". There is one test cases for this flag in testsuite/: g++.old-deja/g++.brendan/array1.C: Jason, is this flag something that we could deprecate for GCC 4.7 and remove? 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 increasing the size of the executable. */ if (!flag_no_common && TREE_CODE (var_decl) == VAR_DECL && TREE_PUBLIC (var_decl) && !have_global_bss_p ()) DECL_COMMON (var_decl) = 1; That does look like premature optimization to me, but I don't really understand the comment, or the effect of this code. Eric, could you please have a look at this and help me out? Ciao! Steven
Re: [RFH] Uses of output.h in the front ends
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 welcome. :-)
>>
>> Looks like premature optimization to me, better done in
>> varpool_finalize_decl?
>
> I thought so, too, but if you look at the code, then there are
> comments explaining what these uses of have_global_bss_p are for.
>
>
> The case in g++ depends on flag_conserve_space and that is a c-family
> specific flag. This is the only use, btw. Here's the code:
>
> /* Tell the back end to use or not use .common as appropriate. If we say
> -fconserve-space, we want this to save .data space, at the expense of
> wrong semantics. If we say -fno-conserve-space, we want this to
> produce errors about redefs; to do this we force variables into the
> data segment. */
> if (flag_conserve_space
> && TREE_CODE (decl) == VAR_DECL
> && TREE_PUBLIC (decl)
> && !DECL_THREAD_LOCAL_P (decl)
> && !have_global_bss_p ())
> DECL_COMMON (decl) = 1;
>
> Note the "at the expense of wrong semantics", egad! The
> -fconserve-space flag was introduced at r11952 by mrs. That revision
> was done on May 7, 1996, with commit comment: "86th Cygnus<->FSF quick
> merge". There is one test cases for this flag in testsuite/:
> g++.old-deja/g++.brendan/array1.C:
>
> 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.
> 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 increasing the size of the executable. */
> if (!flag_no_common
> && TREE_CODE (var_decl) == VAR_DECL
> && TREE_PUBLIC (var_decl)
> && !have_global_bss_p ())
> DECL_COMMON (var_decl) = 1;
>
> That does look like premature optimization to me, but I don't really
> understand the comment, or the effect of this code. Eric, could you
> please have a look at this and help me out?
I suppose in any case have_global_bss_p () should be a target-hook
and/or moved to target.h. And indeed it's implementation is
/* Return true if the target supports some form of global BSS,
either through bss_noswitch_section, or by selecting a BSS
section in TARGET_ASM_SELECT_SECTION. */
bool
have_global_bss_p (void)
{
return bss_noswitch_section || targetm.have_switchable_bss_sections;
}
OTOH, I suppose including target.h from the FEs is against what you
want to achieve, too.
Richard.
> Ciao!
> Steven
Re: [RFH] Uses of output.h in the front ends
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 that targetm will be split up in front end and middle/back end specific parts. Ciao! Steven
Re: [RFH] Uses of output.h in the front ends
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 comes from here:
>>
>> /* Declare the name of the compilation unit as the first global
>> name in order to make the middle-end fully deterministic. */
>> t = create_concat_name (Defining_Entity (Unit (gnat_root)), NULL);
>> first_global_object_name = ggc_strdup (IDENTIFIER_POINTER (t));
>>
>> Only the Ada front end has code like this. The other front ends set
>> first_global_object_name via notice_global_symbol (which is called
>> from varpool_finalize_decl and a few other places). It seems like a
>> good idea to me, to make first_global_object_name deterministic.
>> Perhaps it should be set to the top level translation unit by all
>> front ends? That would also simplify notice_global_symbol and prevent
>> it from accessing/creating DECL_RTL early.
>>
>>
>> user_label_prefix:
>> c-family/c-cppbuiltin.c: builtin_define_with_value
>> ("__USER_LABEL_PREFIX__", user_label_prefix, 0);
>>
>> Because user_label_prefix is defined in toplev.c, I think its global
>> decl should be moved from output.h to toplev.h.
>
> Sounds reasonable.
>
>>
>> asm_out_file for ASM_OUTPUT_IDENT:
>> c-family/c-lex.c:#include "output.h" /* for asm_out_file */
>> c-family/c-lex.c: ASM_OUTPUT_IDENT (asm_out_file, (const char
>> *) cstr.text);
>> ada/gcc-interface/trans.c: (asm_out_file,
>>
>> I am not sure how to fix this. Maybe also write this out via a version
>> of build_constant_desc that puts the data in a specific section (that
>> would be required for MIPS' version of ASM_OUTPUT_IDENT).
>
> Hm. The docs for -fno-ident say
>
> @item -fno-ident
> @opindex fno-ident
> Ignore the @samp{#ident} directive.
>
> And the CPP docs:
>
> @findex #ident
> @findex #sccs
> The @samp{#ident} directive takes one argument, a string constant. On
> some systems, that string constant is copied into a special segment of
> the object file. On other systems, the directive is ignored. The
> @samp{#sccs} directive is a synonym for @samp{#ident}.
>
> 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.
Ciao!
Steven
Re: [RFH] Uses of output.h in the front ends
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_PRIVATE_NAME (label,
>>> first_global_object_name, 0);
>>>
>>> This comes from here:
>>>
>>> /* Declare the name of the compilation unit as the first global
>>> name in order to make the middle-end fully deterministic. */
>>> t = create_concat_name (Defining_Entity (Unit (gnat_root)), NULL);
>>> first_global_object_name = ggc_strdup (IDENTIFIER_POINTER (t));
>>>
>>> Only the Ada front end has code like this. The other front ends set
>>> first_global_object_name via notice_global_symbol (which is called
>>> from varpool_finalize_decl and a few other places). It seems like a
>>> good idea to me, to make first_global_object_name deterministic.
>>> Perhaps it should be set to the top level translation unit by all
>>> front ends? That would also simplify notice_global_symbol and prevent
>>> it from accessing/creating DECL_RTL early.
>>>
>>>
>>> user_label_prefix:
>>> c-family/c-cppbuiltin.c: builtin_define_with_value
>>> ("__USER_LABEL_PREFIX__", user_label_prefix, 0);
>>>
>>> Because user_label_prefix is defined in toplev.c, I think its global
>>> decl should be moved from output.h to toplev.h.
>>
>> Sounds reasonable.
>>
>>>
>>> asm_out_file for ASM_OUTPUT_IDENT:
>>> c-family/c-lex.c:#include "output.h" /* for asm_out_file */
>>> c-family/c-lex.c: ASM_OUTPUT_IDENT (asm_out_file, (const char
>>> *) cstr.text);
>>> ada/gcc-interface/trans.c: (asm_out_file,
>>>
>>> I am not sure how to fix this. Maybe also write this out via a version
>>> of build_constant_desc that puts the data in a specific section (that
>>> would be required for MIPS' version of ASM_OUTPUT_IDENT).
>>
>> Hm. The docs for -fno-ident say
>>
>> @item -fno-ident
>> @opindex fno-ident
>> Ignore the @samp{#ident} directive.
>>
>> And the CPP docs:
>>
>> @findex #ident
>> @findex #sccs
>> The @samp{#ident} directive takes one argument, a string constant. On
>> some systems, that string constant is copied into a special segment of
>> the object file. On other systems, the directive is ignored. The
>> @samp{#sccs} directive is a synonym for @samp{#ident}.
>>
>> 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.
I mean make the whole "write #ident" a target hook.
Richard.
> Ciao!
> Steven
Re: [RFH] Uses of output.h in the front ends
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_POINTER (t));
ada/gcc-interface/utils.c: ASM_FORMAT_PRIVATE_NAME (label,
first_global_object_name, 0);
This comes from here:
/* Declare the name of the compilation unit as the first global
name in order to make the middle-end fully deterministic. */
t = create_concat_name (Defining_Entity (Unit (gnat_root)), NULL);
first_global_object_name = ggc_strdup (IDENTIFIER_POINTER (t));
Only the Ada front end has code like this. The other front ends set
first_global_object_name via notice_global_symbol (which is called
from varpool_finalize_decl and a few other places). It seems like a
good idea to me, to make first_global_object_name deterministic.
Perhaps it should be set to the top level translation unit by all
front ends? That would also simplify notice_global_symbol and prevent
it from accessing/creating DECL_RTL early.
user_label_prefix:
c-family/c-cppbuiltin.c: builtin_define_with_value
("__USER_LABEL_PREFIX__", user_label_prefix, 0);
Because user_label_prefix is defined in toplev.c, I think its global
decl should be moved from output.h to toplev.h.
>>>
>>> Sounds reasonable.
>>>
asm_out_file for ASM_OUTPUT_IDENT:
c-family/c-lex.c:#include "output.h" /* for asm_out_file */
c-family/c-lex.c: ASM_OUTPUT_IDENT (asm_out_file, (const char
*) cstr.text);
ada/gcc-interface/trans.c: (asm_out_file,
I am not sure how to fix this. Maybe also write this out via a version
of build_constant_desc that puts the data in a specific section (that
would be required for MIPS' version of ASM_OUTPUT_IDENT).
>>>
>>> Hm. The docs for -fno-ident say
>>>
>>> @item -fno-ident
>>> @opindex fno-ident
>>> Ignore the @samp{#ident} directive.
>>>
>>> And the CPP docs:
>>>
>>> @findex #ident
>>> @findex #sccs
>>> The @samp{#ident} directive takes one argument, a string constant. On
>>> some systems, that string constant is copied into a special segment of
>>> the object file. On other systems, the directive is ignored. The
>>> @samp{#sccs} directive is a synonym for @samp{#ident}.
>>>
>>> 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.
>
> I mean make the whole "write #ident" a target hook.
Another possibility would be to generate a toplevel asm at this point ...
Richard.
Re: [RFH] Uses of output.h in the front ends
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.
>
> I mean make the whole "write #ident" a target hook.
>
> Richard.
I think I understand what you mean. But consider the following two:
static void
cb_ident (cpp_reader * ARG_UNUSED (pfile),
unsigned int ARG_UNUSED (line),
const cpp_string * ARG_UNUSED (str))
{
#ifdef ASM_OUTPUT_IDENT
if (!flag_no_ident)
{
/* Convert escapes in the string. */
cpp_string cstr = { 0, 0 };
if (cpp_interpret_string (pfile, str, 1, &cstr, CPP_STRING))
{
ASM_OUTPUT_IDENT (asm_out_file, (const char *) cstr.text);
free (CONST_CAST (unsigned char *, cstr.text));
}
}
#endif
}
vs.
static void
cb_ident (cpp_reader * ARG_UNUSED (pfile),
unsigned int ARG_UNUSED (line),
const cpp_string * ARG_UNUSED (str))
{
if (targetm.asm_out.ident)
{
/* Convert escapes in the string. */
cpp_string cstr = { 0, 0 };
if (cpp_interpret_string (pfile, str, 1, &cstr, CPP_STRING))
{
targetm.asm_out.ident ((const char *) cstr.text);
free (CONST_CAST (unsigned char *, cstr.text));
}
}
}
where targetm.asm_out.ident writes to asm_out_file.
This change would allow one to remove #include output.h from
c-family/c-lex.c, but the front end will still be writing to
asm_out_file, indirectly through the target hook. So making
ASM_OUTPUT_IDENT a target hook solves part of the problem (remove
#include output.h) but doesn't solve the bigger problem (try to avoid
writing to asm_out_file from front ends).
Ciao!
Steven
Re: [RFH] Uses of output.h in the front ends
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 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. 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? Cheers, Manuel.
Re: [RFH] Uses of output.h in the front ends
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
Re: [RFH] Uses of output.h in the front ends
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. > > 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? I'm not sure this would work. Say you have a target that defines cpu models (see e.g. ix86_target_macros) and you're parsing a file that depend on those defines. You're going to have to export those those cpu model defines to make parsing work. I think this can only be done with call-backs from the front end to a back-end target hook. But I haven't look at how e.g. clang handles such things, maybe there's another, better way. Ciao! Steven
Re: MIPS: 2'nd pass of ira, causes weird register allocation for 2-op mult
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 some point to > make this legacy code take processor-specific costs into account, but... At least on my target, moving to and from LO/HI is really cheap. If gcc can avoid using mult and div when LO/HI is used a scratch - I am fine with that. But the real reason I say "sane" is that otherwise it is really difficult to convince gcc to use 2-op madd's instead of the 3-op version. Potentially 2-op madd should have a big benefit over 3-op version as it allow the madd to run in the background until you need the result. I suspect ACC_REG cost is the reason this loop: int i; long long acc = 0; for (i=0; i<16; i++) acc += (long long)*a++ * *b++; return acc; doesn't take take advantage of the fact that LO/HI is alive: addiu $8,$4,64 # D.1481, a, move$7,$0# acc, move$6,$0# acc, .L2: lw $3,0($4) # D.1443, MEM[base: a_25, offset: 0B] lw $2,0($5) # D.1445, MEM[base: b_26, offset: 0B] mtlo$7 # acc addiu $4,$4,4 # a, a, addiu $5,$5,4 # b, b, mthi$6 # acc madd$3,$2# D.1443, D.1445 mflo$7 # acc bne $4,$8,.L2#, a, D.1481, mfhi$6 # acc move$2,$6#, acc j $31 mflo$3 # tmp2 But for some reason the unrolled version works fine: long long acc = 0; acc += (long long)*a++ * *b++; acc += (long long)*a++ * *b++; acc += (long long)*a++ * *b++; acc += (long long)*a++ * *b++; return acc; This translates to: lw $6,4($5) # D.1416, MEM[(const int *)b_5(D) + 4B] lw $7,4($4) # D.1414, MEM[(const int *)a_2(D) + 4B] lw $3,0($4) # D.1414, *a_2(D) lw $2,0($5) # D.1416, *b_5(D) mult$7,$6# D.1414, D.1416 lw $8,8($4) # D.1414, MEM[(const int *)a_2(D) + 8B] madd$3,$2# D.1414, D.1416 lw $2,8($5) # D.1416, MEM[(const int *)b_5(D) + 8B] lw $3,12($4)# D.1414, MEM[(const int *)a_2(D) + 12B] madd$8,$2# D.1414, D.1416 lw $2,12($5)# D.1416, MEM[(const int *)b_5(D) + 12B] madd$3,$2# D.1414, D.1416 mfhi$6 # move$2,$6#, j $31 mflo$3 # tmp2 (This is beautiful! Check the interleaved load...) > >> --- gcc-4.7-20120526-orig/gcc/config/mips/mips.c 2012-06-03 >> 19:28:02.137960837 +0800 >> +++ gcc-4.7-20120526/gcc/config/mips/mips.c 2012-06-03 19:31:12.587399458 >> +0800 [...] > ...this says that it is better to use LO as scratch space than spilling > to memory -- and better by some margin -- which often isn't the case. By a margin? - I can not imagine when spilling is cheaper than using internal regs. Spilling to memory, require a stack frame and save and restore of regs. Say I have 300MHz cpu, 100MHz 16bit RAM, 3 clk to first data, 32 byte cache line. So depending on the cache configuration, the cpu might have to first read the cache line, before the write buffer can go there. 20 cycles at 100MHz or 60 cpu cycles before the spilled value can be read back. > > As Vlad says, the behaviour you're seeing with the second pass isn't > deliberate. I am happy to test patches. BR, Klaus
Re: OPTION_DEFAULT_SPECS question
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 want to know is that if I build GCC for MIPS
> > today and configure with --with-synci then some tests fail because
> > the test specifies an old MIPS architecture that doesn't support synci
> > and the test prints a warning:
> >
> > if (TARGET_SYNCI && !ISA_HAS_SYNCI)
> >{
> > warning (0, "the %qs architecture does not support the synci "
> > "instruction", mips_arch_info->name);
> > target_flags &= ~MASK_SYNCI;
> >}
> >
> > Ideally, this warning should only be printed if the user explicitly asked
> > for -msynci, not if -msynci was merely set as the default. But I am not
> > sure
> > how to tell the difference between those two situations.
>
> I think you want to examine target_flags_explicit.
>
> - David
That looks like what I want but when I try to use it, it doesn't seem to
work. I put 'if ((target_flags_explicit & MASK_SYNCI) != 0)' in front
of the warning but I still get the warning if I configure GCC with
'--with-synci' regardless of whether or not I explicitly use -msynci on
the GCC command line. When I look at the value of
target_flags_explicit, the MASK_SYNCI bit always seems to be on,
regardless of whether or not I configured GCC with '--with-synci'
and only the value in target_flags seems to be changing to reflect
whether or not to use synci. Perhaps my understanding of
target_flags_explicit is wrong but I assumed it would set bits for
whatever flags are on in target_flags but only if they were set
explicitly by the user.
Steve Ellcey
sell...@mips.com
Re: [RFH] Uses of output.h in the front ends
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
Re: [RFH] Uses of output.h in the front ends
> 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 increasing the size of the executable. */ > if (!flag_no_common > && TREE_CODE (var_decl) == VAR_DECL > && TREE_PUBLIC (var_decl) > && !have_global_bss_p ()) > DECL_COMMON (var_decl) = 1; > > That does look like premature optimization to me, but I don't really > understand the comment, or the effect of this code. Eric, could you > please have a look at this and help me out? Sure, but I don't understand what you don't understand... the comment seems clear enough to me: DECL_COMMON is needed on some platforms if you don't want uninitialized variables to go in DATA. -- Eric Botcazou
Re: [RFH] Uses of output.h in the front ends
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 global variables would >> go in DATA instead, thus increasing the size of the executable. */ >> if (!flag_no_common >> && TREE_CODE (var_decl) == VAR_DECL >> && TREE_PUBLIC (var_decl) >> && !have_global_bss_p ()) >> DECL_COMMON (var_decl) = 1; >> >> That does look like premature optimization to me, but I don't really >> understand the comment, or the effect of this code. Eric, could you >> please have a look at this and help me out? > > Sure, but I don't understand what you don't understand... the comment seems > clear enough to me: DECL_COMMON is needed on some platforms if you don't want > uninitialized variables to go in DATA. 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://gcc.gnu.org/ml/gcc-patches/2004-12/msg00550.html) and because you obviously have much better understanding of GNAT and of how this kind of low-level thing works in GCC than I do. If this should continue to be supported: For the corresponding option for G++ (-fconserve-space) the documentation says that the flag isn't very useful anymore because: "This option is no longer useful on most targets, now that support has been added for putting variables into BSS without making them common." What I don't understand, is what this means for GNAT. (Remember, I help build aircraft for a living, not compilers! I can barely distinguish .bss from .data, and don't understand at all where/how GCC decides to put variables in one section or another :-D) I was hoping maybe you know how to rewrite that piece of code such that you get that uninitialized variable into BSS without DECL_COMMON. Or maybe you can tell if this code is no longer needed, so I can prepare a patch to remove it. Hope you can help, Ciao! Steven
Re: [RFH] Uses of output.h in the front ends
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://gcc.gnu.org/ml/gcc-patches/2004-12/msg00550.html) and because > you obviously have much better understanding of GNAT and of how this > kind of low-level thing works in GCC than I do. > > If this should continue to be supported: > For the corresponding option for G++ (-fconserve-space) the > documentation says that the flag isn't very useful anymore because: > "This option is no longer useful on most targets, now that support has > been added for putting variables into BSS without making them common." > What I don't understand, is what this means for GNAT. (Remember, I > help build aircraft for a living, not compilers! I can barely > distinguish .bss from .data, and don't understand at all where/how GCC > decides to put variables in one section or another :-D) I was hoping > maybe you know how to rewrite that piece of code such that you get > that uninitialized variable into BSS without DECL_COMMON. > > Or maybe you can tell if this code is no longer needed, so I can > prepare a patch to remove it. Is this feature necessary for non-ELF file formats, such as AIX XCOFF? - David
Re: [RFH] Uses of output.h in the front ends
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
Re: [RFH] Uses of output.h in the front ends
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 of the people who worked on this >> so-many-years ago >> (http://gcc.gnu.org/ml/gcc-patches/2004-12/msg00550.html) and because >> you obviously have much better understanding of GNAT and of how this >> kind of low-level thing works in GCC than I do. >> >> If this should continue to be supported: >> For the corresponding option for G++ (-fconserve-space) the >> documentation says that the flag isn't very useful anymore because: >> "This option is no longer useful on most targets, now that support has >> been added for putting variables into BSS without making them common." >> What I don't understand, is what this means for GNAT. (Remember, I >> help build aircraft for a living, not compilers! I can barely >> distinguish .bss from .data, and don't understand at all where/how GCC >> decides to put variables in one section or another :-D) I was hoping >> maybe you know how to rewrite that piece of code such that you get >> that uninitialized variable into BSS without DECL_COMMON. >> >> Or maybe you can tell if this code is no longer needed, so I can >> prepare a patch to remove it. > > Is this feature necessary for non-ELF file formats, such as AIX XCOFF? Maybe. But none of the other front ends seem to need this to put uninitialized variables in a.bss-like section. Ciao! Steven
Re: [RFH] Uses of output.h in the front ends
> 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 executable if they are uninitialized (in Ada, uninitialized objects at the global level are not zeroed, unlike in C/C++). > For the corresponding option for G++ (-fconserve-space) the > documentation says that the flag isn't very useful anymore because: > "This option is no longer useful on most targets, now that support has > been added for putting variables into BSS without making them common." This looks equivalent to saying "most targets have_global_bss_p" to me. So the problem boils down to finding the remaining targets (if any) and determining if they still matter nowadays. > I was hoping maybe you know how to rewrite that piece of code such that you > get that uninitialized variable into BSS without DECL_COMMON. This is probably low-level trickery on exotic platforms so I'm not sure I want to start this kind of endeavor. -- Eric Botcazou
Re: [RFH] Uses of output.h in the front ends
> 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
Re: [RFH] Uses of output.h in the front ends
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
Re: [RFH] Uses of output.h in the front ends
> Hmm, Mach-O does have BSS. OK, bad memory, this was for Tru64. -- Eric Botcazou
Re: [RFH] Uses of output.h in the front ends
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 means that Tru64 also has BSS (http://h30097.www3.hp.com/docs/base_doc/DOCUMENTATION/V50A_ACRO_SUP/OBJSPEC.PDF). Did GCC support that for Tru64 too? Is there a test case, so that I can see what GCC 4.7 for Tru64 does with it, without and with this code in utils.c? Ciao! Steven
Re: [RFH] Uses of output.h in the front ends
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 BSS_SECTION_ASM_OP
If defined, a C expression whose value is a string, including spacing,
containing the assembler operation to identify the following data as
uninitialized global data. If not defined, and
@code{ASM_OUTPUT_ALIGNED_BSS} not defined,
uninitialized global data will be output in the data section if
@option{-fno-common} is passed, otherwise @code{ASM_OUTPUT_COMMON} will be
used.
@end defmac
The definition of have_global_bss_p() is this:
The following targets have no re-definition of BSS_SECTION_ASM_OP and
no definition of ASM_OUTPUT_ALIGNED_BSS
-bfin
-cris
-iq2000
-mcore
-mips
-mmix
-moxie
-pdp11
-vax
The following of those targets seem to inherit
TARGET_HAVE_SWITCHABLE_BSS_SECTIONS from config/elfos.h:
-bfin (elf only)
-cris (for cris-*-elf only)
-iq2000 (elf only)
-mcore (elf only)
-mips (seems to be elf only, too?!)
-moxie (elf only)
That leaves pdp11, vax, and non-ELF cris as the only targets without
.bss support. AFAICT, that is :-)
Eric, do you remember a test case that was the reason for the patch
that added this to utils.c? I would like to play with it, and see if I
can understand why apparently the data didn't end up in a .bss
section.
Ciao1
Steven
Re: How to avoid sign or zero extension
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.
>
> For example, imagine if I use clz instructions (count leading zeros). Result
> of the function will be positive number between 0 and 32. So, in places where
> result of that clz functions is assigned to a short int it shouldn't
> sign-extend the result.
>
> I use inline asm, and it works with arm's armcc if I use short as a result of
> inline asm expression:
>
> static __inline short CLZ(int n)
> {
> short ret;
> #ifdef __GNUC__
> __asm__("clz %0, %1" : "=r"(ret) : "r"(n));
> #else
> __asm { clz ret, n; }
> #endif
> return ret;
> }
>
> //test function
> short test_clz(int n)
> {
> return CLZ(n);
> }
>
>
> ARMCC generates this code:
> test_clz:
> CLZ r0,r0
> BX lr
>
> GCC generates this code:
> test_clz:
> clz r0, r0
> sxth r0, r0 <--- offending line.
> bx lr
Hi there. This list is about the development of GCC. I recommend
using the gcc-help list for end user topics.
In this case, GCC is correct. Section 5.4 of the ARM AAPCS says "A
Fundamental Data Type that is smaller than 4 bytes is zero- or
sign-extended to a word and returned in r0". You've used inline
assembler so GCC can't tell that the clz instruction already clears
the top bits.
How about using __builtin_clz() instead? You get the bonus that GCC
can then reason about the function and optimise away if possible.
-- Michael
Re: [RFH] Uses of output.h in the front ends
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. Jason
Re: Distributing 'make check' across a cluster
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 during the testsuite setup). Thanks. C, C++, Fortran, Obj-C and Obj-C++ testing have been known to work in the past for installed testing. Java, Ada and Go are quite likely to have problems; I don't think I've tried installed testing for libmudflap, libffi, libitm, libatomic (but it should work for libgomp). Both libmudflap and libgomp are currently giving me grief because they need mfconfig.exp and gompconfig.exp. Both of which are generated at build-time, so I don't have them around. They mostly set GCC_UNDER_TEST and a couple other things, so I'll just generate them in my scripts. Diego.
Re: [RFH] Uses of output.h in the front ends
> ... 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 GCC support that for Tru64 too? Sure, it has BSS since the point of the change was to put variables there. The problem was how to tell the assembler to put it there. > Is there a test case, so that I can see what GCC 4.7 for Tru64 does > with it, without and with this code in utils.c? Put this in a p.ads file: package P is Bigarray : array (1..1024*1024*256) of Character; end P; -- Eric Botcazou
