Re: [RFH] Fixing -fsection-anchors on powerpc-darwin
Andrew Pinski <[EMAIL PROTECTED]> writes:
> Since -fsection-anchors is very useful for PPC-Darwin, I decided to
> see what I needed to do to support them.
> I started by just doing a bootstrap with them enabled by default
> and ran into the first issue of SET_ASM_OP not being set. Next
> I ran into the issue of quoting ". + 0" which caused the assembler
> to think it is a symbol instead of an addition of . and 0.
Have you thought about overriding the output_anchor hook for Darwin?
It sounds simpler than what you did in the patch, and the hook was
there specifically for cases where the ASM_OUTPUT_DEF thing wouldn't
work.
> The next issue I could not figure out how to fix, it is wrong code
> caused by merging constant strings together.
> Here is the reduced testcase (reduced from genmodes.c):
> int modes;
> emit_mode_class (void)
> {
>int t;
>for(t = 0;t__builtin_puts ("");
> }
> int main(void)
> {
>char a[3] = "-h";
>if (!strcmp (a, "-h")) ; else __builtin_abort ();
>emit_mode_class ();
> }
>
> If someone could look into this, it would be nice, I think the use
> of .cstring and anchors are not supported together as .cstring section
> can be merged.
Right. This is handled for ELF by:
/* Don't use anchors for mergeable sections. The linker might move
the objects around. */
sect = SYMBOL_REF_BLOCK (symbol)->sect;
if (sect->common.flags & SECTION_MERGE)
return false;
in default_use_anchor_for_symbol_p. If .cstring contains mergeable
data, it sounds like you should either (a) set SECTION_MERGE for it
or (b) override use_anchor_for_symbol_p for Darwin and check whether
SYMBOL_REF_BLOCK (symbol)->sect == cstring_section.
Richard
very confused about single_set
Steven, Zdenek 1) single_set is built on top of single_set2. 2) single_set_2 uses REG_UNUSED notes. 3) tree-ssa-loop-ivops.c:seq_cost uses single_set. I can find no indication that rtl dfa is run here to provide the information for single_set to produce the correct answer. Inquiring minds want to know. Kenny
Re: very confused about single_set
On Sun, 2006-02-19 at 09:56 -0500, Kenneth Zadeck wrote: > Steven, Zdenek > > 1) single_set is built on top of single_set2. Yes > 2) single_set_2 uses REG_UNUSED notes. Only if there are multiple sets. > 3) tree-ssa-loop-ivops.c:seq_cost uses single_set. This is because Zdenek builds RTL to determine target costs. > > I can find no indication that rtl dfa is run here to provide the > information for single_set to produce the correct answer. I don't understand what you mean. Why does the DFA need to be run to produce the correct answer? (Our ports use Deterministic Finite Automaton based schedulers, so saying DFA is an ambiguous term at best) Or do you mean DataFlow Analysis, in which case, i'm sure everyone expects the notes are always up to date (even though they may not be).
Bootstrap failure on trunk: x86_64-linux-gnu
When building a-textio in libada, today's gcc build fails when memory is exhausted. Seems like VRP is looping, consuming more and more memory. Andrew. make[7]: `a-teioed.o' is up to date. /home/aph/gcc/build-x86_64-unknown-linux-gnu/./gcc/xgcc -B/home/aph/gcc/build-x86_64-unknown-linux-gnu/./gcc/ -B/home/aph/gcc/install/x86_64-unknown-linux-gnu/bin/ -B/home/aph/gcc/install/x86_64-unknown-linux-gnu/lib/ -isystem /home/aph/gcc/install/x86_64-unknown-linux-gnu/include -isystem /home/aph/gcc/install/x86_64-unknown-linux-gnu/sys-include -c -g -O2 -fPIC -W -Wall -gnatpg a-textio.adb -o a-textio.o virtual memory exhausted: Cannot allocate memory make[7]: *** [a-textio.o] Error 1 make[7]: Leaving directory `/homes/home/aph/gcc/build-x86_64-unknown-linux-gnu/gcc/ada/rts' make[6]: *** [gnatlib] Error 2 make[6]: Leaving directory `/homes/home/aph/gcc/build-x86_64-unknown-linux-gnu/gcc/ada' make[5]: *** [gnatlib-shared-default] Error 2 make[5]: Leaving directory `/homes/home/aph/gcc/build-x86_64-unknown-linux-gnu/gcc/ada' make[4]: *** [gnatlib-shared-dual] Error 2 make[4]: Leaving directory `/homes/home/aph/gcc/build-x86_64-unknown-linux-gnu/gcc/ada' make[3]: *** [gnatlib-shared] Error 2 make[3]: Leaving directory `/homes/home/aph/gcc/build-x86_64-unknown-linux-gnu/gcc/ada' make[2]: *** [gnatlib-shared] Error 2 make[2]: Leaving directory `/homes/home/aph/gcc/build-x86_64-unknown-linux-gnu/x86_64-unknown-linux-gnu/libada' make[1]: *** [all-target-libada] Error 2 Program received signal SIGINT, Interrupt. 0x009260c9 in tree_int_cst_compare (t1=0x2b05a43cfe70, t2=0x2b05a55296c0) at /home/aph/gcc/trunk/gcc/tree.c:4390 (gdb) bt #0 0x009260c9 in tree_int_cst_compare (t1=0x2b05a43cfe70, t2=0x2b05a55296c0) at /home/aph/gcc/trunk/gcc/tree.c:4390 #1 0x0095ce9d in extract_range_from_expr (vr=0x7fd07e80, expr=0x2b05a540c9b0) at /home/aph/gcc/trunk/gcc/tree-vrp.c:614 #2 0x0095d752 in vrp_visit_assignment (stmt=0x2b05a540ca00, output_p=0x7fd07ef0) at /home/aph/gcc/trunk/gcc/tree-vrp.c:3366 #3 0x006a2bf1 in simulate_stmt (stmt=0x2b05a540ca00) at /home/aph/gcc/trunk/gcc/tree-ssa-propagate.c:306 #4 0x006a2e0f in process_ssa_edge_worklist (worklist=0x12417e8) at /home/aph/gcc/trunk/gcc/tree-ssa-propagate.c:380 #5 0x006a3243 in ssa_propagate (visit_stmt=Variable "visit_stmt" is not available. ) at /home/aph/gcc/trunk/gcc/tree-ssa-propagate.c:683 #6 0x0095f2bf in execute_vrp () at /home/aph/gcc/trunk/gcc/tree-vrp.c:4569 #7 0x0094fd86 in execute_one_pass (pass=0x12f3550) at /home/aph/gcc/trunk/gcc/passes.c:854 #8 0x0094feec in execute_pass_list (pass=0x12f3550) at /home/aph/gcc/trunk/gcc/passes.c:898 #9 0x0094fefe in execute_pass_list (pass=0xdd6380) at /home/aph/gcc/trunk/gcc/passes.c:899 #10 0x0065853a in tree_rest_of_compilation (fndecl=0x2b05a5359500) at /home/aph/gcc/trunk/gcc/tree-optimize.c:412 #11 0x0041b715 in gnat_expand_body (gnu_decl=0x2b05a5359500) at /home/aph/gcc/trunk/gcc/ada/misc.c:653 #12 0x009a3966 in cgraph_expand_function (node=0x2b05a539f6c0) at /home/aph/gcc/trunk/gcc/cgraphunit.c:1101 #13 0x009a5f38 in cgraph_optimize () at /home/aph/gcc/trunk/gcc/cgraphunit.c:1166 #14 0x0041bf8a in gnat_parse_file (set_yydebug=Variable "set_yydebug" is not available. ) at /home/aph/gcc/trunk/gcc/ada/misc.c:245 #15 0x00921378 in toplev_main (argc=Variable "argc" is not available. ) at /home/aph/gcc/trunk/gcc/toplev.c:999 #16 0x003d4071d024 in __libc_start_main () from /lib64/libc.so.6 #17 0x004030b9 in _start () #18 0x7fd081f8 in ?? () #19 0x in ?? () (gdb)
Re: Bootstrap failure on trunk: x86_64-linux-gnu
On Feb 19, 2006, at 12:09 PM, Andrew Haley wrote: When building a-textio in libada, today's gcc build fails when memory is exhausted. This has already been reported as PR 26348 and it looks like a bug in the Ada front-end. Thanks, Andrew Pinski
Re: Bootstrap failure on trunk: x86_64-linux-gnu
> This has already been reported as PR 26348 and it looks like a bug > in the Ada front-end. Note that technically, its still a regression caused by a non Ada patch. Anyway, hopefully Eric and Jeff can work together in identifying the proper fix. Arno
Re: Bootstrap failure on trunk: x86_64-linux-gnu
Andrew Haley <[EMAIL PROTECTED]> writes: > When building a-textio in libada, today's gcc build fails when memory > is exhausted. This is PR26348. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: Bootstrap failure on trunk: x86_64-linux-gnu
Andrew Pinski writes: > > On Feb 19, 2006, at 12:09 PM, Andrew Haley wrote: > > > When building a-textio in libada, today's gcc build fails when memory > > is exhausted. > > This has already been reported as PR 26348 and it looks like a bug > in the Ada front-end. Oh right, thanks. Was this mentioned on the list anywhere? Andrew.
Re: gcc build / test times on multi-core hosts?
Laurent GUERBY writes: > On Fri, 2006-02-17 at 22:43 +, Joern RENNECKE wrote: > > Has anybody done timings for gcc bootstrap / cross builds and regtests > > with modern multi-core processors? I wonder what a sensible modern > > configuration would be for gcc development, but the the multimedia and > > games benchmarks I found on the web neither seem particularily relevant, > > nor do they paint a uniform picture. > > On a "AMD Athlon(tm) 64 X2 Dual Core Processor 3800+" (2.0 GHz), 2GB of > RAM trunk configured with: > > --enable-languages=c,ada,c++,fortran,java,treelang,objc > --enable-__cxa_atexit > --disable-nls > --enable-threads=posix > --disable-multilib > --enable-checking > > Gives the following timing at -j1: > > === GCCBOOT start === 2006-02-16 22:13:46 > === GCCBOOT configure === 2006-02-16 22:13:46 > === GCCBOOT bootstrap === 2006-02-16 22:13:51 > === GCCBOOT doc === 2006-02-17 01:48:53 > === GCCBOOT check === 2006-02-17 01:48:53 > === GCCBOOT summary === 2006-02-17 04:15:25 > === GCCBOOT install === 2006-02-17 04:15:37 > === GCCBOOT done === 2006-02-17 04:20:03 > > So that's 6h07 total, bootstrap 3h35 and check 2h27. I assume > -j2 could cut bootstrap times by about two, I'm not > sure check is parallel (Ada check isn't for sure). > > On a Pentium III 1GHz, bootstrap is 5h55 and check 5h30 > (on an older version of the tree), so p3/amd64 > > Removing Ada from --enable-languages will also help :). As a comparison point, I get real73m39.275s user113m19.549s sys 15m26.010s for the bootstrap: that's 1h14 elapsed time. That's on a "AMD Athlon(tm) 64 X2 Dual Core Processor 4800+" (2.4 GHz) with make -j3. That's 129min of CPU time in 74min of elapsed time, a pretty good processor utilization ratio of 1.75 : 2. Andrew.
GCC 4.1 RC1
I will be spinning RC1 this morning, as previously announced. I know that there are some outstanding patches in my email, which people have requested for 4.1. I'll review those before producing RC1, and apply them to the 4.1 branch myself if appropriate; I'll still ask the original submitters to apply to other branches. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: Bootstrap failure on trunk: x86_64-linux-gnu
> Anyway, hopefully Eric and Jeff can work together in identifying the > proper fix. Jeff already did a thorough analysis of the problem (thanks!) and came to the following double conclusion. Quoting him: "First, the inconsistency between the type's precision in its min/max values needs to be fixed. Most likely this is an Ada FE problem." more precisely: "Now for the first "oddity". If we look at the underlying type for last we have a type "natural___XDLU_0__2147483647". What's interesting about it is that it has a 32bit type precision, but the min/max values only specify 31 bits. ie, the min/max values are 0, 0x7fff." That's an old problem, which has already been discussed IIRC: should TYPE_MAX_VALUE/TYPE_MIN_VALUE be constrained by TYPE_PRECISION and TYPE_UNSIGNED? Then: "Second, for a given integer type (such as natural___XDLU_0_2147483647), the type for the nodes in TYPE_MIN_VALUE and TYPE_MAX_VALUE really should be a natural___XDLU_0_2147483647. ie, the type of an integer constant should be the same as the type of its min/max values." I think that one is new and again pertains to TYPE_MAX_VALUE/TYPE_MIN_VALUE. Clearly Ada stretches a lot more VRP than C-based languages because of its subtypes with non-canonical bounds. However, there always should be the base type at hand when things go awry; for example in int_fits_type_p /* If we haven't been able to decide at this point, there nothing more we can check ourselves here. Look at the base type if we have one and it has the same precision. */ if (TREE_CODE (type) == INTEGER_TYPE && TREE_TYPE (type) != 0 && TYPE_PRECISION (type) == TYPE_PRECISION (TREE_TYPE (type))) return int_fits_type_p (c, TREE_TYPE (type)); Richard, what do you think? -- Eric Botcazou
Re: Bootstrap failure on trunk: x86_64-linux-gnu
"Second, for a given integer type (such as natural___XDLU_0_2147483647), the type for the nodes in TYPE_MIN_VALUE and TYPE_MAX_VALUE really should be a natural___XDLU_0_2147483647. ie, the type of an integer constant should be the same as the type of its min/max values." No, the type of the bounds of a subtype should be the *base type*. That's how the tree has always looked, as far back as I can remember.
Re: [RFH] Fixing -fsection-anchors on powerpc-darwin
On Feb 19, 2006, at 4:26 AM, Richard Sandiford wrote:
Have you thought about overriding the output_anchor hook for Darwin?
It sounds simpler than what you did in the patch, and the hook was
there specifically for cases where the ASM_OUTPUT_DEF thing wouldn't
work.
That is a good idea, thanks. Forcing ASM_OUTPUT_DEF to be defined
was wrong for Darwin anyways as more failures come in.
Right. This is handled for ELF by:
/* Don't use anchors for mergeable sections. The linker might move
the objects around. */
sect = SYMBOL_REF_BLOCK (symbol)->sect;
if (sect->common.flags & SECTION_MERGE)
return false;
in default_use_anchor_for_symbol_p. If .cstring contains mergeable
data, it sounds like you should either (a) set SECTION_MERGE for it
or (b) override use_anchor_for_symbol_p for Darwin and check whether
SYMBOL_REF_BLOCK (symbol)->sect == cstring_section.
Oh, that is how to fix the issue and it works.
Now I run into another problem:
/Users/pinskia/src/gcc/local/gcc/objdir.objc/./prev-gcc/xgcc
-B/Users/pinskia/src/gcc/local/gcc/objdir.objc/./prev-gcc/
-B/Volumes/temp/gcc/local.objc/powerpc-apple-darwin7.9.0/bin/ -c -g
-O2 -mdynamic-no-pic -DIN_GCC -W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long
-Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition
-Wmissing-format-attribute -Werror -fno-common -DHAVE_CONFIG_H -I.
-I. -I/Users/pinskia/src/gcc/local/gcc/gcc
-I/Users/pinskia/src/gcc/local/gcc/gcc/.
-I/Users/pinskia/src/gcc/local/gcc/gcc/../include -I./../intl
-I/Users/pinskia/src/gcc/local/gcc/gcc/../libcpp/include
-I/Users/pinskia/src/gcc/local/gcc/gcc/../libdecnumber
-I../libdecnumber-I. -I. -I/Users/pinskia/src/gcc/local/gcc/gcc
-I/Users/pinskia/src/gcc/local/gcc/gcc/.
-I/Users/pinskia/src/gcc/local/gcc/gcc/../include -I./../intl
-I/Users/pinskia/src/gcc/local/gcc/gcc/../libcpp/include
-I/Users/pinskia/src/gcc/local/gcc/gcc/../libdecnumber
-I../libdecnumber
/Users/pinskia/src/gcc/local/gcc/gcc/config/host-darwin.c
/var/tmp//ccBWaqmT.s:130:Fixup of 1073745640 too large for field width
of 26 bits
/var/tmp//ccBWaqmT.s:119:Fixup of 1073745636 too large for field width
of 26 bits
/var/tmp//ccBWaqmT.s:104:Fixup of 1073745704 too large for field width
of 26 bits
/var/tmp//ccBWaqmT.s:94:Fixup of 1073745720 too large for field width
of 26 bits
/var/tmp//ccBWaqmT.s:73:Fixup of 1073745832 too large for field width
of 26 bits
/var/tmp//ccBWaqmT.s:42:Fixup of 1073745860 too large for field width
of 26 bits
Thanks,
Andrew Pinski
PS Attached is my current patch:
Index: config/darwin-protos.h
===
--- config/darwin-protos.h (revision 111255)
+++ config/darwin-protos.h (working copy)
@@ -80,3 +80,4 @@ extern void darwin_asm_output_dwarf_delt
const char *);
extern bool darwin_binds_local_p (tree);
extern void darwin_cpp_builtins (struct cpp_reader *);
+extern void darwin_asm_output_anchor (rtx symbol);
Index: config/darwin-sections.def
===
--- config/darwin-sections.def (revision 111255)
+++ config/darwin-sections.def (working copy)
@@ -11,9 +11,9 @@ DEF_SECTION (const_data_coal_section, 0,
".section __DATA,__const_coal,coalesced", 0)
DEF_SECTION (data_coal_section, SECTION_WRITE,
".section __DATA,__datacoal_nt,coalesced", 0)
-DEF_SECTION (cstring_section, 0, ".cstring", 0)
-DEF_SECTION (literal4_section, 0, ".literal4", 0)
-DEF_SECTION (literal8_section, 0, ".literal8", 0)
+DEF_SECTION (cstring_section, SECTION_MERGE, ".cstring", 0)
+DEF_SECTION (literal4_section, SECTION_MERGE, ".literal4", 0)
+DEF_SECTION (literal8_section, SECTION_MERGE, ".literal8", 0)
DEF_SECTION (constructor_section, 0, ".constructor", 0)
DEF_SECTION (mod_init_section, 0, ".mod_init_func", 0)
DEF_SECTION (mod_term_section, 0, ".mod_term_func", 0)
Index: config/darwin.c
===
--- config/darwin.c (revision 111255)
+++ config/darwin.c (working copy)
@@ -1479,4 +1479,17 @@ darwin_binds_local_p (tree decl)
return default_binds_local_p_1 (decl, 0);
}
+/* The Darwin's implementation of TARGET_ASM_OUTPUT_ANCHOR. Define the
+ anchor relative to ".", the current section position. We cannot use
+ the default one because ASM_OUTPUT_DEF is wrong for Darwin. */
+
+void
+darwin_asm_output_anchor (rtx symbol)
+{
+ fprintf (asm_out_file, "\t.set\t");
+ assemble_name (asm_out_file, XSTR (symbol, 0));
+ fprintf (asm_out_file, ", . + " HOST_WIDE_INT_PRINT_DEC "\n",
+ SYMBOL_REF_BLOCK_OFFSET (symbol));
+}
+
#include "gt-darwin.h"
Index: config/darwin.h
===
--- config/darwin.h (revision 111255)
+++ config/darwin.h (working copy)
@@ -792,6 +796,8 @@ enum machopic_addr_class {
Ada subtypes and base types (was: Bootstrap failure on trunk: x86_64-linux-gnu)
On Sun, 2006-02-19 at 14:23 -0500, Richard Kenner wrote: > "Second, for a given integer type (such as > natural___XDLU_0_2147483647), the type for the nodes in TYPE_MIN_VALUE > and TYPE_MAX_VALUE really should be a natural___XDLU_0_2147483647. > ie, the type of an integer constant should be the same as the type of > its min/max values." > > No, the type of the bounds of a subtype should be the *base type*. That's > how the tree has always looked, as far back as I can remember. This is because intermediate computations can produce results outside the subtype range but within the base type range (RM 3.5(6)), right? type T1 is range 0 .. 127; -- Compiler will choose some type for T'Base, likely to be -128..127 -- but could be Integer (implementation dependant) subtype T is T1 range 0 .. 100; R : T := 100+X-X; -- guaranteed work as long 100+X<=T'Base'Last and 100-X>=T'Base'First Laurent
Re: Ada subtypes and base types (was: Bootstrap failure on trunk: x86_64-linux-gnu)
> No, the type of the bounds of a subtype should be the *base type*. > That's how the tree has always looked, as far back as I can remember. This is because intermediate computations can produce results outside the subtype range but within the base type range (RM 3.5(6)), right? No. I'm pretty sure that convention predates the Ada front end by over a decade ...
Re: Ada subtypes and base types
Laurent GUERBY wrote: On Sun, 2006-02-19 at 14:23 -0500, Richard Kenner wrote: "Second, for a given integer type (such as natural___XDLU_0_2147483647), the type for the nodes in TYPE_MIN_VALUE and TYPE_MAX_VALUE really should be a natural___XDLU_0_2147483647. ie, the type of an integer constant should be the same as the type of its min/max values." No, the type of the bounds of a subtype should be the *base type*. That's how the tree has always looked, as far back as I can remember. This is because intermediate computations can produce results outside the subtype range but within the base type range (RM 3.5(6)), right? No, it is because this is the way the language is defined, what other type could the bounds of a subtype have? Clearly they are not of the subtype itself (that would be a nonsense recursion).
Re: [RFH] Fixing -fsection-anchors on powerpc-darwin
On Feb 19, 2006, at 2:39 PM, Andrew Pinski wrote: Now I run into another problem: /var/tmp//ccBWaqmT.s:130:Fixup of 1073745640 too large for field width of 26 bits We have a 1GB decl here. So the section that this decl goes into is between the TEXT section and the stub section which causes this error to happen. I am starting to think the Darwin back-end needs to be changed (or even linker too, I think Eric C. might be dealing with this but I don't know). Thanks, Andrew Pinski
Patch policy for branches
In the past, we've had a confusing situation for users, in which "upgrading" from one branch to another could result in known regressions. In particular, consider our current situation: * GCC 4.0.2 is the latest release on the 4.0 branch. * GCC 4.1 will be released soon. * GCC 4.0.3 will be released at some time in the future. Suppose that after GCC 4.1, we fix a bug, applying the fix to both the 4.0 and 4.1 branches. Then, we release GCC 4.0.3, before GCC 4.1.1. The result is then that a user who uses GCC 4.0.3, and upgrades to GCC 4.1.0, sees a regression for the bug in question. That seems confusing. We didn't use to have this problem because we use to have only one active release branch. However, for a while now, we've had at least two, and sometimes three, active release branches, responding to a demand from some users for longer lifetimes for our release branches. So, now we have the problem outlined above. The best solution I can think of is to synchronize releases across active branches so that GCC 4.0.3 and GCC 4.1.0 would be released simultaneously. The other option would be to postpone applying patches on the 4.0 branch until after a 4.1 release has been made with that patch applied, but that seems administratively difficult. As RM, I am willing to manage the releases of two active branches together. I've already announced that 4.0.3 would be released shortly after 4.1.0, so I think we can achieve near-simultaneous release of 4.0.3 with 4.1.0, and the 3.4.x branch is official dead at this point. However, assuming that Gaby plans to take over the 4.0.x branch (does he?), then I would need Gaby's buy-in to ensure simultaneity going forward. I'd also be interested in other feedback. The obvious negative with the proposed plan is that it means that more scarce resources (RM, testers, etc.) are required over a shorter period, rather than being spread across time. Thoughts? -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: Patch policy for branches
Mark Mitchell writes: > and the 3.4.x branch is official dead at this point. No, see http://gcc.gnu.org/ml/gcc/2005-12/msg00189.html Matthias
Re: very confused about single_set
Daniel Berlin wrote: > On Sun, 2006-02-19 at 09:56 -0500, Kenneth Zadeck wrote: > >> Steven, Zdenek >> >> 1) single_set is built on top of single_set2. >> > Yes > >> 2) single_set_2 uses REG_UNUSED notes. >> > Only if there are multiple sets. > > >> 3) tree-ssa-loop-ivops.c:seq_cost uses single_set. >> > > This is because Zdenek builds RTL to determine target costs. > > >> I can find no indication that rtl dfa is run here to provide the >> information for single_set to produce the correct answer. >> > > I don't understand what you mean. > Why does the DFA need to be run to produce the correct answer? > (Our ports use Deterministic Finite Automaton based schedulers, so > saying DFA is an ambiguous term at best) > > Or do you mean DataFlow Analysis, in which case, i'm sure everyone > expects the notes are always up to date (even though they may not be). > > > I was refering to the reg_unused notes not being there at all when this is called. You are correct that this is not so much a correctness issue as a place where the code is pessimistic. kenny
Re: Patch policy for branches
Matthias Klose wrote: > Mark Mitchell writes: >> and the 3.4.x branch is official dead at this point. > > No, see http://gcc.gnu.org/ml/gcc/2005-12/msg00189.html My mistake; thanks for the pointer. However, that doesn't change the general thrust of my mail; the only issue is how soon we must begin to coordinate. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: Patch policy for branches
Mark Mitchell <[EMAIL PROTECTED]> writes: > In the past, we've had a confusing situation for users, in which > "upgrading" from one branch to another could result in known > regressions. In particular, consider our current situation: > > * GCC 4.0.2 is the latest release on the 4.0 branch. > > * GCC 4.1 will be released soon. > > * GCC 4.0.3 will be released at some time in the future. > > Suppose that after GCC 4.1, we fix a bug, applying the fix to both the > 4.0 and 4.1 branches. Then, we release GCC 4.0.3, before GCC 4.1.1. > The result is then that a user who uses GCC 4.0.3, and upgrades to GCC > 4.1.0, sees a regression for the bug in question. That seems confusing. Did you really hear that many complaints that it's worth to take care of this? If we have a minor release of 4.1 every two month that means a time of less than two month where a user first updates to 4.0.3 and then to 4.1.0. I doubt that users update in that way so often that we have to take care of that. On the other hand, I know of users that have several branches installed to test both old and new compilers and those might get hit by this, Andreas -- Andreas Jaeger, [EMAIL PROTECTED], http://www.suse.de/~aj/ SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 pgporEtBkr5EG.pgp Description: PGP signature
re: Patch policy for branches
Some projects have a time-based release strategy (e.g. "we release once every six months"). Would it make sense for gcc to do that for all maintenance releases? e.g. leave the current process the same for .0 versions, which users are scared of anyway, but coordinate all other releases to occur once per quarter? -- Wine for Windows ISVs: http://kegel.com/wine/isv
Re: Patch policy for branches
On Sun, 19 Feb 2006, Mark Mitchell wrote: | Matthias Klose wrote: | > Mark Mitchell writes: | >> and the 3.4.x branch is official dead at this point. | > | > No, see http://gcc.gnu.org/ml/gcc/2005-12/msg00189.html | | My mistake; thanks for the pointer. | | However, that doesn't change the general thrust of my mail; the only | issue is how soon we must begin to coordinate. I agree. GCC-3.4.x is dead after 3.4.6, which is end of this month. So Mark's general point remains. -- Gaby
Re: Patch policy for branches
On Sun, 19 Feb 2006, Mark Mitchell wrote: | In the past, we've had a confusing situation for users, in which | "upgrading" from one branch to another could result in known | regressions. In particular, consider our current situation: | | * GCC 4.0.2 is the latest release on the 4.0 branch. | | * GCC 4.1 will be released soon. | | * GCC 4.0.3 will be released at some time in the future. | | Suppose that after GCC 4.1, we fix a bug, applying the fix to both the | 4.0 and 4.1 branches. Then, we release GCC 4.0.3, before GCC 4.1.1. | The result is then that a user who uses GCC 4.0.3, and upgrades to GCC | 4.1.0, sees a regression for the bug in question. That seems confusing. | | We didn't use to have this problem because we use to have only one | active release branch. However, for a while now, we've had at least | two, and sometimes three, active release branches, responding to a | demand from some users for longer lifetimes for our release branches. | So, now we have the problem outlined above. | | The best solution I can think of is to synchronize releases across | active branches so that GCC 4.0.3 and GCC 4.1.0 would be released | simultaneously. The other option would be to postpone applying patches | on the 4.0 branch until after a 4.1 release has been made with that | patch applied, but that seems administratively difficult. I agree with the last observation. | As RM, I am willing to manage the releases of two active branches | together. I've already announced that 4.0.3 would be released shortly | after 4.1.0, so I think we can achieve near-simultaneous release of | 4.0.3 with 4.1.0, and the 3.4.x branch is official dead at this point. | However, assuming that Gaby plans to take over the 4.0.x branch (does | he?), then I would need Gaby's buy-in to ensure simultaneity going forward. I agree with your general plan. I planned to release GCC-3.4.6 at the end of this month. So, I think we can proceed with for your outlined plan for GCC-4.0.x and upward. -- Gaby
Re: very confused about single_set
Hello, > 1) single_set is built on top of single_set2. > 2) single_set_2 uses REG_UNUSED notes. > 3) tree-ssa-loop-ivops.c:seq_cost uses single_set. > > I can find no indication that rtl dfa is run here to provide the > information for single_set to produce the correct answer. it is not. Nevertheless, the notes are only relevant for insns with more than one set, which are not common enough to care about them. (also, seq_cost will disappear soon). Zdenek
GCC 4.1.0 RC1
GCC 4.1.0 RC1 is here: ftp://gcc.gnu.org/pub/gcc/prerelease-4.1.0-20060219 Please download, build, and test. Please use these tarballs, rather than the current SVN branch, so that we test packaging, and other similar issues. If you find problems, please do not send me email directly; instead, file a bug in Bugzilla, and add me to the CC: list. Enjoy! -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
