I found that the optimization must be on in order to see the frequency.
Timothy
On 6/24/05, Liu Haibin <[EMAIL PROTECTED]> wrote:
> Then I think I shouldn't use -fprofile-arcs. The reason why I used
> -fprofile-arcs is when I debugged a program without any flags, I saw
> the frequency was zero.
[EMAIL PROTECTED] wrote:
Current questions include whether this tool needs to be used on
platforms for which a bourne shell script is inappropriate and whether
this tool needs to be coded in C instead.
as you're somewhat deadline bound, write it in whatever language suits your
needs. bash w
> If no one is looking at this, may be it's better to just commit the
> workaround patch?
>
> Laurent
>
> Index: misc.c
> ===
> RCS file: /cvs/gcc/gcc/gcc/ada/misc.c,v
> retrieving revision 1.103
> diff -u -r1.103 misc.c
> --- misc.c
Michael Veksler wrote:
According to the (very) long discussion on VRP, signed char/short/int/etc
do not have modulo semantic, they have an undefined behavior on overflow.
However in defines numeric_limits::is_modulo = true.
signed types are undefined on overflow. [5/5] and [3.9.1/2,3]
1. Is
Nathan Sidwell <[EMAIL PROTECTED]> writes:
| Michael Veksler wrote:
| > According to the (very) long discussion on VRP, signed char/short/int/etc
| > do not have modulo semantic, they have an undefined behavior on overflow.
| > However in defines numeric_limits::is_modulo = true.
|
| signed type
I have a situation where a structure is not properly aligned and I want
to copy it to fix this.
I'm aware that -no-builtin-memcpy will suppress the expansion of
memcpy() (force library calls) for a whole module. Is it possible to
suppress the expansion for a single invocation?
--
James Lemke
On Mon, Jun 27, 2005 at 10:11:50AM -0400, James Lemke wrote:
> I have a situation where a structure is not properly aligned and I want
> to copy it to fix this.
>
> I'm aware that -no-builtin-memcpy will suppress the expansion of
> memcpy() (force library calls) for a whole module. Is it possible
Gabriel Dos Reis wrote:
But a compiler could define them to be modulo -- that is the whole
point. The paragraph does not say they don't "modulo".
of course it could do so, but then to be useful it should document it, and it
would be an extension.
| 18.2.1.2/57 claims is_modulo is true 'fo
| signed types are undefined on overflow. [5/5] and [3.9.1/2,3]
> But a compiler could define them to be modulo -- that is the whole
> point. The paragraph does not say they don't "modulo".
True, but you are going to have to deal with the run-time version of
(int)0x8000 / -1
which is u
> "Nathan" == Nathan Sidwell <[EMAIL PROTECTED]> writes:
>> And all useful programs we write rely on undefined behaviour of
>> one sort or the other, starting with GCC. In the case of
Nathan> They do? I thought they usually relied on implementation
Nathan> defined, documented extensions
We are a group of undergrads at Portland State University who accepted as our
senior capstone software engineering project a proposed tool for use with gcov
for summarizing gcov outputs for a given piece of source code tested on
multiple architecture/OS platforms. A summary of the initial propo
Nathan Sidwell <[EMAIL PROTECTED]> writes:
| Gabriel Dos Reis wrote:
|
| > But a compiler could define them to be modulo -- that is the whole
| > point. The paragraph does not say they don't "modulo".
|
| of course it could do so, but then to be useful it should document it,
| and it would be a
Morten Welinder <[EMAIL PROTECTED]> writes:
| | signed types are undefined on overflow. [5/5] and [3.9.1/2,3]
|
| > But a compiler could define them to be modulo -- that is the whole
| > point. The paragraph does not say they don't "modulo".
|
| True, but you are going to have to deal with the
Paul Koning <[EMAIL PROTECTED]> wrote on 27/06/2005 17:47:12:
> > "Nathan" == Nathan Sidwell <[EMAIL PROTECTED]> writes:
>
> >> And all useful programs we write rely on undefined behaviour of
> >> one sort or the other, starting with GCC. In the case of
>
> Nathan> They do? I thought
Jakub Jelinek <[EMAIL PROTECTED]> writes:
> On Mon, Jun 27, 2005 at 10:11:50AM -0400, James Lemke wrote:
>> I have a situation where a structure is not properly aligned and I want
>> to copy it to fix this.
>>
>> I'm aware that -no-builtin-memcpy will suppress the expansion of
>> memcpy() (force
> You can:
> #include
> ...
> extern __typeof(memcpy) my_memcpy __asm ("memcpy");
>
> and use my_memcpy instead of memcpy in the place where you want to force
> library call.
Thanks Jakub! That worked very well.
Jim.
> Or you can use memcpy builtin, just tell GCC it should forget everything
>
Hello All,
I have two questions. I am trying to implement some new register
allocator scheme and at this moment I am trying to spill some of the
pseudos. I am facing two questions:
- For globals how to find the offset of the pseudo from the beginning
variable section? For example for constants in
On Thu, Jun 23, 2005 at 11:41:04AM -0700, [EMAIL PROTECTED] wrote:
> We are a group of undergrads at Portland State University who accepted
> as our senior capstone software engineering project a proposed tool for
> use with gcov for summarizing gcov outputs for a given piece of source
> code te
> You should substitute `i686
> ' in the above command with the appropriate processor
> for your host.
> Thanks for the report, I'll work on fixing that.
have you had a chance to look into this?
Not yet, but it's again at the top of my Texinfo list due to
All,
LCOV looks like what we were planning. Let's steal it.
See you at 7:00.
Dickson
FYI, the change to rtl in -O2 vs. -O1 is that -O2 includes -fforce-
mem which forces memory operands to registers to make memory
references common sub-expressions. In this case, the constant double
float value is assigned to an xmm register which is used where it is
needed. So, I would say
On Mon, Jun 27, 2005 at 12:21:01PM -0700, Fariborz Jahanian wrote:
> FYI, the change to rtl in -O2 vs. -O1 is that -O2 includes -fforce-
> mem which forces memory operands to registers to make memory
> references common sub-expressions.
Hmm. I would suspect this is obsolete now. We'll have f
Sorry it took me so long to get to this.
> You're not showing where this comes from, so it's hard to say. However
> D.1480 is created by the gimplifier, not the Ada front end. There could
> easily be a typing problem in the tree there (e.g., that of the
> subtraction) but I can't
On Jun 27, 2005, at 12:56 PM, Richard Henderson wrote:
Hmm. I would suspect this is obsolete now. We'll have forced
everything into "registers" (or something equivalent that we
can work with) during tree optimization. Any CSEs that can be
made should have been made.
I will do sanity chec
[EMAIL PROTECTED] (Richard Kenner) writes:
> Sorry it took me so long to get to this.
>
> > You're not showing where this comes from, so it's hard to say. However
> > D.1480 is created by the gimplifier, not the Ada front end. There could
> > easily be a typing problem in the tree
gcc some errors appear when compiling gcc-3.4.4 and gcc-4.0.0 on i386 freebsd
-5.2.1.those errrors are caused by byacc's convention of arguments .how to
solve them?
%make
rm -f stamp-h1
/bin/sh ./config.status config.h
config.status: creating config.h
config.status: config.h is unchan
Hi
some errors appear when compiling gcc-3.4.4 and gcc-4.0.0 on i386 freebsd
-5.2.1.those errrors are caused by byacc's convention of arguments .how to
solve them?
best regard
%make
rm -f stamp-h1
/bin/sh ./config.status config.h
config.status: creating config.h
config.status: config
"wangxiuli" <[EMAIL PROTECTED]> writes:
> Hi some errors appear when compiling gcc-3.4.4 and gcc-4.0.0 on i386
> freebsd -5.2.1.those errrors are caused by byacc's convention of
> arguments .how to solve them?
You must use Bison; we do not support byacc.
zw
RTH has been suggesting to use build_int_cst (etype, 0) instead.
Indeed. I was trying to minimize the change, but such cleanups are always
useful. This was also missing a protection on INTEGER_TYPE_P. I just got
a good bootstrap of Ada on x86_64 with this and a patch from Diego to fix
the o
Michael Veksler wrote:
Most programmers "know" that arithmetic is modulo wordsize. And those few
who know the right answer (only unsigned arithmetic is modulo) will
from time to time slip up and omit the "unsigned" keyword in their
declarations.
I agree.
Although the standard clearly makes s
Mark Mitchell <[EMAIL PROTECTED]> writes:
| Michael Veksler wrote:
|
| >> Most programmers "know" that arithmetic is modulo wordsize. And those few
| >>who know the right answer (only unsigned arithmetic is modulo) will
| >>from time to time slip up and omit the "unsigned" keyword in their
| >>d
The first change in GCC which changed signed overflow/wrapping to be
undefined
was added back in 1992 in loop.c. The next change was in 1999 with the
addition of simplify-rtx.c. Why are we talking about this now, instead
of back
when they were added? (note both of these changes were before fw
Andrew Pinski wrote on 28/06/2005 07:08:33:
> The first change in GCC which changed signed overflow/wrapping to be
> undefined
> was added back in 1992 in loop.c. The next change was in 1999 with the
> addition of simplify-rtx.c. Why are we talking about this now, instead
> of back
> when
Andrew Pinski <[EMAIL PROTECTED]> writes:
| The first change in GCC which changed signed overflow/wrapping to be
| undefined
| was added back in 1992 in loop.c. The next change was in 1999 with the
| addition of simplify-rtx.c. Why are we talking about this now,
| instead of back
| when they wer
On Jun 28, 2005, at 12:34 AM, Gabriel Dos Reis wrote:
The attitude that "undefined behaviour" should be interpreted
as "we should not make things more useful when we can" is beyond
understanding.
Then C/C++ aliasing rules go out the window really or maybe I
misunderstand
what you are trying
Andrew Pinski <[EMAIL PROTECTED]> writes:
| On Jun 28, 2005, at 12:34 AM, Gabriel Dos Reis wrote:
|
| > The attitude that "undefined behaviour" should be interpreted
| > as "we should not make things more useful when we can" is beyond
| > understanding.
|
| Then C/C++ aliasing rules go out the w
On Jun 28, 2005, at 1:12 AM, Gabriel Dos Reis wrote:
Andrew Pinski <[EMAIL PROTECTED]> writes:
| On Jun 28, 2005, at 12:34 AM, Gabriel Dos Reis wrote:
|
| > The attitude that "undefined behaviour" should be interpreted
| > as "we should not make things more useful when we can" is beyond
| > un
Andrew Pinski <[EMAIL PROTECTED]> writes:
| On Jun 28, 2005, at 1:12 AM, Gabriel Dos Reis wrote:
|
| > Andrew Pinski <[EMAIL PROTECTED]> writes:
| >
| > | On Jun 28, 2005, at 12:34 AM, Gabriel Dos Reis wrote:
| > |
| > | > The attitude that "undefined behaviour" should be interpreted
| > | > as "
On Tuesday 28 June 2005 07:12, Gabriel Dos Reis wrote:
> For the concrete case at issue, if the hardware I'm writing the C/C++
> programs for consistently displays modulo arithmetics for signed
> integer type, Andrew can you tell me why GCC should deny me access
> to that functionally where it actu
39 matches
Mail list logo
