HI:
There is comment on lui_movf in mips.md like following,
;; because we don't split it. FIXME: we should split instead.
I can split it into a move and a condmove(movesi_on_cc) insns , like
(define_split
[(set (match_operand:CC 0 d_operand )
(match_operand:CC 1 fcc_reload_operand
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 integration
On Thu, Apr 29, 2010 at 7:28 PM, Massimo Nazaria ma...@rocketmail.com 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))
{
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
On Fri, Apr 30, 2010 at 07:36, Aina Niemetz aina.niem...@gmail.com 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
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 to
On Fri, Apr 30, 2010 at 1:42 PM, Massimo Nazaria ma...@rocketmail.com 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
On Fri, Apr 30, 2010 at 1:42 PM, Massimo Nazaria ma...@rocketmail.com 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
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_stmt;
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 mirror
On Fri, Apr 30, 2010 at 3:35 PM, Massimo Nazaria ma...@rocketmail.com 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
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); // My
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
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
joakim.tjernl...@transmode.se 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
On Fri, Apr 30, 2010 at 3:35 PM, Massimo Nazaria ma...@rocketmail.com 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
Jan-Benedict Glaw jbg...@lug-owl.de wrote on 2010/04/30 16:10:42:
On Fri, 2010-04-30 16:08:15 +0200, Joakim Tjernlund
joakim.tjernl...@transmode.se 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
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
joakim.tjernl...@transmode.se wrote:
Jan-Benedict Glaw jbg...@lug-owl.de wrote on 2010/04/30 16:10:42:
On Fri, 2010-04-30 16:08:15 +0200, Joakim Tjernlund
joakim.tjernl...@transmode.se wrote:
Is memcpy supposed to work when the src and
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 put
in
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 NULL.
On Fri, Apr 30, 2010 at 10:48, Michael Matz m...@suse.de 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
area
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
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
I'd
On Fri, Apr 30, 2010 at 5:05 PM, Joe Buck joe.b...@synopsys.com 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()
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-rtemseabi or
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
Jörg Leis jo...@joergleis.com 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
On Fri, Apr 30, 2010 at 1:37 AM, Jan Hubicka hubi...@ucw.cz 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
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
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
In
On Fri, Apr 30, 2010 at 11:12 AM, Jan Hubicka hubi...@ucw.cz 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
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 *)
On Fri, Apr 30, 2010 at 08:29:19AM -0700, Richard Guenther wrote:
On Fri, Apr 30, 2010 at 5:05 PM, Joe Buck joe.b...@synopsys.com 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
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
--- Comment #3 from david at rothlis dot net 2010-04-30 06:05 ---
a function with a missing return is valid
I just can't reconcile that with the following line from the C++ standard: It
is now invalid to return (explicitly or implicitly) from a function which is
declared to return a
--- Comment #2 from pzhao at gcc dot gnu dot org 2010-04-30 06:16 ---
Subject: Bug 43779
Author: pzhao
Date: Fri Apr 30 06:16:26 2010
New Revision: 158919
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158919
Log:
2010-04-30 Shujing Zhao pearly.z...@oracle.com
PR
--- Comment #7 from pault at gcc dot gnu dot org 2010-04-30 06:51 ---
Fixed on trunk.
Thanks for the help, Salvatore - I hope that it will continue.
Paul and Janus
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from patrick at motec dot com dot au 2010-04-30 06:57
---
Khem,
Your libgcc.a looks fine. As far as I know, libgcc.a is supposed to be the last
library listed when linking so the behaviour you are seeing is normal.
My problem is that libgcc.a does not contain
--- Comment #8 from jdemeyer at cage dot ugent dot be 2010-04-30 07:24
---
On first sight, it looks fixed in gcc 4.6.0 SVN.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37195
--- Comment #11 from rguenth at gcc dot gnu dot org 2010-04-30 08:23
---
Subject: Bug 43879
Author: rguenth
Date: Fri Apr 30 08:22:15 2010
New Revision: 158924
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158924
Log:
2010-04-30 Richard Guenther rguent...@suse.de
PR
--- Comment #2 from hubicka at ucw dot cz 2010-04-30 08:45 ---
Subject: Re: [4.6 Regression] FAIL:
gcc.dg/lto/20090126-1 c_lto_20090126-1_0.o-c_lto_20090126-1_0.o
Hi,
the problem here is that the testcase combine -O0 module into -O3 module. This
results in optimization
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.4.4 |4.4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43706
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.4.4 |4.4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39372
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.4.4 |4.4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22488
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.4.4 |4.4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38678
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.4.4 |4.4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41454
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.4.4 |4.4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41043
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.4.4 |4.4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36143
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.4.4 |4.4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43845
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.4.4 |4.4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37022
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.4.4 |4.4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37272
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.4.4 |4.4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36201
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.4.4 |4.4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37273
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.4.4 |4.4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37534
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.4.4 |4.4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38134
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.4.4 |4.4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38671
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.4.4 |4.4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38306
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.4.4 |4.4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39390
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.4.4 |4.4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38747
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.4.4 |4.4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39612
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.4.4 |4.4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39514
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.4.4 |4.4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39355
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.4.4 |4.4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40106
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.4.4 |4.4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38878
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.4.4 |4.4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41176
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.4.4 |4.4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39747
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.4.4 |4.4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41619
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.4.4 |4.4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42108
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.4.4 |4.4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42169
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.4.4 |4.4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42502
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.4.4 |4.4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42438
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.4.4 |4.4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42577
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.4.4 |4.4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42536
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.4.4 |4.4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42973
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.4.4 |4.4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43370
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.4.4 |4.4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42505
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.4.4 |4.4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42621
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.4.4 |4.4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43668
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.4.4 |4.4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43671
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.4.4 |4.4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43700
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.4.4 |4.4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33979
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.4.4 |4.4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38384
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.4.4 |4.4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34199
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.4.4 |4.4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39219
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.4.4 |4.4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40497
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.4.4 |4.4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39979
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.4.4 |4.4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41738
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.4.4 |4.4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41156
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.4.4 |4.4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42073
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.4.4 |4.4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41321
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.4.4 |4.4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42494
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.4.4 |4.4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42509
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.4.4 |4.4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42856
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.4.4 |4.4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43323
1 - 100 of 232 matches
Mail list logo
