Re: How can Autoconf help with the transition to stricter compilation defaults?

[Florian Weimer via cfe-commits]

* Zack Weinberg via Gcc:

> I’m the closest thing Autoconf has to a lead maintainer at present.
>
> It’s come to my attention (via https://lwn.net/Articles/913505/ and
> https://fedoraproject.org/wiki/Changes/PortingToModernC) that GCC and
> Clang both plan to disable several “legacy” C language features by
> default in a near-future release (GCC 14, Clang 16) (see the Fedora
> wiki link for a list).  I understand that this change potentially
> breaks a lot of old dusty code, and in particular that
> Autoconf-generated configure scripts use constructs that may *silently
> give the wrong answer to a probe* when a stricter compiler is in use.

Thank you for reaching out.  The c-std-porting list isn't even
bootstrapped yet, the Fedora documentation is still in flux, and the
Fedora oversight body just approved working on this in the Fedora
context.  That LWN article caught me a bit off guard.

Anyway, based on a limited attempt to get this fixed about three years
ago, I expect that many of the problematic packages have not had their
configure scripts regenerated using autoconf for a decade or more.  This
means that as an autoconf maintainer, you unfortunately won't be able to
help us much.

> Nobody has a whole lot of time to work on Autoconf at present, but I
> would like to ask, anyway, what Autoconf could potentially do to make
> this transition easier.  I’m already aware that the test code Autoconf
> 2.71 uses to probe for C89/C99/C11 support is broken; this has been
> fixed in development trunk to the extent it is possible for me to test
> it with GCC 12 (commit:
> ).

Thanks, these changes are going to be helpful to get a clean run from
our Fedora tester.

I also noticed some issues in the automake test suite, and I hope
Frederic can have a look at them:

  automake: Port to modern C
  

> Several other places using K&R function definitions and/or
> unprototyped function declarations (including the ubiquitously used
> AC_CHECK_FUNC) have also been fixed on trunk,
> .

One reason I hesitate to recommend wide testing with -Werror=… is that
it is actually impossible to model future GCC behavior with -Werror=…
options today.  I very much doubt that the AC_CHECK_FUNC change [that
is, () → (void)] will ever be required by real GCC.  I'm worried that
some of this -Werror=… testing merely introduces unnecessary churn.
These changes help maintainers who wnat to build their packages with
CC="gcc -Werror=…" or something like that, so I guess they still make
sense for autoconf.  But perhaps not as a general model for everyone
else.

> The biggest remaining (potential) problem, that I’m aware of, is that
> AC_CHECK_FUNC unconditionally declares the function we’re probing for
> as ‘char NAME (void)’, and asks the compiler to call it with no
> arguments, regardless of what its prototype actually is.  It is not
> clear to me whether this will still work with the planned changes to
> the compilers.  Both GCC 12 and Clang 14 have on-by-default warnings
> triggered by ‘extern char memcpy(void);’ (or any other standard
> library function whose prototype is coded into the compiler) and this
> already causes problems for people who run configure scripts with
> CC='cc -Werror'.

I think t his approach is actually the most portable approach, at least
as far as GCC is concerned.  GCC treats a function as a compiler
built-in only if the declared prototype matches its expectations.  I
doubt there are any such functions returning char, which makes this
declaration a good choice.  I do not expect any medium-term changes to
the situation here.  The warning will stay, it will not turn into an
error.

> Unfortunately this is very hard to fix — we would
> have to build a comprehensive list of library functions into Autoconf,
> mapping each to either its documented prototype or to a header where
> it ought to be declared; in the latter case we would also have to make
> e.g. AC_CHECK_FUNCS([getaddrinfo]) imply AC_CHECK_HEADERS([sys/types.h
> sys/socket.h netdb.h]) which might mess up configure scripts that
> aren’t expecting headers to be probed at that point.

Once you include the header, you also need to know function parameters,
otherwise you won't be able to form a valid call.  Python
setuptools/distutils tried to do something along this lines, but I can't
see how it can work, as explained here:

  Unclear how CCompiler.has_function works for functions with parameters
  

The char-returning prototype does not seem so bad in the end.  The
function is actually called and the result returned from main, so it's
even compatible with LTO.

> How important do you think it is for this to be fixed?

In isolation?  Not important at all.  Maybe it wo

Re: How can Autoconf help with the transition to stricter compilation defaults?

[Florian Weimer via cfe-commits]

* Rich Felker:

> I've been writing/complaining about autoconf doing this wrong for
> decades, with the best writeup around 9 years ago at
> https://ewontfix.com/13/. Part of the reason is that this has bitten
> musl libc users over and over again due to configure finding symbols
> that were intended only as ABI-compat and trying to use them (without
> declarations) at the source level, leading to various messes, some of
> which we're only just extricating ourselves from now:
>
> https://git.musl-libc.org/cgit/musl/commit/?id=246f1c811448f37a44b41cd8df8d0ef9736d95f4
> https://git.musl-libc.org/cgit/musl/commit/?id=25e6fee27f4a293728dd15b659170e7b9c7db9bc

glibc and autoconf use a __stub_ macro handshake to achieve this.  It
allows you declare and define functions and still have the corresponding
autoconf test fail.  This facility does not depend on GNU-style symbol
versioning.

> But aside from issues like this, just the fact that autoconf was
> precluding making -Werror=implicit-function-declaration default must
> have wasted tens if not hundreds of thousands of human hours debugging
> broken builds.
>
> What I'd like to see happen is complete deprecation of the autoconf
> link-only tests -- only keeping them for use by legacy unmaintained
> projects in the form where they actually implicitly include the right
> header and test compile and link using that.

It may be technically the right thing to do, but for tests that check
for more than just symbol presence, we might need something that has a
third failure mode—“cannot tell”—beyond “feature is there” and “feature
is missing”.  With a binary approach, it is just too easy to produce a
broken test that fails for the wrong reasons.  With compile-time
testing, such unexpected failures become more likely.  Maybe something
like “if strerror_r exists, it must be usable like this, or usable like
that, but not neither or both at the same time”.  Doing this properly
probably needs toolchain support (which is more likely to become
generally available in C++ than in C).

Thanks,
Florian

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: How can Autoconf help with the transition to stricter compilation defaults?

[Florian Weimer via cfe-commits]

* Paul Eggert:

> On 2022-11-14 04:41, Aaron Ballman wrote:
>> it's generally a problem when autoconf relies on invalid
>> language constructs
>
> Autoconf *must* rely on invalid language constructs, if only to test
> whether the language constructs work. And Clang therefore must be 
> careful about how it diagnoses invalid constructs. Clang shouldn't
> willy-nilly change the way it reports invalid constructs, as that can 
> break Autoconf.

This is only true for the status quo.  We could finally band together
and define an interface between autoconf and the toolchain that avoids
feature probing through source code fragments for common cases.  It
might make configure scripts to run quite a bit faster, too.

That being said, system compilers need to be careful when turning
warnings into errors by default, but that doesn't mean we should never
do such changes, particularly when we know based on interactions with
programmers that the warnings are not sufficient for avoiding wasted
time.

Thanks,
Florian

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

[Florian Weimer via cfe-commits]

* H. J. Lu:

> I am proposing to update Intel386, x86-64 and IA MCU psABIs to specify
> how to pass/return empty struct:
>
> 1. "collection".  A collection is a structure, union or C++ class.
> 2. "empty collection".  An empty collection is:
>a. A collection without member.  Or
>b. A collection with only empty collections.  Or
>c. An array of empty collections.
> 3. "empty record".  An empty record is Plain Old Data (POD) for the purpose
>of layout and
>a. A collection without member.  Or
>b. A collection with only empty collections.
> 4. No memory slot nor register should be used to pass or return an object of
> empty collection.

“Aggregate” may be the more standard term instead of collection.

I think you mean “empty record” under 4.

Any syntactical array argument (at the C level) is should be passed as
a pointer.  The language appears to change that.

For 2., static members and non-data members do not count.

Does the definition of POD vary between C++ standards?  Then the
calling convention would vary as well, which is probably not what we
want.

How do existing C++ compilers implement empty array members (an
extension)?  Does the type of such members affect whether a class is a
standard-layout class?

Florian
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

[Florian Weimer via cfe-commits]

* H. J. Lu:

>> Any syntactical array argument (at the C level) is should be passed as
>> a pointer.  The language appears to change that.
>
> I didn't use aggregate so that array is excluded here.
>
>> For 2., static members and non-data members do not count.
>
> They do count here.  That is why I used "POD for the purpose of
> layout.

Let's see what happens today.

struct s0 {
  s0();
};

struct s1 {
  static int a;
};

struct s2 {
  void member();
};

struct s3 {
  int a[0];
};

struct s4 {
  s0 a[0];
};

struct s5 {
  s1 a[1];
};


I tested GCC 5.3.1 and Clang 3.5.0.

 GCC  Clang
s0   non-emptynon-empty
s1   non-emptyempty
s2   non-emptyempty
s3   emptyempty
s4   emptyempty
s5   non-emptyempty

I believe s3, s4, s5 are non-empty according to your rules.  Why put
both compilers in the wrong?  That doesn't make sense to me.

Jason already indicated he intends GCC to move towards more empty
arguments, not fewer.

>> How do existing C++ compilers implement empty array members (an
>> extension)?  Does the type of such members affect whether a class is a
>> standard-layout class?

> Are they "POD for the purpose of layout"? If yes, they are covered here.

The C++ standard does not define this.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

[Florian Weimer via cfe-commits]

* H. J. Lu:

>> I tested GCC 5.3.1 and Clang 3.5.0.
>>
>>  GCC  Clang
>> s0   non-emptynon-empty
>> s1   non-emptyempty
>> s2   non-emptyempty
>> s3   emptyempty
>> s4   emptyempty
>> s5   non-emptyempty
>>
>> I believe s3, s4, s5 are non-empty according to your rules.  Why put
>> both compilers in the wrong?  That doesn't make sense to me.
>
> Please try testcases in
>
> https://llvm.org/bugs/show_bug.cgi?id=26337
>
> with clang on both ia32 and x86-64.  Clang isn't consistent between
> ia32 and x86-64.

Okay, with -m32, I get non-empty passing for s5 from Clang as well.
But I still don't think it makes sense to change the ABI for s3 and
s4, and even for s5, the Clang/x86_64 behavior is arguably more
correct.

>> Jason already indicated he intends GCC to move towards more empty
>> arguments, not fewer.
>>
 How do existing C++ compilers implement empty array members (an
 extension)?  Does the type of such members affect whether a class is a
 standard-layout class?
>>
>>> Are they "POD for the purpose of layout"? If yes, they are covered here.
>>
>> The C++ standard does not define this.
>
> GCC has
>
> * Nonzero means that this class type is not POD for the purpose of layout
>(as defined in the ABI).  This is different from the language's POD.  */
> #define CLASSTYPE_NON_LAYOUT_POD_P(NODE) \
>
> We can use this definition for ia32, x86-64 and IA MCU psABIs.

It still has to be spelled out in non-GCC terms, IMHO.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: Linux-abi group

[Florian Weimer via cfe-commits]

* H. J. Lu:

> I created a mailing list to discuss Linux specific,.processor independent
> modification and extension of generic System V Application Binary Interface:
>
> https://groups.google.com/d/forum/linux-abi
>
> I will start to document existing Linux extensions, like STT_GNU_IFUNC.
> I will propose some new extensions soon.

Why can't you use the existing C++ ABI list?  Is there no overlap at
all?

Florian
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: Linux-abi group

[Florian Weimer via cfe-commits]

* H. J. Lu:

> On Mon, Feb 8, 2016 at 11:32 AM, Florian Weimer  wrote:
>> * H. J. Lu:
>>
>>> I created a mailing list to discuss Linux specific,.processor independent
>>> modification and extension of generic System V Application Binary Interface:
>>>
>>> https://groups.google.com/d/forum/linux-abi
>>>
>>> I will start to document existing Linux extensions, like STT_GNU_IFUNC.
>>> I will propose some new extensions soon.
>>
>> Why can't you use the existing C++ ABI list?  Is there no overlap at
>> all?
>>
> :
> I wasn't referring to empty class
>
> https://gcc.gnu.org/ml/gcc/2016-02/msg00057.html

But still there is going to be some overlap?

> I was referring to program properties:
>
> https://groups.google.com/forum/#!topic/generic-abi/fyIXttIsYc8

This looks more like an ELF topic to me, not really ABI.

Please discuss this on a GNU project list because it affects the
entire GNU project.

Florian
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits