On Nov 24, 2007 5:54 AM, Alexandre Oliva <[EMAIL PROTECTED]> wrote:
> > Apparently, you can't treat DEBUG_INSN just like any other normal
> > insn.
>
> Obviously not. They're weaker uses than anything else. We haven't
> had any such thing in the compiler before.
So we get a "third way". GCC has
L.S.,
I noticed some unexpected progress last night (as opposed to about a
week ago).
Previous figures:
5316 loops vectorized
6060 loops not vectorized
New figures:
5188 loops vectorized
6189 loops not vectorized
i.e., 201 loops *more* recognized by the vectorizer, of which 72 got
vectori
I wrote:
5188 loops vectorized
Dang ! Should be 5388 of course, otherwise the math doesn't add up.
--
Toon Moene - e-mail: [EMAIL PROTECTED] - phone: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
At home: http://moene.indiv.nluug.nl/~toon/
GNU Fortran's path to
On Nov 24, 2007, "Steven Bosscher" <[EMAIL PROTECTED]> wrote:
> On Nov 24, 2007 5:54 AM, Alexandre Oliva <[EMAIL PROTECTED]> wrote:
>> > Apparently, you can't treat DEBUG_INSN just like any other normal
>> > insn.
>>
>> Obviously not. They're weaker uses than anything else. We haven't
>> had an
On Nov 24, 2007, [EMAIL PROTECTED] (Richard Kenner) wrote:
>> Yes, catching all such cases hasn't been trivial. If we miss some,
>> then what happens is that -O2 -g -fvar-tracking-assignments outputs
>> different executable code than -O2.
> But that's a very serious type of bug because it means
On Nov 24, 2007 4:00 PM, Alexandre Oliva <[EMAIL PROTECTED]> wrote:
> On Nov 24, 2007, "Steven Bosscher" <[EMAIL PROTECTED]> wrote:
>
> > And it has to handle this new case everywhere.
>
> I've already explained why this isn't true. It's not even close to
> being true. In fact, I've chosen this r
Alexandre Oliva wrote:
> And then, despite the consensus that GCC must not generate different
> code with and without -g, the patch that fixes one such regression has
> been lingering for months, and the patch that introduced the
> regression hasn't been reverted either.
Pointers?
Bernd
--
Th
> Besides, the Ada RTS compiles differently with -g than without -g,
> such that compare-debug doesn't pass if you compare sysdep.o. Nobody
> but me seems to care.
That's wierd. Except on Windows, VXWorks, and VMS, there's almost
no code in that file.
> I recently compiled the entire Debian archive (around 6500 packages
> that need to be compiled) on SPARC using trunk to identify new issues
> before GCC 4.3 is released. I compiled the archive twice, once with
> default optimization levels specified by packages and once with
> optimization set t
On Nov 24, 2007, [EMAIL PROTECTED] (Richard Kenner) wrote:
>> Besides, the Ada RTS compiles differently with -g than without -g,
>> such that compare-debug doesn't pass if you compare sysdep.o. Nobody
>> but me seems to care.
> That's wierd. Except on Windows, VXWorks, and VMS, there's almost
>
On Nov 24, 2007, Bernd Schmidt <[EMAIL PROTECTED]> wrote:
> Alexandre Oliva wrote:
>> And then, despite the consensus that GCC must not generate different
>> code with and without -g, the patch that fixes one such regression has
>> been lingering for months, and the patch that introduced the
>> re
On Nov 12, 2007, Joe Buck <[EMAIL PROTECTED]> wrote:
> consider dropping observable points where the states will not match.
We can't really do that. The line number mapping is from PC to line
number, regardless of how far into the execution or earlier lines the
code is. Omitting certain mapping
On Nov 24, 2007 9:19 PM, Alexandre Oliva <[EMAIL PROTECTED]> wrote:
> On Nov 24, 2007, Bernd Schmidt <[EMAIL PROTECTED]> wrote:
>
> > Alexandre Oliva wrote:
> >> And then, despite the consensus that GCC must not generate different
> >> code with and without -g, the patch that fixes one such regress
> The piece of the puzzle we're still missing is how to get debuggers
> clever enough to decide where to set a breakpoint. Nowadays, debuggers
> (at least those I'm familiar with) tend to set breakpoints at the
> lowest-numbered PC corresponding to a given source line number. While
> this is usef
On Nov 17, 2007, Gabriel Dos Reis <[EMAIL PROTECTED]> wrote:
> I had no trouble getting students up to spead on well-structured
> plugable proprietary compiler within weeks. However, the same
> experience on GCC has proven much less impressive results.
> Consequently, we have been making more pro
On Nov 16, 2007, Basile STARYNKEVITCH <[EMAIL PROTECTED]> wrote:
> For example, the "simple" plugin mechanism many people have implicitly
> in mind is just: something give you the ability to call a dlsymed
> function inside a dlopened plugin as a pass in a defined (& fixed)
> position in passes.c.
> And then, once the underlying problem is addressed and we have an API
> that is usable by regular users, maybe we will find out that we don't
> need plugins, after all. That, as Diego and Ian say, adding plugin
> support is trivial, but I'm pretty sure that's not where the actual
> problem lies.
On Nov 15, 2007, Diego Novillo <[EMAIL PROTECTED]> wrote:
> If/when your pass reaches certain maturity, you think it's ready for
> production, and people think it's a good idea to have it in the
> compiler, then you convert it into a static pass and you go through
> the traditional bootstrap proce
Alexandre Oliva wrote:
On Nov 15, 2007, Diego Novillo <[EMAIL PROTECTED]> wrote:
If/when your pass reaches certain maturity, you think it's ready for
production, and people think it's a good idea to have it in the
compiler, then you convert it into a static pass and you go through
the tradition
On Nov 7, 2007, Brendon Costa <[EMAIL PROTECTED]> wrote:
> If the license extends to the data generated by GPL apps
It doesn't, AFAIK, but IANAL. But the issue is not so much the
specific data, but the format in which the data is and the reasons
behind choosing that format.
The FSF might succe
On Nov 24, 2007, at 1:54 PM, Alexandre Oliva wrote:
On Nov 16, 2007, Basile STARYNKEVITCH <[EMAIL PROTECTED]>
wrote:
For example, the "simple" plugin mechanism many people have
implicitly
in mind is just: something give you the ability to call a dlsymed
function inside a dlopened plugin a
On Nov 24, 2007, Diego Novillo <[EMAIL PROTECTED]> wrote:
> Alexandre Oliva wrote:
>> On Nov 15, 2007, Diego Novillo <[EMAIL PROTECTED]> wrote:
>>
>>> If/when your pass reaches certain maturity, you think it's ready for
>>> production, and people think it's a good idea to have it in the
>>> compi
On Nov 24, 2007, Alexandre Oliva <[EMAIL PROTECTED]> wrote:
> On Nov 24, 2007, Bernd Schmidt <[EMAIL PROTECTED]> wrote:
>> Alexandre Oliva wrote:
>>> And then, despite the consensus that GCC must not generate different
>>> code with and without -g, the patch that fixes one such regression has
>>>
Alexandre Oliva wrote:
Besides, the Ada RTS compiles differently with -g than without -g,
such that compare-debug doesn't pass if you compare sysdep.o. Nobody
but me seems to care.
We certainly care about this, and appreciate efforts to fix it!
Robert Dewar. We = all the GNAT folks.
On Nov 24, 2007, "Richard Guenther" <[EMAIL PROTECTED]> wrote:
> Generated code shouldn't change if we allocate extra DECL_UIDs, but
> only possibly if we change DECL_UID ordering. (If that is the
> problem, as I remember your analysis)
That is indeed the problem, but I'm not sure your requireme
On Nov 25, 2007 12:28 AM, Alexandre Oliva <[EMAIL PROTECTED]> wrote:
> On Nov 24, 2007, "Richard Guenther" <[EMAIL PROTECTED]> wrote:
>
> > Generated code shouldn't change if we allocate extra DECL_UIDs, but
> > only possibly if we change DECL_UID ordering. (If that is the
> > problem, as I rememb
To imagine that i'm using "-g -Os -finline-functions -funroll-loops".
There are differences in how to generate "optimized AND debugged" code.
A) Whole-optimized but with dirty debugged information if possible.
Wh
To imagine that i'm using "-g -Os -finline-functions -funroll-loops".
There are differences in how to generate "optimized AND debugged" code.
A) Whole-optimized but with dirty debugged information if possible.
Wh
On Nov 24, 2007, Alexandre Oliva <[EMAIL PROTECTED]> wrote:
> hat is indeed the problem, but I'm not sure your requirement is
> feasible. If we permit DECL_UID divergence, it means we can't use
> DECL_UID for hashing any more. Since they already stand for hashable
> proxies for the decl pointers,
> L.S.,
>
> I noticed some unexpected progress last night (as opposed to about a
> week ago).
>
> Previous figures:
>
> 5316 loops vectorized
> 6060 loops not vectorized
>
> New figures:
>
> 5188 loops vectorized
> 6189 loops not vectorized
>
> i.e., 201 loops *more* recognized by the vectorizer, o
> The FSF might successfully present to a court an argument such as:
>
> Look, Your Honor, it is quite obvious that the code in question was
> developed to work as a single program, and that the separation
> through the intermedia representation layer is just an attempt to
> escape the con
The incomplete information (with losses) from A) doesn't mean BAD design.
This is as a paradox of compression,
A) for lossy compressors like JPEG, MP3, Ogg/Vorbis, MPEG, ...
and B) for lossless data compressors like PNG, GIF, zip, gzip, bzip2,
rar, 7z, ...
You will understand quickly the meaning
32 matches
Mail list logo
