headers
Leonardo Lopez | 12 May 20:11
Picon
Favicon

bug with gcc 4.3.2 on openSUSE 11.1

First of all, I'm really sorry for any english grammar mistake or any fault with any rule about bugs sending.

In this environment

Compiler: gcc (SUSE Linux) 4.3.2 [gcc-4_3-branch revision 141291]
OS: openSUSE 11.1

I got this warning

y.tab.c:2075: error: deprecated conversion from string constant to "char *"

due to gcc new checks, but the fact is the source is auto generated by the tool Bison 2.3

--- code begin ---
/* Identify Bison output.  */
#define YYBISON 1

/* Bison version.  */
#define YYBISON_VERSION "2.3"
--- code end ---

at this point

--- code begin ---
yyerror (YY_("memory exhausted")); 
--- code end ---

or the same warning at
--- code begin ---
(Continue reading)

Permalink | Reply | 1 comment |
headers
Akim Demaille | 13 May 08:28
Picon
Picon
Picon
Gravatar

Re: bug with gcc 4.3.2 on openSUSE 11.1


Le 12 mai 09 à 20:11, Leonardo Lopez a écrit :

> --- code begin ---
> yyerror (YY_("memory exhausted"));
> --- code end ---

You probably have defined yyerror as taking a (char *msg).  Make it  
"yyerror (const char *msg)".
Permalink | Reply | 0 comments |
headers
Alexandre Bique | 18 May 15:57
Picon
Gravatar

Re: No header guard in glr.c skeleton (bison 2.4.1)

On Tue, Apr 21, 2009 at 12:56 PM, Alexandre Bique
<bique.alexandre <at> gmail.com> wrote:
> On Tue, Apr 21, 2009 at 7:45 AM, Akim Demaille <akim <at> lrde.epita.fr> wrote:
>>
>> Le 17 avr. 09 à 22:59, Alexandre Bique a écrit :
>>
>>> Hi,
>>>
>>> On Sat, Apr 4, 2009 at 1:22 AM, Alexandre Bique
>>> <bique.alexandre <at> gmail.com> wrote:
>>>>
>>>> On Mon, Jan 19, 2009 at 9:27 PM, Akim Demaille <akim <at> lrde.epita.fr>
>>>> wrote:
>>>>>
>>>>> Thank you for the patch.  Unfortunately the cure is nastier than the
>>>>> disease: you used a constant string as a header guard, which will make
>>>>> life
>>>>> harder for people who mix several parsers.
>>>>
>>>> Well, i just updated my patch. It use b4_prefix and translate [a-z:]
>>>> -> [A-Z_]. I think it should work with people who mix several parsers.
>>>
>>> Is there something wrong with my previous update ?
>>> (http://lists.gnu.org/archive/html/bug-bison/2009-04/msg00003.html)
>>
>> Hi,
>>
>> Sorry for the delays Alexandre.  We are quite busy, and we also have ongoing
>> changes that we would like to focus on before working on something else.  In
>> other words, please be patient, and ping us from time to time :)
(Continue reading)

Permalink | Reply | 1 comment |
headers
Joel E. Denny | 20 May 02:00
Favicon

Re: No header guard in glr.c skeleton (bison 2.4.1)

Hi Alexandre,

On Mon, 18 May 2009, Alexandre Bique wrote:

> Anything new ? Did you applied or read the patch ?

Thanks for the patch.  The basic idea looks fine to me, but there are some 
issues.

> --- /usr/share/bison/glr.c	2008-12-12 09:29:32.000000000 +0000
> +++ glr.c	2009-04-04 01:07:36.000000000 +0100
> @@ -2631,6 +2631,7 @@
>  #endif
>  ]
>  
> +m4_define(b4_header_prefix,m4_translit(b4_prefix, `[a-z:]', `[A-Z_]'))

The expansion of b4_prefix is underquoted.  For example, if the prefix 
contains a comma, M4 gives a cryptic error message to the user.  Of 
course, it's not a valid prefix in that case, but we should let the C 
compiler give an intelligible error message instead.

>  b4_epilogue
>  dnl
>  dnl glr.cc produces its own header.
> @@ -2641,6 +2642,8 @@
>  b4_copyright([Skeleton interface for Bison GLR parsers in C],
>    [2002, 2003, 2004, 2005, 2006])
>  
> +#ifndef b4_header_prefix[]_PARSER_HEADER_H
(Continue reading)

Permalink | Reply | 0 comments |
headers
Didier Godefroy | 27 May 17:33

Bison on Tru64 5.1b

Hello bison gurus,

I have a problem with bison on Tru64 V5.1b systems that I haven't been able
to fix so far.
It's doing the same thing on more than one system and with bison 2.3 ...
2.4.1
I build with the native compilers and gmake (3.79, 3.80 and 3.81)
With a few tweaks in cflags and such, I can build it but then most tests
just hang, they grab almost a full cpu and I tried waiting long enough to
see if anything would happen but after many hours, nothing, so I just kill
off the hanging test and it does it again with others (not quite all
though).
One test I noticed that was hanging with bison 2.3 on one machine isn't
hanging on an other machine with bison 2.4.1 but I don't know what's causing
this issue.
I googled and found some possible hints about alloca but not sure what to
try there.
How should I track down what's causing this hang?

Thanks all,

--

-- 
Didier Godefroy
mailto:dg <at> ulysium.net
Support anti-Spam legislation.
Join the fight http://www.cauce.org/
Permalink | Reply | 0 comments |
headers
Didier Godefroy | 27 May 18:04

A bit more info about hanging bison on tru64 5.1b

Hello all,

I posted a while ago about my issue of hanging bison on more than one tru64
5.1b systems.

I tried a couple more things to make sure and have more details to give.
I had compiled an older version before with gcc but it wouldn't work either.

Now I just tried again building bison 2.4.1 with gcc 4.0.2 and the exact
same thing happen with the same tests:

## --------------------------- ##
## GNU Bison 2.4.1 test suite. ##
## --------------------------- ##

Input Processing.

  1: Invalid $n and @n                               ok
  2: Type Clashes                                    ok
  3: Unused values

If I kill off the hanging test, it will hang again on the next one, although
a few will pass (very few, always the same of course).

I tried disabling optimization, both with gcc and native compilers but that
doesn't change anything.

Of course if I install despite the failed tests, bison will hang when used
later in the same manner.
(Continue reading)

Permalink | Reply | 12 comments |
headers
Hans Aberg | 31 May 10:18
Picon
Picon

Variants

On 27 May 2009, at 20:52, Akim Demaille wrote:

> You will be able to do that in Bison 2.6.  A preview is available at
>
> http://www.lrde.epita.fr/~akim/download/bison-2.4.266-4ff3b.tar.bz2

You might add a reference count GC to your variants. The action syntax  
would be
   $$ = $k;
if one wants to hand over a reference. If one wants to have an  
independent copy, then add extra functions:
   $$ = $k.clone();
or
   $$ = $k; $$.detach();

Since you have a stack of fixed size objects, the implementation of  
such a GC might be simplified: the parser stack just has a state value  
and a pointer to the semantic value. The latter is implemented as a  
sequence of linked objects, with reference count. This could be made  
into a tracing GC, if not because of the destructors that must be  
called.

   Hans Aberg
Permalink | Reply | 0 comments |

Gmane