On 6/18/07, Brooks Moses <[EMAIL PROTECTED]> wrote:
Giovanni Bajo wrote:
> Both our goals are legitimate. But that's not the point. The point is
> what -ffast-math semantically means (the simplistic list of suboptions
> activated by it is of couse unsufficiente because it doesn't explain how
> to
On Tue, 2007-06-19 at 01:50 +, Joseph S. Myers wrote:
> The ARM EABI says that only standard entries under "aeabi" should affect
> link-compatibility of object files, not vendor entries such as "gnu", but
> in the absence of corresponding standards for other processors I don't
> think we can
OTOH, if we start to produce NaN for sqrt(0.0) that is of course simply
'wrong', not inaccurate ;)
I still support the introduction of a special switch for this kind of
transformation, -fwrong-math-optimizations. :-)
Paolo
> I would like to get some more information about pr32374.
>
> I do not know what virtual_stack_vars are and there is no documentation
> in the doc directory.
It is documented:
@findex VIRTUAL_STACK_VARS_REGNUM
@cindex @code{FRAME_GROWS_DOWNWARD} and virtual registers
@item VIRTUAL_STACK_VARS_REG
On 6/19/07, Paolo Bonzini <[EMAIL PROTECTED]> wrote:
> OTOH, if we start to produce NaN for sqrt(0.0) that is of course simply
> 'wrong', not inaccurate ;)
I still support the introduction of a special switch for this kind of
transformation, -fwrong-math-optimizations. :-)
Probably as useful
On Mon, Jun 18, 2007 at 08:28:25PM -0400, Kenneth Zadeck wrote:
> I would like to get some more information about pr32374.
>
> I do not know what virtual_stack_vars are and there is no documentation
> in the doc directory.
less -p 'Virtual registers ' gcc/rtl.h
less -p 'enum global_rtl_index' gcc
On 6/19/07, Rask Ingemann Lambertsen <[EMAIL PROTECTED]> wrote:
> 3) If they really are uninitialized, why is it a problem to assign zero
> to them.
It is possible to mess up the substitution that the vregs pass performs.
IIRC, it happened to me once because I accidentally put one of these v
On Tue, Jun 19, 2007 at 11:11:54AM +0200, Uros Bizjak wrote:
> On 6/19/07, Rask Ingemann Lambertsen <[EMAIL PROTECTED]> wrote:
> >
> > It is possible to mess up the substitution that the vregs pass performs.
> >IIRC, it happened to me once because I accidentally put one of these
> >virtual
> >ps
On 19 June 2007 02:50, Joseph S. Myers wrote:
> Any comments on either the general approach or the details?
Sounds like a sane design to me :)
cheers,
DaveK
--
Can't think of a witty .sigline today
Hi all,
In case someone is interested, we just made a new patch available for gcc to
enable
run-time multiple option exploration and to enable run-time adaptation for
various constraints
on heterogeneous systems using function cloning. More information and a patch
are avilable here:
http://gcc
Rask Ingemann Lambertsen wrote:
> On Tue, Jun 19, 2007 at 11:11:54AM +0200, Uros Bizjak wrote:
>
>> On 6/19/07, Rask Ingemann Lambertsen <[EMAIL PROTECTED]> wrote:
>>
>>> It is possible to mess up the substitution that the vregs pass performs.
>>> IIRC, it happened to me once because I ac
On 6/19/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
Daniel Berlin wrote:
> Hi guys, I have merged all patches touching lto/ into the new lto branch
Thank you! Did you also pull over Kenny's LTO-writer code?
Yup.
I have the complete list of revisions merged with their log entries if
you'd li
On Tue, Jun 19, 2007 at 08:33:52AM -0400, Kenneth Zadeck wrote:
>
> Since it sounds like you understand this, are either of you willing/able
> to attack the problem at it's source?
Uros is already at it
http://gcc.gnu.org/ml/gcc-patches/2007-06/msg01317.html>.
--
Rask Ingemann Lambertsen
Hello,
While testing a patch on current trunk (r 125640) I've noticed that g++'s
cp_compat_x_tst.o-cp_compat_y_tst testcase fails with unexpected failure
on x86_64 with the vanilla version but passes OK with the patched version
(-O2). On ppc64 and i486 the test passes both with the vanilla and t
Hi,
m68k currently doesn't bootstrap, which I think is dataflow related, the
whole precompiled file is at http://www.xs4all.nl/~zippel/expmed.i.gz, but
the small test below should be enough to demonstrate the problem
(although it doesn't crash):
int fi1(int);
int fi2(int);
void *fp1(int, void
Roman Zippel wrote:
> Hi,
>
> m68k currently doesn't bootstrap, which I think is dataflow related, the
> whole precompiled file is at http://www.xs4all.nl/~zippel/expmed.i.gz, but
> the small test below should be enough to demonstrate the problem
> (although it doesn't crash):
>
> int fi1(int);
On powerpc-apple-darwin7 with 4.3.0 20070615, the compilation time
of the polyhedron test suite increased by 35% compared to the
previous snapshot and by 41% compared to the Apr 13 one:
compile execute
06/15 06/
On 6/19/07, Dominique Dhumieres <[EMAIL PROTECTED]> wrote:
On powerpc-apple-darwin7 with 4.3.0 20070615, the compilation time
of the polyhedron test suite increased by 35% compared to the
previous snapshot and by 41% compared to the Apr 13 one:
I did not see this change. What flags are you usi
Hi,
On Tue, 19 Jun 2007, Kenneth Zadeck wrote:
> roman do i need any patches to apply before trying this.
None should be needed, but this one can't hurt:
http://gcc.gnu.org/ml/gcc-patches/2007-06/msg01247.html
> also what are
> the config options i need?
I use --target=m68k-linux-gnu --enable
> I did not see this change. What flags are you using?
gfortran -w -O3 -ffast-math -funroll-loops
Dominique
On Mon, 2007-06-18 at 10:04 -0700, Mark Mitchell wrote:
> > I suspect that the realview compiler accepts
> > this as an oversight or a bug, not as an intentional feature.
>
> Let's ask.
>
> Richard E., is the fact that RealView 3.0SP1 accepts:
>
> class __declspec(notshared) S {
> __declsp
On Tue, Jun 19, 2007 at 04:26:46PM +0300, Revital1 Eres wrote:
> While testing a patch on current trunk (r 125640) I've noticed that g++'s
> cp_compat_x_tst.o-cp_compat_y_tst testcase fails with unexpected failure
> on x86_64 with the vanilla version but passes OK with the patched version
> (-O2).
Hello all:
I am reading codes of gcc front end. But I can not find the implementation
of "sizeof". How does gcc front end calculate size of UNION and STRUCT?
Where is the codes for these work. Can anybody give me some advices? Thank
you so much !
Richard Earnshaw wrote:
> On Mon, 2007-06-18 at 10:04 -0700, Mark Mitchell wrote:
>>> I suspect that the realview compiler accepts
>>> this as an oversight or a bug, not as an intentional feature.
>> Let's ask.
>>
>> Richard E., is the fact that RealView 3.0SP1 accepts:
>>
>> class __declspec(not
On 19 June 2007 16:35, bjzheng wrote:
> Hello all:
>
> I am reading codes of gcc front end. But I can not find the implementation
> of "sizeof". How does gcc front end calculate size of UNION and STRUCT?
> Where is the codes for these work. Can anybody give me some advices? Thank
> you so much !
[EMAIL PROTECTED] wrote:
> Hello all:
>
> I am reading codes of gcc front end. But I can not find the implementation
> of "sizeof". How does gcc front end calculate size of UNION and STRUCT?
> Where is the codes for these work. Can anybody give me some advices? Thank
> you so much !
The code is h
On 6/19/07, Rask Ingemann Lambertsen <[EMAIL PROTECTED]> wrote:
..
Hmm, how do you handle arg_pointer_rtx, frame_pointer_rtx and the like?
The are all uninitialized until the prologue is emitted, which is some time
after reload.
ARG_POINTER_REGNUM is included in the artificial defs of all bl
michael.a wrote:
>
>
> Since I'm already posting, now I'm seeing:
>
> /home/users/michael/gcc.obj/gcc/f951: symbol lookup error:
> /home/users/michael/gcc.obj/gcc/f951: undefined symbol:
> __gmp_get_memory_functions
>
>
I was able to find this:
http://www.nabble.com/Bootstrap-failure-in-
Roman Zippel wrote:
> Hi,
>
> m68k currently doesn't bootstrap, which I think is dataflow related, the
> whole precompiled file is at http://www.xs4all.nl/~zippel/expmed.i.gz, but
> the small test below should be enough to demonstrate the problem
> (although it doesn't crash):
>
> int fi1(int);
On Jun 18, 2007, at 6:50 PM, Joseph S. Myers wrote:
Any comments on either the general approach or the details?
Sounds fine to me. In mips land we were previously using named
sections to solve this, but as long as the approach allows arbitrarily
long sets of attributes I think it sounds g
Mark Mitchell wrote:
One advantage of having some SC members who are not GCC developers (and
thus seem less involved) is that they are more independent. They have
no commercial stake in which companies have maintainers,
The funny part in the discussion on the SC is that most contributors
see
Hello,
I am looking into writing scalar expansion and array privatization
passes for loop distribution with Sebastian.
Has scalar expansion and/or array privatization been implemented in gcc?
If so, how have they been implemented and also to what extent?
Does anyone have any pointers on where I can
> - 2 new attributes "far_data" (to use external memory for data
> storage) and "far_rodata" will be added.
I'd prefer just one "far" attribute. GCC knows (usually better than
the user ;) what data is read-only and what data is not.
> - By default, LDE instructions will be used to access the en
hello,
when I compile with -dv -fdump-rtl-* I somtimes see in the VCG files
some edges that have no meaning in the flow of the program.
these edges are always green and class 3.
what are those edges ? what is their purposes ?
thank you
sunzir
On Fri, Jun 08, 2007 at 01:27:39PM -0700, Mark Mitchell wrote:
> Joseph S. Myers wrote:
> > On Thu, 7 Jun 2007, Mark Mitchell wrote:
> >
> >> I am aware of three remaining projects which are or might be appropriate
> >> for Stage 1:
> >
> > Do we at this point believe that the people who were wor
Hi,
gcc's docs states that at -fstrict-aliasing:
"In particular, an object of one type is assumed never to reside at the
same address as an object of a different type, unless the types are almost
the same."
I have problems with this:
struct A {
float x, y;
};
struct B {
float
This may have been fixed by a recent patch to -Wstrict-aliasing. Let me
try to run the latest version of pre4.3 and will get back to you.
Herman Geza wrote:
Hi,
gcc's docs states that at -fstrict-aliasing:
"In particular, an object of one type is assumed never to reside at the
same address
On 6/19/07, Sunzir Deepur <[EMAIL PROTECTED]> wrote:
hello,
when I compile with -dv -fdump-rtl-* I somtimes see in the VCG files
some edges that have no meaning in the flow of the program.
these edges are always green and class 3.
what are those edges ? what is their purposes ?
thank you
sunzi
I have a -m option that I am handling in a LIB_SPEC that I do not want
passed down to cc1. It seems that by default, the driver passes all -m
options to cc1. Is there a way to prevent that on a per-option basis?
Thanks, Ben
On 6/16/07, Ross Ridge <[EMAIL PROTECTED]> wrote:
Robert Dewar writes:
>The only time that it is reasonable to extend is when there are clear
>signals from the standards committee that it is likely that a feature
>will be added, in which case there may be an argument for adding the
>feature "prem
Lawrence Crowl writes:
> On the specific topic of unions, there is a proposal before the
>committee to extend unions in this direction. Let me caution you
>that this proposal has not been reviewed by a significant fraction
>of the committee, and hence has a small chance of being accepted
>and an e
On Wed, 2007-06-20 at 10:44 +1000, Ben Elliston wrote:
> I have a -m option that I am handling in a LIB_SPEC that I do not want
> passed down to cc1. It seems that by default, the driver passes all -m
> options to cc1. Is there a way to prevent that on a per-option basis?
To now answer my own q
Michael Meissner wrote:
> I've looked at the changes, and I think with a minor bit of abstraction, we
> can
> modify the backends so that they don't care how the arguments are implemented.
Thanks for working on this!
> However, I think changing the representation of the arguments is a much more
ARG_POINTER_REGNUM is included in the artificial defs of all blocks
(which I think is overly conservative - just having them
in the entry block def should be enough).
Hence, from dataflow point of view, they are always considered initialized.
I think we should probably do something similar
for
Hello,
Current function declaration of __bswapdi2 in libgcc2.h is:
DItype __bswapdi2 (DItype u)
Since this declaration does not check if DItype is supported, it is
bound for compilation failure for targets that do not support DItype.
Would it be ok to change the DItype to DWtype as in:
DWtype
45 matches
Mail list logo
