Why does MinGW GCC tolerate missing return types even with `-pedantic-errors`, unlike regular GCC? - c++

Here's the code:
main() {}
On gcc.godbolt.org, both GCC 10.1 and Clang 10 (with -Wall -Wextra -pedantic-errors -std=c++20) refuse to compile this.
GCC: error: ISO C++ forbids declaration of 'main' with no type [-Wpedantic]
Clang: error: C++ requires a type specifier for all declarations
But on my local machine, MinGW GCC happily accepts this code without any errors or warnings (with the same flags). This is not something new; this specific peculiarity was there for years.
Why does MinGW GCC behave differntly from the regular GCC in this case? Are there any flags to make it diagnose this error?
I got my GCC from MSYS2. It identifies as
# g++ --version
g++.exe (Rev3, Built by MSYS2 project) 10.1.0
Copyright (C) 2020 Free Software Foundation, Inc.
Clang 10 on the same machine does reject the code (the official binary, using libstdc++ from this GCC).

As noted by #ssbssa, MinGW GCC enables -fms-extensions by default, and it's one of the effects of that flag.
Compile with -fno-ms-extensions to fix that.

Related

gcc-11 macOS doesn't compile [duplicate]

What is the difference between g++ and gcc? Which one of them should be used for general c++ development?
gcc and g++ are compiler-drivers of the GNU Compiler Collection (which was once upon a time just the GNU C Compiler).
Even though they automatically determine which backends (cc1 cc1plus ...) to call depending on the file-type, unless overridden with -x language, they have some differences.
The probably most important difference in their defaults is which libraries they link against automatically.
According to GCC's online documentation link options and how g++ is invoked, g++ is equivalent to gcc -xc++ -lstdc++ -shared-libgcc (the 1st is a compiler option, the 2nd two are linker options). This can be checked by running both with the -v option (it displays the backend toolchain commands being run).
GCC: GNU Compiler Collection
Referrers to all the different languages that are supported by the GNU compiler.
gcc: GNU C      Compiler
g++: GNU C++ Compiler
The main differences:
gcc will compile: *.c\*.cpp files as C and C++ respectively.
g++ will compile: *.c\*.cpp files but they will all be treated as C++ files.
Also if you use g++ to link the object files it automatically links in the std C++ libraries (gcc does not do this).
gcc compiling C files has fewer predefined macros.
gcc compiling *.cpp and g++ compiling *.c\*.cpp files has a few extra macros.
Extra Macros when compiling *.cpp files:
#define __GXX_WEAK__ 1
#define __cplusplus 1
#define __DEPRECATED 1
#define __GNUG__ 4
#define __EXCEPTIONS 1
#define __private_extern__ extern
For c++ you should use g++.
It's the same compiler (e.g. the GNU compiler collection). GCC or G++ just choose a different front-end with different default options.
In a nutshell: if you use g++ the frontend will tell the linker that you may want to link with the C++ standard libraries. The gcc frontend won't do that (also it could link with them if you pass the right command line options).
What is the difference between g++ and gcc?
gcc has evolved from a single language "GNU C Compiler" to be a multi-language "GNU Compiler Collection". The term gcc may still sometimes refer to the "GNU C Compiler" in the context of C programming.
man gcc
# GCC(1) GNU
#
# NAME
# gcc - GNU project C and C++ compiler
However, g++ is the C++ compiler for the GNU Compiler Collection. Like gnat is the Ada compiler for gcc. see Using the GNU Compiler Collection (GCC)
For example, the Ubuntu 16.04 and 18.04 man g++ command returns the GCC(1) manual page.
The Ubuntu 16.04 and 18.04 man gcc states that ...
g++ accepts mostly the same options as gcc
and that the default ...
... use of gcc does not add the C++ library. g++ is a program
that calls GCC and automatically specifies linking against the C++
library. It treats .c, .h and .i files as C++ source files instead of
C source files unless -x is used. This program is also useful when
precompiling a C header file with a .h extension for use in C++
compilations.
Search the gcc man pages for more details on the option variances between gcc and g++.
Which one should be used for general c++ development?
Technically, either gcc or g++ can be used for general C++ development with applicable option settings. However, the g++ default behavior is naturally aligned to a C++ development.
The Ubuntu 18.04 'gcc' man page added, and Ubuntu 20.04 continues to have, the following paragraph:
The usual way to run GCC is to run the executable called gcc, or machine-gcc when cross-compiling, or machine-gcc-version to run a specific version of GCC. When you compile C++ programs, you should invoke GCC as g++ instead.
Side Note: In the case of the Xcode.app embedded toolchain, g++ simply links to gcc. Thus, g++ invocations may vary on a per-toolchain basis.
ls -l /Applications/Xcode.app/Contents/Developer/usr/bin
# …
# lrwxr-xr-x 1 root wheel 3 Apr 27 2021 g++ -> gcc
# -rwxr-xr-x 1 root wheel 167120 Nov 23 20:51 gcc
### -- versus --
which -a g++
# /usr/bin/g++
ls -l /usr/bin/g++
# -rwxr-xr-x 1 root wheel 137616 Jan 1 2020 /usr/bin/g++
One notable difference is that if you pass a .c file to gcc it will compile as C.
The default behavior of g++ is to treat .c files as C++ (unless -x c is specified).
Although the gcc and g++ commands do very similar things, g++ is designed to be the command you'd invoke to compile a C++ program; it's intended to automatically do the right thing.
Behind the scenes, they're really the same program. As I understand, both decide whether to compile a program as C or as C++ based on the filename extension. Both are capable of linking against the C++ standard library, but only g++ does this by default. So if you have a program written in C++ that doesn't happen to need to link against the standard library, gcc will happen to do the right thing; but then, so would g++. So there's really no reason not to use g++ for general C++ development.
I became interested in the issue and perform some experiments
I found that description here, but it is very short.
Then I tried to experiment with gcc.exe and g++.exe on my windows machine:
$ g++ --version | head -n1
g++.exe (gcc-4.6.3 release with patches [build 20121012 by perlmingw.sf.net]) 4.6.3
$ gcc --version | head -n1
gcc.exe (gcc-4.6.3 release with patches [build 20121012 by perlmingw.sf.net]) 4.6.3
I tried to compile c89, c99, and c++1998 simple test files and It's work well for me with correct extensions matching for language
gcc -std=c99 test_c99.c
gcc -std=c89 test_c89.c
g++ -std=c++98 test_cpp.cpp
gcc -std=c++98 test_cpp.cpp
But when I try to run "gnu compiler collection" tool in that fashion:
$ gcc -std=c++98 test_cpp.c
cc1.exe: warning: command line option '-std=c++98' is valid for C++/ObjC++ but not for C [enabled by default]
But this one still work with no errors
$ gcc -x c++ -std=c++98 test_cpp.c
And this also
$ g++ -std=c++0x test_cpp_11.cpp
p.s. Test files
$ cat test_c89.c test_c99.c test_cpp.cpp
// C89 compatible file
int main()
{
int x[] = {0, 2};
return sizeof(x);
}
// C99 compatible file
int main()
{
int x[] = {[1]=2};
return sizeof(x);
}
// C++1998,2003 compatible file
class X{};
int main()
{
X x;
return sizeof(x);
}
// C++11
#include <vector>
enum class Color : int{red,green,blue}; // scoped enum
int main()
{
std::vector<int> a {1,2,3}; // bracket initialization
return 0;
}
Findings:
If look at process tree then it seems that gcc, and g++ is backend to other tools, which in my environment are: cc1plus.exe, cc1.exe, collect2.exe, as.exe, ld.exe
gcc works fine as metatool for if you have correct extension or set correct
-std -x flags. See this
“GCC” is a common shorthand term for the GNU Compiler Collection. This is both the most general name for the compiler, and the name used when the emphasis is on compiling C programs (as the abbreviation formerly stood for “GNU C Compiler”).
When referring to C++ compilation, it is usual to call the compiler “G++”. Since there is only one compiler, it is also accurate to call it “GCC” no matter what the language context; however, the term “G++” is more useful when the emphasis is on compiling C++ programs.
You could read more here.
I was testing gcc and g++ in a linux system. By using MAKEFILE, I can define the compliler used by "GNU make". I tested with the so called "dynamic memory" locating feature of "C plus plus" by :
int main(){
int * myptr = new int;
* myptr = 1;
printf("myptr[0] is %i\n",*myptr);
return 0;
}
Only g++ can successfully compile on my computer while gcc will report error
undefined reference to `operator new(unsigned long)'
So my own conclusion is gcc does not fully support "C plus plus". It seems that choosing g++ for C++ source files is a better option.
gcc and g ++ are both GNU compiler. They both compile c and c++. The difference is for *.c files gcc treats it as a c program, and g++ sees it as a c ++ program. *.cpp files are considered to be c ++ programs. c++ is a super set of c and the syntax is more strict, so be careful about the suffix.

Weird issues with Clang and C++, and uniform initialization

I was attempting to compile and run the example on this page that explores function pointers as a function input. The example I was running was the 66 line one about halfway down the page.
https://www.learncpp.com/cpp-tutorial/function-pointers/
I am on Mac iOS 12.3.1. I tried to compile with
g++ sort.cc
and was getting errors that no semicolons were in my for loops, i believe due to the bracket initialization throughout the code. And when I run it with:
g++ -std=c++11 sort.cc
It works fine.
BUT
Shouldn't my clang be compiling at at least C++11? running
clang -v
I get
Apple clang version 13.1.6 (clang-1316.0.21.2)
Target: x86_64-apple-darwin21.4.0
And from what I can tell clang versions past 4 default to c++14.
Also, when I run using clang or gcc I get errors setting -std=c++xx, but it works fine with g++. But as far as I can tell, g++ and gcc are aliases to clang, and running gcc -v or g++ -v gives me clang version 13.1.6.
So whats going on?
Xcode clang defaults to C++98. Compiling a simple program which has C++11 or later features will tell you that C++11 or later isn't the default. e.g.,
// a.cpp
constexpr int i = 10;
clang a.cpp -c
a.cpp:1:1: error: unknown type name 'constexpr'
constexpr int i = 10;
^
1 error generated.
while clang a.cpp -c -std=c++11 works fine.
Also see: https://trac.macports.org/wiki/CompilerSelection

Clang refuses to compile libstdc++'s <filesystem> header

Consider this minimal example:
#include <filesystem>
#include <iostream>
int main()
{
std::cout << std::filesystem::current_path() << '\n';
}
It works as expected in GCC 9.2, but Clang 8.0.1 refuses to compile the <filesystem> header (from GCC 9.2's libstdc++):
# clang++ 1.cpp -std=c++17
In file included from 1.cpp:1:
In file included from Z:\Lander\msys2\mingw64\include\c++\9.2.0\filesystem:37:
Z:\Lander\msys2\mingw64\include\c++\9.2.0\bits/fs_path.h:636:31: error: invalid use of incomplete
type 'std::filesystem::__cxx11::filesystem_error'
_GLIBCXX_THROW_OR_ABORT(filesystem_error(
^~~~~~~~~~~~~~~~~
Z:\Lander\msys2\mingw64\include\c++\9.2.0\x86_64-w64-mingw32\bits/c++config.h:177:49: note: expanded
from macro '_GLIBCXX_THROW_OR_ABORT'
# define _GLIBCXX_THROW_OR_ABORT(_EXC) (throw (_EXC))
^~~~
Z:\Lander\msys2\mingw64\include\c++\9.2.0\bits/fs_fwd.h:61:9: note: forward declaration of
'std::filesystem::__cxx11::filesystem_error'
class filesystem_error;
^
1 error generated.
Is it a Clang bug, or a libstdc++ bug?
I found this bug report on MSYS2 bug tracker, but there is no useful information in there.
Is there a way to patch <filesystem> header to get rid of this error, while we're waiting for an official fix?
I'm on Windows. I'm using latest GCC & Clang available in MSYS2 packages.
GCC identifies as:
# g++ --version
g++.exe (Rev2, Built by MSYS2 project) 9.2.0
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Clang identifies as:
# clang++ --version
clang version 8.0.1 (tags/RELEASE_801/final)
Target: x86_64-w64-windows-gnu
Thread model: posix
InstalledDir: Z:\Lander\msys2\mingw64\bin
Clang uses libstdc++ that comes with this GCC.
The issue can be fixed by patching <msys2_path>/mingw64/include/c++/9.2.0/bits/fs_path.h.
At lines 666-692, there is a definition of class filesystem_error. It has to be moved up to line 614, to be right above the definition of u8path().
I think it's a libstdc++ bug. I've reported it here.
class filesystem_error is used several times in bits/fs_path.h, and every use of it is below the definition, except for the problematic line 636.
That line is wrapped in #ifdef _GLIBCXX_FILESYSTEM_IS_WINDOWS, so I guess the Clang developers don't run libstdc++ compatibility tests on Windows.
UPD: This is fixed in GCC 9.3.

clang seems to use the gcc libraries

This is the first time I use clang. What I notices is that any error from clang referencing the std library looks like this:
/usr/bin/../lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/ostream:245:7:
^^^ ^^^ ^^^
So it looks like clang links — or at least includes — the gcc libraries.
The command I used: clang++ -c -Wall -Wextra -Werror -g test.cpp -o test.o. (The program had a intentional error just to prove this).
How is this possible? What can I do to make clang use its own libraries (but not break gcc)?
Additional information:
I am on a Ubuntu 14.04 machine.
clang++ --version
Ubuntu clang version 3.5-1ubuntu1 (trunk) (based on LLVM 3.5)
Target: x86_64-pc-linux-gnu
Thread model: posix
g++ --version
g++ (Ubuntu 4.8.2-19ubuntu1) 4.8.2
Copyright (C) 2013 Free Software Foundation, Inc.
I had previously installed several versions (at the same time, used them with update-alternatives) of gcc with apt-get. Right now I have only 4.8 (I have uninstalled the others). Could I have messed up something then? I have never installed clang (I guess it is default with Ubuntu).
Just to clarify: the correct programs compile and run in clang++.
Further tests: I know that gcc didn’t implement yet types like is_trivially_constructible and move operations on iostream in their standard c++11 library (https://gcc.gnu.org/onlinedocs/libstdc++/manual/status.html) and that clang has full c++11 conforming library so I tested those compiling with clang and I got the corresponding gcc errors, which only confirms that clang is using gcc libraries.
A very basic program
#include <iostream>
using namespace std;
int main() {
cout << "Yada Yada" << endl;
return 0;
}
gives this error when compiling with -std=c++1y in clang++:
In file included from /usr/bin/../lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/iostream:39:
...
/usr/bin/../lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/cstdio:120:11: error: no member named 'gets' in the global namespace
using ::gets;
~~^
So right now I can’t compile anything with c++1y in clang.
You need to install libc++ and make clang use it with -stdlib=libc++
I had similar issue: GCC (g++) already was installed on my LinuxMint (Ubuntu base) so when compile with clang, was getting an " error: no member named 'gets' in the global namespace using ::gets ".
resolved by installing libc++-dev (sudo apt-get install libc++-dev) and compiling with -stdlib++ (clang++ -g -std=c++1y -stdlib=libc++ helloworld.cpp -o helloworld)
Your real problem is that you're using C++14 (c++1y was the informal name used to refer to it when it wasn't yet fully formed), with a C++ library belonging to GCC 4.8. GCC 4.8 has complete C++11 support, but hardly even started on C++14 features.
This is caused by C++14 removing std::gets, and the GNU C library anticipating on that by not defining gets in the global namespace while the C++ library has not yet caught up and is trying to make it available in the std namespace.
The proper way to solve this does not require using libc++, just to use a C++ library with C++14 support. GLIBCXX 4.9 (aka libstdc++) already suffices.

clang's support of C++ 11 lambda

I have this C++ 11 code that uses lambda, this is an example.
#include <iostream>
using namespace std;
int main()
{
auto func = [] () { cout << "Hello world"; };
func(); // now call the function
}
When I compiled this code with clang 3.1 (Apple clang version 3.1 (tags/Apple/clang-318.0.54) (based on LLVM 3.1svn)), I got this error
lambda.cpp:7:17: error: expected expression
auto func = [] () { cout << "Hello world"; };
What might be wrong? In this site, lambda seems to be supported with clang 3.1.
ADDED
With -std=gnu++11 or c++11 option, I got these error messages.
0. Program arguments: /usr/bin/clang -cc1 -triple x86_64-apple-macosx10.7.4 -emit-obj -mrelax-all -disable-free -disable-llvm-verifier -main-file-name lambda.cpp -pic-level 1 -mdisable-fp-elim -relaxed-aliasing -masm-verbose -munwind-tables -target-cpu core2 -target-linker-version 128.2 -resource-dir /usr/bin/../lib/clang/3.1 -fmodule-cache-path /var/folders/ng/h2hkycqd2q5g2hz42c47bt4w0000gn/T/clang-module-cache -std=gnu++11 -fdeprecated-macro -fdebug-compilation-dir /Users/smcho/Desktop/C++test -ferror-limit 19 -fmessage-length 173 -stack-protector 1 -fblocks -fobjc-runtime-has-arc -fobjc-runtime-has-weak -fobjc-dispatch-method=mixed -fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o /var/folders/ng/h2hkycqd2q5g2hz42c47bt4w0000gn/T/lambda-XvZzHg.o -x c++ lambda.cpp
1. lambda.cpp:7:49: current parser token ';'
2. lambda.cpp:6:1: parsing function body 'main'
3. lambda.cpp:6:1: in compound statement ('{}')
clang: error: unable to execute command: Segmentation fault: 11
clang: error: clang frontend command failed due to signal 2 (use -v to see invocation)
clang: note: diagnostic msg: Please submit a bug report to http://developer.apple.com/bugreporter/ and include command line arguments and all diagnostic information.
clang: note: diagnostic msg: Preprocessed source(s) and associated run script(s) are located at:
clang: note: diagnostic msg: /var/folders/ng/h2hkycqd2q5g2hz42c47bt4w0000gn/T/lambda-roTwCZ.ii
clang: note: diagnostic msg: /var/folders/ng/h2hkycqd2q5g2hz42c47bt4w0000gn/T/lambda-roTwCZ.sh
This is because clang++ by default compiles your code using ISO C++ 1998 standard (including the defects addressed in the ISO C++ 2003 standard) except for 'export' (which has been removed in C++11)
Lambdas are part of Clang's C++11 Language Extension, therefore you need to compile your code with -std=c++11 or -std=gnu++11
Also see: Clang 3.1 and C++11 support status and Activating C++11 support in Clang
EDIT: I think you are trying to compile your program with the C compiler (clang) rather than C++ compiler (clang++) or your installation of Clang doesn't link to libc or libstdc++. Try to link against each library to see which one works for you, it is possible that libc might not be installed on your system.
Try to compile your program with C++11 mode using the clang++ executable (the C++ compiler) and link it either with Clang C++ Standard Library or the GNU Standard C++ Library
1)
# Uses Clang C++ Library and enables C++11 mode
clang++ -stdlib=libc++ -std=c++11 [input]
2)
# Uses GNU Standard C++ Library and enables C++11 mode
clang++ -stdlib=libstdc++ -std=c++11 [input]
Another possible problem might be that you haven't compiled Clang with the right options to enable C++11 language extensions, try and check the documentation for correct flags to use when you configure the compilation process for Clang.
The Xcode is updated using AppStore, but it still crashes on my Mac (Lion 10.7.5)
I could download the macport to compile the example successfully.
sudo port install clang-3.1
clang++-mp-3.1 -std=c++11 lambda.cpp
Responding to the newly edited post:
I investigated this issue a bit, and it's a bug that was corrected in release versions of clang 3.1. I'm currently using:
Debian clang version 3.1-3eudoxos1 (branches/release_31) (based on LLVM 3.1)
However when I tested with clang 3.0-6ubuntu3 I get a similar error to the one you posted.
Because your version is marked from SVN I assume that your issue is that it's from the prerelease versions of 3.1 and lambda support hadn't been fully implemented yet.
I can confirm that lambdas do work in clang because I'm working on a project that uses them and we target both clang and gcc. There are a few compiler boogs that crop up from time to time; however, nothing as simple as your given example, of course.
So, my recommendation is to update your version of clang.
I needed to install command line tools as is this post explains - Does Xcode 4.4 come with subversion?