bugGNU Octave - Bugs: bug #60586, type 'yysymbol_kind_t' violates...

 
 

bug #60586: type 'yysymbol_kind_t' violates the C++ One Definition Rule'

Submitter:  Robert Jenssen <morgawr>
Submitted:  Wed 12 May 2021 02:55:21 AM UTC
   
 
Category:  Interpreter Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Unexpected Error or Warning
Status:  Fixed Assigned to:  None
Originator Name:  Robert Jenssen Open/Closed:  * Closed
Release:  * dev Operating System:  * GNU/Linux
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Wed 09 Jun 2021 04:26:10 AM UTC, comment #11: 

Thanks for checking.  Closing as fixed.

John W. Eaton <jwe>
Group administrator
Wed 09 Jun 2021 12:21:33 AM UTC, comment #10: 

I compiled hg tag 29746:7f339da6cabd. There are no warnings for multiple definitions of yysymbol_kind_t.

Robert Jenssen <morgawr>
Tue 08 Jun 2021 07:57:23 PM UTC, comment #9: 

Robert:  Does this change fix the problem for you?

John W. Eaton <jwe>
Group administrator
Tue 08 Jun 2021 07:56:43 PM UTC, comment #8: 

Sorry for the delay.  I thought I would be able to look at this problem on Friday and that it would be simply a matter of submitting a bug report for bison.  But the more I looked at it, I couldn't be sure whether the bug was in bison or gcc.

We can't easily use the api.namespace definition because even though Octave compiles the generated parser files using a C++ compiler, we are still using the C interface files that bison generates, not the C++ interface files.  Maybe we can switch to using the C++ interface for bison-generated parsers in the future, but that's not a change I want to tackle now.

In the generated files, yysymbol_kind_t is an enum and a typedef for enum yysymbol_kind_t (C!).  The declaration of the enum is different in the generated oct-parse.cc and oct-tex-parser.cc files.  But in each case, it is only used internally in the generated parser file and in argument lists of some static functions.  So I don't see how multiple declarations like that could cause trouble.  Is the GCC warning wrong?  What symbol is actually defined multiple times here?

The problem can be avoided if the api.prefix is applied to yysymbol_kind_t.  Doing that in the same way as other yy symbols means adding a preprocessor macro to the generated parser files like this:


#define yysymbol_kind_t octave_symbol_kind_t


Maybe bison should be fixed to do that.  It should only require adding the line


#define yysymbol_kind_t  ]b4_prefix[symbol_kind_t


to the bison source file data/skeletons/glr.c (and maybe other skeleton files in that directory).

But even if that change is made to bison, or if the gcc warning turns out to be incorrect and is eliminated in the future, we would probably still want to work around it until a fix is widely available.  So, I checked in the following changeset for Octave:

http://hg.savannah.gnu.org/hgweb/octave/rev/7f339da6cabd

John W. Eaton <jwe>
Group administrator
Fri 04 Jun 2021 04:02:04 PM UTC, comment #7: 

Rik: I have not, but will try to do it later today.

John W. Eaton <jwe>
Group administrator
Fri 04 Jun 2021 03:44:40 PM UTC, comment #6: 

Did anyone file upstream?  I'm not motivated as I have other higher priority bugs that I'm working on.

Rik <rik5>
Group administrator
Sat 29 May 2021 02:19:38 AM UTC, comment #5: 

I agree we should report it upstream.

John W. Eaton <jwe>
Group administrator
Thu 27 May 2021 03:11:25 PM UTC, comment #4: 

Should Octave workaround this, or should we simply file an upstream bug report with Bison?

My preference would be to file upstream.

Rik <rik5>
Group administrator
Wed 12 May 2021 04:28:48 AM UTC, comment #3: 

We can probably work around this problem as you suggest, but it seems like it is a bug in bison that the api.prefix doesn't apply to this type name since it appears to be specific to the parser.

John W. Eaton <jwe>
Group administrator
Wed 12 May 2021 03:15:03 AM UTC, comment #2: 


# gcc -v
Using built-in specs.
COLLECT_GCC=/usr/bin/gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/11/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap --enable-languages=c,c++,fortran,objc,obj-c++,ada,go,d,lto --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared --enable-threads=posix --enable-checking=release --enable-multilib --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-gcc-major-version-only --with-linker-hash-style=gnu --enable-plugin --enable-initfini-array --with-isl=/builddir/build/BUILD/gcc-11.1.1-20210428/obj-x86_64-redhat-linux/isl-install --enable-offload-targets=nvptx-none --without-cuda-driver --enable-gnu-indirect-function --enable-cet --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.1.1 20210428 (Red Hat 11.1.1-1) (GCC)


Robert Jenssen <morgawr>
Wed 12 May 2021 03:12:14 AM UTC, comment #1: 

What compiler and version are you using?

John W. Eaton <jwe>
Group administrator
Wed 12 May 2021 02:55:21 AM UTC, original submission:  

When compiling hg-id 3e8bc8bee8e9 I get the following warning (edited to remove highlighting ESC's):

libinterp/parse-tree/oct-parse.cc:475:warning: type 'yysymbol_kind_t' violates the C++ One Definition Rule
  475 | enum yysymbol_kind_t
      |
libinterp/corefcn/oct-tex-parser.cc:238:note: an enum with different value name is defined in another translation unit
  238 | enum yysymbol_kind_t
      |
libinterp/parse-tree/oct-parse.cc:481: note: name 'YYSYMBOL_3_ESC' differs from name 'YYSYMBOL_BF' defined in another translation unit
  481 |   YYSYMBOL_3_ = 3,                         /* '='  */
      |
libinterp/corefcn/oct-tex-parser.cc:244:note: mismatching definition
  244 |   YYSYMBOL_BF = 3,                         /* BF  */
      |


So far as I can see the solution is to place the C++ tex parser in a separate namespace. For example:

%define api.namespace {octave_tex}


Robert Jenssen <morgawr>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by pantxo (Updated the item)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by morgawr (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2021-06-09 pantxo Open/ClosedOpen Closed
    2021-06-09 jwe StatusReady For Test Fixed
    2021-06-08 jwe StatusNeed Info Ready For Test
    2021-05-27 rik5 StatusNone Need Info

    Back to the top

    Powered by Savane 3.13-4b48.
    Corresponding source code