Dear all,
I wrote a new pass for gcc. Actually the pass is always executed, but
I'd like to execute it only if I specify an option from shell (ex. gcc
--mypass pippo.c). How can I do?
Thanks to all
Andrea
[EMAIL PROTECTED] wrote on 04/12/2006 10:48:25:
> Dear all,
> I wrote a new pass for gcc. Actually the pass is always executed, but
> I'd like to execute it only if I specify an option from shell (ex. gcc
> --mypass pippo.c). How can I do?
Maybe adding a gate to your pass which is controlled by
Mark Mitchell <[EMAIL PROTECTED]> writes:
| Manuel López-Ibáñez wrote:
| > The message for the following error:
| >
| > enum e { E3 = 1 / 0 };
| >
| > is in C: error: enumerator value for 'E3' not integer constant
| > and in C++: error: enumerator value for 'E3' is not an integer constant
| >
Hello,
I have a problem with delete_output_reload. It sometimes deletes
instructions
which are needed. Here an analysis of a recent case (In a private
version of
the S390 port). The original S390 shows almost the same reloads, but
chooses
different registers.
Before reload we have
(insn 1597 169
Hello,
CLI back-end uses GIMPLE representation (to be more precise, a subset of
GIMPLE, the code undergoes a CLI-specific GIMPLE lowering at the end of
middle-end passes) and just emits bytecode in a CLI-specific assembler
generation pass.
Because of that, we (I mean CLI back-end project) would
> Hello,
> CLI back-end uses GIMPLE representation (to be more precise, a subset of
> GIMPLE, the code undergoes a CLI-specific GIMPLE lowering at the end of
> middle-end passes) and just emits bytecode in a CLI-specific assembler
> generation pass.
> Because of that, we (I mean CLI back-end pro
Jan Hubicka wrote:
Hello,
CLI back-end uses GIMPLE representation (to be more precise, a subset of
GIMPLE, the code undergoes a CLI-specific GIMPLE lowering at the end of
middle-end passes) and just emits bytecode in a CLI-specific assembler
generation pass.
Because of that, we (I mean CLI bac
Andrea Callia D'Iddio wrote on 12/04/06 03:48:
Dear all,
I wrote a new pass for gcc. Actually the pass is always executed, but
I'd like to execute it only if I specify an option from shell (ex. gcc
--mypass pippo.c). How can I do?
Create a new flag in common.opt and read its value in the gate fu
> Create a new flag in common.opt and read its value in the gate function
> of your pass. I *believe* this is documented somewher in the internals
> manual, but I'm not sure.
See also -
http://gcc.gnu.org/wiki/WritingANewPass
Hi,
Consider this (simplified) test case:
int bar (int a)
{
int b;
memcpy (&b, &a, sizeof (int));
return b;
}
gcc 3.4.3 compiles this to (-O3 -fomit-frame-pointer)
bar:
movl4(%esp), %eax
ret
But gcc 4.1.0 (and gcc 4.0.0 as well) generates:
bar:
See slides 18-35 in
http://gcc.gnu.org/wiki/OptimizationCourse?action=AttachFile&do=get&target=ExampleGCC_middle.pdf
(linked from http://gcc.gnu.org/wiki/OptimizationCourse).
dorit
> Dear all,
> I wrote a new pass for gcc. Actually the pass is always executed, but
> I'd like to execute it only i
On 12/3/06, Kaveh R. GHAZI <[EMAIL PROTECTED]> wrote:
This patch updates configure to require MPFR 2.2.1 as promised here:
http://gcc.gnu.org/ml/gcc/2006-12/msg00054.html
Tested on sparc-sun-solaris2.10 using mpfr-2.2.1, mpfr-2.2.0 and an older
mpfr included with gmp-4.1.4. Only 2.2.1 passed (a
On 12/3/06, Toon Moene <[EMAIL PROTECTED]> wrote:
Richard,
Somewhere, in a mail lost in my large e-mail clash with my ISP
(verizon), you said that gfortran couldn't profit from the pow(x, 1./3.)
-> cbrt(x) conversion because gfortran didn't "know" of cbrt.
Could you be more explicit about this
On Dec 3, 2006, at 12:44, Kaveh R. GHAZI wrote:
In case i370 support is revived or a format not using base==2 is
introduced, I could proactively fix the MPFR precision setting for any
base that is a power of 2 by multiplying the target float precision by
log2(base). In the i370 case I would mu
On Dec 4, 2006, at 8:23 AM, Richard Guenther wrote:
On 12/3/06, Kaveh R. GHAZI <[EMAIL PROTECTED]> wrote:
This patch updates configure to require MPFR 2.2.1 as promised here:
http://gcc.gnu.org/ml/gcc/2006-12/msg00054.html
Tested on sparc-sun-solaris2.10 using mpfr-2.2.1, mpfr-2.2.0 and
an ol
On Sun, Dec 03, 2006 at 12:44:11PM -0500, Kaveh R. GHAZI wrote:
>
> I'm not sure if these issues come up for fortran in prior releases. I
> think i370 was removed before 4.0/f95 and decimal floats were added in
> 4.2, which is not yet released.
>
This issue hasn't come up yet. In gfc_arith_ini
Richard Guenther wrote on 12/04/06 11:23:
On 12/3/06, Kaveh R. GHAZI <[EMAIL PROTECTED]> wrote:
I'd like to give everyone enough time to update their personal
installations and regression testers before installing this. Does
one week sound okay? If there are no objections, that's what I'd
On Mon, 2006-12-04 at 17:23 +0100, Richard Guenther wrote:
> On 12/3/06, Kaveh R. GHAZI <[EMAIL PROTECTED]> wrote:
> > This patch updates configure to require MPFR 2.2.1 as promised here:
> > http://gcc.gnu.org/ml/gcc/2006-12/msg00054.html
> >
> > Tested on sparc-sun-solaris2.10 using mpfr-2.2.1, m
I am pleased to announce that the GCC Steering Committee has
appointed Richard Guenther as non-algorithmic middle-end maintainer.
Please join me in congratulating Richi on his new role. Richi,
please update your listings in the MAINTAINERS file.
Happy hacking!
David
David Edelsohn wrote:
I am pleased to announce that the GCC Steering Committee has
appointed Richard Guenther as non-algorithmic middle-end maintainer.
Please join me in congratulating Richi on his new role.
Yes, congratulations Richard!
Paolo.
On Sat, Dec 02, 2006 at 12:01:45PM -0500, Kaveh R. GHAZI wrote:
> Hi Vincent, thanks for making this release. Since this version of mpfr
> fixes important bugs encountered by GCC, I've updated the gcc
> documentation and error messages to refer to version 2.2.1.
>
> I have NOT (yet) updated gcc's
On Mon, 2006-12-04 at 15:47 +0200, Kimmo Fredriksson wrote:
> Hi,
>
> Consider this (simplified) test case:
>
> int bar (int a)
> {
> int b;
> memcpy (&b, &a, sizeof (int));
> return b;
> }
> The local variable is optimized away, so what's the point adjusting esp?
On Dec 4, 2006, at 11:27 AM, Richard Guenther wrote:
On 12/3/06, Toon Moene <[EMAIL PROTECTED]> wrote:
Richard,
Somewhere, in a mail lost in my large e-mail clash with my ISP
(verizon), you said that gfortran couldn't profit from the pow(x,
1./3.)
-> cbrt(x) conversion because gfortran didn
Erwin Unruh wrote:
> I have a problem with delete_output_reload. It sometimes deletes
> instructions
> which are needed. Here an analysis of a recent case (In a private
> version of
> the S390 port). The original S390 shows almost the same reloads, but
> chooses
> different registers.
What GCC ve
here's an ignorant, naive, and very likely wrong attempt:
what happens if you mask off the high and low bytes of the
larger number, do two 8,8->16 multiplies, left shift the result
of the result of the higher one, and add, as a macro?
#define _mul8x16(c,s) ( \
(long int) ((c) * (unsigned
> IMHO, you should *never* update gcc's configure to force the issue. To do
> so would be unprecedented.
I'm not in favor of this either, but aren't there precedents with either
automake, autoconf, or both?
On Mon, Dec 04, 2006 at 02:09:25PM -0500, Richard Kenner wrote:
> > IMHO, you should *never* update gcc's configure to force the issue. To do
> > so would be unprecedented.
>
> I'm not in favor of this either, but aren't there precedents with either
> automake, autoconf, or both?
The ordinary us
Dear Janis,
I am having problems implementing your proposal.
The following testcase should fail with current mainline for every
dg-bogus. It actually passes perfectly :-(. I have tried removing
the dg-warning tests but then only the first dg-bogus fails, while
the other dg-bogus pass. The res
Joe Buck <[EMAIL PROTECTED]> writes:
> The ordinary user who builds gcc from source does not need *any*
> version of automake, autoconf, etc., so any strict requirements that
> are imposed on these tools have an impact only on gcc developers.
I wish we could have similar requirements for GMP and
> Yes, congratulations Richard!
Auf Deutsch, bitte! :-)
--
Eric Botcazou
Eric Botcazou wrote:
Yes, congratulations Richard!
Auf Deutsch, bitte! :-)
Mais oui, mon ami! ;)
Paolo.
I have finished a merge from mainline @ 119445 into the tuples branch. It
bootstraps and exhibits only one regression in libjava:
FAIL: PR27908 -O3 execution - source compiled test
This has been around forever, I've just been lazy and hadn't figured out
how to run java tests individually. Tom T
77662
Hi.
I've been seeing bootstrap failures in my last few attempts to build
mainline GCC. My last successful build was around November 26. I'm
running on i686-pc-linux-gnu using Debian unstable. My builds are
configured with the following short script:
$ cat gcc_conf.sh
#!/bin/sh
params="-march=pe
On 12/4/06, Howard Hinnant <[EMAIL PROTECTED]> wrote:
On Dec 4, 2006, at 11:27 AM, Richard Guenther wrote:
> On 12/3/06, Toon Moene <[EMAIL PROTECTED]> wrote:
>> Richard,
>>
>> Somewhere, in a mail lost in my large e-mail clash with my ISP
>> (verizon), you said that gfortran couldn't profit fro
On 12/4/06, David Edelsohn <[EMAIL PROTECTED]> wrote:
I am pleased to announce that the GCC Steering Committee has
appointed Richard Guenther as non-algorithmic middle-end maintainer.
Please join me in congratulating Richi on his new role. Richi,
please update your listings in t
On 12/4/06, Richard Guenther <[EMAIL PROTECTED]> wrote:
On 12/4/06, David Edelsohn <[EMAIL PROTECTED]> wrote:
> I am pleased to announce that the GCC Steering Committee has
> appointed Richard Guenther as non-algorithmic middle-end maintainer.
>
> Please join me in congratulating
On Dec 4, 2006, at 4:57 PM, Richard Guenther wrote:
My inclination is that if pow(x, 1./3.) (computed
correctly to the last bit) ever differs from cbrt(x) (computed
correctly to the last bit) then this substitution should not be done.
C99 7.12.7.1 says "The cbrt functions compute the real cu
On 12/4/06, Howard Hinnant <[EMAIL PROTECTED]> wrote:
On Dec 4, 2006, at 4:57 PM, Richard Guenther wrote:
>
>> My inclination is that if pow(x, 1./3.) (computed
>> correctly to the last bit) ever differs from cbrt(x) (computed
>> correctly to the last bit) then this substitution should not be do
On Tue, 5 Dec 2006, Richard Guenther wrote:
> is whether a correctly rounded "exact" cbrt differs from the pow
> replacement by more than 1ulp - it looks like this is not the case.
They fairly obviously differ for negative arguments, which are valid for
cbrt but not for pow (raising to a fractio
On 12/5/06, Joseph S. Myers <[EMAIL PROTECTED]> wrote:
On Tue, 5 Dec 2006, Richard Guenther wrote:
> is whether a correctly rounded "exact" cbrt differs from the pow
> replacement by more than 1ulp - it looks like this is not the case.
They fairly obviously differ for negative arguments, which
I have a situation where I have a class that internally maintains a
container object of non-const objects that it wants to publish to
clients as a const container of const objects, that is, clients can't
modify the list or the items in the list. The data member wants to be
non-const because th
> You can work around this by using union's of pointers of both non-const
> and const types, but the reinterpret_cast solution would be more attractive.
>
> Thoughts?
This has nothing to do with const vs non-const but rather
a and a are two seperate types which are not related in any way.
The C+
Andrew Pinski <[EMAIL PROTECTED]> writes:
| > You can work around this by using union's of pointers of both non-const
| > and const types, but the reinterpret_cast solution would be more attractive.
| >
| > Thoughts?
|
| This has nothing to do with const vs non-const but rather
| a and a are tw
>
> Andrew Pinski <[EMAIL PROTECTED]> writes:
>
> | > You can work around this by using union's of pointers of both non-const
> | > and const types, but the reinterpret_cast solution would be more
> attractive.
> | >
> | > Thoughts?
> |
> | This has nothing to do with const vs non-const but r
Doug Gregor wrote:
> This patch introduces canonical types into GCC, which allow us to
> compare two types very efficiently and results in an overall
> compile-time performance improvement. I have been seeing 3-5%
> improvements in compile time on the G++ and libstdc++ test suites,
> 5-10% on templ
In the code snippet below, the function mul_8_8 compiles to use
exactly one `mul' instruction on the AVR. The function mul_16_8 calls
mul_8_8 twice. If mul_8_8 is a static inline function and inlined in
mul_16_8, each call generates three `mul' instructions! Why does
inlining mul_8_8 cause each 8x
On 12/4/06, Shaun Jackman <[EMAIL PROTECTED]> wrote:
In the code snippet below, the function mul_8_8 compiles to use
exactly one `mul' instruction on the AVR. The function mul_16_8 calls
mul_8_8 twice. If mul_8_8 is a static inline function and inlined in
...
For comparison, a hand-coded 16x8 m
On Dec 4, 2006, at 6:08 PM, Richard Guenther wrote:
The question
is whether a correctly rounded "exact" cbrt differs from the pow
replacement by more than 1ulp - it looks like this is not the case.
If that is the question, I'm afraid your answer is not accurate. In
the example I showed the
Andrew Pinski <[EMAIL PROTECTED]> writes:
| >
| > Andrew Pinski <[EMAIL PROTECTED]> writes:
| >
| > | > You can work around this by using union's of pointers of both non-const
| > | > and const types, but the reinterpret_cast solution would be more
attractive.
| > | >
| > | > Thoughts?
| > |
On 2006-12-04 15:34:32 -0500, DJ Delorie wrote:
> Joe Buck <[EMAIL PROTECTED]> writes:
> > The ordinary user who builds gcc from source does not need *any*
> > version of automake, autoconf, etc., so any strict requirements that
> > are imposed on these tools have an impact only on gcc developers.
> > I wish we could have similar requirements for GMP and MPFR, rather
> > than requiring the user to pre-install them on pretty much EVERY
> > computer.
>
> Do you mean that gcc should be distributed with GMP and MPFR libraries
> in the tarball? (There had been a discussion about including them
On Mon, 4 Dec 2006, Joe Buck wrote:
> On Sat, Dec 02, 2006 at 12:01:45PM -0500, Kaveh R. GHAZI wrote:
> > Hi Vincent, thanks for making this release. Since this version of mpfr
> > fixes important bugs encountered by GCC, I've updated the gcc
> > documentation and error messages to refer to versi
On Mon, Dec 04, 2006 at 09:32:19PM -0500, Kaveh R. GHAZI wrote:
> OTOH, Joe you're arguing we should never require people to upgrade. Well
> I think that's unfair to people who rely on gcc to produce correct code.
So, should we detect old binutils versions and refuse to build as well?
How about o
Howard Hinnant wrote:
On Dec 4, 2006, at 6:08 PM, Richard Guenther wrote:
The question
is whether a correctly rounded "exact" cbrt differs from the pow
replacement by more than 1ulp - it looks like this is not the case.
If that is the question, I'm afraid your answer is not accurate. In
th
55 matches
Mail list logo
