Re: [rfc] mainline slush
> On Sat, May 21, 2005 at 12:16:27AM +0200, Eric Botcazou wrote: > > http://gcc.gnu.org/ml/gcc-testresults/2005-05/msg01339.html > > The vectorization failures still need to be fixed. Are these specific to SPARC? If so, I don't think development should be held off for them at this point. If not, platforms with real SIMD units are probably better testbeds. The struct-layout-1 failures in 64-bit mode are IMHO more annoying, but these tests are easy to break so I'm not really worried either. -- Eric Botcazou
A constant pool and addressing mode question
I'm porting GCC 4.0.1 to a new architecture. Its load/store instructions are similar to ARM's. The RTL is always generating a symbol_ref RTX to access a global variable, and the symbol_ref is an immediate which will be determined at the assembling/linking time. The addressing modes of my architecture didn't support the "direct addressing mode", that is, the syntax "load, " isn't allowed. I can only use the the two forms: "load, [#]" and "load, []". I cannot generate the following instructions if I have limited length of immediate field: mov, load, [#0] I noticed that the ARM's porting used the hook "TARGET_MACHINE_DEPENDENT_REORG" to solve it. It generated a "mini constant pool" in the proper location by computing the insn length attributes, and replaced the "ldr, " to "ldr, ". The mini constant pool looks like: .L3: .word .L4: .word ... And I has found the comment which is just before the implementation of the hook for a long time: /* Gcc puts the pool in the wrong place for ARM, since we can only load addresses a limited distance around the pc. We do some special munging to move the constant pool values to the correct point in the code. */ In my porting, I have no idea to let GCC to generate the constant pool with symbol names if I don't use the TARGET_MACHINE_DEPENDENT_REORG hook. (Currently, there are only string literal constant pools appeared in my porting.) So I cannot understand what the comment "Gcc puts the pool in the wrong place for ARM" means. I have three questions: 1. Could GCC generate the kind of constant pools which are contained symbol names by setting some target machine macros? (even if it was broken) 2. Are there any general soultions by telling GCC how far the load/store instruction could access? 3. In order to reduce the memory accessing operations, I want to use some special assmebly code syntax: movimr1, /highpart@ move MSB 16-bit of the symbol address to r1 [31..16] movil r1, /lowpart @ move LSB 16-bit of the symbol address to r1 [15..0] instead of the ARM's solution: ldr r1, .L3 ... .L3: .word Of course it should to modify the assembler/linker and loader. Is it a good idea? Thanks a lot.
Re: [rfc] mainline slush
On Sat, May 21, 2005 at 09:08:45AM +0200, Eric Botcazou wrote: > Are these specific to SPARC? No. r~
Re: [rfc] mainline slush
Eric Botcazou <[EMAIL PROTECTED]> writes: >> On Sat, May 21, 2005 at 12:16:27AM +0200, Eric Botcazou wrote: >> > http://gcc.gnu.org/ml/gcc-testresults/2005-05/msg01339.html >> >> The vectorization failures still need to be fixed. > > Are these specific to SPARC? If so, I don't think development should be held > off for them at this point. If not, platforms with real SIMD units are > probably better testbeds. Happen also on x86_64-linux-gnu, e.g.: http://gcc.gnu.org/ml/gcc-testresults/2005-05/msg01336.html === gcc tests === Running target unix FAIL: gcc.c-torture/execute/simd-1.c compilation, -O1 UNRESOLVED: gcc.c-torture/execute/simd-1.c execution, -O1 XPASS: gcc.dg/cpp/cmdlne-dI-M.c scan-file (^|n)cmdlne-dI-M.*:[^n]*cmdlne-dI-M.c XPASS: gcc.dg/cpp/cmdlne-dM-M.c scan-file (^|n)cmdlne-dM-M[^n]*:[^n]*cmdlne-dM-M.c XPASS: gcc.dg/uninit-9.c uninitialized variable warning (test for bogus messages, line 26) FAIL: gcc.dg/tree-ssa/gen-vect-11.c (test for excess errors) WARNING: gcc.dg/tree-ssa/gen-vect-11.c compilation failed to produce executable FAIL: gcc.dg/tree-ssa/gen-vect-11b.c (test for excess errors) WARNING: gcc.dg/tree-ssa/gen-vect-11b.c compilation failed to produce executable FAIL: gcc.dg/tree-ssa/gen-vect-11b.c scan-tree-dump-times vectorized 0 loops 1 FAIL: gcc.dg/tree-ssa/gen-vect-11c.c scan-tree-dump-times vectorized 0 loops 1 FAIL: gcc.dg/vect/pr18400.c (test for excess errors) WARNING: gcc.dg/vect/pr18400.c compilation failed to produce executable FAIL: gcc.dg/vect/vect-11a.c (test for excess errors) WARNING: gcc.dg/vect/vect-11a.c compilation failed to produce executable FAIL: gcc.dg/vect/vect-11a.c scan-tree-dump-times vectorized 1 loops 2 FAIL: gcc.dg/vect/vect-2.c (test for excess errors) WARNING: gcc.dg/vect/vect-2.c compilation failed to produce executable XPASS: gcc.dg/vect/vect-22.c scan-tree-dump-times vectorized 3 loops 1 FAIL: gcc.dg/vect/vect-34.c (test for excess errors) WARNING: gcc.dg/vect/vect-34.c compilation failed to produce executable FAIL: gcc.dg/vect/vect-66.c (test for excess errors) WARNING: gcc.dg/vect/vect-66.c compilation failed to produce executable XPASS: gcc.dg/vect/vect-67.c scan-tree-dump-times vectorized 1 loops 1 FAIL: gcc.dg/vect/vect-93.c (test for excess errors) WARNING: gcc.dg/vect/vect-93.c compilation failed to produce executable FAIL: gcc.dg/vect/vect-all.c (test for excess errors) WARNING: gcc.dg/vect/vect-all.c compilation failed to produce executable FAIL: gcc.dg/vect/vect-none.c scan-tree-dump-times vectorized 1 loops 1 And also powerpc64-linux-gnu http://gcc.gnu.org/ml/gcc-testresults/2005-05/msg01352.html: Running target unix/-m32 XPASS: gcc.c-torture/execute/20020720-1.c compilation, -O1 UNRESOLVED: gcc.c-torture/execute/20020720-1.c execution, -O2 UNRESOLVED: gcc.c-torture/execute/20020720-1.c execution, -O3 -fomit-frame-pointer UNRESOLVED: gcc.c-torture/execute/20020720-1.c execution, -O3 -g UNRESOLVED: gcc.c-torture/execute/20020720-1.c execution, -Os FAIL: gcc.dg/altivec-types-1.c (test for errors, line 87) FAIL: gcc.dg/altivec-types-1.c (test for excess errors) FAIL: gcc.dg/ppc-vec-merge.c (test for excess errors) WARNING: gcc.dg/ppc-vec-merge.c compilation failed to produce executable XPASS: gcc.dg/uninit-9.c uninitialized variable warning (test for bogus messages, line 26) FAIL: gcc.dg/pch/inline-4.c -O0 -g (test for excess errors) FAIL: gcc.dg/pch/inline-4.c -O0 (test for excess errors) FAIL: gcc.dg/vect/pr18400.c (test for excess errors) FAIL: gcc.dg/vect/vect-11a.c (test for excess errors) FAIL: gcc.dg/vect/vect-11a.c scan-tree-dump-times vectorized 1 loops 2 FAIL: gcc.dg/vect/vect-2.c (test for excess errors) FAIL: gcc.dg/vect/vect-34.c (test for excess errors) FAIL: gcc.dg/vect/vect-66.c (test for excess errors) XPASS: gcc.dg/vect/vect-67.c scan-tree-dump-times vectorized 1 loops 1 FAIL: gcc.dg/vect/vect-93.c (test for excess errors) FAIL: gcc.dg/vect/vect-all.c (test for excess errors) FAIL: gcc.dg/vect/vect-shift-1.c (test for excess errors) The errors I'm seeing are: FAIL: gcc.dg/vect/pr18400.c (test for excess errors) Excess errors: /cvs/gcc/gcc/testsuite/gcc.dg/vect/pr18400.c:9: internal compiler error: tree ch eck: expected ssa_name, have var_decl in verify_ssa, at tree-ssa.c:750 WARNING: gcc.dg/vect/pr18400.c compilation failed to produce executable 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 pgpWXxcCHl39R.pgp Description: PGP signature
Re: [rfc] mainline slush
> The struct-layout-1 failures in 64-bit mode are IMHO more annoying, but
> these tests are easy to break so I'm not really worried either.
Huh, I was wrong, they are quite problematic. Testcase attached.
We have as initial RTL:
(insn 35 34 36 1 (set (mem/i:TF (plus:DI (reg/f:DI 103 virtual-stack-vars)
(const_int -5120 [0xec00])) [0 S16 A128])
(reg:TF 110 [ D.1221 ])) -1 (nil)
(nil))
and instantiate_virtual_regs_in_insn invokes extract_insn on it. Previously
the instantiate_virtual_regs machinery (instantiate_virtual_regs_1) would
have detected that the insn is not valid.
--
Eric Botcazou
struct S1132 {
struct{
unsigned long int b;
struct{void * d[7];}c[30];
}a[3];
char e:8) - 1) & 7) + 1);
struct{}f;
};
extern int fails;
void check1132va (int z, ...)
{
struct S1132 arg;
long double ld;
__builtin_va_list ap;
__builtin_va_start (ap, z);
if (__builtin_va_arg (ap, long double) != 2.0L)
++fails;
__builtin_va_end (ap);
}
Re: [rfc] mainline slush
> On Sat, May 21, 2005 at 09:08:45AM +0200, Eric Botcazou wrote: > > Are these specific to SPARC? > > No. I believe Andrew mentioned that there is a patch for this? (it is lack of sync in between operands and stmt itself) Honza > > > r~
[PR21029] [4.1 Regression] vrp miscompiles Ada front-end, ping...
Is there any progress in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21029 ? -- Cheers, /ChJ
RE: libgcc_s.so.1 exception handling behaviour depending on glibc version
On Fri, 20 May 2005 19:24:07 +0100, Dave Korn wrote: > Absolutely so, no problem Absolutely not, there will be lots of problems. This whole thread is about how you *can't* just do that. Your app still won't run on older systems (reliably) even if you target old APIs and use dlopen for the rest. That's the bit which is unintuitive, unexpected and should be (IMHO) fixed :) thanks -mike
RE: C99 implies -Wimplicit-function-declaration?
On Fri, 20 May 2005, Gary Funck wrote: > OK, thanks. I (now) understand that the reference to a warning about a > missing protoype > does not apply. However, I don't see anything in section 6.5.2.2 > (rev. 1999-12-01) that says that a function declaration or prototype > declaration must (or should) precede a call to the function. And GCC isn't > treating it That's because it's 6.5.1 paragraph 2: only declared identifiers are valid in expressions. > as an error, but rather is enabling the warning by default. Because C90 permitted this, we guess what you meant. However, by choosing C99 mode you're giving a strong indication that you should not be using any feature removed in C99, so we warn, or give an error with -pedantic-errors. -- Joseph S. Myers http://www.srcf.ucam.org/~jsm28/gcc/ [EMAIL PROTECTED] (personal mail) [EMAIL PROTECTED] (CodeSourcery mail) [EMAIL PROTECTED] (Bugzilla assignments and CCs)
Re: GCC 4.1: Buildable on GHz machines only?
[EMAIL PROTECTED] (Peter Barada) wrote on 17.05.05 in <[EMAIL PROTECTED]>: > Its a 266Mhz ColdFire v4e machine, about 263 BogoMips, 1/20 the > BogoMips of my workstation, and with an NFS rootfs, it gets network BogoMips are called BogoMips because they are not comparable among different CPUs. All they measure is how often the CPU needs to run a particular near-empty loop to delay a certain time. There usually is a small factor which can convert between BogoMips and CPU MHz for every CPU model. It would seem to be 1 for your ColdFire; it happens to be 1/2 for my Athlon (bogomips: 2287.20, cpu MHz: 1145.142). Comparisions like yours are worse than meaningless. MfG Kai
Re: GCC 4.1: Buildable on GHz machines only?
>> Its a 266Mhz ColdFire v4e machine, about 263 BogoMips, 1/20 the >> BogoMips of my workstation, and with an NFS rootfs, it gets network > >BogoMips are called BogoMips because they are not comparable among >different CPUs. All they measure is how often the CPU needs to run a >particular near-empty loop to delay a certain time. I know exactly what a BogoMips is. >There usually is a small factor which can convert between BogoMips and CPU >MHz for every CPU model. It would seem to be 1 for your ColdFire; it >happens to be 1/2 for my Athlon (bogomips: 2287.20, cpu MHz: 1145.142). > >Comparisions like yours are worse than meaningless. I wouldn't call it meaningless. I don't have other benchmark numbers for the chip, and it was menat to show that it isn't a blazingly fast processor (as compared to desktop machines). -- Peter Barada [EMAIL PROTECTED]
basic-block and tree statement iterator enums
Hi,
I've been pushing, locally, the compilation of GCC sources with g++.
So far, I've gotten past libiberty, fixincludes, libcpp, the C
front-end specific files, RTL files with no much pain. However, the
files tree-* and associated headers seem to be the most resolutely C++
unfriendly (I guess I would have to change that judgment when I come
to some files in cp/ ;-)).
My first attempt this morning met:
/home/gdr/redhat/libcpp.gcc/gcc/tree-cfg.c: In function 'void
bsi_insert_before(block_stmt_iterator*, tree_node*, bsi_iterator_update)':
/home/gdr/redhat/libcpp.gcc/gcc/tree-cfg.c:2935: error: cannot convert
'bsi_iterator_update' to 'tsi_iterator_update' for argument '3' to
'void tsi_link_before(tree_stmt_iterator*, tree_node*, tsi_iterator_update)'
The fragment in question is:
void
bsi_insert_before (block_stmt_iterator *i, tree t, enum bsi_iterator_update m)
{
set_bb_for_stmt (t, i->bb);
update_modified_stmts (t);
tsi_link_before (&i->tsi, t, m); // <=== HERE
}
Now, tsi_link_before() is declared to take "enum tsi_iterator_update" as
its third argument, so this is really a type violation or at least
looks very suspicious. Chasing the definitions of both enums, I found
/* (from tree-flow.h) */
enum bsi_iterator_update
{
/* Note that these are intentionally in the same order as TSI_FOO. They
mean exactly the same as their TSI_* counterparts. */
BSI_NEW_STMT,
BSI_SAME_STMT,
BSI_CHAIN_START,
BSI_CHAIN_END,
BSI_CONTINUE_LINKING
};
/* from tree-iterator.h */
enum tsi_iterator_update
{
TSI_NEW_STMT, /* Leave the iterator at the same statement. */
TSI_SAME_STMT,/* Only valid when single statement is added, move
iterator to it. */
TSI_CHAIN_START, /* Only valid when chain of statements is added, move
iterator to the first statement in the chain. */
TSI_CHAIN_END,/* Only valid when chain of statements is added, move
iterator to the last statement in the chain. */
TSI_CONTINUE_LINKING /* Move iterator to whatever position is suitable for
linking other statements/chains of statements in
the same direction. */
};
So, both enums are pretty similar, except for the names (of the type
and constants).
Is there any particular reason why we cannot have just *one*
"iterator_update" enum, instead of two, and we have to cheat?
This duplication does not look to me like good thing we want to
have. What am I overlooking?
-- Gaby
tree ssa and type issues
Hi again, I just hit this one from tree-ssa-into.c:rewrite_into_ssa() /* Initialize dominance frontier. */ dfs = (bitmap *) xmalloc (last_basic_block * sizeof (bitmap *)); If the sizeof operand really supposed to be "bitmap*" and not "bitmap"? -- Gaby
Re: tree ssa and type issues
Gabriel Dos Reis <[EMAIL PROTECTED]> writes: > Hi again, > > I just hit this one from tree-ssa-into.c:rewrite_into_ssa() > > /* Initialize dominance frontier. */ > dfs = (bitmap *) xmalloc (last_basic_block * sizeof (bitmap *)); > > > If the sizeof operand really supposed to be "bitmap*" and not "bitmap"? This indeed looks wrong - and could lead to real memory corruption :-(. If this is wrong, he should be changed on the 4.0 branch as well, Seems your C++ project is indeed usefull ;-) 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 pgp9Gv6U7xhUr.pgp Description: PGP signature
Re: tree ssa and type issues
Andreas Jaeger <[EMAIL PROTECTED]> writes: | Gabriel Dos Reis <[EMAIL PROTECTED]> writes: | | > Hi again, | > | > I just hit this one from tree-ssa-into.c:rewrite_into_ssa() | > | > /* Initialize dominance frontier. */ | > dfs = (bitmap *) xmalloc (last_basic_block * sizeof (bitmap *)); | > | > | > If the sizeof operand really supposed to be "bitmap*" and not "bitmap"? | | This indeed looks wrong - and could lead to real memory corruption | :-(. If this is wrong, he should be changed on the 4.0 branch as | well, And if it is wrong, it would be interesting to know wheter we already have PRs related to that memory corruption -- but I guess it would be hard to know :-) Parenthetically, I was wondering who is freeing those extensive regions of storage xmalloc/xcalloc()ed here and there? -- Gaby
Re: tree ssa and type issues
Gabriel Dos Reis <[EMAIL PROTECTED]> writes: > Andreas Jaeger <[EMAIL PROTECTED]> writes: > > | Gabriel Dos Reis <[EMAIL PROTECTED]> writes: > | > | > Hi again, > | > > | > I just hit this one from tree-ssa-into.c:rewrite_into_ssa() Note update_ssa has the same problem. > | > > | > /* Initialize dominance frontier. */ > | > dfs = (bitmap *) xmalloc (last_basic_block * sizeof (bitmap *)); > | > > | > > | > If the sizeof operand really supposed to be "bitmap*" and not "bitmap"? > | > | This indeed looks wrong - and could lead to real memory corruption > | :-(. If this is wrong, he should be changed on the 4.0 branch as > | well, > > And if it is wrong, it would be interesting to know wheter we already > have PRs related to that memory corruption -- but I guess it would be > hard to know :-) Yeah. > Parenthetically, I was wondering who is freeing those extensive > regions of storage xmalloc/xcalloc()ed here and there? I went through the file (btw. it's named tree-into-ssa.c) and it does not look that bad. I could not find a place which is obviously wrong. Looking at rewrite_into_ssa I see: interesting_blocks = sbitmap_alloc (last_basic_block); dfs = (bitmap *) xmalloc (last_basic_block * sizeof (bitmap *)); FOR_EACH_BB (bb) dfs[bb->index] = BITMAP_ALLOC (NULL); [...] /* Free allocated memory. */ FOR_EACH_BB (bb) BITMAP_FREE (dfs[bb->index]); free (dfs); sbitmap_free (interesting_blocks); So, this does look fine, 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 pgp8bWMWVmwy1.pgp Description: PGP signature
Re: [rfc] mainline slush
On Sat, May 21, 2005 at 10:59:44AM +0200, Jan Hubicka wrote: > I believe Andrew mentioned that there is a patch for this? (it is lack > of sync in between operands and stmt itself) The last state I saw is that the patch needed some minor updates. I was hoping that one of the original authors would take care of that, but ... r~
Problem in assembly and linking(gcc-4.0)
Hi I am working on gcc-4.0. I have edited some files in code and the remaking of gcc works well, and even files compile with it. But when i try to run a compiled program it gives segmentaion fault. I checked that assembly code produced is fine and i just compiled file to file.s and then assembled and linked it using standard commands in unix, as : gcc -S file.c as -o file.o file.s ld -o exefile file.o /usr/lib/crt1.o /usr/lib/crti.o -lc /usr/lib/crtn.o -dynamic /lib/ld-linux.so.2 The executable produced above works fine. This would mean that there is some problem occuring while assembling or linking in regualr commands used by gcc. is there a solution for this ? Regards. Virender
Re: tree ssa and type issues
> "Gabriel" == Gabriel Dos Reis <[EMAIL PROTECTED]> writes: Gabriel> I just hit this one from tree-ssa-into.c:rewrite_into_ssa() Gabriel> /* Initialize dominance frontier. */ Gabriel> dfs = (bitmap *) xmalloc (last_basic_block * sizeof (bitmap *)); Gabriel> Maybe we should be using the XNEWVEC macro (libiberty.h) everywhere. That would avoid this problem. How did you catch this btw? (If gcc or g++ warns about this, it is cool news... and if it doesn't, wouldn't that be nice?) Tom
Re: tree ssa and type issues
On Sat, 2005-05-21 at 18:55 +0200, Andreas Jaeger wrote: > Gabriel Dos Reis <[EMAIL PROTECTED]> writes: > > > Hi again, > > > > I just hit this one from tree-ssa-into.c:rewrite_into_ssa() > > > > /* Initialize dominance frontier. */ > > dfs = (bitmap *) xmalloc (last_basic_block * sizeof (bitmap *)); > > > > > > If the sizeof operand really supposed to be "bitmap*" and not "bitmap"? > > This indeed looks wrong - and could lead to real memory corruption > :-(. If this is wrong, he should be changed on the 4.0 branch as > well, It's wrong, but it couldn't lead to actual memory corruption, since sizeof (bitmap) == sizeof (bitmap *), since both are pointers.
Re: tree ssa and type issues
On Sat, 2005-05-21 at 20:33 +0200, Gabriel Dos Reis wrote: > Andreas Jaeger <[EMAIL PROTECTED]> writes: > > | Gabriel Dos Reis <[EMAIL PROTECTED]> writes: > | > | > Hi again, > | > > | > I just hit this one from tree-ssa-into.c:rewrite_into_ssa() > | > > | > /* Initialize dominance frontier. */ > | > dfs = (bitmap *) xmalloc (last_basic_block * sizeof (bitmap *)); > | > > | > > | > If the sizeof operand really supposed to be "bitmap*" and not "bitmap"? > | > | This indeed looks wrong - and could lead to real memory corruption > | :-(. If this is wrong, he should be changed on the 4.0 branch as > | well, > > And if it is wrong, it would be interesting to know wheter we already > have PRs related to that memory corruption -- but I guess it would be > hard to know :-) Again, it won't corrupt memory, because sizeof (bitmap *) == sizeof (bitmap), though it is still wrong. > > Parenthetically, I was wondering who is freeing those extensive > regions of storage xmalloc/xcalloc()ed here and there? 1. The people who write the code to do the xmalloc'ing. 2. Every couple of months, people run gcc through valgrind with leak checking on to make sure we arne't leaking the xmalloc'd memory.
Re: tree ssa and type issues
Tom Tromey <[EMAIL PROTECTED]> writes: | > "Gabriel" == Gabriel Dos Reis <[EMAIL PROTECTED]> writes: | | Gabriel> I just hit this one from tree-ssa-into.c:rewrite_into_ssa() | Gabriel> /* Initialize dominance frontier. */ | Gabriel> dfs = (bitmap *) xmalloc (last_basic_block * sizeof (bitmap *)); | Gabriel> | | Maybe we should be using the XNEWVEC macro (libiberty.h) everywhere. | That would avoid this problem. Absolutely. | | How did you catch this btw? (If gcc or g++ warns about this, it is | cool news... and if it doesn't, wouldn't that be nice?) The way I got it was simple: I just grepped for xmalloc/xcalloc in tree-* (most of them rely on implicit void * -> T* which C++ does not like) and was going to replace them with XNEWVEC/XCNEWVEC and my eyes could not parse that line :-) No, gcc/g++ -- unfortunately -- cannot catch such things. Yes, it would be nice (e.g. useful), if it could warn about them. I think it is a common mistake. Of source if works only for syntactic construct like (T) allocate (sizeof (U)) or (T) allocate (n * sizeof (U)) where T are not equivalent. But, I guess that would already be an improvement. -- Gaby
Re: tree ssa and type issues
Daniel Berlin <[EMAIL PROTECTED]> writes: | On Sat, 2005-05-21 at 18:55 +0200, Andreas Jaeger wrote: | > Gabriel Dos Reis <[EMAIL PROTECTED]> writes: | > | > > Hi again, | > > | > > I just hit this one from tree-ssa-into.c:rewrite_into_ssa() | > > | > > /* Initialize dominance frontier. */ | > > dfs = (bitmap *) xmalloc (last_basic_block * sizeof (bitmap *)); | > > | > > | > > If the sizeof operand really supposed to be "bitmap*" and not "bitmap"? | > | > This indeed looks wrong - and could lead to real memory corruption | > :-(. If this is wrong, he should be changed on the 4.0 branch as | > well, | | It's wrong, but it couldn't lead to actual memory corruption, since | sizeof (bitmap) == sizeof (bitmap *), since both are pointers. Aha. This the second time, I'm hitting something like this. The first one was with libiberty/argv.c:dupargv() a month ago. -- Gaby
Re: tree ssa and type issues
Daniel Berlin <[EMAIL PROTECTED]> writes: [...] | > Parenthetically, I was wondering who is freeing those extensive | > regions of storage xmalloc/xcalloc()ed here and there? | | 1. The people who write the code to do the xmalloc'ing. | 2. Every couple of months, people run gcc through valgrind with leak | checking on to make sure we arne't leaking the xmalloc'd memory. If all memory is realized at the end of program, then obviously there is no leak, but that is not what I was looking for. But, it is nice to know that people run GCC through valgrind every couple of months. Do you know whether the have the resulst publically available somewhere? -- Gaby
Re: [rfc] mainline slush
On Sat, May 21, 2005 at 10:46:19AM +0200, Eric Botcazou wrote: > We have as initial RTL: > > (insn 35 34 36 1 (set (mem/i:TF (plus:DI (reg/f:DI 103 virtual-stack-vars) > (const_int -5120 [0xec00])) [0 S16 A128]) > (reg:TF 110 [ D.1221 ])) -1 (nil) > (nil)) > > and instantiate_virtual_regs_in_insn invokes extract_insn on it. Previously > the instantiate_virtual_regs machinery (instantiate_virtual_regs_1) would > have detected that the insn is not valid. The new implementation of instantiate_virtual_regs requires that the insn be valid *before* instantiation. When you see something like this it means there's a bug in the rtl expanders. The bug is in sparc_emit_float_lib_cmp, 5807 slot0 = assign_stack_temp (TFmode, GET_MODE_SIZE(TFmode), 0); 5808 emit_insn (gen_rtx_SET (VOIDmode, slot0, x)); You have to call validize_mem there. r~
Re: tree ssa and type issues
On Sat, 2005-05-21 at 22:00 +0200, Gabriel Dos Reis wrote: > Daniel Berlin <[EMAIL PROTECTED]> writes: > > [...] > > | > Parenthetically, I was wondering who is freeing those extensive > | > regions of storage xmalloc/xcalloc()ed here and there? > | > | 1. The people who write the code to do the xmalloc'ing. > | 2. Every couple of months, people run gcc through valgrind with leak > | checking on to make sure we arne't leaking the xmalloc'd memory. > > If all memory is realized at the end of program, then obviously there > is no leak, but that is not what I was looking for. Then what are you looking for? Some of the xmalloc's are hidden behind things like pool_alloc and pool_free, which internally use xmalloc/free, etc. > > But, it is nice to know that people run GCC through valgrind every > couple of months. You can even use valgrind during bootstrap to verify even the gc'd memory is being used properly. --enable-checking=valgrind It should work for both the zone and page collectors (I know Daniel J. was using it with zone to verify the zone collector was working properly) > Do you know whether the have the resulst publically > available somewhere? No, i don't think anyone takes the extra effort to try to set up a web page. > > -- Gaby
Re: [rfc] mainline slush
> The new implementation of instantiate_virtual_regs requires that the > insn be valid *before* instantiation. I see. I didn't find it written anywhere so I thought I should ask. > The bug is in sparc_emit_float_lib_cmp, > > 5807 slot0 = assign_stack_temp (TFmode, GET_MODE_SIZE(TFmode), > 0); 5808 emit_insn (gen_rtx_SET (VOIDmode, slot0, x)); > > You have to call validize_mem there. emit_move_insn should work fine too. Thanks for the tip. Btw, is it me or the individual RTL dump options are broken? [EMAIL PROTECTED]:~/build/gcc/sparc64-sun-solaris2.9> gcc/xgcc -Bgcc -S t007_y.c -dr cc1: warning: unrecognized gcc debugging option: r [EMAIL PROTECTED]:~/build/gcc/sparc64-sun-solaris2.9> gcc/xgcc -Bgcc -S t007_y.c -fdump-rtl-expand cc1: error: unrecognized command line option "-fdump-rtl-expand" -- Eric Botcazou
Re: tree ssa and type issues
Daniel Berlin <[EMAIL PROTECTED]> writes: | On Sat, 2005-05-21 at 22:00 +0200, Gabriel Dos Reis wrote: | > Daniel Berlin <[EMAIL PROTECTED]> writes: | > | > [...] | > | > | > Parenthetically, I was wondering who is freeing those extensive | > | > regions of storage xmalloc/xcalloc()ed here and there? | > | | > | 1. The people who write the code to do the xmalloc'ing. | > | 2. Every couple of months, people run gcc through valgrind with leak | > | checking on to make sure we arne't leaking the xmalloc'd memory. | > | > If all memory is realized at the end of program, then obviously there | > is no leak, but that is not what I was looking for. | | Then what are you looking for? [ A useful answer ;-) ] where the storage is returned/reused as soon as done, as opposed to waiting for the end of the compilation. [...] | > Do you know whether the have the resulst publically | > available somewhere? | No, i don't think anyone takes the extra effort to try to set up a web | page. Thanks, -- Gaby
Re: tree ssa and type issues
On Sat, 2005-05-21 at 22:59 +0200, Gabriel Dos Reis wrote: > Daniel Berlin <[EMAIL PROTECTED]> writes: > > | On Sat, 2005-05-21 at 22:00 +0200, Gabriel Dos Reis wrote: > | > Daniel Berlin <[EMAIL PROTECTED]> writes: > | > > | > [...] > | > > | > | > Parenthetically, I was wondering who is freeing those extensive > | > | > regions of storage xmalloc/xcalloc()ed here and there? > | > | > | > | 1. The people who write the code to do the xmalloc'ing. > | > | 2. Every couple of months, people run gcc through valgrind with leak > | > | checking on to make sure we arne't leaking the xmalloc'd memory. > | > > | > If all memory is realized at the end of program, then obviously there > | > is no leak, but that is not what I was looking for. > | > | Then what are you looking for? > > [ A useful answer ;-) ] > > where the storage is returned/reused as soon as done, as opposed to > waiting for the end of the compilation. Uh, nobody waits for the end of compilation to free their xmalloc'd things. > > [...] > > | > Do you know whether the have the resulst publically > | > available somewhere? > | No, i don't think anyone takes the extra effort to try to set up a web > | page. > > Thanks, > > -- Gaby
Re: [rfc] mainline slush
On Sat, May 21, 2005 at 09:45:38PM +0200, Eric Botcazou wrote: > Btw, is it me or the individual RTL dump options are broken? The initial rtl dump is broken. The rest work. I think one of Jan's IPA pass manager changes broke it. r~
Re: tree ssa and type issues
On Saturday 21 May 2005 22:15, Daniel Berlin wrote: > > where the storage is returned/reused as soon as done, as opposed to > > waiting for the end of the compilation. > > Uh, nobody waits for the end of compilation to free their xmalloc'd > things. Except the alloc pools of et-forest :-) Gr. Steven
Spread snapshot building more evenly throughout the week
I just applied the following patch and will update the gccadmin account on gcc.gnu.org after tomorrow's snapshot of GCC 4.1 has been made. (The new schedule is more in line what we originally had.) Gerald 2005-05-21 Gerald Pfeifer <[EMAIL PROTECTED]> * crontab: Spread snapshot building more evenly throughout the week. Index: crontab === RCS file: /cvs/gcc/gcc/maintainer-scripts/crontab,v retrieving revision 1.14 diff -u -3 -p -r1.14 crontab --- crontab 19 May 2005 00:33:47 - 1.14 +++ crontab 21 May 2005 21:55:14 - @@ -1,6 +1,6 @@ 16 0 * * * sh /home/gccadmin/scripts/update_version 50 0 * * * sh /home/gccadmin/scripts/update_web_docs 55 0 * * * sh /home/gccadmin/scripts/update_web_docs_libstdcxx -32 22 * * 5 sh /home/gccadmin/scripts/gcc_release -s 3.4:gcc-3_4-branch -l -d /sourceware/snapshot-tmp/gcc all -32 22 * * 6 sh /home/gccadmin/scripts/gcc_release -s 4.0:gcc-4_0-branch -l -d /sourceware/snapshot-tmp/gcc all -43 17 * * 7 sh /home/gccadmin/scripts/gcc_release -s 4.1:HEAD -l -d /sourceware/snapshot-tmp/gcc all +32 22 * * 2 sh /home/gccadmin/scripts/gcc_release -s 3.4:gcc-3_4-branch -l -d /sourceware/snapshot-tmp/gcc all +32 22 * * 4 sh /home/gccadmin/scripts/gcc_release -s 4.0:gcc-4_0-branch -l -d /sourceware/snapshot-tmp/gcc all +43 17 * * 6 sh /home/gccadmin/scripts/gcc_release -s 4.1:HEAD -l -d /sourceware/snapshot-tmp/gcc all
gcc.gnu.org/releases.html
Hi, the GCC Timeline doesn't seem ok: a wide 'internal version' field and 4.0.0 completely missing. Is this a known issue? Thanks, Paolo.
Re: [rfc] mainline slush
> On Sat, May 21, 2005 at 09:45:38PM +0200, Eric Botcazou wrote: > > Btw, is it me or the individual RTL dump options are broken? > > The initial rtl dump is broken. The rest work. > > I think one of Jan's IPA pass manager changes broke it. What are the symptoms? -fdump-tree-expand seems to work fine for me as does -d (not sure of -fdump-rtl-expand ever worked, but I might try to restore it if it did). Honza > > > r~
Re: gcc.gnu.org/releases.html
On Sun, 22 May 2005, Paolo Carlini wrote: > the GCC Timeline doesn't seem ok: a wide 'internal version' field and > 4.0.0 completely missing. Is this a known issue? I'll see what I can do about the formatting, but the missing release is a feature (so that our release managers do not have to perform that many manual steps during the process). That's why the page states: Please refer to our development plan for releases past 4.0.0 and future releases. Gerald
Some questions about FIELD_DECL
While moving FIELD_DECL to it's own substruct, the following questions have come up. I figured one of you might know: 1. Do we need DECL_ASSEMBLER_NAME on FIELD_DECL? I can't think of a place where we would actually try to *output* a FIELD_DECL directly, but maybe i've missed something. I ask because the C frontend tests decl_assembler_name on field decl, but never sets it on them. Related to this: 2. Do we allow setting the section of a FIELD_DECL, so that DECL_SECTION_NAME on FIELD_DECL is necessary?
Re: gcc.gnu.org/releases.html
Gerald Pfeifer wrote: >I'll see what I can do about the formatting, > Thanks! > but the missing release >is a feature (so that our release managers do not have to perform that >many manual steps during the process). > >That's why the page states: > > Please refer to our development plan for releases past 4.0.0 and future > releases. > > Yes ;) noticed in the meanwhile... Maybe you may want to have a look to web/21679 too, anyway, I think Dave Abrahams has a point. Paolo.
Re: gcc.gnu.org/releases.html
On Sun, 22 May 2005, Paolo Carlini wrote: >> I'll see what I can do about the formatting, > Thanks! I installed the following patch. Gerald Streamline the reference to our binaries page. Remove references to egcs internal version numbers. Index: releases.html === RCS file: /cvs/gcc/wwwdocs/htdocs/releases.html,v retrieving revision 1.56 retrieving revision 1.58 diff -u -3 -p -r1.56 -r1.58 --- releases.html 20 May 2005 20:48:54 - 1.56 +++ releases.html 21 May 2005 22:57:44 - 1.58 @@ -14,11 +14,9 @@ Important: because these are source releases, they will be of little use to you if you do not already have a C compiler on your machine. If you don't already have a compiler, you need pre-compiled -binaries. - -To find pre-compiled binaries for various platforms, please -refer to our http://gcc.gnu.org/install/binaries.html";>binaries -page. +binaries. +Our http://gcc.gnu.org/install/binaries.html";>binaries page +has references to pre-compiled binaries for various platforms. You can also retrieve the current development sources using CVS. @@ -29,14 +27,8 @@ page. for releases past 4.0.0 and future releases. -Releaseinternal versionRelease date -GCC 3.4.4 - -The egcs project maintained two kinds of version numbers. One was of the -form 2.9x.yy and indicated the relationship between the GCC sources and -the egcs sources; the other version number identified egcs releases (as -opposed to development snapshots). -May 18, 2005 +ReleaseRelease date +GCC 3.4.4 May 18, 2005 GCC 3.4.3 November 4, 2004 GCC 3.4.2 September 6, 2004 GCC 3.4.1 July 1, 2004 @@ -64,18 +56,18 @@ opposed to development snapshots). GCC 2.95.1 August 19, 1999 GCC 2.95 July 31, 1999 -EGCS 1.1.22.91.66March 15, 1999 -EGCS 1.1.12.91.60December 1, 1998 -EGCS 1.12.91.57September 3, 1998 +EGCS 1.1.2 March 15, 1999 +EGCS 1.1.1 December 1, 1998 +EGCS 1.1 September 3, 1998 -EGCS 1.0.32.90.29May 15, 1998 -EGCS 1.0.22.90.27March 16, 1998 +EGCS 1.0.3May 15, 1998 +EGCS 1.0.2March 16, 1998 -gcc 2.8.1 March 2, 1998 -gcc 2.8.0 January 7, 1998 +gcc 2.8.1 March 2, 1998 +gcc 2.8.0 January 7, 1998 -EGCS 1.0.12.90.23January 6, 1998 -EGCS 1.02.90.21December 3, 1997 +EGCS 1.0.1January 6, 1998 +EGCS 1.0December 3, 1997
Re: Some questions about FIELD_DECL
Daniel Berlin <[EMAIL PROTECTED]> writes:
| While moving FIELD_DECL to it's own substruct, the following questions
| have come up. I figured one of you might know:
|
| 1. Do we need DECL_ASSEMBLER_NAME on FIELD_DECL? I can't think of a
| place where we would actually try to *output* a FIELD_DECL directly, but
| maybe i've missed something. I ask because the C frontend tests
| decl_assembler_name on field decl, but never sets it on them.
What happens when you have this (in C++)
namespace foo {
union {
int baz;
double foobar;
} bar;
};
?
-- Gaby
Re: [rfc] mainline slush
On Sunday 22 May 2005 00:16, Jan Hubicka wrote: > (not sure of -fdump-rtl-expand ever worked, but I > might try to restore it if it did). It very definitely did work, and quite nicely too. Try -fdump-rtl-expand-details. Gr. Steven
[wwwdocs] make release download more prominent (was: gcc.gnu.org/releases.html)
On Sun, 22 May 2005, Paolo Carlini wrote: > Maybe you may want to have a look to web/21679 too, anyway, I think Dave > Abrahams has a point. I installed the patch below. If this is not sufficient, we could consider creating a download page of its own, though this would add yet another level of indirection in many cases. Having a selectable list of releases which lead to a download site for that *particular* release seems beyond what we can do with acceptable effort. Gerald Make "Download" a section of its own on the releases.html page. Index: releases.html === RCS file: /cvs/gcc/wwwdocs/htdocs/releases.html,v retrieving revision 1.58 diff -u -3 -p -r1.58 releases.html --- releases.html 21 May 2005 22:57:44 - 1.58 +++ releases.html 21 May 2005 23:16:39 - @@ -8,6 +8,8 @@ GCC Releases +Download + Source code for GCC releases may be downloaded from our mirror sites. @@ -21,6 +23,7 @@ has references to pre-compiled binaries You can also retrieve the current development sources using CVS. + GCC Timeline Please refer to our development plan Index: style.mhtml === RCS file: /cvs/gcc/wwwdocs/htdocs/style.mhtml,v retrieving revision 1.78 diff -u -3 -p -r1.78 style.mhtml --- style.mhtml 16 May 2005 22:23:44 - 1.78 +++ style.mhtml 21 May 2005 23:16:42 - @@ -206,7 +206,7 @@ > - Releases + Releases Snapshots Mirror sites http://gcc.gnu.org/install/binaries.html";>Binaries
Re: Some questions about FIELD_DECL
On Sun, 2005-05-22 at 02:14 +0200, Gabriel Dos Reis wrote:
> Daniel Berlin <[EMAIL PROTECTED]> writes:
>
> | While moving FIELD_DECL to it's own substruct, the following questions
> | have come up. I figured one of you might know:
> |
> | 1. Do we need DECL_ASSEMBLER_NAME on FIELD_DECL? I can't think of a
> | place where we would actually try to *output* a FIELD_DECL directly, but
> | maybe i've missed something. I ask because the C frontend tests
> | decl_assembler_name on field decl, but never sets it on them.
>
>
> What happens when you have this (in C++)
>
>namespace foo {
> union {
> int baz;
> double foobar;
> } bar;
>};
>
I tried this, and it still doesn't access DECL_ASSEMBLER_NAME of
FIELD_DECL.
> ?
>
> -- Gaby
Re: [rfc] mainline slush
On Sun, 2005-05-22 at 00:16 +0200, Jan Hubicka wrote: > > On Sat, May 21, 2005 at 09:45:38PM +0200, Eric Botcazou wrote: > > > Btw, is it me or the individual RTL dump options are broken? > > > > The initial rtl dump is broken. The rest work. > > > > I think one of Jan's IPA pass manager changes broke it. > > What are the symptoms? -fdump-tree-expand seems to work fine for me as > does -d (not sure of -fdump-rtl-expand ever worked, but I > might try to restore it if it did). > > Honza You should definitely try to restore it. :) Let me know when you are done, because i'm about to do some surgery on register_dump_files to remove the fact that it likes to reset properties on passes. > > > > > > r~
Re: GCC-4.0 vs GCC-3.3.6 ia32 -Os: code size increase from 261 to5339 bytes
Daniel Berlin <[EMAIL PROTECTED]> wrote: >> $ ./xgcc -c -Os -B. btst.c && size btst.o >>textdata bss dec hex filename >>5339 0 0533914db btst.o >> $ ./xgcc -c -Os -fno-tree-sra -B. btst.c && size btst.o >>textdata bss dec hex filename >> 224 0 0 224 e0 btst.o >> >> So we're actually better than 3.3, after we disable -ftree-sra. I >> guess SRA should be tuned (disabled?) for -Os. > > Structure aliasing should be able to make up for turning off SRA, i'm > guessing, at least as far as propagating constants and DCE is > concerned. > > You could test this by seeing if -fno-tree-sra -fno-tree-salias > produces > an increased code size over the above. Not really: with -fno-tree-salias I get exactly the same result (224 bytes). Giovanni Bajo
gcc-4.0-20050521 is now available
Snapshot gcc-4.0-20050521 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.0-20050521/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.0 CVS branch with the following options: -rgcc-ss-4_0-20050521 You'll find: gcc-4.0-20050521.tar.bz2 Complete GCC (includes all of below) gcc-core-4.0-20050521.tar.bz2 C front end and core compiler gcc-ada-4.0-20050521.tar.bz2 Ada front end and runtime gcc-fortran-4.0-20050521.tar.bz2 Fortran front end and runtime gcc-g++-4.0-20050521.tar.bz2 C++ front end and runtime gcc-java-4.0-20050521.tar.bz2 Java front end and runtime gcc-objc-4.0-20050521.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.0-20050521.tar.bz2The GCC testsuite Diffs from 4.0-20050514 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.0 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: tree ssa and type issues
Andreas Jaeger <[EMAIL PROTECTED]> writes: > Gabriel Dos Reis <[EMAIL PROTECTED]> writes: > >> Hi again, >> >> I just hit this one from tree-ssa-into.c:rewrite_into_ssa() >> >> /* Initialize dominance frontier. */ >> dfs = (bitmap *) xmalloc (last_basic_block * sizeof (bitmap *)); >> >> >> If the sizeof operand really supposed to be "bitmap*" and not "bitmap"? > > This indeed looks wrong - and could lead to real memory corruption > :-(. Since bitmap is also a pointer, sizeof (bitmap) == sizeof (bitmap *). > If this is wrong, he should be changed on the 4.0 branch as well, While it's wrong, it's harmless. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: Some questions about FIELD_DECL
Daniel Berlin <[EMAIL PROTECTED]> writes:
| On Sun, 2005-05-22 at 02:14 +0200, Gabriel Dos Reis wrote:
| > Daniel Berlin <[EMAIL PROTECTED]> writes:
| >
| > | While moving FIELD_DECL to it's own substruct, the following questions
| > | have come up. I figured one of you might know:
| > |
| > | 1. Do we need DECL_ASSEMBLER_NAME on FIELD_DECL? I can't think of a
| > | place where we would actually try to *output* a FIELD_DECL directly, but
| > | maybe i've missed something. I ask because the C frontend tests
| > | decl_assembler_name on field decl, but never sets it on them.
| >
| >
| > What happens when you have this (in C++)
| >
| >namespace foo {
| > union {
| > int baz;
| > double foobar;
| > } bar;
| >};
| >
|
| I tried this, and it still doesn't access DECL_ASSEMBLER_NAME of
| FIELD_DECL.
OK, that is the corner case that comes to my mind where C++ directly
specifies linkage for FIELD_DECL. Maybe Jason or Mark might further
comments.
-- Gaby
Re: Some questions about FIELD_DECL
On Sun, 2005-05-22 at 03:13 +0200, Gabriel Dos Reis wrote:
> Daniel Berlin <[EMAIL PROTECTED]> writes:
>
> | On Sun, 2005-05-22 at 02:14 +0200, Gabriel Dos Reis wrote:
> | > Daniel Berlin <[EMAIL PROTECTED]> writes:
> | >
> | > | While moving FIELD_DECL to it's own substruct, the following questions
> | > | have come up. I figured one of you might know:
> | > |
> | > | 1. Do we need DECL_ASSEMBLER_NAME on FIELD_DECL? I can't think of a
> | > | place where we would actually try to *output* a FIELD_DECL directly, but
> | > | maybe i've missed something. I ask because the C frontend tests
> | > | decl_assembler_name on field decl, but never sets it on them.
> | >
> | >
> | > What happens when you have this (in C++)
> | >
> | >namespace foo {
> | > union {
> | > int baz;
> | > double foobar;
> | > } bar;
> | >};
> | >
> |
> | I tried this, and it still doesn't access DECL_ASSEMBLER_NAME of
> | FIELD_DECL.
>
> OK, that is the corner case that comes to my mind where C++ directly
> specifies linkage for FIELD_DECL. Maybe Jason or Mark might further
> comments.
I've actually discovered that we set the assembler name on a field that
is the vtable, but never actually use it again, at least for DWARF2 and
STABS (it's set to a constant called VFIELD_NAME).
I grepped .s file from all of libjava and the stl testcases compared
with -gstabs and -gdwarf-2, and none of them contain VFIELD_NAME with or
without my change.
>
> -- Gaby
Re: Some questions about FIELD_DECL
Daniel Berlin <[EMAIL PROTECTED]> writes: > I've actually discovered that we set the assembler name on a field that > is the vtable, but never actually use it again, at least for DWARF2 and > STABS (it's set to a constant called VFIELD_NAME). > I grepped .s file from all of libjava and the stl testcases compared > with -gstabs and -gdwarf-2, and none of them contain VFIELD_NAME with or > without my change. This appears to be mostly vestigial old ABI stuff. VFIELD_NAME_P is used to special-case the vtable pointer in the default copy constructor and assignment operator (see cp/method.c: do_build_copy_constructor, do_build_assign_ref respectively) but that can and probably should be changed. Even if it's kept, it would suffice to use the DECL_NAME, not the DECL_ASSEMBLER_NAME, for that. zw
Reduction rule for Kleene's Closure in replacement of Thompson's algorithm
Hi
I guess there must be people watching this list, interested in this.
I hope I now finally found the way I was looking for, to formulate a
reduction rule for Kleene's Closure which can be used in replacement
of Thompson's algorithm, or so I hope. I could be wrong about it,
however.
http://erik-poupaert.com/12001.html
If anybody feels like veryfying the reduction rule and the resulting
algorithm used to derive a regex DFA directly, feel free to let me
know what your results are.
The reduction rule is:
T{a(xy)*b} = T{ab} + T {axyb} + T{axyxyb}
With T{e} the collection of transitions derived from any regex e.
By applying the rule recursively, one obtains all DFA transitions for
any regex, or so I hope it is true. In such case, if proven to be
true, it is truly a replacement for Thompson's algorithm.
Greetings
Erik Poupaert
