gcc-11 compiler optimisation levels not working on Mac m1 - c

I have to complete a project for university where I need to be able to optimise using compiler optimisation levels.
I am using OpenMP and as a result I have got the gcc-11 compiler from brew.
I have watched this video https://www.youtube.com/watch?v=U161zVjv1rs and tried the same thing but I am getting an error:
gcc-11 -fopenmp jacobi2d1.c -o1 out/jacobi2d1
But I am getting the following error:
How do I do this?
Any advice would be appreciated

Optimization levels are specified with -O1 etc, using capital letter O, not lower-case letter o.
Lower-case -o1 specifies that the output file should be 1, and then out/jacobi2d1 is an input file to be linked, but it is an existing executable and you can't link one executable into another — hence the error from the linker.

Related

getting mixed C and inline assembly from gcc

I'm trying to diagnose why a seemingly small C function I wrote has produced a large .text section. I have used arm-elf-size and arm-elf-objdump to isolate the object file and function, but I have only been able to get these tools to produce assembly code, which I don't have the time to reverse engineer.
I tried using gcc switches "-g" which is supposed to be compatible with arm-elf-objdump -g, but it keeps producing the error "No debugging information found," which I've googled around for a bit with no clear cut answer (though other people had an identical problem).
Is there any other means of producing mixed C/assembly files so I can isolate the trouble spot in the function? Thanks!
Is there any other means of producing mixed C/assembly files so I can
isolate the trouble spot in the function?
gcc/gas can generate an assembler listing with C source; I recommend these compiler options:
-g -Wa,-adhln=filename.lst

compiling a C file with gcc to get x86 assembly code

I have a C file heapsort.c which Im trying to compile on a 64 bit linux machine to output the corresponding assembly code. Im using the following command:
gcc -02 -S heapsort.c
when I type this Im getting this error message
gcc:error: unrecognized option '-02'
I tried googling this error but nothing helpful came up. Any suggestions on how to navigate this error and get the x86 output?
The flag is -O2, not -02. That's a letter O for "optimization", not a number 0. You might want to look into using a font that makes the difference more obvious.
I suggest even (as every pointed out is is the letter O not the digit 0)
gcc -O2 -fverbose-asm -S heapsort.c
The -fverbose-asm will give you more generated comments in the assembly file heapsort.s
BTW, passing -Wall to GCC is always a good habit.
if you are really curious and want to understand a bit more the internal representations inside GCC try even
gcc -fdump-tree-all -O2 -S heapsort.c
but be prepared to get a lot of files.
You'll get hundreds of them, matching heapsort.c.*!
If you want some crude GUI interface to query the Gimple internal representation at some arbitrary source code position, consider using MELT. MELT is mostly a high-level domain specific language (with a Lisp-like syntax, powerful pattern matching, object oriented, functional, dynamically typed, ....) to extend GCC, but you can also use its (crude) probe to query interactively some of the GCC internal representations.
It should be -O2 with 'O' not "zero"
Try -O2 instead of -02. It's a letter 'O' and shorthand for "optimization level 2".

Function specific optimization in GCC 4.4.3

In reference to my earlier question here, I found out a possilbe bug in GCC 4.4.3 when it did not support following pragmas in the source code for optimization (although it says 4.4.x onwards it does!)
#pragma GCC optimize ("O3")
__attribute__((optimize("O3")))
Tried both above options but both gave compile time errors in the compiler itself(See the error message snapshot posted in the link mentioned above)
Now are there any further options for me to enable different optimization levels for different functions in my C code?
From the online docs:
Numbers are assumed to be an optimization level. Strings that begin with O are assumed to be an optimization option, while other options are assumed to be used with a -f prefix.
So, if you want the equivalent of the command line -O3 you should probably use the just the number 3 instead of "O3".
I agree that this is a bug and should not generate an ICE, consider reporting it along with a small test case to the GCC guys.
Now are there any further options for me to enable different optimization levels for different functions
in my C code?
Your remaining option is to place the functions in their own .c file and compile that .c file with the optimization flag you want.

ARM assembler: bad immediate value for offset

I am using GCC crosscompiler to compile to an ARM platform. I have a problem where, using opitmization -O3 gives me a "bad immediate value for offset (4104)" on a temp file ccm4baaa.s. Can't find this file either.
How do I debug this, or find the source of the error? I know that it's located somewhere in hyper.c, but it's impossible to find it because there is no errors showing in hyper.c. Only the cryptic error message above.
Best Regards
Mr Gigu
There have been similar known bugs in previous releases of GCC. It might just be a matter of updating your version of the GCC toolchain. Which one are you using currently?
In order to debug the problem and find the offending source, in these cases it helps to add the gcc option -save-temps to the compilation. The effect is that the compiler keeps the intermediate assembly files (and the pre-processor output) for you to examine.

Syntax error with different gcc version?

I wrote a program in C with Ubuntu Linux and now I need to port it over to a UNIX machine (or what I believe to be a UNIX box). It compiles fine on my Ubuntu with GCC but when I try to compile it with GCC on the UNIX box, it gives this error:
a.c: In function `goUpDir':
a.c:44: parse error before `char'
a.c:45: `newDir' undeclared (first use in this function)
a.c:45: (Each undeclared identifier is reported only once
a.c:45: for each function it appears in.)
a.c: In function `goIntoDir':
a.c:54: parse error before `char'
a.c:57: `newDir' undeclared (first use in this function)
a.c:57: `oldDir' undeclared (first use in this function)
The main problems seem to be the parse error before char (the others are related)
44 char newDir[50] = "";
54 char* oldDir = (char*)get_current_dir_name();
These are just simple C-style strings declarations. Is there a header file that I need to include to get it to work in UNIX?
P.S. what is the command to see what version of unix and which version of gcc you are using? Knowing this will allow me to be more specific in my question.
Thanks
If you are compiling pure C, variables must be declared on the beggining of the functions. I mention this because most people compile their C programs using C++ compilers, which offers then some resources not normally available to pure C compilers, the most common example being the // comment lines.
If you want to make sure your code is portable always use the -pedantic or -pedantic-errors.
This will provide warnings/errors where your code strays from standards compliance.
While we are on the subject. You should probably also turn on all the warnings. There are good reasons why the compiler warns you; when moving code from one platform to another these warnings are the source of potential bugs as the new hardware/OS/Compiler may not act the same as your current one.
Also use the correct GCC frontend executable: g++ Will treat *.c files like C++ files unless you explicitly tell it not too. So if you are compiling real C then use gcc not g++.
gcc -pedantic -Wall -Werror *.c
g++ -pedantic -Wall -Werror *.cpp
To help with your specific problem it may be nice to see line 43. Though the error says line 44 a lot of problems are caused by the proceeding line having a problem and the problem not being detected by the parser until you get to the first lexeme on the next line.
How did you copy the file over? Is it possible that you inserted something that shouldn't be there?
BTW: Please fix up your use of the code tag in your code - it's currently nearly impossible to read without using "view source" in my browser.
As for you end questions:
uname -a
gcc -v
When trying to write portable code, the following compiler flags will tell you about a lot of problems before you get as far as trying to compile the code on the next platform:
-std=c89 -pedantic -Wall
If you only need to target GCC on other platforms, not any other compilers, then you could try:
-std=gnu89 -pedantic -Wall
But I'd guess this might allow GNU extensions on a newer GCC that aren't supported on an older one. I'm not sure.
Note that although it would be nice if -pedantic was guaranteed to warn about all non-standard programs, it isn't. There are still some things it misses.
You will have to provide us with more context for the errors...at least one, probably several lines before lines 44 and 54. At a guess, if you give us the code from the start of the function definition before line 44 (perhaps line 40 or so) through to line 54 (or a few lines later - maybe line 60 - then we may be able to help. Something is up with the information before line 44 that is causing it to expect something other than 'char' at line 44; ditto (probably the same problem) at line 54.
The information is insufficient. The code above is at least as intersting and one has to
know if ones talks about ANSI C89 or ANSI C99. The first answer is wrong in that broad sense.
Regards
Friedrich
Steve,
The first error message says "parse error before 'char'". What is the code that precedes char? Is it a function declaration? Does it include any user-defined types or anything of the sort?
The most likely source of this error is that something shortly above line 44 uses a type or macro that's declared in a header file... that header file may differ between your own Ubuntu system and the one you're trying to compile on.
What UNIX is it? AIX, Ultrix, Minix, Xenix?
GCC has a "--version" flag:
gcc --version
To display the GCC version:
gcc --version
It might help to show the function so we could see the surrounding code. That is often the problem with "parse error before" type errors.

Resources