On 01/28/2016 03:11 AM, Florian Weimer wrote:
On 01/27/2016 04:17 PM, Richard Biener wrote:
We are trying to support
t.c
---
void *foo();
int bar()
{
return ((int (*)())foo) ();
}
t2.c
-
int foo () { return 0; }
thus doing a direct call to a function with a (wrong) prototype via a fu
On 01/27/2016 03:07 PM, Michael Karcher wrote:
Why can't ghc produce code like:
int bar ()
{
int (*foo1)() = foo;
asm("":"+r"(foo1));
return foo1();
}
Thank you for the first suggestion about what ghc can do to avoid the
problem without the need to change the internally used Cmm languag
On 29 January 2016 at 18:13, Magnus Fromreide wrote:
> I just noticed that the C and C++ compiler output pointer types differently:
>
> Consider
>
> int i;
> printf("%p", &i);
>
> When compiled as C that gives the warning
>
> format '%p' expects argument of type 'void *', but argument 2 has type 'i
On Fri, Jan 29, 2016 at 07:13:00PM +0100, Magnus Fromreide wrote:
> I just noticed that the C and C++ compiler output pointer types differently:
>
> Consider
>
> int i;
> printf("%p", &i);
>
> When compiled as C that gives the warning
>
> format '%p' expects argument of type 'void *', but argum
I just noticed that the C and C++ compiler output pointer types differently:
Consider
int i;
printf("%p", &i);
When compiled as C that gives the warning
format '%p' expects argument of type 'void *', but argument 2 has type 'int *'
but when compiled as C++ it gives the warning
format '%p' exp
On 28 January 2016 at 18:19, Bin.Cheng wrote:
> Hi,
> I ran into below error message at stage2 of bootstrap GCC:
>
> /work/obj/gcc-bootstrap/./prev-gcc/xg++
> -B/work/obj/gcc-bootstrap/./prev-gcc/ -B//aarch64-none-linux-gnu/bin/
> -nostdinc++
> -B/work/obj/gcc-bootstrap/prev-aarch64-none-linux-gn
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
I first discovered this by bootstrapping gcc and running the
testsuite. I got around 1200 new failures for the same gcc revision
using binutils-2.26 compared to using binutils-2.25.1, see
https://gcc.gnu.org/ml/gcc-testresults/2016-01/msg02756.html
a
On Thu, 28 Jan 2016, Jim Wilson wrote:
> On Thu, Jan 28, 2016 at 5:37 AM, Richard Biener wrote:
> >> To workaround this, I defined a new hook expand_divmod_libfunc, which
> >> targets must override for expanding call to target-specific dimovd.
> >> The "default" hook default_expand_divmod_libfunc
