Re: converting Ada to handle USE_MAPPED_LOCATION
> IIRC, current default max line length for Ada programs is 255, and 32767 > for configuration pragmas. But it's always better to be prepared > for the worse :). Actually that's no longer the same. You can have line length much bigger now with GNAT, assuming you use the proper compiler switch. As Geert said, we do not want to create a strong dependency between the Ada front-end and one particular GCC back-end notion of linemap/source location. Arno
Re: AVR: CC0 to CCmode conversion
Paul Schlie <[EMAIL PROTECTED]> writes: [...] > > > I think that better to support > > cmpHI, cbranch -> cmpQI1_set_CC, cmpQI2_use_CC, cbranch. because > > AVR is a microcontroller and code size more important than code speed. > > - I fully agree that code-size tends to be most important, which is why I > believe it's important to enable instruction scheduling/re-ordering > optimizations that are capable of eliminating potentially unnecessary > explicit comparison operations for wider than byte-sized operand results > against 0, if the instructions within a basic block can be safely > rescheduled to eliminate them. > > Which would seem to require that both instruction FLAGS_REG side-effects > be fully exposed, and correspondingly that conditional branches expose > their dependency on them (and all are visible during DFCG scheduling). > > - possibly something like: ? > > (define_insn "*addhi3" > [(set (match_operand:HI 0 ...) >(plus:HI (match_operand:HI 1 ...) > (match_operand:HI 2 ...))) > (set (reg ZCMP_FLAGS) >(compare:HI (plus:HI (match_dup 1) (match_dup 2))) (const_int 0)) > (set (reg CARRY_FLAGS) >(compare:HI (plus:HI (match_dup 1) (match_dup 2))) (const_int 0))] > "" > "@ add %A0,%A2\;adc %B0,%B2 >..." > [(set_attr "length" "2, ...")]) You have presented a very good example. Are you know any port which already used this technique ? As I remember - addhi3 is a special insn which used by reload. The reload will generate addhi3 and reload will have a problem with two modified regs (ZCMP_FLAGS, CARRY_FLAGS) which will be a bad surprise for reload. :( As I remember. Denis.
Re: Question on tree-ssa-loop-im.c:for_each_index
> x = 22; what is the semantics of this expression? Should not this rather be x = 22 (or just INTEGER_CST:some_type 22)? Depends what the type is. If it's an array type, then there's no simple equivalent expression.
Re: reload-branch created
Bernd Schmidt wrote: I have created a new branch, "reload-branch", on which I'm going to check in these changes. Thanks - very important first step to make reload "the preferred way to distribute the software" :-) AKA as complying to the GPL. -- Toon Moene - e-mail: [EMAIL PROTECTED] - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands A maintainer of GNU Fortran 95: http://gcc.gnu.org/fortran/ News on GNU Fortran 95: http://gfortran.org/
Re: [AVR] RTL prologue/epilogue
Hello Andy, I have tested your patch concerning RTL prologue/epilogue. Gratulations: My testsuite run only reports a single regression Tests that now fail, but worked before: gcc.c-torture/execute/20010122-1.c execution, -O0 . This happens on a testcase that anyway is problematic (succeeds only for selected set of optimization switches). Due to your "rjmp" trick the resulting code also is sligtly tighter. IIUC, now there is also hope for optimizing sequences like call other_function ret to jmp other_function .? Yours, Björn
Re: PRE in GCC-3.3.3
The target I used is i686-linux. For the same example gcc-3.4.1 eliminated the redundant expression, where as gcc-3.3.3 didn't do it. I observed it by dumping RTL with -dG switch. I didnt get abt the flaw you were talking about. The optimization is done on the pseudo registers, where is the question of forcing into memory there. Or else can you modify the example so that pre is done on it by gcc-3.3.3. I tried with some other examples also and found that the hash table entries of the expressions is not correct. For this example there are 2 occurences of a+b, so in 1st pass of gcse, there will be 2 entries of a+b in hash table. For the 2nd pass these 2 are combined and made as one entry and data flows are calculated and pre is done. This procedure is followed in gcc-3.4.1, where as in gcc-3.3.3 it is not done in that fashion. Even after 2nd pass the hash table has 2 entries for a+b, so pre is not done on it. Rajesh On Tue, 15 Mar 2005, James E Wilson wrote: Rajesh Babu wrote: I found that PRE is not done in gcc-3.3.3, though the code for doing PRE exists in source code. gcc-3.3 is not interesting for work like this. The PRE support in gcc-3.3 has already been effectively obsoleted by other work in current gcc sources, though it is still there. You failed to specify the target. The target often makes a big difference on whether optimizations are performed. I am assuming the target is ia64-linux. Your testcase incidentally is serious flawed. The varible c is both used while uninitialized, and set using an unitialized value. It doesn't make much sense to talk about compiler optimizations when you have a testcase that invokes undefined behaviour. The testcase is also flawed in that it takes the address of both a and b, forcing them into memory, and thus making optimization of them difficult, particularly in pre-gcc-4 sources. I seem to get the same behaviour from both gcc-3.3 and gcc-3.4. In neither case is the partially redundant expression eliminated. gcc-4 does perform the optimization.
Re: Question on tree-ssa-loop-im.c:for_each_index
Hello, > > x = 22; > > what is the semantics of this expression? Should not this rather be > > x = 22 > > (or just INTEGER_CST:some_type 22)? > > Depends what the type is. If it's an array type, then there's no > simple equivalent expression. using CONSTRUCTOR node? Zdenek
Re: Question on tree-ssa-loop-im.c:for_each_index
On Sat, Mar 19, 2005 at 09:59:32PM +0100, Zdenek Dvorak wrote:
> > x = 22;
>
> what is the semantics of this expression? Should not this rather be
>
> x = 22
>
> (or just INTEGER_CST:some_type 22)?
The semantics are, exactly,
union {
some_type st;
int_type it;
} u;
u.it = 22;
x = u.st;
In many cases we *could* fold the constant, but fold-const.c doesn't
know much about view_convert_expr so we don't.
r~
Re: AVR: CC0 to CCmode conversion
On Sun, Mar 20, 2005 at 01:59:44PM +0300, Denis Chertykov wrote: > The reload will generate addhi3 and reload will have a problem with > two modified regs (ZCMP_FLAGS, CARRY_FLAGS) which will be a bad > surprise for reload. :( As I remember. In order to expose the flags register before reload, you *must* have load, store, reg-reg move, and add operations that do not modify the flags. Note, for instance, that i386 "add" instruction always modifies the flags, but the "lea" instruction does not. So we emit the later when reload emits an add. If you cannot meet these requirements, then you must represent "setcc" and "compare-and-branch" patterns as a single insn until after reload. You can then split them apart, followed by peep2 patterns to remove compare patterns that are redundant with immediately preceeding arithmetic. r~
Re: AVR: CC0 to CCmode conversion
> From: Richard Henderson <[EMAIL PROTECTED]> > On Sun, Mar 20, 2005 at 01:59:44PM +0300, Denis Chertykov wrote: >> The reload will generate addhi3 and reload will have a problem with >> two modified regs (ZCMP_FLAGS, CARRY_FLAGS) which will be a bad >> surprise for reload. :( As I remember. > > In order to expose the flags register before reload, you *must* > have load, store, reg-reg move, and add operations that do not > modify the flags. > > Note, for instance, that i386 "add" instruction always modifies > the flags, but the "lea" instruction does not. So we emit the > later when reload emits an add. > > If you cannot meet these requirements, then you must represent > "setcc" and "compare-and-branch" patterns as a single insn until > after reload. You can then split them apart, followed by peep2 > patterns to remove compare patterns that are redundant with > immediately preceeding arithmetic. - OK, so GCC's assumes that it may arbitrarily spill/reload at any point and not destructively modify the machines state; as opposed to attempting to select optimal points to do so through the analysis of the code's data-flow/control dependencies, and then as potentially may be necessary, re-synthesize machine state post the actions to consistently satisfy any dependencies which may remain. - so in AVR's case, simply pretending that add operations don't modify CC state may only be asking for trouble; however may it be sufficient to somehow force spill/reload to only use indexed/auto-inc/dec load/store operations, without inadvertently picking up a general add/sub/etc. operation in the process which will modify CC state?
Re: AVR: CC0 to CCmode conversion
> From: Paul Schlie <[EMAIL PROTECTED]> >> From: Richard Henderson <[EMAIL PROTECTED]> >> On Sun, Mar 20, 2005 at 01:59:44PM +0300, Denis Chertykov wrote: >>> The reload will generate addhi3 and reload will have a problem with >>> two modified regs (ZCMP_FLAGS, CARRY_FLAGS) which will be a bad >>> surprise for reload. :( As I remember. >> >> In order to expose the flags register before reload, you *must* >> have load, store, reg-reg move, and add operations that do not >> modify the flags. >> >> Note, for instance, that i386 "add" instruction always modifies >> the flags, but the "lea" instruction does not. So we emit the >> later when reload emits an add. > > - OK, so GCC's assumes that it may arbitrarily spill/reload at any > point and not destructively modify the machines state; as opposed > to attempting to select optimal points to do so through the analysis > of the code's data-flow/control dependencies, and then as potentially > may be necessary, re-synthesize machine state post the actions to > consistently satisfy any dependencies which may remain. > > - so in AVR's case, simply pretending that add operations don't modify > CC state may only be asking for trouble; however may it be sufficient to > somehow force spill/reload to only use indexed/auto-inc/dec load/store > operations, without inadvertently picking up a general add/sub/etc. > operation in the process which will modify CC state? - what about blk moves? (as they would seem to most likely destructively modify the machine's cc state in most implementations, as their implementation implies a conditional loop; or are they an exception? if so, why?) >> If you cannot meet these requirements, then you must represent >> "setcc" and "compare-and-branch" patterns as a single insn until >> after reload. You can then split them apart, followed by peep2 >> patterns to remove compare patterns that are redundant with >> immediately preceeding arithmetic. - what would be the requirements to enable the SMS pass (assuming it to be the most likely appropriate) to try to reorder operations such that a naturally occurring operation with the required side effects for a conditional branch may be moved closer to to it, such that an otherwise explicit compare may be optimally eliminated? (as opposed to an otherwise more coincidental peephole opportunity)
gcc-4.1-20050320 is now available
Snapshot gcc-4.1-20050320 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20050320/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.1 CVS branch with the following options: -D2005-03-20 17:43 UTC You'll find: gcc-4.1-20050320.tar.bz2 Complete GCC (includes all of below) gcc-core-4.1-20050320.tar.bz2 C front end and core compiler gcc-ada-4.1-20050320.tar.bz2 Ada front end and runtime gcc-fortran-4.1-20050320.tar.bz2 Fortran front end and runtime gcc-g++-4.1-20050320.tar.bz2 C++ front end and runtime gcc-java-4.1-20050320.tar.bz2 Java front end and runtime gcc-objc-4.1-20050320.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.1-20050320.tar.bz2The GCC testsuite Diffs from 4.1-20050313 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.1 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: reload-branch created
Ulrich Weigand wrote: - As mentioned in http://gcc.gnu.org/ml/gcc/2005-01/msg00911.html there is a code path in find_reloads that sets rld[].inc to a nonzero value even for a platform that doesn't actually *have* pre-/post-increment insns, leading to an ICE later on. The patch below simply avoids setting .inc unless it was already set to a nonzero value (by find_inc_amount). This one I'm not sure about yet. - As mentioned in http://gcc.gnu.org/ml/gcc/2005-01/msg01112.html there are problems with reload ordering when optional reloads are disabled, leading to address reload insns being emitted after the main insn. The patch below is the same I suggested in that mail; it considers such address reloads to feed into both the optional reload and the main insn in scan_rtx. This problem will probably require more invasive surgery. - Finally, there is still a (new) problem in the latest version of usable_for_inheritance: if an inherited register is chosen as override-in because it is not suitable as reload register due to HARD_REGNO_MODE_OK, it isn't even checked against the *usable_regs array. The patch below adds back that check (using inmode, not mode). This is OK. Would you check it in? Bernd
Re: AVR: CC0 to CCmode conversion
On Sun, Mar 20, 2005 at 12:06:31PM -0500, Paul Schlie wrote: > - so in AVR's case, simply pretending that add operations don't modify > CC state may only be asking for trouble; however may it be sufficient to > somehow force spill/reload to only use indexed/auto-inc/dec load/store > operations, without inadvertently picking up a general add/sub/etc. > operation in the process which will modify CC state? Nope. You need to be able to support "reg = frame_pointer + offset". r~
Re: Question on tree-ssa-loop-im.c:for_each_index
> Depends what the type is. If it's an array type, then there's no > simple equivalent expression. using CONSTRUCTOR node? What I mean by "simple" is something that's easy to derive. Suppose I have a record with numerous fields of various sizes and I unchecked convert a constant to it. Yes, I could write code to convert that into a CONSTRUCTOR by figuring out what value should be assigned to each field, but that's a pretty large block of code for a pretty marginal case.
Re: AVR: CC0 to CCmode conversion
On Sun, Mar 20, 2005 at 12:41:39PM -0500, Paul Schlie wrote: > - what about blk moves? (as they would seem to most likely destructively > modify the machine's cc state in most implementations, as their > implementation implies a conditional loop; or are they an exception? > if so, why?) Why ever would you get that idea that they're special? There's exactly one target that implements the "strmov" pattern, and that's i386. It either exposes the use of the flags register immediately (and so is seen by the optimizer), or it expands to a single instruction that implements the entire block copy, with no conditional loop. > - what would be the requirements to enable the SMS pass (assuming it > to be the most likely appropriate) to try to reorder operations such > that a naturally occurring operation with the required side effects > for a conditional branch may be moved closer to to it, such that an > otherwise explicit compare may be optimally eliminated? (as opposed > to an otherwise more coincidental peephole opportunity) You could enable the SMS pass, but it would only ever see the fused compare-and-branch pattern, and so would never be able to move the compare separately from the branch. You could enable more explicit compare elimination by creating even larger fused operate-compare-and-branch instructions that could be recognized by combine. I wouldn't actually recommend this though, because branch instructions with output reloads are EXTREMELY DIFFICULT to implement properly. It may be possible to enhance reload such that it inserts reloads on edges, and so removes the bulk of the pain from the backend, but it hardly seems worthwhile. r~
Re: Question on tree-ssa-loop-im.c:for_each_index
Hello, > > Depends what the type is. If it's an array type, then there's no > > simple equivalent expression. > > using CONSTRUCTOR node? > > What I mean by "simple" is something that's easy to derive. Suppose I have > a record with numerous fields of various sizes and I unchecked convert a > constant to it. Yes, I could write code to convert that into a CONSTRUCTOR > by figuring out what value should be assigned to each field, but that's a > pretty large block of code for a pretty marginal case. however, avoiding possibly a large amount of bugs in code that does not expect this corner case. I would certainly consider it much cleaner solution than adding hacks to for_each_index and possibly other places that do not expect something as weird. That being said, I think your patch is safe and will not break any of the uses of for_each_index. Zdenek
Re: reload-branch created
Bernd Schmidt <[EMAIL PROTECTED]> wrote on 03/20/2005 07:41:14 PM: > This is OK. Would you check it in? Done, thanks. Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand Linux for S/390 Design & Development IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032 Boeblingen Phone: +49-7031/16-3727 --- Email: [EMAIL PROTECTED]
Re: Question on tree-ssa-loop-im.c:for_each_index
however, avoiding possibly a large amount of bugs in code that does not expect this corner case. I would certainly consider it much cleaner solution than adding hacks to for_each_index and possibly other places that do not expect something as weird. But there are a *huge* number of types. You have arrays, records, even FP to integer and vice versa. That being said, I think your patch is safe and will not break any of the uses of for_each_index. OK, thanks.
PL/I Frontend for GCC version 0.0.10 released
Cross posted to alt.os.multics comp.lang.pl1 [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] gcc@gcc.gnu.org March 2005 This is the tenth code drop of the GCC front-end for the PL/I programming language. PL/I for GCC is released under the terms of the GNU Public License; version 2. Version 0.0.10 marks yet another milestone for the PL/I front-end project. With this release most if not all of the Multics source code can be parsed using only flex and bison. Special thanks to Tom Van Vleck and Douglas Quebbeman for their effort in providing some 100+ megabytes of Multics source code. It dramatically helped squeeze out many of the quirks of the PL/I grammar. If you have a PL/I project you would like to see supported by the pl1gcc effort, please get in touch with us. If you are testing the PL/I compiler, please inform us about any syntax errors that might occur. It suffers to send the offending line of code. Changes in v0.0.10: * Updated INSTALL to follow gcc.gnu.org/install guidelines * Added new compiler option -isuffix, to control suffix of %include files * Included killer test program from Paul Karagianis www.multicians.org/proc-proc.html * Added offset counting to the location tracking * Enhanced the ./testone script for mass compiling * Added online manual to pl1gcc.sourceforge.net/pl1gcc-0.0.10.doc/doc.html Removed in v0.0.10 * Removed usage of spaces in numeric constants (wrongly introduced in v0.0.9) * Removed compiler option -J, introduced in v0.0.4 Fixed syntax in v0.0.10: * Added 'INITIAL TO' for initialising pointers to strings * Added B2 bitconstants * Allow negative precision and scale for numeric declares * Added attribute expressions to DEFAULT statement * Added RENAME to procedure options * Added support for iSUB array specification * RETURNS on procedure and entry can now specify a structure or array * Added to entry and procedure options - non_quick_blocks, packed_decimal, separate_static, - packed, support, variable,non_quick * Added to environment list - interactive, stringvalue * Added irreducible,reducible to declare statement * Corrected CALL to array of entries with parameters * Added constant,format,local,nonvarying to declare statement * Allow for user defined conditions * Allow '*' in array specifications * Change edit specification for E specifications * On GENERIC declares allow precision range in WHEN option * Allow UNS as abbreviation for UNSIGNED * Allow PARM as abbreviation for PARAMETER * Floating point constants can end with just '.' * Options elements can be separated by blanks or comma * Added 'F' in fixed point constants notation * Ignore various hex codes in scanner For a complete changelog look in the README file. What is pl1gcc ? The pl1gcc project is an attempt to create a native PL/I compiler using the GNU Compiler Collection. The project is looking for more people to join the development and testing. If you want to help speed up the development of a free PL/I compiler please do contact us and join the fun. Looking ahead. After the grammar has settled down, the real code generation is forseen to take place. To capitalize of the effort so far, the parser input file, will be used as basis for a highlightning editor, using the Eclipse project. If you do try the compiler on some of your own code, please let us know how it goes. For more information, comments, feedback and download, please visit http://pl1gcc.sourceforge.net and don't forget to join the newsgroup: [EMAIL PROTECTED] Have fun The GCC PL/I Team. [EMAIL PROTECTED]
Re: AVR indirect_jump addresses limited to 16 bits
On Sun, Mar 20, 2005 at 02:58:29AM +0100, Giovanni Bajo wrote:
> It is possible in GNU C at least:
>
> int foo(int dest)
> {
>__label__ l1, l2, l3;
>void *lb[] = { &&l1, &&l2, &&l3 };
>int x = 0;
>
>goto *lb[dest];
>
> l1:
>x += 1;
> l2:
>x += 1;
> l3:
>x += 1;
>return x;
> }
Thanks for explaining this. So yes, unfortunately we have to support
indirect_jump properly (I was hoping it was only for something like
trampolines, which can't work on the AVR anyway).
I was wrong about needing two jumps - just one for each label should
be enough, because switching to .text_low and back to .text doesn't
disrupt the normal flow of instructions in .text. So, it's not that
bad, really the same thing for indirect jumps and calls (using function
pointers), each affected label needs to be output like this:
.section .text_low,"ax",@progbits
label:
jmp 1f
.text
1:
This includes all global labels (visible to other object files, like
function entry points), and local labels referenced by anything other
than direct jumps or calls).
On the other hand, branches within the same function should avoid the
extra jump and go to "1:" directly. If the same label is used in both
ways (direct jump/branch, and address taken), two separate labels (at
the same address) should be output for both of these uses, but I'm not
sure how to do this in GCC. Any suggestions?
(The problem can be seen by adding something like "if (dest > 2) goto l3;"
above the goto in the original example: in the assembler output, there is
only one label corresponding to l3 which is both 1. referenced with pm()
and 2. target of a branch for which .text_low would be out of range.)
Marek
Re: AVR indirect_jump addresses limited to 16 bits
On Mon, Mar 21, 2005 at 01:12:40AM +0100, Marek Michalkiewicz wrote: > On the other hand, branches within the same function should avoid the > extra jump and go to "1:" directly. If the same label is used in both > ways (direct jump/branch, and address taken), two separate labels (at > the same address) should be output for both of these uses, but I'm not > sure how to do this in GCC. Any suggestions? The easiest way is to do this in the linker instead of the compiler. See the xstormy16 port and how it handles R_XSTORMY16_FPTR16. This has the distinct advantage that you do not commit to the creation of an indirect jump until you discover that the target label is outside the low 64k. But failing that, you can override ASM_OUTPUT_LABEL to make sure that the two labels get output; e.g. .Lnnn: .section .text_low,"ax",@progbits .Lnnn_low: jmp .Lnnn .previous and then in print_operand_address you can mangle the name printed when taking the address of a label. r~
Extra gcc-3.3 java failures when using expect-5.43
After I upgraded to expect-5.43, I noticed that I'm getting extra java failures on the 3.3 branch on x86_64-unknown-linux-gnu. Other gcc branches do not have problems. http://gcc.gnu.org/ml/gcc-testresults/2005-03/msg01295.html I'm using an expect-5.43 binary on x86_64 that was compiled on i686 if that matters. When I back down to expect-5.42.1, the testsuite results go back to normal. Anyone else seeing this? Thanks, --Kaveh -- Kaveh R. Ghazi [EMAIL PROTECTED]
Ada and ARM build assertion failure
I've been having some difficulty building Ada as a native compiler for an ARM-based target that I'm working on. The error is: ../../xgcc -B../../ -c -g -O2 -W -Wall -gnatpg -g -O1 -fno-inline \ a-except.adb -o a-except.o | 4.0.0 20050318 (prerelease) (arm-riscos-elf) Assert_Failure nlists.adb:296| | Error detected at a-exexpr.adb:85:9 This seems to be a reoccurance of PR5677. As I'm using a modified backend, I wanted to know whether other users are having this problem when building Ada for ARM targets. The only patch I apply to Ada is below. Any thoughts before I go barking up the wrong tree ? Regards, Nick. diff -x '*.orig' -x '*.rej' -uprN /home/nick/riscos-aof/masters/gcc-4.0/gcc/ada/s-auxdec.ads gcc-4.0/gcc/ada/s-auxdec.ads --- /home/nick/riscos-aof/masters/gcc-4.0/gcc/ada/s-auxdec.ads 2004-06-16 14:50:06.0 +0100 +++ gcc-4.0/gcc/ada/s-auxdec.ads2005-03-18 11:30:24.0 + @@ -283,7 +283,7 @@ pragma Elaborate_Body (Aux_DEC); end record; for Aligned_Word'Alignment use - Integer'Min (2, Standard'Maximum_Alignment); + Integer'Min (4, Standard'Maximum_Alignment); procedure Clear_Interlocked (Bit : in out Boolean;
