On 12/19/06, Ferad Zyulkyarov <[EMAIL PROTECTED]> wrote:
tree fn_decl;
tree fn_id;
fn_id = get_identifier("test_fn_call");
fn_decl = lookup_name(fn_id); /* returns you a pointer to the function
declaration tree */
Hope this is what you are looking for.
On 12/19/06, Rohit Arul Raj <[EMAIL PROT
Paul Schlie wrote:
As a compromise, I'd vote that no optimizations may alter program behavior
in any way not explicitly diagnosed in each instance of their application.
Sounds reasonable, but it is impossible and impractical! And I think
anyone familiar with compiler technology and optimizatio
Robert Dewar writes:
> Paul Brook wrote:
>
> > As opposed to a buggy program with wilful disregard for signed overflow
> > semantics? ;-)
>
> I know there is a smiley there, but in fact I think it is useful to
> distinguish these two cases.
This is, I think, a very interesting comment.
Andrew Haley wrote:
Is it simply that one error is likely to be more common than another?
Or is there some more fundamental reason?
I think it is more fundamental. Yes, of course any optimization
will change resource utilization (space, time). An optimization
may well make a program larger, wh
On 2006-12-20, at 00:10, Richard B. Kreckel wrote:
C89 did not refer to IEEE 754 / IEC 60559. Yet, as far as I am aware,
-ffast-math or the implied optimizations have never been turned on
by GCC
unless explicitly requested. That was a wise decision.
By the same token it would be wise to re
Hello,
> > Paul Brook wrote:
> > >> Compiler can optimize it any way it wants,
> > >> as long as result is the same as unoptimized one.
> > >
> > > We have an option for that. It's called -O0.
> > >
> > > Pretty much all optimization will change the behavior of your program.
> >
> > Now that's
Denis Vlasenko writes:
> On Tuesday 19 December 2006 20:05, Andrew Haley wrote:
> > Denis Vlasenko writes:
> > >
> > > I wrote this just a few days ago:
> > >
> > > do {
> > > int32_t v1 = v << 1;
> > > if (v < 0) v1 ^= mask;
> > >
Zdenek Dvorak wrote:
actually, you do not even need (invalid) multithreaded programs to
realize that register allocation may change behavior of a program.
If the size of the stack is bounded, register allocation may
cause or prevent program from running out of stack, thus turning a
crashing prog
[EMAIL PROTECTED] wrote:
it should be fairly easy to indicate each and every
undefined/unspecified value/semantic
assumption being applied to both explicitly declared variables and
implicit intermediate
results of programmer specified expressions and their resulting
hopefully logically equival
Hi,
PR19978 reports that some overflow warnings are emitted multiple times. Like
for example,
test.c:6: warning: integer overflow in expression
test.c:6: warning: integer overflow in expression
test.c:6: warning: integer overflow in expression
The current testsuite will match any number of thos
blitzen:/home/jonatha/packages/gcc-3.4.5$ config.guess
powerpc-ibm-aix5.3.0.0
blitzen:/home/jonatha/packages/gcc-3.4.5$ gcc -v
Reading specs from
/home/jonatha/build/bin/../lib/gcc/powerpc-ibm-aix5.3.0.0/3.4.5/specs
Configured with: ./configure --with-as=/usr/bin/as
--with-ld=/usr/bin-ld --disable
> [EMAIL PROTECTED] net writes:
jonathan> Configured with: ./configure --with-as=/usr/bin/as
jonathan> Had to export DESTDIR for make install in gcc objdir
jonathan> to work
Thanks for the notification. You will have less problems building
and installing GCC if you do not build it i
Hi,
The gcc docs say:
`-fwrapv'
... This flag enables some optimizations and disables others.
-fwrapv turns some undefined behaviour (according to C99) into well-defined
behaviour, therefore it is obvious that it can disable some optimizations.
But the other way around? Without -fwrapv t
Jan Eissfeld <[EMAIL PROTECTED]> writes:
> PR19978 reports that some overflow warnings are emitted multiple times. Like
> for example,
>
> test.c:6: warning: integer overflow in expression
> test.c:6: warning: integer overflow in expression
> test.c:6: warning: integer overflow in expression
>
On Wed, 20 Dec 2006, Bruno Haible wrote:
> But the other way around? Without -fwrapv the compiler can assume more
> about the program being compiled (namely that signed integer overflows
> don't occur), and therefore has more freedom for optimizations. All
> optimizations that are possible with -f
On Wed, 20 Dec 2006, Bruno Haible wrote:
> > But the other way around? Without -fwrapv the compiler can assume more
> > about the program being compiled (namely that signed integer overflows
> > don't occur), and therefore has more freedom for optimizations. All
> > optimizations that are possible
On Wed, Dec 20, 2006 at 03:50:23PM +, Joseph S. Myers wrote:
Indeed. Fixing this may require it to be possible to mark individual
operations with their overflow semantics (which will also be needed for
LTO to handling inlining between translation units compiled with different
options).
> "Paolo" == Paolo Bonzini <[EMAIL PROTECTED]> writes:
>> On Wed, Dec 20, 2006 at 03:50:23PM +, Joseph S. Myers wrote:
>> For signed integers, overflow is undefined, but for unsigned integers,
>> overflow wraps.
Paolo> You mean writing the hypothetical PLUS_WRAP_EXPR (where a and b
Paolo
Dave Korn wrote:
On 20 December 2006 02:28, Andrew Pinski wrote:
Paul Brook wrote:
Pretty much all optimization will change the behavior of your program.
Now that's a bit TOO strong a statement, critical optimizations like
register allocation and instruction scheduling will generally not chan
On 20 December 2006 16:25, Matthew Woehlke wrote:
> Dave Korn wrote:
>> On 20 December 2006 02:28, Andrew Pinski wrote:
Paul Brook wrote:
> Pretty much all optimization will change the behavior of your program.
Now that's a bit TOO strong a statement, critical optimizations lik
On 12/20/06, Dave Korn <[EMAIL PROTECTED]> wrote:
...
> We (in a major, commercial application) ran into exactly this issue.
> 'asm volatile("lock orl $0,(%%esp)"::)' is your friend when this happens
> (it is a barrier across which neither the compiler nor CPU will reorder
> things). Failing that
Dave Korn wrote:
Particularly lock-free queues whose correct
operation is critically dependent on the order in which the loads and
stores are performed.
No, absolutely not. Lock-free queues work by (for example) having a single
producer and a single consumer, storing the queue in a circular
Marcin Dalecki wrote:
Numerical stability of incomplete floating point representations are
an entirely different
problem category then some simple integer tricks. In the first case
the difficulties are inherent
to the incomplete representation of the calculation domain. In the
second case it's
Matthew Woehlke <[EMAIL PROTECTED]> writes:
> That said, I've seen even stranger things, too. For example:
>
> foo->bar = make_a_bar();
> foo->bar->none = value;
>
> being rendered as:
>
> call make_a_bar
> foo->bar->none = value
> foo->bar =
You are not describing a C compiler.
Andreas.
--
A
On 2006-12-20, at 22:48, Richard B. Kreckel wrote:
2) Signed types are not an algebra, they are not even a ring, at
least when their elements are interpreted in the canonical way as
integer numbers. (Heck, what are they?)
You are apparently using a different definition of an algebra or rin
On 12/20/06, Marcin Dalecki <[EMAIL PROTECTED]> wrote:
You are apparently using a different definition of an algebra or ring
than the common one.
Fascinating discussion. Pointers to canonical on-line definitions of
the terms "algebra" and "ring" as used in compiler design please?
While testing a cross-compiler, I had to track down a handful of
failures in gcc.misc-tests/bprob.exp and g++.dg/bprop/bprob.exp. The
test harness was reporting that the .gcda data files were not being
created after running the instrumented test case.
After some digging, I managed to work out why
On Thu, 2006-12-21 at 09:56 +1100, Ben Elliston wrote:
> After some digging, I managed to work out why: the gcov runtime code
> wants to create the .gcda file in the same directory that the object
> file was created on the build system. Unless the same directory
> structure exists on the target,
2006/12/12, [EMAIL PROTECTED] <[EMAIL PROTECTED]>:
I've come across an issue with using the -pg switch for profiling on the
DJGPP DOS platform, using GCC 4.1.0.
I suggest that you send this report to [EMAIL PROTECTED], the
DJGPP port of GCC maintainers are much more likely to respond there.
-
> I suggest that you send this report to [EMAIL PROTECTED], the
> DJGPP port of GCC maintainers are much more likely to respond there.
He did that first.
"Laurynas Biveinis" <[EMAIL PROTECTED]> wrote on 12/20/2006
04:05:00 PM:
# I suggest that you send this report to [EMAIL PROTECTED], the
# DJGPP port of GCC maintainers are much more likely to respond there.
I've actually already been in communication with DJ Delorie; I thought I
might get some a
Marcin Dalecki wrote:
On 2006-12-20, at 22:48, Richard B. Kreckel wrote:
2) Signed types are not an algebra, they are not even a ring, at
least when their elements are interpreted in the canonical way as
integer numbers. (Heck, what are they?)
You are apparently using a different definiti
But the same applies to floating point numbers. There, the
situation is even better, because nowadays I can rely on a float or
double being the representation defined in IEEE 754 because there
is such overwhelming hardware support.
You better don't. Really! Please just realize for example t
Paul Brook <[EMAIL PROTECTED]> writes:
| > Compiler can optimize it any way it wants,
| > as long as result is the same as unoptimized one.
|
| We have an option for that. It's called -O0.
|
| Pretty much all optimization will change the behavior of your program. The
| important distinction is
"Dave Korn" <[EMAIL PROTECTED]> writes:
[...]
| > We (in a major, commercial application) ran into exactly this issue.
| > 'asm volatile("lock orl $0,(%%esp)"::)' is your friend when this happens
| > (it is a barrier across which neither the compiler nor CPU will reorder
| > things). Failing that
Andrew Haley <[EMAIL PROTECTED]> writes:
[...]
| C is no longer a kind of high-level assembly laguage:
| it's defined by a standard, in terms of an abstract machine, and some
| operations are not well-defined.
that does not mean C is not a kind of high-level assembly language.
:-/
-- Gaby
Matthew Woehlke <[EMAIL PROTECTED]> writes:
> That said, I've seen even stranger things, too. For example:
>
> foo->bar = make_a_bar();
> foo->bar->none = value;
>
> being rendered as:
>
> call make_a_bar
> foo->bar->none = value
> foo->bar =
That would obviously be a bug in the compiler.
>
On 20 December 2006 20:16, Seongbae Park wrote:
> On 12/20/06, Dave Korn <[EMAIL PROTECTED]> wrote:
> ...
>>> We (in a major, commercial application) ran into exactly this issue.
>>> 'asm volatile("lock orl $0,(%%esp)"::)' is your friend when this happens
>>> (it is a barrier across which neither
On Thursday 21 December 2006 02:38, Gabriel Dos Reis wrote:
> Paul Brook <[EMAIL PROTECTED]> writes:
> | > Compiler can optimize it any way it wants,
> | > as long as result is the same as unoptimized one.
> |
> | We have an option for that. It's called -O0.
> |
> | Pretty much all optimization wil
On 20 December 2006 21:42, Matthew Woehlke wrote:
> Dave Korn wrote:
>>> Particularly lock-free queues whose correct
>>> operation is critically dependent on the order in which the loads and
>>> stores are performed.
>>
>> No, absolutely not. Lock-free queues work by (for example) having a
>>
On 21 December 2006 02:50, Gabriel Dos Reis wrote:
> Andrew Haley <[EMAIL PROTECTED]> writes:
>
> [...]
>
>> C is no longer a kind of high-level assembly laguage:
>> it's defined by a standard, in terms of an abstract machine, and some
>> operations are not well-defined.
>
> that does not mean
Gabriel Dos Reis wrote:
I don't believe this particular issue of optimization based on
"undefined behaviour" can be resolved by just telling people "hey
look, the C standard says it is undefined, therefore we can optimize.
And if you're not happy, just tell the compiler not to optimize".
For not
On Dec 20, 2006, at 09:38, Bruno Haible wrote:
But the other way around? Without -fwrapv the compiler can assume more
about the program being compiled (namely that signed integer overflows
don't occur), and therefore has more freedom for optimizations. All
optimizations that are possible with -f
Geert Bosch wrote:
This is completely wrong. Making operations undefined is a two-edged
sword. At the one hand, you can make more assumptions, but there's
also the issue that when you want to rewrite expressions, you have
to be more careful to not introduce undefined behavior when there
was none
Hi All,
Does anyone know of any document describing (in details) the reload phase
of GCC?
I am planning to write a linear scan reload for GCC (one that does not
take reg_renumber
but takes instruction specific register allocation and move information).
Can anyone point me
to some existing code
45 matches
Mail list logo
