Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 5 years ago.
Improve this question
EDIT:
NVM ... I found the error after a line by line scan of this 2000 line shader. This should have broke during compile yet it passed ... why? It is literally a line that's like this:
uv2.xy -= (someVec3Var.x * someFloatScale) + (anotherVec3Var2* anotherFloatScal);
So basically the error is that the first one would generate a float and it is added to a vec3 and it's assigned to a vec2 .... This code works in HSLSL :(
I'm seeing something really weird ... my GLSL compiles but when it links, it complaints for my fragment shader:
0(1805) : error C7011: implicit cast from "vec3" to "vec2"
0(1805) : error C7011: implicit cast from "vec4" to "vec3"
0(1808) : error C7011: implicit cast from "vec3" to "vec2"
0(1808) : error C7011: implicit cast from "vec4" to "vec3"
I used to have those errors during compile time and I fixed all of them such that it's all good ... but why would they show up in link ? These also happen on different lines than the compile error that was happening prior to my fix. Any reason this would only happen during link time? Could this be due to the fact that I have uniforms name the same across vertex and fragment? I read something in OpenGL ES, they would map to the same memory ... which is fine with me because I want them to be the same variable ... (else why would I name them the same?).
Thanks!
Many GLSL implementations don't actually compile the shaders until you call LinkProgram. When you call CompileShader it just does a basic syntax sanity check. That's because to get reasonable performance on most GPUs, whole program optimization is needed. Thus, you might see what one would normally consider "compile" errors only when you link.
Related
I have a derived-type with pointer (or allocatable) component
type Tmy
real, dimension(:), pointer :: vals
integer :: nVals
end type Tmy
And I want to create a parameter, e.g. to pass it to a subroutine as intent(in):
type (Tmy), parameter, public :: my_missing = Tmy(null(), 0)
Currently a similar code compiles fine to me by GNU Fortran (Spack GCC) 9.4.0, but introduction of the parameter triggers numerous strange errors in another module that uses the current one. The using module has variables of the type, but no reference to the parameter. The first error is triggered in a derived-type declaration with default initialization:
550 | logical, dimension(:,:), pointer :: ifValid => null()
| 1
Error: Cannot change attributes of USE-associated symbol null at (1)
and follows by numerous similar errors and complains about missing members in various structures. If I comment out the parameter declaration the code compiles and runs just fine.
So the questions are:
How introducing a parameter in one module can trigger compilation errors in another module, given that the name my_missing is unique within the project? Or is it just a bug in the compiler?
Is introducing such a parameter a valid practice in Fortran?
If it is valid, what is the effect of assigning this parameter to a structure that has vals already allocated (in case if vals is declared as allocatable)?
PS Yes, I know that allocating pointers is a bad idea. I try to turn them to allocatables bit by bit..
UPD: The issue is reproducible with two different versions of gfortran, but only at one specific computer. Also I did not manage to compile any observable MWE so far..
UPD2: Thank you all, who commented so far. It seems clear that there is no breaking of Fortran standards in my examples here. MWE is of little use since the issue is reproducible only at one computer. I'll then ask for help from our HPC staff and come back once something interesting found.
TL;DR
Bug in gfortran-9 (9.4.0 from Spack, 9.5.0-1ubuntu1~22.04). Other gfortran compilers available for Ubuntu 22.04 (10.4.0-4ubuntu1~22.04,11.3.0-1ubuntu1~22.04, and 12.1.0-2ubuntu1~22.04) work just fine.
Details
I have managed to reproduce the issue in Ubuntu 20.04, by changing to gcc-9. Here is the way to reproduce it:
Make sure that gcc-9 is called for gfortran
Checkout and compile https://github.com/fmidev/silam-model/ See README there for more details
Edit source/namelist.silam.mod.f90 with adding after the definition of Tsilam_namelist (around l. 257):
! Enabling these lines causes a mysterious error at GNU Fortran 9.4.0 and 9.5.0
type(Tsilam_namelist), parameter, private :: silam_namelist_missing = Tsilam_namelist( &
& null(), int_missing, int_missing, int_missing, &
& silja_false, "Missing_namelist" &
& )
make clean
make full
The problematic lines were added in our development branch quite some time ago. The only way to pinpoint the line that triggers the bug was a bisect on many revisions. Luckily, the revision that introduced the trigger was small.
The specific bug in gcc-9 responsible for the problem is yet unknown, but it is more of an academic interest...
Thank everyone once again for valuable comments!
I recently (finally!) upgraded to VS2019 from VS2008 and I ran across a ridiculous error that I had never seen before - MSB6006: "CL.exe" exit code 2.
After some searching, Microsoft suggested a screwed up Path variable. Nope!
And then a lot of other people on the interweb had the same error for screwy and seemingly unrelated reasons.
I finally found the problem by disabling sections of my code one-at-a-time. It turned out I forgot to return a value in a non-void function.
It was something like this:
class myClass{
int classMember;
....
int memberFunc(int input){
int out = input * classMember;
//should have returned 'out' here but I didn't.
}
};
My two questions are:
1) What in the HOLY **** happened to the nice, user friendly compiler error in VS2008 that used to tell me I had forgotten to return a value? (not that -ahem- I do that very often.)
2) Is there a way to get the nice error message back? Some setting buried somewhere? Perhaps even some sort of default configuration VS2019 is using for my projects that I can dumb-down?
And next, here's a thought for any others who are beating their heads against the MSB6006 wall: The fact that I got this opaque build error when VS2019 SHOULD have caught a very simple and explainable compile-time error implies that others may be seeing it for similar reasons - that is, something simple that you would normally expect the compiler to catch for you isn't being caught... Systematically disabling sections of code worked for me.
I've been asked to use a library provided here and I was following the instructions to build it in Windows, those are located here.
Now I downloaded Intel Parallel Studio XE as requested and did everything as in the instructions but there's a problem inside the code that I can't figure out completely how to solve it. The compiler says Error #6362: The data type(s) of the argument(s) are invalid..
The lines that give trouble are both the same: call free(adr(n))
And the declaration of adr(n) is what I don't know if it is correct or not since I haven't touched FORTRAN 77 in a while. It is: adr(n) = malloc(length*ipa) where ipa and length are properly defined but I don't know if adr(n) is already defined somewhere else in the header files. Should I just add a declaration at the top (I heard FORTRAN needs declarations at the top) or should I do something else? What I know is that adr(n) should be length*ipa bytes but not if it should be a specific type or not, and I don't remember how to do something along the lines of char * adr = (char *) malloc(length*ipa); as I would do in C.
This was asked and answered at https://software.intel.com/en-us/forums/intel-visual-fortran-compiler-for-windows/topic/801638 The source being used declared the variable as integer*8 (nonstandard), but a 32-bit build was being done. Since the Intel compiler treats malloc and free as intrinsics, it detected the mismatch.
In Fortran when you pass an array to a subroutine you do not include an index. By passing adr(n) you are only passing the nth element of adr to the subroutine. You most likely want to pass the whole array like this:
call free(adr)
If this does not do it, please post a Minimal, Complete, and Verifiable example.
Welcome to stackoverflow. I suggest you take the tour. and learn how to ask good questions.
I'm currently trying to compile a python project (5files # total 1200 lines of code) with shedskin.
I tried shedskin Version 0.9.3 and 0.9.2 both result in the same errors.
This is the first error I encounter:
mmain.cpp: In function ‘__shedskin__::list<__shedskin__::list<int>*>* __mmain__::list_comp_3(__shedskin__::__ss_int)’:
mmain.cpp:133: error: no matching function for call to ‘__shedskin__::list<__shedskin__::list<int>*>::append(__shedskin__::list<double>*)’
Moreover, I after running shedskin (i.e. before typing "make") I receive many warnings - all related to dynamic types:
*WARNING* mmain.py: expression has dynamic (sub)type: {float, int, list}
However, shedskin seems to work flawlessly with the provided examples since I can compile and execute them without any errors.
Do you have an idea where to look for the error or what the error is related to?
mmain.cpp:133: error: no matching function for call to ‘__shedskin__::list<__shedskin__::list<int>*>::append(__shedskin__::list<double>*)’
This error means that you've got a Python object that shedskin has inferred as a list of lists of ints, but now you're trying to append something that it's inferred as a list of floats. You can get that by, for example, doing this:
a = [[1], [2]]
b = 1.0
a.append([b])
However, from the line above it, the function name is list_comp_3. Unless you've actually named a function list_comp_3 (which you haven't), this is a list comprehension. So, you may be doing something like this:
a = [1, 2, 3.0]
b = [[i] for i in a]
You may be wondering why it let you get away with a but failed on b. Well, first of all, it probably didn't really let you get away with it, if you've got dozens of warnings you haven't dealt with. But second, as the documentation says:
Integers and floats can often be mixed, but it is better to avoid this where possible, as it may confuse Shed Skin:
a = [1.0]
a = 1 # wrong - use a float here, too
As for the warnings, they can mean anything from "you got away with it this time, but don't expect to always do so" to "an error is coming up related to this" to "this will compile, but to something less efficient than the original Python code rather than more" to "this will compile, but to something incorrect".
More generally, it sounds like your program just can't be statically typed by shedskin's inference engine. Without actually seeing your code, it's impossible to tell you what you're doing wrong, but if you re-read the Typing Restrictions and Python Subset Restrictions sections of the docs, that should give you ideas of what kinds of things are and aren't appropriate.
to avoid confusion, please note that both code snippets provided by 'abartert' compile and run fine when compiled separately (shedskin 0.9.3). my guess is also that the problem should disappear after resolving the dynamic typing warnings. if not, I'd be very interested in seeing the program you are trying to compile, or at least enough of it to reproduce the problem.
update: btw, as of 0.9.1 or so, shedskin should be smarter about int and float mixing. if it encounters something that would lead to broken or inefficient c++ code (because of necessary run-time conversion of sorts), it should now usually complain with an 'incompatible types' warning. so perhaps it's time to update this part of the documentation slightly for 0.9.3.
I feel so dumb right now:
moveSequence look(COORD xyBeatle, fieldd &field);
what could be so wrong about that, to give a syntax error?
error C2061: syntax error : identifier 'fieldd'
What I am trying to do is pass an a reference of a class fieldd to look() via:
moveSequence sequence = look(xy, m_field);
It doesn't seem to recognize the type field
Actually I am being littered with errors all about things that should be type field are having type int assumed ect..
This is after a long week of refactoring and not even getting back to the point of compiling so I cannot tell what change immediately caused this.
edit: now I am noticing that intellisense is underlining, for only a moment, intermittently the places where the compiler is throwing real errors..... I disabled PCH and rebuilt but this didn't work.
edit2:
The variable name was NOT the problem, that was one of the first things I Tried.
edit3:
I was finally able to catch one of the intellisense errors and it read "identifier "fieldd" is undefined" before shortly changing to "class fieldd" I think this might be a problem with the headers. this guys problem was headers: http://www.gamedev.net/topic/555445-solvederror-c2061-syntax-error--identifier-t3dobject/
field appears to be a type name. Use a different variable name.
We really need more code to identify your problem but I wonder if you need to forward declare fieldd since you have refactored the code into different files, perhaps the headers are not included correctly or the dependencies no longer make sense?
changing your declaration to: moveSequence look(COORD xyBeatle, class fieldd &field)
might give you more information.
fieldd is not recognized as a type if I understand well.
Does fieldd foobar works over the line triggering the error? If not it's likely that you're missing the include declaring fieldd.