On Sat, Oct 18, 2008 at 11:13 AM, Edward Peschko <[EMAIL PROTECTED]> wrote:
> All,
>
> I'm trying to compile a thread with the boost, threading libraries,
> and am getting errors like these.
>
>gcc -o conftest -g -O2
> -I/GAAL/pesced_release/install/fuego/include/boost-1_36
> -L/GAAL/pesced_rel
All,
I'm trying to compile a thread with the boost, threading libraries,
and am getting errors like these.
gcc -o conftest -g -O2
-I/GAAL/pesced_release/install/fuego/include/boost-1_36
-L/GAAL/pesced_release/install/fuego/lib /tmp/aa.c
-lboost_thread-gcc43-mt
/GAAL/pesced_release/install/fu
Andrew Pinski wrote:
> On Fri, Oct 17, 2008 at 2:15 PM, Diego Novillo <[EMAIL PROTECTED]> wrote:
>
>> On Fri, Oct 17, 2008 at 16:51, Richard Henderson <[EMAIL PROTECTED]> wrote:
>>
>>
>>> If the version of GCC being used isn't compatible with the version of the IL
>>> in the object file, we
Hello Everyone,
I am trying to add a specialized RTL into GCC. The main point of
this RTL is to add specialized instructions during scheduling (so there
is no specific regions such as every basic block or every function
beginning/end where I can predict ahead of time before scheduling to
insert
Snapshot gcc-4.4-20081017 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20081017/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.4 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk
On Fri, Oct 17, 2008 at 2:15 PM, Diego Novillo <[EMAIL PROTECTED]> wrote:
> On Fri, Oct 17, 2008 at 16:51, Richard Henderson <[EMAIL PROTECTED]> wrote:
>
>> If the version of GCC being used isn't compatible with the version of the IL
>> in the object file, we can just fall back on the final code.
>
On Fri, Oct 17, 2008 at 16:51, Richard Henderson <[EMAIL PROTECTED]> wrote:
> If the version of GCC being used isn't compatible with the version of the IL
> in the object file, we can just fall back on the final code.
Fair enough. But this could be provided via a flag to optionally emit
final co
Diego Novillo wrote:
We are currently emitting object files that contain both final code
and IL. I believe this is wasteful and does not really serve a useful
purpose. However, I think we started emitting hybrid object files for
some reason. Does anyone remember why?
If the version of GCC be
On Fri, Oct 17, 2008 at 1:27 PM, Nicholas Nethercote
<[EMAIL PROTECTED]> wrote:
> Early versions of AppleScript -- a "naturalistic" language with lots of
> keywords -- supported a french "dialect" and even Japanese. See page 20 of
> http://www.cs.utexas.edu/~wcook/Drafts/2006/ashopl.pdf
>
> AIUI,
On Mon, 6 Oct 2008, Kai Henningsen wrote:
You're not the first person to come up with this idea, and you
probably won't be the last, but it's a misbegotten idea, and there's
In fact, I believe it came up around the time when COBOL was invented.
And you'll notice that it didn't get implemente
On Oct 17, 2008, at 1:01 PM, Jeff Law wrote:
Reality is there aren't too many non-ELF targets that matter anymore
and, IMHO, it's reasonable to demand ELF support for LTO. The only
other format that has a reasonable chance of working would be the
COFF variants anyway and the only COFF varia
On Fri, Oct 17, 2008 at 16:01, Jeff Law <[EMAIL PROTECTED]> wrote:
> I'm not really involved in the LTO stuff at all, but my recommendation would
> be to severely de-emphasize any non-ELF targets -- to the point where I'd
> say LTO is only supported on ELF targets.
Yeah, I agree. We are certainl
Diego Novillo wrote:
On Fri, Oct 17, 2008 at 15:40, Ollie Wild <[EMAIL PROTECTED]> wrote:
On Fri, Oct 17, 2008 at 12:32 PM, Diego Novillo <[EMAIL PROTECTED]> wrote:
lto1 (even if -flto is not provided) and eventually we'll need to
support archives in the reader.
Will we? I thou
On Fri, Oct 17, 2008 at 15:40, Ollie Wild <[EMAIL PROTECTED]> wrote:
> On Fri, Oct 17, 2008 at 12:32 PM, Diego Novillo <[EMAIL PROTECTED]> wrote:
>>
>> lto1 (even if -flto is not provided) and eventually we'll need to
>> support archives in the reader.
>
> Will we? I thought one of the main justif
On Fri, Oct 17, 2008 at 12:32 PM, Diego Novillo <[EMAIL PROTECTED]> wrote:
>
> lto1 (even if -flto is not provided) and eventually we'll need to
> support archives in the reader.
Will we? I thought one of the main justifications for implementing a
plugin architecture in the linker was to avoid ha
On Fri, Oct 17, 2008 at 15:24, Ollie Wild <[EMAIL PROTECTED]> wrote:
> At the moment, this won't work if final code is omitted. Collect2 requires
> the presence of -flto or -fwhopr before lto1 will be invoked. I'm not sure
> what the new Gold plugin does.
>
> Also, this will be problematic for s
Jim Meyering <[EMAIL PROTECTED]> wrote:
> "Manuel López-Ibáñez" <[EMAIL PROTECTED]> wrote:
>> 2008/10/17 Bruno Haible <[EMAIL PROTECTED]>:
>>> "#pragma GCC diagnostic" has a few limitations, which make it unusable to
>>> resolve warnings like this one:
>>>
>>> Jim Meyering wrote in [1]:
$
"Manuel López-Ibáñez" <[EMAIL PROTECTED]> wrote:
> 2008/10/17 Bruno Haible <[EMAIL PROTECTED]>:
>> "#pragma GCC diagnostic" has a few limitations, which make it unusable to
>> resolve warnings like this one:
>>
>> Jim Meyering wrote in [1]:
>>> $ cat in.c
>>> int f (void) __attribute__ ((__
On Fri, Oct 17, 2008 at 15:09, Andrew Pinski <[EMAIL PROTECTED]> wrote:
> Yes, so you can just link the files without any LTO at all. That is
> you can have the object files act like real object files in the
> process of compiling.
You can do that with IL-only objects too, as long as you use gcc
We are starting to use the lto branch internally for testing and we
would like to have some degree of stability for the next few months.
Currently, the lto branch is tracking 4.4, but we will soon move to
stage 1, which will bring a whole lot of instability that we would
like to avoid. Ken, Jan,
On Fri, Oct 17, 2008 at 12:07 PM, Diego Novillo <[EMAIL PROTECTED]> wrote:
> We are currently emitting object files that contain both final code
> and IL. I believe this is wasteful and does not really serve a useful
> purpose. However, I think we started emitting hybrid object files for
> some r
We are currently emitting object files that contain both final code
and IL. I believe this is wasteful and does not really serve a useful
purpose. However, I think we started emitting hybrid object files for
some reason. Does anyone remember why?
Object files with just IL are not a problem for
On Fri, Oct 17, 2008 at 01:26:20PM -0400, Michael Meissner wrote:
> Why do you need new syntax? The current constraints file already supports
> target specific constraints. For example, from the i386:
>
> (define_register_constraint "x" "TARGET_SSE ? SSE_REGS : NO_REGS"
> "Any SSE register.")
>
On Fri, Oct 17, 2008 at 10:46:41AM -0700, Ian Lance Taylor wrote:
>
> I think you could achieve the same result by writing multiple
> define_insn patterns and using the instruction predicate.
Yes, I could. But that would quadruple my machine description,
which is already 169 KB, and it would mak
Joern Rennecke <[EMAIL PROTECTED]> writes:
> ARCompact has three-address instructions, but it has a number of
> shorter two-address instruction codes.
>
> When optimizing or speed, I think it would generally be best to
> choose the three-address alternatives for input reloads, since this
> allows
On Fri, Oct 17, 2008 at 05:51:03PM +0100, Joern Rennecke wrote:
> I want some constriants to be register constraints when compiling with
> a particular set of compiler flags, and extra constraints when compiling
> with another.
> (In the first case, alternatives that use this constraint can be sele
I want some constriants to be register constraints when compiling with
a particular set of compiler flags, and extra constraints when compiling
with another.
(In the first case, alternatives that use this constraint can be selected by
reload for reloading non-matching insns, whereas in the second
I am pleased to announce that the GCC Steering Committee has
appointed Sebastian Pop and Daniel Berlin as Graphite Reviewers.
Please join me in congratulating Sebastian and Danny on their new role.
Sebastian and Danny, please update your listings in the MAINTAINERS file.
Happy hac
I just merged mainline rev 141167 into lto. This fixes some
regression tests. I also needed to add support for the newly
added IMPORTED_DECL nodes.
Tested on x86_64 and x86.
Diego.
* lto-function-in.c (input_imported_decl): New.
(input_tree_operand): Handle IMPORTED_DECL.
ARCompact has three-address instructions, but it has a number of
shorter two-address instruction codes.
When optimizing or speed, I think it would generally be best to
choose the three-address alternatives for input reloads, since this
allows more reload inheritance. OTOH, when optimizing for siz
Hello,
I tried to enable modulo scheduling for our target VLIW. It fails even for the
simplest loop. I would like to have a look at how GCC produces schedule for
other targets. I know that modulo scheduling relies on doloop_end pattern to
identify a pipelineable loop. There are only a handful of
2008/10/17 Bruno Haible <[EMAIL PROTECTED]>:
> "#pragma GCC diagnostic" has a few limitations, which make it unusable to
> resolve warnings like this one:
>
> Jim Meyering wrote in [1]:
>> $ cat in.c
>> int f (void) __attribute__ ((__warn_unused_result__));
>> void g (void) { (void) f (
"#pragma GCC diagnostic" has a few limitations, which make it unusable to
resolve warnings like this one:
Jim Meyering wrote in [1]:
> $ cat in.c
> int f (void) __attribute__ ((__warn_unused_result__));
> void g (void) { (void) f (); }
> $ gcc -Werror -c in.c
> cc1: warnings be
Hello,
I ran into the following using gcc 4.2.3 on ubuntu 8.04. I ran it with
-Werror so it died on receiving this warning:
cc1: warnings being treated as errors
tux3fuse.c: In function 'tux3_lookup':
tux3fuse.c:78: warning: initialized field overwritten
tux3fuse.c:78: warning: (near initializati
Kai Tietz <[EMAIL PROTECTED]> writes:
> or: in vt_add_function_parameters, at var-tracking.c:3176
This is PR37815.
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44
Hi,
Till the last days I noticed that the bootstrap of the target
x86_64-pc-mingw32 is broken, while compiling libstdc++-v3. Is this a known
issue, or could somebody take a look for it?
The error message is:
In file included from
/vol/d/sources/gcc_new/gcc_1017/build3/x86_64-pc-mingw32/libstdc
On Fri, Oct 17, 2008 at 11:33 AM, Andrew Haley <[EMAIL PROTECTED]> wrote:
> hyeron bosh wrote:
>> I have a (probably naive) question about
>> messing up the stack pointer.
>>
>> Here is the code produced by gcc
>> for some function "X" (original source code is C/Obj-C)
>>
>> # function "X" entr
hyeron bosh wrote:
> I have a (probably naive) question about
> messing up the stack pointer.
>
> Here is the code produced by gcc
> for some function "X" (original source code is C/Obj-C)
>
> # function "X" entry point
> 0x82699 <>: push %ebp
> 0x8269a <+1>: mov%
I have a (probably naive) question about
messing up the stack pointer.
Here is the code produced by gcc
for some function "X" (original source code is C/Obj-C)
# function "X" entry point
0x82699 <>: push %ebp
0x8269a <+1>: mov%esp,%ebp
0x8269c <+3>: push %
39 matches
Mail list logo
