GCC 5 concerns
- Primis
- Member
- Posts: 62
- Joined: Fri May 14, 2010 3:46 pm
- Libera.chat IRC: Primis
- Location: New York, NY
- Contact:
GCC 5 concerns
With the impending GCC update to a new number (5) I'm assuming this is gonna break a lot of things, and it's not something that I can see being an easy cross compile build. Am I the only one worrying about this?
-
- Member
- Posts: 193
- Joined: Wed Jan 11, 2012 6:10 pm
Re: GCC 5 concerns
I tried the beta version a while back. It doesn't break anything from what I can tell. I may be mistaken, but I believe I read somewhere that the changes being made were in the backend; switching the algorithms being used to speed up compilation.Primis wrote:With the impending GCC update to a new number (5) I'm assuming this is gonna break a lot of things, and it's not something that I can see being an easy cross compile build. Am I the only one worrying about this?
Re: GCC 5 concerns
You forgot to actually correlate your beliefs with reality. Go to gcc.gnu.org and read the change list. It is just another 0.1 release in the 4.x series, except it carried a one. I'm very much looking forward to builtin overflow checks and has_include.
-
- Member
- Posts: 193
- Joined: Wed Jan 11, 2012 6:10 pm
Re: GCC 5 concerns
Seems like my beliefs correlate pretty well with reality. Most of the changes on that list are improvements for optimization or adding new backends. The rest are mostly warnings, new command line options for existing functionality, or the addition of extensions.sortie wrote:You forgot to actually correlate your beliefs with reality. Go to gcc.gnu.org and read the change list. It is just another 0.1 release in the 4.x series, except it carried a one. I'm very much looking forward to builtin overflow checks and has_include.
Also, this made me laugh a little:
If you're going to take it that far, why not just replace the preprocessor with bash or ruby or something. Something like:New preprocessor constructs, __has_include and __has_include_next, to test the availability of headers have been added.
This demonstrates a way to include the header <optional> only if it is available:
Code: Select all
#ifdef __has_include # if __has_include(<optional>) # include <optional> # define have_optional 1 # elif __has_include(<experimental/optional>) # include <experimental/optional> # define have_optional 1 # define experimental_optional # else # define have_optional 0 # endif #endif
Code: Select all
#error -*- !bash -*-
# if [ -f <optional> ]; then
# source <optional>
# export have_optional=1
# else if [ -f <experimental/<optional> ]; then
# export have_optional=1
# export experimental_optional
# else
# export have_optional=0
# fi
- Bender
- Member
- Posts: 449
- Joined: Wed Aug 21, 2013 3:53 am
- Libera.chat IRC: bender|
- Location: Asia, Singapore
Re: GCC 5 concerns
Because the standard also defines stuff about the preprocessor, and you probably want backward compatibility with the standard defined preprocessor so that your compiler is considered sane?
"In a time of universal deceit - telling the truth is a revolutionary act." -- George Orwell
(R3X Runtime VM)(CHIP8 Interpreter OS)
(R3X Runtime VM)(CHIP8 Interpreter OS)
Re: GCC 5 concerns
Ahem.SoulofDeity wrote:I'm not saying you should intentionally break C, but if you really need to do something like this, why not just use a custom preprocessor?
Code: Select all
/* Awful, awful things makes this happen. */
#ifdef HAVE_STDFOO_H
#include <stdfoo.h>
#endif
- Combuster
- Member
- Posts: 9301
- Joined: Wed Oct 18, 2006 3:45 am
- Libera.chat IRC: [com]buster
- Location: On the balcony, where I can actually keep 1½m distance
- Contact:
Re: GCC 5 concerns
And is one big invitation to make code unportable.
-
- Member
- Posts: 193
- Joined: Wed Jan 11, 2012 6:10 pm
Re: GCC 5 concerns
There still would be; the line "#error -*- !bash -*-" would normally throw an error if bash preprocessing wasn't supported. I just think it's humorous how we keep on adding extensions to the preprocessor without considering that it's a separate language altogether.Bender wrote:Because the standard also defines stuff about the preprocessor, and you probably want backward compatibility with the standard defined preprocessor so that your compiler is considered sane?
eg. consider the following
Code: Select all
# define valueof(x) x
# define str_helper(x) #x
# define str(x) str_helper(x)
# define x 1
# define y 2
// print x
# pragma message str(x)
// ld x, y
# undef x
# define x valueof(y)
// inc x
# if valueof(x) == 0
# undef x
# define x 1
# elif valueof(x) == 1
#...
# elif valueof(x) == 255
# undef x
# define x 0
# endif
// dec y
# if valueof(y) == 0
# undef y
# define y 255
# elif valueof(y) == 255
#...
# elif valueof(y) == 1
# undef y
# define y 0
# endif
// add x, y
# if valueof(y) != 0
# include "inc_x.c"
# include "dec_y.c"
# include "add_x_y.c"
# endif