bison miscompiled with %oneapi #37172
Comments
|
I got the same error, have you figured out a solution? |
|
我也得到了同样的问题，我尝试过将krb5%gcc置换了krb5%intel文件夹，并且修改了 I got the same problem. I tried replacing krb5%intel with krb5%gcc folder and changed |
|
Same problem, unable to solve with krb5%intel or krb5%gcc Spack: 0.20.0.dev0 |
|
Hi, I had the same problem but I think I (partially) solved it. It seems to be that bison is not generating the following prologue from getdate.y - Relevant block%{
/*
** Originally written by Steven M. Bellovin <smb@research.att.com> while
** at the University of North Carolina at Chapel Hill. Later tweaked by
** a couple of people on Usenet. Completely overhauled by Rich $alz
** <rsalz@bbn.com> and Jim Berets <jberets@bbn.com> in August, 1990;
** send any email to Rich.
**
** This grammar has four shift/reduce conflicts.
**
** This code is in the public domain and has no copyright.
*/
/* SUPPRESS 287 on yaccpar_sccsid *//* Unusd static variable */
/* SUPPRESS 288 on yyerrlab *//* Label unused */
#include "autoconf.h"
#include <string.h>
/* Since the code of getdate.y is not included in the Emacs executable
itself, there is no need to #define static in this file. Even if
the code were included in the Emacs executable, it probably
wouldn't do any harm to #undef it here; this will only cause
problems if we try to write to a static variable, which I don't
think this code needs to do. */
#ifdef emacs
#undef static
#endif
/* The following block of alloca-related preprocessor directives is here
solely to allow compilation by non GNU-C compilers of the C parser
produced from this file by old versions of bison. Newer versions of
bison include a block similar to this one in bison.simple. */
#ifdef __GNUC__
#undef alloca
#define alloca __builtin_alloca
#else
#ifdef HAVE_ALLOCA_H
#include <alloca.h>
#else
#ifdef _AIX /* for Bison */
#pragma alloca
#else
void *alloca ();
#endif
#endif
#endif
#include <stdio.h>
#include <ctype.h>
#if defined(HAVE_STDLIB_H)
#include <stdlib.h>
#endif
/* The code at the top of get_date which figures out the offset of the
current time zone checks various CPP symbols to see if special
tricks are need, but defaults to using the gettimeofday system call.
Include <sys/time.h> if that will be used. */
#if defined(vms)
#include <types.h>
#include <time.h>
#else
#include <sys/types.h>
#ifdef HAVE_SYS_TIME_H
#include <sys/time.h>
#endif
#include <time.h>
#ifdef timezone
#undef timezone /* needed for sgi */
#endif
/*
** We use the obsolete `struct my_timeb' as part of our interface!
** Since the system doesn't have it, we define it here;
** our callers must do likewise.
*/
struct my_timeb {
time_t time; /* Seconds since the epoch */
unsigned short millitm; /* Field not used */
short timezone; /* Minutes west of GMT */
short dstflag; /* Field not used */
};
#endif /* defined(vms) */
#if defined (STDC_HEADERS) || defined (USG)
#include <string.h>
#endif
/* Some old versions of bison generate parsers that use bcopy.
That loses on systems that don't provide the function, so we have
to redefine it here. */
#ifndef bcopy
#define bcopy(from, to, len) memcpy ((to), (from), (len))
#endif
extern struct tm *gmtime();
extern struct tm *localtime();
#define yyparse getdate_yyparse
#define yylex getdate_yylex
#define yyerror getdate_yyerror
static int getdate_yylex (void);
static int getdate_yyerror (char *);
#define EPOCH 1970
#define EPOCH_END 2106 /* assumes unsigned 32-bit range */
#define HOUR(x) ((time_t)(x) * 60)
#define SECSPERDAY (24L * 60L * 60L)
/*
** An entry in the lexical lookup table.
*/
typedef struct _TABLE {
char *name;
int type;
time_t value;
} TABLE;
/*
** Daylight-savings mode: on, off, or not yet known.
*/
typedef enum _DSTMODE {
DSTon, DSToff, DSTmaybe
} DSTMODE;
/*
** Meridian: am, pm, or 24-hour style.
*/
typedef enum _MERIDIAN {
MERam, MERpm, MER24
} MERIDIAN;
/*
** Global variables. We could get rid of most of these by using a good
** union as the yacc stack. (This routine was originally written before
** yacc had the %union construct.) Maybe someday; right now we only use
** the %union very rarely.
*/
static char *yyInput;
static DSTMODE yyDSTmode;
static time_t yyDayOrdinal;
static time_t yyDayNumber;
static int yyHaveDate;
static int yyHaveDay;
static int yyHaveRel;
static int yyHaveTime;
static int yyHaveZone;
static time_t yyTimezone;
static time_t yyDay;
static time_t yyHour;
static time_t yyMinutes;
static time_t yyMonth;
static time_t yySeconds;
static time_t yyYear;
static MERIDIAN yyMeridian;
static time_t yyRelMonth;
static time_t yyRelSeconds;
%}Instead leaving the whole section empty in y.tab.c -Relevant part/* A Bison parser, made by GNU Bison 3.8.2. */
/* Bison implementation for Yacc-like parsers in C
Copyright (C) 1984, 1989-1990, 2000-2015, 2018-2021 Free Software Foundation,
Inc.
This program is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation, either version 3 of the License, or
(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program. If not, see <https://www.gnu.org/licenses/>. */
/* As a special exception, you may create a larger work that contains
part or all of the Bison parser skeleton and distribute that work
under terms of your choice, so long as that work isn't itself a
parser generator using the skeleton or a modified version thereof
as a parser skeleton. Alternatively, if you modify or redistribute
the parser skeleton itself, you may (at your option) remove this
special exception, which will cause the skeleton and the resulting
Bison output files to be licensed under the GNU General Public
License without this special exception.
This special exception was added by the Free Software Foundation in
version 2.2 of Bison. */
/* C LALR(1) parser skeleton written by Richard Stallman, by
simplifying the original so-called "semantic" parser. */
/* DO NOT RELY ON FEATURES THAT ARE NOT DOCUMENTED in the manual,
especially those whose name start with YY_ or yy_. They are
private implementation details that can be changed or removed. */
/* All symbols defined below should begin with yy or YY, to avoid
infringing on user name space. This should be done even for local
variables, as they might otherwise be expanded by user macros.
There are some unavoidable exceptions within include files to
define necessary library symbols; they are noted "INFRINGES ON
USER NAME SPACE" below. */
/* Identify Bison output, and Bison version. */
#define YYBISON 30802
/* Bison version string. */
#define YYBISON_VERSION "3.8.2"
/* Skeleton name. */
#define YYSKELETON_NAME "yacc.c"
/* Pure parsers. */
#define YYPURE 0
/* Push parsers. */
#define YYPUSH 0
/* Pull parsers. */
#define YYPULL 1
/* First part of user prologue. */
#line 1 "getdate.y"
/* -------------------------->THIS SHOULD NOT BE EMPTY<------------------------------- */
#line 73 "y.tab.c"I couldn't figure out why bison wasn't generating the prologue. According to the documentation the syntax was correct and bison was being called without special arguments. I eventually figured that it seems to be an issue of bison when it's compiled with OneAPI/Intel ( The temporary workaround I found was to remove bison and then force the krb5 spec to use a gcc variant: $ spack uninstall bison
$ spack install -v krb5%oneapi^bison%gccThis at least compiles correctly, though I'm getting a segfault when compiling openssh (I don't know if it's related yet). If a maintainer/dev reads this, please check if bison is working correctly with OneAPI. I imagine that a parser generator that compiles correctly but produces faulty output can bring major headaches in the future. Any extra info that I can provide, please ask.
|
|
Confirmed this still exists on v20.0
>> 2666 ../../lib/cgraph/grammar.y:194:1: error: source file is not valid UTF-8
2667 <E0>=<U+0008><U+0002>
2668 ^if I do bison:
require: "%gcc"then my life is happy again |
|
I am also getting same error while building |
|
I can confirm this behavior when installing openmpi with Intel oneAPI. Thanks to this thread my workaround was: |
|
Confirm: problem still present with Spack 0.21.0.dev0 (2023-10-18) and intel-oneapi-compilers@2023.2.1 |
|
Same thing here, problem still present with spack 0.20.1 and oneapi@2023.0.0. |
|
@rscohn2 did you see this? I can reproduce. oneapi compiled bison produces a garbage output bytes. I guess it's similar to the python thing we've seen before. |
|
For now adding a conflict as in #40860 should be a workaround, but let's keep this issue open. |
|
If only spack didn't make it so easy to compile all the dependencies with intel compilers ...
Agreed. |
|
So far I've tried two compilers and two versions of bison: and in all cases
let's hope that bugs uncovered here improve the quality of the compiler for scientific code too :) I haven't checked if bison is doing something shady or not, I also dunno how to narrow it down further easily, since older versions of bison ship old gnulib that break with any more modern compiler. |
EDIT: this issue does not have to do with `isnan` checks, failure persists with `-fp-model=strict`@rscohn2 oneapi compilers still default to fast math, correct? I still think it would be best to turn that off by default, since there's likely many packages that use signaling nans and what not that get "optimized" out by oneapi compilers. Quick pass through configure logs: is one thing that's different in oneapi compiled bison. |
|
(I've asked a similar thing here #40860 (comment) but for visibility's sake I'll be redundant) Has this been reported upstream? I'm not entirely clear on that last comment @haampie : I mean, if the error persists without optimizations it probably lies within OneAPI, or is there another possiblity I'm missing? I wouldn't mind reporting this on the Intel forums if this is effectively the case. Footnotes |
|
@rscohn2 works for Intel and has helped with similar issues. For a bug report to be useful it has to be reduced to something manageable. just a matter of how invested you are in getting it fixed ;p
yes, I checked it cause I noticed the only difference in configure between gcc and oneapi was that the latter did not support The issue does not show up with |
|
@rscohn2 it looks like no release of oneapi compilers with a fix for that Python / aliasing issue is available yet. Is the particular issue fixed? This bison issue sounds pretty similar. Can you check it's fixed by the next oneapi release? Happens with Reproducer is which produces 3 weird trailing bytes, and its output is much shorter than GCC compiled bison's version. The file getdate.y is here |
|
I verified that the python issue was fixed in a pre-release compiler. The compiler with the fix (2024.0) should be available in Spack early next week. |
|
OK, then let's remember to revisit this when it's available |
|
Remains an issue with |
Steps to reproduce the issue
I have anonymized the beginning of my paths with $HOME.
I use spack env. My specs in spack.yaml ( I attached entire spack.yaml file):
I am installing by:
$ spack installspack.yaml.txt
Error message
Error message
==> Installing krb5-1.19.3-73nv7ywb2bysfk63n46hpyxm224wnjfa ==> No binary for krb5-1.19.3-73nv7ywb2bysfk63n46hpyxm224wnjfa found: installing from source ==> Using cached archive: $HOME/new_spack_gcc/cache-gcc1120/var/cache/_source-cache/archive/56/56d04863cfddc9d9eb7af17556e043e3537d41c6e545610778676cf551b9dcd0.tar.gz ==> Ran patch() for krb5 ==> krb5: Executing phase: 'autoreconf' ==> krb5: Executing phase: 'configure' ==> krb5: Executing phase: 'build' ==> Error: ProcessError: Command exited with status 2: 'make' '-j16' 'V=1'11 errors found in build log:
5602 bison -y getdate.y
5603 $HOME/new_spack_gcc/gcc1120/lib/spack/env/oneapi/icx -DHAVE_CONFIG_H -I../../include -I../../include -I. -DKRB5_DEPRECATED=1 -DKRB5_PRIVATE -g -O2 -Werror=unknown-warning-o
ption -Wall -Wcast-align -Wshadow -Wmissing-prototypes -Wno-format-zero-length -Woverflow -Wstrict-overflow -Wmissing-format-attribute -Wmissing-prototypes -Wreturn-type -Wmissing-braces -Wparenthe
ses -Wswitch -Wunused-function -Wunused-label -Wunused-variable -Wunused-value -Wunknown-pragmas -Wsign-compare -Wnewline-eof -Werror=uninitialized -Wno-maybe-uninitialized -Werror=pointer-arith -W
error=int-conversion -Werror=incompatible-pointer-types -Werror=implicit-int -Werror=declaration-after-statement -Werror-implicit-function-declaration -pthread -c keytab_local.c
5604 $HOME/new_spack_gcc/gcc1120/lib/spack/env/oneapi/icx -DHAVE_CONFIG_H -I../../include -I../../include -I. -DKRB5_DEPRECATED=1 -DKRB5_PRIVATE -g -O2 -Werror=unknown-warning-o
ption -Wall -Wcast-align -Wshadow -Wmissing-prototypes -Wno-format-zero-length -Woverflow -Wstrict-overflow -Wmissing-format-attribute -Wmissing-prototypes -Wreturn-type -Wmissing-braces -Wparenthe
ses -Wswitch -Wunused-function -Wunused-label -Wunused-variable -Wunused-value -Wunknown-pragmas -Wsign-compare -Wnewline-eof -Werror=uninitialized -Wno-maybe-uninitialized -Werror=pointer-arith -W
error=int-conversion -Werror=incompatible-pointer-types -Werror=implicit-int -Werror=declaration-after-statement -Werror-implicit-function-declaration -pthread -c keytab.c
5605 getdate.y: warning: 4 shift/reduce conflicts [-Wconflicts-sr]
5606 getdate.y: note: rerun with option '-Wcounterexamples' to generate conflict counterexamples
5607 $HOME/new_spack_gcc/gcc1120/lib/spack/env/oneapi/icx -DHAVE_CONFIG_H -I../../include -I../../include -I. -DKRB5_DEPRECATED=1 -DKRB5_PRIVATE -g -O2 -Werror=unknown-warning-o
ption -Wall -Wcast-align -Wshadow -Wmissing-prototypes -Wno-format-zero-length -Woverflow -Wstrict-overflow -Wmissing-format-attribute -Wmissing-prototypes -Wreturn-type -Wmissing-braces -Wparenthe
ses -Wswitch -Wunused-function -Wunused-label -Wunused-variable -Wunused-value -Wunknown-pragmas -Wsign-compare -Wnewline-eof -Werror=uninitialized -Wno-maybe-uninitialized -Werror=pointer-arith -W
error=int-conversion -Werror=incompatible-pointer-types -Werror=implicit-int -Werror=declaration-after-statement -Werror-implicit-function-declaration -pthread -c kadmin_ct.c
See build log for details:
$HOME/new_spack_gcc/stage-gcc1120/spack-stage-krb5-1.19.3-73nv7ywb2bysfk63n46hpyxm224wnjfa/spack-build-out.txt
==> Error: Failed to generate environment view, because the target$HOME/test_krb5_spack/.spack-env/._view/j5igvh72lemhoaepufwpobt4entfzign already exists or is not empty. To update the view, remove this path, and run
spack env view regenerateInformation on your system
Additional information
spack-build-out.txt
spack-build-env.txt
General information
spack debug reportand reported the version of Spack/Python/Platformspack maintainers <name-of-the-package>and @mentioned any maintainersThe text was updated successfully, but these errors were encountered: