Re: [ping^2] [buildrobot] gcc/config/linux-android.c:40:7: error: ‘OPTION_BIONIC’ was not declared in this scope
On Mon, Sep 2, 2013 at 5:28 PM, Jan-Benedict Glaw wrote: > Hi! > > On Mon, 2013-08-26 12:51:53 +0200, Jan-Benedict Glaw > wrote: >> On Tue, 2013-08-20 11:24:31 +0400, Alexander Ivchenko >> wrote: >> > I certainly missed that OPTION_BIONIC is not defined for linux targets >> > that do not include config/linux.h in their tm.h. >> > >> > This patch fixed build for powerpc64le-linux and mn10300-linux. >> > linux_libc, LIBC_GLIBC, LIBC_BIONIC should be defined for all targets. >> [...] >> >> It would be nice if somebody would review this patch. The initial >> commit had fallout on a few targets: >> >> alpha-linux: >> http://toolchain.lug-owl.de/buildbot/showlog.php?id=9537&mode=view >> mn10300-linux: >> http://toolchain.lug-owl.de/buildbot/showlog.php?id=9657&mode=view >> sparc64-linux: >> http://toolchain.lug-owl.de/buildbot/showlog.php?id=9655&mode=view >> tic6x-uclinux: >> http://toolchain.lug-owl.de/buildbot/showlog.php?id=9647&mode=view >> powerpc64le-linux: >> http://toolchain.lug-owl.de/buildbot/showlog.php?id=9638&mode=view >> (all other PPC variants, too.) > > This is still broken. Today it's two weeks. Can we please have the > patch ACKed or revert the patch? I agree. This is ridiculous. Would some global reviewer please approve the fix? Thanks, David
[ping^2] [buildrobot] gcc/config/linux-android.c:40:7: error: ‘OPTION_BIONIC’ was not declared in this scope
Hi! On Mon, 2013-08-26 12:51:53 +0200, Jan-Benedict Glaw wrote: > On Tue, 2013-08-20 11:24:31 +0400, Alexander Ivchenko > wrote: > > I certainly missed that OPTION_BIONIC is not defined for linux targets > > that do not include config/linux.h in their tm.h. > > > > This patch fixed build for powerpc64le-linux and mn10300-linux. > > linux_libc, LIBC_GLIBC, LIBC_BIONIC should be defined for all targets. > [...] > > It would be nice if somebody would review this patch. The initial > commit had fallout on a few targets: > > alpha-linux: > http://toolchain.lug-owl.de/buildbot/showlog.php?id=9537&mode=view > mn10300-linux: > http://toolchain.lug-owl.de/buildbot/showlog.php?id=9657&mode=view > sparc64-linux: > http://toolchain.lug-owl.de/buildbot/showlog.php?id=9655&mode=view > tic6x-uclinux: > http://toolchain.lug-owl.de/buildbot/showlog.php?id=9647&mode=view > powerpc64le-linux: > http://toolchain.lug-owl.de/buildbot/showlog.php?id=9638&mode=view > (all other PPC variants, too.) This is still broken. Today it's two weeks. Can we please have the patch ACKed or revert the patch? MfG, JBG -- Jan-Benedict Glaw jbg...@lug-owl.de +49-172-7608481 Signature of:If it doesn't work, force it. the second : If it breaks, it needed replacing anyway. signature.asc Description: Digital signature
Re: Generating multiple binaries from a single source file
Thank you, I appreciate your response.
It seems an interesting alternative, but still I can't figure out how to do it.
I want to forge some statements in the middle of the code, in some
specific points, for instance. That is something I know how to do
already, during parsing time. The thing is, I want to do it two
different times, each one with some specific instructions, to get two
different binaries. All that without having to add code to the source
file.
I'll give you a simple example.
Input source code:
int foo (void) {
int x = 10;
return x;
}
Binary one:
int foo (void) {
int x = 10;
x = 20; // I added this statement to the tree during parsing time
return x;
}
Binary two:
int foo (void) {
int x = 10;
x = 30; // I added this statement to the tree during parsing time
return x;
}
So, are the Target Specific Optimizations the way to do it?
Regards,
---
Rodolfo Guilherme Wottrich
Universidade Estadual de Campinas - Unicamp
2013/9/1 David Edelsohn :
> On Sat, Aug 31, 2013 at 11:57 PM, Rodolfo Guilherme Wottrich
> wrote:
>> Hello everyone,
>>
>> I would like to be able to generate multiple binaries from a single
>> source file, each of which being slightly different from the other(s).
>> For example, in case there's an OpenMP parallel region in the code, I
>> want to generate two binaries: one of them being the normal one and
>> the other one ignoring the parallel region, just like if the -fopenmp
>> flag hadn't been used.
>> This isn't exactly a good example, because I could just write a script
>> to compile the source file twice, with and without the flag. But the
>> manipulation I want to do with the code is something else.
>>
>> How do you guys suggest me to do it? It occurs to me that I may simply
>> implement a new flag to perform a different behavior and compile the
>> code twice, but looking at the code, I found it somehow difficult to
>> do. Also, there may be some more clever way to do it.
>>
>> However, if you guys think that the flag thing is the best way to do
>> it, please let me know and help me, telling how to implement that new
>> flag (I can't figure out how to).
>
> This sounds a little like Target specific function optimizations.
>
> http://gcc.gnu.org/wiki/FunctionSpecificOpt
>
> - David
RE: Prototypes for builtin functions
> -Original Message- > From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of Paulo > Matos > Sent: 29 August 2013 11:44 > To: gcc@gcc.gnu.org > Subject: Prototypes for builtin functions > > Hi, > > I would like to hear how other architectures organize their builtin/intrinsic > headers. > > Until recently we had a header that would look like: > > /* Types */ > typedef char V8B __attribute__ ((vector_size (8))); > ... > > /* Prototypes */ > extern V8B __vec_put_v8b (V8B B, char C, unsigned char D); > ... Besides pinging this question for some sort of answer, isn't true that if a declaration is marked extern, then the tree location for the decl shouldn't be changed? -- Paulo Matos
