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.
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.
Is there a lint for Elixir (like for Javascript) which checks that every function has a type specification?
There is an Erlang compiler switch, +warn_missing_spec, which does this, but I'm having trouble getting it to work with Elixir at the moment, I think there is a bug with it's parsing of the ELIXIR_ERL_OPTS environment variable which is converting +warn_missing_spec into -warn_missing_spec which isn't a valid compiler option. I'm going to open an issue on the tracker, but thought you might like to know that this does indeed exist.
EDIT: As José mentioned below, the correct flag is ERL_COMPILER_OPTIONS. You can enable the missing spec warning during compilation by doing the following:
ERL_COMPILER_OPTIONS="warn_missing_spec" mix compile
Keep in mind you may get superfluous warnings from Elixir itself, for functions like __MODULE__. It should still be useful though. One last thing to note, I discovered this morning that there is a problem using this flag with mix compile, and that it's currently only warning about mix.exs. This is being fixed, and may even be fixed by the time you see this, but it's something to be aware of.
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.
I'm getting a "Compilation exited with code 134" when attempting to use the "LLVM Optimizing Compiler" switch for release iPhone builds, using MonoTouch 4.0.1.
I don't get much information from build output window at all - just:
"Compilation exited with code 134, command:"
MONO_PATH=(snip)/bin/iPhone/Release/LSiOS.app /Developer/MonoTouch/usr/bin/arm-darwin-mono --llvm --aot=mtriple=armv7-darwin,nimt-trampolines=2048,full,static,asmonly,nodebug,llvm-path=/Developer/MonoTouch/LLVM/bin/,outfile=/var/folders/03/033pAAGuHgGkIy4CorbVV++++TI/-Tmp-/tmp38107451.tmp/Newtonsoft.Json.MonoTouch.dll.7.s "(snip)/bin/iPhone/Release/LSiOS.app/Newtonsoft.Json.MonoTouch.dll"
Mono Ahead of Time compiler - compiling assembly (snip)/mscorlib.dll
What is odd is that in earlier command lines, there is a correlation between the DLL mentioned in the arm-darwin-mono command line and what is the compiling, but in this case it says "mscorlib.dll".
Any thoughts?
I have found a few cases (googling and from bugzilla.xamarin.com) where the error code 134 is related to Mono.Linker being too aggressive (removing something that's needed).
This is easy to confirm by turning off the linker, i.e. "Don't link" in Linker Options. If the build works then you can try isolating the assembly where the linker makes a mistake.
E.g. add a "--linkskip=mscorlib" to the mtouch extra parameters and re-enable linking. This will link everything (Link All) or all SDK (Link SDK assemblies) except the assembly you selected (mscorlib in the example). That's only a workaround and a bug report should be filled so the issue can be fixed properly (and get you all the linker advantages).
However be warned that there are other issues sharing the same error code, like:
http://ios.xamarin.com/Documentation/Troubleshoot#Error_134.3a_mtouch_failed_with_the_following_message.3a
YMMV
mtouch does its native builds in parallel so the logs can be confusing, e.g. you can see a bit of assembly X output followed by some assembly Y output.
Reading the full log might help you (or us) to pinpoint the issue.
I was having the exact same problem Scolestock. My app would build fine until I enabled llvm, then it was "Compilation exited with code 134, command" when trying to build the 7s for the app itself.
I'm elated to say that after 2 days of painstakingly whittling my app down to the core problem, I was able to isolate the issue to the usage of embedded dictionaries such as:
Dictionary<enum, Dictionary<enum, value>>
I was able to fix this by defining a class for the embedded dictionary and using that instead:
public class MyDefinition : Dictionary<enum, value>
{
}
...
public Dictionary<enum, MyDefinition>
Not sure if this will help you, but hopefully it'll help some poor soul who decides to use embedded dictionaries and runs into my same problem.
I unintentionally compiled the following statement:
manager.groupName - lastGroupName;
Instead of:
manager.groupName = lastGroupName;
I am trying to understand why the compiler does not even provide a warning for the former statement I unintentionally provided. The statement has no effect, even it if is legal to subtract pointers from one another.
Both groupName and lastGroupName are of type (NSString *).
The groupName property is declared as:
#property (nonatomic, retain) NSString *groupName;
Wondering if I should visit bugreporter or if there is a reason that XCode isn't providing a diagnostic.
This is a legal statement in C and thus also in Objective-C, so the compiler doesn’t have to warn about it. You could add the warning flag -Wunused-value to the compiler settings. This warns about statements without effect like this.
Generally there are lots of flags to tell the compiler what exactly to warn about. Everybody has different ideas what is OK, and what should be warned about. If the compiler emits too many warnings they become useless.
Also note that clang does indeed produce better warning and error messages it doesn’t mean that it will automatically produce more warnings. It also has the same flags for enabling and disabling certain warnings that gcc has.
XCode doesn't have the best syntax checking, although it's supposed to be much better in the version coming out soon (4.0 I believe, in beta now).
Registered developers can download XCode 4 beta which improves syntax checking in the "clang" 2.0 front-end. You can get some of that now by selecting "llvm" with clang 1.5 as your compiler instead of GCC. Apple's current recommendation is the GCC front-end and LLVM 1.5 back-end, but then you'll still be stuck with GCC's awful error messages.
I'd recommend downloading XCode 4 and trying the code out on that. You might find some significant bugs that you can go back and fix in XCode 3 before release.
In addition, periodically doing a "Clean All" and "Compile and Analyze" will find a lot of common mistakes. Highly recommended, especially if you're stuck on something.
This is legal syntax, so no error should be expected. It does seem useless, and a high quality compiler might issue a warning.
At runtime the result is a different matter. Unless I'm misremembering this is undefined behavior unless the two pointers are the same or at least point into the same array.