[Bug c/71199] Support overloadable attribute in GNU C front-end

2016-09-15 Thread yuxuanchiadm at 126 dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71199

--- Comment #10 from Yu Xuanchi  ---
So there is currently i'm working on:
-Add "OVERLOAD" tree or just use chain. So we can put all function with same
identifier overloaded in a same tree so we can obtain them use
build_external_ref.
-Find a way to handle function invoke overload resolution.
-Find a way to handle function address-of overload resolution.

[Bug c/71199] Support overloadable attribute in GNU C front-end

2016-09-11 Thread yuxuanchiadm at 126 dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71199

--- Comment #8 from Yu Xuanchi  ---
I have test extern "C" in clang. Look like clang dose not actually mangled it
to "C format". I think because clang C front-end actually not have any mangle
logic. So it just mangled it like CPP front-end does.

[Bug c/71199] Support overloadable attribute in GNU C front-end

2016-09-11 Thread yuxuanchiadm at 126 dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71199

--- Comment #7 from Yu Xuanchi  ---
And there is another option. Because clang documentation say:
"However, when an overloadable function occurs within an extern "C" linkage
specification, it’s name will be mangled in the same way as it would in C."
So should we think nested function as implicit extern "C" and mangled it in C
way like "test.", "test.0001"?

[Bug c/71199] Support overloadable attribute in GNU C front-end

2016-09-11 Thread yuxuanchiadm at 126 dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71199

--- Comment #6 from Yu Xuanchi  ---
So I think in short term. We just reject those code. Because our aim is to
support this feature like clang. If there is no any problem. I'll go impl it.

[Bug c/71199] Support overloadable attribute in GNU C front-end

2016-09-11 Thread yuxuanchiadm at 126 dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71199

--- Comment #5 from Yu Xuanchi  ---
So there is a problem clang does not support nested function. Like:
-
void foo() {
  void foo1() {
// Bar
  }
}
-
And cpp also not supported. But gcc support it as an extensions. So how we deal
with code like this:
-
void __attribute__((overloadable)) test(long bar) {}
void foo1() {
  void __attribute__((overloadable)) test(int bar) {}
  void __attribute__((overloadable)) test(float bar) {}
}
void foo2() {
  void __attribute__((overloadable)) test(int bar) {}
  void __attribute__((overloadable)) test(float bar) {}
}
-
So extern scope "test" function should be mangled to "_Z4testl" right? But how
about others? Should we reject compile code like this? Or just allow it and
mangle it in some way? The origin gcc mangle nested function linke "test.".
the  is some number only gcc what it mean. So should we mangle name like
"Z4testi."? or "Z9test.i"?

[Bug c/71199] Support overloadable attribute in GNU C front-end

2016-06-07 Thread yuxuanchiadm at 126 dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71199

Yu Xuanchi  changed:

   What|Removed |Added

 CC||yuxuanchiadm at 126 dot com

--- Comment #4 from Yu Xuanchi  ---
Trying to implement it.

https://github.com/yuxuanchiadm/gcc/tree/gcc-overloadable-attribute