>>> Look at the calls to cgraph_mark_edge in ipa-inline.c
>> There is no such function. I couldn't find anything in ipa-inline
>> that (1) had access to both ends of the call edge, (2) was actually
>> called, and (3) was called before the inlining happened.
>
> Sorry, I meant cgraph_mark_inline.
Guys - what branch/tag are you looking at doing this on?
I've been in discussions with Dorit about SPMD utilisation of graphics cards
(AMD CTM) which has more inline with parallel asymetric architectures than it
does with simple SIMD optimisations.
Cheers,
Nick.
> ---Original Message-
Jim Wilson <[EMAIL PROTECTED]> writes:
> Dave Korn wrote:
>> But it is ok to use a define_expand (that accepts all alternatives) for
>> movsf and use that to generate one of several movsf_ insns, isn't it?
>
> Reload doesn't use the move define_expands. It can't. A define_expand
> is allow
On 16 March 2007 15:30, Richard Sandiford wrote:
> Jim Wilson <[EMAIL PROTECTED]> writes:
>> Dave Korn wrote:
>>> But it is ok to use a define_expand (that accepts all alternatives) for
>>> movsf and use that to generate one of several movsf_ insns, isn't it?
>>
>> Reload doesn't use the mo
> Guys - what branch/tag are you looking at doing this on?
It's only a couple of lines of code, do we need a branch for that?
Or do you mean the COPmode changes, which are bigger? They still
might be managable enough for trunk, if the timing is right.
This is the beta release of binutils 2.17.50.0.13 for Linux, which is
based on binutils 2007 0315 in CVS on sourceware.org plus various
changes. It is purely for Linux.
All relevant patches in patches have been applied to the source tree.
You can take a look at patches/README to see what have been
On Tue, 13 Mar 2007, Mark Mitchell wrote:
> The GCC 4.2.0 RC1 build has failed (on x86_64-unknown-linux-gnu) with:
>
> Comparing stages 2 and 3
> Bootstrap comparison failure!
> ./java/parse.o differs
> ./java/parse-scan.o differs
This is caused by --enable-generated-files-in-srcdir, as used by
Again with attachment and CC to the Mailing List. Sorry for missing this.
Regards,
Markus
---
Hello,
thanks for your instructions. Indeed you were right. I mixed up some files.
Again an excerpt of the output-files:
---snip--- // expand
(insn 45 47 46 1 (set (subreg:SI (reg:DI 92 [ D.1212 ]) 4)
"Joseph S. Myers" <[EMAIL PROTECTED]> writes:
> This is caused by --enable-generated-files-in-srcdir, as used by the
> release script, hence not being seen by people configuring normally
> without that option. The first time Java is built (stage 2), the file
> java/parse.c is generated in the
Ian Lance Taylor wrote:
> "Joseph S. Myers" <[EMAIL PROTECTED]> writes:
>
>> This is caused by --enable-generated-files-in-srcdir, as used by the
>> release script, hence not being seen by people configuring normally
>> without that option.
Thanks for the analysis!
> Since we require GNU make,
Mark Mitchell <[EMAIL PROTECTED]> writes:
> Ian Lance Taylor wrote:
> > "Joseph S. Myers" <[EMAIL PROTECTED]> writes:
> >
> >> This is caused by --enable-generated-files-in-srcdir, as used by the
> >> release script, hence not being seen by people configuring normally
> >> without that option.
> This didn't apply with 4.1 because then, without toplevel bootstrap, all
> files to be copied to the source directory were generated and copied in
> stage 1, so stage 2 and stage 3 both built them from the source directory.
> Now, stage 1 is not only built as C only but the whole stage 1 bui
I have long been annoyed by the failure of the test builtin-apply4.c on
IA64 HP-UX and I know there are failures of tests using __builtin_apply
on other platforms as well.
My question is: Is it time to obsolete __builtin_apply,
__builtin_apply_args, and __builtin_return?
It looks like the main
On Fri, 16 Mar 2007, Mark Mitchell wrote:
> I was thinking about trying to fix this by doing something similar --
> but avoiding the copy.
You still need the srcextra rule around to do the copy, for use in
generating gcc.pot without --egfis - or the regeneration instructions
could change to req
Paolo Bonzini wrote:
> IIUC, the problem only manifests while *building* the release candidates,
> not for users of the release candidate.
>
> For 4.2, my suggestion is to just use a bootstrap4 while building the RC.
That's an attractive idea. But, I'd rather fix it correctly, because
distribut
On 3/16/07, Steve Ellcey <[EMAIL PROTECTED]> wrote:
My thinking is that if libobjc was changed then we could put in a
depreciated message on these builtins for 4.3 and maybe remove them for
4.4.
libobjc has not changed yet. There was a patch a while back to change
libobjc to use libffi but I n
On 3/16/07, Andrew Pinski <[EMAIL PROTECTED]> wrote:
On 3/16/07, Steve Ellcey <[EMAIL PROTECTED]> wrote:
> My thinking is that if libobjc was changed then we could put in a
> depreciated message on these builtins for 4.3 and maybe remove them for
> 4.4.
libobjc has not changed yet. There was a
Paolo Bonzini wrote:
For 4.3, we can use --enable-stage1-languages=all when building the RCs.
I can prepare a patch to do that automatically when
--enable-generated-files-in-srcdir
is passed.
That should not be needed on the trunk, as the .y files in question
(gcc/java/parse.y and gcc/java/
Snapshot gcc-4.3-20070316 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20070316/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.3 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk
On 3/16/07, Steven Bosscher <[EMAIL PROTECTED]> wrote:
Do you mean this patch:
http://gcc.gnu.org/ml/gcc-patches/2004-12/msg00841.html
Yes, thanks for finding the patch.
I will look over it this weekend and apply it if it is good.
-- Pinski
Hi ,
I am trying to build GCC without bootstrapping
The config options I used were
-- prefix= --disable-bootstrap --disable-libada --enable-languages=c
I then did a
make
After that, I edited some code in c-parser.c , then, as suggested in
http://gcc.gnu.org/ml/gcc/2007-02/msg00025.html , I t
"Karthikeyan M" <[EMAIL PROTECTED]> writes:
> I am trying to build GCC without bootstrapping
>
> The config options I used were
>
> -- prefix= --disable-bootstrap --disable-libada --enable-languages=c
>
> I then did a
>
> make
>
> After that, I edited some code in c-parser.c , then, as sugges
> > Sorry, I meant cgraph_mark_inline. It looks like what you want to
> > me. But maybe I'm misreading it.
>
> And cgraph_check_inline_limits
The magic place was cgraph_mark_inline_edges.
Turns out, when I changed disallow_* to allow_*, I forgot to reverse
the sense of the target's implementa
when you run configure.
If you do use --disable-bootstrap, just run "make all-gcc".
I tried this, it is still using the compiled-compiler in stage2 and beyond
I added some code to c-parser.c and this crashes the built-compiler
when it tries to compile itself. I want the build to stop after
s
On Mar 16, 2007, at 6:51 PM, Karthikeyan M wrote:
when you run configure.
If you do use --disable-bootstrap, just run "make all-gcc".
I tried this, it is still using the compiled-compiler in stage2 and
beyond
There is no stage 2 if you aren't bootstrapping. I'd recommend rm -
rf build a
Mark Mitchell wrote:
> Paolo Bonzini wrote:
>
>> IIUC, the problem only manifests while *building* the release candidates,
>> not for users of the release candidate.
>>
>> For 4.2, my suggestion is to just use a bootstrap4 while building the RC.
>
> That's an attractive idea. But, I'd rather fix
26 matches
Mail list logo
