Hello,
I get the following error while running
make check-gcc RUNTESTFLAGS="compat.exp"
with mainline gcc version 4.3.0 20070312
on PPC.
Revital
=== g++ tests ===
Schedule of variations:
unix
Running target unix
Using /usr/local/share/dejagnu/baseboards/unix.exp as board d
As I'm now building GCC 4.2.0 RC1 (*), and am thereby beginning the
release cycle for 4.2.0, I've disabled the 4.2 branch snapshots. It
seems confusing to have both the prereleases (which I build) and the
snapshots (which robots build) available simultaneously, and I would
prefer to focus testing
I've noticed some behavior with make_relative_prefix that surprised
me. In particular, consider this program:
#include
extern char * make_relative_prefix (const char *progname,
const char *bin_prefix,
const char *p
[EMAIL PROTECTED] wrote:
I sincerely apologize for the spammish nature of this e-mail - I
don't mean to abuse this list. I am trying to collect responses
from as many open source developers and users as possible and a
mailing list like can be the only way to reach many developers.
FWIW, one op
Hello
My name is Lara Thynne and I am a PhD candidate at Deakin University
Australia. I am currently researching the boundary between work and
leisure activities directly related to the open source community and
open source program development.
As part of this I am running a survey at the follo
Hi,
We are pleased to announce the release of AspeCt-oriented C (ACC) V
0.5, formerly known as AspectC.
Besides some new features, the ACC 0.5 release also includes a set of
experimental weave adapters that
help integrate aspeCts in the build process of large C-based software
projects.
For m
On 3/12/07, Mike Stump <[EMAIL PROTECTED]> wrote:
On Mar 12, 2007, at 2:14 PM, Paolo Carlini wrote:
> When I said, let's support Doug, I meant let's support Doug from a
> *practical* point of view. Either we suggest something doable with
> a realistically sized effort or a little larger and at th
On 3/12/07, Mike Stump <[EMAIL PROTECTED]> wrote:
That said, we
all realize we are _not_ asking Doug to please re-implement the C++
frontend to our design to fix this issue. I'd be against that.
Thank you :)
I'm hoping that might allow us to reduce the pressure enough so that
we can fit back
> So, you need to run aclocal with:
> $ aclocal -I ../config -I ..
>
> --
> albert chin ([EMAIL PROTECTED])
Thanks, that helps a lot. For libstdc++-v3 I actually needed "-I ." as
well in order to find linkage.m4 so maybe "-I . -I .. -I ../config" is
the best option list to use on aclocal call
Snapshot gcc-4.1-20070312 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20070312/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.1 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
On Mar 12, 2007, at 2:14 PM, Paolo Carlini wrote:
When I said, let's support Doug, I meant let's support Doug from a
*practical* point of view. Either we suggest something doable with
a realistically sized effort or a little larger and at the same
time we volunteer to actually do it. In my o
Mark Mitchell wrote:
* PR 27945 (Merill)
* PR 30590 (Guenther, Merill)
I'll get on these.
Jason
> It's going to have a big performance impact. To extract a 9-bit value,
> the compiler will need to do a lot of masking every time it accesses
> the TREE_CODE.
"a lot masking" means at most two additional instructions, one if we
put it in the right place. I'd be shocked if we could even measure
On 3/12/07, Paolo Carlini <[EMAIL PROTECTED]> wrote:
In my opinion, "visions" for a better
future do not help here.
No, I fully agree. I mean, imagine we'd have a long term plan for
GCC. That would be so out of line!
;-)
I'm not arguing against a practical solution. But to me at least it is
Mike Stump wrote:
On Mar 12, 2007, at 11:13 AM, Doug Gregor wrote:
With the introduction of the variadic templates patch, we now have
more than 255 tree codes in GCC.
I do wonder about compilation speed for C++ code. Barring some other
innovative approach, even with a slow down, which I'd hat
On Mon, 12 Mar 2007, Mike Stump wrote:
> :-) I don't have any objections, as long as people can keep the compilation
> speed up, though, sounds like a bit of work. I'd look towards a project
> architect to help steer us towards goodness and keep us out of trouble. I can
> see some advantage to
On 3/12/07, Andrew Pinski <[EMAIL PROTECTED]> wrote:
On 3/12/07, Steven Bosscher <[EMAIL PROTECTED]> wrote:
> On 3/12/07, Andrew Pinski <[EMAIL PROTECTED]> wrote:
> > Can I recommend something just crazy, rewrite the C and C++ front-ends
> > so they don't use the tree structure at all except when
Paolo Carlini <[EMAIL PROTECTED]> writes:
| In my opinion, "visions" for a better future do not help here.
And here we are. :-)
-- Gaby
Steven Bosscher wrote:
Another real solution would perhaps be to not use 'tree' for front end
specific data structures in C++, and instead just define g++ specific
data structures to represent all the language details ;-)
When I said, let's support Doug, I meant let's support Doug from a
*pra
On Mar 12, 2007, at 1:47 PM, Andrew Pinski wrote:
Can I recommend something just crazy, rewrite the C++ front-end so
they don't use the tree structure at all except when lowering until
gimple like the rest of the GCC front-ends?
:-) I don't have any objections, as long as people can keep th
"Steven Bosscher" <[EMAIL PROTECTED]> writes:
| On 3/12/07, Paolo Carlini <[EMAIL PROTECTED]> wrote:
| > we are unavoidably
| > adding tree codes and we must solve the issue, one way or another.
|
| Another real solution would perhaps be to not use 'tree' for front end
| specific data structures
On 3/12/07, Steven Bosscher <[EMAIL PROTECTED]> wrote:
On 3/12/07, Andrew Pinski <[EMAIL PROTECTED]> wrote:
> Can I recommend something just crazy, rewrite the C and C++ front-ends
> so they don't use the tree structure at all except when lowering until
> gimple like the rest of the GCC front-end
On 3/12/07, Andrew Pinski <[EMAIL PROTECTED]> wrote:
Can I recommend something just crazy, rewrite the C and C++ front-ends
so they don't use the tree structure at all except when lowering until
gimple like the rest of the GCC front-ends?
The C front end already emits generic, so there's almost
On 3/12/07, Paolo Carlini <[EMAIL PROTECTED]> wrote:
we are unavoidably
adding tree codes and we must solve the issue, one way or another.
Another real solution would perhaps be to not use 'tree' for front end
specific data structures in C++, and instead just define g++ specific
data structures
On 3/12/07, Paolo Carlini <[EMAIL PROTECTED]> wrote:
Hi,
just wanted to say explicitely that I'm supporting completely Doug'
efforts at fixing this issue. Well, I'm a little biased, because I'm
working on C++/26099 and I will need at least one new tree code, but
that's not the point, the point i
Hi,
just wanted to say explicitely that I'm supporting completely Doug'
efforts at fixing this issue. Well, I'm a little biased, because I'm
working on C++/26099 and I will need at least one new tree code, but
that's not the point, the point is that where we are implementing C++0x
features an
On Monday 12 of March 2007 19:47:21 Mark Mitchell wrote:
> * PR 29906 (Oliva) -- This is a crash during DWARF generation for a
> small C++ test case.
+= PR 29202.
ps).
the PR 30052 (aliasing related) is still unconfirmed.
On 3/12/07, Steven Bosscher <[EMAIL PROTECTED]> wrote:
On 3/12/07, David Edelsohn <[EMAIL PROTECTED]> wrote:
> I thought that the Tuples conversion was suppose to address this
> in the long term.
The tuples conversion is only going to make things worse in the short term.
Doug, isn't the
On Mar 12, 2007, at 11:13 AM, Doug Gregor wrote:
With the introduction of the variadic templates patch, we now have
more than 255 tree codes in GCC.
I do wonder about compilation speed for C++ code. Barring some other
innovative approach, even with a slow down, which I'd hate, I think
this
Dave Korn wrote:
Was this description perhaps written in pre-RISC days?
Yes. You can find identical text in the gcc-1.42 documentation, when
almost every port was a CISC.
The docs in rtl.texi for the call expression is a bit clearer about the
intent here for FUNCTION_MODE.
--
Jim Wilson
Ulrich Weigand wrote:
> Mark Mitchell wrote:
>
>> * PR 28544 (Brook, Weigand) -- this is an ARM ICE which Paul has tracked
>> to reload, but he's not sure what to do there. Perhaps Ulrich can help.
>
> This description doesn't appear to match the bugzilla record. Maybe you're
> referring to PR
On 3/12/07, David Edelsohn <[EMAIL PROTECTED]> wrote:
I thought that the Tuples conversion was suppose to address this
in the long term.
The tuples conversion is only going to make things worse in the short term.
Doug, isn't there a lang_tree bit you can make available, and use it
to m
Mark Mitchell wrote:
> * PR 28544 (Brook, Weigand) -- this is an ARM ICE which Paul has tracked
> to reload, but he's not sure what to do there. Perhaps Ulrich can help.
This description doesn't appear to match the bugzilla record. Maybe you're
referring to PR 28675? I can have a look at that
On 3/12/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
Here are some GCC 4.2.0 P1s which I think it would be good for GCC to
have resolved before the release, together with names of people I'd like
to volunteer to help. (Naturally, I have no command authority, and I'd
encourage anyone else who wan
On 3/12/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
* PR 30132 (Pinski, Berlin) -- This is an aliasing crash on complex
numbers. Andrew, you mentioned you might have a patch.
Yes I have a patch but I need to go back and look at the sources
again, I can get to this bug tomorrow as the sources
Here are some GCC 4.2.0 P1s which I think it would be good for GCC to
have resolved before the release, together with names of people I'd like
to volunteer to help. (Naturally, I have no command authority, and I'd
encourage anyone else who wants to help to pitch in, but I'm trying to
tap a few lik
I thought that the Tuples conversion was suppose to address this
in the long term.
David
"Doug Gregor" <[EMAIL PROTECTED]> writes:
Am I the only one to receive Doug's recent messages with empty body?
-- Gaby
[This is a re-send of my previous e-mail; my apologies, yet again, for
the e-mail mangling on my end. Those responsible have been sacked.]
With the introduction of the variadic templates patch, we now have
more than 255 tree codes in GCC. This causes the mainline
Objective-C++ compiler to fail to
On 3/12/07, Andrea Callia D'Iddio <[EMAIL PROTECTED]> wrote:
Great! thank you! I tested with your code and it works... but I'm
still a bit confused.
Could you help me with this simple example?
Suppose that I obtained a tree structure with the following command:
tree stmt = bsi_stmt (si);
and su
Ross Ridge wrote:
> Any library that needs to be able to be called from VisualBasic 6 or some
> other "stdcall only" environment should explictly declare it's exported
> functions with the stdcall calling convention.
Tobias Burnus writes:
> Thus, if I understood you correctly, you recommend that w
On Mon, Mar 12, 2007 at 05:27:21PM +0100, Richard Guenther wrote:
> Most of the problems are fixed, dealII remains with:
>
> /gcc/spec/sb-balakirew-head-64-2006/x86_64/install-hack/bin/g++ -c -o
> quadrature.o -DSPEC_CPU -DNDEBUG -Iinclude -DBOOST_DISABLE_THREADS
> -Ddeal_II_dimension=3 -O2 -D
Great! thank you! I tested with your code and it works... but I'm
still a bit confused.
Could you help me with this simple example?
Suppose that I obtained a tree structure with the following command:
tree stmt = bsi_stmt (si);
and suppose I want to execute the following task:
For each tree sta
On 3/3/07, Grigory Zagorodnev <[EMAIL PROTECTED]> wrote:
Hi,
Trunk GCC shows massive (2 compile-time and 6 run-time) failures on SPEC
CPU2000 and CPU2006 at i386 and x86_64 on -O2 optimization level.
Regression introduced somewhere between revision 122487 and 122478.
There are three checkins, ca
On Mon, Mar 12, 2007 at 08:32:43AM -0400, Jack Howarth wrote:
> - else if (decl_readonly_section_1 (exp, reloc, MACHOPIC_INDIRECT))
> + else if (decl_readonly_section (exp, reloc))
Not just that. Try this.
* config/darwin.c (machopic_reloc_rw_mask): New.
(machopic_select_sect
On 3/12/07, Andreas Krebbel <[EMAIL PROTECTED]> wrote:
Hi,
gcc currently doesn't boostrap on s390 and s390x:
See http://gcc.gnu.org/ml/gcc-bugs/2007-03/msg00930.html
Gr.
Steven
Hi,
gcc currently doesn't boostrap on s390 and s390x:
/build2/gcc-4.3-build/s390x-ibm-linux-gnu/libstdc++-v3/include/bits/locale_facets.tcc:2025:
internal compiler error: in cse_find_path, at cse.c:5930
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.
Andrea Callia D'Iddio wrote on 12/03/2007 16:56:53:
> Hi all,
> i have a very little question for you. I have a basic block and by a
> statement iterator i can obtain a tree structure in the following
> manner:
> tree stmt = bsi_stmt (si);
> I want to use this tree structure to manipulate
[EMAIL PROTECTED] wrote on 12/03/2007 16:56:53:
> Hi all,
> i have a very little question for you. I have a basic block and by a
> statement iterator i can obtain a tree structure in the following
> manner:
> tree stmt = bsi_stmt (si);
> I want to use this tree structure to manipulate t
>On 3/12/07, Unruh, Erwin <[EMAIL PROTECTED]> wrote:
>> In a private port I had the problem that reg_equiv_alt_mem_list did
>> contain the same RTL as reg_equiv_memory_loc. This caused an assert
in
>> delete_output_reload, where these are compared with equal_rtx_p.
>> The list is build with push_
Hi all,
i have a very little question for you. I have a basic block and by a
statement iterator i can obtain a tree structure in the following
manner:
tree stmt = bsi_stmt (si);
I want to use this tree structure to manipulate the statement, for
example i 'd like to know if
It would seem we need to change...
Index: gcc/config/darwin.c
===
/usr/local/bin/gccdiff: line 1: i#!/bin/bash: No such file or directory
--- gcc/config/darwin.c (revision 122839)
+++ gcc/config/darwin.c (working copy)
@@ -1112,7 +
On 3/12/07, Unruh, Erwin <[EMAIL PROTECTED]> wrote:
In a private port I had the problem that reg_equiv_alt_mem_list did
contain the
same RTL as reg_equiv_memory_loc. This caused an assert in
delete_output_reload,
where these are compared with equal_rtx_p.
The list is build with push_reg_equiv_alt
In a private port I had the problem that reg_equiv_alt_mem_list did
contain the
same RTL as reg_equiv_memory_loc. This caused an assert in
delete_output_reload,
where these are compared with equal_rtx_p.
The list is build with push_reg_equiv_alt_mem, but only when "tem !=
orig". The
value tem is bu
55 matches
Mail list logo
