bison: update to 3.8.2

[ballapete (Peter "Pete" Dyballa)]

This error shows up on systems that default to gcc-4.2 (10.4 and 10.5):

/opt/local/bin/gcc-apple-4.2 -std=gnu99 -DEXEEXT=\"\"   -I. -I./lib -I. -I./lib -DINSTALLDIR=\"/opt/local/bin\" -I/opt/local/include   -pipe -Os -arch ppc -MT src/bison-InadequacyList.o -MD -MP -MF src/.deps/bison-InadequacyList.Tpo -c -o src/bison-InadequacyList.o `test -f 'src/InadequacyList.c' || echo './'`src/InadequacyList.c
src/InadequacyList.c: In function 'InadequacyList__new_conflict':
src/InadequacyList.c:37: error: #pragma GCC diagnostic not allowed inside functions
src/InadequacyList.c:37: error: #pragma GCC diagnostic not allowed inside functions
src/InadequacyList.c:40: error: #pragma GCC diagnostic not allowed inside functions
make: *** [src/bison-InadequacyList.o] Error 1
make: Leaving directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_lil.fr.rsync.macports.org_release_tarballs_ports_devel_bison/bison/work/bison-3.5'
Command failed:  cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_lil.fr.rsync.macports.org_release_tarballs_ports_devel_bison/bison/work/bison-3.5" && /usr/bin/make -w all 
Exit code: 2

[ballapete (Peter "Pete" Dyballa)]

Main.log from PPC Tiger

[kencu (Ken)]

bison was broken by this thread and commit <​https://lists.gnu.org/archive/html/bug-bison/2019-10/msg00061.html> and the test for GCC is not quite right yet.

In libuv we use this.

#if defined(__GNUC__)
#define GCC_VERSION \
	(__GNUC__ * 10000 + __GNUC_MINOR__ * 100 + __GNUC_PATCHLEVEL__)
#endif
#if defined(__clang__) || (defined(GCC_VERSION) && (GCC_VERSION >= 40500))
/* gcc diagnostic pragmas available */
# define GCC_DIAGNOSTIC_AVAILABLE
#endif

In bison in src/system.h:

/* See https://lists.gnu.org/archive/html/bug-bison/2019-10/msg00061.html. */
# if defined __GNUC__ && ! defined __clang__ && ! defined __ICC && __GNUC__ < 5
#  define IGNORE_TYPE_LIMITS_BEGIN \
     _Pragma ("GCC diagnostic push") \
     _Pragma ("GCC diagnostic ignored \"-Wtype-limits\"")
#  define IGNORE_TYPE_LIMITS_END \
     _Pragma ("GCC diagnostic pop")
# else
#  define IGNORE_TYPE_LIMITS_BEGIN
#  define IGNORE_TYPE_LIMITS_END
# endif

That block needs to be adjusted so that older gcc versions fall through to the no-ops.

[kencu (Ken)]

Changing the test to disable the macro indeed fixes it.

BTW, you don't need Tiger to test this. Just force a build with any gcc-4.2 version, eg on Lion:

sudo port -v destroot bison configure.compiler=llvm-gcc-4.2

[kencu (Ken)]

Even if that is fixed, the test suite for bison won't run, due to other errors related to older gcc versions:

/usr/bin/llvm-gcc-4.2 -std=gnu99 -DEXEEXT=\"\"   -I./examples/c/reccalc -I./examples/c/reccalc -I/opt/local/include  -pipe -Os -arch x86_64 -MT examples/c/reccalc/reccalc-parse.o -MD -MP -MF examples/c/reccalc/.deps/reccalc-parse.Tpo -c -o examples/c/reccalc/reccalc-parse.o `test -f 'examples/c/reccalc/parse.c' || echo './'`examples/c/reccalc/parse.c
In file included from examples/c/reccalc/parse.c:1678:
examples/c/reccalc/scan.h:112: error: redefinition of typedef 'yyscan_t'
examples/c/reccalc/parse.c:117: error: previous declaration of 'yyscan_t' was here
make[3]: *** [examples/c/reccalc/reccalc-parse.o] Error 1

It's looking simpler, perhaps, to just require a newer c compiler with

compiler.c_standard 2011

[ballapete (Peter "Pete" Dyballa)]

On PPC Leopard, Mac OS X 10.5.8, the same failure happens.

[kencu (Ken)]

unfortunately

compiler.c_standard 2011

does not work on Tiger PPC, as you then later get this error:

In file included from lib/strverscmp.c:21:0:
./lib/libc-config.h:78:21: error: operator '%' has no left operand
 # define __WORDSIZE %%%
                     ^
./lib/libc-config.h:78:21: error: operator '%' has no left operand
 # define __WORDSIZE %%%
                     ^

[ballapete (Peter "Pete" Dyballa)]

Replying to kencu:

On Leopard bison @3.5 built with GCC7.

[kencu (Ken)]

but throwing in the definition to lib/libc-config.h, works:

#define __WORDSIZE 32

bison does some trickery in libc-config.h that I don't fully understand to not include some standard headers...

[kencu (Ken)]

OK, so Leopard does work, Tiger fails for odd reasons. Probably have to throw in the __WORDSIZE definition on Tiger, unless we sort out why it is needed there in the first place and fix that.

[kencu (Ken)]

See <​https://github.com/macports/macports-ports/commit/2a88518daaa14ba8efbb873bc344e036c9750054> for a similar error with the same macro in gnutls...

[kencu (Ken)]

In 421e073d982bbc8461a419183e65a6504dbd6e19/macports-ports (master):

bison: require C11

the build uses C11 features in the test builds
and requires newer gcc versions to support the
pragmas inside functions

closes: #59927

[jmroot (Joshua Root)]

Replying to kencu:

Even if that is fixed, the test suite for bison won't run, due to other errors related to older gcc versions:

/usr/bin/llvm-gcc-4.2 -std=gnu99 -DEXEEXT=\"\"   -I./examples/c/reccalc -I./examples/c/reccalc -I/opt/local/include  -pipe -Os -arch x86_64 -MT examples/c/reccalc/reccalc-parse.o -MD -MP -MF examples/c/reccalc/.deps/reccalc-parse.Tpo -c -o examples/c/reccalc/reccalc-parse.o `test -f 'examples/c/reccalc/parse.c' || echo './'`examples/c/reccalc/parse.c
In file included from examples/c/reccalc/parse.c:1678:
examples/c/reccalc/scan.h:112: error: redefinition of typedef 'yyscan_t'
examples/c/reccalc/parse.c:117: error: previous declaration of 'yyscan_t' was here
make[3]: *** [examples/c/reccalc/reccalc-parse.o] Error 1

Please report this upstream; it's clearly a bug to be both redefining typedefs and building with -std=gnu99.

[kencu (Ken)]

bit confusing... some google hits suggest redefining typedefs is allowed by gnu99, but the exact gcc and clang versions may handle the situation differently...

will see if a clear understanding is possible...

[ballapete (Peter "Pete" Dyballa)]

  bison @3.5.3_0 (active) platform='darwin 8' archs='ppc' date='2020-03-21T17:54:43+0100'
  bison-runtime @3.5.3_0 (active) platform='darwin 8' archs='noarch' date='2020-03-21T17:44:26+0100'

built on PPC Tiger, Mac OS X 10.4.11, today.

[akimd (Akim Demaille)]

Hi,

I'm the Bison upstream maintainer.

Why on Earth this was never reported to bug-bison@…? I was told about this issue *today*, three all months afterwards. As you may have noticed, we make quite frequent bug fix releases, the last one being 3.5.3. We should have known about this earlier, the bugs/issues would have been fixed long ago.

Bison does not require C11 to build.

None of these errors are visible on our CI. We need your input to improve Bison. Please, work with us.

[kencu (Ken)]

Well, that's nice to hear.

Honest truth is not many upstream projects are too interested in tweaking builds for compilers like gcc-4.2 any more, and working around things missing from the MacOSX Tiger headers even less, so we are fairly used to doing a little surgery on these ports for our rather dedicated legacy system user base.

redefining typedefs was introduced in some compiler version > gcc-4.2 -- I don't recall just when it occurred -- but in the way MacPorts works, it's basically a built-in next compiler step to set the bar at C11 and that sets a generation of compilers that do work rather than doing a lot of experimenting to find out just exactly which version of gcc allowed it and then undertaking a project of blacklisting or fallbacking.

Appreciate your interest.

[akimd (Akim Demaille)]

Hi Ken,

Replying to kencu:

Well, that's nice to hear.

Honest truth is not many upstream projects are too interested in tweaking builds for compilers like gcc-4.2 any more, and working around things missing from the MacOSX Tiger headers even less, so we are fairly used to doing a little surgery on these ports for our rather dedicated legacy system user base.

Ok, I see. Out of curiosity: how long do you plan on keeping these platforms updated?

I'm using Travis for the CI, and unfortunately I don't think I can run GCC 4.2 over there, the oldest we have currently is 4.6 (see ​https://travis-ci.org/github/akimd/bison/builds/669995270 for instance).

redefining typedefs was introduced in some compiler version > gcc-4.2 -- I don't recall just when it occurred --

Yep, it's C11, rejected in C99.

I took care of two issues:

• the pragmas for diagnostics
• the double typedef

So it is my understanding that in this case the C11 compiler is no longer needed, and as a consequence the __WORDSIZE hack is no longer needed either, right? Do you have means to check a tarball? If you can, please give a shot at this one:

​https://www.lrde.epita.fr/~akim/private/bison/bison-3.5.3.3-6e89b.tar.gz
​https://www.lrde.epita.fr/~akim/private/bison/bison-3.5.3.3-6e89b.tar.xz

I'll release it once I know it addresses your concerns.

Cheers!

[kencu (Ken)]

thanks. i'll test it tomorrow, assuming cv-19 doesn't get me overnight...

[akimd (Akim Demaille)]

Hi Ken,

If you have some spare time, I'm ready to release 3.5.4, I'm just waiting for your ACK. Please use these tarballs instead.

​https://www.lrde.epita.fr/~akim/private/bison/bison-3.5.3.9-21320.tar.gz
​https://www.lrde.epita.fr/~akim/private/bison/bison-3.5.3.9-21320.tar.xz

Cheers!

[kencu (Ken)]

apologies for delay-will get on it in a few hours in am.

[akimd (Akim Demaille)]

Apologies too: the CI found portability issues in the previous tarballs. Please use these instead :-)

​https://www.lrde.epita.fr/~akim/private/bison/bison-3.5.3.9-c199f-dirty.tar.gz
​https://www.lrde.epita.fr/~akim/private/bison/bison-3.5.3.9-c199f-dirty.tar.xz

[akimd (Akim Demaille)]

Hi Ken,

Sorry to insist, but I would like to release 3.5.4 today. Cheers!

[akimd (Akim Demaille)]

(Actually, I need feedback from anybody on PPC Tiger, it doesn't have to be Ken.)

[kencu (Ken)]

Hi Akim -- can you recheck that URL?

$ sudo wget https://www.lrde.epita.fr/~akim/private/bison/bison-3.5.3.9-c199f-dirty.tar.xz
--2020-04-04 22:55:06--  https://www.lrde.epita.fr/~akim/private/bison/bison-3.5.3.9-c199f-dirty.tar.xz
Resolving www.lrde.epita.fr (www.lrde.epita.fr)... 163.5.55.8
Connecting to www.lrde.epita.fr (www.lrde.epita.fr)|163.5.55.8|:443... connected.
HTTP request sent, awaiting response... 404 Not Found
2020-04-04 22:55:07 ERROR 404: Not Found.

$ sudo wget https://www.lrde.epita.fr/~akim/private/bison/bison-3.5.3.9-c199f-dirty.tar.gz
--2020-04-04 22:55:19--  https://www.lrde.epita.fr/~akim/private/bison/bison-3.5.3.9-c199f-dirty.tar.gz
Resolving www.lrde.epita.fr (www.lrde.epita.fr)... 163.5.55.8
Connecting to www.lrde.epita.fr (www.lrde.epita.fr)|163.5.55.8|:443... connected.
HTTP request sent, awaiting response... 404 Not Found
2020-04-04 22:55:20 ERROR 404: Not Found.

[akimd (Akim Demaille)]

Doh... My uploading script was not -dirty compliant, and I was stupid enough to forget the damn set -e...

I'm sorry for the waste of time. Here's a newer one:

​https://www.lrde.epita.fr/~akim/private/bison/bison-3.5.3.13-961ea.tar.gz
​https://www.lrde.epita.fr/~akim/private/bison/bison-3.5.3.13-961ea.tar.xz

Thanks!

[kencu (Ken)]

It's building now! I'll run the tests and report back shortly.

[kencu (Ken)]

When the compiler gcc-4.2 is used, there still is a redefinition error here when building the tests :

updating examples/c/reccalc/parse.output
updating examples/c/reccalc/parse.h
/opt/local/bin/gcc-apple-4.2 -std=gnu99 -DEXEEXT=\"\"   -I./examples/c/reccalc -I./examples/c/reccalc -I/opt/local/include  -pipe -Os -arch ppc -MT examples/c/reccalc/reccalc-parse.o -MD -MP -MF examples/c/reccalc/.deps/reccalc-parse.Tpo -c -o examples/c/reccalc/reccalc-parse.o `test -f 'examples/c/reccalc/parse.c' || echo './'`examples/c/reccalc/parse.c
examples/c/reccalc/parse.c:1680: error: redefinition of typedef 'yyscan_t'
examples/c/reccalc/parse.c:117: error: previous declaration of 'yyscan_t' was here
make[3]: *** [Makefile:6952: examples/c/reccalc/reccalc-parse.o] Error 1

[kencu (Ken)]

when I force the compiler to gcc7, it gets past the redefinition error, but still has the WORDSIZE error (which is a deficiency in the Tiger stdint.h header):

lib/strverscmp.c
In file included from lib/strverscmp.c:21:0:
./lib/libc-config.h:87:21: error: operator '%' has no left operand
 # define __WORDSIZE %%%
                     ^
./lib/libc-config.h:87:21: error: operator '%' has no left operand
 # define __WORDSIZE %%%
                     ^
make: *** [Makefile:6630: lib/libbison_a-strverscmp.o] Error 1

[akimd (Akim Demaille)]

Sorry about the yyscan_t failure, I was really stupid. This tarball should really fix it this time.

​https://www.lrde.epita.fr/~akim/private/bison/bison-3.5.3.14-6788.tar.gz
​https://www.lrde.epita.fr/~akim/private/bison/bison-3.5.3.14-6788.tar.xz

For the other one, this involves gnulib, it would take more time to address it. But it was my understanding that it's not urgent if the stock compiler can be used, right?

[kencu (Ken)]

Well done. It builds through now with gcc-4.2, thank you. The test suite looks good too.

I also disabled the WORDSIZE patch, and it seems that this no longer causes an error as well.

So it looks GOOD from here. Thanks, Akim.

[akimd (Akim Demaille)]

Thanks a lot for your help! I'm starting the release process, it should be available on gnu.org in about half an hour. Cheers!

[kencu (Ken)]

In 421e073d982bbc8461a419183e65a6504dbd6e19/macports-ports (dar, master, py38-reproject, revert-6945-rust-1.43.0, wireshark):

bison: require C11

the build uses C11 features in the test builds
and requires newer gcc versions to support the
pragmas inside functions

closes: #59927

[mascguy (Christopher Nielsen)]

This ticket piqued my interest, as I was updating one of my old Macs running 10.4 this weekend.

The problem is, while port apple-gcc42 is installed (and up-to-date), gcc7 is not. And the latter would have to be built from source, which is a bit unsavory on an old PowerBook G4 with a single CPU core.

It's frustrating to have a foundational port like bison dependent on a newer GCC, when it sounds (?) like it should be buildable on gcc 4.2.

From the various discussion, it seems like most of the issues were fixed. How much work would be required to tackle the remaining items?

[kencu (Ken)]

with Tiger and Leopard, both PPC and Intel, you quickly come across a large number of ports that need gcc7. So pretty much 100% of users will have that installed in short order if they want to have any modern ports. Anything that needs C11 or c++11 or more needs gcc7.

As there is no buildbot, this is not generally a hindrance as it is not uninstalled & reinstalled with every buildbot build cycle -- one a user has it installed, s/he's good to go.

It's possible there may be a user or two who is on Tiger or Leopard, wants bison, but has otherwise no need for anything that needs gcc7. I can't really picture this scenario, but I won't deny that it could happen. So if you have time to fix it so that bison, and hopefully the test suite (as we'd certainly like to test it on Tiger), builds fine with apple-gcc42, that would sure be great.

I don't know how much work it might be to fix the remaining items.

In the larger picture I find that once a software project goes down the path of C11 / c++11 features, then they usually just add more; so even if you fixed this bison for apple-gcc42 today, it's often just broken again on tomorrow's update. So I don't personally find that a fruitful use of my own time, except for ports needed for bootstrapping to the key toolchain items (apple-gcc42, cctools, ld64, and then gcc5+).

[akimd (Akim Demaille)]

Hi guys, My mind completely garbage collected this issue, but I do believe that we do not need a recent GCC to build Bison. I don't see what motivated the requirement for C11. Cheers!

[kencu (Ken)]

Actually, there is something funny about that commit. Where did all this stuff come from?

 (dar, master, py38-reproject, revert-6945-rust-1.43.0, wireshark):

and what I put here comment:32 suggests I got it to work with apple-gcc42, and yet there was a commit two months later to enable C11?

It's all a bit strange. Probably worth a second look.

[mascguy (Christopher Nielsen)]

Just tested on 10.4. After removing the C11 requirement from the portfile, and building with apple-gcc42, the port installed successfully.

[mascguy (Christopher Nielsen)]

Fixed in commit:

bison: eliminate C11 requirement; add variant tests

[mascguy (Christopher Nielsen)]

One final thought:

While it's true that many ports need gcc7, most of the key foundational ports don't. And by fixing this, users can now build/install bash and all dependencies, without gcc7. That's a win in my book!

[kencu (Ken)]

I went on a big project of enabling and running test suites for all the software I came across over the past couple of years. I thought this was especially useful for never-tested systems like Tiger.

So 18 months ago I definitely would have elected to enable the testable bison built with gcc7, rather than the untestable bison built with apple-gcc42.

I still think this is (for my way of thinking) the better idea, but it's a no maintainer port and you can have a different idea.

I just pegged the bison built with gcc7 in my repo. Simple.

I would encourage you to install gcc7/libgcc7 and have that done with as you will certainly need it soon enough if you want to be working on Tiger at all.

Thanks for taking the time to go exploring in the older regions of macOS! I used Tiger when it first came out and still do here at home on a daily basis... it runs my faxing service using hylafax, for one, and has been so doing since 2005.

I wouldn't be eager to see a lot of ports be modified to work with ancient apple-gcc42 rather than the much more modern gcc7, but once again, it's an open-source project going here so I don't have any control over what is done.

According to upstream gcc11 / libgcc11 works great on Tiger. I recently enabled that on SnowLeopard, and I was thinking to bring it all the way back to Tiger at some opportune moment, in my own repos if not in MacPorts.

[mascguy (Christopher Nielsen)]

Akim, circling back on this, as we'd ideally like to have the tests compile and run using gcc-4.2 as well. And while not absolutely necessary - we worked around it by disabling tests by default, and requiring a newer GCC when those are enabled - that's not great either.

Any thoughts?

[akimd (Akim Demaille)]

Hi Christopher, What failure of the test suite do you observe with gcc-4.2? Please, provide me with the logs (especially test-suite.log) so that I have a look and see if there's something we can address upstream. Cheers!

[mascguy (Christopher Nielsen)]

Akim, I'll rebuild on my old Mac, and provide a log based on the latest Bison release.

In the interim, take a look at comment:29. I believe that's the same failure I encountered a few weeks ago, but I'll still provide an up-to-date log regardless. More to follow.

[akimd (Akim Demaille)]

But comment:31 seems to indicate I took care of that one.

And really, one-year old logs about a different version of Bison are unlikely to be relevant.

Cheers!

[mascguy (Christopher Nielsen)]

Akim, the good news is that the tests now seem to compile with gcc-4.2. Beautiful!

However, regardless of what compiler is used, one of the tests appear to fail. Attached are the results, run from macOS 10.13; filename bison-3.7.6-test-10.13.test-suite.log. Also attached the MacPorts build log; filename bison-3.7.6-test-10.13.macports-main.log.gz.

Of note, the tests fail with the same result on both macOS 10.5 (compiled with gcc-4.2), as well as on newer releases compiled with a recent Clang.

And finally, my apologies: I thought I had done all of this testing/validation with Bison 3.7.6, but perhaps not? Must be getting old. Lol

[Christopher Nielsen <mascguy@…>]

In 45f0f055724a4f03eaf126f18e35cac3fa072f96/macports-ports (master):

bison: remove C11 requirement for tests, along with variant

See: #59927

[akimd (Akim Demaille)]

Hi Christopher,

This failure has bugged me for a while now... I'm not sure I understand its root, but the symptoms are precisely this trailing TAB in some tests for some users. Let's nail it.

The following tarballs contain a first fix, but maybe the following test cases will also fail, and I need your help.

​https://www.lrde.epita.fr/~akim/private/bison/bison-3.7.6.335-1d541.tar.gz ​https://www.lrde.epita.fr/~akim/private/bison/bison-3.7.6.335-1d541.tar.lz ​https://www.lrde.epita.fr/~akim/private/bison/bison-3.7.6.335-1d541.tar.xz

Please after configure and make, run make check-examples and if there are failures, then look in examples/c/bistromathic/bistromathic.test for the corresponding call to run, and add -t as first argument to it. Your logs show that we need it on line 318, so I did this:

@@ -306,7 +306,16 @@ esac
 sed -e 's/\\t/ /g' >input <<EOF
 (1+\t\t
 EOF
-run 0 '> (1+
+run -t 0 '> (1+
 (       -       atan    cos     exp     ln      number  sin     sqrt
 > (1+
 > ''

Please tell me if more calls to run need that to get a passing test suite.

Cheers!

[akimd (Akim Demaille)]

I expect to release Bison 3.8 within a few weeks. I'm ready to roll the first betas. But I'd like to get feedback about my fix proposal and on the possible additional changes the test suite might need.

Here are more recent snapshots:

• ​https://www.lrde.epita.fr/~akim/private/bison/bison-3.7.6.356-e01a.tar.gz
• ​https://www.lrde.epita.fr/~akim/private/bison/bison-3.7.6.356-e01a.tar.lz
• ​https://www.lrde.epita.fr/~akim/private/bison/bison-3.7.6.356-e01a.tar.xz

Cheers!

[mascguy (Christopher Nielsen)]

Thanks Akim, I'll try your latest snapshot. Updates to follow.

[mascguy (Christopher Nielsen)]

It looks like test 14 [for bistromathic.test] is failing. All of the others pass, though:

bistromathic: PASS: 13
checking for kernel name... Darwin
bistromathic: FAIL: 14
bistromathic: input:
  (1+		
bistromathic: expected output:
  > (1+
  (       -       atan    cos     exp     ln      number  sin     sqrt
  > (1+
  > 
  err: 1.4: syntax error: expected - or ( or number or function or variable before end of file
  err:     1 | (1+
  err:       |    ^
bistromathic: effective output:
  > (1+
  (       -       atan    cos     exp     ln      number  sin     sqr
  > (1+
  > 
  err: 1.4: syntax error: expected - or ( or number or function or variable before end of file
  err:     1 | (1+
  err:       |    ^
bistromathic: diff:
  --- exp	2021-08-07 09:14:37.000000000 -0400
  +++ eff	2021-08-07 09:14:37.000000000 -0400
  @@ -1,5 +1,5 @@
   > (1+
  -(       -       atan    cos     exp     ln      number  sin     sqrt
  +(       -       atan    cos     exp     ln      number  sin     sqr
   > (1+
   > 
   err: 1.4: syntax error: expected - or ( or number or function or variable before end of file
bistromathic: PASS: 15

The run command for that test - on line 370, I believe? - looks like it's passing -t:

run -t 0 '> (1+

Is there anything else I can try?

[akimd (Akim Demaille)]

Gosh:

  -(       -       atan    cos     exp     ln      number  sin     sqrt
  +(       -       atan    cos     exp     ln      number  sin     sqr

so it seems that that sed does not grok \t, and instead of removing the tab, it deleted the t... Which is still magical to me, since the pattern was s/\t$//g, i.e., it requires the t to be last in the line to fire, and the whole problem is precisely that that character was not last in the line: there are trailing spaces...

On second thought, it appears I was wrong believing we had a spurious tab, it's actually padding with white spaces.

I have adjusted examples/test to kill trailing spaces. Could you please try it? I expect test 14 to pass, and the following ones too. Thanks!

• ​https://www.lrde.epita.fr/~akim/private/bison/bison-3.7.6.356-fed2.tar.gz
• ​https://www.lrde.epita.fr/~akim/private/bison/bison-3.7.6.356-fed2.tar.lz
• ​https://www.lrde.epita.fr/~akim/private/bison/bison-3.7.6.356-fed2.tar.xz

[akimd (Akim Demaille)]

Christopher,

Sorry for the previous tarballs (fed2). Forget about them, they won't work. Try these instead:

• ​https://www.lrde.epita.fr/~akim/private/bison/bison-3.7.6.356-61e7.tar.gz
• ​https://www.lrde.epita.fr/~akim/private/bison/bison-3.7.6.356-61e7.tar.lz
• ​https://www.lrde.epita.fr/~akim/private/bison/bison-3.7.6.356-61e7.tar.xz

[mascguy (Christopher Nielsen)]

Test compilation is now failing with the following:

$ make check-examples
/usr/bin/gcc-4.2 -std=gnu99 -DEXEEXT=\"\"   -I./examples/c/glr -I./examples/c/glr -I/opt/local/include    -pipe -Os -arch ppc -MT examples/c/glr/examples_c_glr_c___types-c++-types.o -MD -MP -MF examples/c/glr/.deps/examples_c_glr_c___types-c++-types.Tpo -c -o examples/c/glr/examples_c_glr_c___types-c++-types.o `test -f 'examples/c/glr/c++-types.c' || echo './'`examples/c/glr/c++-types.c
examples/c/glr/c++-types.c:762: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'static'
examples/c/glr/c++-types.c:770: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'static'
examples/c/glr/c++-types.c: In function 'yyexpandGLRStack':
examples/c/glr/c++-types.c:1507: warning: implicit declaration of function 'yyMemoryExhausted'
examples/c/glr/c++-types.c: In function 'yyrecoverSyntaxError':
examples/c/glr/c++-types.c:2574: warning: implicit declaration of function 'yyFail'
make: *** [examples/c/glr/examples_c_glr_c___types-c++-types.o] Error 1

[akimd (Akim Demaille)]

Wow. If this test does not pass, it actually means that the main test suite is certainly not passing either. Bison comes with "two" test suites: that of the examples (less than a dozen cases), and then the real one (more than 700 cases). It appears you are stuck in the first, auxiliary, test suite. I guess we will need more exchanges after this one...

Your failure shows that your GCC does not grok _Noreturn the way we expect it. Please run /usr/bin/gcc-4.2 -std=gnu99 -pipe -Os -arch ppc -E bison.c on the attached bison.c file and post the output. For some reason we think it supports _Noreturn, but does not, and we need to tune the detection to fix that.

/*
/usr/bin/gcc-4.2 -std=gnu99 -pipe -Os -arch ppc -E bison.c
*/


#ifndef _Noreturn
# if (defined __cplusplus \
      && ((201103 <= __cplusplus && !(__GNUC__ == 4 && __GNUC_MINOR__ == 7)) \
          || (defined _MSC_VER && 1900 <= _MSC_VER)))
case 1
#  define _Noreturn [[noreturn]]
# elif ((!defined __cplusplus || defined __clang__) \
        && (201112 <= (defined __STDC_VERSION__ ? __STDC_VERSION__ : 0) \
            || (!defined __STRICT_ANSI__ \
                && (__4 < __GNUC__ + (7 <= __GNUC_MINOR__) \
                    || (defined __apple_build_version__ \
                        ? 6000000 <= __apple_build_version__ \
                        : 3 < __clang_major__ + (5 <= __clang_minor__))))))
   /* _Noreturn works as-is.  */
case 2
# elif (2 < __GNUC__ + (8 <= __GNUC_MINOR__) || defined __clang__ \
        || 0x5110 <= __SUNPRO_C)
#  define _Noreturn __attribute__ ((__noreturn__))
# elif 1200 <= (defined _MSC_VER ? _MSC_VER : 0)
case 3
#  define _Noreturn __declspec (noreturn)
# else
case 4
#  define _Noreturn
# endif
#endif

c++: __cplusplus
clang: __clang__
clang maj: __clang_major__
clang min: __clang_minor__
STDC: __STDC_VERSION__
STRICT_ANSI: __STRICT_ANSI__
GNUC: __GNUC__
GNUC MIN: __GNUC_MINOR__
apple: __apple_build_version__

_Noreturn static void
yyFail (yyGLRStack* yystackp, YYLTYPE *yylocp, const char* yymsg);

Cheers!

[akimd (Akim Demaille)]

Check _Noreturn support

[mascguy (Christopher Nielsen)]

Akim, here's the requested output:

$ /usr/bin/gcc-4.2 -std=gnu99 -pipe -Os -arch ppc -E bison.c
# 1 "bison.c"
# 1 "<built-in>"
# 1 "<command-line>"
# 1 "bison.c"
# 20 "bison.c"
case 2
# 33 "bison.c"
c++: __cplusplus
clang: __clang__
clang maj: __clang_major__
clang min: __clang_minor__
STDC: 199901L
STRICT_ANSI: __STRICT_ANSI__
GNUC: 4
GNUC MIN: 2
apple: __apple_build_version__

_Noreturn static void
yyFail (yyGLRStack* yystackp, YYLTYPE *yylocp, const char* yymsg);

[akimd (Akim Demaille)]

Thanks for the report. It revealed a typo I had not seen in the code I sent to you. There's a line with a very strange spelling of "4".

                && (__4 < __GNUC__ + (7 <= __GNUC_MINOR__) \

Could you please try this tarball? At some point I will also need the results of the full make check, not just make check-examples. Depending on the number of cores you have, I suggested make check -j2, cause it is very long. Cheers!

• ​https://www.lrde.epita.fr/~akim/private/bison/bison-3.7.6.361-95b72.tar.gz
• ​https://www.lrde.epita.fr/~akim/private/bison/bison-3.7.6.361-95b72.tar.lz
• ​https://www.lrde.epita.fr/~akim/private/bison/bison-3.7.6.361-95b72.tar.xz

[mascguy (Christopher Nielsen)]

Looks good so far: The latest snapshot fixed the test compilation errors, and the "light" (auxiliary) test suite passes. One test is skipped though, is that normal/expected (at least with an older compiler like gcc-4.2)?

/usr/bin/make  check-TESTS check-local
PASS: examples/c/mfcalc/mfcalc.test
PASS: examples/c/rpcalc/rpcalc.test
PASS: examples/c/bistromathic/bistromathic.test
PASS: examples/c/calc/calc.test
PASS: examples/c/glr/c++-types.test
PASS: examples/c/lexcalc/lexcalc.test
PASS: examples/c/pushcalc/calc.test
SKIP: examples/c/reccalc/reccalc.test
PASS: examples/c++/calc++/calc++.test
PASS: examples/c++/variant.test
============================================================================
Testsuite summary for GNU Bison 3.7.6.361-95b72
============================================================================
# TOTAL: 10
# PASS:  9
# SKIP:  1
# XFAIL: 0
# FAIL:  0
# XPASS: 0
# ERROR: 0

As for the in-depth test cases, I'm still waiting for those to finish. But most appear to be passing, with some (hopefully expected?) failures. I'll provide the full test suite log once it finishes.

[mascguy (Christopher Nielsen)]

Full test results attached; filename bison-test-results-20210811-95b72.log.xz.

[akimd (Akim Demaille)]

I think we are getting close. The "skip" is because seq is not available. The test failures are due to g++ not supporting std::vector::data, so I ruled this compiler out.

Please try ​https://www.lrde.epita.fr/~akim/private/bison/bison-3.7.6.371-024f.tar.xz.

Cheers!

[mascguy (Christopher Nielsen)]

Looks great Akim! The entire test suite passes, with some skips.

Full log attached; filename bison-test-results-20210812-024f.log.xz.

[akimd (Akim Demaille)]

Portability issues found in other platforms required a few more changes. They should not change anything here, buuuuuut... A test would be most useful. Thanks!

• ​https://www.lrde.epita.fr/~akim/private/bison/bison-3.7.90.8-8556.tar.gz
• ​https://www.lrde.epita.fr/~akim/private/bison/bison-3.7.90.8-8556.tar.lz
• ​https://www.lrde.epita.fr/~akim/private/bison/bison-3.7.90.8-8556.tar.xz

[mascguy (Christopher Nielsen)]

Akim, I've rerun the tests against 10.5/gcc-4.2, with your latest snapshot. And everything looks good to me. There were no failures, with 117 tests skipped.

Full log attached; filename bison-test-results-20210902-3.7.90.8-8556.log.

And thanks again for all of your help and support with this effort!

[akimd (Akim Demaille)]

Thanks for the tests, Christopher. I expect to release Bison 3.8 next week.

Cheers!

[Christopher Nielsen <mascguy@…>]

In c5f712c80ba8bee22ee2b579e2b901e92db788b5/macports-ports (master):

bison: update to 3.8.2

Closes: #59927