> I tried this evening to install gmp-4.1.4 and mpfr-2.1.0 on my Solaris
> machines and I failed on the first try. (I think the default install
> for gmp on my machines is a 64-bit version, but the default for mpfr
> and gcc is 32-bit, so I'm going to have to figure out how to configure
> everythi
On Tue, 2005-02-15 at 03:09 +, Joseph S. Myers wrote:
> Another incidental observation from experiments with subversion: the
> output from svn diff seems to be in a fairly random order (rather than
> alphabetical order of filenames). Alphabetical order tends to be easier
> to follow when ch
Sorry if this has been answered before.
I installed gmp and mpfr successfully on my Mac G5 and so I can test
gfortran on my Mac.
I tried this evening to install gmp-4.1.4 and mpfr-2.1.0 on my Solaris
machines and I failed on the first try. (I think the default install
for gmp on my machines is
Joe Buck wrote:
The problem is that the user can independently set the IEEE rounding mode.
This means that you can only fold floating point constants in cases where
the generated result is exact; you cannot fold 1./3. for example.
Also, you should not assume that the user wants the kinds of diagnos
Mark Mitchell wrote:
Yes, that's useful -- but it's not actually *necessary* for a conforming
C++ compiler to be able to fold floating-point constants.
Also, note that strictly speaking, folding floating-point operations usually
violates the IEEE standard, which requires rounding mode to be able t
On Tue, 15 Feb 2005, Joe Buck wrote:
> The problem is that the user can independently set the IEEE rounding mode.
> This means that you can only fold floating point constants in cases where
> the generated result is exact; you cannot fold 1./3. for example.
You can fold 1./3. unless the user uses
On Wed, Feb 16, 2005 at 08:01:13AM +0900, Neil Booth wrote:
> Mark Mitchell wrote:-
>
> > However, while that may be necessary for Java, it's not necessary for
> > C++. In C++, fold should only be called for "integral constant
> > expressions", which, by definition, are made up of simple operat
> This is not actually true. Both ArX and tla support hardlinking the
> tree against the extra pristine copy. In fact, for the use case given
> (lots of old test builds), some or all could be linked against each
> other.
You could do this with svn as well if you wanted to.
Neil Booth wrote:
Mark Mitchell wrote:-
However, while that may be necessary for Java, it's not necessary for
C++. In C++, fold should only be called for "integral constant
expressions", which, by definition, are made up of simple operations on
integers. (It's a little more complicated than t
Mark Mitchell wrote:-
> However, while that may be necessary for Java, it's not necessary for
> C++. In C++, fold should only be called for "integral constant
> expressions", which, by definition, are made up of simple operations on
> integers. (It's a little more complicated than that, but a
> "Roger" == Roger Sayle <[EMAIL PROTECTED]> writes:
Roger> The operator BIT_FIELD_REF, for example, can be seen as a
Roger> canonical representation of a shift-and-mask or a
Roger> mask-and-shift operation.
The problem that lead to the creation of the can_use_bit_fields_p lang
hook was that
On Tue, 15 Feb 2005 22:26:31 +0100, Richard Guenther
<[EMAIL PROTECTED]> wrote:
> I guess the above
> should rather read
>
> if (TREE_CODE (exp) == VAR_DECL)
> {
> if (!cxx_mark_addressable (exp))
> return error_mark_node;
> adr = build1 (ADDR_EXPR, p
As per http://gcc.gnu.org/cvswrite.html:
"If you already have an account on sources.redhat.com, please send email
to overseers(at)gcc.gnu.org with a request for access to the GCC
repository. Include the name of the person who is sponsoring your
access. Else use this form to supply your SSH publi
> Yes, I'm working at fixing PR19807, i.e. folding of &a[] + c and &a + c,
> current patch (and related fixes) attached.
Now, really.
Richard.
p
Description: Binary data
On Tue, 15 Feb 2005 16:29:09 -0500, Andrew Pinski
<[EMAIL PROTECTED]> wrote:
>
> On Feb 15, 2005, at 4:26 PM, Richard Guenther wrote:
>
> > Ok, I guess the following excerpts from cp/typechk.c show a
> > discrepancy:
>
> Can you at least reduce the C++ code and also provide the patch which
> you
On Feb 15, 2005, at 4:26 PM, Richard Guenther wrote:
Ok, I guess the following excerpts from cp/typechk.c show a
discrepancy:
Can you at least reduce the C++ code and also provide the patch which
you are working on currently, this will help us understand the problem
better?
-- Pinski
Ok, I guess the following excerpts from cp/typechk.c show a discrepancy:
tree
build_address (tree t)
{
tree addr;
if (error_operand_p (t) || !cxx_mark_addressable (t))
return error_mark_node;
addr = build1 (ADDR_EXPR, build_pointer_type (TREE_TYPE (t)), t);
return addr;
}
1381 (de
Daniel Berlin wrote:
On Tue, 2005-02-15 at 15:59 +, Andrew STUBBS wrote:
I should note that svn treats it's remote connections as
disposable, so
svn+ssh will probably connect more than once for things
like remote
diffs. So if it takes a while to authenticate, this may
Roger Sayle writes:
>
> On Tue, 15 Feb 2005, Andrew Haley wrote:
> > There's one other thing to bear in mind when considering the way that
> > fold relates to language front ends. We've seen problems in Java
> > where fold() returned tree nodes that Java didn't recognize: one time,
> > for
On Tue, 15 Feb 2005, Andrew Haley wrote:
> There's one other thing to bear in mind when considering the way that
> fold relates to language front ends. We've seen problems in Java
> where fold() returned tree nodes that Java didn't recognize: one time,
> for example, it returned a BITFIELD_EXPR.
Andrew Haley wrote:
Mark Mitchell writes:
> >
> 1. Front ends should build up trees, calling fold only when/if they
> want. For example, in C++, we would want to call fold when we finish
> processing an "integral constant expression", which is a term of art in
> C++. (Though that operat
On Feb 15, 2005, at 2:37 PM, Benjamin Redelings I wrote:
Hi,
I have a reduced testcase from BOOST that fails with yesterdays CVS
(4.0.0 20050214 (experimental)), but compiles under 3.4. I don't know
if this is a bug in BOOST or in g++:
-- begin testcase
template< typename T, T
Hi,
I have a reduced testcase from BOOST that fails with yesterdays CVS
(4.0.0 20050214 (experimental)), but compiles under 3.4. I don't know
if this is a bug in BOOST or in g++:
-- begin testcase
template< typename T, T N >
struct integral_c
{
static const T value = N;
typ
Mark Mitchell writes:
> >
> 1. Front ends should build up trees, calling fold only when/if they
> want. For example, in C++, we would want to call fold when we finish
> processing an "integral constant expression", which is a term of art in
> C++. (Though that operation would be recursi
On Tue, Feb 15, 2005 at 06:02:39PM +, Andrew Haley wrote:
> Richard Henderson writes:
> > On Tue, Feb 15, 2005 at 05:27:15PM +, Andrew Haley wrote:
> > > So, now for my question: why do we not call __register_frame_info() or
> > > __register_frame_info_bases() ?
> >
> > Because in the
On Tue, Feb 15, 2005 at 09:20:57AM -0700, Bob Proulx wrote:
>Daniel Berlin wrote:
>>I should note that svn treats it's remote connections as disposable, so
>>svn+ssh will probably connect more than once for things like remote
>>diffs. So if it takes a while to authenticate, this may not be your
>>
Richard Henderson writes:
> On Tue, Feb 15, 2005 at 05:27:15PM +, Andrew Haley wrote:
> > So, now for my question: why do we not call __register_frame_info() or
> > __register_frame_info_bases() ?
>
> Because in the normal case for C/C++, folks don't use that many
> exceptions. So dela
Hi!
The C++ frontend creates from cp/call.c:3864 (build_new_op
(code=PLUS_EXPR, flags=3, ...)) with arg1
(gdb) call debug_tree(arg1)
volatile unsigned type_6 DI
size
unit size
align 64 symtab -1780663408 alias set -1
pointer_to_this
Richard Kenner wrote:
1. Exactly what expressions need to get folded at compile-time is
language-dependent. Therefore, front ends need to control what
expressions get folded and how that folding takes place.
I think I'm agreeing with you, but I just want to make sure that "need" in
1. Exactly what expressions need to get folded at compile-time is
language-dependent. Therefore, front ends need to control what
expressions get folded and how that folding takes place.
I think I'm agreeing with you, but I just want to make sure that "need" in
the above means "requi
On Tue, Feb 15, 2005 at 12:43:44PM -0500, Daniel Jacobowitz wrote:
> This may be exactly what you're suggesting, but could we do this
> instead of what we do now?
>
> - use dl_iterate_phdr to register and search any unregistered objects
Done naievely, this will fail with dlclose.
r~
On Tue, Feb 15, 2005 at 09:41:22AM -0800, Richard Henderson wrote:
> On Tue, Feb 15, 2005 at 05:27:15PM +, Andrew Haley wrote:
> > So, now for my question: why do we not call __register_frame_info() or
> > __register_frame_info_bases() ?
>
> Because in the normal case for C/C++, folks don't us
On Tue, Feb 15, 2005 at 05:27:15PM +, Andrew Haley wrote:
> So, now for my question: why do we not call __register_frame_info() or
> __register_frame_info_bases() ?
Because in the normal case for C/C++, folks don't use that many
exceptions. So delaying doing anything until it's needed is a w
I agree with Nathan. I'm going to try to restate.
Premises:
1. Exactly what expressions need to get folded at compile-time is
language-dependent. Therefore, front ends need to control what
expressions get folded and how that folding takes place.
2. It is of course useful to share optimization
This is about DWARF 2 unwinding through shared libraries.
As far as I can see, on current x86 GNU/Linux targets we don't call
__register_frame_info() or __register_frame_info_bases() from the
library startup code in crtbegin. There is code to do it, but it's
disabled.
When _Unwind_Find_FDE() is
On Sun, 7 Nov 2004 10:36:13 -0500
Daniel Jacobowitz <[EMAIL PROTECTED]> wrote:
> Yes, this is also rounded up to the page size at present. Redefining
> HOST_HOOKS_GT_PCH_ALLOC_GRANULARITY should be all it takes..
[ responding to an ancient email, sorry... ]
This actually turns out to be impract
Daniel Berlin wrote:
> I should note that svn treats it's remote connections as disposable, so
> svn+ssh will probably connect more than once for things like remote
> diffs. So if it takes a while to authenticate, this may not be your
> best bet if you are looking for blazing speed (as some seem t
On Tue, 2005-02-15 at 15:59 +, Andrew STUBBS wrote:
> > > > I should note that svn treats it's remote connections as
> > > > disposable, so
> > > > svn+ssh will probably connect more than once for things
> > like remote
> > > > diffs. So if it takes a while to authenticate, this may
> > not
> > > I should note that svn treats it's remote connections as
> > > disposable, so
> > > svn+ssh will probably connect more than once for things
> like remote
> > > diffs. So if it takes a while to authenticate, this may
> not be your
> > > best bet if you are looking for blazing speed (as som
On Tue, 2005-02-15 at 15:35 +, Andrew STUBBS wrote:
> > The ssh username is actually gcc, password foo2bar
> >
> > so svn+ssh://[EMAIL PROTECTED]/gcc/trunk
> >
> > would work (note for ssh, it's /gcc/trunk, not /svn/gcc/trunk. This is
> > because it's running svnserve with a different root.
> The ssh username is actually gcc, password foo2bar
>
> so svn+ssh://[EMAIL PROTECTED]/gcc/trunk
>
> would work (note for ssh, it's /gcc/trunk, not /svn/gcc/trunk. This is
> because it's running svnserve with a different root. Just an
> oversight,
> AFAIK :P)
Excellent. I now have a successfu
On Tue, 2005-02-15 at 12:36 +, Andrew STUBBS wrote:
> Hi,
>
> Joern and I are having difficulty accessing the subversion test repository.
>
> "svn co svn://svn.toolchain.org/svn/gcc/trunk" does not work due to the ST
> corporate firewall (don't ask - the wheels turn slowly), so I have been
>
On Tue, 15 Feb 2005, Daniel Berlin wrote:
> On Tue, 2005-02-15 at 11:31 +0100, Richard Guenther wrote:
>
> > Wether fully_constant_expression
> > is in error, or the assert, I do not know. But I guess other
> > kind of folding could trigger this, too.
>
> Neither is really in error, it should c
On Tue, 2005-02-15 at 11:31 +0100, Richard Guenther wrote:
> On Tue, 15 Feb 2005, Richard Guenther wrote:
>
> > Hi!
> >
> > I have isolated the patch (attached) that caused the previously reported
> > build ICE and a testcase. The patch enables folding of
> > &a[i] + cst to &a[i+cst] in addition
Hi,
Joern and I are having difficulty accessing the subversion test repository.
"svn co svn://svn.toolchain.org/svn/gcc/trunk" does not work due to the ST
corporate firewall (don't ask - the wheels turn slowly), so I have been
looking for an alternative approach.
Is there any alternative to stra
On Tue, 15 Feb 2005, Richard Guenther wrote:
> Hi!
>
> I have isolated the patch (attached) that caused the previously reported
> build ICE and a testcase. The patch enables folding of
> &a[i] + cst to &a[i+cst] in addition to &a[i] + cst*j -> &a[i+j].
> If enabled, this transformation triggeres
Hi!
I have isolated the patch (attached) that caused the previously reported
build ICE and a testcase. The patch enables folding of
&a[i] + cst to &a[i+cst] in addition to &a[i] + cst*j -> &a[i+j].
If enabled, this transformation triggeres two times in the
testcase derived from libiberty/sort.c:
* Daniel Berlin:
> It's not easier to implement. Trying to translate cvs into changesets
> is not easy (though the reverse is), unless you do it the stupid way (IE
> not try to discover what is a copy and what isn't).
> So matching commit for commit won't give you good history.
> Especially on br
48 matches
Mail list logo
