 |
Version 2.6.1
|
|
|
|
|
The compiler will crash after a function declaration that uses two
or more identical parameter names, and a call to this function.
This input is of course wrong, but the compiler shouldn't crash.
Workaround: Don't do it:-)
Fix: Is fixed in the development version.
|
|
| |
Version 2.6.0
|
|
|
|
|
Absolute long addressing does not work in 65816 mode. This is a problem
that was introduced some time ago with a change in the handling of
pseudo instructions (assembler commands). The problem is that the
dot (which is needed to separate bank and address in long addressing
mode) is not handled as a separate token by the scanner, but as part
of an (illegal) pseudo instruction.
Workaround: You may use a macro that encodes the
necessary instructions by emitting literal bytes. Here is an example:
.macro ldaf addr
.byte $AF
.faraddr addr
.endmacro
Fix: Download and apply the
patch,
then recompile the assembler. Please note that this patch is not a
complete solution for the problem. If the intra bank address is a
symbol, you will have to enclose it in parenthesis to make it work.
Bug found by: John Weidman <jweidman@slip.net>
|
|
|
|
Several small subroutines that increment the primary register (ax)
have errors.
Workaround: None
Fix: Download the replacement modules
from the patch directory, and recompile the library. You may also add
these files to your project, so they are used instead of the ones from
the library when linking.
Bug found by: Eric Au <eric_au@hotmail.com>
|
|
|
|
In 65C02 mode (that is, with an explicit --cpu 65C02 given
on the command line) with optimization enabled, the optimizer
generates several dangling pointers when trying to translate bit
operations into the 65C02 TRB and TSB
instructions. The results differ from platform to platform but are
usually unpleasant: The Linux version often generates wrong code,
the Windows version will crash with a segmentation violation.
Please note that this bug is only
triggered in 65C02 mode with optimization enabled. If you use 6502
mode (the default) or disable optimizations, you don't need to care
about it.
Workaround: Disable the buggy optimizer step by using
the (undocumented) -Of option. Add
-Of0x1000
to the compiler command line. You may also disable optimization
completely, but this is often not desirable.
Fix: Apply
this patch
to the optimize.c module and and recompile the compiler.
Bug found by: Dennis Lin <dennis@mosart.com.tw>
|
|
|
|
Using separate load and run areas
does not work correctly.
Note: None of the predefined system uses this feature,
you have to supply a configuration file to the linker to make use of
it.
Workaround: In the linker configuration file, place
all memory areas that are used as load areas before
those used as run areas. That is, place the lines
describing ROM areas before those describing RAM areas.
Fix: Apply
this patch
and recompile the linker.
Bug found by: Eric Bacher <ebacher@teaser.fr>
|
|
| |
Version 2.5.0
|
|
|
|
|
The .IFP02, .IFPC02 and .IFP816
instructions described in the docs are not available.
Workaround: Use
.if .cpu = x
instead.
Fix: Is fixed in the development version.
|
|
|
|
The '+' and ' ' (space) flags in any of the printf functions do not
work correctly. A plus or space character is added, even if the value
is negative.
Workaround: None.
Fix: Apply the
patch
to the _printf.c module and and recompile the library.
|
|
|
|
The linker does not accept the -h command line option.
Workaround: Use --help instead.
Fix: Is fixed in the development version.
Bug found by: Christian Groessler, cpg@aladdin.de
|
|
|
|
Macro redefinitions are not detected and flagged as an error.
Workaround: None.
Fix: Is fixed in the development version.
|
|
|
|
The code generated for explicit type casts is sometimes wrong.
Workaround: Don't use explicit type casts if you don't
need them.
Fix: I'm currently testing replacement code and will
post a patch as soon as I'm confident that it works.
Bug found by: Eric Au, eric_au@hotmail.com
|
|
|
|
The memcmp() function does not work correctly.
Workaround: None available.
Fix: Use
this
replacement function. Be sure to recompile the library or use it as
part of your project (in this case the buggy one from the library
will not be used).
Bug found by: Eric Au, eric_au@hotmail.com
|
|
|
|
The routine that handles switch statements for longs
has a bug. There is a high chance that a label is not found, and
the program may even crash.
Workaround: None available.
Fix: Apply the
patch
to the lswitch.s module and and recompile the library.
Bug found by: Greg King, gngking@erols.com
|
|
|
|
A change in the newline handling applied to v2.5 broke the
cvline and cvlinexy functions. After
output of the first character, the X position is reset to zero.
Workaround: Use calls to cputc or
cputcxy to draw vertical lines.
Fix: There is currently no fix available.
|
|
|
|
When using 65SC02 mode, the BIT instruction has a wrong
encoding in immidiate mode. Both, 6502 mode and 65816 mode, as well as
the other addressing modes are ok.
Workaround: Temporarily switch to 816 mode.
Fix: Apply the
patch
and recompile the assembler.
Bug found by: C. N. Wong, superufo@netvigator.com
|
|
|
|
Subtracting zero from a variable will compile but not link:
Unresolved external `decax0' in ...
Workaround: Don't do it:-)
Bug found by: Christian Groessler, cpg@aladdin.de
|
|
|
|
The header files needed for GEOS programs are not installed by the
source RPMs and they are not included in the binary RPMs. In the
second version of the RPMs, the geos subdirectory has the wrong
permissions (I didn't notice because I tested it as root :-().
Fix: If you have the -2 RPMs, just fix the permissions
of the /usr/lib/cc65/include/geos directory. If you have
the -1 RPMs and if you want to create GEOS programs, download the
updated -3 RPMs. Otherwise don't care.-)
|
|
|
|
The .ERROR directive does not work. The error message
"String constant expected" is displayed instead of the requested
one.
Workaround: None. You may use .OUT
instead, but you cannot avoid generation of the resulting binary.
Fix: Apply the
patch
and recompile the assembler.
Bug found by: Dagan Galarneau, dagan@dnai.com
|
|
|
|
Defining a macro with .DEFINE in a .IF...
sequence that is assembled more than once (for example because you
writing an idempotent include file) will fail if the macro takes
parameters. Here is an example:
.define foo(bar) fubar, bar
.if 0
.define foo(bar) fubar, bar
.endif
Defining the macro twice should not matter since the second definition
should get skipped. Unfortunately, .DEFINE style macros
are expanded when transforming the input into tokens. This is needed
because you may also replace keywords by using these macros. So, when
seeing the second "foo", the assembler tries to expand the macro
foo and expects a parameter, but in fact a left paren
follows, so it prints an error message, even if the resulting token
would be skipped later.
Workaround: Try to avoid redefining
.DEFINE style macros, even if the second definition is
inside a .IF... statement. You may also use a classic
macro instead.
Fix: This problem is inherent in the design and I'm
not sure if it is possible to fix it.
Bug found by: Dagan Galarneau, dagan@dnai.com
|
|
|
|
time.h contains a wrong definition. The macro
CLOCKS_PER_TICK should be named
CLOCKS_PER_SEC. One of the sample programs (nachtm.c)
is using this wrong identifier.
Fix: Replace the identifier by
CLOCKS_PER_SEC.
|
|
|
|
A local, static, uninitialized variable declaration, immidiately
followed by the declaration of an initialized auto variable inside
a function will cause the compiler to emit wrong code. What happens
is that the segment is not switched, so the code to initialize the
auto variable is emitted into the BSS segment.
The error is easily detected since the linker will emit a warning.
Workaround: Change the order of declarations, declare
the static variable after the auto one, or place the declaration of an
uninitialized auto varable between the two other decls.
Fix: Is fixed in the development version.
|
|
| |
Old bugs
bugs.php; last change: 22-Mar-2001
webmaster@cc65.org
| |
