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
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,
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 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
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
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
> >
> > 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
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
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
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
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
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, 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 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, 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 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.
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, 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
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,
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
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
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.
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
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
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
Is memcpy supposed to work when the src and dest are the same:
memcpy(p, p, 100);
Jocke
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
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]$
> 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 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
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
> 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 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 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 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
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 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
> 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
39 matches
Mail list logo
