Hello,
The configure changes on the trunk require GMP 4.1+ and MPFR 2.2+. If
I understand things correctly, these libraries are only needed for
gfortran. Would it be possible to disable the checks for GMP and MPFR
when building with --enable-languages=[something not including
fortran] ?
On 11/7/06, Richard Kenner <[EMAIL PROTECTED]> wrote:
> typedef int foo;
> typedef foo* foo_p;
>
> In a truly canonical type-node environment, "foo" would have the same
> type node as "int" (so we couldn't produce the name "foo" in
> diagnostics), and "foo_p" would have the same type
On 11/7/06, Dale Johannesen <[EMAIL PROTECTED]> wrote:
On Nov 7, 2006, at 11:47 AM, Douglas Gregor wrote:
> I just read Nathan's discussion [1] on changing GCC's type system
> to use canonical type nodes, where the comparison between two types
> requires only a pointer comparison. Right now, we
On 11/7/06, Mike Stump <[EMAIL PROTECTED]> wrote:
Anyway, in C++, the entire template mechanism was rife with building
up duplicates. I'd propose that this problem can (and should be
addressed) and that we can do it incrementally. Start with a hello
world, then in comptypes, check to see when i
On 11/8/06, Mike Stump <[EMAIL PROTECTED]> wrote:
On Nov 7, 2006, at 7:13 PM, Doug Gregor wrote:
> Now, how much do we worry about the fact that we won't be printing
> typedef names
The only potential language gotcha I can think of is:
5 If the typedef declaration defines
On 11/9/06, Mike Stump <[EMAIL PROTECTED]> wrote:
On Nov 8, 2006, at 5:59 AM, Doug Gregor wrote:
> However, this approach could have some odd side effects when there are
> multiple mappings within one context. For instance, we could have
> something like:
>
> typedef int
On 08 Nov 2006 03:45:26 +0100, Gabriel Dos Reis
<[EMAIL PROTECTED]> wrote:
[EMAIL PROTECTED] (Richard Kenner) writes:
| > Like when int and long have the same range on a platform?
| > The answer is they are different, even when they imply the same object
| > representation.
| >
| > The notion of
On 10 Nov 2006 19:15:45 +0100, Gabriel Dos Reis
<[EMAIL PROTECTED]> wrote:
"Doug Gregor" <[EMAIL PROTECTED]> writes:
| With concepts, there are cases where we end up creating two different
| type nodes that we later find out should have been the same type nod
On 10 Nov 2006 20:12:27 +0100, Gabriel Dos Reis
<[EMAIL PROTECTED]> wrote:
"Doug Gregor" <[EMAIL PROTECTED]> writes:
I don't see why you need to merge the types, as opposed to setting
their canonical types.
I have union-find on the mind, so I'm using the term
On 11/22/06, Mike Stump <[EMAIL PROTECTED]> wrote:
ensure if doesn't fall over, if you structure it that way, however,
if instead you just warn:
[snip code using warnings]
or even maybe just a note, it'll make it just a bit safer in the
short term. People can then watch for these messages and
rt one of three, containing changes to the parts of the
compiler that are shared amount the C family of languages.
Okay for mainline?
Cheers,
Doug Gregor
Open Systems Lab @ Indiana University
2006-11-28 Douglas Gregor <[EMAIL PROTECTED]>
* builtins.c (std_gimplify_va_arg_ex
This patch introduces canonical types into GCC; see the first part of
this patch for a complete description.
This is part two of three, containing changes to the C++ front end.
Okay for mainline?
Cheers,
Doug Gregor
Open Systems Lab @ Indiana University
2006-11-28 Douglas Gregor <[EM
This patch introduces canonical types into GCC. See the first part of
this patch for a complete explanation.
This is part three of three, containing changes to the Objective-C
(and, thus, Objective-C++) front end.
Okay for mainline?
Cheers,
Doug Gregor
Open Systems Lab @ Indiana University
[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, 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 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
Hi Mike,
[I'm replying in this thread to the Objective-C patch you posted in
the type-traits discussion, because both that post and this one are
about reducing the number of tree codes]
On 3/13/07, Mike Stump <[EMAIL PROTECTED]> wrote:
I just converted the Objective-C front-end to free up enoug
On 3/14/07, Richard Guenther <[EMAIL PROTECTED]> wrote:
#define LANG_TYPE_CODE (t) (TREE_CODE (t) == LANG_TYPE ?
LANG_TYPE_SUBCODE (t) : INVALID_SUBCODE)
and then INVALID_SUBCODE will fall through to the default case as well.
But that doesn't put the subcodes and the codes into the same
"names
On 3/12/07, Richard Kenner <[EMAIL PROTECTED]> wrote:
> 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 th
On 3/19/07, Steven Bosscher <[EMAIL PROTECTED]> wrote:
On 3/19/07, Doug Gregor <[EMAIL PROTECTED]> wrote:
> I went ahead and implemented this, to see what the real impact would
> be. The following patch frees up TREE_LANG_FLAG_5, and uses that extra
> bit for the tree
On 3/19/07, Nicholas Nethercote <[EMAIL PROTECTED]> wrote:
As an interested outsider: GCC's compile-time speed has been gradually
decreasing for a while now. It seems to be acknowledged as an undesirable
thing, but not much has happened to change it. AIUI, this is largely
because it's very dif
On 19 Mar 2007 19:12:35 -0500, Gabriel Dos Reis <[EMAIL PROTECTED]> wrote:
similar justifications for yet another small% of slowdown have been
given routinely for over 5 years now. small% build up; and when they
build up, they don't not to be convincing ;-)
But what is the solution? We can com
On 3/20/07, Brooks Moses <[EMAIL PROTECTED]> wrote:
Steven Bosscher wrote:
> On 3/20/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
>> I think it's fair for front ends to pay for their
>> largesse. There are also relatively cheap changes in the C++ front end
>> to salvage a few codes, and postpon
On 3/20/07, Jakub Jelinek <[EMAIL PROTECTED]> wrote:
On Tue, Mar 20, 2007 at 08:56:10AM -0400, Kaveh R. GHAZI wrote:
> We've been considering two solutions, the 9 bit codes vs the subcode
> alternative.
>
> The 9 bit solution is considered simpler and without any memory penalty
> but slows down t
On 3/20/07, Steven Bosscher <[EMAIL PROTECTED]> wrote:
On 3/20/07, Doug Gregor <[EMAIL PROTECTED]> wrote:
> > So the memory hit shouldn't be
> > as big as e.g. going to 16 bit tree codes if that means increasing the size
> > of most of the trees the compile
On 3/20/07, Kaveh R. GHAZI <[EMAIL PROTECTED]> wrote:
Would you please consider testing the 16 bit tree code as you did for 8 vs
9 bits? Perhaps you could also measure memory usage for all three
solutions?
I've measured the 8 vs. 9-bit solutions: they have identical memory footprints.
I thi
On 3/20/07, Dan Nicolaescu <[EMAIL PROTECTED]> wrote:
"Doug Gregor" <[EMAIL PROTECTED]> writes:
> On 3/20/07, Kaveh R. GHAZI <[EMAIL PROTECTED]> wrote:
> > Would you please consider testing the 16 bit tree code as you did for 8 vs
> > 9 bits?
On 20 Mar 2007 17:04:56 -0500, Gabriel Dos Reis <[EMAIL PROTECTED]> wrote:
That defered parsing might work with C (I don't really know), but it
certainly is problematic with C++ because there are bindings that
need to be in overload sets, and you cannot accurately capture those if
you don't parse
On 3/21/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
Yes, that's true. Here, however, we have two paths in front of us:
9-bit tree codes, or some language-dependent subcodes. The benefit of
9-bit tree codes is that they're easy to understand; the benefit of
subcodes is that they might be faster
On 3/22/07, Steven Bosscher <[EMAIL PROTECTED]> wrote:
On 3/22/07, Doug Gregor <[EMAIL PROTECTED]> wrote:
> The results, compile time:
For what test case?
All the numbers I've reported are for tramp3d, compiled with -O2
-funroll-loops -ffast-math on i686-pc-linux-gnu.
On 3/22/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
Doug, thanks for doing all the experiments!
OK, we've got to pick our poison.
1. We can go to 9-bit codes. They're slower, independent of checking.
Maybe we can make bitfields go faster, and get some of that back. Of
course, if we can make
On 3/23/07, Kaveh R. GHAZI <[EMAIL PROTECTED]> wrote:
When I brought up the 16-bit option earlier, Jakub replied that x86 would
get hosed worse because it's 16-bit accesses are not as efficient as it's
8 or 32 bit ones.
http://gcc.gnu.org/ml/gcc/2007-03/msg00763.html
I assume you tested on Darw
Hello,
What is the protocol for confirming, taking ownership of, and closing
bug reports in Bugzilla? I'd like to close out some bugs for which
I've already committed the patches (20599 and 29993, at least) and
take ownership of several others, but I am unable to do anything but
comment on the bu
On 28 Mar 2007 07:21:13 -0700, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
> What is the protocol for confirming, taking ownership of, and closing
> bug reports in Bugzilla? I'd like to close out some bugs for which
> I've already committed the patches (20599 and 29993, at least) and
> take owner
Hello,
I have just created a new branch for development of C++0x-specific
features in the GNU C++ front end. The branch is branches/cxx0x-branch
in Subversion, and information about this branch is available at
http://gcc.gnu.org/projects/cxx0x.html.
The intent of this branch is to collect all of
A question for the C++ maintainers considering the lvalue-ness of
NON_DEPENDENT_EXPR expressions...
As part of tightening up our checking of non-dependent expressions
within templates (and necessary step for C++0x, and a good idea in
C++98 anyway), I bumped into this bit of code in lvalue_p_1:
Hello Brian,
How does this compare to GCC-XML?
http://www.gccxml.org/HTML/Index.html
- Doug
On Jan 4, 2008 10:42 AM, Brian M. Ames <[EMAIL PROTECTED]> wrote:
> Hello,
>
> I have substantially completed an extension that would allow dumps to be
> emitted as XML. I would like to contribute i
On Dec 19, 2007 3:02 PM, <[EMAIL PROTECTED]> wrote:
> My specific candidate for exclusion from -Wall is this one:
>
> if (a && b || c && d)
>
> which yields (as you know) advice to parenthesize the two && pairs.
To make this discussion a bit more concrete, the attached patch
removes this
PR c++/34935 illustrates a problem with the way attributes interact
with type identity. The example in question looks something like this:
typedef int X __attribute((may_alias));
void foo(X);
void foo(int);
The fundamental question here is whether 'X' is a new type distinct
from 'int', or
On Jan 24, 2008 11:41 AM, Jakub Jelinek <[EMAIL PROTECTED]> wrote:
> On Thu, Jan 24, 2008 at 04:06:47PM +0100, Richard Guenther wrote:
> > On Jan 24, 2008 3:58 PM, Doug Gregor <[EMAIL PROTECTED]> wrote:
> > The middle-end type system (useless_type_conversion_p) says t
On Jan 21, 2008 8:08 PM, Benjamin Kosnik <[EMAIL PROTECTED]> wrote:
> Jason Merrill, Doug Gregor, and I invite all interested GCC hackers to
> discuss implementation of the compiler and library parts of the
> C++0x concepts proposals. This is to be a brainstorming session, where
&
On Jan 27, 2008 8:23 PM, Gerald Pfeifer <[EMAIL PROTECTED]> wrote:
> On Fri, 25 Jan 2008, Doug Gregor wrote:
> > Organization:
> > - We'll start a fresh branch in the FSF repository dedicated to concepts
> >(it's branches/cxx0x-concepts-branch). Ini
On Mon, Jan 28, 2008 at 5:22 AM, Richard Guenther <[EMAIL PROTECTED]> wrote:
>
> Status
> ==
>
> We are in Stage 3 and the trunk is open for regression and documentation
> fixes only. When we reach zero open P1 regressions, we will create a
> release candidate for 4.3.0, branch and announ
On Mon, Jan 28, 2008 at 5:38 PM, Gerald Pfeifer <[EMAIL PROTECTED]> wrote:
> On Sun, 27 Jan 2008, Doug Gregor wrote:
> > I was planning to kill the cxx0x-branch outright, because it has
> > nothing that isn't available on mainline (except a not-nearly-complete
&g
On Feb 18, 2008 6:18 PM, Jakub Jelinek <[EMAIL PROTECTED]> wrote:
> Hi!
>
> As I've mentioned last week, I've created branches/gcc-4_3-branch.
> The trunk is now 4.4 stage 1, the branch is open for regression bugfixes
> and documentation fixes only, but additionally all checkings require
> RM appro
I see that it is time to submit applications to be a mentor
organization for the Google Summer of Code. I've updated the GSoC wiki
page at:
http://gcc.gnu.org/wiki/SummerOfCode
with a class of projects I'm interested in; others should do the same.
I'll be happy to mentor C++0x projects for GCC
I see that it is time to submit applications to be a mentor
organization for the Google Summer of Code. I've updated the GSoC wiki
page at:
http://gcc.gnu.org/wiki/SummerOfCode
with a class of projects I'm interested in; others should do the same.
I'll be happy to mentor C++0x projects for GCC
Hello,
On Wed, Mar 19, 2008 at 4:23 AM, Lukas Mai <[EMAIL PROTECTED]> wrote:
> I'm having problems with g++-4.3.0 and C++0x. Disclaimer: I don't
> understand rvalue references, but since I need (indirect) argument
> forwarding, I copied and modified an example from the web.
> (I believe detail
On Fri, May 2, 2008 at 11:39 AM, Peter Collingbourne <[EMAIL PROTECTED]> wrote:
> In the C++ frontend, record_types maintain list(s) of the parameters
> which were used to instantiate the type, one list for each "level" of
> the instantiation. I would like to know how to determine the list of
>
On Wed, Jun 18, 2008 at 2:01 AM, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
> As I promised at the summit today, I have created the branch
> gcc-in-cxx (I originally said gcc-in-c++, but I decided that it was
> better to avoid possible meta-characters). The goal of this branch is
> to develop a v
On Wed, Jun 25, 2008 at 10:49 AM, Tom Tromey <[EMAIL PROTECTED]> wrote:
>> "Daniel" == Daniel Jacobowitz <[EMAIL PROTECTED]> writes:
>
>>> On Wed, Jun 25, 2008 at 08:35:41AM -0600, Tom Tromey wrote:
>>> I think most of the needed changes will be in gengtype. If you aren't
>>> familiar with wha
On Mon, Jul 14, 2008 at 7:20 PM, Benjamin Kosnik <[EMAIL PROTECTED]> wrote:
> In particular, design. The using bits seem pretty straightforward. It
> would be nice if you could provide some detail in terms of scope (what
> are the algorithms or data structures you intend to instrument),
> and how t
I'm CC'ing Howard, the master of the rvalue reference, and Russell,
the author of the rvalue references patch... see below for my take on
this.
On 5/7/07, Sylvain Pion <[EMAIL PROTECTED]> wrote:
I have done some experiments with the rvalue reference feature on the
cxx0x-branch.
Great!
I am
On 6/16/07, michael.a <[EMAIL PROTECTED]> wrote:
You are of course free to demonstrate how placement new could circumnavigate
the need of unions.
Boost.Variant implements discriminated unions using placement new:
http://www.boost.org/doc/html/variant.html
Of course, you would have to mimic t
On 7/12/07, Basile STARYNKEVITCH <[EMAIL PROTECTED]> wrote:
Mark Mitchell wrote:
> 3. After GCC 4.2.1 is released, we will renumber the branch to GCC 4.3.
> What would have been GCC 4.2.2 will instead be GCC 4.3.3, to try to
> emphasize the GPLv3 switch. The GCC mainline will then be GCC 4.4.
On 7/12/07, David Edelsohn <[EMAIL PROTECTED]> wrote:
>>>>> Doug Gregor writes:
Doug> Could we ask the SC to reconsider the change in the GCC major version
Doug> numbering for GPLv3? Or, at the very least, explain why it is
Doug> important to change the major ver
On 7/12/07, Dave Korn <[EMAIL PROTECTED]> wrote:
On 12 July 2007 15:29, Doug Gregor wrote:
> I had the same reaction. A new major release of GCC
Ok, hadn't you better both stop right there. "Major" release?
"significantly" affect the version numbering? W
Hi Richard,
On 7/26/07, Richard Smith <[EMAIL PROTECTED]> wrote:
About five years ago, I reported a bug about an ICE when
trying to mangle expressions involving operator new.
http://gcc.gnu.org/ml/gcc-patches/2002-03/msg01417.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6057
A three l
On 7/26/07, Richard Smith <[EMAIL PROTECTED]> wrote:
Doug Gregor wrote:
> This kind of thing came up that the last C++ committee meeting, as
> part of core issue 339:
>
> http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#339
>
> Name mangling is part of the pr
On 7/26/07, Richard Smith <[EMAIL PROTECTED]> wrote:
template
class is_default_constructible {
template struct helper {};
typedef char no; typedef char yes[2];
static no fn(...);
static yes fn( helper* );
public:
static const bool value = sizeof(fn(0)) == sizeof(yes);
We can't seem to decide whether ISO C++ really forbids comparisons
between pointers and integers or not. The first two are for == and !=,
the second two are for <, >, <=, >=. Why the inconsistency?
typeck.c: error ("ISO C++ forbids comparison between pointer
and integer");
typeck.c:
For the last few days I've been unable to make or bootstrap on
i386-apple-darwin8.10.1. It doesn't seem to be a problem on my
Core2-based Mac Pro, but on my Intel Core Duo (MacBook Pro) the build
fails with the error message below.
Perhaps we're trying to use Core2-only instructions on this platfo
On 10/2/07, Jack Howarth <[EMAIL PROTECTED]> wrote:
> The fink packaging for gcc42/gcc43 builds fine on Macintel when we use...
>
> --with-arch=nocona --with-tune=generic --host=i686-apple-darwin8
This gets further, failing now for a very different reason:
cc -O2 -g -O2 -m64 -O2 -O2 -g -O2
On 11/15/07, Rob Quill <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I was wondering if anyone could help me make sense of the
> more_specialized_fn() function in pt.c (line 13281).
>
> Specifically, I am trying to understand what each of the are:
>
> tree decl1 = DECL_TEMPLATE_RESULT (pat1);
This is the
On Nov 27, 2007 4:19 PM, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> 1. I noticed that there are quite a few P2 ICE reports regarding
>variadic templates. Doug Gregor, would you please look into these?
There are patches for a few of these issues (two P2s and a P3) that
still need
On Dec 19, 2007 3:02 PM, <[EMAIL PROTECTED]> wrote:
> One last point. In looking for the rationale behind this warning, I searched
> for examples of it. I didn't find any discussion on this list. What I did
> find were many examples of people rototilling perfectly fine code, "improving"
> it by
67 matches
Mail list logo
