Take the following C code:
typedef long atype[];
typedef long atype1[];
int NumSift (atype *a, atype1 *a1)
{
(*a)[0] = 0;
(*a1)[0] = 1;
return (*a)[0];
}
Shouldn't the aliasing set for the type atype be the same as atype1?
In NumSift, shouldn't the store to (*a1)[0] interfere with (*a)[0] s
On Mon, 2006-03-20 at 18:55 -0500, Andrew Pinski wrote:
> On Mar 20, 2006, at 5:18 PM, Andrew MacLeod wrote:
>
> > I'm not sure when this happened, but I noticed on the weekend that
> > there
> > has been an explosion in the time spent during the alias analysis
> > phase.
> > using cplusplus-gra
> I don't see any progress on GCOV, so I assume it's up to me to fix
> these bugs. I'm writing here to cooperate with GCOV developers to
> avoid duplicate work.
There are two gcov maintainers listed in the GCC maintainers file:
gcovJan Hubicka [EMAIL PROTECTED]
gco
On Sat, 2006-03-18 at 10:24 +0100, Laurent GUERBY wrote:
> On Fri, 2006-03-17 at 12:51 -0700, Jeffrey A Law wrote:
> > I'm not suggesting the FEs deduce more types and track ranges;
> > that would be rather absurd. What I'm saying is that exposing
> > these types outside the FE is most likely cost
Tom Tromey wrote:
> I am leaning toward putting it into the rhug repository on
> sourceware.org, simply because then we (the gcj hackers) won't have to
> go through some long project registration process. Speak up if you
> have a particular problem with this.
Thanks!
I would prefer it go on sav
> "Mark" == Mark Mitchell <[EMAIL PROTECTED]> writes:
Mark> The FSF and GCC SC have decided to move fastjar to savannah, and
Mark> stop including it in future GCC releases, which will clarify
Mark> this situation. Will someone please volunteer to migrate
Mark> fastjar out of our repository?
On Mar 20, 2006, at 5:18 PM, Andrew MacLeod wrote:
I'm not sure when this happened, but I noticed on the weekend that
there
has been an explosion in the time spent during the alias analysis
phase.
using cplusplus-grammer.ii, it use to compile on my machine in about 55
seconds, and its now up
I'm not sure when this happened, but I noticed on the weekend that there
has been an explosion in the time spent during the alias analysis phase.
using cplusplus-grammer.ii, it use to compile on my machine in about 55
seconds, and its now up to about 150 seconds.
A quick gprof indicated about 60%
Hello again Daniel and all!
I'm still working on building the iWMMXt/EABI/NPTL toolchain. I've got to the
stage where I have everything built upto the final linking of glibc. Sadly
despite making a lot of progress and fixing many problems I am now stuck.
As I previously discovered the current g
> Did the compiler give you a warning about inability to track the
> lifetime of "p"? It should have.
No. Not even with -Wall -O2.
gcc -v:
gcc (GCC) 4.0.2 20050808 (prerelease) (Ubuntu 4.0.1-4ubuntu9)
> - FChE
>
Thanks,
Rafael
rafael.espindola wrote:
> [...]
> extern char *p;
> [...]
>char a = p[0];
> [...]
> compile and link with
> gcc -shared -fPIC a.c -o liba.so
> gcc -fmudflap -lmudflap b.c -la -L. -o b
Did the compiler give you a warning about inability to track the
lifetime of "p"? It should have.
- F
"Ling-hua Tseng" <[EMAIL PROTECTED]> writes:
> Because I need to use the feature of `length' attribute (i.e., use
> get_attr_length() in machine description),
> I have to insert NOPs explicitly before performing the pass 58
> (shorten) such that the shorten pass can calculate the length of insns
Paolo Bonzini <[EMAIL PROTECTED]> writes:
> >> The lower-subreg patch that Richard Henderson posted, and that
> >> comes up again and again from time to time, may also help. It does
> >> require a bit of hacking in the MDs (mostly removing the DImode
> >> patterns for logical operations since the
Using libmudflap to test a program that uses libxml2, I found that if
a program access a constant pointer in a non-instrumented library,
mudflap thinks that a read violation has occurred.
A simple test that illustrates this is:
a.c:
-
char *p = "abc";
-
The lower-subreg patch that Richard Henderson posted, and that comes
up again and again from time to time, may also help. It does require
a bit of hacking in the MDs (mostly removing the DImode patterns for
logical operations since the middle-end is able to synthesize them on
its own).
Tha
On 20 March 2006 15:31, Richard Henderson wrote:
> On Mon, Mar 20, 2006 at 12:57:14PM -, Dave Korn wrote:
>> Taking a look at leaf_function_p, I see that it specifically discounts
>> sibcalls; why not noreturncalls as well?
>
> Because generally losing unwind information from noreturn calls
>
On 20 March 2006 15:14, Richard Henderson wrote:
> On Mon, Mar 20, 2006 at 02:56:00PM -, Dave Korn wrote:
>> If the stack frame size is >32kB, I need to use a temporary register in
>> the epilogue to assemble the lo/hi parts of the frame size before adding
>> it to the SP. In the non-sibcal
Paolo Bonzini wrote:
Michael Matz wrote:
Hi Vladimir,
On Sat, 18 Mar 2006, Vladimir N. Makarov wrote:
What I am going to do in short perspective is
o work on code quality of some SPECINT tests (e.g. reload is doing
better job for crafty with many multi-registers than YARA)
The lower
Michael Matz wrote:
Hi Vladimir,
On Sat, 18 Mar 2006, Vladimir N. Makarov wrote:
What I am going to do in short perspective is
o work on code quality of some SPECINT tests (e.g. reload is doing
better job for crafty with many multi-registers than YARA)
I haven't looked at the new
On Mon, Mar 20, 2006 at 12:57:14PM -, Dave Korn wrote:
> Taking a look at leaf_function_p, I see that it specifically discounts
> sibcalls; why not noreturncalls as well?
Because generally losing unwind information from noreturn calls
is a lose when it comes to debugging.
r~
On Mon, Mar 20, 2006 at 02:56:00PM -, Dave Korn wrote:
> If the stack frame size is >32kB, I need to use a temporary register in the
> epilogue to assemble the lo/hi parts of the frame size before adding it to the
> SP. In the non-sibcall version of the epilogue[*] it uses one of the
> arg-p
On 20 March 2006 14:45, Richard Henderson wrote:
Hi Richard :)
> On Sat, Mar 11, 2006 at 12:41:32AM -, Dave Korn wrote:
>> So, what if the decision it needs to make depends on the stack frame
>> size of the current function?
>
> How can this possibly be? When the sibcall is done, the cu
On Sat, Mar 11, 2006 at 12:41:32AM -, Dave Korn wrote:
> So, what if the decision it needs to make depends on the stack frame
> size of the current function?
How can this possibly be? When the sibcall is done, the current
function's stack frame is removed.
r~
On Sun, 19 Mar 2006, Laurent GUERBY wrote:
> Are statistics for GCC download available somewhere? I suspect
> in these days of broadband that just about everyone gets the full
> tarball (especially for releases...).
The FreeSD ports, for example, by default do not build gfortran nor
Java at this p
Good morning everyone!
Here's a simple testcase that illustrates what I'm observing in gcc-3.3.3
--
extern void abort (void) __attribute ((noreturn));
int foo (int a, int b)
{
if (a > 25)
abort ();
return (a + b);
}
int bar
Michael Matz wrote:
Hi Vladimir,
On Sat, 18 Mar 2006, Vladimir N. Makarov wrote:
What I am going to do in short perspective is
o work on code quality of some SPECINT tests (e.g. reload is doing
better job for crafty with many multi-registers than YARA)
The lower-subreg patch that Richard
Hi Vladimir,
On Sat, 18 Mar 2006, Vladimir N. Makarov wrote:
> What I am going to do in short perspective is
> o work on code quality of some SPECINT tests (e.g. reload is doing
>better job for crafty with many multi-registers than YARA)
I haven't looked at the new branch yet, so forgive me
Hi,
I want to get the profiling data of an application in linux. Now I am
using -pg options of gcc for generating the profile data. then used
gprof for generating profiles. Here I am getting only in terms of
seconds. But I want in millisecond resolution. can anybody help me.
Thanks & regards
Ja
28 matches
Mail list logo
