I'm compiling a piece of Delphi code with Free Pascal with a JVM backend.
On an off chance that someone who's involved in porting Free Pascal to the JVM back-end is reading this, here's a compilation error message I'm getting:
MyFile.j:379326: JAS Error: reference from line 10039 exceed size for short.
The file is pretty big (>6000 lines), and the functions in it are, too. So there can be some resource that's getting exhausted. Can one hint me as what exactly to to simplify to get rid of this?
Tracked down the error message to the Jasmin assembler: http://www.java2s.com/Open-Source/Java/Byte-Code/Jasmin-2.4/jas/InsnOperand.java.htm
Looks like the error manifests when there's a goto command in the bytecode assembly file that points to a label that's more than 32KB away. So it seems that block size is to blame - the assembly generator in FPC assumes the byte code for a single if/loop body fits into a 64K block. I couldn't find any goto_w commands in generated assembly - guess FPC does not emit them.
The issue was fixed in Jasmin - it now replaces goto with goto_w where appropriate. Grab a copy at ftp://ftp.freepascal.org/pub/fpc/contrib/jvm/fpcjvmutilities.zip
Related
I have a piece of Verilog code here
$size(data);
where data is a 16-bit number.
But, it gives an error in Vivado.
error: system call size not allowed in this dialect use system Verilog mode
I have tried searching for a solution, but no luck, hence posting it here.
The error message means that the $size system function can only be used if SystemVerilog features are enabled in Vivado. One way to do so is to give your files a .sv extension.
Rust has very clear error display, showing the line and part of line where an error occurred:
Is there a function from the Rust standard library or crate which replicates this for an arbitrary error? I'm kind of assuming it must exist somewhere within the Rust codebase, but can't find anything (mostly because any search term like "Rust rich line errors..." returns errors people have got while writing Rust, not how to generate the error display :-)).
E.g. I have the line number and character number of an error as well as the source, is an existing implementation of the above pretty error which I can reuse?
I don't know if this is of much help, but the rustc compiler uses the rustc_errors crate to generate these messages. I found this by looking at the README in librustc and searching the guide book for "message".
The search brought me to this section in the guide which covers error messages.
I am trying to add code in a Valgrind suppression file that removes errors and warnings that do not list the actual function calls or files causing the errors and warnings.
For instance:
<b>IPW</b> ==55555== Invalid write of size X
==55556== at 0xFFFFFFFF: ???
==55557== by 0xFFFFEEEE: ???
Therefore I am trying to create a few lines of code in a Valgrind suppression file that will suppress all of these instances where the function call or file causing the error/warning is unknown. Unfortunately I cannot find anything in the Valgrind docs that explain how to do this. Does anyone know how to suppress errors or warnings coming from unknown function calls or file?
First, verify that your changes aren't causing the issue and it's really an issue/false-positive within outside code.
If so, you can add the following line into your Valgrind suppression to get what you need:
obj:???
I got a problem recently that when I added a code to a lib, which is used by a dll, the dll cannot be loaded. I get an exception "Floating point invalid operation at xxx". When I comment out the code it works. The code added is just straight forward like creating a TADOQuery object, add the sql statment and the parameters, then do an open, check value etc. Nothing suspicious. Now when I uncomment the code and comment another chuck of code in the unit elsewhere, it starts to work. So obviously the newly added code was just tripping the issue caused elsewhere.
Now this error happens when LoadLibrary() call is invoked. There is no attach code. The DllMain, just has a return 1. When this happens the assembly code is always at FSTP tbyte ptr doing a System::Variant::Clear().
Anyone has come across such issues? Any tips on how to debug is also appreciated.
PS: It could also be Embarcadero's compiler issue. I recently figured out that the assembly generated for a combination of assignment and comparison is incorrect. The only suspicion here is the lib that the dll uses is large. When I do a clean and build of the lib, the total lines shows 5.7m. Maybe there is some setting for large libs?
IDE-XE4, c++ builder
OS-Win 7
Thanks,
Mathew Joy
C++Builder and Delphi have different default FPU settings than, say, MSVC and the DLLs written in it.
It probably goes like this: After DllMain, certain exceptions are masked to be hidden. But before the first floating point operation in C++Builder code occurs, that exception is unmasked and the exception occurs.
This is a known problem with C++Builder/Delphi floating point and DLLs.
If I compile with -O0 in ifort, the program can run correctly. But as long as I open the optimization option, like -O, -O3, -fast, there will be a SIGSEGV segmentation fault come out.
This error occurred in a subroutine named maketable(). And the belows are the phenomenons:
(1) I call fftw library in this subroutine. If I comment the sentences about fftw, it'll be ok. But I think it's not the fault of fftw, because I also use fftw in some other places of this code, and they are good.
(2) the fftw is called in a loop, and the loop can run several times when the program crashed. The segfault does not happen at the first time of entering the loop.
(3) I considered the stack overflow, but I don't think so now. I have the executable file complied by others long time ago, it's can be executed in my computer. I think that suggests it's not due to the system stack overflow.
The version of ifort is 10.0, of fftw is fftw-2.1.5. The cpu type is intel xeon 5130. Thanks a lot.
There are two common causes of segmentation faults in Fortran programs:
Attempting to access an element outside the bounds of an array.
Mismatching actual and dummy arguments in a procedure call.
Both are relatively easy to find:
Your compiler will have an option to generate code which performs array bounds checking at run time. Check your compiler documentation, rebuild your code and rerun it. If this is the cause of the problem you will get an error message identifying where your code goes awry.
Program explicit interfaces for any subroutines and functions in your program, or use modules so that the compiler generates such interfaces for you, or use a compiler option (see the documentation) to check that argument types match at compile-time.
It's not unusual that such errors (seem to) arise only when optimisation is turned up high.
EDIT
Note that I'm not suggesting that optimisation causes the error you observe, but that it causes the error to affect the execution of your program and become evident.
It's not unknown for incorrect programs to run many times apparently without fault only for, say, recompilation with a new compiler version to create an executable which crashes every time.
Your wish to switch off optimisation only for the subroutine where the segmentation fault seems to arise is, I suggest, completely wrong-headed. I expect my programs to execute correctly at any level of optimisation (save for clear evidence of a compiler bug, such things are not unknown). I think that by turning off optimisation you are sweeping a real problem with your program under the carpet, as it were.