Re: Call for testers: MPC-0.6 released
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Built with disable-shared: - - i686-pc-mingw32 gcc-4.4.0 gmp-4.2.4 mpfr-2.4.1 ok - - i686-pc-cygwin gcc-4.4.0 gmp-4.2.4 mpfr-2.4.1 ok Rainer -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknZwpoACgkQoUhjsh59BL4J4wCglgAtv2l+mBhZHGDWIc+ymOhl aeMAoIAKGzb37aOb0mXsa8mLkZifkH5z =/8BI -END PGP SIGNATURE-
Re: GCC + libJIT instead of LLVM
Basile STARYNKEVITCH wrote: I believe that Kiril mentioned in a separate post the equation (mcs | csc | cscc) & gcc & libJIT == LLVM ? I tend to believe that Kiril dreams of building a CLI/.NET infrastructure and VM which uses all the powerful optimisations of GCC. For reference to Kiril: do you know that there exist some branches of GCC (I believe it was contributed by STMicro guys) which are able to 1. Parse (as a front-end) the CLI bytecode and generate the Gimple IR from it 2. Parse C# (as a front-end) and generate the Gimple IR from it 3. Provide a backend which spills CLI bytecode from Gimple IR (without using the backend infrastructure of GCC, but "replacing" it). Maybe these branches could satisfy some of Kiril dreams (which I still did not understood exactly). the CLI BE/FE branch (http://gcc.gnu.org/projects/cli.html) has seen little progress lately mostly because we have been 'redirected' to another project but we're still trying to push it forward and we have recently applied a few patches that make it quite usable for compiling C code and running the resulting CLI binaries under Mono. We support emitting CLI from GIMPLE and using CLI as a source language (though the front-end hasn't been tested for a while now unfortunately). We haven't written a C# front-end though, but maybe somebody else tried. That would end up as something very different from what we've been doing in the CLI branch (i.e. something more like gcj).
Re: Minimum required GNAT version for bootstrap of GNAT on gcc trunk
To add to this data: on i686-mingw the system gcc-3.4.5-20060117-3 is able to bootstrap SVN 4.4 with --enable-languages=c,ada the resulting compiler is able to compile simple Ada programs and ACATS is currently running (I can't test C because I don't have dejagnu - advice welcomed). Current trunk fails to bootstrap but this is with C only so the issue is not Ada related. Sincerely, Laurent On Fri, 2009-03-06 at 19:46 +0100, Laurent GUERBY wrote: > On Thu, 2009-03-05 at 18:24 +0100, Laurent GUERBY wrote: > > On Tue, 2009-02-24 at 20:40 +0100, Laurent GUERBY wrote: > > > On Tue, 2009-02-24 at 19:36 +, Dave Korn wrote: > > > > Laurent GUERBY wrote: > > > > > On Tue, 2009-02-24 at 18:59 +, Dave Korn wrote: > > > > >> Laurent GUERBY wrote: > > > > >> > > > > >>> I'm not sure 3.4 will work for trunk > > > > >> I was just entirely unable to get 3.4.4 to bootstrap a 4.3.2 > > > > >> compiler. I > > > > >> used 4.3.0 and it worked. I forget what I used to build the 4.3.0 > > > > >> with in the > > > > >> first place. I think the documentation needs updating to say you'll > > > > >> need to > > > > >> use an early/intermediate 4.x version to bootstrap your way past the > > > > >> 3.x/4.x > > > > >> boundary, but I couldn't say exactly where the break lies. > > > > > > > > > > Was this on cygwin or Linux? > > > > > > > > Cygwin. Would that be likely to make a difference? > > > > > > Depending on the error it could make a difference. The oldest > > > system I have access to is Ubuntu 5.10 which I believe > > > came with 4.0 GCC default and optional 3.4 GCC packages (the system is > > > offline right now so I rely on memory, I'll confirm > > > when it comes back online). > > > > The old system just came back online so I checked and GCC 3.4.6 (the > > oldest version I have, released Mar 06 2006) is able to bootstrap c,ada > > for 4.3.2 release (2008-08-27) on Linux i686. > > > > So at least 3.4.x is able to build 4.3.x with Ada enabled on Linux. > > > > I will build and test ability of 3.4.0 (released Apr 18 2004) to 5 to > > bootstrap 4.3.x in the coming weeks. > > On i686-linux for c,ada: > > 3.4.4 bootstraped 4.3.2 fine (your configuration) > 3.4.0 bootstraped 4.3.1 fine > 3.4.0 bootstraped trunk 143919 fine > > I'm not going to test more, a priori what the documentation > currently says for Ada is correct at least for i686-linux, > the minimum required GNAT version for bootstrap is 3.4.x. > > Sincerely, > > Laurent >
Re: Invalid reload inheritance with paradoxical subregs
On Thu, 2 Apr 2009, Uros Bizjak wrote:
> Combine simplifies lshiftrt/shift/and combined instruction under the
> assumption, that for ZERO_EXTEND LOAD_EXTEND_OP targets it can prove
> that certain bits are zero, so AND operation can be omitted. The
> resulting instruction is valid only for memory operand:
...
> (gdb) p debug_rtx (insn)
> (insn 121 120 125 2 t.c:22 (set (reg:SI 6 r6 [orig:48 y$k.115 ] [48])
> (lshiftrt:SI (subreg:SI (reg:HI 7 r7) 0)
> (const_int 5 [0x5]))) 62 {lshrsi3} (nil))
>
> This substitution is wrong. Paradoxical subreg of a memory operand is
> for our target known to zero extend to SImode value, however -
> paradoxical subreg of a register operand has undefined bits outside
> the reg. So, combine and reload doesn't agree on the bits outside the
> register.
Looks like the issue I attributed to IRA for
mmix-knuth-mmixware:
(no, not a great deal of analysis there, I'm afraid).
And again, I'd be perfectly fine with removing this weird
LOAD_EXTEND_OP-specific "feature". I'm of half a mind to remove
the #define from the MMIX port.
brgds, H-P
Re: GCC + libJIT instead of LLVM
David Edelsohn wrote: >> My explanations seem to have also failed to explain you. >> Unfortunately, one really needs have some back group with both >> Just-In-Time compilers,Virtual Machines, and Common Intermediate >> Language to understand this area. I understand that it is not your >> area of expertise, so it is not an issue for me. > > I think a JIT associated with GCC would be great. Not everything is > static compilation. "Split Compilation" combining static compilation > for complicated analysis along with a "Managed Runtime" for > execution and runtime transformations is becoming more important. I agree. I don't know how relevant libJIT might or might not be for this, but the basic idea of GCC generating deployable code which can be further optimized at run-time (presumably using some kind of JIT) is certainly a good one. I believe that's a usage model that will become increasingly important over time. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
[lto] Mainline merge @145453
Unsurprisingly, this merge was quite painful. Particularly adapting to all the new EH changes. The main changes I needed to do: - The master_clone field is gone from cgraph_node. Some things had to be handled differently when reading/writing cgraph nodes. - There was a bug when emitting/reading EH tables. We were not handling region aliases (the aka bitmap). EH regions are shared, so I added a new LTO_eh_shared_region marker to indicate that on the IL files. - When resetting the context on function arguments, we only need to reset it on functions that have a gimple body. With the new FE changes, the FE is generating different decls for the same function and depending on the order in which those FUNCTION_DECLs are processed, we were setting DECL_CONTEXT to the wrong function (PARM_DECLs are shared, so once set in one function, it is set in all of them). I fixed this to only reset DECL_CONTEXT on the FUNCTION_DECL that has a gimple body, since that's really the only one that matters. Bootstrapped and tested on x86_64. Mainline merge @145453. * configure.ac (acx_pkgversion): update revision merge string. * configure: regenerate. * Makefile.in (lto-cgraph.o): Add dependency on lto-utils.h. * cgraph.c (initialize_inline_failed): Check that E has a call (cgraph_is_master_clone): Remove. (cgraph_master_clone): Remove. * except.c (debug_eh_tree): New. * except.h (debug_eh_tree): Declare. * lto-function-in.c (input_bitmap): New. (input_eh_region): Handle LTO_eh_table_shared_region. Return a previously created EH region corresponding to the number read. (fixup_eh_region_pointers): Remove argument LAST_REGION. Change type of ROOT_REGION to HOST_WIDE_INT. Update all users. Handle shared and NULL regions. (input_eh_regions): Read size of EH region table before reading the array. (input_bb): Assert that CFUN is properly set. (input_node): Rename WROTE_MASTER_P to CLONE_P. (input_function): Look for the first clone in NODE's list of clones. * lto-cgraph.c (output_node): Rename WROTE_MASTER to WRITTEN_DECLS. (output_cgraph_verify_node): Remove. (output_cgraph): Rename WROTE_MASTER to WRITTEN_DECLS. * lto-function-out.c (output_bitmap): New. (output_eh_region): For shared regions, output the marker LTO_eh_table_shared_region and the region number of the shared region. (output_eh_regions): Output the AKA bitmap. If there is no EH region tree, output -1 to mark its absence. Call output_eh_region for every region, even NULL ones. (output_parm_decl): Only check DECL_CONTEXT of DECL if FN has a gimple body. * lto-tags.h (enum LTO_tags): Add LTO_eh_table_shared_region. * tree.c (free_lang_data_in_type): After building a qualified type for an argument type, call free_lang_data_in_type on the new type. (free_lang_data_in_decl): Only reset DECL_CONTEXT on FUNCTION_DECL arguments when the function has a gimple body. lto/ChangeLog * lto-lang.c (lto_post_options): Set flag_excess_precision_cmdline. * lto.c (read_cgraph_and_symbols): Set cgraph_function_flags_ready. (lto_add_all_inlinees): Tidy. --- Makefile.in (revision 144738) +++ Makefile.in (working copy) @@ -2084,7 +2084,7 @@ lto-cgraph.o: lto-cgraph.c $(CONFIG_H) $ tree-pass.h tree-flow.h $(CGRAPH_H) $(FUNCTION_H) $(GGC_H) $(DIAGNOSTIC_H) \ except.h debug.h $(TIMEVAR_H) $(LTO_TAGS_H) $(LTO_SECTION_IN_H) \ $(LTO_SECTION_OUT_H) output.h dwarf2asm.h dwarf2out.h pointer-set.h \ - $(LTO_TREE_IN_H) + $(LTO_TREE_IN_H) lto-utils.h lto-function-in.o: lto-function-in.c $(CONFIG_H) $(SYSTEM_H) coretypes.h \ $(TM_H) $(TOPLEV_H) $(EXPR_H) $(FLAGS_H) $(PARAMS_H) input.h $(VARRAY_H) \ $(HASHTAB_H) langhooks.h $(BASIC_BLOCK_H) tree-iterator.h tree-pass.h \ --- cgraph.c2009/04/03 11:46:06 1.3 +++ cgraph.c2009/04/04 02:04:43 @@ -666,7 +666,7 @@ initialize_inline_failed (struct cgraph_ e->inline_failed = CIF_REDEFINED_EXTERN_INLINE; else if (!callee->local.inlinable) e->inline_failed = CIF_FUNCTION_NOT_INLINABLE; - else if (gimple_call_cannot_inline_p (e->call_stmt)) + else if (e->call_stmt && gimple_call_cannot_inline_p (e->call_stmt)) e->inline_failed = CIF_MISMATCHED_ARGUMENTS; else e->inline_failed = CIF_FUNCTION_NOT_CONSIDERED; @@ -690,7 +690,7 @@ cgraph_create_edge (struct cgraph_node * hashtable. */ gcc_assert (!cgraph_edge (caller, call_stmt)); #endif - + gcc_assert (is_gimple_call (call_stmt)); } @@ -729,7 +729,6 @@ cgraph_create_edge (struct cgraph_node * edge->indirect_call = 0; edge->call_stmt_cannot_inline_p = (call_stmt ? gimple_call_cannot_inline_p (call_stmt) : false); - edge->uid =
Re: bitfields: types vs modes?
Ian Lance Taylor wrote: >> So... can I/we move forward on this? Or will such a change be >> rejected? > It's hard for me to get excited about something like this. It's > straightforward a programmer to write code that is clearly correct in > this sort of situation: just don't use a bitfield. In part, because of the ARM ABI issue, I think we ought to accept patches that fix this problem. It's true that GCC doesn't in general document these semantics, but users of some ABIs have expectations about how volatile bitfields will work. DJ, I'd suggest you look at: http://infocenter.arm.com/help/topic/com.arm.doc.ihi0042c/IHI0042C_aapcs.pdf and, in particular, \S 7.1.7.5, entitled "Volatile bit-fields". A first question is if these are the semantics that you're looking for in your project. If so, then we could collaborate with you on implementing them. If not, there may be still be some common parts. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
C front end trouble
Hi, I´m having some troubles again. I wanna convert a tree structure to c_declspecs structure. Anybody know how I could do that? Thanks -- -- "Never memorize something that you can look up." - Albert Einstein --
Re: generating functions and eh region
On Fri, 3 Apr 2009, Ian Lance Taylor wrote: > gcc's -fasynchronous-unwind-tables option is > intended to support unwinding the stack at any precise instruction > boundary, which might be adequate for this purpose if the OS can handle > the adjustment from an exception in the middle of an instruction to an > exception after the previous instruction is complete. Unfortunately, > -fasynchronous-unwind-tables doesn't work; unwinding the stack during a > function epilogue is not handled correctly. FWIW, that's what I've once thought, but different GCC people have different opinions on the extent of exceptions that -fasynchronous-unwind-tables can and should enable. For example some Richards exclude prologue and epilogue and/or stack-slot accesses. Just pointing out that there's no consensus on what's a bug and what's a reasonable limitation of -fasynchronous-unwind-tables. I'm not sure there is consensus among the GNAT people either. brgds, H-P
Re: [lto] Mainline merge @145453
> Unsurprisingly, this merge was quite painful. Particularly > adapting to all the new EH changes. The main changes I needed to > do: > > - The master_clone field is gone from cgraph_node. Some things > had to be handled differently when reading/writing cgraph > nodes. > > - There was a bug when emitting/reading EH tables. We were not > handling region aliases (the aka bitmap). EH regions are Sorry, I was actually thinking about checking if LTO saves AKA bitmaps and tell you, but forgot about that. What do you mean by shared regions? It wold probably be easiest to just dump the tree and after reading populate the region array based on AKA bitmaps? Honza
Re: Invalid reload inheritance with paradoxical subregs
Hans-Peter Nilsson wrote:
On Thu, 2 Apr 2009, Uros Bizjak wrote:
Combine simplifies lshiftrt/shift/and combined instruction under the
assumption, that for ZERO_EXTEND LOAD_EXTEND_OP targets it can prove
that certain bits are zero, so AND operation can be omitted. The
resulting instruction is valid only for memory operand:
...
(gdb) p debug_rtx (insn)
(insn 121 120 125 2 t.c:22 (set (reg:SI 6 r6 [orig:48 y$k.115 ] [48])
(lshiftrt:SI (subreg:SI (reg:HI 7 r7) 0)
(const_int 5 [0x5]))) 62 {lshrsi3} (nil))
This substitution is wrong. Paradoxical subreg of a memory operand is
for our target known to zero extend to SImode value, however -
paradoxical subreg of a register operand has undefined bits outside
the reg. So, combine and reload doesn't agree on the bits outside the
register.
Looks like the issue I attributed to IRA for
mmix-knuth-mmixware:
(no, not a great deal of analysis there, I'm afraid).
And again, I'd be perfectly fine with removing this weird
LOAD_EXTEND_OP-specific "feature". I'm of half a mind to remove
the #define from the MMIX port.
Please note, that my findings were on 4.3.4 to-be-released branch. I'm
afraid that IRA has nothing to do with this problem, IMO we are looking
at plain reload bug here. Removing your #define won't fix the failure,
it will simply change register allocation slightly to _hide_ the failure.
The problem is, that reload should not inherit/substitute memory operand
(where LOAD_EXTEND_OP defines bits outside the range) with register
operand (where bits outside the range are undefined).
Uros.
Re: [lto] Mainline merge @145453
On Mon, Apr 6, 2009 at 10:44, Jan Hubicka wrote:
> Sorry, I was actually thinking about checking if LTO saves AKA bitmaps
> and tell you, but forgot about that. What do you mean by shared
> regions?
If EH region 3 has the AKA bitmap { 4, 5, 7, 13 } then slots 3, 4, 5 7
and 13 in the EH table will point to the same physical region.
> It wold probably be easiest to just dump the tree and after reading
> populate the region array based on AKA bitmaps?
Not really. Reading the EH table makes it easier to reconstruct the
tree. We emit all the regions together and replace the pointers with
indices into the EH table. We then fixup those pointers after the EH
table has been read in.
Diego.
Re: Invalid reload inheritance with paradoxical subregs
On Mon, 6 Apr 2009, Uros Bizjak wrote: > Hans-Peter Nilsson wrote: > > And again, I'd be perfectly fine with removing this weird > > LOAD_EXTEND_OP-specific "feature". I'm of half a mind to remove > > the #define from the MMIX port. > Please note, that my findings were on 4.3.4 to-be-released branch. I'm afraid > that IRA has nothing to do with this problem, IMO we are looking at plain > reload bug here. IRA was just "needed" for MMIX to *uncover* the bug. > Removing your #define won't fix the failure, it will simply > change register allocation slightly to _hide_ the failure. I was referring to the MMIX #define LOAD_EXTEND_OP, not (the never committed) #define IRA_COVER_CLASSES. > The problem is, that reload should not inherit/substitute memory operand > (where LOAD_EXTEND_OP defines bits outside the range) with register operand > (where bits outside the range are undefined). Something like that, yes. brgds, H-P
Re: Debugging gcc front end
Guilherme Puglia <1c3br...@gmail.com> writes: > To solve my problem I wanna debug the C front end. I was trying to > debug the gcc main function, toplev_main. Unfortunately, I can't > insert a break point in this line. > > I saw the site http://gcc.gnu.org/wiki/DebuggingGCC and > http://gcc.gnu.org/ml/gcc/2004-03/msg01195.html > > But I don't understand where is "my path". And how to insert the break point. If you want help, you need to tell us precisely what you did, precisely what happened, and what you expected to happen. >From your description it sounds like you are having trouble running the debugger, in which case you might want to ask for help about the debugger. But I'm really not sure. Ian
Re: C front end trouble
Guilherme Puglia <1c3br...@gmail.com> writes: > I´m having some troubles again. I wanna convert a tree structure to > c_declspecs structure. > > Anybody know how I could do that? That seems like an odd transformation to want to make. There is nothing in the compiler which does that today. You could do a rough approximation of it by examining the type to look for qualifiers, and pull them off. There is no way to do the fully general transformation, as c_declspecs as information which is not represented in tree. Ian
Re: generating functions and eh region
Hans-Peter Nilsson writes: > On Fri, 3 Apr 2009, Ian Lance Taylor wrote: >> gcc's -fasynchronous-unwind-tables option is >> intended to support unwinding the stack at any precise instruction >> boundary, which might be adequate for this purpose if the OS can handle >> the adjustment from an exception in the middle of an instruction to an >> exception after the previous instruction is complete. Unfortunately, >> -fasynchronous-unwind-tables doesn't work; unwinding the stack during a >> function epilogue is not handled correctly. > > FWIW, that's what I've once thought, but different GCC people > have different opinions on the extent of exceptions that > -fasynchronous-unwind-tables can and should enable. For example > some Richards exclude prologue and epilogue and/or stack-slot > accesses. > > Just pointing out that there's no consensus on what's a bug and > what's a reasonable limitation of -fasynchronous-unwind-tables. > I'm not sure there is consensus among the GNAT people either. Could be, but the documentation of -fasynchronous-unwind-tables clearly implies that it should work during a function epilogue, and there are reasonable uses which require it to work during a function epilogue (e.g., a profil based signal handler which captures stack backtraces). I'm perfectly happy to have both -fasynchronous-unwind-tables and -fincomplete-ascyhronous-unwind-tables. Ian
Re: fwprop and CSE const anchor opt
Adam Nemet writes:
> Richard Sandiford writes:
>> Adam Nemet writes:
>> > * Synthesizing multi-insns constants from const anchors make sense
>> > regardless
>> > whether the constant is used as an address so I am adjusting the cost
>> > system
>> > to make those stick independent of the context. I still need to benchmark
>> > this.
>>
>> Out of interest, what sort of changes did you need to make? Do you care
>> about the cases where rtx_costs is applied to a pattern that won't later
>> be checked by recog (such as the calls from the expander)? Or do you
>> just care about the cases where rtx_costs is used to check whether a
>> validate_change would be profitable?
>
> I am glad you asked because I myself was going to ask you some questions in
> this area ;).
>
> I think the best way to formulate the profitability question for multi-insn
> constants in CSE is this. We found an expression using a const-anchor that is
> equivalent to the REG_EQUAL note on the insn. We go with the const-anchor
> expression if it is cheaper than the REG_EQUAL expression.
>
> Comparing the cost of the actual source in the insn against the const-anchor
> expression would ignore the fact that the preceding instructions buiding up
> the constants become redundant with the const-anchor expression.
>
> I also have an alternative solution that feels more hackish and gives less
> control to the backend but works with the current cost model. For a
> multi-insn constant if the current cost and the cost of the new expression are
> equal we prefer the new expression. This works for MIPS because AFAICT we
> always replace a binary expression with another one of the same cost.
Nicely explained, thanks. I see where you're coming from.
So it's the CSE REG_EQUAL costs that are causing problems. We're applying
rtx_costs to something that isn't usually a valid insn pattern (the first
case above). Hmm.
> The problem with the first approach and I feel you were anticipating this with
> your question is that multi-insn constants have a cost of zero in the MIPS
> backend currently. Or with the code from mips_rtx_costs:
>
> case CONST_INT:
> [...]
> /* When not optimizing for size, we care more about the cost
>of hot code, and hot code is often in a loop. If a constant
>operand needs to be forced into a register, we will often be
>able to hoist the constant load out of the loop, so the load
>should not contribute to the cost. */
> if (!optimize_size
> || mips_immediate_operand_p (outer_code, INTVAL (x)))
> {
> *total = 0;
> return true;
> }
>
> That is really hard to beat for an immediate add, which is COSTS_N_INSNS (1).
Right. ;)
> Since you already offered :), can you please explain where the above code is
> needed and whether we can refine the picture a little bit. It definitely
> feels like the above cost value is only true in certain contexts. This might
> be a naive comment but maybe somehow limiting the effect to that particular
> context would be a good improvement.
OK, well, I should probably start by saying that this behaviour is
traditional. The version in 3.0 was:
case CONST_INT: \
if (! TARGET_MIPS16)\
{ \
/* Always return 0, since we don't have different sized \
instructions, hence different costs according to Richard \
Kenner */\
return 0; \
} \
And like you, I found it somewhat strange at first. (The comment didn't
exactly help.) But when I began to experiment with costs as part of
CodeSourcery and MTI's 2007-09-11 -Os patch, it did indeed seem to be
right thing when optimising for speed rather than size. The comment
in trunk is my attempt to explain why. (I'm not sure now that it's
any better than the 3.0 comment, but never mind.)
If we have an instruction:
A: (set (reg Z) (plus (reg X) (const_int 0xdeadbeef)))
we will need to use something like:
(set (reg Y) (const_int 0xdead))
(set (reg Y) (ior (reg Y) (const_int 0xbeef)))
B: (set (reg Z) (plus (reg X) (reg Y)))
But if A is in a loop, the Y loads can be hoisted, and the cost
of A is effectively the same as the cost of B. In other words,
the (il)legitimacy of the constant operand doesn't really matter.
(Of course, anything that relies on a hoisted value can increase register
pressure, but rtx_costs is too blunt a tool to determine when that's
actually a problem. I remember experimenting with adding a sub-insn
cost (like 1 rather than COSTS_N_INSNS(1)), but these subinsn costs
can aggregate into a misle
PATCH for Re: "Host/Target specific installation notes for GCC": broken link
On Sun, 22 Mar 2009, Dennis Schridde wrote:
> The page on "Host/Target specific installation notes for GCC"
> (http://gcc.gnu.org/install/specific.html) has a broken link.
> In the table of contents it links to
> "http://gcc.gnu.org/install/specific.html#x-x-mingw";, while
> "http://gcc.gnu.org/install/specific.html#x-x-mingw32"; would be correct.
Not just that, there also was another broken cross-reference. The
patch below fixes both of those. I have tested this by building and
examining the HTML files and also deployed the change on gcc.gnu.org
and verified them via the website there.
Thanks for the report, Dennis!
Gerald
2009-04-06 Gerald Pfeifer
* doc/install.texi (Specific): Fix two cross-references to MinGW.
Index: doc/install.texi
===
--- doc/install.texi(revision 145616)
+++ doc/install.texi(working copy)
@@ -2726,7 +2726,7 @@
@item
@uref{#x-x-interix,,*-*-interix}
@item
-...@uref{#x-x-mingw,,*-*-mingw}
+...@uref{#x-x-mingw32,,*-*-mingw32}
@item
@uref{#os2,,OS/2}
@item
@@ -4124,7 +4124,7 @@
Linux API emulation layer in the Win32 subsystem.
@item Interix @uref{#x-x-interix,,*-*-interix}: The Interix subsystem
provides native support for POSIX.
-...@item MinGW @uref{#x-x-mingw,,*-*-mingw}: MinGW is a native GCC port for
+...@item MinGW @uref{#x-x-mingw32,,*-*-mingw32}: MinGW is a native GCC port
for
the Win32 subsystem that provides a subset of POSIX.
@item MKS i386-pc-mks: NuTCracker from MKS. See
@uref{http://www.mkssoftware.com/} for more information.
Re: typo in gcc-4.4 changes
On Sat, 4 Apr 2009, Jonathan Wakely wrote:
> There is currently no way to get from the front page to the
> gcc-4.4/changes.html page, should there be a "(changes)" link on the
> front page until a release is added to the gcc-4.4/index.html page?
I think that would be appropriate, yes. Are you going to make this
change?
GeraldIndex: htdocs/gcc-4.4/porting_to.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.4/porting_to.html,v
retrieving revision 1.2
diff -u -p -r1.2 porting_to.html
--- htdocs/gcc-4.4/porting_to.html 9 Feb 2009 21:05:18 - 1.2
+++ htdocs/gcc-4.4/porting_to.html 4 Apr 2009 12:51:15 -
@@ -79,7 +79,7 @@ struct A
void foo()
{
char buf[sizeof(struct A)];
- ((struct A*)buf)->i = 4;
+ ((struct A*)buf)->i = 4;
}
@@ -151,11 +151,11 @@ but will issue the diagnostic
-In constructor ‘C::C()’:
-error: uninitialized member ‘C::a’ with ‘const’ type ‘const B’
+In constructor 'C::C()':
+error: uninitialized member 'C::a' with 'const' type 'const B'
-To fix, use a member initialization list to initialize the memmber, like so:
+To fix, use a member initialization list to initialize the member, like so:
Re: bitfields: types vs modes?
> http://infocenter.arm.com/help/topic/com.arm.doc.ihi0042c/IHI0042C_aapcs.pdf
>
> and, in particular, \S 7.1.7.5, entitled "Volatile bit-fields".
>
> A first question is if these are the semantics that you're looking for
> in your project. If so, then we could collaborate with you on
> implementing them. If not, there may be still be some common parts.
Yes, that's pretty much what they asked for. However, it is still
somewhat ambiguous - for example, if you have an 8-bit "int" field,
which 4 bytes are read to get that field? Should we take into
consideration adjacent field types, or the type's natural alignment?
What if the field spans natural alignment boundaries? What if the
larger-than-field access exceeds the memory region and causes a fault?
For example, in this case, when we access x.b does it also read a, or
c? Will reading x.d cause a segment fault?
volatile struct {
char a:8;
int b:24;
char c:8;
int d:8;
} x;
We need to figure out how much information we should pass to the
target to let it make these decisions, if it needs to. A common
function to do by-type access could be called from your target and
mine.
Re: Call for testers: MPC-0.6 released
On Sat, 4 Apr 2009, Andreas Tobler wrote: >>> I've cc'ed others who have access to the platforms in question based on >>> GCC test results. Please help if you can. >> >> - powerpc-apple-darwin9.6.0 gcc-4.5.0 gmp-4.2.2 mpfr-2.3.1 ok. >> - sparc-sun-solaris2.10 gcc-4.4 gmp-4.2.2 mpfr-2.3.1 ok >> - i686-apple-darwin9 gcc-4.0.1 gmp-4.2.2 mpfr-2.3.1 ok >> - x86_64-apple-darwin9 gcc-4.5.0 gmp-4.2.2 mpfr-2.3.1 ok >> >> Open: hppa2.0w-hp-hpux11.11 and x86_64-xxx-freebsd8, will follow tomorrow. > > - powerpc-unknown-freebsd8 gcc-4.2.1 gmp-4.2.4 mpfr-2.4.1 ok > - sparc64-unknown-freebsd8 gcc-4.2.1 gmp-4.2.4 mpfr-2.4.1 ok > - x86_64-unknown-freebsd8 gcc-4.2.1 gmp-4.2.4 mpfr-2.4.1 ok > > - hppa2.0w-hp-hpux11.11 gcc-4.3.1 gmp-4.2.2 mpfr-2.3.1 ok > - hppa64-hp-hpux11.11 gcc-4.1.1 gmp-4.2.2 mpfr-2.3.1 ok > > That's all. Cool, thanks. Kaveh, are you going to relay these to the MPC developers, or should we do this to get FreeBSD (and the others) covered? Gerald
Re: typo in gcc-4.4 changes
2009/4/6 Gerald Pfeifer: > On Sat, 4 Apr 2009, Jonathan Wakely wrote: >> There is currently no way to get from the front page to the >> gcc-4.4/changes.html page, should there be a "(changes)" link on the >> front page until a release is added to the gcc-4.4/index.html page? > > I think that would be appropriate, yes. Are you going to make this > change? I've just checked in the attached. Jonathan Index: htdocs/index.html === RCS file: /cvs/gcc/wwwdocs/htdocs/index.html,v retrieving revision 1.696 diff -u -p -r1.696 index.html --- htdocs/index.html 31 Mar 2009 21:20:58 - 1.696 +++ htdocs/index.html 6 Apr 2009 20:11:09 - @@ -88,6 +88,7 @@ target has been contributed by Picochip Current release series: GCC 4.4.0 + (changes) Status: http://gcc.gnu.org/ml/gcc/2009-03/msg00397.html";>2009-03-13
Re: GCC 4.4.0 Status Report (2009-03-13)
On Fri, 20 Mar 2009, Joe Buck wrote: > When there is traffic, the SC gets to spend time arguing with RMS. Oh, joy. On Mon, 23 Mar 2009, Tom Tromey wrote: > Recently I've been thinking: let's have a periodic election for a > developer ombudsman member on the SC, someone who could summarize > (to the extent possible) SC happenings, much as the RMs do now for > releases. I think you will be surprised how little (let alone: interesting) goes on there. I can understand what you are saying, though, and will raise a proposal to compile and share a (bi-)monthly report on the SC list which I volunteer to create. Gerald
Re: bitfields: types vs modes?
DJ Delorie wrote: > Yes, that's pretty much what they asked for. However, it is still > somewhat ambiguous - for example, if you have an 8-bit "int" field, > which 4 bytes are read to get that field? I haven't gone back just now to try to find the right words in the ABI, so I don't know for sure that they're there, but the intent is the types' natural alignment. All "int" bit-fields in that ABI are located within a 32-bit aligned range of memory; the intent is that you read/write that entire 4-byte range. In other words, take the byte address of the start of the bit-field, mask off the two low-order bits, that's the 4-byte address to read. On an ARM, you can never cross a protection boundary in that way; you're never going to get a SEGV from the bytes you read in that way if you wouldn't have gotten one from the byte containing the start of the bit-field. Protection is done at the page (or cache-line, I forget) boundary; in either case, the granularity of protection is greater than the granularity of any basic type. And, if it's not, that's your problem; the ABI semantics of a volatile bit-field of type T are that you get sizeof(T) bytes, and if it blows up (which I don't think it can), it's not the compiler's fault. If you have an ABI where an int bit-field can cross a sizeof(int)-byte boundary, that's a harder case. That can happen on ARM with GCC's packed-structure extension, but that's outside the ARM ABI, and therefore the behavior is not specified. > We need to figure out how much information we should pass to the > target to let it make these decisions, if it needs to. A common > function to do by-type access could be called from your target and > mine. I'd like to know how many of the assumptions above are valid on your target. I would imagine that many of them are. In which case, the existing hook is good enough; we just need to implement middle-end behavior depending on the hook. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: Merging the alias-improvements branch
I wrote: Richard Guenther wrote: I plan to merge the alias-improvements branch next weekend (in 7 days) if all goes well. I will do bootstrap & regtesting on the archs I have available (x86_64, i?86, ppc, ppc64, ia64, s390 and s390x). I am absolutely thrilled to test it on our weather forecasting system. The top routine in our profile looks a *lot* like the loop you got such an improvement on in SPEC's mgrid ... Unfortunately, the improvement is not as large as I had hoped: Before the merge of the alias-improvements branch into mainline: 00 UTC run 20090405, last file produced: -rw-r--r-- 1 hirlam hirlam 21492000 2009-04-05 08:31 fc20090405_00+048ve After the merge of the alias-improvements branch into mainline: 00 UTC run 20090406, last file produced: -rw-r--r-- 1 hirlam hirlam 21648000 2009-04-06 08:29 fc20090406_00+048ve So the improvement is 2 minutes for a 3.5 hour run (~ 1%). Kind regards, -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands At home: http://moene.org/~toon/ Progress of GNU Fortran: http://gcc.gnu.org/gcc-4.4/changes.html
Re: GCC Compile Farm News: 12 architectures now available
Hi Laurent, On Wed, 4 Mar 2009, Laurent GUERBY wrote: > On Wed, 2009-03-04 at 13:24 +0100, Richard Guenther wrote: >> On the above list, what are the target triples that are available? Do >> they match what we have in our list of primary and secondary targets >> (see http://gcc.gnu.org/gcc-4.4/criteria.html)? > We have only variants of Linux as OS for now, so these > match but not the rest. > > For i386-unknown-freebsd I could set up one, it seems that Gerald > Pfeifer has a tester already spamming gcc-testresult :). sadly, nobody has sent me his credit card or account information yet; I guess I need to add some testcases for blue pills or such. :) Seriously, I think it would be great to also have a FreeBSD tester on the Compile Farm, once because that'll allow access by others, and secondly because my tester may fail (and in fact that has happened a few days ago and while I managed to get it up and running again, it would be really comforting to have a backup). If you need some help administrating such a machine, I may be able to provide some help. Gerald
Re: GCC Compile Farm News: 12 architectures now available
On Mon, 2009-04-06 at 23:10 +0200, Gerald Pfeifer wrote: > Hi Laurent, > > On Wed, 4 Mar 2009, Laurent GUERBY wrote: > > On Wed, 2009-03-04 at 13:24 +0100, Richard Guenther wrote: > >> On the above list, what are the target triples that are available? Do > >> they match what we have in our list of primary and secondary targets > >> (see http://gcc.gnu.org/gcc-4.4/criteria.html)? > > We have only variants of Linux as OS for now, so these > > match but not the rest. > > > > For i386-unknown-freebsd I could set up one, it seems that Gerald > > Pfeifer has a tester already spamming gcc-testresult :). > > sadly, nobody has sent me his credit card or account information > yet; I guess I need to add some testcases for blue pills or such. :) > > Seriously, I think it would be great to also have a FreeBSD tester > on the Compile Farm, once because that'll allow access by others, and > secondly because my tester may fail (and in fact that has happened a > few days ago and while I managed to get it up and running again, it > would be really comforting to have a backup). If you need some help > administrating such a machine, I may be able to provide some help. In facy I just started yesterday the effort to get physical i686-net/open/freeBSD machines in the compile farm: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39625 << I've found machines and hosting to add i686 free/net/openBSD to the compile farm, they should be online in the coming weeks, this allow smoother GCC development and testing on these platforms. >> Your admin expertise will certainly be helpful, thanks! Note to gcc@ readers: if you're in Paris (France), know how to install any of free/net/openBSD (on a bi-pentium3 Dell poweredge 1550 machine if that matters) or know someone in Paris who could do that please contact me privately that will speed up the process. Laurent
lookup_name
does the function lookup_name distinguish the identifier between
different contexts?
for example
void func1()
{
int foo;
}
void func2()
{
int foo;
}
if I call lookup_name with the foo ident-tree while parsing these
functions, will it return different decl-tree nodes?
thanks
Re: Debugging gcc front end
Guilherme Puglia wrote: > Hi! > > or better, hello again! I have posted a question (with my class friend > Eduardo) about 2 or 3 weeks ago. My question was about the grammar > wich gcc C front end use. Yeh! Hi again you guys :) > To solve my problem I wanna debug the C front end. I was trying to > debug the gcc main function, toplev_main. Unfortunately, I can't > insert a break point in this line. > > I saw the site http://gcc.gnu.org/wiki/DebuggingGCC and > http://gcc.gnu.org/ml/gcc/2004-03/msg01195.html > > But I don't understand where is "my path". And how to insert the break point. Ok, sounds like you're not much familiar with using the shell? When it says your path, it means the $PATH variable used to look for command-line executables. About setting the breakpoint: if you're using gdb, the command would be "b toplev_main", it's all in the manual. The main thing I'm not sure if you're fully aware of is that when you run "gcc" at the command-line you're just invoking a simple driver program that then invokes the preprocessor, compiler, assembler and linker as separate processes, so you don't want to debug gcc itself. If you add "-v" to the gcc command-line, you will see (among other debug info) the separate individual commands it issues to run these other processes. You'll see that the first two commands both invoke "cc1" (or "cc1plus in C++) - the first time, with the "-E" option to do the preprocessing on the source file, the second time without "-E" to process the generated .i file. It's that second command-line that you want to actually run under the debugger to inspect the compilation process. cheers, DaveK
Re: Call for testers: MPC-0.6 released
From: "Gerald Pfeifer" On Sat, 4 Apr 2009, Andreas Tobler wrote: I've cc'ed others who have access to the platforms in question based on GCC test results. Please help if you can. - powerpc-apple-darwin9.6.0 gcc-4.5.0 gmp-4.2.2 mpfr-2.3.1 ok. - sparc-sun-solaris2.10 gcc-4.4 gmp-4.2.2 mpfr-2.3.1 ok - i686-apple-darwin9 gcc-4.0.1 gmp-4.2.2 mpfr-2.3.1 ok - x86_64-apple-darwin9 gcc-4.5.0 gmp-4.2.2 mpfr-2.3.1 ok Open: hppa2.0w-hp-hpux11.11 and x86_64-xxx-freebsd8, will follow tomorrow. - powerpc-unknown-freebsd8 gcc-4.2.1 gmp-4.2.4 mpfr-2.4.1 ok - sparc64-unknown-freebsd8 gcc-4.2.1 gmp-4.2.4 mpfr-2.4.1 ok - x86_64-unknown-freebsd8 gcc-4.2.1 gmp-4.2.4 mpfr-2.4.1 ok - hppa2.0w-hp-hpux11.11 gcc-4.3.1 gmp-4.2.2 mpfr-2.3.1 ok - hppa64-hp-hpux11.11 gcc-4.1.1 gmp-4.2.2 mpfr-2.3.1 ok That's all. Cool, thanks. Kaveh, are you going to relay these to the MPC developers, or should we do this to get FreeBSD (and the others) covered? Gerald I've been relaying the messages, (but I haven't seen the MPC webpage updated to reflect this yet). --Kaveh
Re: lookup_name
Eduardo Cruz writes: > does the function lookup_name distinguish the identifier between > different contexts? I assume you mean the function in the C frontend, in c-decl.c. That function looks up the name in the current scope, so, yes, it will return different DECL nodes when appropriate. Ian
