Re: bison-3.1.91 released [beta]
> Le 24 oct. 2018 à 06:43, Akim Demaille a écrit : > > Hi Paul, > >> Le 24 oct. 2018 à 00:27, Paul Eggert a écrit : >> >> On 10/23/18 8:23 AM, Akim Demaille wrote: >>> Fighting warnings is a nightmare. >>> Incredibly time consuming. >> >> You have to pick your battles. I shut off warnings that are more trouble >> than they're worth. This particular warning, though, is worthwhile as the >> program can have undefined behavior. > > Yes, I agree. But ICC is incredibly picky on code generated by Flex > 2.5.35. That’s the warnings that are currently annoying me. And ICC’s > documentation about pragma is quite unclear, so I don’t know yet what’s > the cleanest/simplest way to avoid this. I chose the following one. I’ll push it once Travis is happy (https://travis-ci.com/akimd/bison/builds/89061486). With that, I think I’m done with 3.2. Except for documentation issues. Cheers! commit 849d91bc024f0795a369437f97f8f1e3bb78f9e3 Author: Akim Demaille Date: Wed Oct 24 20:45:18 2018 +0200 configure: quit on trying to get ICC and Flex be friends The CI is using Flex 2.5.35. And ICC is too picky for it. Let's stop making these warnings errors. I wish I could disable them in the source files using the ICC version and the Flex version, but ICC's pragma support is unclear, and I'm tired of fighting it. * configure.ac (FLEX_SCANNER_CXXFLAGS): Make warnings warnings. * examples/c++/local.mk: Comment changes. diff --git a/configure.ac b/configure.ac index c81446ca..3d55f08c 100644 --- a/configure.ac +++ b/configure.ac @@ -162,15 +162,11 @@ if test "$enable_gcc_warnings" = yes; then do gl_WARN_ADD([$i], [WARN_CXXFLAGS_TEST]) done - # Clang++ 3.2+ rejects C code generated by Flex. - gl_WARN_ADD([-Wno-null-conversion], [FLEX_SCANNER_CXXFLAGS]) - # So does G++ 4.8... - gl_WARN_ADD([-Wno-sign-compare], [FLEX_SCANNER_CXXFLAGS]) - # ... possibly in std=c++11 mode. - gl_WARN_ADD([-Wno-zero-as-null-pointer-constant], [FLEX_SCANNER_CXXFLAGS]) - CXXFLAGS=$save_CXXFLAGS + # Too many compilers complain about Flex generated code. + gl_WARN_ADD([-Wno-error], [FLEX_SCANNER_CXXFLAGS]) # Clang++ deprecates compiling C. gl_WARN_ADD([-Wno-deprecated], [WNO_DEPRECATED_CXXFLAGS]) + CXXFLAGS=$save_CXXFLAGS AC_LANG_POP([C++]) fi diff --git a/examples/c++/local.mk b/examples/c++/local.mk index 4d40abca..b9c2f071 100644 --- a/examples/c++/local.mk +++ b/examples/c++/local.mk @@ -46,6 +46,7 @@ endif check_PROGRAMS += %D%/variant nodist_%C%_variant_SOURCES = %D%/variant.yy +# Don't use gnulib's system headers. %C%_variant_CPPFLAGS = -I$(top_builddir) dist_TESTS += %D%/variant.test %D%/variant.cc: $(BISON_IN) $(dist_pkgdata_DATA) @@ -54,6 +55,7 @@ if ENABLE_CXX11 check_PROGRAMS += %D%/variant-11 nodist_%C%_variant_11_SOURCES = %D%/variant-11.yy %C%_variant_11_CXXFLAGS = $(CXX11_CXXFLAGS) + # Don't use gnulib's system headers. %C%_variant_11_CPPFLAGS = -I$(top_builddir) dist_TESTS += %D%/variant-11.test %D%/variant-11.cc: $(BISON_IN) $(dist_pkgdata_DATA)
Re: bison-3.1.91 released [beta]
Hi Paul,
> Le 24 oct. 2018 à 00:27, Paul Eggert a écrit :
>
> On 10/23/18 8:23 AM, Akim Demaille wrote:
>> Fighting warnings is a nightmare.
>> Incredibly time consuming.
>
> You have to pick your battles. I shut off warnings that are more trouble than
> they're worth. This particular warning, though, is worthwhile as the program
> can have undefined behavior.
Yes, I agree. But ICC is incredibly picky on code generated by Flex
2.5.35. That’s the warnings that are currently annoying me. And ICC’s
documentation about pragma is quite unclear, so I don’t know yet what’s
the cleanest/simplest way to avoid this.
(see below too)
> examples/calc++/scanner.cc(928): error #2259: non-pointer conversion from
> "flex_int32_t={int}" to "YY_CHAR={unsigned char}" may lose significant bits
> register YY_CHAR yy_c = yy_ec[YY_SC_TO_UI(*yy_cp)];
> ^
>
> examples/calc++/scanner.cc(938): error #2259: non-pointer conversion from
> "flex_int32_t={int}" to "YY_CHAR={unsigned char}" may lose significant bits
> yy_c = yy_meta[(unsigned int) yy_c];
>^
>
> examples/calc++/scanner.cc(951): error #1682: implicit conversion of a 64-bit
> integral type to a smaller integral type (potential portability problem)
> YY_DO_BEFORE_ACTION;
> ^
>
> examples/calc++/scanner.cc(1263): error #1682: implicit conversion of a
> 64-bit integral type to a smaller integral type (potential portability
> problem)
> YY_CURRENT_BUFFER_LVALUE->yy_buf_size - number_to_move
> - 1;
> ^
>
> examples/calc++/scanner.cc(1276): error #1682: implicit conversion of a
> 64-bit integral type to a smaller integral type (potential portability
> problem)
> int new_size = b->yy_buf_size * 2;
> ^
>
> examples/calc++/scanner.cc(1297): error #1682: implicit conversion of a
> 64-bit integral type to a smaller integral type (potential portability
> problem)
> num_to_read = YY_CURRENT_BUFFER_LVALUE->yy_buf_size -
> ^
>
> examples/calc++/scanner.cc(1306): error #1682: implicit conversion of a
> 64-bit integral type to a smaller integral type (potential portability
> problem)
> YY_INPUT(
> (_CURRENT_BUFFER_LVALUE->yy_ch_buf[number_to_move]),
> ^
>
> examples/calc++/scanner.cc(1306): error #1682: implicit conversion of a
> 64-bit integral type to a smaller integral type (potential portability
> problem)
> YY_INPUT(
> (_CURRENT_BUFFER_LVALUE->yy_ch_buf[number_to_move]),
> ^
>
> examples/calc++/scanner.cc(1367): error #2259: non-pointer conversion from
> "flex_int32_t={int}" to "YY_CHAR={unsigned char}" may lose significant bits
> register YY_CHAR yy_c = (*yy_cp ? yy_ec[YY_SC_TO_UI(*yy_cp)] :
> 1);
> ^
>
> examples/calc++/scanner.cc(1377): error #2259: non-pointer conversion from
> "flex_int32_t={int}" to "YY_CHAR={unsigned char}" may lose significant bits
> yy_c = yy_meta[(unsigned int) yy_c];
>^
>
> examples/calc++/scanner.cc(1410): error #2259: non-pointer conversion from
> "flex_int32_t={int}" to "YY_CHAR={unsigned char}" may lose significant bits
> yy_c = yy_meta[(unsigned int) yy_c];
>^
>
> examples/calc++/scanner.cc(1814): error #1682: implicit conversion of a
> 64-bit integral type to a smaller integral type (potential portability
> problem)
> num_to_alloc = (yy_buffer_stack_max) + grow_size;
>^
>
> examples/calc++/scanner.cc(1854): error #1682: implicit conversion of a
> 64-bit integral type to a smaller integral type (potential portability
> problem)
> b->yy_n_chars = b->yy_buf_size;
> ^
>
> examples/calc++/scanner.cc(1878): error #1682: implicit conversion of a
> 64-bit integral type to a smaller integral type (potential portability
> problem)
> return yy_scan_bytes(yystr,strlen(yystr) );
> ^
Sometimes ICC’s warnings don’t make sense to me. For instance:
> src/muscle-tab.c(413): warning #3179: deprecated conversion of string literal
> to char* (should be const char*)
> char const *fmt = !eq && value && *value ? "%%define %s %s" : "%%define
> %s";
> ^
>
> src/muscle-tab.c(497): warning #188: enumerated type mixed with another type
> muscle_percent_define_how how_old = atoi (muscle_find_const
> (how_name));
> ^
>
> src/muscle-tab.c(529): warning #3179: deprecated conversion of string literal
> to char* (should be const char*)
Re: bison-3.1.91 released [beta]
On 10/22/18 8:42 AM, Akim Demaille wrote: This is coming from gnulib. Could you submit your patch there? I don’t know how they handle _Noreturn. In Gnulib, _Noreturn is for function declarations and definitions, whereas __attribute_noreturn__ is for pointed-to functions (i.e., for function types that are targets of pointers). The distinction is needed partly because _Noreturn is a C11-ism and should be portable to any C11 compiler, whereas __attribute_noreturn__ is a GCC-ism and should work with both non-C11 and C11 GCCs. So from the Gnulib point of view, the patch -static _Noreturn void +static __attribute_noreturn__ void print_and_abort (void) seems like it's heading in the wrong direction. However, I don't fully grok the original bug report so it's possible I'm missing something. Was the compiler in question GCC, or something else? What version and platform?
Re: bison-3.1.91 released [beta]
On 10/23/18 8:23 AM, Akim Demaille wrote: Fighting warnings is a nightmare. Incredibly time consuming. You have to pick your battles. I shut off warnings that are more trouble than they're worth. This particular warning, though, is worthwhile as the program can have undefined behavior.
Re: bison-3.1.91 released [beta]
> Le 22 oct. 2018 à 19:10, Derek Clegg a écrit : > > On Oct 22, 2018, at 10:42 AM, Akim Demaille wrote: >> >> Hi Derek! >> >>> Le 21 oct. 2018 à 19:43, Derek Clegg a écrit : >>> >>> I’m seeing a minor warning when building bison-3.1.91: >>> >>> lib/obstack.c:351:31: warning: incompatible pointer types initializing 'void >>>(*)(void) __attribute__((noreturn))' with an expression of type >>>'void (void)' [-Wincompatible-pointer-types] >>> __attribute_noreturn__ void (*obstack_alloc_failed_handler) (void) >>> ... >> >> This is coming from gnulib. Could you submit your patch there? >> I don’t know how they handle _Noreturn. >> >> bug-gnu...@gnu.org. > > Thanks for the reply; I’ll do that. I’ll note that data/c.m4 has this: > > #if !defined _Noreturn \ > && (!defined __STDC_VERSION__ || __STDC_VERSION__ < 201112) > # if defined _MSC_VER && 1200 <= _MSC_VER > # define _Noreturn __declspec (noreturn) > # else > # define _Noreturn YY_ATTRIBUTE ((__noreturn__)) > # endif > #endif > > That makes it into the generated header, and produces the warning > > aux/x.h:97:11: error: macro name is a reserved identifier > [-Werror,-Wreserved-id-macro] > # define _Noreturn YY_ATTRIBUTE ((__noreturn__)) > > As this isn’t used anywhere (as far as I can tell), it seems reasonable to > omit it. I’ll install this soon. Thanks! commit b5515215c188a48c0a9956a5cb03ddb951870477 Author: Akim Demaille Date: Tue Oct 23 07:12:09 2018 +0200 yacc.c: don't define _Noreturn uselessly Clang warns: aux/x.h:97:11: error: macro name is a reserved identifier [-Werror,-Wreserved-id-macro] # define _Noreturn YY_ATTRIBUTE ((__noreturn__)) Reported by Derek Clegg. http://lists.gnu.org/archive/html/bug-bison/2018-10/msg00024.html * data/c.m4 (b4_attribute_define): Don't define _Noreturn unconditionally. * data/glr.c: Ask for _Noreturn. diff --git a/data/c.m4 b/data/c.m4 index 2ec6ceea..2df76e77 100644 --- a/data/c.m4 +++ b/data/c.m4 @@ -204,11 +204,12 @@ m4_define([b4_table_value_equals], ## Compiler issues. ## ## - ## -# b4_attribute_define -# --- -# Provide portable compiler "attributes". +# b4_attribute_define([noreturn]) +# --- +# Provide portable compiler "attributes". If "noreturn" is passed, define +# _Noreturn. m4_define([b4_attribute_define], -[#ifndef YY_ATTRIBUTE +[[#ifndef YY_ATTRIBUTE # if (defined __GNUC__ \ && (2 < __GNUC__ || (__GNUC__ == 2 && 96 <= __GNUC_MINOR__))) \ || defined __SUNPRO_C && 0x5110 <= __SUNPRO_C @@ -226,7 +227,7 @@ m4_define([b4_attribute_define], # define YY_ATTRIBUTE_UNUSED YY_ATTRIBUTE ((__unused__)) #endif -#if !defined _Noreturn \ +]m4_bmatch([$1], [\bnoreturn\b], [[#if !defined _Noreturn \ && (!defined __STDC_VERSION__ || __STDC_VERSION__ < 201112) # if defined _MSC_VER && 1200 <= _MSC_VER # define _Noreturn __declspec (noreturn) @@ -235,7 +236,7 @@ m4_define([b4_attribute_define], # endif #endif -/* Suppress unused-variable warnings by "using" E. */ +]])[/* Suppress unused-variable warnings by "using" E. */ #if ! defined lint || defined __GNUC__ # define YYUSE(E) ((void) (E)) #else @@ -260,7 +261,7 @@ m4_define([b4_attribute_define], #ifndef YY_INITIAL_VALUE # define YY_INITIAL_VALUE(Value) /* Nothing. */ #endif -]) +]]) # b4_null_define diff --git a/data/glr.c b/data/glr.c index 56788b80..f77da621 100644 --- a/data/glr.c +++ b/data/glr.c @@ -311,7 +311,7 @@ static YYLTYPE yyloc_default][]b4_yyloc_default;])[ } while (yyfalse) #endif -]b4_attribute_define[ +]b4_attribute_define([noreturn])[ #ifndef YYASSERT # define YYASSERT(Condition) ((void) ((Condition) || (abort (), 0)))
Re: bison-3.1.91 released [beta]
> Le 22 oct. 2018 à 18:09, Akim Demaille a écrit :
>
> commit fe1cdd8d0cdedf99d344d8010c5c3989a166e96f
> Author: Akim Demaille
> Date: Mon Oct 22 08:22:53 2018 +0200
>
>build: enable more warnings during tests
>
>Prompted by Derek Clegg.
>http://lists.gnu.org/archive/html/bug-bison/2018-10/msg00018.html
>
>* configure.ac: here.
I need to install this to pacify ICC.
commit ab3dc5415c8b3a6a55fe95dd283cdbd013d55ee1
Author: Akim Demaille
Date: Tue Oct 23 06:44:48 2018 +0200
pacify ICC 16.0.3 20160415
Found on the CI.
yacc.c:
error #2259: non-pointer conversion from "int" to
"yytype_int16={short}" may lose significant bits
yystate = (0 <= yyi && yyi <= YYLAST && yycheck[yyi] == *yyesp
^
glr.c:
error #2259: non-pointer conversion from "int" to "yybool={unsigned
char}" may lose significant bits
yybool yynormal YY_ATTRIBUTE_UNUSED = (yystackp->yysplitPoint ==
YY_NULLPTR);
^
error #2259: non-pointer conversion from "int" to "yybool={unsigned
char}" may lose significant bits
return yypact_value_is_default (yypact[yystate]);
^
error #2259: non-pointer conversion from "int" to "yybool={unsigned
char}" may lose significant bits
return 0 < yyaction;
^
error #2259: non-pointer conversion from "int" to "yybool={unsigned
char}" may lose significant bits
return yyaction == 0;
^
error #2259: non-pointer conversion from "int" to "yybool={unsigned
char}" may lose significant bits
yystackp->yytops.yylookaheadNeeds[yys] = yychar != YYEMPTY;
^
* data/glr.c, data/yacc.c: Avoid these warnings.
diff --git a/data/glr.c b/data/glr.c
index c185a4bc..56788b80 100644
--- a/data/glr.c
+++ b/data/glr.c
@@ -293,6 +293,7 @@ static YYLTYPE yyloc_default][]b4_yyloc_default;])[
# define yytrue true
# define yyfalse false
#else
+ /* When we move to stdbool, get rid of the various casts to yybool. */
typedef unsigned char yybool;
# define yytrue 1
# define yyfalse 0
@@ -783,7 +784,7 @@ yyuserAction (yyRuleNum yyn, int yyrhslen, yyGLRStackItem*
yyvsp,
yyGLRStack* yystackp,
YYSTYPE* yyvalp]b4_locuser_formals[)
{
- yybool yynormal YY_ATTRIBUTE_UNUSED = (yystackp->yysplitPoint == YY_NULLPTR);
+ yybool yynormal YY_ATTRIBUTE_UNUSED = (yybool) (yystackp->yysplitPoint ==
YY_NULLPTR);
int yylow;
]b4_parse_param_use([yyvalp], [yylocp])dnl
[ YYUSE (yyrhslen);
@@ -903,7 +904,7 @@ yylhsNonterm (yyRuleNum yyrule)
static inline yybool
yyisDefaultedState (yyStateNum yystate)
{
- return yypact_value_is_default (yypact[yystate]);
+ return (yybool) yypact_value_is_default (yypact[yystate]);
}
/** The default reduction for YYSTATE, assuming it has one. */
@@ -929,7 +930,7 @@ yygetLRActions (yyStateNum yystate, int yytoken,
int* yyaction, const short** yyconflicts)
{
int yyindex = yypact[yystate] + yytoken;
- if (yypact_value_is_default (yypact[yystate])
+ if (yyisDefaultedState (yystate)
|| yyindex < 0 || YYLAST < yyindex || yycheck[yyindex] != yytoken)
{
*yyaction = -yydefact[yystate];
@@ -964,13 +965,13 @@ yyLRgotoState (yyStateNum yystate, yySymbol yysym)
static inline yybool
yyisShiftAction (int yyaction)
{
- return 0 < yyaction;
+ return (yybool) (0 < yyaction);
}
static inline yybool
yyisErrorAction (int yyaction)
{
- return yyaction == 0;
+ return (yybool) (yyaction == 0);
}
/* GLRStates */
@@ -2354,7 +2355,7 @@ b4_dollar_popdef])[]dnl
size_t yys;
for (yys = 0; yys < yystack.yytops.yysize; yys += 1)
-yystackp->yytops.yylookaheadNeeds[yys] = yychar != YYEMPTY;
+yystackp->yytops.yylookaheadNeeds[yys] = (yybool) (yychar !=
YYEMPTY);
/* yyprocessOneStack returns one of three things:
diff --git a/data/yacc.c b/data/yacc.c
index 4f044a3c..03adcffd 100644
--- a/data/yacc.c
+++ b/data/yacc.c
@@ -974,9 +974,10 @@ yy_lac (yytype_int16 *yyesa, yytype_int16 **yyes,
{
const int yylhs = yyr1[yyrule] - YYNTOKENS;
const int yyi = yypgoto[yylhs] + *yyesp;
- yystate = (0 <= yyi && yyi <= YYLAST && yycheck[yyi] == *yyesp
- ? yytable[yyi]
- : yydefgoto[yylhs]);
+ yystate = ((yytype_int16)
+ (0 <= yyi && yyi <= YYLAST && yycheck[yyi] == *yyesp
+ ? yytable[yyi]
+ : yydefgoto[yylhs]));
}
if (yyesp == yyes_prev)
{
@@ -996,7 +997,7 @@ yy_lac (yytype_int16 *yyesa, yytype_int16 **yyes,
}
*++yyesp = yystate;
}
-YYDPRINTF ((stderr, " G%d", yystate));
+
Re: bison-3.1.91 released [beta]
> Le 23 oct. 2018 à 17:21, Akim Demaille a écrit :
>
>
>> Le 22 oct. 2018 à 18:09, Akim Demaille a écrit :
>>
>> commit fe1cdd8d0cdedf99d344d8010c5c3989a166e96f
>> Author: Akim Demaille
>> Date: Mon Oct 22 08:22:53 2018 +0200
>>
>> build: enable more warnings during tests
>>
>> Prompted by Derek Clegg.
>> http://lists.gnu.org/archive/html/bug-bison/2018-10/msg00018.html
>>
>> * configure.ac: here.
>
> I need to install this to pacify ICC.
>
> commit ab3dc5415c8b3a6a55fe95dd283cdbd013d55ee1
> Author: Akim Demaille
> Date: Tue Oct 23 06:44:48 2018 +0200
>
>pacify ICC 16.0.3 20160415
On top of which, I need this. Fighting warnings is a nightmare.
Incredibly time consuming.
commit 9d8fc7fd3ec43a781a610f56943cce3bec1593b0
Author: Akim Demaille
Date: Tue Oct 23 08:50:44 2018 +0200
yacc.c: work around strange typing issues
On the CI, both GCC and Clang report:
src/parse-gram.c: In function 'yy_lac':
src/parse-gram.c:1479:29: error: format '%hd' expects argument of type
'int',
but argument 3 has type 'yytype_int16 {aka long int}'
[-Werror=format=]
YYDPRINTF ((stderr, " G%hd", yystate));
^
Although yytype_int16 is supposed to be a short int, not a long int.
This must be explored.
* data/yacc.c (yy_lac): Work around typing issue.
diff --git a/data/yacc.c b/data/yacc.c
index 03adcffd..d8021ef6 100644
--- a/data/yacc.c
+++ b/data/yacc.c
@@ -997,7 +997,7 @@ yy_lac (yytype_int16 *yyesa, yytype_int16 **yyes,
}
*++yyesp = yystate;
}
-YYDPRINTF ((stderr, " G%hd", yystate));
+YYDPRINTF ((stderr, " G%d", (int) yystate));
}
}
}]])[
Re: bison-3.1.91 released [beta]
On Oct 22, 2018, at 10:42 AM, Akim Demaille wrote: > > Hi Derek! > >> Le 21 oct. 2018 à 19:43, Derek Clegg a écrit : >> >> I’m seeing a minor warning when building bison-3.1.91: >> >> lib/obstack.c:351:31: warning: incompatible pointer types initializing 'void >> (*)(void) __attribute__((noreturn))' with an expression of type >> 'void (void)' [-Wincompatible-pointer-types] >> __attribute_noreturn__ void (*obstack_alloc_failed_handler) (void) >> ... > > This is coming from gnulib. Could you submit your patch there? > I don’t know how they handle _Noreturn. > > bug-gnu...@gnu.org. Thanks for the reply; I’ll do that. I’ll note that data/c.m4 has this: #if !defined _Noreturn \ && (!defined __STDC_VERSION__ || __STDC_VERSION__ < 201112) # if defined _MSC_VER && 1200 <= _MSC_VER # define _Noreturn __declspec (noreturn) # else # define _Noreturn YY_ATTRIBUTE ((__noreturn__)) # endif #endif That makes it into the generated header, and produces the warning aux/x.h:97:11: error: macro name is a reserved identifier [-Werror,-Wreserved-id-macro] # define _Noreturn YY_ATTRIBUTE ((__noreturn__)) As this isn’t used anywhere (as far as I can tell), it seems reasonable to omit it. Thanks! Derek
Re: bison-3.1.91 released [beta]
> Le 21 oct. 2018 à 19:52, Derek Clegg a écrit :
>
> There are two minor warnings I’m encountering with bison-3.1.91 in my
> generated files:
Thanks a lot for the report.
As a matter of fact, it triggered more fixes than just these
ones. See
c++: fix signedness issues
https://lists.gnu.org/archive/html/bison-patches/2018-10/msg00095.html
tests: be strict about types
https://lists.gnu.org/archive/html/bison-patches/2018-10/msg00096.html
printf returns a signed int
https://lists.gnu.org/archive/html/bison-patches/2018-10/msg00097.html
glr.c: be strict about types
https://lists.gnu.org/archive/html/bison-patches/2018-10/msg00099.html
To which I add those two commits, more directly related to your
report.
Cheers!
commit f1de52f719d3ff54f51b169ec744de0b4f90a9e6
Author: Akim Demaille
Date: Mon Oct 22 14:30:41 2018 +0200
yacc.c: fix warnings about integral types
Reported by Derek Clegg.
http://lists.gnu.org/archive/html/bug-bison/2018-10/msg00018.html
Rather than adding casts, we should be more careful with types. For
instance yystate should be a yytype_int16. But currently we can't: it
is also used sometimes for storing other things that state numbers.
* data/yacc.c (yyparse): Add missing casts.
diff --git a/TODO b/TODO
index 4e3258dc..05729fb1 100644
--- a/TODO
+++ b/TODO
@@ -5,6 +5,12 @@ itself uses int (for yylen for instance), yet stack is based
on size_t.
Maybe locations should also move to ints.
+** C
+Introduce state_type rather than spreading yytype_int16 everywhere?
+
+** glr.c
+yyspaceLeft should probably be a pointer diff.
+
** Graphviz display code thoughts
The code for the --graph option is over two files: print_graph, and
graphviz. This is because Bison used to also produce VCG graphs, but since
diff --git a/data/yacc.c b/data/yacc.c
index 2e1c275c..4f044a3c 100644
--- a/data/yacc.c
+++ b/data/yacc.c
@@ -788,7 +788,7 @@ yy_lac_stack_realloc (YYSIZE_T *yycapacity, YYSIZE_T yyadd,
yytype_int16 **yytop, yytype_int16 *yytop_empty)
{
YYSIZE_T yysize_old =
-*yytop == yytop_empty ? 0 : *yytop - *yybottom + 1;
+(YYSIZE_T) (*yytop == yytop_empty ? 0 : *yytop - *yybottom + 1);
YYSIZE_T yysize_new = yysize_old + yyadd;
if (*yycapacity < yysize_new)
{
@@ -954,7 +954,7 @@ yy_lac (yytype_int16 *yyesa, yytype_int16 **yyes,
YYDPRINTF ((stderr, " R%d", yyrule - 1));
if (yyesp != yyes_prev)
{
-YYSIZE_T yysize = yyesp - *yyes + 1;
+YYSIZE_T yysize = (YYSIZE_T) (yyesp - *yyes + 1);
if (yylen < yysize)
{
yyesp -= yylen;
@@ -970,7 +970,7 @@ yy_lac (yytype_int16 *yyesa, yytype_int16 **yyes,
yyesp = yyes_prev -= yylen;
}
{
-int yystate;
+yytype_int16 yystate;
{
const int yylhs = yyr1[yyrule] - YYNTOKENS;
const int yyi = yypgoto[yylhs] + *yyesp;
@@ -1084,7 +1084,7 @@ yytnamerr (char *yyres, const char *yystr)
if (! yyres)
return yystrlen (yystr);
- return yystpcpy (yyres, yystr) - yyres;
+ return (YYSIZE_T) (yystpcpy (yyres, yystr) - yyres);
}
# endif
@@ -1445,12 +1445,12 @@ b4_locations_if([[ yylsp[0] =
]b4_push_if([b4_pure_if([*])yypushed_loc], [yyllo
yyssp++;
yysetstate:
- *yyssp = yystate;
+ *yyssp = (yytype_int16) yystate;
if (yyss + yystacksize - 1 <= yyssp)
{
/* Get the current used size of the three stacks, in elements. */
- YYSIZE_T yysize = yyssp - yyss + 1;
+ YYSIZE_T yysize = (YYSIZE_T) (yyssp - yyss + 1);
#ifdef yyoverflow
{
@@ -1470,10 +1470,9 @@ b4_locations_if([[ yylsp[0] =
]b4_push_if([b4_pure_if([*])yypushed_loc], [yyllo
, yysize * sizeof (*yyvsp),]b4_locations_if([
, yysize * sizeof (*yylsp),])[
);
-]b4_locations_if([
-yyls = yyls1;])[
yyss = yyss1;
-yyvs = yyvs1;
+yyvs = yyvs1;]b4_locations_if([
+yyls = yyls1;])[
}
#else /* no yyoverflow */
# ifndef YYSTACK_RELOCATE
commit fe1cdd8d0cdedf99d344d8010c5c3989a166e96f
Author: Akim Demaille
Date: Mon Oct 22 08:22:53 2018 +0200
build: enable more warnings during tests
Prompted by Derek Clegg.
http://lists.gnu.org/archive/html/bug-bison/2018-10/msg00018.html
* configure.ac: here.
diff --git a/configure.ac b/configure.ac
index a569ef7c..f2240100 100644
--- a/configure.ac
+++ b/configure.ac
@@ -107,7 +107,9 @@ if test "$enable_gcc_warnings" = yes; then
# -Wno-keyword-macro: We use the "#define private public" dirty
# trick in the test suite to check some private implementation
# details for lalr1.cc.
- warn_tests='-Wundef -pedantic -Wdeprecated -Wsign-compare
-fno-color-diagnostics
+ warn_tests='-Wundef -pedantic -Wconversion
+-Wdeprecated -Wsign-compare -Wsign-conversion
+-fno-color-diagnostics
-Wno-keyword-macro'
Re: bison-3.1.91 released [beta]
Hi Derek!
> Le 21 oct. 2018 à 19:43, Derek Clegg a écrit :
>
> I’m seeing a minor warning when building bison-3.1.91:
>
> lib/obstack.c:351:31: warning: incompatible pointer types initializing 'void
> (*)(void) __attribute__((noreturn))' with an expression of type
> 'void (void)' [-Wincompatible-pointer-types]
> __attribute_noreturn__ void (*obstack_alloc_failed_handler) (void)
>
> Patch:
>
> diff -ur bison-3.1.91/lib/obstack.c bison/lib/obstack.c
> --- bison-3.1.91/lib/obstack.c2018-09-02 09:08:33.0 -0700
> +++ bison/lib/obstack.c 2018-10-21 10:36:46.0 -0700
> @@ -326,7 +326,7 @@
> # include
> # endif
>
> -static _Noreturn void
> +static __attribute_noreturn__ void
> print_and_abort (void)
> {
> /* Don't change any of these strings. Yes, it would be possible to add
>
This is coming from gnulib. Could you submit your patch there?
I don’t know how they handle _Noreturn.
bug-gnu...@gnu.org.
Re: bison-3.1.91 released [beta]
There are two minor warnings I’m encountering with bison-3.1.91 in my generated
files:
aux/x.cc:1402:12: error: implicit conversion loses integer precision: 'int' to
'yytype_int16' (aka 'short') [-Werror,-Wconversion]
*yyssp = yystate;
~ ^~~
aux/x.cc:1407:38: error: implicit conversion changes signedness: 'long' to
'unsigned long' [-Werror,-Wsign-conversion]
YYSIZE_T yysize = yyssp - yyss + 1;
~~ ~^~~
2 errors generated.
Here’s the fix:
diff -ur bison-3.1.91/data/yacc.c bison/data/yacc.c
--- bison-3.1.91/data/yacc.c2018-10-15 23:37:34.0 -0700
+++ bison/data/yacc.c 2018-10-21 10:47:01.0 -0700
@@ -1451,12 +1451,12 @@
yyssp++;
yysetstate:
- *yyssp = yystate;
+ *yyssp = (yytype_int16)yystate;
if (yyss + yystacksize - 1 <= yyssp)
{
/* Get the current used size of the three stacks, in elements. */
- YYSIZE_T yysize = yyssp - yyss + 1;
+ YYSIZE_T yysize = (YYSIZE_T)(yyssp - yyss + 1);
#ifdef yyoverflow
{
diff -ur bison-3.1.91/src/parse-gram.c bison/src/parse-gram.c
--- bison-3.1.91/src/parse-gram.c 2018-10-16 12:10:08.0 -0700
+++ bison/src/parse-gram.c 2018-10-21 10:47:28.0 -0700
@@ -1869,12 +1869,12 @@
yyssp++;
yysetstate:
- *yyssp = yystate;
+ *yyssp = (yytype_int16)yystate;
if (yyss + yystacksize - 1 <= yyssp)
{
/* Get the current used size of the three stacks, in elements. */
- YYSIZE_T yysize = yyssp - yyss + 1;
+ YYSIZE_T yysize = (YYSIZE_T)(yyssp - yyss + 1);
#ifdef yyoverflow
{
Derek Clegg
> On Oct 18, 2018, at 4:44 AM, Akim Demaille wrote:
>
> A problem was found in Bison 3.1.90: in modern C++ the parser stack
> failed to grow properly.
>
> So we are very happy to announce Bison 3.1.91, a beta of the forthcoming
> Bison 3.2. Massive improvements were brought to the deterministic C++
> skeleton, lalr1.cc. When variants are enabled and the compiler supports
> C++11 or better, move-only types can now be used for semantic values. C++98
> support is not deprecated.
>
> We expect to release Bison 3.2 within a couple of weeks. If you are a user
> of Bison's lalr1.cc, and you are using modern C++ (C++11 or newer), *please*
> try this version now. We are especially interested in usability and
> performance feedback: does your grammar look nicer, does your parser run
> faster. Any suggestion will be welcomed.
>
> Many thanks to Frank Heckenbach for paving the way for this release with his
> implementation of a C++17 skeleton.
>
>
> Here are the compressed sources:
> https://alpha.gnu.org/gnu/bison/bison-3.1.91.tar.gz (4.1MB)
> https://alpha.gnu.org/gnu/bison/bison-3.1.91.tar.xz (2.1MB)
>
> Here are the GPG detached signatures[*]:
> https://alpha.gnu.org/gnu/bison/bison-3.1.91.tar.gz.sig
> https://alpha.gnu.org/gnu/bison/bison-3.1.91.tar.xz.sig
>
> Use a mirror for higher download bandwidth:
> https://www.gnu.org/order/ftp.html
>
> [*] Use a .sig file to verify that the corresponding file (without the
> .sig suffix) is intact. First, be sure to download both the .sig file
> and the corresponding tarball. Then, run a command like this:
>
> gpg --verify bison-3.1.91.tar.gz.sig
>
> If that command fails because you don't have the required public key,
> then run this command to import it:
>
> gpg --keyserver keys.gnupg.net --recv-keys 0DDCAA3278D5264E
>
> and rerun the 'gpg --verify' command.
>
> This release was bootstrapped with the following tools:
> Autoconf 2.69
> Automake 1.16.1
> Flex 2.6.4
> Gettext 0.19.8.1
> Gnulib v0.1-2176-ga79f2a287
>
> NEWS
>
> * Noteworthy changes in release 3.1.91 (2018-10-18) [beta]
>
> ** Bug fixes
>
> With modern C++, the parser stack failed to grow properly.
>
> * Noteworthy changes in release 3.1.90 (2018-10-17) [beta]
>
> ** Backward incompatible changes
>
> Support for DJGPP, which have been unmaintained and untested for years, is
> obsolete. Unless there is activity to revive it, it will be removed.
>
> ** New features
>
> *** C++: Support for move semantics (lalr1.cc)
>
> The lalr1.cc skeleton now fully supports C++ move semantics, while
> maintaining compatibility with C++98. You may now store move-only types
> when using Bison's variants. For instance:
>
>%code {
> #include
> #include
>}
>
>%skeleton "lalr1.cc"
>%define api.value.type variant
>
>%%
>
>%token INT "int";
>%type > int;
>%type >> list;
>
>list:
> %empty{}
>| list int { $$ = std::move($1); $$.emplace_back(std::move($2)); }
>
>int: "int" { $$ = std::make_unique($1); }
>
> *** C++: Implicit move of right-hand side values (lalr1.cc)
>
> In modern C++ (C++11 and later), you should always use 'std::move' with
> the values of the right-hand side symbols ($1, $2, etc.), as they will be
> popped from the stack anyway. Using 'std::move' is mandatory for
> move-only types
Re: bison-3.1.91 released [beta]
I’m seeing a minor warning when building bison-3.1.91:
lib/obstack.c:351:31: warning: incompatible pointer types initializing 'void
(*)(void) __attribute__((noreturn))' with an expression of type
'void (void)' [-Wincompatible-pointer-types]
__attribute_noreturn__ void (*obstack_alloc_failed_handler) (void)
Patch:
diff -ur bison-3.1.91/lib/obstack.c bison/lib/obstack.c
--- bison-3.1.91/lib/obstack.c 2018-09-02 09:08:33.0 -0700
+++ bison/lib/obstack.c 2018-10-21 10:36:46.0 -0700
@@ -326,7 +326,7 @@
# include
# endif
-static _Noreturn void
+static __attribute_noreturn__ void
print_and_abort (void)
{
/* Don't change any of these strings. Yes, it would be possible to add
Derek Clegg
> On Oct 18, 2018, at 4:44 AM, Akim Demaille wrote:
>
> A problem was found in Bison 3.1.90: in modern C++ the parser stack
> failed to grow properly.
>
> So we are very happy to announce Bison 3.1.91, a beta of the forthcoming
> Bison 3.2. Massive improvements were brought to the deterministic C++
> skeleton, lalr1.cc. When variants are enabled and the compiler supports
> C++11 or better, move-only types can now be used for semantic values. C++98
> support is not deprecated.
>
> We expect to release Bison 3.2 within a couple of weeks. If you are a user
> of Bison's lalr1.cc, and you are using modern C++ (C++11 or newer), *please*
> try this version now. We are especially interested in usability and
> performance feedback: does your grammar look nicer, does your parser run
> faster. Any suggestion will be welcomed.
>
> Many thanks to Frank Heckenbach for paving the way for this release with his
> implementation of a C++17 skeleton.
>
>
> Here are the compressed sources:
> https://alpha.gnu.org/gnu/bison/bison-3.1.91.tar.gz (4.1MB)
> https://alpha.gnu.org/gnu/bison/bison-3.1.91.tar.xz (2.1MB)
>
> Here are the GPG detached signatures[*]:
> https://alpha.gnu.org/gnu/bison/bison-3.1.91.tar.gz.sig
> https://alpha.gnu.org/gnu/bison/bison-3.1.91.tar.xz.sig
>
> Use a mirror for higher download bandwidth:
> https://www.gnu.org/order/ftp.html
>
> [*] Use a .sig file to verify that the corresponding file (without the
> .sig suffix) is intact. First, be sure to download both the .sig file
> and the corresponding tarball. Then, run a command like this:
>
> gpg --verify bison-3.1.91.tar.gz.sig
>
> If that command fails because you don't have the required public key,
> then run this command to import it:
>
> gpg --keyserver keys.gnupg.net --recv-keys 0DDCAA3278D5264E
>
> and rerun the 'gpg --verify' command.
>
> This release was bootstrapped with the following tools:
> Autoconf 2.69
> Automake 1.16.1
> Flex 2.6.4
> Gettext 0.19.8.1
> Gnulib v0.1-2176-ga79f2a287
>
> NEWS
>
> * Noteworthy changes in release 3.1.91 (2018-10-18) [beta]
>
> ** Bug fixes
>
> With modern C++, the parser stack failed to grow properly.
>
> * Noteworthy changes in release 3.1.90 (2018-10-17) [beta]
>
> ** Backward incompatible changes
>
> Support for DJGPP, which have been unmaintained and untested for years, is
> obsolete. Unless there is activity to revive it, it will be removed.
>
> ** New features
>
> *** C++: Support for move semantics (lalr1.cc)
>
> The lalr1.cc skeleton now fully supports C++ move semantics, while
> maintaining compatibility with C++98. You may now store move-only types
> when using Bison's variants. For instance:
>
>%code {
> #include
> #include
>}
>
>%skeleton "lalr1.cc"
>%define api.value.type variant
>
>%%
>
>%token INT "int";
>%type > int;
>%type >> list;
>
>list:
> %empty{}
>| list int { $$ = std::move($1); $$.emplace_back(std::move($2)); }
>
>int: "int" { $$ = std::make_unique($1); }
>
> *** C++: Implicit move of right-hand side values (lalr1.cc)
>
> In modern C++ (C++11 and later), you should always use 'std::move' with
> the values of the right-hand side symbols ($1, $2, etc.), as they will be
> popped from the stack anyway. Using 'std::move' is mandatory for
> move-only types such as unique_ptr, and it provides a significant speedup
> for large types such as std::string, or std::vector, etc.
>
> If '%define api.value.automove' is set, every occurrence '$n' is replaced
> by 'std::move ($n)'. The second rule in the previous grammar can be
> simplified to:
>
>list: list int { $$ = $1; $$.emplace_back($2); }
>
> With automove enabled, the semantic values are no longer lvalues, so do
> not use the swap idiom:
>
>list: list int { std::swap($$, $1); $$.emplace_back($2); }
>
> This idiom is anyway obsolete: it is preferable to move than to swap.
>
> A warning is issued when automove is enabled, and a value is used several
> times.
>
>input.yy:16.31-32: warning: multiple occurrences of $2 with
> api.value.automove enabled [-Wother]
>exp: "twice" exp { $$ = $2 + $2; }
> ^^
>
> Enabling
Re: bison-3.1.91 released [beta]
A problem was found in Bison 3.1.90: in modern C++ the parser stack
failed to grow properly.
So we are very happy to announce Bison 3.1.91, a beta of the forthcoming
Bison 3.2. Massive improvements were brought to the deterministic C++
skeleton, lalr1.cc. When variants are enabled and the compiler supports
C++11 or better, move-only types can now be used for semantic values. C++98
support is not deprecated.
We expect to release Bison 3.2 within a couple of weeks. If you are a user
of Bison's lalr1.cc, and you are using modern C++ (C++11 or newer), *please*
try this version now. We are especially interested in usability and
performance feedback: does your grammar look nicer, does your parser run
faster. Any suggestion will be welcomed.
Many thanks to Frank Heckenbach for paving the way for this release with his
implementation of a C++17 skeleton.
Here are the compressed sources:
https://alpha.gnu.org/gnu/bison/bison-3.1.91.tar.gz (4.1MB)
https://alpha.gnu.org/gnu/bison/bison-3.1.91.tar.xz (2.1MB)
Here are the GPG detached signatures[*]:
https://alpha.gnu.org/gnu/bison/bison-3.1.91.tar.gz.sig
https://alpha.gnu.org/gnu/bison/bison-3.1.91.tar.xz.sig
Use a mirror for higher download bandwidth:
https://www.gnu.org/order/ftp.html
[*] Use a .sig file to verify that the corresponding file (without the
.sig suffix) is intact. First, be sure to download both the .sig file
and the corresponding tarball. Then, run a command like this:
gpg --verify bison-3.1.91.tar.gz.sig
If that command fails because you don't have the required public key,
then run this command to import it:
gpg --keyserver keys.gnupg.net --recv-keys 0DDCAA3278D5264E
and rerun the 'gpg --verify' command.
This release was bootstrapped with the following tools:
Autoconf 2.69
Automake 1.16.1
Flex 2.6.4
Gettext 0.19.8.1
Gnulib v0.1-2176-ga79f2a287
NEWS
* Noteworthy changes in release 3.1.91 (2018-10-18) [beta]
** Bug fixes
With modern C++, the parser stack failed to grow properly.
* Noteworthy changes in release 3.1.90 (2018-10-17) [beta]
** Backward incompatible changes
Support for DJGPP, which have been unmaintained and untested for years, is
obsolete. Unless there is activity to revive it, it will be removed.
** New features
*** C++: Support for move semantics (lalr1.cc)
The lalr1.cc skeleton now fully supports C++ move semantics, while
maintaining compatibility with C++98. You may now store move-only types
when using Bison's variants. For instance:
%code {
#include
#include
}
%skeleton "lalr1.cc"
%define api.value.type variant
%%
%token INT "int";
%type > int;
%type >> list;
list:
%empty{}
| list int { $$ = std::move($1); $$.emplace_back(std::move($2)); }
int: "int" { $$ = std::make_unique($1); }
*** C++: Implicit move of right-hand side values (lalr1.cc)
In modern C++ (C++11 and later), you should always use 'std::move' with
the values of the right-hand side symbols ($1, $2, etc.), as they will be
popped from the stack anyway. Using 'std::move' is mandatory for
move-only types such as unique_ptr, and it provides a significant speedup
for large types such as std::string, or std::vector, etc.
If '%define api.value.automove' is set, every occurrence '$n' is replaced
by 'std::move ($n)'. The second rule in the previous grammar can be
simplified to:
list: list int { $$ = $1; $$.emplace_back($2); }
With automove enabled, the semantic values are no longer lvalues, so do
not use the swap idiom:
list: list int { std::swap($$, $1); $$.emplace_back($2); }
This idiom is anyway obsolete: it is preferable to move than to swap.
A warning is issued when automove is enabled, and a value is used several
times.
input.yy:16.31-32: warning: multiple occurrences of $2 with
api.value.automove enabled [-Wother]
exp: "twice" exp { $$ = $2 + $2; }
^^
Enabling api.value.automove does not require support for modern C++. The
generated code is valid C++98/03, but will use copies instead of moves.
The new examples/variant-11.yy shows these features in action.
*** C++: The implicit default semantic action is always run
When variants are enabled, the default action was not run, so
exp: "number"
was equivalent to
exp: "number" {}
It now behaves like in all the other cases, as
exp: "number" { $$ = $1; }
possibly using std::move if automove is enabled.
We do not expect backward compatibility issues. However, beware of
forward compatibility issues: if you rely on default actions with
variants, be sure to '%require "3.2"' to avoid older versions of Bison to
generate incorrect parsers.
*** C++: Renaming location.hh
When both %defines and %locations are enabled, Bison generates a
location.hh file. If you don't use locations outside of the parser, you
may avoid its creation with:
%define
