> 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
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, wh
> 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.
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:
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 o
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
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 n
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
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
> 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.
>
> I
> 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
>>>
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
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
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
> operation
> 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
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
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
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. 2
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 o
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.
Versi
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;
>
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 ad
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
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
24 matches
Mail list logo
