Lenient overhead resolutions and where to find them in the manual
GCC seems to have a non-standard lenient C++ overload resolution that is
not documented (or easy to find in the manual).
The following C++ code compiles with GCC. However, it produces a warning
about an ambiguous overload that apparently is not acceptable by the
standard. Clang and MVSC simply reject the code because of the ambiguous
overload.
```
// reduced example
#include
using namespace std;
struct A{};
struct B: public A {};
struct C{};
struct D{ D() = default; D(const C&){}; };
void p( A&, const C& ){ cout << "AC\n"; };
void p( B&, const D& ){ cout << "BD\n"; };
int main() {
B b; C c;
p(b,c); // ambiguous call
return 0;
}
```
GCC detects ambiguity in which `p` to choose: either cast from derived
class B& to base class A& or construct D from C.
```
$ g++ test.cpp
test.cpp: In function ‘int main()’:
test.cpp:51:10: warning: ISO C++ says that these are ambiguous, even
though the worst conversion for the first is better than the worst
conversion for the second:
51 | p(b,c);
| ~^
test.cpp:12:6: note: candidate 1: ‘void p(A&, const C&)’
12 | void p( A&, const C& ){ cout << "AC\n"; };
| ^
test.cpp:15:6: note: candidate 2: ‘void p(B&, const D&)’
15 | void p( B&, const D& ){ cout << "BD\n"; };
| ^
```
With `-pedantic` it does not compile anymore. I subjectively agree with
GCC that the first choice is better than the second. But not everyone
may do so. Is there a documentation of all these deviations from the
standard?
Re: Lenient overhead resolutions and where to find them in the manual
On Mon, 29 Jan 2024, 18:17 Martin Licht via Gcc, wrote:
> GCC seems to have a non-standard lenient C++ overload resolution that is
> not documented (or easy to find in the manual).
>
> The following C++ code compiles with GCC. However, it produces a warning
> about an ambiguous overload that apparently is not acceptable by the
> standard. Clang and MVSC simply reject the code because of the ambiguous
> overload.
>
> ```
> // reduced example
> #include
> using namespace std;
> struct A{};
> struct B: public A {};
> struct C{};
> struct D{ D() = default; D(const C&){}; };
>
> void p( A&, const C& ){ cout << "AC\n"; };
> void p( B&, const D& ){ cout << "BD\n"; };
>
> int main() {
> B b; C c;
> p(b,c); // ambiguous call
> return 0;
> }
> ```
>
> GCC detects ambiguity in which `p` to choose: either cast from derived
> class B& to base class A& or construct D from C.
>
> ```
> $ g++ test.cpp
> test.cpp: In function ‘int main()’:
> test.cpp:51:10: warning: ISO C++ says that these are ambiguous, even
> though the worst conversion for the first is better than the worst
> conversion for the second:
> 51 | p(b,c);
>| ~^
> test.cpp:12:6: note: candidate 1: ‘void p(A&, const C&)’
> 12 | void p( A&, const C& ){ cout << "AC\n"; };
>| ^
> test.cpp:15:6: note: candidate 2: ‘void p(B&, const D&)’
> 15 | void p( B&, const D& ){ cout << "BD\n"; };
>| ^
> ```
>
> With `-pedantic` it does not compile anymore. I subjectively agree with
> GCC that the first choice is better than the second. But not everyone
> may do so. Is there a documentation of all these deviations from the
> standard?
>
The standard says this is ill-formed and requires a diagnostic, and gcc
gives you a diagnostic. So it's not strictly-speaking a deviation from the
standard.
I don't think there are docs for this or for other similar "pedwarn"
extensions.
>
Re: Lenient overhead resolutions and where to find them in the manual
On Mon, 29 Jan 2024, 18:24 Jonathan Wakely, wrote:
>
>
> On Mon, 29 Jan 2024, 18:17 Martin Licht via Gcc, wrote:
>
>> GCC seems to have a non-standard lenient C++ overload resolution that is
>> not documented (or easy to find in the manual).
>>
>> The following C++ code compiles with GCC. However, it produces a warning
>> about an ambiguous overload that apparently is not acceptable by the
>> standard. Clang and MVSC simply reject the code because of the ambiguous
>> overload.
>>
>> ```
>> // reduced example
>> #include
>> using namespace std;
>> struct A{};
>> struct B: public A {};
>> struct C{};
>> struct D{ D() = default; D(const C&){}; };
>>
>> void p( A&, const C& ){ cout << "AC\n"; };
>> void p( B&, const D& ){ cout << "BD\n"; };
>>
>> int main() {
>> B b; C c;
>> p(b,c); // ambiguous call
>> return 0;
>> }
>> ```
>>
>> GCC detects ambiguity in which `p` to choose: either cast from derived
>> class B& to base class A& or construct D from C.
>>
>> ```
>> $ g++ test.cpp
>> test.cpp: In function ‘int main()’:
>> test.cpp:51:10: warning: ISO C++ says that these are ambiguous, even
>> though the worst conversion for the first is better than the worst
>> conversion for the second:
>> 51 | p(b,c);
>>| ~^
>> test.cpp:12:6: note: candidate 1: ‘void p(A&, const C&)’
>> 12 | void p( A&, const C& ){ cout << "AC\n"; };
>>| ^
>> test.cpp:15:6: note: candidate 2: ‘void p(B&, const D&)’
>> 15 | void p( B&, const D& ){ cout << "BD\n"; };
>>| ^
>> ```
>>
>> With `-pedantic` it does not compile anymore. I subjectively agree with
>> GCC that the first choice is better than the second. But not everyone
>> may do so. Is there a documentation of all these deviations from the
>> standard?
>>
>
>
> The standard says this is ill-formed and requires a diagnostic, and gcc
> gives you a diagnostic. So it's not strictly-speaking a deviation from the
> standard.
>
> I don't think there are docs for this or for other similar "pedwarn"
> extensions.
>
You can find them all by grepping the sources for pedwarn though.
>
Re: contributing advice
On 26/01/2024 17:51, Florin Mateoc via Gcc wrote: > Hi all, > > I am an experienced software developer, with an interest in compilers, and > an admirer of gcc. > I would like to contribute, hopefully reusing some of my existing skills, > experience and interests, but unfortunately the (current) overlap is not > great, so I am asking for some guidance/reality check. Hi Florin, I'm also just starting to contribute and it's a bit daunting, you're not the only one! :). Why not start with an existing bug report? https://gcc.gnu.org/bugs/ has a link to bugzilla, which is full of opportunities! Cheers, Claudio > While I did start my career (a long time ago (my first programming > language, in college, was Fortran (77), using punch cards)) writing > software in assembly for bare metal and debugging it with an oscilloscope > and a serial interface, and I also wrote (in Borland C++) a remote debugger > for a micro-controller development board, for a long time now I've only > been using higher-level languages, and my C is quite rusty. > I am an expert-level programmer in Smalltalk, Java and JavaScript, but I am > aware that these are not even client languages, let alone useful/used for > gcc development. > As far as compiler-related experience, I have worked on a type inferencer > for Smalltalk and on a Smalltalk to Java transpiler, part of a proprietary > tool that has been used to migrate a very large and successful Smalltalk > financial application to Java. I have also written an open-source > transpiler from Smalltalk to JavaScript (https://github.com/fmateoc/JsSqueak) > that can compile a Smalltalk image to JavaScript code that can be run in a > browser. > > With regards to potential contribution areas, among the supported > languages, Objective-C is close enough to Smalltalk that I think I should > be able to contribute, but I am not sure how much interest there is for it, > especially in its gcc incarnation. I was also thinking (without looking at > the code, so this could be just wishful thinking) that I might try to work > on something Gimple-related. Of course, this is just what I came up with, > based on very incomplete information > > I would appreciate any thoughts/advice. > > Thank you, > Florin
Re: contributing advice
On Mon, 29 Jan 2024 at 19:15, Claudio Bantaloukas via Gcc wrote: > > On 26/01/2024 17:51, Florin Mateoc via Gcc wrote: > > Hi all, > > > > I am an experienced software developer, with an interest in compilers, and > > an admirer of gcc. > > I would like to contribute, hopefully reusing some of my existing skills, > > experience and interests, but unfortunately the (current) overlap is not > > great, so I am asking for some guidance/reality check. > > Hi Florin, > I'm also just starting to contribute and it's a bit daunting, you're not > the only one! :). > > Why not start with an existing bug report? https://gcc.gnu.org/bugs/ has > a link to bugzilla, which is full of opportunities! Specifically, have a look at https://gcc.gnu.org/wiki/EasyHacks Which is one of the links from the https://gcc.gnu.org/wiki/GettingStarted page. > > Cheers, > Claudio > > > While I did start my career (a long time ago (my first programming > > language, in college, was Fortran (77), using punch cards)) writing > > software in assembly for bare metal and debugging it with an oscilloscope > > and a serial interface, and I also wrote (in Borland C++) a remote debugger > > for a micro-controller development board, for a long time now I've only > > been using higher-level languages, and my C is quite rusty. > > I am an expert-level programmer in Smalltalk, Java and JavaScript, but I am > > aware that these are not even client languages, let alone useful/used for > > gcc development. > > As far as compiler-related experience, I have worked on a type inferencer > > for Smalltalk and on a Smalltalk to Java transpiler, part of a proprietary > > tool that has been used to migrate a very large and successful Smalltalk > > financial application to Java. I have also written an open-source > > transpiler from Smalltalk to JavaScript > > (https://github.com/fmateoc/JsSqueak) > > that can compile a Smalltalk image to JavaScript code that can be run in a > > browser. > > > > With regards to potential contribution areas, among the supported > > languages, Objective-C is close enough to Smalltalk that I think I should > > be able to contribute, but I am not sure how much interest there is for it, > > especially in its gcc incarnation. I was also thinking (without looking at > > the code, so this could be just wishful thinking) that I might try to work > > on something Gimple-related. Of course, this is just what I came up with, > > based on very incomplete information > > > > I would appreciate any thoughts/advice. > > > > Thank you, > > Florin
Re: contributing advice
3dw...@verizon.net On Monday, January 29, 2024 at 03:13:07 PM EST, Jonathan Wakely via Gcc wrote: On Mon, 29 Jan 2024 at 19:15, Claudio Bantaloukas via Gcc wrote: > > On 26/01/2024 17:51, Florin Mateoc via Gcc wrote: > > Hi all, > > > > I am an experienced software developer, with an interest in compilers, and > > an admirer of gcc. > > I would like to contribute, hopefully reusing some of my existing skills, > > experience and interests, but unfortunately the (current) overlap is not > > great, so I am asking for some guidance/reality check. > > Hi Florin, > I'm also just starting to contribute and it's a bit daunting, you're not > the only one! :). > > Why not start with an existing bug report? https://gcc.gnu.org/bugs/ has > a link to bugzilla, which is full of opportunities! Specifically, have a look at https://gcc.gnu.org/wiki/EasyHacks Which is one of the links from the https://gcc.gnu.org/wiki/GettingStarted page. I seems like the recent additions to the C++ standard library have a lot of things that look like a good first project.Like the flat containers (flat_map and flat_set) for example orInterfacing std::bitset with std::string_view https://wg21.link/P2697R1.OrInterfacing string streams with std::string_view https://wg21.link/P2495R3. Assuming these aren't being worked on by someone else already. > > Cheers, > Claudio > > > While I did start my career (a long time ago (my first programming > > language, in college, was Fortran (77), using punch cards)) writing > > software in assembly for bare metal and debugging it with an oscilloscope > > and a serial interface, and I also wrote (in Borland C++) a remote debugger > > for a micro-controller development board, for a long time now I've only > > been using higher-level languages, and my C is quite rusty. > > I am an expert-level programmer in Smalltalk, Java and JavaScript, but I am > > aware that these are not even client languages, let alone useful/used for > > gcc development. > > As far as compiler-related experience, I have worked on a type inferencer > > for Smalltalk and on a Smalltalk to Java transpiler, part of a proprietary > > tool that has been used to migrate a very large and successful Smalltalk > > financial application to Java. I have also written an open-source > > transpiler from Smalltalk to JavaScript > > (https://github.com/fmateoc/JsSqueak) > > that can compile a Smalltalk image to JavaScript code that can be run in a > > browser. > > > > With regards to potential contribution areas, among the supported > > languages, Objective-C is close enough to Smalltalk that I think I should > > be able to contribute, but I am not sure how much interest there is for it, > > especially in its gcc incarnation. I was also thinking (without looking at > > the code, so this could be just wishful thinking) that I might try to work > > on something Gimple-related. Of course, this is just what I came up with, > > based on very incomplete information > > > > I would appreciate any thoughts/advice. > > > > Thank you, > > Florin
Re: contributing advice
On Mon, 29 Jan 2024 at 20:25, Ed wrote: > > > On Monday, January 29, 2024 at 03:13:07 PM EST, Jonathan Wakely via Gcc > wrote: > > > On Mon, 29 Jan 2024 at 19:15, Claudio Bantaloukas via Gcc > wrote: > > > > On 26/01/2024 17:51, Florin Mateoc via Gcc wrote: > > > Hi all, > > > > > > I am an experienced software developer, with an interest in compilers, and > > > an admirer of gcc. > > > I would like to contribute, hopefully reusing some of my existing skills, > > > experience and interests, but unfortunately the (current) overlap is not > > > great, so I am asking for some guidance/reality check. > > > > Hi Florin, > > I'm also just starting to contribute and it's a bit daunting, you're not > > the only one! :). > > > > Why not start with an existing bug report? https://gcc.gnu.org/bugs/ has > > a link to bugzilla, which is full of opportunities! > > Specifically, have a look at https://gcc.gnu.org/wiki/EasyHacks > > Which is one of the links from the https://gcc.gnu.org/wiki/GettingStarted > page. > > I seems like the recent additions to the C++ standard library have a lot of > things that look like a good first project. > Like the flat containers (flat_map and flat_set) for example or > Interfacing std::bitset with std::string_view https://wg21.link/P2697R1. > Or > Interfacing string streams with std::string_view https://wg21.link/P2495R3. > Assuming these aren't being worked on by someone else already. There are bugs for some of them, which should be status=ASSIGNED if somebody's working on them: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=c%2B%2B23-lib https://gcc.gnu.org/bugzilla/show_bug.cgi?id=c%2B%2B26-lib
[Patch, stage-1, RFC]: i386: attribute regparm/stdcall and vaargs
[I was torn towards asking gcc@ only, individual i386 maintainers in
private or bluntly asking for help on gcc-patches or re-iterate through
ABI, so in an attempt to cut off years of latency i hereby ask all and
everybody for assistance. Stage4 means any chances are low, i know..
hence stage 1 material since it's not pressing in any foreseeable way]
Hello i386 maintainers
Recently, elsewhere, there was discussion about attribute regparm (and
stdcall) on functions with variable number of arguments in C.
Allegedly clang warns about these but GCC does not. I did not look at
clang.
gcc/doc/extend.texi currently states that:
---8<---
@cindex @code{regparm} function attribute, x86
[]
Functions that
take a variable number of arguments continue to be passed all of their
arguments on the stack.
[]
@cindex @code{sseregparm} function attribute, x86
[]
Functions that take a
variable number of arguments continue to pass all of their
floating-point arguments on the stack.
[]
@cindex @code{stdcall} function attribute, x86-32
[]
On x86-32 targets, the @code{stdcall} attribute causes the compiler to
assume that the called function pops off the stack space used to
pass arguments, unless it takes a variable number of arguments.
---8<---
which seems to suggest that all of attribute regparm/sseregparm/stdcall
are ignored on functions with variable number of arguments. I.e. the
ABI mandates that everything is passed on the stack.
[Right? ISTM that this is correct; Didn't follow ABI (tweaks) too
closely in the last decade, admittedly.. But i think this still holds.
Please correct me if i missed something?]
If this is correct, then ISTM that attributes
regparm/sseregparm/stdcall should be rejected on functions with
variable number of arguments also in GCC.
There seems to be (exact) struct function cfun->va_list_[fg]pr_size
for the real fpr and gpr save area sizes. But (unfortunately / of
course) they are layed out way later than parsing the attributes in
both the C++ and C FEs, so using those in ix86_handle_cconv_attribute
is not possible as there is no cfun readily available there yet. ²).
Hence i would propose to ¹):
gcc/ChangeLog:
* builtin-attrs.def (ATTR_TM_NOTHROW_RT_LIST): Use ATTR_NOTHROW_LIST
instead of ATTR_TM_NOTHROW_LIST, thus removing ATTR_TM_REGPARM.
* config/i386/i386-options.cc (ix86_handle_cconv_attribute): Decline
regparm, stdcall and regparm attribute on functions with variable number
of arguments.
libitm/ChangeLog:
* libitm.h (_ITM_beginTransaction): Remove ITM_REGPARM.
gcc/testsuite/ChangeLog:
* gcc.dg/lto/trans-mem.h: Remove ITM_REGPARM.
* gcc.target/i386/attributes-error.c: Extend to cover
(regparm(3),stdcall) on vaargs functions.
* gcc.target/i386/attributes-error-sse.c: New test.
¹) as per attached
²) Unfortunately, the C FE does not readily provide a sensible locus
for the attributes in question but points input_location at that spot
of the beginning of the declaration of such a function. The C++ FE is
a little bit better in this regard:
[here i meant to verbatim emphasis discrepancy of the C++ and C FE
diagnostics for the abovementioned target tests, striking, isn't it, But
see yourselves.]
³) unreferenced, hence implied, where would on do this instead, more
helpful?
diff --git a/gcc/builtin-attrs.def b/gcc/builtin-attrs.def
index 71f4db1f3da..4813509b9c3 100644
--- a/gcc/builtin-attrs.def
+++ b/gcc/builtin-attrs.def
@@ -400,7 +400,7 @@ DEF_ATTR_TREE_LIST (ATTR_TM_NORETURN_NOTHROW_LIST,
DEF_ATTR_TREE_LIST (ATTR_TM_CONST_NOTHROW_LIST,
ATTR_TM_REGPARM, ATTR_NULL, ATTR_CONST_NOTHROW_LIST)
DEF_ATTR_TREE_LIST (ATTR_TM_NOTHROW_RT_LIST,
- ATTR_RETURNS_TWICE, ATTR_NULL, ATTR_TM_NOTHROW_LIST)
+ ATTR_RETURNS_TWICE, ATTR_NULL, ATTR_NOTHROW_LIST)
/* Same attributes used for BUILT_IN_MALLOC except with TM_PURE thrown in. */
DEF_ATTR_TREE_LIST (ATTR_TMPURE_MALLOC_NOTHROW_LIST,
diff --git a/gcc/config/i386/i386-options.cc b/gcc/config/i386/i386-options.cc
index 3605c2c53fb..daea2394e1a 100644
--- a/gcc/config/i386/i386-options.cc
+++ b/gcc/config/i386/i386-options.cc
@@ -3679,6 +3679,12 @@ ix86_handle_cconv_attribute (tree *node, tree name, tree args, int,
name, REGPARM_MAX);
*no_add_attrs = true;
}
+ else if (FUNC_OR_METHOD_TYPE_P (*node) && stdarg_p (*node))
+ {
+ warning (OPT_Wattributes, "%qE attribute ignored "
+ "on function with variable number of arguments", name);
+ *no_add_attrs = true;
+ }
return NULL_TREE;
}
@@ -3732,6 +3738,12 @@ ix86_handle_cconv_attribute (tree *node, tree name, tree args, int,
{
error ("stdcall and thiscall attributes are not compatible");
}
+ if (FUNC_OR_METHOD_TYPE_P (*node) && stdarg_p (*node))
+ {
+ warning (OPT_Wattributes, "%qE attribute ignored "
+ "on function with variable number of arguments", name);
+ *no_add_attrs = true;
+ }
}
/* Can combine cdecl with regparm and sseregparm. */
@@ -3768
Re: RFC: Formalization of the Intel assembly syntax (PR53929)
On Fri, 19 Jan 2024, LIU Hao wrote: > ? 2024-01-18 20:54, Jan Beulich ??: > > I'm sorry, but most of your proposal may even be considered for being > > acceptable only if you would gain buy-off from the MASM guys. Anything > > MASM treats as valid ought to be permitted by gas as well (within the > > scope of certain divergence that cannot be changed in gas without > > risking to break people's code). It could probably be considered to > > introduce a "strict" mode of Intel syntax, following some / most of > > what you propose; making this the default cannot be an option. > > Thanks for your reply. > > I have attached the Markdown source for that page, modified a few hours ago. I > am planning to make some updates according to your advice tomorrow. > > And yes, I am proposing a 'strict' mode, however not for humans, only for > compilers. > > My first message references a GCC bug report, where the problematic symbol > `bx` comes from C source. I have been aware of the `/APP` and `/NO_APP` It's #APP #NO_APP, not /APP /NO_APP, for x86_64-linux, even for -masm=intel. > markers in generated assembly, so I suspect that GAS should be able to tell > which parts are generated from a compiler and which parts are composed by > hand. Since a very long time, none but a very few gcc targets (not including i686/x64_64-linux) emit the initial #NO_APP, which have to be the very first characters of the generated assembly file, without which subsequent #APP/#NO_APP pairs are just for show. That said, I guess you're going to modify gas too. But please don't change the #APP/#NO_APP semantics for non-intel targets. brgds, H-P
