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 destr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316
Jonathan Wakely changed:
What|Removed |Added
CC||dan.cermak@cgc-instruments.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316
--- Comment #53 from Harald van Dijk ---
(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 initialisa
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316
--- Comment #52 from Marc Glisse ---
(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();
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316
--- Comment #51 from Harald van Dijk ---
(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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316
--- Comment #50 from Jorn Wolfgang Rennecke ---
(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
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316
--- Comment #49 from Marc Glisse ---
(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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316
Harald van Dijk changed:
What|Removed |Added
CC||harald at gigawatt dot nl
--- Comment #4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316
Andrew Pinski changed:
What|Removed |Added
CC||jed at 59A2 dot org
--- Comment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316
xiaoyuanbo changed:
What|Removed |Added
CC||xiaoyuanbo at yeah dot net
--- Comment #46 fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316
--- Comment #45 from Marc Glisse 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316
--- Comment #44 from Jonathan Wakely 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 ;
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316
--- Comment #43 from Marc Glisse 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
> lan
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #42 f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316
Wolfgang Bangerth changed:
What|Removed |Added
CC||bangerth at gmail dot com
--- Comment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316
--- Comment #40 from Jonathan Wakely 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316
Marc Glisse changed:
What|Removed |Added
Attachment #26214|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316
--- Comment #38 from Marc Glisse 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316
--- Comment #37 from Andrew Pinski 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316
--- Comment #36 from Jonathan Wakely 2012-01-02
01:04:14 UTC ---
The library should overload qsort, then the libitm/clone.cc change wouldn't be
needed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316
Marc Glisse changed:
What|Removed |Added
Attachment #25181|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316
--- Comment #34 from Marc Glisse 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316
--- Comment #33 from Marc Glisse 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, tha
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316
Marc Glisse changed:
What|Removed |Added
Attachment #25140|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316
--- Comment #31 from Marc Glisse 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
> > using func_t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316
--- Comment #30 from Marc Glisse 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316
Marc Glisse changed:
What|Removed |Added
Attachment #25134|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316
--- Comment #28 from Marc Glisse 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 lo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316
--- Comment #27 from Jonathan Wakely 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316
--- Comment #26 from Jonathan Wakely 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)]]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316
--- Comment #25 from Marc Glisse 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
> using func_type = T (*)();
> }
>
> extern "C" voi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316
--- Comment #24 from Jonathan Wakely 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316
--- Comment #23 from Jonathan Wakely 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 tha
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316
--- Comment #22 from Marc Glisse 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 wit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316
--- Comment #21 from Jonathan Wakely 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 langu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316
--- Comment #20 from Marc Glisse 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
--- 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
--- 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 som
--- 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 diffe
--- 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
-
--- 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
---
--- 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 +, gcc-bugzilla at kayari dot org wrote:
>
> --- Comment #13 from gcc-bugzilla at kayari dot org 2006-10-15 03:24
> ---
>
On Sun, 2006-10-15 at 03:24 +, 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
--- 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. p
--- 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
--
--- 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
-
--- 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
-
--- 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
---
--- 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-2
--- 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" <[EMAIL PROTECTED]> writes:
| EDG aggrees with gcc here. Maybe not a bug.
I don't know why I don't like that
--- 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
51 matches
Mail list logo
