On Sat, 2007-06-16 at 06:17 -0700, H. J. Lu wrote:
> BTW, an x86 DFP configure bug was reported 3 months ago. But it still
> hasn't benen fixed. I opened a DFP bug report:
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32351
>
> with a patch. I hope it will be fixed before gcc 4.3 is released
> I'm completely unsurprised this is broken at the tree level given how
> it is implemented
Nice tautology. :-) You have resisted implementing anything at the tree level
to fix the problem and now you're complaining there is a problem...
Let's try and devise something plausible at the tree leve
> I am trying now to prototype a new approach along the lines of
> returning true in component_uses_parent_alias_set for SFT's with
> DECL_NONADDRESSABLE_P.
Yes, the key problem is indeed SFTs, which is why we disable structure
aliasing in the Ada compiler.
--
Eric Botcazou
- compile with the loop unrolled 1x, 2x, 4x, 8x, 16x, 32x and
measure the time the benchmark takes
The optimal unrolling factor may not be a power of two, depending on
icache size (11 times the loop body size?), iteration count (13*n for
some unknown n?), and whether there are actions perf
> > type T1 is record
> >J : Integer;
> > end record;
> >
> > X1 : T1;
> >
> > => then X1.J "address" cannot be taken in legal Ada, so no integer
> > pointer can ever point to it.
>
> However, can a pointer to X1, stored into, affect J?
Of course.
> If so, field J's alias set must be marked
On Jun 17, 2007, at 6:40 PM, Dave Korn wrote:
On 17 June 2007 18:17, Ross Ridge wrote:
Daniel Jacobowitz writes:
The minimum I'd want to accept this code would be a complete and
useful
example in the manual; since Mark and Danny say this happens a lot
on Windows
I don't understand how th
On 6/17/07, Richard Kenner <[EMAIL PROTECTED]> wrote:
> > > > So if I have
> > > > struct foo {int x; float y; } bar;
> > >
> > > But if you add
> > >
> > > struct foo *foop = &bar.
> > >
> > > foop->x = 5.
> > >
> > > It can, even though we *claim* X is nonaddressable.
> >
> > Which can
Tim Prince-4 wrote:
>
> Then use s release or snapshot tarball from mirrors of
> ftp://gcc.gnu.org/pub/gcc/, and/or get better software, and use gcc-help
> as intended.
>
Yes, I apologize, that link and virtually all of the mirrors were timing out
all last night (well for a couple hours at
[EMAIL PROTECTED] wrote:
http://gcc.gnu.org/mirrors.html
Can someone recommend an alternative means of obtaining GCC source releases?
I can't find a GCC source package in debian repositories.
EDIT: I should've said the subversion repository is likely unworkible for my
setup according to googl
On 17 June 2007 18:17, Ross Ridge wrote:
> Daniel Jacobowitz writes:
>> The minimum I'd want to accept this code would be a complete and useful
>> example in the manual; since Mark and Danny say this happens a lot
>> on Windows
>
> I don't understand how this issue can come up at all on Windows.
On Monday 18 June 2007 04:23:35 michael.a wrote:
> I'm sorry, but can anyone get through to any of these mirrors ever:
>
> http://gcc.gnu.org/mirrors.html
The first mirror there, ftp://gd.tuwien.ac.at/gnu/gcc/ works fine. But next
time please use gcc-help mailing list for such questions. Thanks.
I'm sorry, but can anyone get through to any of these mirrors ever:
http://gcc.gnu.org/mirrors.html
Can someone recommend an alternative means of obtaining GCC source releases?
I can't find a GCC source package in debian repositories.
--
View this message in context:
http://www.nabble.com/I%
> > > > So if I have
> > > > struct foo {int x; float y; } bar;
> > >
> > > But if you add
> > >
> > > struct foo *foop = &bar.
> > >
> > > foop->x = 5.
> > >
> > > It can, even though we *claim* X is nonaddressable.
> >
> > Which can what exactly?
>
> It can be addressed, as i've shown ab
On Sun, 2007-06-17 at 17:02 -0400, Daniel Berlin wrote:
> On 6/17/07, Laurent GUERBY <[EMAIL PROTECTED]> wrote:
> > In Ada if you have a struct type, components of the struct
> > that do not have the explicit keyword "aliased" cannot
> > have their adress taken. Example:
> >
> > type T1 is record
>
On Sun, 17 Jun 2007, Uros Bizjak wrote:
> I was trying to load a full 128 bit constant into __float128 variable, but
> with "L" suffix, I was able to load only XFmode constant. Is there a special
> suffix for __float128 available in gcc?
No; since the x86-64 ABI is what defines the __float128 nam
On 6/17/07, Laurent GUERBY <[EMAIL PROTECTED]> wrote:
On Sun, 2007-06-17 at 15:31 -0400, Daniel Berlin wrote:
> On 6/17/07, Eric Botcazou <[EMAIL PROTECTED]> wrote:
> > > > So if I have
> > > > struct foo {int x; float y; } bar;
> > > > int *pi;
> > > > float *pf;
> > > >
[EMAIL PROTECTED] wrote:
Tim Prince wrote:
There are several issues. EQUIVALENCE produces such a problem
(PR32373) as do various kinds of references to multiple sections of
the same array (PR32375,32376,32377,32378,32379,32380). Only 2 of
those PRs involve actual source/destination overlap,
On Sun, 2007-06-17 at 15:31 -0400, Daniel Berlin wrote:
> On 6/17/07, Eric Botcazou <[EMAIL PROTECTED]> wrote:
> > > > So if I have
> > > > struct foo {int x; float y; } bar;
> > > > int *pi;
> > > > float *pf;
> > > >
> > > > and mark X as "nonaddressable", I know that an a
Hello!
I was trying to load a full 128 bit constant into __float128 variable,
but with "L" suffix, I was able to load only XFmode constant. Is there a
special suffix for __float128 available in gcc?
Uros.
Rask Ingemann Lambertsen wrote:
> On Sat, Jun 16, 2007 at 11:36:00PM -0400, Kenneth Zadeck wrote:
>
>>> Try:
>>>
>>> df_note_add_problem ();
>>> df_analyze ();
>>> --
>>> #pragma ident "Seongbae Park, compiler, http://seongbae.blogspot.com";
>>>
>> What Seongbae said is correct. However,
On 6/17/07, Eric Botcazou <[EMAIL PROTECTED]> wrote:
> > So if I have
> > struct foo {int x; float y; } bar;
> > int *pi;
> > float *pf;
> >
> > and mark X as "nonaddressable", I know that an assigment to *pi can't
> > affect bar.x.
>
> But if you add
>
> struct foo *foop
Tim Prince wrote:
There are several issues. EQUIVALENCE produces such a problem (PR32373)
as do various kinds of references to multiple sections of the same array
(PR32375,32376,32377,32378,32379,32380). Only 2 of those PRs involve
actual source/destination overlap, where the vectorizer would
On 17/06/2007 20.20, Uros Bizjak wrote:
I was wondering if there are objects to automatically activating Uros'
new -mrecip flag when -ffast-math is specified. It looks like a good
match since -mrecip is exactly about fast non-precise mathematics.
There is a discussion in gcc-patches@ mailing
Eric Botcazou writes:
> For the Ada testcase:
>
> ;; s->i = 0
> (insn 7 6 0 p.adb:5 (set (mem/s/j:SI (reg/v/f:DI 59 [ s ]) [4 .i+0
> S4 A32])
> (const_int 0 [0x0])) -1 (nil))
>
> ;; *p = 1
> (insn 8 7 0 p.adb:6 (set (mem:SI (reg/v/f:DI 60 [ p ]) [2 S4 A32])
> (const_int 1 [0x1]))
Hello,
I have one more question regarding the comment in
tree-ssa-ccp.c file -
/* Note that for propagation purposes, we are only interested in
visiting statements that load the exact same memory reference
stored here. Those statements will have the exact same list
Hello!
I was wondering if there are objects to automatically activating Uros'
new -mrecip flag when -ffast-math is specified. It looks like a good
match since -mrecip is exactly about fast non-precise mathematics.
There is a discussion in gcc-patches@ mailing list about this topic, in
"Re: [
Hello,
I was wondering if there are objects to automatically activating Uros' new
-mrecip flag when -ffast-math is specified. It looks like a good match since
-mrecip is exactly about fast non-precise mathematics.
--
Giovanni Bajo
Hi Dorit,
some years ago I posted these testcases to Bugzilla's GCC:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18437
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18438
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18439
It looks like none of those are vectorized as of GCC 4.3. I read today that
Aaron W. LaFramboise-3 wrote:
>
> michael.a wrote:
>
>> So in closing, I'm interested in any ideas / advice, but compromising the
>> existing codebase is completely out of the question. You have my
>> appreciation in advance naturally...
>
> I suspect the proper solution here is something fro
michael.a wrote:
So in closing, I'm interested in any ideas / advice, but compromising the
existing codebase is completely out of the question. You have my
appreciation in advance naturally...
I suspect the proper solution here is something from www.boost.org. You
didn't say exactly what you
Just for the record, this construction was proposed to me from behind the
scenes:
> class Rect
> {
>Rect()
>{
> new (&xlat) Vec2(); // Explicit calls to the ctor
> new (&size) Vec2();
>}
>~Rect()
>{
> xlat.~Vec2();
>
Daniel Jacobowitz writes:
>The minimum I'd want to accept this code would be a complete and useful
>example in the manual; since Mark and Danny say this happens a lot
>on Windows
I don't understand how this issue can come up at all on Windows. As far
I know, visibility is an ELF-only thing, while
Martin Jambor wrote:
>
> On Sat, Jun 16, 2007 at 06:16:03PM -0700, michael.a wrote:
>>
>> Any advice on compiling gcc? That is the chicken and egg problem. If I
>> install a binary version of GCC, then use it to build and install a
>> custom
>> GCC (which I want to become the system wide GCC)
On Sat, Jun 16, 2007 at 10:13:34PM -0700, Chris Lattner wrote:
> Because there is no standard to reference, I think it's important to consider
> these things in terms of explainability.
Chris said everything I could have said about this (better, too). I
want to particularly highlight this part.
[EMAIL PROTECTED] wrote:
Tim Prince <[EMAIL PROTECTED]> wrote on 17/06/2007 04:15:56:
[EMAIL PROTECTED] wrote:
On Sat, Jun 16, 2007 at 06:54:46PM +0300, Dorit Nuzman wrote:
There are quite a few known simple cases which vectorizer fails to
vectorize.
by "known" you mean there are open missed
On Sat, Jun 16, 2007 at 04:31:14PM -0700, Mark Mitchell wrote:
> H. J. Lu wrote:
>
> > Who are those relevant maintainers? Since Intel BID patches only
> > affects DFP intrinsics, which is only supported on Linux/PPC,
> > Linux/ia32 and Linux/x86-64 while Linux/PPC uses DPD encoding, not
> > BID e
Ross Ridge wrote:
Since it's essentially impossible to be impartial about a feature you
created, both senses of the word apply here.
It's not only possible, but usual in many technical settings. There
is no reason (or excuse) for getting emotionally attached to language
design proposals. In my
Ross Ridge wrote:
t formal definition.
Most of GCC's long list of extensions to C are also implemented as
extensions to C++, so you've already lost this battle in GNU C++.
And many of them are ill-defined (and some would agree ill-considered).
Mistakes in the past are not a good reason for mis
Rask Ingemann Lambertsen wrote:
On Sat, Jun 16, 2007 at 08:11:18PM +0200, Uros Bizjak wrote:
Hello!
There is something strange going on, it looks that initialization of
virtual-stack-vars register in init-regs pass confuses greg. In
154r.regclass we have this sequence:
It should
Dorit Nuzman wrote:
>> H. J. Lu wrote:
>>
>>> Why don't we turn on vectorizer at -O3 or even -O2, depending on
>>> ISA? I added -ftree-vectorize to BOOT_CFLAGS on x86-64. According to
>>> -ftree-vectorizer-verbose=1, there are 82 loops vectorized in
>>> gcc source. There are no regressions. There a
Ross Ridge wrote:
>I completely disagree. Standards should primarily standardize existing
>practice, not inventing new features. New features should be created
>by people who actually want and will use the features, not by some
>disinterested committee.
Robert Dewar write:
>First of all, I think
Fortunately gcc 4.3 will have also faster compilation speed than 4.2
even with the df infrastructure (which may be, and I hope, helps to
improve the code finally). That is because some work was done to speed
up tree-SSA infrastructure (and Paolo Bonizini's frwprop) to improve the
compilation
"Daniel Berlin" <[EMAIL PROTECTED]> wrote on 16/06/2007:
> On 6/16/07, Dorit Nuzman <[EMAIL PROTECTED]> wrote:
>
> > Do you have specific examples where SLP helps performance out of loops?
>
> hash calculations.
>
> For md5, you can get a 2x performance improvement by straight-line
> vectorizing
> > struct foo {int x; float y; } bar;
> > int *pi;
> > float *pf;
> >
> > and mark X as "nonaddressable", I know that an assigment to *pi can't
> > affect bar.x.
>
> But if you add
>
> struct foo *foop = &bar.
>
> foop->x = 5.
>
> It can, even though we *claim* X is non
On Sat, Jun 16, 2007 at 06:16:03PM -0700, michael.a wrote:
>
> Any advice on compiling gcc? That is the chicken and egg problem. If I
> install a binary version of GCC, then use it to build and install a custom
> GCC (which I want to become the system wide GCC) ...then how is this
> commonly done?
> H. J. Lu wrote:
>
> > Why don't we turn on vectorizer at -O3 or even -O2, depending on
> > ISA? I added -ftree-vectorize to BOOT_CFLAGS on x86-64. According to
> > -ftree-vectorizer-verbose=1, there are 82 loops vectorized in
> > gcc source. There are no regressions. There are not much changes
>
Tim Prince <[EMAIL PROTECTED]> wrote on 17/06/2007 04:15:56:
> [EMAIL PROTECTED] wrote:
> > On Sat, Jun 16, 2007 at 06:54:46PM +0300, Dorit Nuzman wrote:
> >>> There are quite a few known simple cases which vectorizer fails to
> >>> vectorize.
> >> by "known" you mean there are open missed-optimiz
> > So if I have
> > struct foo {int x; float y; } bar;
> > int *pi;
> > float *pf;
> >
> > and mark X as "nonaddressable", I know that an assigment to *pi can't
> > affect bar.x.
>
> But if you add
>
> struct foo *foop = &bar.
>
> foop->x = 5.
>
> It can, even though we *cl
> Because it wouldn't be pruning it if the alias sets conflicted!
Well, just look at the first RTL dump for:
struct S { int i; };
int f (struct S *s, int *p)
{
s->i = 0;
*p = 1;
return s->i;
}
and
package P is
type S is record
i : Integer;
end record;
type SP is access all S;
49 matches
Mail list logo
