Compiling this code
int main(int argc, char **argv)
{
int xor = 0;
}
via
g++ main.cpp
results in:
internal compiler error: Segmentation fault
with
i686-apple-darwin10-g++-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5659).
Renaming the variable removes the error.
Question: Is gcc from Apple crap?
Any time your compiler segfaults, it's a bug. Your already reduced test case is a perfect candidate to be reported to GCC.
and_eq, bitand, bitor, compl, not, not_eq, or, or_eq, xor and xor_eq are keywords which are enabled with -ansi or -foperator-names
you have one of those switches enabled?
check also out: this
Related
I have the following code:
#include <ctype.h>
void myfn(void)
{
uint8_t any0 = 'c';
char any1 = 'c';
if (isprint(any0))
{
return;
}
if (isprint(any1))
{
return;
}
}
When I compile it with gcc for arm, I get the following error:
error: array subscript has type 'char' [-Werror=char-subscripts]
if (isprint(any1))
^
If I pass an unit8_t to isprint, the compiler is happy, but not if I pass it a char.
The prototype for isprint is:
int isprint(int c);
It expects an int as parameter, I give it a char.
I would expect it to complain about the type of the parameter, but not something unrelated as 'array subscript'.
The error goes away if I change the call to:
if (isprint((uint8_t)any1))
Is there something I have overlooked?
The compiler I use is:
GNU C (15:4.9.3+svn231177-1) version 4.9.3 20150529 (prerelease) (arm-none-eabi)
compiled by GNU C version 5.2.1 20151129, GMP version 6.1.0, MPFR version 3.1.3, MPC version 1.0.3
warning: MPFR header version 3.1.3 differs from library version 3.1.4.
Commandline options:
'-v' '-fshort-enums' '-specs=nosys.specs' '-specs=nano.specs'
'-mfloat-abi=soft' '-save-temps' '-Werror' '-Wpedantic' '-pedantic-errors' '-mthumb' '-fno-builtin' '-mcpu=cortex-m0' '-Wall' '-std=gnu99' '-ffunction-sections'
'-fdata-sections' '-fomit-frame-pointer' '-mabi=aapcs' '-fno-unroll-loops' '-ffast-math' '-ftree-vectorize' '-Og' '-g'
If I compile the same code with the gcc compiler for AVR /usr/bin/avr-gcc (using similar commandline options and I intentionally added option -Werror=char-subscripts), it doesn't complain about isprint. So it seems to be something related to the ARM compiler.
It turned out that the implementation of isprint for ARM is a macro and, more importantly, header file ctype.h contains the following comment:
These macros are intentionally written in a manner that will trigger
a gcc -Wall warning if the user mistakenly passes a 'char' instead of
an int containing an 'unsigned char'.
For AVR, header file ctype.h contains:
extern int isprint(int __c) __ATTR_CONST__;
This explains the difference in behaviour when compiling for AVR or for ARM.
I'm using the official release of ARM GCC 2018 Q4 Major. For this C code:
int main(void) { return 0; }
the compiler produces a warning:
$ arm-none-eabi-gcc -mstructure-size-boundary=32 main.c
cc1.exe: warning: option '-mstructure-size-boundary' is deprecated
Is it possible to suppress this warning? The flag -Wno-deprecated has no effect.
I need to use the -mstructure-size-boundary option because I need to link against someone else's closed source compiled libraries that used the same setting. (Well, I guess I could edit their headers and manually set trailing struct padding but that would not be Plan A).
It's just a piece of "hello world" C++ code.
#include <stdio.h>
int main(int argc, char* argv[])
{
printf("hello");
return 0;
}
I compiled the code with clang 3.9. The command is: clang -m32 hello.cpp -o hello.exe, and the target executable size is about 44kb. It didn't make any difference with "O3" option added to the command.
While I compiled it with visual studio 2010, the size of the target executable file is only 6kb for release version and 28kb for debug version.
Could anyone help to explain the difference between the two versions' binary.
Any help would be appreciated.
I use clang-cl that accepts the flag /MD instead of clang. Problem resolved. I still need to explore what's the difference between clang and clang-cl.
all.
Compiling simple stuff using the gcc toolchain for several years, today I ran against a curious phenomenon.
I installed Kubuntu 14.04 to a common desktop i686 machine with gcc 4.8.2 in it. But then, trying to build some well coded stuff pulled out from my local repository, I ran against tons of 'undefined reference to' messages. The code compiles, links und runs well under Ubuntu 11.04 / gcc 4.5.2.
I checked the linking process (by -Wl,--verbose to gcc), think it works. It finds all libraries I specify in the link command. An objdump -t myLib.so brings exactly the symbols I'd expect - but the linker doesn't see them.
Checking the pthread library also brings according symbols, except they are suffixed with some #GLIBC... stuff. Didn't check linker/loader tricks so far.
A sample like
#include <stdio.h>
#include <unistd.h>
#include <pthread.h>
static void *fooo (void *xxx) {
char *txt = (char*)xxx;
printf("My job is to print this :'%s'. Bye now!\n", txt);
return 0;
}
int main (int argc, char *argv[]) {
pthread_t thd;
pthread_create(&thd, NULL, fooo, "A POSIX thread");
sleep(1);
return 0;
}
runs very well on the old system just saying
gcc -l pthread fooo.c && ./a.out
but breaks at the linking step with 4.8.2.
Any idea would be very welcome.
.M
Thanks to sfrehse, JoachimPileborg et al!
Indeed, success depends on argument order. I knew this fact for static linking, but it is new in processing of shared objects with gcc.
Does someone know what the background of this improvement is? It breaks innumerable build processes, and I guess thousands of tomatoes are being made ready against gcc.gnu.org .....
.M
I am beginning Zed Shaw's Learn C The Hard Way. I have downloaded XCode and the Command Line Tools. But when I compile the very first program:
int main(int argc, char *argv[]) {
puts("Hello world.");
return 0;
}
I get this warning:
ex1.c:2:1: warning: implicit declaration of function 'puts' is invalid
in C99
[-Wimplicit-function-declaration]
The program does compile and execute correctly.
I'm using OSX 10.8.3. Entering 'gcc -v' gives:
Using built-in specs. Target: i686-apple-darwin11 Configured with:
/private/var/tmp/llvmgcc42/llvmgcc42-2336.11~182/src/configure
--disable-checking --enable-werror --prefix=/Applications/Xcode.app/Contents/Developer/usr/llvm-gcc-4.2 --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-prefix=llvm- --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib --build=i686-apple-darwin11 --enable-llvm=/private/var/tmp/llvmgcc42/llvmgcc42-2336.11~182/dst-llvmCore/Developer/usr/local
--program-prefix=i686-apple-darwin11- --host=x86_64-apple-darwin11 --target=i686-apple-darwin11 --with-gxx-include-dir=/usr/include/c++/4.2.1 Thread model: posix gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00)
Please help.
You need to include stdio.h, i.e.
#include <stdio.h>
at the start to import the function definition.
This "book" should be renamed to Learn To Hate C By Following Meaningless Examples That Are Blatantly Wrong.
The correct code in modern C would be plain and easy
#include <stdio.h> // include the correct header
int main(void) { // no need to repeat the argument mantra as they're not used
puts("Hello world.");
} // omit the return in main as it defaults to 0 anyway
While the original example
int main(int argc, char *argv[]) {
puts("Hello world.");
return 0;
}
would have been just plain bad in 1989, in 1999 (that is 18 years prior to the writing of this answer, and almost as many years before the "book" was written) the C standard was revised. In the C99 revision, this kind of implicit function declaration was made illegal - and naturally it remains illegal in the current revision of the standard (C11). Thus using puts without #includeing the relevant header, i.e. prepending #include <stdio.h> (or declaring the puts function with int puts(const char*);) is a constraint error.
A constraint error is an error that must cause the compiler output a diagnostics message. Additionally such a program is considered an invalid program. However the peculiar thing about the C standard is that it allows a C compiler to also successfully compile an invalid program, though a compiler may as well reject it. Therefore, such an example is hardly a good starting point in a book that is supposed to teach C to beginners.