Re: How can Autoconf help with the transition to stricter compilation defaults?
Hello,
On Wed, 16 Nov 2022, Paul Eggert wrote:
> On 2022-11-16 06:26, Michael Matz wrote:
> > char foobar(void);
> > int main(void) {
> >return != 0;
> > }
>
> That still has undefined behavior according to draft C23,
This is correct (and also holds for the actually working variant later,
with a volatile variable). If your argument is then that as both
solutions for the link-test problem are relying on undefined behaviour
they are equivalent and hence no change is needed, you have a point, but I
disagree. In practice one (with the call) will cause more problems than
the other (with address taking).
> If Clang's threatened pickiness were of some real use elsewhere, it
> might be justifiable for default Clang to break Autoconf. But so far we
> haven't seen real-world uses that would justify this pickiness for
> Autoconf's use of 'char memset_explicit(void);'.
Note that both, GCC and clang, already warn (not error out!) about the
mismatching decl, even without any headers. So we are in the pickiness
era already.
I.e. a C file containing just a single line "char printf(void);" will be
warned about, by default. There is about nothing that autoconf could do
to rectify this, except containing a long list of prototypes for
well-known functions, with the associated maintenance hassle. But
autoconf _can_ do something about how the decls are used in the
link-tests.
Ciao,
Michael.
___
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?
Hello,
On Wed, 16 Nov 2022, Jonathan Wakely wrote:
> > > Unrelated but I was a bit tempted to ask for throwing in
> > > -Wbuiltin-declaration-mismatch to default -Werror while Clang 16 was at
> > > it, but I suppose we don't want the world to burn too much,
> >
> > :-) It's IMHO a bug in the standard that it misses "if any of its
> > associated headers are included" in the item for reservation of external
> > linkage identifiers; it has that for all other items about reserved
> > identifiers in the Library clause. If that restriction were added you
> > couldn't justify erroring on the example at hand (because it doesn't
> > include e.g. and then printf wouldn't be reserved). A warning
> > is of course always okay and reasonable. As is, you could justify
> > erroring out, but I too think that would be overzealous.
>
>
> I think that's very intentional and not a defect in the standard.
>
> If one TU was allowed to define:
>
> void printf() { }
>
> and have that compiled into the program, then that would cause
> unexpected behaviour for every other TU which includes and
> calls printf. They would get the non-standard rogue printf.
True. But suppose the restriction would be added. I could argue that
then your problem program (in some other TU) _does_ include the header,
hence the identifier would have been reserved and so the above definition
would have been wrong. I.e. I think adding the restriction wouldn't allow
the problematic situation either.
I'm aware that the argument would then invoke all the usual problems of
what constitutes a full program, and if that includes the library even
when not including headers and so on. And in any case currently the
standard does say they're reserved so it's idle speculation anyway :)
Ciao,
Michael.
___
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?
Hello, On Wed, 16 Nov 2022, Sam James wrote: > Unrelated but I was a bit tempted to ask for throwing in > -Wbuiltin-declaration-mismatch to default -Werror while Clang 16 was at > it, but I suppose we don't want the world to burn too much, :-) It's IMHO a bug in the standard that it misses "if any of its associated headers are included" in the item for reservation of external linkage identifiers; it has that for all other items about reserved identifiers in the Library clause. If that restriction were added you couldn't justify erroring on the example at hand (because it doesn't include e.g. and then printf wouldn't be reserved). A warning is of course always okay and reasonable. As is, you could justify erroring out, but I too think that would be overzealous. Ciao, Michael. ___ 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?
Hey,
On Wed, 16 Nov 2022, Alexander Monakov wrote:
> > The idea is so obvious that I'm probably missing something, why autoconf
> > can't use that idiom instead. But perhaps the (historic?) reasons why it
> > couldn't be used are gone now?
>
> Ironically, modern GCC and LLVM optimize ' != 0' to '1' even at -O0,
> and thus no symbol reference remains in the resulting assembly.
Err, right, *head-->table*.
Playing with volatile should help:
char foobar(void);
char (* volatile ptr)(void);
int main(void) {
ptr = foobar;
return ptr != 0;
}
Ciao,
Michael.
___
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?
Hi,
On Tue, 15 Nov 2022, Paul Eggert wrote:
> On 2022-11-15 11:27, Jonathan Wakely wrote:
> > Another perspective is that autoconf shouldn't get in the way of
> > making the C and C++ toolchain more secure by default.
>
> Can you cite any examples of a real-world security flaw what would be
> found by Clang erroring out because 'char foo(void);' is the wrong
> prototype? Is it plausible that any such security flaw exists?
>
> On the contrary, it's more likely that Clang's erroring out here would
> *introduce* a security flaw, because it would cause 'configure' to
> incorrectly infer that an important security-relevant function is
> missing and that a flawed substitute needs to be used.
>
> Let's focus on real problems rather than worrying about imaginary ones.
I sympathize, and I would think a compiler emitting an error (not a
warning) in the situation at hand (in absence of -Werror) is overly
pedantic. But, could autoconf perhaps avoid the problem? AFAICS the
ac_fn_c_check_func really does only a link test to check for symbol
existence, and the perceived problem is that the call statement in main()
invokes UB. So, let's avoid the call then while retaining the access to
the symbol? Like:
-
char foobar(void);
int main(void) {
return != 0;
}
-
No call involved: no reason for compiler to complain. The prototype decl
itself will still be "wrong", but compilers complaining about that (in
absence of a pre-existing different prototype, which is avoided by
autoconf) seem unlikely.
Obviously this program will also say "foobar exists" if it's a data
symbol, but that's the same with the variant using the call on most
platforms (after all it's not run).
The idea is so obvious that I'm probably missing something, why autoconf
can't use that idiom instead. But perhaps the (historic?) reasons why it
couldn't be used are gone now?
Ciao,
Michael.
___
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
Hi, On Mon, 29 Feb 2016, Jason Merrill wrote: > > Also this insistence that all of "trivially copyable" is already quite > > nicely specified in the C++ ABI is still not really relevant because > > C++ _is not the only language out there_. I'm not sure how often I > > have to repeat this until people get it. > > Other language ABIs can handle language specific calling conventions as > appropriate for them. The psABI can only talk about things that are in > its domain. Naturally. How far to follow that road, though? Remove the word "class" from the description of empty types again? Why is that in-domain and the notion of trivially copyable isn't? Ciao, Michael. ___ 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
Hi,
On Fri, 26 Feb 2016, H.J. Lu wrote:
> >> It is clear to me now. Let's go with
> >>
> >> ---
> >> An empty type is a type where it and all of its subobjects (recursively)
> >> are of class, structure, union, or array type. No memory slot nor
> >> register should be used to pass or return an object of empty type that's
> >> trivially copyable.
> >> ---
> >>
> >> Any comments?
> >
> > Yes. "trivially copyable" is the wrong restriction. See
> > http://mentorembedded.github.io/cxx-abi/abi.html#normal-call for the
> > actual Itanium C++ ABI rule.
>
> I looked it up. " trivially copyable" is covered by C++ ABI.
>
> > It's also completely nonsensical to mention this as a special case in
> > relation to empty types. The special case applies to all function
> > parameters, irrespective of whether they're empty -- this rule applies
> > *long* before you consider whether the type is empty. For instance, in
> > the x86-64 psABI, this should go right at the start of section 2.2.3
> > ("Parameter Passing and Returning Values"). But please don't add it
> > there -- it's completely redundant, as section 5.1 already says that
> > the Itanium C++ ABI is used, so it's not necessary to duplicate rules
> > from there.
>
> Here is the final wording:
>
> An empty type is a type where it and all of its subobjects (recursively)
> are of class, structure, union, or array type. No memory slot nor register
> should be used to pass or return an object of empty type.
>
> Footnote: Array of empty type can only passed by reference in C and C++.
>
> Michael, can you put it in x86-64 psABI? I will update i386 and IA MCU
> psABIs.
Not without further discussion, sorry. If we want to invoke the C++ ABI
to not have to worry about trivially copyable (and yeah, of course it
would be placed better at the beginning for the whole argument passing
section), then we need to also look at its other rules. In particular at:
3.1.3 Empty Parameters
* Empty classes will be passed no differently from ordinary classes. If
passed in registers the NaT bit must not be set on all registers that
make up the class.
* The contents of the single byte parameter slot are unspecified, and the
callee may not depend on any particular value. On Itanium, the
associated NaT bit must not be set if the parameter slot is associated
with a register.
So, in C++, empty classes will be passed as above, not as no registers.
The new rule would create a conflict between "no registers/slots" and "the
single byte parameter slot".
Have you thought about this?
(I'll also note that putting in this rule might interact with "2.2 POD
Data Types / If the base ABI does not specify rules for empty classes,
then an empty class has size and alignment 1." because we now do specify
rules for empty classes, though not for size and alignment explicitely).
Also this insistence that all of "trivially copyable" is
already quite nicely specified in the C++ ABI is still not really relevant
because C++ _is not the only language out there_. I'm not sure how often
I have to repeat this until people get it.
Ciao,
Michael.
___
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
Hi, On Tue, 23 Feb 2016, H.J. Lu wrote: > > --- > > An empty type is a type where it and all of its subobjects (recursively) > > are of class, structure, union, or array type. No memory slot nor > > register should be used to pass or return an object of empty type that's > > trivially copyable. > > --- > > > > (With possibly a self-sufficient definition of trivially copyable, that's > > language agnostic) > > > > Do you have an example in which an empty type defined above isn't > "trivially copyable"? The ones we've always talked about: empty C++ types with non-trivial copy ctors or dtors. Yes, I'm aware of the fact that the Itanium C++ ABI doesn't invoke the underlying psABI for these types (or better, it specifies them to be passed by reference). But first, there are other languages that have such constructs, but don't necessarily have an written-down ABI (OO fortran anyone? Ada?). Second, there may be other C++ ABIs that don't contain such language (which would be an ommission, but well, happens). And third even for our C++ needs (based on the Itanium ABI) I feel it's simply more clear and self-sufficient to be explicit about this restriction. It's not that we have any sort of upper bound on the number of words we're allowed to use in the psABI, and I also don't think anything is gained by being as terse as possible. Succinct, sure, but not as arcane as we can make it while still being correct. So, question back: can you imaging any cases where the "restriction" to trivially copyable would _not_ do the thing we want? Ciao, Michael. ___ 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
Hi, On Sat, 20 Feb 2016, Richard Smith wrote: > > An empty type is a type where it and all of its subobjects > > (recursively) are of class, structure, union, or array type. > > > > doesn't cover "trivially-copyable". > > That's correct. Whether a type is trivially copyable is unrelated to > whether it is empty. I would still feel more comfortable to include the restriction to trivially copyable types, not in the part of definition of empty type, of course, but as part of the restrictions of when a type can be passed in no registers. Basically to clarify the intent in the psABI if there's any doubt. I.e. like so: --- An empty type is a type where it and all of its subobjects (recursively) are of class, structure, union, or array type. No memory slot nor register should be used to pass or return an object of empty type that's trivially copyable. --- (With possibly a self-sufficient definition of trivially copyable, that's language agnostic) Ciao, Michael. ___ 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
Hi,
On Fri, 19 Feb 2016, Richard Smith wrote:
> >> > The trivially copyable is gone again. Why is it not necessary?
> >>
> >> The C++ ABI doesn't defer to the C psABI for types that aren't
> >> trivially-copyable. See
> >> http://mentorembedded.github.io/cxx-abi/abi.html#normal-call
> >
> > Hmm, yes, but we don't want to define something for only C and C++, but
> > language independend (so far as possible). And given only the above
> > language I think this type:
> >
> > struct S {
> > S() {something();}
> > };
> >
> > would be an empty type, and that's not what we want.
>
> Yes it is. Did you mean to give S a copy constructor, copy assignment
> operator, or destructor instead?
Er, yes, I did mean to :-)
Ciao,
Michael.
___
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
Hi,
On Thu, 18 Feb 2016, H.J. Lu wrote:
> >> An empty type is a type where it and all of its subobjects
> >> (recursively) are of class, structure, union, or array type. No
> >> memory slot nor register should be used to pass or return an object
> >> of empty type.
> >
> > The trivially copyable is gone again. Why is it not necessary?
>
> I think we want to cover
>
> struct
> {
> unsigned int : 8;
> };
>
> but not
>
> struct
> {
> unsigned int i :8;
> };
>
> " trivially copyable" applies to both.
Correct, but I'm not suggesting to use only the trivially copyable
definition, I want to have it added as condition for not requiring a
register or memory slot. I.e. "an object of empty type that's trivially
copyable".
Ciao,
Michael.
___
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
Hi,
On Thu, 18 Feb 2016, Richard Smith wrote:
> >> An empty type is a type where it and all of its subobjects
> >> (recursively) are of class, structure, union, or array type. No
> >> memory slot nor register should be used to pass or return an object
> >> of empty type.
> >
> > The trivially copyable is gone again. Why is it not necessary?
>
> The C++ ABI doesn't defer to the C psABI for types that aren't
> trivially-copyable. See
> http://mentorembedded.github.io/cxx-abi/abi.html#normal-call
Hmm, yes, but we don't want to define something for only C and C++, but
language independend (so far as possible). And given only the above
language I think this type:
struct S {
S() {something();}
};
would be an empty type, and that's not what we want. "Trivially copyable"
is a reasonably common abstraction (if in doubt we could even define it in
the ABI), and captures the idea that we need well (namely that a bit-copy
is enough).
Ciao,
Michael.
___
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
Hi, On Tue, 16 Feb 2016, H.J. Lu wrote: > Here is the new definition: > > An empty type is a type where it and all of its subobjects (recursively) > are of class, structure, union, or array type. No memory slot nor > register should be used to pass or return an object of empty type. The trivially copyable is gone again. Why is it not necessary? Ciao, Michael. ___ 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
Hi,
On Thu, 11 Feb 2016, H.J. Lu wrote:
> Any suggestions on new wording, something like
>
> 1. "class type". A class type is a structure, union or C++ class.
> 2. "empty type". An empty type is a type where it and all of its
> subobjects are of class or array type.
>
> Does it cover
>
> struct A { };
> struct B { };
> struct C : A, B { };
I think this is covered by the above points. But without further
restriction I don't see how e.g. the above example with ctors and dtors
would be ruled out (except if you regard a ctor as a sub-object). For
that you seem to need trivially-copyable, or that POD-ly thing. So,
perhaps simply amend (2) "... is a trivially copyable type where it ...".
Ciao,
Michael.
___
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
Hi, On Thu, 11 Feb 2016, Jonathan Wakely wrote: > On 11 February 2016 at 12:40, Matthijs van Duin wrote: > > You never define "POD for the purposes of layout", and I can only > > interpret it as being equivalent to "standard-layout". > > As Richard pointed out, it's defined in the C++ ABI. Which is C++y as well (and hence doesn't in itself solve the C/C++ compatibility we should strive for in the ABI). I'll concur with Matthijs and think that trivially copyable is the correct distinction for passing without registers (in addition of it being clearer than a strangly defined concept of "POD-but-not-quite-POD"). Do you think different? Are there non-trivially copyable examples that we'd wish to pass without registers as well? Ciao, Michael. ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
