Hi Denis,
I have had a look at your patch. It generally seems to work. Presently it
still misses some optimization where the old cc0 back-end was smarter. The
testsuite also reports a couple of new failures.
Yours,
Björn.
Here are a couple of cases where the old cc0 interface generated bette
James E Wilson dixit:
>Currently, -fpack-struct is defined
>to have the same effect as attribute ((packed)) for all structures,
>which in turn is equivalent to #pragma pack(1) for all structures.
Let me please add a feature request here.
gcc warns if it cannot pack structs since they're already
On 2005-03-13 15:26:05 +0100, Gabriel Dos Reis wrote:
> Vincent Lefevre <[EMAIL PROTECTED]> writes:
> | When one uses the power notation in mathematics, one (almost) never
> | says when the context is a function R x R -> R or R x Z -> R or
> | whatever.
>
> That is (almost) absolutely false.
Your
On Saturday 19 March 2005 07:51, Carl van_Schaik wrote:
> I'm running into a bug with gcc 3.4.3:
>
> I've got syscall code for user-land to our kernel that trashes r14/lr.
> The code is inlined, and works find in ARM mode. When compiling in thumb,
> gcc does not preserve lr. With an older gcc 3.3.3
Hi,
Here are build and test results for gcc-3.4.3 on standard (just slightly
upgraded) Red Hat Linux 8.0 system. Everything worked fine.
Regards,
Anna Aret
==
config.guess
i686-pc-linux-gnu
gcc -v
Reading specs from /usr/local/lib/g
Paul Schlie <[EMAIL PROTECTED]> writes:
> > From: Denis Chertykov <[EMAIL PROTECTED]>
> >> Paul Schlie <[EMAIL PROTECTED]> writes:
> >>> Denis wrote:
> >>> I have converted the AVR port from CC0 to CCmode.
> >>> But may be I have converted the port in wrong way.
> >>> (It's because I was intereste
Bernardo Innocenti <[EMAIL PROTECTED]> writes:
> Denis Chertykov wrote:
>
> > I have converted the AVR port from CC0 to CCmode.
>
> That's indeed very good news. Incidentally, CC0
> conversion of the AVR target was being discussed
> in an off-list thread with Andy Hutchinson.
>
>
> > But may
I'm updating the copyrights in the Blackfin port, and I noticed that
there appear to be two versions of the wording that allows more-or-less
unlimited use of libgcc files. One can be found e.g. in
config/arm/crtn.asm:
As a special exception, if you link this library with files
compiled wit
Hello,
I'm looking into adding support for ATmega256x and larger devices to
the AVR port. This means that program memory addresses no longer fit
in 16 bits - and I'm looking how to avoid making pointers larger.
Jumps and function calls are no problem as long as they use labels
(constant addresse
> From: Denis Chertykov <[EMAIL PROTECTED]>
>> Paul Schlie <[EMAIL PROTECTED]> writes:
>>> From: Denis Chertykov <[EMAIL PROTECTED]>
>> - although I agree that there's likely a cleaner more consistent way
>> to accurately describe and track condition-code side-effects of AVR's
>> ISA, it seems
Sorry meant denote the setting of FLAG_REGS based solely on it's result,
which should be implied by operand 0, the target of 3-operand instructions;
with the exception of compare, as it's effective target are the FLAGS_REGS.
corrected below:
> From: Paul Schlie <[EMAIL PROTECTED]>
> - possibly so
Hi Paul,
I have the impression that you are trying to open open doors :-) : If IIUC
what Denis aims to do is to segment the re-organization of the back-end into
several independent small steps. One step will be the cc0 -> CC_mode issue he
is addressing now. The splitting issue would be one of t
> Marek Michalkiewicz wrote:
> I'm looking into adding support for ATmega256x and larger devices to
> the AVR port. This means that program memory addresses no longer fit
> in 16 bits - and I'm looking how to avoid making pointers larger.
- Fully agree, just can't keep from wondering if this may
> From: Paul Schlie <[EMAIL PROTECTED]>
>> Marek Michalkiewicz wrote:
>> I'm looking into adding support for ATmega256x and larger devices to
>> the AVR port. This means that program memory addresses no longer fit
>> in 16 bits - and I'm looking how to avoid making pointers larger.
>
> - Fully ag
I fixed the regressions USE_MAPPED_LOCATION for C and C++, and
we've now branched, so it's is probably time to get Ada working.
(There is a Java problem, for which I have a patch, but it may
hurt debugging. Until that is fixed, leave Java out of
--enable-languages, or apply this patch:
http://gcc.
> From: Björn Haase <[EMAIL PROTECTED]>
> I have the impression that you are trying to open open doors :-) : If IIUC
> what Denis aims to do is to segment the re-organization of the back-end into
> several independent small steps. One step will be the cc0 -> CC_mode issue he
> is addressing now. Th
On Sat, 2005-03-19 at 11:52 -0800, Per Bothner wrote:
> && line not excessively big;
> The latter is a heuristic to avoid using up line number too greedily;
> I suspect it may not be an issue.
IIRC, current default max line length for Ada programs is 255, and 32767
for configuration p
On Sat, Mar 19, 2005 at 01:51:05PM -0500, Paul Schlie wrote:
> - Fully agree, just can't keep from wondering if this may be most
> efficiency accomplish by simply requiring the alignment of all
> function entry points to be two instruction word aligned. Thereby
This only doubles the available
Hello,
> VIEW_CONVERT_EXPR is tcc_reference, but we can have a statement like:
>
> x = 22;
what is the semantics of this expression? Should not this rather be
x = 22
(or just INTEGER_CST:some_type 22)?
Zdenek
> What ends up happening here is that find_interesting_uses_stmt calls
> f
> From: Marek Michalkiewicz <[EMAIL PROTECTED]>
>> - Fully agree, just can't keep from wondering if this may be most
>> efficiency accomplish by simply requiring the alignment of all
>> function entry points to be two instruction word aligned. Thereby
>
> This only doubles the available addres
On Sat, Mar 19, 2005 at 04:38:28PM -0500, Paul Schlie wrote:
> - understood, however unlikely; observing it will likely take Atmel at
> least 2-3 years to stabilize production of the 256K devices, and larger
> device volume potential vs. competitive offerings couldn't likely justify
> their
> From: Marek Michalkiewicz <[EMAIL PROTECTED]>
> Good question - I can't. On the other hand, the manual says:
>
> `indirect_jump'
> An instruction to jump to an address which is operand zero. *This pattern
> name is mandatory on all machines.*
>
> Why would it be mandatory if it was not truly
> From: Björn Haase <[EMAIL PROTECTED]>
> In my opinion segmenting the rework of the back-end would indeed be the best
> approach, also because I expect that the instruction patterns *with*
> splitting will be fairly different. E.g. I do not think that the "addsi3"
> will be present any more. So it
> From: Paul Schlie <[EMAIL PROTECTED]>
>> From: Marek Michalkiewicz <[EMAIL PROTECTED]>
>> Good question - I can't. On the other hand, the manual says:
>>
>> `indirect_jump'
>> An instruction to jump to an address which is operand zero. *This pattern
>> name is mandatory on all machines.*
>>
>
Snapshot gcc-4.0-20050319 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.0-20050319/
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-20050319
You'll
Hi Per,
Of the three proposals:
[...]
The ideal solution I think is for Ada to use line-map's
source_location for Sloc in its lexer.
[...]
translate Sloc integers to source_location
when we translate the Ada intermal format to Gcc trees.
[...]
the location_t in the shared Gcc should be a language-
On Sat, Mar 19, 2005 at 06:37:54PM -0500, Paul Schlie wrote:
> - or possibly GCC may try to be clever by jumping to no-return attribute
> function calls?
Such "trying to be clever" would most likely be optional.
Again, why is indirect_jump _mandatory_ on all machines?
Please, don't try to be t
Paul Schlie <[EMAIL PROTECTED]> wrote:
> - Sorry, I'm confused; can you give me an example of legal C
> expression specifying an indirect jump to an arbitrary location
> within a function?
It is possible in GNU C at least:
int foo(int dest)
{
__label__ l1, l2, l3;
void *lb[] = { &&l1, &
On Sunday 20 March 2005 01:58, Giovanni Bajo wrote:
> Paul Schlie <[EMAIL PROTECTED]> wrote:
> > - Sorry, I'm confused; can you give me an example of legal C
> > expression specifying an indirect jump to an arbitrary location
> > within a function?
>
> It is possible in GNU C at least:
>
> int fo
> From: Giovanni Bajo <[EMAIL PROTECTED]>
>> Paul Schlie <[EMAIL PROTECTED]> wrote:
>> - Sorry, I'm confused; can you give me an example of legal C
>> expression specifying an indirect jump to an arbitrary location
>> within a function?
> It is possible in GNU C at least:
- thanks, obviously w
> From: Paul Brook <[EMAIL PROTECTED]>
> Don't we know which labels are targets of indirect jumps?
> So the proposed restriction now becomes: functions *and targets of indirect
> jumps* must be aligned to an N word boundary. I'd guess that the latter are
> sufficiently rare that this is still an ac
Kazu Hirata wrote:
I created a set of scripts that generates predicates.md based on
PREDICATE_CODES in tm.h.
Thank you! I had been planning to do this for the Xtensa port, but your scripts
motivated me to do it sooner. I ended up rewriting most of the predicates in
Lisp-style, but the scripts w
Attached is patched for 4.1.0 head that changes AVR to use RTL
prologue/epilogue generation.
This also should also fix the c++ bug caused by the existing code using the
function name as a label. (sorry the PR escapes me!)
It generates same code with following exceptions:
Small stack adjustmen
33 matches
Mail list logo
