Opened 5 years ago
Closed 3 years ago
#59927 closed defect (fixed)
bison: update to 3.8.2
Reported by: | ballapete (Peter "Pete" Dyballa) | Owned by: | mascguy (Christopher Nielsen) |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | 2.6.2 |
Keywords: | Cc: | Schamschula (Marius Schamschula), akimd (Akim Demaille) | |
Port: | bison |
Description (last modified by kencu (Ken))
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
Attachments (8)
Change History (80)
Changed 5 years ago by ballapete (Peter "Pete" Dyballa)
comment:1 Changed 5 years ago by jmroot (Joshua Root)
Cc: | Schamschula added |
---|
comment:2 Changed 5 years ago by 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.
comment:3 Changed 5 years ago by 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
comment:4 Changed 5 years ago by kencu (Ken)
Description: | modified (diff) |
---|---|
Keywords: | tiger removed |
Summary: | bison @3.5 does not build on PPC Tiger, Mac OS X 10.4.11, because "#pragma GCC diagnostic not allowed inside functions" → bison @3.5 does not build with older gcc versions (gcc-4.2 and similar) because "#pragma GCC diagnostic not allowed inside functions" |
comment:5 follow-up: 13 Changed 5 years ago by 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
comment:6 Changed 5 years ago by ballapete (Peter "Pete" Dyballa)
On PPC Leopard, Mac OS X 10.5.8, the same failure happens.
comment:7 follow-up: 8 Changed 5 years ago by 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 %%% ^
comment:8 Changed 5 years ago by ballapete (Peter "Pete" Dyballa)
Replying to kencu:
On Leopard bison @3.5
built with GCC7
.
comment:9 Changed 5 years ago by 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...
comment:10 Changed 5 years ago by 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.
comment:11 Changed 5 years ago by kencu (Ken)
See <https://github.com/macports/macports-ports/commit/2a88518daaa14ba8efbb873bc344e036c9750054> for a similar error with the same macro in gnutls...
comment:12 Changed 5 years ago by kencu (Ken)
Owner: | set to kencu |
---|---|
Resolution: | → fixed |
Status: | new → closed |
comment:13 Changed 5 years ago by 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
.
comment:14 Changed 5 years ago by 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...
comment:15 Changed 5 years ago by 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.
comment:16 Changed 5 years ago by 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.
comment:17 follow-up: 18 Changed 5 years ago by 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.
comment:18 Changed 5 years ago by 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!
comment:19 Changed 5 years ago by kencu (Ken)
thanks. i'll test it tomorrow, assuming cv-19 doesn't get me overnight...
comment:20 Changed 5 years ago by 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!
comment:21 Changed 5 years ago by kencu (Ken)
apologies for delay-will get on it in a few hours in am.
comment:22 Changed 5 years ago by 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
comment:23 Changed 5 years ago by akimd (Akim Demaille)
Hi Ken,
Sorry to insist, but I would like to release 3.5.4 today. Cheers!
comment:24 Changed 5 years ago by akimd (Akim Demaille)
Cc: | akimd added |
---|
comment:25 Changed 5 years ago by akimd (Akim Demaille)
(Actually, I need feedback from anybody on PPC Tiger, it doesn't have to be Ken.)
comment:26 Changed 5 years ago by 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.
comment:27 Changed 5 years ago by 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!
comment:28 Changed 5 years ago by kencu (Ken)
It's building now! I'll run the tests and report back shortly.
comment:29 Changed 5 years ago by 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
Changed 5 years ago by kencu (Ken)
Attachment: | bison-3.5.3.13.log added |
---|
comment:30 Changed 5 years ago by 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
comment:31 Changed 5 years ago by 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?
comment:32 Changed 5 years ago by 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.
comment:33 Changed 5 years ago by 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!
comment:34 Changed 4 years ago by kencu (Ken)
In 421e073d982bbc8461a419183e65a6504dbd6e19/macports-ports (dar, master, py38-reproject, revert-6945-rust-1.43.0, wireshark):
comment:35 Changed 3 years ago by mascguy (Christopher Nielsen)
Cc: | mascguy added |
---|
comment:36 Changed 3 years ago by 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?
comment:37 Changed 3 years ago by 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+).
comment:38 Changed 3 years ago by 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!
comment:39 Changed 3 years ago by 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.
comment:40 Changed 3 years ago by 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.
comment:42 Changed 3 years ago by 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!
comment:43 Changed 3 years ago by 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.
comment:44 Changed 3 years ago by 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?
comment:45 Changed 3 years ago by 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!
comment:46 Changed 3 years ago by 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.
comment:47 Changed 3 years ago by 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!
Changed 3 years ago by mascguy (Christopher Nielsen)
Attachment: | bison-3.7.6-test-10.13.macports-main.log.gz added |
---|
Changed 3 years ago by mascguy (Christopher Nielsen)
Attachment: | bison-3.7.6-test-10.13.test-suite.log added |
---|
comment:48 Changed 3 years ago by 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
comment:49 Changed 3 years ago by Christopher Nielsen <mascguy@…>
comment:50 Changed 3 years ago by 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!
comment:51 Changed 3 years ago by 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!
comment:52 Changed 3 years ago by mascguy (Christopher Nielsen)
Resolution: | fixed |
---|---|
Status: | closed → reopened |
comment:53 Changed 3 years ago by mascguy (Christopher Nielsen)
Thanks Akim, I'll try your latest snapshot. Updates to follow.
comment:54 Changed 3 years ago by 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?
comment:55 Changed 3 years ago by kencu (Ken)
Description: | modified (diff) |
---|---|
Owner: | kencu deleted |
Status: | reopened → assigned |
Summary: | bison @3.5 does not build with older gcc versions (gcc-4.2 and similar) because "#pragma GCC diagnostic not allowed inside functions" → bison: update to 3.8 |
comment:56 Changed 3 years ago by mascguy (Christopher Nielsen)
Cc: | kencu added; mascguy removed |
---|---|
Owner: | set to mascguy |
comment:57 Changed 3 years ago by 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!
comment:58 Changed 3 years ago by akimd (Akim Demaille)
Christopher,
Sorry for the previous tarballs (fed2). Forget about them, they won't work. Try these instead:
comment:59 Changed 3 years ago by 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
comment:60 Changed 3 years ago by kencu (Ken)
Cc: | kencu removed |
---|
comment:61 Changed 3 years ago by 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!
comment:62 Changed 3 years ago by 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);
comment:63 Changed 3 years ago by 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!
comment:64 Changed 3 years ago by 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.
Changed 3 years ago by mascguy (Christopher Nielsen)
Attachment: | bison-test-results-20210811-95b72.log.xz added |
---|
comment:65 Changed 3 years ago by mascguy (Christopher Nielsen)
Full test results attached; filename bison-test-results-20210811-95b72.log.xz
.
comment:66 Changed 3 years ago by 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!
Changed 3 years ago by mascguy (Christopher Nielsen)
Attachment: | bison-test-results-20210812-024f.log.xz added |
---|
comment:67 Changed 3 years ago by 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
.
comment:68 Changed 3 years ago by 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!
Changed 3 years ago by mascguy (Christopher Nielsen)
Attachment: | bison-test-results-20210902-3.7.90.8-8556.log added |
---|
comment:69 Changed 3 years ago by 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!
comment:70 Changed 3 years ago by akimd (Akim Demaille)
Thanks for the tests, Christopher. I expect to release Bison 3.8 next week.
Cheers!
comment:71 Changed 3 years ago by mascguy (Christopher Nielsen)
Summary: | bison: update to 3.8 → bison: update to 3.8.2 |
---|
comment:72 Changed 3 years ago by Christopher Nielsen <mascguy@…>
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
Main.log from PPC Tiger