i use xcode to write a c command line program,but i found the jump to define is not work well for the stand lib,i record a picture to show what happen,is that normal with xcode?
//
// main.c
// 0.4 xCodecantjump
//
// Created by Sen on 14-5-19.
// Copyright (c) 2014年 SLboat. All rights reserved.
//
#include <stdio.h>
#include <limits.h>
#include "main.h"
int main(int argc, const char * argv[])
{
int a = INT_MAX;
int c = INT_MIN;
int b = START;
// insert code here...
printf("some int: %d, %d, %d\n", a, c ,b);
return 0;
}
I suspect it is some kind of ObjC optimization.
Switching to C++ Source compilation solved this problem (with rebuild).
Related
I am using TrueStudio for my own stm32 project. I create 2 file foo.h and foo.c includes 2 functions
//foo.h
int add(int a, int b);
int sub(int a, int b);
and the implementation of timeout
//foo.c
#include "foo.h"
int add(int a, int b)
{
return a + b;
}
int sub(int a, int b)
{
return a - b;
}
After that, I used gcc to compile a static library foo.a. I continue to make the main file to implement the library to test.
//main.c
#include <stdio.h>
#include "foo.h"
int main(int argc, const char *argv[])
{
int a = 100, b = 50;
printf("sum is: %d\n", add(a,b));
printf("sub is: %d\n", sub(a,b));
return 0;
}
Next, I link the static foo lib to main.c to make an executable file using command is
gcc main.c foo.a -o main
I ran it and get the result is
sum is: 150
sub is: 50
That's worked fine prove my static lib was built successfully.
I begin to create a project stm32 from stmcubeMX and linker to this foo.a and the error appeared.
undefined reference to 'add'
undefined reference to 'sub'
My full code and setting path and build bellow
//main.c in TrueStudio
#include "main.h"
#include "foo.h"
int main(void)
{
HAL_Init();
SystemClock_Config();
int a = 200, b = 100;
int _sum, _sub;
_sum = add(a, b);
_sub = sub(a, b);
while (1)
{
/* USER CODE END WHILE */
/* USER CODE BEGIN 3 */
}
}
I am very grateful for any help, thanks!
Rename your foo.a file to libfoo.a, then change the C Linker -> Libraries -> Libraries to just foo with nothing in front or in the back. This should cause the final output to be -lfoo, which in turn causes linker to search for libfoo.a in the library search paths.
The following MEXed C code simply makes calls to magma to invert a matrix. The stand alone C code (which is also posted) works, but the mex code crashes.
I've triple checked the documentation, verified that other magma functions work as expected, and posted on the Magma forum and was told my code is fine (this post is a cross post from Magma forum). This means that the problem is with mex. I would like to know what is causing the mex code to seg-fault and how to get it to run as expected.
Mexed code:
#include <mex.h>
#include <stdlib.h>
#include <stdio.h>
#include <string.h>
#include <math.h>
#include <stddef.h>
#include <magma_v2.h>
#include <cuda_runtime.h>
void mat2magma(magmaDoubleComplex* p, double* pr, double* pi,int numElements)
{
int j=0;
for(j=0;j<numElements;j++){
p[j].x=pr[j];
p[j].y=pi[j];
}
}
void magma2mat(magmaDoubleComplex* p, double* pr, double* pi,int numElements)
{
int j=0;
for(j=0;j<numElements;j++){
pr[j]= p[j].x;
pi[j]= p[j].y;
}
}
/*gateway function*/
void mexFunction( int nlhs, mxArray *plhs[],
int nrhs, const mxArray *prhs[]) {
/*initialize magma*/
magma_init();
magma_queue_t queue = NULL;
magma_device_t dev;
magma_getdevice(&dev);
magma_queue_create(dev,&queue );
magma_int_t m,ldwork,info;
magma_int_t *piv;
magmaDoubleComplex *a,*da,*dwork;
/* Matlab -> Host */
m=mxGetM(prhs[0]);
piv=(magma_int_t*) malloc(m*sizeof(magma_int_t));
magma_zmalloc_cpu(&a,m*m);
mat2magma(a,mxGetPr(prhs[0]),mxGetPi(prhs[0]),m*m);
ldwork = m*magma_get_zgetri_nb(m);
/* Host -> GPU */
magma_zmalloc(&dwork,ldwork);
magma_zmalloc(&da,m*m);
magma_zsetmatrix(m,m,a,m,da,m,queue);
/*LU and Inverse */
magma_zgetrf_gpu(m,m,da,m,piv,&info);
magma_zgetri_gpu(m,da,m,piv,dwork,ldwork,&info);
/*GPU -> Host */
magma_zgetmatrix(m,m,da,m,a,m,queue);
/*Host -> Matlab*/
plhs[0] = mxCreateDoubleMatrix(m,m,mxCOMPLEX);
magma2mat(a,mxGetPr(plhs[0]),mxGetPi(plhs[0]),m*m);
free(a);
free(piv);
magma_free(dwork);
magma_free(da);
magma_queue_destroy(queue);
magma_finalize();
}
I compliled it with mex CC=gcc LDFLAGS="-lmagma -lcudart -lcublas" magmaZinv.c then from matlab, I ran:
a=magic(3)+magic(3)*1i;
magmaZinv(a)
Standalone C code:
#include <stdlib.h>
#include <stdio.h>
#include <string.h>
#include <math.h>
#include <stddef.h>
#include <magma_v2.h>
#include <cuda_runtime.h>
#include <sys/time.h>
#include <time.h>
/*gateway function*/
int main() {
/*initialize magma*/
magma_init();
magma_queue_t queue = NULL;
magma_device_t dev;
magma_getdevice(&dev);
magma_queue_create(dev,&queue );
int m,ldwork,info;
int *piv;
magmaDoubleComplex *a,*da,*dwork;
/* allocate and initialize a = magic(3)+magic(3)*1i; */
m=3;
piv=(int*) malloc(m*sizeof(int));
ldwork = m*magma_get_zgetri_nb(m);
magma_zmalloc_cpu(&a,m*m);
a[0].x=8;a[0].y=8;
a[1].x=3;a[1].y=3;
a[2].x=4;a[2].y=4;
a[3].x=1;a[3].y=1;
a[4].x=5;a[4].y=5;
a[5].x=9;a[5].y=9;
a[6].x=6;a[6].y=6;
a[7].x=7;a[7].y=7;
a[8].x=2;a[8].y=2;
/* Host -> GPU */
magma_zmalloc(&dwork,ldwork);
magma_zmalloc(&da,m*m);
magma_zsetmatrix(m,m,a,m,da,m,queue);
/*LU and Inverse */
magma_zgetrf_gpu(m,m,da,m,piv,&info);
magma_zgetri_gpu(m,da,m,piv,dwork,ldwork,&info);
/*GPU -> Host */
magma_zgetmatrix(m,m,da,m,a,m,queue);
/* display inv(a) */
for (int i=0;i<(m*m);i++){
printf("%f +%fi\n",a[i].x,a[i].y);
}
/* free memory */
free(a);
free(piv);
magma_free(dwork);
magma_free(da);
magma_queue_destroy(queue);
magma_finalize();
return 0;
}
I compiled with: gcc -lmagma -lcudart Ccode.c -o Ccode.o
My sys admin has figured out why the standalone C code works while the mexed C code does not. I'll post the reason here incase it is helpful to anyone facing the same issues when using Magma from within Matlab.
The version of Matlab I was using was 2014a. The supported compiler for this version is 4.7.x. I was using a higher version of gcc to compile the code. I've never had a problem with using different versions of GCC with matlab, despite the warning it gives, but for the above code it does matter.
Compile with the MKL_ilp64 flag when using Magma with Matlab to ensure that magma_int_t is int64.
With these two suggestions, Magma can be mexed into matlab with no problems.
I am using two functions to read doubles(read_double) and integers(read_integer) from a file.
The file format is as follows excluding the characters in the ( )'s
12345678 (ID)
3.78 (GPA)
3 (Year)
20.5 (Age)
There are 5 of these entries in the file to be read.
#include <stdio.h>
double read_double(FILE *infile)
{
double double1=0.0;
fscanf(infile, "%lf",&double1);
return double1;
}
int read_integer(FILE *infile)
{
int int1=0;
fscanf(infile, "%d",&int1);
return int1;
}
int main(void)
{
FILE *inp,*outp;
double gpa1=0.0;
int id1=0;
inp=fopen("input.txt","r");
outp=fopen("output.txt","w");
id1=read_integer(inp);
gpa1=read_double(inp);
printf("%d, %.2lf",id1,gpa1);
return 0;
}
When this code runs it prints the Student ID which is 12345678, it then prints 1.00. This is due to it reading first the ID again.
How would I make this read the second line and return the GPA (3.78)
I need to split the program so that main is in one file, and the other functions are on another.
Note: I will have to do this 5 times. Also we have not "learned while statements or "gets()" so please try not to use these or more complex methods.
As per the comments, what you want is to split the program in library and main.
So, the library will have the two functions:
/* lib.c */
#include <stdio.h>
double read_double(FILE *infile)
{
double double1=0.0;
fscanf(infile, "%lf",&double1);
return double1;
}
int read_integer(FILE *infile)
{
int int1=0;
fscanf(infile, "%d",&int1);
return int1;
}
The header file will help programs that use your library know what to expect from the functions (what types should be used for their arguments and return values). It only contains prototypes, and not the actual function definitions:
/* lib.h */
#include <stdio.h>
double read_double(FILE *infile);
int read_integer(FILE *infile);
And main uses them:
/* main.c */
#include <stdio.h>
#include "lib.h" /* <== here! use the prototypes so
the compiler will know that
read_double returns double! */
int main(void)
{
FILE *inp;
double gpa1=0.0;
int id1=0;
inp=fopen("input.txt","r");
id1=read_integer(inp);
gpa1=read_double(inp);
printf("%d, %.2lf",id1,gpa1);
return 0;
}
And compile them:
gcc lib.c main.c -o program
Now, the input file is:
12345678
3.78
3
20.5
And we run the program:
./program
12345678, 3.78
Now, if we remove the #include "lib.h" from main
#include <stdio.h>
int main(void)
{
FILE *inp;
double gpa1=0.0;
int id1=0;
inp=fopen("input.txt","r");
id1=read_integer(inp);
gpa1=read_double(inp);
printf("%d, %.2lf",id1,gpa1);
return 0;
}
and compile it with optimization,
gcc -O3 lib.c main.c
Then the result is wrong:
./program
12345678, 1.0
because the compiler generated code assuming all functions return integers. And doubles and integers are represented in a totally different way, internally.
I would like to report an intriguing bug I have. The piece of code below is supposed to print out 20 times "1.0". Instead, when compiling with icc (11.1) on my mac (snow leopard 10.6.8), I get unstable values (16 times "0.0" then 4 times "1.0"). I make use of several features in the code but none of them seems to have a bad syntax (no error during compilation, and valgrind reports no error during running). However if I change anything (even non used function - that's why I find it very strange), I get the correct output. Compiling with gcc gives the correct output as well.
But I think the strangest thing is that if I delete the function "function1", the bug disappears, although the function is NOT used in the code.
This is really odd, and now I fear that my code (which is much bigger than that) will be unstable. I need your help, I'm really puzzled by this. Is there anything wrong in the syntax?
main.c:
#include "main.h"
int main(argc,argv)
int argc;
char **argv;
{
Config para;
para.option1 = ONE;
para.a[0] = 0.0;
para.a[1] = 0.0;
para.a[2] = 0.0;
para.a[3] = 1.0;
int i;
double *x = (double *)malloc(20*sizeof(double));
for(i=0;i<20;i++) x[i] = 1.0;
for(i=0;i<20;i++) printf("%f \n", x[i]);
free(x);
function2(para);
return EXIT_SUCCESS;
}
void function1(int option){
switch(option){
case ONE: case TWO: case THREE: case MONE:
printf("MONE to THREE\n");
break;
case FOUR:
printf("FOUR\n");
break;
}
return;
}
void function2(const Config para){
if(para.option1 == FOUR){
printf("FOUR\n");
}
return;
}
main.h:
#include <string.h>
#include <stdio.h>
#include <stddef.h>
#include <math.h>
#include <stdlib.h>
#include <unistd.h>
#include <time.h>
#include <stdarg.h>
#define MONE -1
#define ONE 1
#define TWO 2
#define THREE 3
#define FOUR 4
typedef struct Config
{
int option1, option2;
double a[4];
} Config;
void function1(int option);
void function2(const Config para);
When digging more on the web, I found this bug report from Intel:
http://software.intel.com/en-us/articles/intel-compiler-and-xcode-322-linker-runtime-crash-with-switch-statement/
It seems to be related to how the icc compiler optimizes case statements. Their suggestions to solve the problem are the following:
1) Use Xcode 3.2.1 with 11.1 compiler.
2) Use 11.1 compiler with the option -use-asm with Xcode 3.2.2, 3.2.3, 3.2.4.
It should fix most cases but there are some cases when even generating object file through external assembler L* symbols still may appear in object file. Those cases are usually constant string literals placed in cstring section
3) Use Intel Composer XE.
My Xcode is version 3.2.6, but solution 2) solved my problem. I remain however quite puzzled about this (and the lack of documentation on the web).
Thanks.
#include <qapplication.h>
#include <qmainwindow.h>
#include "mainwindow.hpp"
#include "../RegisterOfErrors.hpp"
#include <clocale>
extern std::string* Error::DescriptionOfErrors;
int main (int argc, char *argv[])
{
std::locale::global(std::locale("en_US"));
setlocale(LC_ALL, "en_US");
FILE *conf = fopen("dupa.txt", "r");
float dupa;
fscanf(conf, "%f", &dupa);
printf("%f\n", dupa);
Error::setDescriptionOfErrors();
QApplication app(argc, argv);
MainWindow window;
window.show();
return app.exec();
}
My default locales are "es_ES", so "," is a decimal point.
It is my code. In the file "dupa.txt" is a number "1.0344" and it works correctly. However, deeper in the code I'm using the fann library, which is linked in g++ by "-ldoublefann" and read some data from files, and in this library works only ",".
The problem was caused by Qt.
There is some code
#include "doublefann.h"
#include "fann_cpp.h"
#include <clocale>
int main() {
setlocale(LC_ALL, "en_US");
const int max_neurons = 20;
const int neurons_between_reports = 1;
const double desired_error = 0.0001;
FANN::neural_net* repetition_ann;
repetition_ann = new FANN::neural_net();
repetition_ann->create_shortcut(2, 2, 1);
repetition_ann->cascadetrain_on_file("train.dat", max_neurons, neurons_between_reports, desired_error);
}
And this code works as I expect - It reads numbers, which have ".", from file "train.dat" ad prints numbers with ".".
The difference between those cases: in the first case the similiar code is somewhere in qtapplication, this code is independent.
Qt sets own locales, so the solution is adding a line: std::locale::global(std::locale("en_US")); and #include <QtCore>