Re: binary integer constants in gcc
On Fri, Jun 21, 2013 at 10:20:01AM +0200, Mark Kettenis wrote:
Date: Fri, 21 Jun 2013 17:31:39 +1000
From: Jonathan Gray j...@jsg.id.au
Both gcc and clang have an extension for binary integer constants.
In gcc's case this has been around since 4.3.
The mesa backend for newer intel parts (i965) assumes this extension
is present in recent versions.
Sigh... Can't these people just write portable C?
Below is a diff to add support for this to our in tree gcc4. While the
i965 backend is only built on gcc4 archs the concern is that abuse
of this extension in ports or other places may make gcc3/gcc2 archs
worse off unless similiar patches can be done...
Well, lots of ports stuff is compiled with newer gcc versions anyway.
Looks like it is trivial to bring this extension to gcc3, since the
code seems to be almost unchanged in gcc4. It just moved to a
different location.
Here is the gcc3 diff:
Index: gcc/cppexp.c
===
RCS file: /cvs/src/gnu/usr.bin/gcc/gcc/cppexp.c,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 cppexp.c
--- gcc/cppexp.c29 Nov 2003 12:21:45 - 1.1.1.1
+++ gcc/cppexp.c26 Jun 2013 03:17:21 -
@@ -178,6 +178,11 @@ cpp_classify_number (pfile, token)
radix = 16;
str++;
}
+ else if ((*str == 'b' || *str == 'B') (str[1] == '0' || str[1] ==
'1'))
+ {
+ radix = 2;
+ str++;
+ }
}
/* Now scan for a well-formed integer or float. */
@@ -216,10 +221,22 @@ cpp_classify_number (pfile, token)
radix = 10;
if (max_digit = radix)
-SYNTAX_ERROR2 (invalid digit \%c\ in octal constant, '0' + max_digit);
+{
+ if (radix == 2)
+ SYNTAX_ERROR2 (invalid digit \%c\ in binary constant, '0' +
max_digit);
+ else
+ SYNTAX_ERROR2 (invalid digit \%c\ in octal constant, '0' +
max_digit);
+}
if (float_flag != NOT_FLOAT)
{
+ if (radix == 2)
+ {
+ cpp_error (pfile, DL_ERROR,
+invalid prefix \0b\ for floating constant);
+ return CPP_N_INVALID;
+ }
+
if (radix == 16 CPP_PEDANTIC (pfile) !CPP_OPTION (pfile, c99))
cpp_error (pfile, DL_PEDWARN,
use of C99 hexadecimal floating constant);
@@ -293,11 +310,15 @@ cpp_classify_number (pfile, token)
if ((result CPP_N_IMAGINARY) CPP_PEDANTIC (pfile))
cpp_error (pfile, DL_PEDWARN, imaginary constants are a GCC extension);
+ if (radix == 2 CPP_PEDANTIC (pfile))
+cpp_error (pfile, DL_PEDWARN, binary constants are a GCC extension);
if (radix == 10)
result |= CPP_N_DECIMAL;
else if (radix == 16)
result |= CPP_N_HEX;
+ else if (radix == 2)
+result |= CPP_N_BINARY;
else
result |= CPP_N_OCTAL;
@@ -350,6 +371,11 @@ cpp_interpret_integer (pfile, token, typ
base = 16;
p += 2;
}
+ else if ((type CPP_N_RADIX) == CPP_N_BINARY)
+ {
+ base = 2;
+ p += 2;
+ }
/* We can add a digit to numbers strictly less than this without
needing the precision and slowness of double integers. */
@@ -409,12 +435,25 @@ append_digit (num, digit, base, precisio
size_t precision;
{
cpp_num result;
- unsigned int shift = 3 + (base == 16);
+ unsigned int shift;
bool overflow;
cpp_num_part add_high, add_low;
- /* Multiply by 8 or 16. Catching this overflow here means we don't
+ /* Multiply by 2, 8 or 16. Catching this overflow here means we don't
need to worry about add_high overflowing. */
+ switch (base)
+{
+case 2:
+ shift = 1;
+ break;
+
+case 16:
+ shift = 4;
+ break;
+
+default:
+ shift = 3;
+}
overflow = !!(num.high (PART_PRECISION - shift));
result.high = num.high shift;
result.low = num.low shift;
Index: gcc/cpplib.h
===
RCS file: /cvs/src/gnu/usr.bin/gcc/gcc/cpplib.h,v
retrieving revision 1.1.1.2
diff -u -p -r1.1.1.2 cpplib.h
--- gcc/cpplib.h24 Dec 2004 23:51:31 - 1.1.1.2
+++ gcc/cpplib.h26 Jun 2013 03:10:33 -
@@ -630,6 +630,7 @@ struct cpp_num
#define CPP_N_DECIMAL 0x0100
#define CPP_N_HEX 0x0200
#define CPP_N_OCTAL0x0400
+#define CPP_N_BINARY 0x0800
#define CPP_N_UNSIGNED 0x1000 /* Properties. */
#define CPP_N_IMAGINARY0x2000
binary integer constants in gcc
Both gcc and clang have an extension for binary integer constants.
In gcc's case this has been around since 4.3.
The mesa backend for newer intel parts (i965) assumes this extension
is present in recent versions.
Below is a diff to add support for this to our in tree gcc4. While the
i965 backend is only built on gcc4 archs the concern is that abuse
of this extension in ports or other places may make gcc3/gcc2 archs
worse off unless similiar patches can be done...
From
http://gcc.gnu.org/git/?p=gcc.git;a=patch;h=d7282a2b2cacdf62e80c1f29f06933f38a70d743
still under the GPLv2.
Index: libcpp/expr.c
===
RCS file: /cvs/src/gnu/gcc/libcpp/expr.c,v
retrieving revision 1.2
diff -u -p -r1.2 expr.c
--- libcpp/expr.c 4 Apr 2013 22:01:32 - 1.2
+++ libcpp/expr.c 21 Jun 2013 06:34:53 -
@@ -188,6 +188,11 @@ cpp_classify_number (cpp_reader *pfile,
radix = 16;
str++;
}
+ else if ((*str == 'b' || *str == 'B') (str[1] == '0' || str[1] ==
'1'))
+ {
+ radix = 2;
+ str++;
+ }
}
/* Now scan for a well-formed integer or float. */
@@ -226,10 +231,22 @@ cpp_classify_number (cpp_reader *pfile,
radix = 10;
if (max_digit = radix)
-SYNTAX_ERROR2 (invalid digit \%c\ in octal constant, '0' + max_digit);
+{
+ if (radix == 2)
+ SYNTAX_ERROR2 (invalid digit \%c\ in binary constant, '0' +
max_digit);
+ else
+ SYNTAX_ERROR2 (invalid digit \%c\ in octal constant, '0' +
max_digit);
+}
if (float_flag != NOT_FLOAT)
{
+ if (radix == 2)
+ {
+ cpp_error (pfile, CPP_DL_ERROR,
+invalid prefix \0b\ for floating constant);
+ return CPP_N_INVALID;
+ }
+
if (radix == 16 CPP_PEDANTIC (pfile) !CPP_OPTION (pfile, c99))
cpp_error (pfile, CPP_DL_PEDWARN,
use of C99 hexadecimal floating constant);
@@ -321,11 +338,16 @@ cpp_classify_number (cpp_reader *pfile,
if ((result CPP_N_IMAGINARY) CPP_PEDANTIC (pfile))
cpp_error (pfile, CPP_DL_PEDWARN,
imaginary constants are a GCC extension);
+ if (radix == 2 CPP_PEDANTIC (pfile))
+cpp_error (pfile, CPP_DL_PEDWARN,
+ binary constants are a GCC extension);
if (radix == 10)
result |= CPP_N_DECIMAL;
else if (radix == 16)
result |= CPP_N_HEX;
+ else if (radix == 2)
+result |= CPP_N_BINARY;
else
result |= CPP_N_OCTAL;
@@ -376,6 +398,11 @@ cpp_interpret_integer (cpp_reader *pfile
base = 16;
p += 2;
}
+ else if ((type CPP_N_RADIX) == CPP_N_BINARY)
+ {
+ base = 2;
+ p += 2;
+ }
/* We can add a digit to numbers strictly less than this without
needing the precision and slowness of double integers. */
@@ -431,12 +458,25 @@ static cpp_num
append_digit (cpp_num num, int digit, int base, size_t precision)
{
cpp_num result;
- unsigned int shift = 3 + (base == 16);
+ unsigned int shift;
bool overflow;
cpp_num_part add_high, add_low;
- /* Multiply by 8 or 16. Catching this overflow here means we don't
+ /* Multiply by 2, 8 or 16. Catching this overflow here means we don't
need to worry about add_high overflowing. */
+ switch (base)
+{
+case 2:
+ shift = 1;
+ break;
+
+case 16:
+ shift = 4;
+ break;
+
+default:
+ shift = 3;
+}
overflow = !!(num.high (PART_PRECISION - shift));
result.high = num.high shift;
result.low = num.low shift;
Index: libcpp/include/cpplib.h
===
RCS file: /cvs/src/gnu/gcc/libcpp/include/cpplib.h,v
retrieving revision 1.2
diff -u -p -r1.2 cpplib.h
--- libcpp/include/cpplib.h 4 Apr 2013 22:01:32 - 1.2
+++ libcpp/include/cpplib.h 21 Jun 2013 06:34:53 -
@@ -744,6 +744,7 @@ struct cpp_num
#define CPP_N_DECIMAL 0x0100
#define CPP_N_HEX 0x0200
#define CPP_N_OCTAL0x0400
+#define CPP_N_BINARY 0x0800
#define CPP_N_UNSIGNED 0x1000 /* Properties. */
#define CPP_N_IMAGINARY0x2000
Re: binary integer constants in gcc
On Fri, Jun 21, 2013 at 10:20:01AM +0200, Mark Kettenis wrote: Date: Fri, 21 Jun 2013 17:31:39 +1000 From: Jonathan Gray j...@jsg.id.au Both gcc and clang have an extension for binary integer constants. In gcc's case this has been around since 4.3. The mesa backend for newer intel parts (i965) assumes this extension is present in recent versions. Sigh... Can't these people just write portable C? Below is a diff to add support for this to our in tree gcc4. While the i965 backend is only built on gcc4 archs the concern is that abuse of this extension in ports or other places may make gcc3/gcc2 archs worse off unless similiar patches can be done... Well, lots of ports stuff is compiled with newer gcc versions anyway. Actually, not so many: $echo select count(*) from modules where value='gcc4'; | sqlite3/usr/local/share/sqlports 34 And if you rip out all the subpackages, the actual list is: audio/mscore editors/libreoffice lang/classpath lang/luajit net/rtorrent print/cups-filters textproc/pdftk www/mozilla-firefox www/seamonkey www/squid Landry
Re: binary integer constants in gcc
Date: Fri, 21 Jun 2013 10:50:42 +0200 From: Landry Breuil lan...@rhaalovely.net On Fri, Jun 21, 2013 at 10:20:01AM +0200, Mark Kettenis wrote: Well, lots of ports stuff is compiled with newer gcc versions anyway. Actually, not so many: $echo select count(*) from modules where value='gcc4'; | sqlite3/usr/local/share/sqlports 34 And if you rip out all the subpackages, the actual list is: audio/mscore editors/libreoffice lang/classpath lang/luajit net/rtorrent print/cups-filters textproc/pdftk www/mozilla-firefox www/seamonkey www/squid Don't libreoffice and mozilla-firefox account for about half the lines of code that's in ports? ;) Seriously though; I was under the impression that it was a lot more. Thanks for enlightening me Landry.
Re: binary integer constants in gcc
On Fri, Jun 21, 2013 at 11:03:16AM +0200, Mark Kettenis wrote: Date: Fri, 21 Jun 2013 10:50:42 +0200 From: Landry Breuil lan...@rhaalovely.net On Fri, Jun 21, 2013 at 10:20:01AM +0200, Mark Kettenis wrote: Well, lots of ports stuff is compiled with newer gcc versions anyway. Actually, not so many: $echo select count(*) from modules where value='gcc4'; | sqlite3/usr/local/share/sqlports 34 And if you rip out all the subpackages, the actual list is: audio/mscore editors/libreoffice lang/classpath lang/luajit net/rtorrent print/cups-filters textproc/pdftk www/mozilla-firefox www/seamonkey www/squid Don't libreoffice and mozilla-firefox account for about half the lines of code that's in ports? ;) Seriously though; I was under the impression that it was a lot more. Thanks for enlightening me Landry. Some of the big ones have moved to llvm (chromium). In actuality, as you know, we're playing linking games, since we mix both libstdc++ from base and libstdc++ from the ports gcc4. The only clean option would be to move all the ports that want C++ to using a single compiler... or to a single libstdc++/libcxxrt...
Re: binary integer constants in gcc
On Fri, Jun 21, 2013 at 1:03 PM, Stuart Henderson st...@openbsd.org wrote: only for sparc64: net/rtorrent Yes, this is due to a gcc bug: https://github.com/rakshasa/rtorrent/issues/28
Re: binary integer constants in gcc
On 6/21/2013 7:03 AM, Stuart Henderson wrote: ICE with base gcc (lacking info about arch etc) audio/mscore For completeness, the ICE was on amd64: [ 11%] Building CXX object singleapp/src/CMakeFiles/qtsingleapp.dir/moc_qtsingleapplication.cxx.o command-line:0: internal compiler error: Segmentation fault But I had trouble compiling on powerpc without gcc-4.6 too iirc. ~Brian
