Paolo Carlini wrote:
> Besides repeating again that personally I consider this effort very,
> very welcome, just wanted to restate (*) that probably you should take
> as baseline current *mainline*, not 4.0.0, because, of course, any
> possible patch will go in mainline only. Also obvious, in case
Sebastian Pop wrote on 19/07/2005 09:49:11:
> Robert Dewar wrote:
> >
> > and that is called a false positive if in fact the loop does
> > not overrun. this sounds very dubious to me
I concur.
>
> The problem is that the compiler has no other information about the
> number of iterations in t
[EMAIL PROTECTED] (Gabriel Dos Reis) wrote on 17.07.05 in <[EMAIL PROTECTED]>:
> Daniel Berlin <[EMAIL PROTECTED]> writes:
>
> | On Sun, 2005-07-17 at 00:05 +0200, Gabriel Dos Reis wrote:
> | > Daniel Berlin <[EMAIL PROTECTED]> writes:
> | >
> | > [...]
> | >
> | > | You make it sound like the s
There are regressions involving complex aritmetic in the testsuite too:
> FAIL: gfortran.dg/real_const_1.f (test for excess errors)
> WARNING: gfortran.dg/real_const_1.f compilation failed to produce
> executable
The regression appeared between 20050716 and 20050717 on i686-linux and
i386-freeb
[EMAIL PROTECTED] wrote:
>I hope copyright assignment won't be neccessary, though, since the patch
>doesn't contain any
>large blocks of code outside of the testcases. It's just a lot of small,
>scattered changes. But if you think copyright assignment is neccessary,
>please tell me what I need to
OK to commit?
Ping.
This problem is really blocking a very nice gfortran feature (support
for large real kinds). Since it is very short, could someone review it?
FX
2005-07-19 Francois-Xavier Coudert <[EMAIL PROTECTED]>
* builtins.def: Add DEF_EXT_C99RES_BUILTIN to define builtins
PING. Could one of the mingw/cygwin maintainers review this patch? Or
can someone else do it?
http://gcc.gnu.org/ml/gcc-patches/2005-07/msg00086.html
[EMAIL PROTECTED] (Kai Henningsen) writes:
| [EMAIL PROTECTED] (Gabriel Dos Reis) wrote on 17.07.05 in <[EMAIL
PROTECTED]>:
|
| > Daniel Berlin <[EMAIL PROTECTED]> writes:
| >
| > | On Sun, 2005-07-17 at 00:05 +0200, Gabriel Dos Reis wrote:
| > | > Daniel Berlin <[EMAIL PROTECTED]> writes:
| >
Michael Veksler wrote:
> This is problematic:
> 1. I am not sure it will turn the warning off.
So you don't want a warning that cannot be turned off simply by
modifying the code. Then, I withdraw the patch that I have proposed
to implement the warning.
Sebastian Pop <[EMAIL PROTECTED]> wrote on 19/07/2005 12:58:23:
| Michael Veksler wrote:
| > This is problematic:
| > 1. I am not sure it will turn the warning off.
|
| So you don't want a warning that cannot be turned off simply by
| modifying the code.
Most of gcc warnings are like that: you
currently the C++ include directories for biarch builds
(i.e. i486-linux-gnu, x86_64-linux-gnu) are not set properly for the
non-default target. At least the c++config.h header differs. On
i486-linux-gnu a x86_64-linux dir is installed, but is not used, for
powerpc-linux-gnu, no powerpc64-linux-gnu
Hi,
I am working on some gcc patches (now profiling indirect/virtual
calls and it's devirtualization) and i would like to contribute it to
gcc. I've read that i must sign some forms for contributing. Could you
tell me where can i get it ?
Thanks
Tomas Bily
Hello,
I'm currently working on implementing a tool chain for a 'pet
language' of mine called O (for Obscure, since my preferred name was
taken). You can see the [unfinished] language specification here:
http://sean.heybryan.org/spec0_unfinished.pdf
Note that the implementation notes chap
On Mon, 18 Jul 2005, Tom Tromey wrote:
>> his weekend 4.1 snapshot installs two new info files,
>> hacking.info and vmintegration.info.
> We don't want these. I'll disable this one way or another.
Great, thanks.
> I have a few other minor cleanup fixes from this merge too; I'll get
> them all in
(I have put these directions at
http://www.dberlin.org/~dberlin/patchdirections.html)
After much discussion on IRC.
I've set up a simple patch queue for tracking patches at
http://www.dberlin.org/cgi-bin/patches.py
The data in there is real, those are patches that need to be reviewed,
along wit
Today's checkout and bootstrap on apple-x86-darwin resulted in the
following:
stage1/xgcc -Bstage1/ -B/usr/local/i686-apple-darwin8.1.0/bin/ -O2 -
g -fomit-frame-pointer -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-
prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-
variadic-m
On Tue, 2005-07-19 at 09:37 +0200, FX Coudert wrote:
> > There are regressions involving complex aritmetic in the testsuite too:
> > FAIL: gfortran.dg/real_const_1.f (test for excess errors)
> > WARNING: gfortran.dg/real_const_1.f compilation failed to produce
> > executable
>
> The regression
On Tue, Jul 19, 2005 at 01:17:22PM -0400, Daniel Berlin wrote:
> On Tue, 2005-07-19 at 09:37 +0200, FX Coudert wrote:
> > > There are regressions involving complex aritmetic in the testsuite too:
> > > FAIL: gfortran.dg/real_const_1.f (test for excess errors)
> > > WARNING: gfortran.dg/real_const
For the curious, the patch queue source (which is just about 60 lines
python + cheetah templates) is at
http://www.dberlin.org/cgi-bin/viewcvs.cgi/?root=webrepo
I haven't added the thing that grabs info from gcc-patches into the
source yet.
Patches welcome, of course (Ian Taylor submitted a patch
On Tue, Jul 19, 2005 at 03:31:08PM +0200, Tomas Bily took 10 lines to write:
> Hi,
>
> I am working on some gcc patches (now profiling indirect/virtual
> calls and it's devirtualization) and i would like to contribute it to
> gcc. I've read that i must sign some forms for contributing. Could you
Does someone know of any comparisons (with regard to optimization,
standard conformance, etc.) made between GCC and other, comercial,
compilers?
I'm primarily interested in comparisons made for ARM and PowerPC
targets, but x86 is also of interest.
-- Stefan
> Gabriel Dos Reis writes:
> If by analysis, you can determine ...
The problem with this type of logic is that it leads to arbitrary
inconsistent designation of an object's reference as a function of
the breadth of the "analysis", therefore seems clearly undesirable.
Resulting in only two possibi
Paul Schlie <[EMAIL PROTECTED]> writes:
| > Gabriel Dos Reis writes:
| > If by analysis, you can determine ...
|
| The problem with this type of logic is that it leads to arbitrary
| inconsistent designation of an object's reference as a function of
| the breadth of the "analysis", therefore seem
On Tue, Jul 19, 2005 at 10:31:13AM -0700, Steve Kargl wrote:
> Someone broke optimization of complex arithmetic. A 2005-06-01
> mainline gives the expected answer. A 2005-06-15 mainline is
> broken. I'll continue my binary search. Fortunately, building
> gcc on a dual opteron system with 12 GB
On Tue, Jul 19, 2005 at 11:20:51AM -0700, Richard Henderson wrote:
> On Tue, Jul 19, 2005 at 10:31:13AM -0700, Steve Kargl wrote:
> > Someone broke optimization of complex arithmetic. A 2005-06-01
> > mainline gives the expected answer. A 2005-06-15 mainline is
> > broken. I'll continue my binar
> From: Gabriel Dos Reis <[EMAIL PROTECTED]>
> Paul Schlie <[EMAIL PROTECTED]> writes:
>
> | > Gabriel Dos Reis writes:
> | > If by analysis, you can determine ...
> |
> | The problem with this type of logic is that it leads to arbitrary
> | inconsistent designation of an object's reference as a
I think that the underlying problem here, as with pointers to data members,
comes from using POINTER_TYPE in the first type. Pointers to members are
not pointers, and so using POINTER_TYPE just causes confusion.
Jason
Jason Merrill wrote:
I think that the underlying problem here, as with pointers to data members,
comes from using POINTER_TYPE in the first type. Pointers to members are
not pointers, and so using POINTER_TYPE just causes confusion.
I heartily agree. PTRMEM_CST was a step in the right directi
Hello,
Please complete the attached questionnaire according to the included
instructions.
All the best,
Ted Teah
Please email the following information to [EMAIL PROTECTED], and we
will send you the assignment form for your past and future changes.
Please use your full name as the subject line
Mark Mitchell <[EMAIL PROTECTED]> writes:
| Jason Merrill wrote:
| > I think that the underlying problem here, as with pointers to data members,
| > comes from using POINTER_TYPE in the first type. Pointers to members are
| > not pointers, and so using POINTER_TYPE just causes confusion.
|
| I h
On Tue, Jul 19, 2005 at 11:07:33AM +0200, FX Coudert wrote:
>PING. Could one of the mingw/cygwin maintainers review this patch? Or
>can someone else do it?
>
>http://gcc.gnu.org/ml/gcc-patches/2005-07/msg00086.html
I'd prefer that Danny review this but neither of us has the right to
approve this
I'd prefer that Danny review this but neither of us has the right to
approve this patch.
Well, then, who has the right to approve such a patch?
However, it seems like you're adding extra stuff to the Makefile where
it is already trying to do the right thing if $(LN) fails. Couldn't LN
just be
I am porting gcc to a new platform which is supported vector arithmetic
operations.
(I'm using the latest 4.0.x snapshot version and upgrading it every week.)
Currently, we can write the following multiply-accumulation RTL template for
non-vector type:
[(set (match_operand:DI 0 "register_opera
Gabriel Dos Reis wrote:
| the object-representation side; we need a PTRMEM_TYPE on the type side
| as well. Because we don't have a proper lowering phase, the
| difficulty is that we need to transmute PTRMEM_TYPE into
| OFFSET_TYPE/RECORD_TYPE at some point.
|
| However, that's no excuse for f
On Tue, Jul 19, 2005 at 10:03:14PM +0200, FX Coudert wrote:
>>I'd prefer that Danny review this but neither of us has the right to
>>approve this patch.
>
>Well, then, who has the right to approve such a patch?
>
>>However, it seems like you're adding extra stuff to the Makefile where
>>it is alrea
On Tue, Jul 19, 2005 at 04:14:04PM -0400, Christopher Faylor wrote:
> Ok. Given that 'cp' was an acceptable fallback in the original version
> of the above script, I wonder why 'cp' wasn't used instead of creating a
> shell script wrapper.
Because it is desirable to leave the tools where they wer
Mark Mitchell <[EMAIL PROTECTED]> writes:
| Gabriel Dos Reis wrote:
|
| > | the object-representation side; we need a PTRMEM_TYPE on the type side
| > | as well. Because we don't have a proper lowering phase, the
| > | difficulty is that we need to transmute PTRMEM_TYPE into
| > | OFFSET_TYPE/RE
Gabriel Dos Reis wrote:
| > I recon that such
| > representation needs a lowering stage, but it looks like we're doing
| > that more or less already. Do I miss something?
|
| Yes -- we don't really have a lowering stage, unless you count
| transformation to GENERIC.
Yes, I had transformatio
Snapshot gcc-3.4-20050719 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/3.4-20050719/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 3.4 CVS branch
with the following options: -rgcc-ss-3_4-20050719
You'll
Hi
This is just a headsup for any folks running 3.4.x testsuite under Linux
2.6.12 kernels (stock Linus).
I started seeing new PCH failures after upgrading to this kernel:
http://gcc.gnu.org/ml/gcc-testresults/2005-07/msg01069.html
The cause is due to inclusion of the address space randomizat
40 matches
Mail list logo
