Re: [sr #110286] Make it possible to request a specific (non-latest) version of a language standard

[Nick Bowler]

On 2020-07-27, Zack Weinberg  wrote:
> URL:
>   
>
>  Summary: Make it possible to request a specific
> (non-latest)
> version of a language standard
>  Project: Autoconf
> Submitted by: zackw
> Submitted on: Mon 27 Jul 2020 06:31:37 PM UTC
> Category: None
> Priority: 5 - Normal
> Severity: 1 - Wish
>   Status: None
>  Privacy: Public
>  Assigned to: None
> Originator Email:
>  Open/Closed: Open
>  Discussion Lock: Any
> Operating System: None
>
> ___
>
> Details:
>
> Feedback on the 2.69b beta indicates that users find the new behavior of
> AC_PROG_CC and AC_PROG_CXX, automatically selecting the latest supported
> language standard, problematic.  Quoting
> https://lists.gnu.org/archive/html/autoconf/2020-07/msg00010.html :
>
>> One issue we [PostgreSQL] would like to point out is that
>> the new scheme of automatically checking for the latest
>> version of the C and C++ standards (deprecating AC_PROG_CC_C99
>> etc.) is problematic...
>>
>> [W]e have set C99 as the project standard. So checking for
>> C11 is (a) useless, and (b) bad because we don't want
>> developers to accidentally make use of C11 features and have
>> the compiler accept them silently.

I have no comments on the C++ side of things but on the C side this
request doesn't make too much sense.

As a portability tool, the goal of Autoconf and configure scripts is
to find a compiler that can successfully compile the application.

Aside from the removal of gets from the standard library (which most
C11 compilers still implement anyway) and that some language features
which were mandatory in C99 are now optional (which again, most C11
compilers implement anyway), C11 is essentially completely backwards
compatible with C99 so such a compiler should be perfectly fine for
building a C99 codebase.

AC_PROG_CC_C99 has never guaranteed that a C99 compiler will be selected,
it is "best effort" only and has always accepted C11 compilers provided
they support VLAs.  GCC has defaulted to C11 mode for the better part
of a decade now (since version 5) and AC_PROC_CC_C99 will not add any
options.

All compilers I'm aware of that support both C99 and C11 modes will
silently accept most if not all C11 features even when C99 mode is
selected by the user.  So having Autoconf select a C99 mode is probably
not going to do anything to help projects avoid modern language
features.  For the same reason it could be difficult to write a feature
test program which usefully determines that the compiler is in C99 mode
(probably the best you can do is test for specific values of the
__STDC_VERSION__ macro which is really not the Autoconf way).

If you don't want specific language constructs to be used in your
codebase the proper way to do this is with linting tools or warning
flags during development, not with portability tools like Autoconf.

For example with GCC if you want to reject new C11 syntax you can
build with the -Werror=c99-c11-compat option.  (You could even use
Autoconf to write a configure test that will automatically add this
option to CFLAGS if it is supported by the compiler.

Cheers,
  Nick

[sr #110286] Make it possible to request a specific (non-latest) version of a language standard

[Zack Weinberg]

URL:
  

 Summary: Make it possible to request a specific (non-latest)
version of a language standard
 Project: Autoconf
Submitted by: zackw
Submitted on: Mon 27 Jul 2020 06:31:37 PM UTC
Category: None
Priority: 5 - Normal
Severity: 1 - Wish
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
Operating System: None

___

Details:

Feedback on the 2.69b beta indicates that users find the new behavior of
AC_PROG_CC and AC_PROG_CXX, automatically selecting the latest supported
language standard, problematic.  Quoting
https://lists.gnu.org/archive/html/autoconf/2020-07/msg00010.html :

> One issue we [PostgreSQL] would like to point out is that
> the new scheme of automatically checking for the latest
> version of the C and C++ standards (deprecating AC_PROG_CC_C99
> etc.) is problematic...
> 
> [W]e have set C99 as the project standard. So checking for
> C11 is (a) useless, and (b) bad because we don't want
> developers to accidentally make use of C11 features and have
> the compiler accept them silently.
>
> It looks like it's not easy to disable these tests even
> with low-level hackery. It would be better if there were
> still a way to set the preferred level of C and C++ in
> an official way.

and https://lists.gnu.org/archive/html/autoconf/2020-07/msg00012.html :

> Particularly as applies to C++, it is useful to be able
> to set an upper bar (and lower bar) for the C++ version
> requested because C++11 is in many ways not similar to
> older C++. I am already aware that some of my own software
> will not compile with C++11 because of removed deprecated
> features which I have not attended to yet in the code.
> Furthermore, the ABI often changes between C++ versions
> and it is useful to be able to specify the C++ version
> for purposes of the ABI.







___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[sr #110285] Probes for C++11 and C11 are too slow

[Zack Weinberg]

URL:
  

 Summary: Probes for C++11 and C11 are too slow
 Project: Autoconf
Submitted by: zackw
Submitted on: Mon 27 Jul 2020 06:24:27 PM UTC
Category: None
Priority: 5 - Normal
Severity: 3 - Normal
  Status: In Progress
 Privacy: Public
 Assigned to: zackw
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
Operating System: None

___

Details:

Reported by Peter Eisentraut on the autoconf mailing list:

> ... the additional tests for C11 and C++11 are slow.  This entirely
> eliminates all the performance improvements made elsewhere.  In
> particular, the test
>
> checking for g++ option to enable C++11 features... none needed
>
> takes on the order of 10 seconds for some developers.  And that is for
> one loop, since "none needed"; good luck if you need more than none.

This is because the test probes for C++11 *library* features, and the C++
standard library is notoriously heavyweight.  The test program used by
_AC_PROG_CXX_CXX11 is only about 150 lines long but it expands to 47,000 lines
of gnarly template classes after preprocessing, and roughly 30,000 assembly
instructions after compilation. With -g enabled (as is the default) 770,000
lines of debug information are also emitted into the assembly.

(By way of comparison, the test program used by _AC_PROG_CXX_CXX98 also
expands to 47,000 lines of standard-library template classes after
preprocessing, but they're not nearly as gnarly.  The assembly output has only
about 2000 lines of actual instructions and 90,000 lines of debug
information.)

Both of these tests are new since Autoconf 2.69, so there's no installed base
depending on this behavior.  The equivalent macro from the Autoconf Macro
Archive,
https://git.savannah.gnu.org/gitweb/?p=autoconf-archive.git;a=blob_plain;f=m4/ax_cxx_compile_stdcxx.m4
, only tests for *language* features; I think it would be reasonable to make
our tests do the same.  Unfortunately we can't just uplift that code without
first chasing a bunch of copyright assignments.




___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[sr #110283] 2.69b on OpenIndiana: many testsuite failures without GNU utilities in $PATH

[Zack Weinberg]

Update of sr #110283 (project autoconf):

  Status:None => Ready For Test 

___

Follow-up Comment #1:

It appears that many of the failures are spurious, caused by ksh93's
_AST_FEATURES shell variable varying from invocation to invocation.  The test
suite already filters out many other shell variables with this property. 
Could you please apply the following patch and report how many failures
remain?

diff --git a/tests/local.at b/tests/local.at
index 308eae32..e8302273 100644
--- a/tests/local.at
+++ b/tests/local.at
@@ -326,6 +326,7 @@ m4_define([AT_CHECK_CONFIGURE],
 # - AC_SUBST'ed variables
 #   (FIXME: Generate a list of these automatically.)
 # - _|@|.[*#?$].|argv|ARGC|LINENO|OLDPWD|PIPESTATUS|RANDOM|SECONDS
+#   |_AST_FEATURES
 #   Some variables some shells use and change.
 #   `.[*#?$].' catches `$#' etc. which are displayed like this:
 #  | '!'=18186
@@ -375,7 +376,8 @@ if test -f state-env.before && test -f state-env.after;
then
   [AWK|LEX|LEXLIB|LEX_OUTPUT_ROOT|LN_S|M4|MKDIR_P|RANLIB|SET_MAKE|YACC],
   [GREP|[EF]GREP|SED],
   [[_@]|.[*#?$].],
- 
[argv|ARGC|LINENO|BASH_ARGC|BASH_ARGV|OLDPWD|PIPESTATUS|RANDOM|SECONDS]))=' \
+  [argv|ARGC|LINENO|BASH_ARGC|BASH_ARGV|OLDPWD|PIPESTATUS|RANDOM],
+  [SECONDS|_AST_FEATURES]))=' \
  $act_file ||
test $? -eq 1 || echo failed >&2
 ) 2>stderr-$act_file |

It would also be helpful if you could file a separate bug report explaining
what is wrong with ksh93's 'rm -f' and how it makes configure fail.  We ought
to be detecting the problem and working around it; CONFIG_SHELL=/usr/bin/bash
shouldn't be necessary.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[sr #110284] 2.69b on OpenIndiana: one testsuite failure with GNU utilities in $PATH

[Zack Weinberg]

Update of sr #110284 (project autoconf):

  Status:None => Need Info  

___

Follow-up Comment #1:

The key part of the logfile reads

/home/bfriesen/src/gnu/autoconf-2.69b/tests/fortran.at:989: ./configure
$configure_options 
--- /dev/null   2020-07-25 08:48:30.0 +
+++
/home/bfriesen/build/autoconf-2.69b/tests/testsuite.dir/at-groups/329/stderr  
 2020-07-25 08:48:30.768221951 +
@@ -0,0 +1 @@
+./config.status: line 488: syntax error at line 491: `<<' unmatched

If you still have the build tree from this test, could you please attach the
files
/home/bfriesen/build/autoconf-2.69b/tests/testsuite.dir/at-groups/329/config.status
and
/home/bfriesen/build/autoconf-2.69b/tests/testsuite.dir/at-groups/329/configure
to this ticket?

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[sr #110284] 2.69b on OpenIndiana: one testsuite failure with GNU utilities in $PATH

[Zack Weinberg]

URL:
  

 Summary: 2.69b on OpenIndiana: one testsuite failure with GNU
utilities in $PATH
 Project: Autoconf
Submitted by: zackw
Submitted on: Mon 27 Jul 2020 02:01:10 PM UTC
Category: None
Priority: 5 - Normal
Severity: 3 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
Operating System: None

___

Details:

Reported to bug-autoconf by Bob Friesenhahn:

Running the Autoconf test suite on an OpenIndiana system produced one test
failure.

Please note that /usr/gnu/bin is in the executable path prior to the normal
system paths so GNU utilities may be used rather than the Illumos ones. 

##  ##
## Summary of the failures. ##
##  ##
Failed tests:
GNU Autoconf 2.69b test suite test groups:

 NUM: FILE-NAME:LINE TEST-GROUP-NAME
  KEYWORDS

 329: fortran.at:962 AC_FC_FIXEDFORM with AC_FC_SRCEXT



___

File Attachments:


---
Date: Mon 27 Jul 2020 02:01:10 PM UTC  Name: testsuite.log.gz  Size: 15KiB  
By: zackw



___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[sr #110283] 2.69b on OpenIndiana: many testsuite failures without GNU utilities in $PATH

[Zack Weinberg]

URL:
  

 Summary: 2.69b on OpenIndiana: many testsuite failures
without GNU utilities in $PATH
 Project: Autoconf
Submitted by: zackw
Submitted on: Mon 27 Jul 2020 01:55:03 PM UTC
Category: None
Priority: 5 - Normal
Severity: 3 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
Operating System: Solaris

___

Details:

Reported to bug-autoconf by Bob Friesenhahn:

On OpenIndiana, Autoconf 2.69b fairs very poorly without the GNU utilities in
the path.

##  ##
## Summary of the failures. ##
##  ##
Failed tests:
GNU Autoconf 2.69b test suite test groups:

 NUM: FILE-NAME:LINE TEST-GROUP-NAME
  KEYWORDS

 221: autotest.at:1893   C unit tests
  ac_config_testdir at_tested autotest
 246: torture.at:186 AC_CONFIG_FILES, HEADERS, LINKS and COMMANDS
 279: compile.at:390 AC_TRY_LINK_FUNC
 282: aclang.at:14   AC_REQUIRE_CPP
 286: c.at:94AC_PROG_CPP requires AC_PROG_CC
 287: c.at:109   AC_PROG_CPP with warnings
 288: c.at:145   AC_PROG_CPP without warnings
 289: c.at:189   AC_PROG_CPP via CC
 292: c.at:255   AC_USE_SYSTEM_EXTENSIONS
 297: acc.at:14  AC_C_BIGENDIAN
 303: acc.at:20  AC_C_STRINGIZE
 305: acc.at:22  AC_C_VARARRAYS
 307: acc.at:24  AC_OPENMP
 309: acc.at:26  AC_PROG_CPP_WERROR
 310: acc.at:27  AC_PROG_GCC_TRADITIONAL
 315: fortran.at:61  GNU Fortran
 329: fortran.at:962 AC_FC_FIXEDFORM with AC_FC_SRCEXT
 333: acfortran.at:13AC_F77_IMPLICIT_NONE
 334: acfortran.at:14AC_F77_MAIN
 335: acfortran.at:15AC_F77_WRAPPERS
 338: acfortran.at:18AC_FC_FREEFORM
 339: acfortran.at:19AC_FC_IMPLICIT_NONE
 340: acfortran.at:20AC_FC_LINE_LENGTH
 341: acfortran.at:21AC_FC_MAIN
 343: acfortran.at:23AC_FC_MODULE_FLAG
 344: acfortran.at:24AC_FC_MODULE_OUTPUT_FLAG
 345: acfortran.at:25AC_FC_PP_DEFINE
 346: acfortran.at:26AC_FC_WRAPPERS
 360: semantics.at:33AC_CHECK_LIB
 361: semantics.at:81AC_SEARCH_LIBS
 362: semantics.at:94AC_SEARCH_LIBS (none needed)
 363: semantics.at:110   AC_CHECK_DECLS
 364: semantics.at:171   AC_CHECK_FUNCS
 365: semantics.at:184   AC_REPLACE_FUNCS
 366: semantics.at:247   AC_CHECK_HEADERS
 367: semantics.at:282   AC_CHECK_HEADERS (preprocessor test)
 368: semantics.at:320   AC_CHECK_HEADERS (compiler test)
 369: semantics.at:356   AC_CHECK_MEMBER
 370: semantics.at:382   AC_CHECK_MEMBERS
 372: semantics.at:397   AC_CHECK_ALIGNOF (cross compile)
  cross
 374: semantics.at:414   AC_CHECK_ALIGNOF struct (cross compile)
  cross
 376: semantics.at:426   AC_CHECK_SIZEOF (cross compile)
  cross
 378: semantics.at:442   AC_CHECK_SIZEOF struct (cross compile)
  cross
 379: semantics.at:467   AC_CHECK_TYPES
 383: semantics.at:609   AC_C_BIGENDIAN
  cross
 386: semantics.at:792   AC_PATH_XTRA
 404: acgeneral.at:16AC_CHECK_DECLS_ONCE
 405: acgeneral.at:17AC_EGREP_CPP
 406: acgeneral.at:18AC_EGREP_HEADER
 416: acgeneral.at:30AC_TRY_CPP
  autoupdate
 423: acspecific.at:14   AC_SYS_LARGEFILE
 426: acspecific.at:19   AC_AIX
  autoupdate
 428: acspecific.at:21   AC_DECL_SYS_SIGLIST
  autoupdate
 431: acspecific.at:24   AC_IRIX_SUN
  autoupdate
 433: acspecific.at:26   AC_MINIX
  autoupdate
 434: acspecific.at:27   AC_SCO_INTL
  autoupdate
 435: acspecific.at:28   AC_XENIX_DIR
  autoupdate
 439: acprograms.at:16   AC_PROG_LEX
 447: acprograms.at:26   AC_DECL_YYTEXT
  autoupdate
 450: acheaders.at:14AC_CHECK_HEADER_STDBOOL
 455: acheaders.at:19AC_HEADER_STDBOOL
 456: acheaders.at:20AC_HEADER_TIOCGWINSZ
 464: actypes.at:14  AC_STRUCT_DIRENT_D_TYPE
 466: actypes.at:16  AC_STRUCT_TIMEZONE
 467: actypes.at:17  AC_TYPE_INT16_T
 468: actypes.at:18  AC_TYPE_INT32_T
 469: actypes.at:19  AC_TYPE_INT64_T
 470: actypes.at:20  AC_TYPE_INT8_T
 471: actypes.at:21  AC_TYPE_INTMAX_T
 472: actypes.at:22  AC_TYPE_INTPTR_T
 475: actypes.at:25  AC_TYPE_MODE_T
 476: actypes.at:26  AC_TYPE_OFF_T
 477: actypes.at:27  AC_TYPE_SSIZE_T
 482: actypes.at:32  AC_TYPE_UINTMAX_T
 483: actypes.at:33  AC_TYPE_UINTPTR_T
 489: actypes.at:41  AC_TYPE_SIGNAL
  autoupdate
 490: actypes.at:42  AM_TYPE_PTRDIFF_T
  autoupdate
 492: acfunctions.at:14  AC_FUNC_CHOWN
 494: acfunctions.at:16  AC_FUNC_ERROR_AT_LINE
 496: acfunctions.at:18  AC_FUNC_FORK
 498: acfunctions.at:20  AC_FUNC_GETGROUPS
 500: acfunctions.at:22  AC_FUNC_GETPGRP
 507: acfunctions.at:29  AC_FUNC_OBSTACK
 510: acfunctions.at:32  AC_FUNC_SETPGRP
 513: acfunctions.at:35  AC_FUNC_STRER