I have been having problems with ICU's rule-based Transliterator which turned out to be caused by a missing -O2 flag on debug builds using g++ 4.7.1. It was working fine when I did a release build (which had -O2), but when I built my project without that flag for debugging, the Transliterator object would never be created properly.
Transliterator* t = Transliterator::createFromRules(id, rules, UTRANS_FORWARD, parseError, status);
Without optimisation, t is assigned a null pointer and status is set to 32767, which translates to BOGUS UErrorCode when run through ICU's u_errorName().
The first thing I tried was to remove the -g debug flag from my build, but that made no difference to what createFromRules() returned. Only when I added -O2 did it create the Transliterator object.
Testing indicates that -O1, -O2 and -O3 all work as expected, and only -O0 causes this to happen.
Can someone explain why this should be the case?
You should not have different results with/without debugging. Can you create a small test case including rules, give the ICU version and OS/platform, and file a ticket? 4.7.1 was released 2 months ago. Could be a compiler bug (ICU has a long history of finding those!!) or latent bug. You can link the bug to this question and vice versa.
Related
I am about to test GHDL and Yosys as a replacement of EDA proprietary design flows, for my students. My point is about VHDL synthesis.
I have a fresh install of several tools : trellis (ECP5), yosys, nexpnr, fujprog (ulx3s).
GHDL is also installed for a longer time but it is supposed to include synthesis also (--synth option works).
ghdl -v
GHDL 1.0-dev (v0.37.0-208-g2c66a8bd) [Dunoon edition]
Compiled with GNAT Version: Community 2019 (20190517-83)
llvm code generator
It seems that I also need ghdl-yosys-plugin. However, the install does not work for me.
I get a bunch of error messages :
make GHDL=/opt/ghdl/bin/ghdl
yosys-config --exec --cxx -c --cxxflags -o ghdl.o src/ghdl.cc -fPIC -DYOSYS_ENABLE_GHDL -I/opt/ghdl/include -O
src/ghdl.cc:361:2: error: unknown type name 'Attribute'
Attribute attr = get_first_attribute (inst);
^
src/ghdl.cc:361:19: error: use of undeclared identifier 'get_first_attribute'
Attribute attr = get_first_attribute (inst);
^
src/ghdl.cc:379:7: error: use of undeclared identifier 'Id_Posedge'; did you mean 'Id_Edge'?
case Id_Posedge:
^~~~~~~~~~
Id_Edge
etc
I am missing something. Can someone help ?
Thanks in advance
JCLL
As I suspected (despite versioning that seemed correct), a fresh new install of GHDL fixed the issue.
i did some investigating: ghdl has undergone some restructuring, for proper FHS compliance. for example this commit https://github.com/ghdl/ghdl/commit/66cd5e0aa897b947533d269535fde4c0852472c2 and further commits show some renaming which ensures compliance with FHS conventions. files that used to be installed as /usr/local/include/ghdhsynth.h are now in /usr/local/include/ghdl
however because there are two completely separate pieces of software involved here (ghdl and yosys-ghdl-plugin) you have to (a) keep them in sync and (b) ensure that prior-installed ghdl headers are manually cleared out HOWEVER
manually deleting the installed files in /usr/local/include and reinstalling may not help if you cross over the threshold of commits from stable to developer releases on one but not the other, because older versions of yosys-ghdl-plugin were also not FHS convention-compliant. or, if you don't get them exactly right (i had to check the git log commit timestamps for both ghdl and ghdl-yosys-plugin in order to get a match), you get the general idea
if you really want to use a mis-matched version of ghdl and ghdl-yosys-plugin (YMMV here) then there are a few solutions:
manually copy the files in /usr/local/include/ghdl into /usr/local/include. this is a really dreadful hack that will need repeating each time you re-install ghdl.
modify the yosys-ghdl-plugin Makefile to include "-I/usr/local/include/ghdl" in CFLAGS or ALL_CFLAGS
in ghdl/synth.h and anywhere you see ghdl/synth.h used replace it with just "synth.h", likewise with synth_gates.h.
bear in mind that all of these are absolutely awful, totally not guaranteed to work, and you are way better off making sure that the versions being used are properly in sync.
it also does not help that some things from yosys latest master are also being removed, on which yosys-ghdl-plugin relies, to compile! as of writing i have found that tag yosys-1.13, ghdl-plugin commit c9b05e481423c, and ghdl commit 263c843ed49 will compile and work. however if i update to latest ghdl master (0e46300) microwatt fails to build, so i am sticking with 263c843 for now.
YMMV, hopefully however that gives you some insights rather than considering these complex and fantastically useful pieces of interlinked software to be opaque black boxes.
I get two warnings at the cpp compile phase with all the stan programs that I submit.
C:/Larry/R/win-library/3.4/BH/include/boost/config/compiler/gcc.hpp:186:0: warning: "BOOST_NO_CXX11_RVALUE_REFERENCES" redefined # define BOOST_NO_CXX11_RVALUE_REFERENCES
and
cc1plus.`exe: warning: unrecognized command line option "-Wno-ignored-attributes"
Since I don't get these warnings in submitting other Rcpp programs, I suspect that they are generated in the course of gc++ compiling of the Stan program. They seem to be harmless, but they are disconcerting. I see many other messages on Stack Overfkiw that include these warnings, but I have not found any explanations of them, nor ways to correct what is producing these warnings.
I am running R 3.4.3 and RStudio 1.1.383 in Windows 10 with Rtools 3.4.0.1964. I'd be grateful to anyone that will explain these warnings to me and what I have to do to correct them.
Don't worry about either of those.
The first is telling you that it redefines that Boost thing, but it is redefining it to what it was already set to.
The second is avoidable if you take -Wno-ignored-attributes out of the CXXFLAGS line of your ~/.R/Makevars file. It applies to a different compiler or version or something and is being ignored.
I've tried FauxPas source code analyzer and it showed me that I am missing -DNDEBUG flag, with next description:
This argument disables the C standard library assertion macro (as
defined in assert.h).
Though, when I check my build settings I found very similar by description flag -DNS_BLOCK_ASSERTIONS=1.
So I wonder now. Do I really need the flag that FauxPas suggests or I am fine with the one I have?
NDEBUG disables assert(), which is part of the C standard library. NS_BLOCK_ASSERTIONS disables NSAssert() which is part of Foundation. You generally will require both if you have both kinds of assertions in your code.
When I write a routine to test the performance of two stuffs, which optimization flags should I use? -O0, -O2, or -g ?
You should test the performance of your code using each of the settings. Ideally the larger the number -O0, -O1, -O2, -O3, implies better performance as there is more/better optimization, but that is not always the case.
Likewise depending on how your code is written some of it may be removed in a way that you didnt expect from the language or the compiler or both. So not only do you need to test the performance of your code, you need to actually test the program generated from your code to see that it does what you think it does.
There is definitely not one optimization setting that provides the best performance for any code that can be compiled by that compiler. You have to test the settings and compiler on a particular system to verify that for that system the code does indeed run faster. How you test that performance is filled with many traps and other error producing problems that you can easily misunderstand the results. So you have to be careful in how you test your performance.
For gcc folks usually say -O3 is risky to use and -O2 is the best performance/safe. And for the most part that is the case -O2 is used enough to get many bugs flushed out. -O2 does not always produce the fastest code but it generally produces faster code that -O0 and -O1. Use of debuggers can defeat the optimization or remove it all together, so never test for performance with a debugger based build or using a debugger. Test on the system as the user would use the system, if the user uses a debugger when they run your program then test that way, otherwise dont.
In GCC -O0 disables compiler code optimizations at all. -g adds debugging info to executable so you can use debugger.
If you want to enable speed optimizations use flags -O1 or -O2. See man gcc(1) for more information.
If you want to measure performance of your code use profiler such as valgrind or gprof.
Actually, if you care about performance you should definitely use -O3. Why give away potential optimisations?
And yes, there’s a small but measurable difference between -O2 and -O3.
-g is not an optimisation flag but it can prevent optimisations so it must be disabled for representative benchmarks.
I have a C project which was previously being built with Codesourcery's gnu tool chain. Recently it was converted to use Realview's armcc compiler but the performance that we are getting with Realview tools is very poor compared to when it is compiled with gnu tools. Shouldnt it be opposite case i.e it should give better performance when compiled with Realview's tools? What am I missing here. How can I improve the performance with Realview's tools?
Also I have noticed that if I run the binary produced by Realview Tools with Lauterbach it crashes but If I run it using Realview ICE it runs fine.
UPDATE 1
Realview Command line:
armcc -c --diag_style=ide
--depend_format=unix_escaped --no_depend_system_headers --no_unaligned_access --c99 --arm_only --debug --gnu --cpu=ARM1136J-S --fpu=SoftVFP --apcs=/nointerwork -O3 -Otime
GNU GCC command line:
arm-none-eabi-gcc -mcpu=arm1136jf-s
-mlittle-endian -msoft-float -O3 -Wall
I am using Realview Tools version 4.1 and GCC version 4.4.1
UPDATE 2
Lauterbach issue has been solved. It was being caused because of Semihosting as the semihosting SWI was not being handled in Lauterbach environment. Retargeting the C library to avoid Semihosting did the trick and now my program runs successfully with Lauterbach as well as Realview ICE. But the performance issue is as it is.
Since you have optimisations on, and in some environments it crashes, it may be that your code uses undefined behaviour or other latent error. Such behaviour can change with optimisation, or even break altogether.
I suggest that you try both tool-chains without optimisation, and make sure that the warning level is set high, and you fix them all. GCC is far better that armcc at error checking so is a reasonable static analysis check. If the code builds clean it is more likely to work and may be easier for the optimiser to handle.
Have you tried removing the '--no_unaligned_access'? ARM11s can typically do unaligned access (if enabled in the startup code) and forcing the compiler/library to not do them may be slowing down your code.
The current version of RVCT says of '--fpu=SoftVFP':
In previous releases of RVCT, if you
specified --fpu=softvfp and a CPU with
implicit VFP hardware, the linker
chose a library that implemented the
software floating-point calls using
VFP instructions. This is no longer
the case. If you require this legacy
behavior, use --fpu=softvfp+vfp.
This suggests to me that if you perhaps have an old version of RVCT the behaviour will be to use software floating point regardless of the presence of hardware floating point. While in the GNU version -msoft-float will use hardware floating point instructions when an FPU is available.
So what version of RVCT are you using?
Either way I suggest that you remove the --fpu option since the compiler will make an implicit appropriate selection based on the --cpu option selected. You also need to correct the CPU selection, your RVCT option says --cpu=ARM1136J-S not ARM1136FJ-S as you told GCC. This will no doubt prevent the compiler from generating VFP instructions, since you told it it has no VFP.
The same source code can produce dramatically different binaries due to factors like. Different compilers (llvm vs gcc, gcc 4 vs gcc3, etc). Different versions of the same compiler. Different compiler options if the same compiler. Optimization (on either compiler). Compiled for release or debug (or whatever terms you want to use, the binaries are quite different). When going embedded, you add in the complication of a bootloader or rom monitor (debugger) and things like that. Then add to that the host side tools that talk to the rom monitor or compiled in debugger. Despite being a far better compiler than gcc, arm compilers were infected with the assumption that the binaries would always be run on top of their rom monitor. I want to remember that by the time rvct became their primary compiler that assumption was on its way out, but I have not really used their tools since then.
The bottom line is there are a handful of major factors that can affect the differences between binaries that can and will lead to a different experience. Assuming that you will get the same performance or results, is a bad assumption, the expectation is that the results will differ. Likewise, within the same environment, you should be able to create binaries that give dramatically different performance results. All from the same source code.
Do you have compiler optimizations turned on in your CodeSourcery build, but not in the Realview build?