[Bug c++/2316] g++ fails to overload on language linkage

[Bug c++/2316] g++ fails to overload on language linkage

[marc.glisse at normalesup dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316

--- Comment #20 from Marc Glisse <marc.glisse at normalesup dot org> 2011-08-30 00:20:07 UTC ---
Created attachment 25134
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25134
remember linkage of a function type

This is an extremely basic patch, that probably misses many things (and we'd
want to have conversions between extern"C" and regular functions not to break
too much code), but it can be useful to play with (it got at least 4 examples
right :-) although it ICEs (assert) on some other code...).

Obviously it has to be built with --disable-bootstrap since the gcc source code
is far from extern"C"-clean, but it can also be used to help clean it ;-) Oh,
and it won't build libstdc++ either, first because of functions in gthread that
take &pthread_cancel and then because of the __stoa helper in
ext/string_conversions.h (I didn't try to go further).

Function type trees apparently leave at least 2 trees unused in
tree_type_non_common so I reused one (minval), but since I only want one bit,
there are probably better ways to store it.

[Bug c++/2316] g++ fails to overload on language linkage

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316

--- Comment #21 from Jonathan Wakely <redi at gcc dot gnu.org> 2011-08-30 09:12:23 UTC ---
Thanks, Marc! We can (and eventually should) fix anything in libstdc++ that
incorrectly relies on this bug. Gthreads might be a little harder, but we could
probably overload on language linkage if necessary, so the existing interfaces
are preserved.
I'll try your patch and see what, if anything, can be changed safely in
libstdc++ right away.

[Bug c++/2316] g++ fails to overload on language linkage

[marc.glisse at normalesup dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316

--- Comment #22 from Marc Glisse <marc.glisse at normalesup dot org> 2011-08-30 09:32:24 UTC ---
(In reply to comment #21)
> I'll try your patch and see what, if anything, can be changed safely in
> libstdc++ right away.

Thanks :-)

Note that some things are painful to do right with extern "C". For instance,
the __stoa helper takes as argument a pointer to a function with a type that
depends on template arguments. As far as I can see, it is not possible to do
that for extern "C" functions (I posted a question about that on clc++m
yesterday), so that would mean rewriting this code differently. My guess is
that making extern "C" functions usable would require a few DR, or extern "C"
being part of the type will follow the example of "export" and be
deprecated/removed (the second option is more likely, even if that's yet
another change that hurts Oracle's compiler).

[Bug c++/2316] g++ fails to overload on language linkage

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316

--- Comment #23 from Jonathan Wakely <redi at gcc dot gnu.org> 2011-08-30 10:46:51 UTC ---
(In reply to comment #22)
> Note that some things are painful to do right with extern "C". For instance,
> the __stoa helper takes as argument a pointer to a function with a type that
> depends on template arguments. As far as I can see, it is not possible to do
> that for extern "C" functions (I posted a question about that on clc++m
> yesterday), so that would mean rewriting this code differently.

I think you can do it with a alias-declaration in an extern "C" block:

extern "C" {
  template<typename T>
    using func_type = T (*)();
}

extern "C" void c() { }

template<typename T>
  void f( func_type<T> p ) { p(); }

int main()
{
  f(&c);
}

But yes, it's a bit of a hole in the type system that language linkage is part
of the type but can only be specified in some contexts and can't be deduced by
templates.  We could solve it with an alternative syntax for language linkage
using attributes:

  void f( [[extern(C)]] void (*p)() );

could be equivalent to:

  extern "C" {  typedef void (*func_type)();  }
  void f( func_type p );

so we could say:

  template<typename T, typename U>
    void g( [[extern(C)]] T (*p)(U));


Without alias-declarations, the tedious way to fix __stoa would be write an
extern "C++" forwarding function for each of the strtol, stroul, vsnprintf etc.
functions we need, and pass that forwarding function to the helper function
templates. That could be done with macros, and would still be simpler than
re-implementing the __stoa error-checking logic in each one.  Anyway, that is
probably straying off-topic for this PR.

> My guess is
> that making extern "C" functions usable would require a few DR, or extern "C"
> being part of the type will follow the example of "export" and be
> deprecated/removed (the second option is more likely, even if that's yet
> another change that hurts Oracle's compiler).

Clang++ and VC++ also "implement" this bug.  If it's fixed in G++ it would need
to be controlled by a switch, maybe with the current behaviour as the default
(but issuing a warning) for a couple of releases. As I said in c13, it could
break a lot of code, plenty of people don't even know that they shouldn't be
able to pass extern "C++" functions to C library APIs.

[Bug c++/2316] g++ fails to overload on language linkage

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316

--- Comment #24 from Jonathan Wakely <redi at gcc dot gnu.org> 2011-08-30 10:49:27 UTC ---
(In reply to comment #23)
> I think you can do it with a alias-declaration in an extern "C" block:

But that might have only worked when I tested it because Clang++ doesn't
overload on language linkage either, I'm not sure if it's actually valid.

[Bug c++/2316] g++ fails to overload on language linkage

[marc.glisse at normalesup dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316

--- Comment #25 from Marc Glisse <marc.glisse at normalesup dot org> 2011-08-30 11:28:48 UTC ---
(In reply to comment #23)
> I think you can do it with a alias-declaration in an extern "C" block:
> 
> extern "C" {
>   template<typename T>
>     using func_type = T (*)();
> }
> 
> extern "C" void c() { }
> 
> template<typename T>
>   void f( func_type<T> p ) { p(); }
> 
> int main()
> {
>   f(&c);
> }
> 
> But yes, it's a bit of a hole in the type system that language linkage is part
> of the type but can only be specified in some contexts and can't be deduced by
> templates.

Yes, I thought about the alias, but it doesn't deduce the type. I really don't
think your example works unless you call f<thetype>(&c) as aliases are not
supposed to be deduced.

> We could solve it with an alternative syntax for language linkage
> using attributes:
> 
>   void f( [[extern(C)]] void (*p)() );

Is that where attributes go? That must be inconvenient for functions returning
function pointers. Or does it have some kind of "scope"?

> could be equivalent to:
> 
>   extern "C" {  typedef void (*func_type)();  }
>   void f( func_type p );
> 
> so we could say:
> 
>   template<typename T, typename U>
>     void g( [[extern(C)]] T (*p)(U));

Yes, that would be nice.

My guess is that we are supposed to use extern "C" functions very rarely and
only in very specific contexts where it doesn't matter so much if you can't do
all the meta-programming stuff.

> Anyway, that is probably straying off-topic for this PR.

Finding reasons to ask for the removal of this feature from the next standard
is kind of relevant ;-)

> Clang++ and VC++ also "implement" this bug.  If it's fixed in G++ it would need
> to be controlled by a switch, maybe with the current behaviour as the default
> (but issuing a warning) for a couple of releases. As I said in c13, it could
> break a lot of code, plenty of people don't even know that they shouldn't be
> able to pass extern "C++" functions to C library APIs.

Oracle's compiler implements it as different types, which already breaks a bit
of code (but it also means that a number of large projects have been fixed for
it), but it still allows many kinds of conversions between them, so most code
only gives warnings.

[Bug c++/2316] g++ fails to overload on language linkage

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316

--- Comment #26 from Jonathan Wakely <redi at gcc dot gnu.org> 2011-08-30 12:17:47 UTC ---
(In reply to comment #25)
> (In reply to comment #23)
> 
> > We could solve it with an alternative syntax for language linkage
> > using attributes:
> > 
> >   void f( [[extern(C)]] void (*p)() );
> 
> Is that where attributes go? That must be inconvenient for functions returning
> function pointers. Or does it have some kind of "scope"?

I probably have the syntax wrong, I wanted that attribute to apply to the
parameter p, but for a function poiner maybe it should be:

void f( void (*p)() [[extern(C)]] );

And for a function pointer return type my attempt would be

void (* ugly(int)[[extern(C++)]] )() [[extern(C)]] ;

i.e. 

extern "C" {  typedef void (*c_func)() }

extern "C++" {  c_func ugly(int); }


Maybe.


> My guess is that we are supposed to use extern "C" functions very rarely and
> only in very specific contexts where it doesn't matter so much if you can't do
> all the meta-programming stuff.

I did suggest to the POSIX C++ WG that there should be extern "C++" overloads
of pthread_create, pthread_atfork etc. just as we have overloads of qsort and
bsearch taking pointers to extern "C++" functions, which would allow existing
code that relies on this bug to just work without changes.  I was going to
submit a proposal along those lines, but that WG seemed to fizzle out and I
never finished the paper.  I probably still have it on an old hard drive on a
shelf somewhere.

[Bug c++/2316] g++ fails to overload on language linkage

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316

--- Comment #27 from Jonathan Wakely <redi at gcc dot gnu.org> 2011-08-30 12:19:23 UTC ---
this is DR13 btw
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_closed.html#13
I don't know if that's been reconsidered now we have attributes

[Bug c++/2316] g++ fails to overload on language linkage

[marc.glisse at normalesup dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316

--- Comment #28 from Marc Glisse <marc.glisse at normalesup dot org> 2011-08-30 12:34:20 UTC ---
(In reply to comment #27)
> this is DR13 btw
> http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_closed.html#13
> I don't know if that's been reconsidered now we have attributes

Gah, I looked for it, and once again forgot to look outside of the "active"
list :-(

Yes, this is exactly this DR, thanks for digging it up.

[Bug c++/2316] g++ fails to overload on language linkage

[marc.glisse at normalesup dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316

Marc Glisse <marc.glisse at normalesup dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #25134|0                           |1
        is obsolete|                            |

--- Comment #29 from Marc Glisse <marc.glisse at normalesup dot org> 2011-08-30 18:57:16 UTC ---
Created attachment 25140
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25140
remember linkage of a function type (2)

New version that works with typedefs (I was forgetting extern "C" in the
canonical type...). The patch also includes a workaround for __stoa. There
seems to still be an issue with argument deduction.

For some reason, -fpermissive already allows all conversions :-)

[Bug c++/2316] g++ fails to overload on language linkage

[marc.glisse at normalesup dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316

--- Comment #30 from Marc Glisse <marc.glisse at normalesup dot org> 2011-08-30 20:32:57 UTC ---
(In reply to comment #29)
> New version that works with typedefs (I was forgetting extern "C" in the
> canonical type...). The patch also includes a workaround for __stoa. There
> seems to still be an issue with argument deduction.

Also need to fix strip_typedefs (I am not uploading a new patch right now):

--- gcc/cp/tree.c    (revision 178336)
+++ gcc/cp/tree.c    (working copy)
@@ -1151,8 +1151,8 @@
       }
     else
       {
-        result = build_function_type (type,
-                      arg_types);
+        result = build_function_type2 (type, arg_types,
+                TYPE_MINVAL (t) != 0);
         result = apply_memfn_quals (result, type_memfn_quals (t));
       }

[Bug c++/2316] g++ fails to overload on language linkage

[marc.glisse at normalesup dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316

--- Comment #31 from Marc Glisse <marc.glisse at normalesup dot org> 2011-08-31 13:40:28 UTC ---
(In reply to comment #25)
> (In reply to comment #23)
> > I think you can do it with a alias-declaration in an extern "C" block:
> > 
> > extern "C" {
> >   template<typename T>
> >     using func_type = T (*)();
> > }
> > 
> > extern "C" void c() { }
> > 
> > template<typename T>
> >   void f( func_type<T> p ) { p(); }
> > 
> > int main()
> > {
> >   f(&c);
> > }
> > 
> > But yes, it's a bit of a hole in the type system that language linkage is part
> > of the type but can only be specified in some contexts and can't be deduced by
> > templates.
> 
> Yes, I thought about the alias, but it doesn't deduce the type. I really don't
> think your example works unless you call f<thetype>(&c) as aliases are not
> supposed to be deduced.

Sorry for that comment, I was completely wrong because of a gross
misunderstanding of template aliases, your solution is great (as soon as gcc
has template aliases ;-).

http://groups.google.com/group/comp.lang.c++.moderated/browse_thread/thread/43df1e789d3b44fe

[Bug c++/2316] g++ fails to overload on language linkage

[marc.glisse at normalesup dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316

Marc Glisse <marc.glisse at normalesup dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #25140|0                           |1
        is obsolete|                            |

--- Comment #32 from Marc Glisse <marc.glisse at normalesup dot org> 2011-09-03 13:00:20 UTC ---
Created attachment 25181
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25181
remember linkage of a function type (3)

This version of the patch, with -fpermissive and without -Werror, bootstraps
gcc without requiring any patching. -fpermissive does most of the work of
allowing any conversion, I only had to add some code so "&operator new[]"
(overloaded) knew which conversion to pick.

Obviously the patch needs completing (I am certainly missing many things),
cleaning up, and additional work to allow conversions without -fpermissive, and
only those that differ only by extern "C" somewhere. In other words it still
needs to be (re)written ;-)

But I think it is very encouraging that it compiles gcc (including libstdc++)
without any patching (but lots of warnings), which means this bug might be
fixed without breaking too much user code (we can be more lax than sunpro,
which rejects gcc sources in 2 places). And I don't think it introduces too
much ambiguity (overloading on linkage still works on a few tests).

[Bug c++/2316] g++ fails to overload on language linkage

[marc.glisse at normalesup dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316

--- Comment #33 from Marc Glisse <marc.glisse at normalesup dot org> 2011-09-04 11:03:41 UTC ---
And if you don't like errors saying that X can't be converted to X, you'll need
something like the below. I don't think I'll go much further anytime soon (if
someone else wants a go, that'd be great...).

--- cp/error.c  (revision 178506)
+++ cp/error.c  (working copy)
@@ -805,6 +805,8 @@
          pp_cxx_cv_qualifier_seq (cxx_pp, class_of_this_parm (t));
        else
          pp_cxx_cv_qualifier_seq (cxx_pp, t);
+       if (TREE_CODE (t) == FUNCTION_TYPE && TYPE_MINVAL (t))
+         pp_string (cxx_pp, " extern \"C\"");
        dump_exception_spec (TYPE_RAISES_EXCEPTIONS (t), flags);
        dump_type_suffix (TREE_TYPE (t), flags);
        break;

[Bug c++/2316] g++ fails to overload on language linkage

[marc.glisse at normalesup dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316

--- Comment #34 from Marc Glisse <marc.glisse at normalesup dot org> 2011-09-15 16:53:33 UTC ---
I posted a related demangler patch on gcc-patches a couple weeks ago, let me
just link it from here so it doesn't get lost:
http://gcc.gnu.org/ml/gcc-patches/2011-09/msg00231.html

[Bug c++/2316] g++ fails to overload on language linkage

[marc.glisse at normalesup dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316

Marc Glisse <marc.glisse at normalesup dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #25181|0                           |1
        is obsolete|                            |

--- Comment #35 from Marc Glisse <marc.glisse at normalesup dot org> 2012-01-02 00:18:19 UTC ---
Created attachment 26214
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26214
remember linkage of a function type (4)

I updated the patch to work with alias templates. I also hacked the library
enough to complete a --disable-bootstrap --enable-languages=c,c++ build. It
works well enough to play with it and see how buggy every code out there is...
I didn't implement conversions, -fpermissive or C casts are good enough as long
as this is just a toy.

[Bug c++/2316] g++ fails to overload on language linkage

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316

--- Comment #36 from Jonathan Wakely <redi at gcc dot gnu.org> 2012-01-02 01:04:14 UTC ---
The library should overload qsort, then the libitm/clone.cc change wouldn't be
needed

[Bug c++/2316] g++ fails to overload on language linkage

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316

--- Comment #37 from Andrew Pinski <pinskia at gcc dot gnu.org> 2012-01-02 02:30:17 UTC ---
I think the change to tree.c should not be done as it is middle-end code.  That
should be in the C++ front-end specific code instead.  That is the middle-end
should not care about the difference between extern "C" function types and
extern "C++" ones.

[Bug c++/2316] g++ fails to overload on language linkage

[marc.glisse at normalesup dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316

--- Comment #38 from Marc Glisse <marc.glisse at normalesup dot org> 2012-01-02 10:39:35 UTC ---
Thanks for the comments.

(In reply to comment #36)
> The library should overload qsort, then the libitm/clone.cc change wouldn't be
> needed

Indeed, that was the meaning of my comment "provide the true qsort prototype
instead", I'll do that next time.


(In reply to comment #37)
> I think the change to tree.c should not be done as it is middle-end code.  That
> should be in the C++ front-end specific code instead.  That is the middle-end
> should not care about the difference between extern "C" function types and
> extern "C++" ones.

That makes sense. I am surprised to see that I only use the new function once
outside of the cp/ directory, and I don't even know whether that is really
necessary. On the other hand, there may be other places I missed that need to
preserve this information while building variants of the type. And keeping it
in tree.c avoids duplicating this code. Maybe it would make sense to keep it in
the middle-end, making the extra field an opaque "extra information" that the
middle-end needs to preserve if it ever builds type variants? Although if it
clones the function in some way, preserving the linkage may not make that much
sense. (I don't have any experience so I may talk nonsense ;-)

This information is supposed to be related to the calling convention (although
the g++ ABI uses the same in all cases), which I guess is relevant to pass down
to middle and back-end (then it isn't opaque anymore).

The functions like __builtin_memcpy declared in tree.c should probably have "C"
linkage. Which means it might be better if I switched to using a non-zero value
for "C++" linkage (or at least make build_function_type build a C linkage type
by default) so I don't interfere as much with the rest.

So many choices... Well, that's for the next holidays unless someone else wants
to work on it.

[Bug c++/2316] g++ fails to overload on language linkage

[marc.glisse at normalesup dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316

Marc Glisse <marc.glisse at normalesup dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #26214|0                           |1
        is obsolete|                            |

--- Comment #39 from Marc Glisse <marc.glisse at normalesup dot org> 2012-01-04 11:10:30 UTC ---
Created attachment 26237
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26237
remember linkage of a function type (5)

Updated patch, now bootstraps with configure --enable-languages=c,c++
--disable-werror (except for some __int128 error in libitm which I assume is
unrelated). The main difference is that I allow (with a warning) conversions
between function pointers that differ by extern "C", so things like calling
pthread_create with a C++ function compile. The library changes are still there
but most of them are unnecessary if we don't mind warnings.

I didn't try to do the cleanup suggested by Andrew, I was concentrating on the
functionality. And I believe the only big functionality missing is giving
builtins their right type (__builtin_memcpy is extern "C", operator new[] is
"C++", etc).

Then (before even thinking of cleaning up the patch and fixing the whole gcc
code base) will come the decision of whether we actually want to do this
change. It is necessary in order to conform to the standard, but it is more
convenient to keep ignoring linkage...

[Bug c++/2316] g++ fails to overload on language linkage

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316

--- Comment #40 from Jonathan Wakely <redi at gcc dot gnu.org> 2012-01-04 11:49:35 UTC ---
Great! If all existing code is accepted with a warning that provides backwards
compatibility, but also allows conforming code to correctly overload on
language linkage - that sounds ideal.

IMHO the warning should be controllable by something such as -Wlanguage-linkage
(since there will be lots of warnings in some codebases, so it needs to be
possible to use -Wall but disable these warnings) and the conversion should be
rejected with -pedantic-errors.

[Bug c++/2316] g++ fails to overload on language linkage

[bangerth at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316

Wolfgang Bangerth <bangerth at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bangerth at gmail dot com

--- Comment #41 from Wolfgang Bangerth <bangerth at gmail dot com> 2012-01-04 12:28:13 UTC ---
I would expect a lot of code to trigger this warning. It is quite common
to pass the address of a static member function to pthread_create but since
there is no way to make a static member function 'extern "C"', I can't see
how to do that without major contortions. I'm rather sure that this will
turn out to be an unpopular warning :-)

W.

[Bug c++/2316] g++ fails to overload on language linkage

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #42 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-01-04 12:45:15 UTC ---
Well, perhaps something like:
#ifdef __cplusplus
extern "C++" int __REDIRECT_NTH (pthread_create, (pthread_t *__restrict
__newthread, const pthread_attr_t *__restrict __attr,
void *(*__start_routine) (void *),
void *__restrict __arg) __nonnull ((1, 3)), pthread_create);
#endif
(for glibc) could do the trick (and similarly for qsort and other C functions
that take callbacks?), still I agree this would be terribly annoying for
everybody.
At least this shouldn't be considered for GCC 4.7 at this point.

[Bug c++/2316] g++ fails to overload on language linkage

[marc.glisse at normalesup dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316

--- Comment #43 from Marc Glisse <marc.glisse at normalesup dot org> 2012-01-04 12:51:55 UTC ---
(In reply to comment #40)
> Great! If all existing code is accepted with a warning that provides backwards
> compatibility, but also allows conforming code to correctly overload on
> language linkage - that sounds ideal.

Well, not all existing code, just the most common ones. For instance:
template<class>struct is_fun1{static const bool value=false;};
template<class F,class T>struct is_fun1<F(T)>{static const bool value=true;};
will answer false for an extern "C" function type, and I am not sure how I
could make it return true without breaking valid code too much (and you can
call template<class F,class T>void f(F(T)); with an extern "C" function, but it
has lower priority than template<class T> void f(T); or even void f(...);).

But most uses in common code seem to be fine (it is even more lenient than
sunCC, which fails to compile gcc because of extern "C"). Note that accepting
these broken codes does imply we do the wrong thing on some valid code but I am
hoping not too much. As a guiding principle, I tried to allow conversions only
when there would be an error otherwise.

> IMHO the warning should be controllable by something such as -Wlanguage-linkage
> (since there will be lots of warnings in some codebases, so it needs to be
> possible to use -Wall but disable these warnings) and the conversion should be
> rejected with -pedantic-errors.

Agreed, there's a lot of cleanup to do...


(In reply to comment #41)
> I would expect a lot of code to trigger this warning. It is quite common
> to pass the address of a static member function to pthread_create but since
> there is no way to make a static member function 'extern "C"', I can't see
> how to do that without major contortions. I'm rather sure that this will
> turn out to be an unpopular warning :-)

libstdc++ does something like that in one place. As Jonathan told earlier, it
would make sense to overload pthread_create so it can take a C++ function. The
easiest way not to have the warning is to use a cast (not that this is very
standard...).

As for the popularity... I am still not sure we actually want to do this at
all, this is a proof of concept to help make a decision.

[Bug c++/2316] g++ fails to overload on language linkage

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316

--- Comment #44 from Jonathan Wakely <redi at gcc dot gnu.org> 2012-01-04 13:00:27 UTC ---
(In reply to comment #42)
> still I agree this would be terribly annoying for
> everybody.

Not everybody, only those who don't also use another compiler that already
diagnoses it  ;)

I'd be happy if a warning was only enabled by -pedantic not -Wall, but I accept
I'm in a small minority who even know about this problem, and an even smaller
minority who want it fixed

[Bug c++/2316] g++ fails to overload on language linkage

[marc.glisse at normalesup dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316

--- Comment #45 from Marc Glisse <marc.glisse at normalesup dot org> 2012-01-04 13:06:10 UTC ---
(In reply to comment #42)
> Well, perhaps something like:
> #ifdef __cplusplus
> extern "C++" int __REDIRECT_NTH (pthread_create, (pthread_t *__restrict
> __newthread, const pthread_attr_t *__restrict __attr,
> void *(*__start_routine) (void *),
> void *__restrict __arg) __nonnull ((1, 3)), pthread_create);
> #endif
> (for glibc) could do the trick (and similarly for qsort and other C functions
> that take callbacks?)

For bsearch and qsort, the standard actually requires those (and solaris has
them, although we fixinclude them out currently). For posix functions, well,
the posix-c++-wg mailing-list hasn't seen a single email since March 2010...

> still I agree this would be terribly annoying for everybody.

Yes.

> At least this shouldn't be considered for GCC 4.7 at this point.

Oh, of course. Maybe not even 4.8. In the patch, I (partially) enabled alias
templates in system headers because there are some things in libstdc++ that may
not be possible to do without those, so it may be better to wait until
-std=c++11 becomes the default if we want to do that. Plus, that completely
breaks the ABI, so it should be synchronized with other ABI-breaking changes.

And we may even decide on an official WONTFIX.

[Bug c++/2316] g++ fails to overload on language linkage

[xiaoyuanbo at yeah dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316

xiaoyuanbo <xiaoyuanbo at yeah dot net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |xiaoyuanbo at yeah dot net

--- Comment #46 from xiaoyuanbo <xiaoyuanbo at yeah dot net> 2012-02-22 12:42:46 UTC ---
i sure you problem primary

[Bug c++/2316] g++ fails to overload on language linkage

[harald at gigawatt dot nl]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316

Harald van Dijk <harald at gigawatt dot nl> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |harald at gigawatt dot nl

--- Comment #48 from Harald van Dijk <harald at gigawatt dot nl> ---
(In reply to Marc Glisse from comment #39)
> Created attachment 26237 [details]
> remember linkage of a function type (5)

I've been experimenting with this (although updated to more recent GCC), and
one issue I see, functionality-wise, is what happens when an extern "C"
function declaration is followed by a function definition without extern "C"
being specified:

extern "C" {
typedef void (*fpt)();
void f();
}
fpt x = f;
void f() { }
fpt y = f;

The initialisation of x is correctly silently accepted, but the initialisation
of y warns about an invalid conversion.

As I understand the standard, if the first declaration specifies language
linkage, that language linkage is remembered, even if later declarations omit
it. The name f does keep C linkage (as seen by nm), but its type loses it.

Note: it is possible that I made a mistake when updating to newer GCC.

[Bug c++/2316] g++ fails to overload on language linkage

[glisse at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316

--- Comment #49 from Marc Glisse <glisse at gcc dot gnu.org> ---
(In reply to Harald van Dijk from comment #48)
> I've been experimenting with this (although updated to more recent GCC), and
> one issue I see, functionality-wise, is what happens when an extern "C"
> function declaration is followed by a function definition without extern "C"
> being specified:

The examples in [dcl.link] seem to agree with your interpretation. It is likely
that I missed several cases like this one. As you can see, I haven't worked on
this in more than 2 years, and I don't think I'll work on it again any time
soon, so feel free to take over (and don't hesitate to consider large pieces of
my patch as nonsense). Fixing this particular issue should not be too hard,
there must be a place in the compiler that merges a number of properties from
the early declaration into the definition, and we need to add extern "C" to
that list.

[Bug c++/2316] g++ fails to overload on language linkage

[amylaar at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316

--- Comment #50 from Jorn Wolfgang Rennecke <amylaar at gcc dot gnu.org> ---
(In reply to Marc Glisse from comment #49)
> large pieces of my patch as nonsense). Fixing this particular issue should
> not be too hard, there must be a place in the compiler that merges a number
> of properties from the early declaration into the definition, and we need to
> add extern "C" to that list.

It's not exactly a single place. For C, in c/c-decl.c, we got
duplicate_decls, which uses merge_decls.

For C++, in cp/decl.c, we got another function called duplicate_decls.

[Bug c++/2316] g++ fails to overload on language linkage

[harald at gigawatt dot nl]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316

--- Comment #51 from Harald van Dijk <harald at gigawatt dot nl> ---
(In reply to Marc Glisse from comment #49)
> Fixing this particular issue should
> not be too hard, there must be a place in the compiler that merges a number
> of properties from the early declaration into the definition, and we need to
> add extern "C" to that list.

That does indeed seem simple enough. duplicate_decls can change the type pretty
much the same way it can change the name's linkage (except it cannot simply
modify the old type; it does have to build a new one, but it can set the new
type in the existing declaration), and can do so at the same location. It seems
like the right place to do it, since the inheritance of the type's linkage
works pretty much the same way as the inheritance of the name's linkage.

Note that a consequence of this is that a function declaration that uses a
typedef may not be compatible with the typedef (I think):

extern "C" { void f(); }
typedef void t();
t f, *g = f; // valid redeclaration of f, invalid initialisation of g
extern "C" t f; // invalid redeclaration of f
extern "C++" t f; // invalid redeclaration of f

Linkage conflicts with built-in declarations of functions are also a bit of a
problem: implementing this as described makes GCC fail to compile, because of
conflicts with built-in functions. The implicit declarations of built-in
functions have types with C++ linkage. A simple example:

extern "C" { int (&myputs)(const char *) = __builtin_puts; }

test.cc:1:44: error: invalid initialization of reference of type ‘int (&)(const
char*) extern "C"’ from expression of type ‘int(const char*)’
 extern "C" { int (&myputs)(const char *) = __builtin_puts; }
                                            ^

So the same logic to change the a redeclaration's type would need to be applied
to built-in function declarations as well.

(I may well continue working on this, but if I do, I will only do so
occasionally and will likely not be able to send anything meaningful or useful
for a long time.)
>From gcc-bugs-return-445765-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat Mar 08 01:43:38 2014
Return-Path: <gcc-bugs-return-445765-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 2762 invoked by alias); 8 Mar 2014 01:43:38 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 2723 invoked by uid 48); 8 Mar 2014 01:43:32 -0000
From: "jeremygccb at baymoo dot org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libgcc/60464] New: [arm] ARM -mthumb version of libgcc contains ARM (non-thumb) code; not safe for thumb-only architectures
Date: Sat, 08 Mar 2014 01:43:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: libgcc
X-Bugzilla-Version: unknown
X-Bugzilla-Keywords:
X-Bugzilla-Severity: critical
X-Bugzilla-Who: jeremygccb at baymoo dot org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter
Message-ID: <bug-60464-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-03/txt/msg00634.txt.bz2
Content-length: 4601

http://gcc.gnu.org/bugzilla/show_bug.cgi?id`464

            Bug ID: 60464
           Summary: [arm] ARM -mthumb version of libgcc contains ARM
                    (non-thumb) code; not safe for thumb-only
                    architectures
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: critical
          Priority: P3
         Component: libgcc
          Assignee: unassigned at gcc dot gnu.org
          Reporter: jeremygccb at baymoo dot org

SUMMARY

Configuring and building gcc 4.8.2 for the target 'arm-none-eabi' results in a
thumb version of libgcc.a that is not entirely suitable for thumb-only
processors. This bug is also present in 4.8.1.

DETAILS

I have built GCC 4.8.2 using the following configuration:

----- config.log snippet -----
  $ /Users/build/Downloads/gcc-4.8.2/configure --target=arm-none-eabi
--enable-languages=c --disable-libssp --disable-libstcdxx

  ## --------- ##
  ## Platform. ##
  ## --------- ##

  hostname = not-relevant.local
  uname -m = x86_64
  uname -r = 12.4.0
  uname -s = Darwin
  uname -v = Darwin Kernel Version 12.4.0: Wed May  1 17:57:12 PDT 2013;
root:xnu-2050.24.15~1/RELEASE_X86_64
-----------

When using this compiler to compile code targeted for '-mcpu=cortex-m3 -mthumb'
I noticed that some of the routines in the resulting binary still seem to
expect the processor to support ARM (non-thumb) mode. On further inspection I
found that these routines came from '_clzsi2.o' and '_divsi3.o' from libgcc.a.
I double-checked that the correct version of libgcc.a was being used:

-----
$ /usr/local/bin/arm-none-eabi-gcc -mcpu=cortex-m3 -mthumb
-print-libgcc-file-name

/usr/local/lib/gcc/arm-none-eabi/4.8.2/thumb/libgcc.a
-----

TO REPRODUCE

1. Configure: --target=arm-none-eabi --enable-languages=c --disable-libssp
--disable-libstcdxx

2. Compile a short test program:

  $ arm-none-eabi-gcc -mcpu=cortex-m3 -mthumb -S test.c

  ----- test.c
  unsigned int
  test1(unsigned long long a)
  {
          return a % 100000;
  }
  -----

3. Notice that the resultant 'test.s' generates a call to __aeabi_uldivmod:

  -----
          .global test1
          .thumb
          .thumb_func
          .type   test1, %function
  test1:
  ...
  movw    r2, #34464
  movt    r2, 1
  mov     r3, #0
  bl      __aeabi_uldivmod
  mov     r3, r2
  mov     r0, r3
  -----

4. Notice that __aeabi_uldivmod in
/usr/local/lib/gcc/arm-none-eabi/4.8.2/thumb/libgcc.a is a non-thumb function.

  $ arm-none-eabi-objdump -d
/usr/local/lib/gcc/arm-none-eabi/4.8.2/thumb/libgcc.a

  -----
  _aeabi_uldivmod.o:     file format elf32-littlearm


  Disassembly of section .text:

  00000000 <__aeabi_uldivmod>:
     0:   e3530000        cmp     r3, #0
     4:   03520000        cmpeq   r2, #0
     8:   1a000004        bne     20 <__aeabi_uldivmod+0x20>
     c:   e3510000        cmp     r1, #0
    10:   03500000        cmpeq   r0, #0
    14:   13e01000        mvnne   r1, #0
    18:   13e00000        mvnne   r0, #0
    1c:   eafffffe        b       0 <__aeabi_ldiv0>
    20:   e24dd008        sub     sp, sp, #8
    24:   e92d6000        push    {sp, lr}
    28:   ebfffffe        bl      0 <__gnu_uldivmod_helper>
    2c:   e59de004        ldr     lr, [sp, #4]
    30:   e28dd008        add     sp, sp, #8
    34:   e8bd000c        pop     {r2, r3}
    38:   e12fff1e        bx      lr
    -----

5. Notice that this occurred even though the build process for
thumb/libgcc.a(_aeabi_uldivmod.o) correctly asserted its intent by passing the
'-mthumb' to the compiler driver by inspecting the GCC build log:

  -----
  /Users/build/builds/gcc-4.8.2-arm-none-eabi/./gcc/xgcc
-B/Users/build/builds/gcc-4.8.2-arm-none-eabi/./gcc/
-B/usr/local/arm-none-eabi/bin/ -B/usr/local/arm-none-eabi/lib/ -isystem
/usr/local/arm-none-eabi/include -isystem /usr/local/arm-none-eabi/sys-include
  -g -O2 -mthumb -O2  -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE  -W -Wall
-Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition  -isystem ./include   -fno-inline -g -DIN_LIBGCC2
-fbuilding-libgcc -fno-stack-protector -Dinhibit_libc  -fno-inline -I. -I.
-I../../.././gcc -I/Users/build/Downloads/gcc-4.8.2/libgcc
-I/Users/build/Downloads/gcc-4.8.2/libgcc/.
-I/Users/build/Downloads/gcc-4.8.2/libgcc/../gcc
-I/Users/build/Downloads/gcc-4.8.2/libgcc/../include  -DHAVE_CC_TLS  -o
_aeabi_uldivmod.o -MT _aeabi_uldivmod.o -MD -MP -MF _aeabi_uldivmod.dep
-DL_aeabi_uldivmod -xassembler-with-cpp -c
/Users/build/Downloads/gcc-4.8.2/libgcc/config/arm/lib1funcs.S -include
_aeabi_uldivmod.vis
  -----

[Bug c++/2316] g++ fails to overload on language linkage

[glisse at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316

--- Comment #52 from Marc Glisse <glisse at gcc dot gnu.org> ---
(In reply to Harald van Dijk from comment #51)
> Note that a consequence of this is that a function declaration that uses a
> typedef may not be compatible with the typedef (I think):
> 
> extern "C" { void f(); }
> typedef void t();
> t f, *g = f; // valid redeclaration of f, invalid initialisation of g

Fun!

> extern "C" t f; // invalid redeclaration of f

I am not 100% sure about that one.

> Linkage conflicts with built-in declarations of functions are also a bit of
> a problem:

Yes, as I said in comment #38 and comment #39, giving builtin functions the
right linkage is a big missing part of the patch.

> implementing this as described makes GCC fail to compile,

At least in the version of the patch that is attached to the PR, gcc tries to
accept almost anything except in some pedantic mode. The goal is to avoid
breaking every code on earth, or the patch has no chance of ever being
accepted.

> (I may well continue working on this, but if I do, I will only do so
> occasionally and will likely not be able to send anything meaningful or
> useful for a long time.)

Good luck!

[Bug c++/2316] g++ fails to overload on language linkage

[harald at gigawatt dot nl]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316

--- Comment #53 from Harald van Dijk <harald at gigawatt dot nl> ---
(In reply to Marc Glisse from comment #52)
> (In reply to Harald van Dijk from comment #51)
> > extern "C" { void f(); }
> > typedef void t();
> > t f, *g = f; // valid redeclaration of f, invalid initialisation of g
> 
> Fun!

What's fun is that in getting this working, I found not only had I accidentally
introduced a bug (already fixed -- the typedef got changed, instead of only the
function's type), but that exact same bug also affects in Sun C++.

> > extern "C" t f; // invalid redeclaration of f
> 
> I am not 100% sure about that one.

It redeclares f as void(), where the previous declaration gave it type void()
extern "C", and the special exception in [dcl.link] to inherit a previous
declaration's linkage (both of the name and of the type) doesn't apply when the
linkage is explicitly specified, right?

> > Linkage conflicts with built-in declarations of functions are also a bit of
> > a problem:
> 
> Yes, as I said in comment #38 and comment #39, giving builtin functions the
> right linkage is a big missing part of the patch.

I've got this part working, and found it much easier to reverse the logic: all
code using build_function_type gets a C function type. It required just a few
more changes of build_function_type to build_function_type2 in the C++
frontend.

> > implementing this as described makes GCC fail to compile,
> 
> At least in the version of the patch that is attached to the PR, gcc tries
> to accept almost anything except in some pedantic mode. The goal is to avoid
> breaking every code on earth, or the patch has no chance of ever being
> accepted.

I've given it a try on a large number of packages (including Firefox, Chromium,
Qt+KDE), and I'm down to five categories of hard errors, four of which IMO
should be warnings, but comments on that would be welcome.

1:

extern "C" typedef void (*fpt1)() __attribute__((noreturn));
void f1();
fpt1 fp1 = f1; // error: invalid conversion from ‘void (*)()’ to ‘fpt1 {aka
void (*)()__attribute__((noreturn)) extern "C"}’ [-fpermissive]

This should work, with a warning. The logic to allow an implicit conversion to
the corresponding function type with different linkage doesn't work when the
attributes differ.

2:

extern "C" typedef void (*fpt2)();
template <typename> void f2();
fpt2 fp2 = f2<int>; // error: no matches converting function ‘f2’ to type ‘fpt2
{aka void (*)() extern "C"}’

This should work, with a warning. This possibly has the same underlying cause
as what I reported as PR60531, namely that f2<int> is considered an overloaded
function even though it isn't.

3:

extern "C" void f3();
template <void()> struct S3 { };
template struct S3<f3>;

This should work, with a warning. I was worried this might cause a conflict
between a C function template argument and a C++ function template argument
with the same name, but that cannot ever happen, the only possible way that
they could get the same mangled name is if the code is already invalid for
other reasons.

4:

extern "C" void f4();
struct S4 {
  S4(void());
private:
  S4(const S4 &);
};
S4 s4(f4);

This should work, with a warning, but only after all standard means of
constructing S4 have failed. In particular, if another constructor is added
that can accept f4's type (say S4(...), or S4(bool)), the other constructor
needs to be picked.

5:

extern "C" void f5(void());
void f5(void());
void g5() { long p = (long)f5; }

This should be considered acceptable breakage. The function f5 in question is
actually atexit, which in current glibc is not an overloaded function, but
would become an overloaded function, as specified in the standard. Taking its
address without any context doesn't give enough information to determine which
overload's address should be taken (even though they both have the same
address).

P.S.: the patch here contains a comment questioning the validity of extern "C"
template aliases. I think that a _lot_ more is valid than is currently
accepted:

7.5p1:
All function types, function names with external linkage, and variable names
with external linkage have a language linkage.

14p4:
A template name has linkage (3.5). A non-member function template can have
internal linkage; any other template name shall have external linkage. [...] A
template, a template explicit specialization (14.7.3), and a class template
partial specialization shall not have C linkage.

A static template function has internal linkage, so doesn't have external
linkage, so doesn't have language linkage, so never has C linkage, even if it
appears in an extern "C" block. Template classes and template aliases aren't
function types, so also never have language linkage, so never have C linkage.

The restriction on class template partial specializations suggests that this
isn't what the standard intends (they never have C linkage, so why specify that
they cannot have C linkage?), but it's useful, and I don't see any other
interpretation based on the actual wording, so that is what I've implemented.
This avoids the need for some of the uses of template aliases in libstdc++. If
desired, the useful templates that were previously rejected could get a pedwarn
rather than a hard error.
>From gcc-bugs-return-449432-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Apr 21 19:41:27 2014
Return-Path: <gcc-bugs-return-449432-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 1270 invoked by alias); 21 Apr 2014 19:41:27 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 1239 invoked by uid 48); 21 Apr 2014 19:41:24 -0000
From: "jvdelisle at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libfortran/59513] [4.7/4.8/4.9] Fortran runtime error: Sequential READ or WRITE not allowed after EOF marker, possibly use REWIND or BACKSPACE
Date: Mon, 21 Apr 2014 19:41:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: libfortran
X-Bugzilla-Version: 4.7.2
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jvdelisle at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P5
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.7.4
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-59513-4-s2VfHhu00s@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-59513-4@http.gcc.gnu.org/bugzilla/>
References: <bug-59513-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-04/txt/msg01452.txt.bz2
Content-length: 181

http://gcc.gnu.org/bugzilla/show_bug.cgi?idY513

--- Comment #12 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
Dominique, any progress on this one? Shall I look into it?

[Bug c++/2316] g++ fails to overload on language linkage

[eric-bugs at omnifarious dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316

--- Comment #55 from eric-bugs at omnifarious dot org ---
C++ may get an ABI change one of these days. It needs one in order to have a
properly efficient unique_ptr. Since that ABI change would involve who calls
destructors and C doesn't have destructors, I'm not sure if it would be a huge
deal for C/C++ ABI compatibility. But, still...

[Bug c++/2316] g++ fails to overload on language linkage

[pinskia at gcc dot gnu dot org]

------- Comment #9 from pinskia at gcc dot gnu dot org  2006-07-07 20:52 -------
*** Bug 28308 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hhinnant at apple dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316

[Bug c++/2316] g++ fails to overload on language linkage

[pinskia at gcc dot gnu dot org]

------- Comment #10 from pinskia at gcc dot gnu dot org  2006-09-12 16:55 -------
*** Bug 29038 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |amylaar at gcc dot gnu dot
                   |                            |org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316

[Bug c++/2316] g++ fails to overload on language linkage

[pinskia at gcc dot gnu dot org]

------- Comment #11 from pinskia at gcc dot gnu dot org  2006-10-10 16:33 -------
*** Bug 29411 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bkoz at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316

[Bug c++/2316] g++ fails to overload on language linkage

[bkoz at gcc dot gnu dot org]

------- Comment #12 from bkoz at gcc dot gnu dot org  2006-10-10 20:07 -------

adding ABI keyword as implementing this may change mangling for "C" functions.


-- 

bkoz at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |ABI


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316

[Bug c++/2316] g++ fails to overload on language linkage

[gcc-bugzilla at kayari dot org]

------- Comment #13 from gcc-bugzilla at kayari dot org  2006-10-15 03:24 -------
If this ever gets fixed (which I hope it does) then maybe it should depend on
-std=c++98 so this continues to work by default, or it will break a lot of code
that incorrectly passes extern "C++" functions to e.g. pthread_create and
sigaction.  That's a lot of code.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316

Re: [Bug c++/2316] g++ fails to overload on language linkage

[Andrew Pinski]

On Sun, 2006-10-15 at 03:24 +0000, gcc-bugzilla at kayari dot org wrote:
> 
> ------- Comment #13 from gcc-bugzilla at kayari dot org  2006-10-15 03:24 -------
> If this ever gets fixed (which I hope it does) then maybe it should depend on
> -std=c++98 so this continues to work by default, or it will break a lot of code
> that incorrectly passes extern "C++" functions to e.g. pthread_create and
> sigaction.  That's a lot of code.
The problem is -std=c++98 vs no options should not produce different
code which can happen as shown in this bug already, that we have wrong
code.

-- Pinski

[Bug c++/2316] g++ fails to overload on language linkage

[pinskia at gmail dot com]

------- Comment #14 from pinskia at gmail dot com  2006-10-15 03:29 -------
Subject: Re:  g++ fails to overload on language linkage

On Sun, 2006-10-15 at 03:24 +0000, gcc-bugzilla at kayari dot org wrote:
> 
> ------- Comment #13 from gcc-bugzilla at kayari dot org  2006-10-15 03:24 -------
> If this ever gets fixed (which I hope it does) then maybe it should depend on
> -std=c++98 so this continues to work by default, or it will break a lot of code
> that incorrectly passes extern "C++" functions to e.g. pthread_create and
> sigaction.  That's a lot of code.
The problem is -std=c++98 vs no options should not produce different
code which can happen as shown in this bug already, that we have wrong
code.

-- Pinski


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316

[Bug c++/2316] g++ fails to overload on language linkage

[marc dot glisse at normalesup dot org]

------- Comment #15 from marc dot glisse at normalesup dot org  2006-12-04 15:54 -------
*** Bug 30062 has been marked as a duplicate of this bug. ***


-- 

marc dot glisse at normalesup dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |marc dot glisse at
                   |                            |normalesup dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316

[Bug c++/2316] g++ fails to overload on language linkage

[pinskia at gcc dot gnu dot org]

------- Comment #16 from pinskia at gcc dot gnu dot org  2009-06-04 14:36 -------
*** Bug 40336 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |schaub-johannes at web dot
                   |                            |de


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316

[Bug c++/2316] g++ fails to overload on language linkage

[paolo dot carlini at oracle dot com]

------- Comment #17 from paolo dot carlini at oracle dot com  2009-06-04 14:49 -------
Interestingly, the only current compiler I tried which actually accepts this
(SunStudio) warns:

"2316.C", line 8: Warning: function int(int(*)()) overloads extern "C"
int(extern "C" int(*)()) because of different language linkages.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316

[Bug c++/2316] g++ fails to overload on language linkage

[marc dot glisse at normalesup dot org]

------- Comment #18 from marc dot glisse at normalesup dot org  2009-06-05 04:22 -------
(In reply to comment #17)
I just checked, and the sunpro warning is overzealous. It is meant to catch
cases where the programmer writes a declaration with one linkage and later
provides a definition with some other linkage, which ends up as an overload and
not a definition of the first function (this is a valid use, but may not be
what the programmer intended). It is hard to warn about such wrong cases
without also catching perfectly normal uses...

http://forums.sun.com/thread.jspa?threadID=5390323


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316

[Bug c++/2316] g++ fails to overload on language linkage

[jason at gcc dot gnu dot org]

------- Comment #19 from jason at gcc dot gnu dot org  2009-11-12 04:54 -------
I was thinking that the ABI didn't distinguish between C and C++ function
types, but I was wrong; it does specify a different mangling for extern "C"
functions.  The problem is that currently G++ only tracks language linkage for
declarations, not types.


-- 

jason at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jason at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316

[Bug c++/2316] g++ fails to overload on language linkage

[rguenth at gcc dot gnu dot org]

------- Additional Comments From rguenth at gcc dot gnu dot org  2005-09-09 12:56 -------
EDG aggrees with gcc here.  Maybe not a bug.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316

[Bug c++/2316] g++ fails to overload on language linkage

[gdr at integrable-solutions dot net]

------- Additional Comments From gdr at integrable-solutions dot net  2005-09-09 14:27 -------
Subject: Re:  g++ fails to overload on language linkage

"rguenth at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org> writes:

| EDG aggrees with gcc here.  Maybe not a bug.

I don't know why I don't like that syllogism, especially when it is
applied to many PRs in row :-/

-- Gaby


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316

[Bug c++/2316] g++ fails to overload on language linkage

[sebor at roguewave dot com]

------- Additional Comments From sebor at roguewave dot com  2005-09-11 21:34 -------
In reply to comment #6:
The vanilla EDG eccp 3.5 compiles the test case w/o an error:

$ eccp -v t.cpp && ./a.out; echo $?
Edison Design Group C/C++ Front End, version 3.5 (Nov  9 2004 20:00:33)
Copyright 1988-2004 Edison Design Group, Inc.

0

Intel C++ 9.0 (based on eccp 3.4.1) does reject the code, but that's most likely
for compatibility with gcc. I wouldn't rely on its behavior to determine whether
gcc is or isn't correct. (Note that HP aCC 6.0 which is also based on EDG eccp
accepts the code as expected.)

In reply to comment #4:
I don't think DR 4 is related since it's about internal linkage.

The test case is well-formed according to 7.5.1, p1, "Two function types with
different language linkages are distinct types even if they are otherwise
identical."

I.e., the first foo() can only take the address of an extern "C" function as an
argument (and not extern "C++") while the second foo() only an extern "C++"
function (and not extern "C"). Thus, each foo() is a distinct overload.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316