> In theory, LIPO should not generate better results than LTO+FDO. What
> makes LIPO attractive is that it allows distributed build from the
> beginning. Its integration with large distributed build system is also
> easy. Another point is that LIPO can be decoupled from FDO as well.
The integrati
On Thu, Apr 29, 2010 at 7:28 PM, Massimo Nazaria wrote:
> Hi everybody!
> I am working on a gcc-pass which processes every statement using this code:
>
> for (node = cgraph_nodes; node; node = node->next)
> {
> if (node->analyzed && cgraph_is_master_clone (node))
> {
> pus
Ian,
thanks a lot for your feedback.
I'm aware of the fact that this might be quite a challenge, I hope that my
efforts won't be futile, though.
Would it be a good time to get the copyright assignment stuff done now? Or is
this too early, yet?
Aina
On 04/28/2010 03:21 PM, Ian Lance Taylor wrote
On Fri, Apr 30, 2010 at 07:36, Aina Niemetz wrote:
> Would it be a good time to get the copyright assignment stuff done now? Or is
> this too early, yet?
It's never too early to get the copyright assignment going. To get
the process started, follow the instructions on this form:
git.savannah.gn
> You have to schedule your IPA pass at a point where the
> whole
> program is in SSA form, which is during the regular IPA
> passes
> at earlierst.
>
> Richard.
>
It does not work :(
I put my pass after all the ipa-passes and right before the optimization-passes.
My problem occurs when I try t
On Fri, Apr 30, 2010 at 1:42 PM, Massimo Nazaria wrote:
>> You have to schedule your IPA pass at a point where the
>> whole
>> program is in SSA form, which is during the regular IPA
>> passes
>> at earlierst.
>>
>> Richard.
>>
>
> It does not work :(
> I put my pass after all the ipa-passes and r
On Fri, Apr 30, 2010 at 1:42 PM, Massimo Nazaria wrote:
>> You have to schedule your IPA pass at a point where the
>> whole
>> program is in SSA form, which is during the regular IPA
>> passes
>> at earlierst.
>>
>> Richard.
>>
>
> It does not work :(
> I put my pass after all the ipa-passes and r
> You'll have to post your work so people can see. Now the
> best the
> experts here can do is guess what you're holding behind
> your back :-)
>
> Ciao!
> Steven
>
I completely agree with you. This is my pass:
static unsigned int
execute_mypass (void)
{
basic_block bb;
gimple stmt, def_stm
On Sat, 2 Jan 2010, Gerald Pfeifer wrote:
> That said, mirrors.laffeycomputer.com may indeed not be active
> anymore. Let me include mirrormas...@laffey.biz, the documented
> contact for that mirror.
>
> mirrormas...@laffey.biz, would you mind letting us know about the
> status of your GCC mirro
On Fri, Apr 30, 2010 at 3:35 PM, Massimo Nazaria wrote:
>> You'll have to post your work so people can see. Now the
>> best the
>> experts here can do is guess what you're holding behind
>> your back :-)
>>
>> Ciao!
>> Steven
>>
>
> I completely agree with you. This is my pass:
The place where yo
> The place where you insert the patch is as important as
> the
> implementation of your patch. What do your changes to
> passes.c look
> like?
Here is the "passes.c":
NEXT_PASS (pass_early_warn_uninitialized);
NEXT_PASS (pass_all_early_optimizations);
NEXT_PASS (pass_mypass); //
On 04/29/2010 06:06 PM, Joseph S. Myers wrote:
On Thu, 29 Apr 2010, Joel Sherrill wrote:
Hi,
I am looking at the arm-rtems test results for the
trunk and noticing that most failures appear to be
for neon tests.
[j...@rtbf64a gcc]$ grep ^FAIL gcc.log.sent | wc -l
2203
[j...@rtbf64a gcc]$
On 4/30/10 09:35 , Massimo Nazaria wrote:
> fprintf (dump_file, "gimple_code: %d\n",
> gimple_code (def_stmt)); // Here I get segmentation fault...
For default SSA names, the defining statement will be NULL. A default
SSA name will be created when a symbol is n
Is memcpy supposed to work when the src and dest are the same:
memcpy(p, p, 100);
Jocke
On Fri, 2010-04-30 16:08:15 +0200, Joakim Tjernlund
wrote:
> Is memcpy supposed to work when the src and dest are the same:
> memcpy(p, p, 100);
It may work, but you cannot rely on it. Use memmove() alternatively.
MfG, JBG
--
Jan-Benedict Glaw jbg...@lug-owl.de +49-172
On Fri, Apr 30, 2010 at 3:35 PM, Massimo Nazaria wrote:
>> You'll have to post your work so people can see. Now the
>> best the
>> experts here can do is guess what you're holding behind
>> your back :-)
>>
>> Ciao!
>> Steven
>>
>
> I completely agree with you. This is my pass:
>
> static unsigned
Jan-Benedict Glaw wrote on 2010/04/30 16:10:42:
>
> On Fri, 2010-04-30 16:08:15 +0200, Joakim Tjernlund
> wrote:
> > Is memcpy supposed to work when the src and dest are the same:
> > memcpy(p, p, 100);
>
> It may work, but you cannot rely on it. Use memmove() alternatively.
My view too, but gcc
Hi,
On Wed, Apr 28, 2010 at 11:54:45AM -0400, Brian Gough wrote:
> I am just following up on my earlier email to mpc-discuss to check if
> some signatures can be made available for the mpc tarballs. Currently
> it's not possible to install the latest gcc without the risk of using
> unsigned code.
On Fri, 2010-04-30 16:14:36 +0200, Joakim Tjernlund
wrote:
> Jan-Benedict Glaw wrote on 2010/04/30 16:10:42:
> > On Fri, 2010-04-30 16:08:15 +0200, Joakim Tjernlund
> > wrote:
> > > Is memcpy supposed to work when the src and dest are the same:
> > > memcpy(p, p, 100);
> >
> > It may work, but
Just a quick comment than Jan-Benedict's opinion is widely shared by the
specification and by the Linux glibc manpage:
DESCRIPTION
The memcpy() function copies n bytes from memory area src to
memory
area dest. The memory areas should not overlap. Use memmove(3)
if the
That would be a bug.
If h1 and h2 were marked __restrict__ then using memcpy to make the
assignment is valid, but without that marking h1 may be == h2 so memmove
is required.
paul
> -Original Message-
> From: Joakim Tjernlund [mailto:joakim.tjernl...@transmode.se]
> Sent: Friday,
On Fri, 30 Apr 2010, Joel Sherrill wrote:
> This is fairly typical.
>
> FAIL: gcc.target/arm/neon/vzips8.c (test for excess errors)
> Excess errors:
> vzips8.s:13: Error: selected processor does not support `fldd d17,[fp,#-40]'
[...]
>
> Would it be better for the arm_neon_ok check to actually p
Hi,
On Fri, 30 Apr 2010, Diego Novillo wrote:
> On 4/30/10 09:35 , Massimo Nazaria wrote:
>
> > fprintf (dump_file, "gimple_code: %d\n",
> > gimple_code (def_stmt)); // Here I get segmentation fault...
>
> For default SSA names, the defining statement will be
On Fri, Apr 30, 2010 at 10:48, Michael Matz wrote:
>> For default SSA names, the defining statement will be NULL.
>
> Nope, it will be non-NULL but gimple_nop_p().
Bah! yes, of course. Sorry about that.
Diego.
On Fri, Apr 30, 2010 at 07:30:33AM -0700, Mark Mielke wrote:
> Just a quick comment than Jan-Benedict's opinion is widely shared by the
> specification and by the Linux glibc manpage:
>
> DESCRIPTION
> The memcpy() function copies n bytes from memory area src to
> memory
> ar
On 04/30/2010 09:37 AM, Joseph S. Myers wrote:
On Fri, 30 Apr 2010, Joel Sherrill wrote:
This is fairly typical.
FAIL: gcc.target/arm/neon/vzips8.c (test for excess errors)
Excess errors:
vzips8.s:13: Error: selected processor does not support `fldd d17,[fp,#-40]'
[...]
Would i
On Fri, 30 Apr 2010, Joel Sherrill wrote:
> > For EABI, this is done
> > with .cpu, .arch and .fpu directives; for non-EABI you may need to write
> > specs to pass command-line options to the assembler. Creating an
> > arm-rtemseabi or similar target and obsoleting the old-ABI version is what
>
On Fri, Apr 30, 2010 at 5:05 PM, Joe Buck wrote:
> On Fri, Apr 30, 2010 at 07:30:33AM -0700, Mark Mielke wrote:
>> Just a quick comment than Jan-Benedict's opinion is widely shared by the
>> specification and by the Linux glibc manpage:
>>
>> DESCRIPTION
>> The memcpy() function copies
On Fri, 2010-04-30 at 15:26 +, Joseph S. Myers wrote:
> On Fri, 30 Apr 2010, Joel Sherrill wrote:
>
> > > For EABI, this is done
> > > with .cpu, .arch and .fpu directives; for non-EABI you may need to write
> > > specs to pass command-line options to the assembler. Creating an
> > > arm-r
Hi,
would it be possible for GCC to ignore the expression that is not
chosen by __builtin_choose_expr?
Furthermore, it seems like this built-in function inhibits GCC's
ability to inline functions. I get an undefined reference when I
compile without -O2; the function is defined in C99-mode as "inl
Jörg Leis writes:
> would it be possible for GCC to ignore the expression that is not
> chosen by __builtin_choose_expr?
>
> Furthermore, it seems like this built-in function inhibits GCC's
> ability to inline functions. I get an undefined reference when I
> compile without -O2; the function is d
On Fri, Apr 30, 2010 at 1:37 AM, Jan Hubicka wrote:
>> In theory, LIPO should not generate better results than LTO+FDO. What
>> makes LIPO attractive is that it allows distributed build from the
>> beginning. Its integration with large distributed build system is also
>> easy. Another point is th
> >
> > Interesting. My plan for profiling with LTO is to ultimately make it
> > linktime
> > transform. This will be more difficult with WHOPR (i.e. instrumenting need
> > function bodies that are not available at WPA time), but I believe it is
> > solvable: just assign uids to the edges and do
Status
==
GCC 4.4.4 release tarballs have been uploaded to gcc.gnu.org and most
of them already to ftp.gnu.org too (there have been issues with
most of the tarballs being rejected due to make dist checking,
the main tarballs have been moved there manually already, but some
auxiliary tarballs a
Thank you everyone!!!
I found out a solution...
I had to add a line to my pass (the 2nd if):
for (node = cgraph_nodes; node; node = node->next) {
if (node->analyzed && cgraph_is_master_clone (node)) {
if (!gimple_in_ssa_p (DECL_STRUCT_FUNCTION (node->decl))) return 0; // I
added this line
On Fri, Apr 30, 2010 at 11:12 AM, Jan Hubicka wrote:
>> >
>> > Interesting. My plan for profiling with LTO is to ultimately make it
>> > linktime
>> > transform. This will be more difficult with WHOPR (i.e. instrumenting need
>> > function bodies that are not available at WPA time), but I belie
Hi,
gcc (for a STRICT_ALIGNMENT target and with -Wcast-align) do not warn
about the increasing of alignment requirement on the pointer assignments
present on the following C code.
struct {
short var;
} __attribute__((packed)) str;
void fun(void)
{
short *ptr;
ptr = (short *) (&str.var)
On Fri, Apr 30, 2010 at 08:29:19AM -0700, Richard Guenther wrote:
> On Fri, Apr 30, 2010 at 5:05 PM, Joe Buck wrote:
> > On Fri, Apr 30, 2010 at 07:30:33AM -0700, Mark Mielke wrote:
> >> Just a quick comment than Jan-Benedict's opinion is widely shared by the
> >> specification and by the Linux gl
Hi, I compile .c files using both gcc.3.4.6 and gcc-4.3.2 chaining to Sun's
assembler "Sun Compiler Common 10 Patch 09/04/2007" in both cases:
gcc -O3 -D_SOLARIS -D_SPARC -Wall -Wa,-xarch=v8plus -fexceptions -c ...
I run on a "SunOS 5.10 Generic_137111-08 sun4v sparc SUNW,T5240" box with
16x1
39 matches
Mail list logo
