On Mon, Sep 10, 2012 at 10:41 AM, Aaron Gray wrote:
> What I am looking to obtain is isolating the C++ parser with no real
> semantic changes, just isolating the interfaces in order that the
> parser be reusable as a library component and allow migration to other
> solutions.
Yes, for that, you
On Wed, Sep 12, 2012 at 11:50 AM, Diego Novillo wrote:
> Alternately, we could use Richi's approach I suppose (what happened to that
> patch, btw)?
I was under the impression that the patch was good to go in; Richard?
-- Gaby
On Sat, Sep 22, 2012 at 4:36 PM, Marc Glisse wrote:
> Are you looking for gcc-h...@gcc.gnu.org?
>
> mpc-devel ? (not my platform, I don't even know if that package exists, but
> your grep pattern excludes such a package)
yes, it is "mpc-devel" on suse.
one needs the "-devel" packages of all the
On Sat, Sep 22, 2012 at 5:58 PM, Bruce Korb wrote:
> On 09/22/12 15:02, Gabriel Dos Reis wrote:
>> On Sat, Sep 22, 2012 at 4:36 PM, Marc Glisse wrote:
>>> Are you looking for gcc-h...@gcc.gnu.org?
>>
>>> mpc-devel ? (not my platform, I don't even know if
On Sat, Oct 6, 2012 at 1:59 PM, _ wrote:
> Now obviously you can't put stl everywhere.
True. Did you send in a patch to review?
-- Gaby
On Sat, Oct 6, 2012 at 7:47 PM, _ wrote:
> You will probably kill me for this. But no such patch yet exists.
> I am kinda trying findout wheter there is interest in such experiment
> and find some help since to me alone it would take ages.
> But I love to see that you are interested. It really is
On Sat, Oct 20, 2012 at 12:53 AM, Chandler Carruth wrote:
> On Fri, Oct 19, 2012 at 10:04 PM, Richard Smith wrote:
>>
>> [Crossposted to both GCC and Clang dev lists]
>>
>> Hi,
>>
>> One issue facing library authors wanting to use C++11's constexpr feature is
>> that the same implementation must
On Sat, Oct 20, 2012 at 2:24 PM, Jordan Rose wrote:
> While throwing things out there, why not just optionally allow constexpr
> functions to coexist with non-constexpr functions of the same name, like
> inline and non-inline?
Or remove most of the restrictions on constexpr functions that were
On Sat, Oct 20, 2012 at 10:23 PM, Richard Smith wrote:
>> Allow loops and the like in constexpr functions and be done with it. See my
>> comments on the C++ Extension Working Group when these (and related)
>> issues where brought up.
>
> Yes, I completely agree, but I don't think this solves the
On Thu, Nov 15, 2012 at 8:48 AM, Michael Matz wrote:
[...]
> The method name should imply the action, e.g. 'add_stmt' or append_stmt
> or the like.
strongly agreed.
[...]
> All in all I think we can severely improve on building gimple statements
> without introduction of any helper class. Basic
On Fri, Nov 16, 2012 at 9:42 AM, Andrew MacLeod wrote:
> PS I'd also prefer the term 'memory pool' or something... the term 'obstack'
> still makes my skin crawl :-)
Amen.
-- Gaby, old enough to remember the obstack days
On Sat, Nov 17, 2012 at 1:33 PM, Xinliang David Li wrote:
> My main point is that other main open source compilers like
> clang/llvm, open64 and some main commercial compilers I know do not
> use GC, which proves that GC is not a must for a compiler to be easy
> to work with or to be a good open
On Tue, Nov 20, 2012 at 6:16 PM, Lawrence Crowl wrote:
> And, as a side note, highly formatted output generally is not
> much better than printf. For any text that needs to be localized,
> I recommend that we stick with what we have.
I agree with Lawrence that for texts that need localization,
On Tue, Nov 20, 2012 at 7:01 PM, Xinliang David Li wrote:
> Right -- gdb does not know the complete type of std::cout and
> std::cerr -- try the following program with -g and invoke print, or <<
> in the debugger -- see what you will get:
Is this because the hack we (libstdc++ folks) used to defi
On Wed, Nov 21, 2012 at 5:37 AM, Theodore Papadopoulo
wrote:
> On 11/21/2012 02:01 AM, Xinliang David Li wrote:
>>
>> Right -- gdb does not know the complete type of std::cout and
>> std::cerr -- try the following program with -g and invoke print, or <<
>> in the debugger -- see what you will get:
On Wed, Nov 21, 2012 at 7:07 AM, Tobias Grosser wrote:
> On 11/20/2012 08:32 PM, Basile Starynkevitch wrote:
>>
>> On Tue, Nov 20, 2012 at 11:24:40AM -0800, Lawrence Crowl wrote:
>> []
>
> All of these functions come in two forms.
>
> function (FILE *, item_to_dump, forma
On Wed, Nov 21, 2012 at 7:48 AM, Tobias Grosser wrote:
> Is it correct to state that every translation unit that includes iostream
> will include the iostream static constructors?
C++ requires the definitions of globals such as std::cin, std::cout,
and std::cerr
that must be contructed (by any m
ter. Said, differently, the worry
about IOStreams introducing unnecessary "static
constructor" is either overblown or misplaced, or both.
-- Gaby
On Wed, Nov 21, 2012 at 8:25 AM, Gabriel Dos Reis
wrote:
> On Wed, Nov 21, 2012 at 7:48 AM, Tobias Grosser wrote:
>
>> Is it correct to s
On Wed, Nov 21, 2012 at 9:02 AM, Ian Lance Taylor wrote:
> On Wed, Nov 21, 2012 at 3:18 AM, Gabriel Dos Reis
> wrote:
>> On Tue, Nov 20, 2012 at 6:16 PM, Lawrence Crowl wrote:
>>
>>> And, as a side note, highly formatted output generally is not
>>> much be
On Thu, Nov 22, 2012 at 12:18 PM, Lawrence Crowl wrote:
> I have found that tree-flow.h implements iteration over htab_t,
> while there is no current facility to do that with hash_table.
> Unfortunately, the specific form does not match the standard C++
> approach to iterators. We have several ch
On Sat, Nov 24, 2012 at 11:13 AM, Ian Lance Taylor wrote:
> 2) The fact that Android refuses to provide a non-HTML e-mail capability
> is ridiculous but does not seem to me to be a reason for us to change
> our policy.
Amen.
Rich texts in technical conversations where people people use
various
On Sun, Nov 25, 2012 at 7:45 AM, Richard Biener
wrote:
> Just to add another case which seems to be not covered in the thread.
> When dumping from inside a gdb session in many cases I cut&paste
> addresses literally. For overloading to work I'd need to write casts
> in front of the inferior call
On Tue, Nov 27, 2012 at 8:54 AM, Tom Tromey wrote:
>>>>>> "Gaby" == Gabriel Dos Reis writes:
>
> Richard> Just to add another case which seems to be not covered in the thread.
> Richard> When dumping from inside a gdb session in many cases I cut
On Wed, Nov 28, 2012 at 3:14 PM, Jonathan Wakely wrote:
> On 28 November 2012 09:03, Jonathan Wakely wrote:
>> On 28 November 2012 07:36, Xinliang David Li wrote:
>>> What you described is the 'transitional model' right? but I don't see
>>> any of those in the C++ standard working paper:
>>> http:
On Wed, Nov 28, 2012 at 6:41 PM, Miles Bader wrote:
> 2012/11/29 Gabriel Dos Reis :
>> My understanding from attending the last C++ standards committee is
>> that we are still way far from having something that gets consensus of
>> good enough proposal on modules to coal
On Wed, Nov 28, 2012 at 7:07 PM, Lawrence Crowl wrote:
> On 11/28/12, Gabriel Dos Reis wrote:
>> On Nov 28, 2012 Miles Bader wrote:
>> > 2012/11/29 Gabriel Dos Reis :
>> > > My understanding from attending the last C++ standards
>> > > committe
On Thu, Nov 29, 2012 at 12:12 PM, Benjamin Kosnik wrote:
>
>
>
>> Assuming that the new implementation will be available in time for 4.9, my
>> primary concern is that in the meanwhile running the libstdc++ testsuite
>> will be quite noticeably slower. Do you have some numbers?
>
>
> Just use th
On Tue, Dec 11, 2012 at 4:14 AM, Richard Biener wrote:
>
> This brings the build-requirements up-to-date with us now requiring
> a C++ host compiler. I optimistically increased the minimum required
> GCC version listed from 2.95 to 3.4 as that is the earliest version
> that could reasonably be ca
On Thu, Jan 24, 2013 at 1:59 PM, Jeff Law wrote:
> On 01/24/2013 12:55 PM, Diego Novillo wrote:
>>
>>
>> I do see, however, a few areas where Clang/LLVM have gone that I do
>> not think GCC is currently thinking of entering: "toolability" (for
>> the lack of a better term). Clang's design follows
On Tue, Mar 5, 2013 at 1:43 PM, Jason Merrill wrote:
> On 03/05/2013 02:28 PM, Lawrence Crowl wrote:
>>
>> Are you planning for C++11 ABI stability in 4.9?
>
>
> Yes. But if mangling bugs are discovered after 4.9, I propose to just fix
> them (as I believe EDG and Clang do) rather than hold them
Ian Lance Taylor <[EMAIL PROTECTED]> writes:
| "Doug Gregor" <[EMAIL PROTECTED]> writes:
|
| > To make this discussion a bit more concrete, the attached patch
| > removes this particular warning from -Wparentheses and puts it into a
| > new warning, -Wprecedence, that is not enabled by -Wall. Thi
Ismail Dönmez <[EMAIL PROTECTED]> writes:
| Hi again,
|
| Wednesday 09 January 2008 00:28:54 tarihinde Manuel López-Ibáñez şunları
| yazmıştı:
| > For your particular example, you could open a regression bug against
| > 4.3 that says:
| > * '"foo' redefined" is not mandated by the standard or it
On Sun, 13 Jan 2008, Ismail Dönmez wrote:
| Sunday 13 January 2008 17:41:03 tarihinde Gabriel Dos Reis sunlar? yazm?st?:
| > Ismail Dönmez <[EMAIL PROTECTED]> writes:
| > | Hi again,
| > |
| > | Wednesday 09 January 2008 00:28:54 tarihinde Manuel López-Ibáñez sunlar?
|
On Sun, 13 Jan 2008, Ismail Dönmez wrote:
| Sunday 13 January 2008 18:40:25 tarihinde Gabriel Dos Reis sunlar? yazm?st?:
| > | real life testcase shows that problem stems from
| > | autoconf and its config.h. Projects end up defining things like
| > | HAVE_STDLIB_H twice which is not h
On Thu, 17 Jan 2008, Taras Glek wrote:
| Major Issue: Specifying TFF_CHASE_TYPEDEFS as a parameter only works with
| top-level typenames because the C/C++ pretty printing code does not
| support/propagate the flags parameter. Is this considered a bug or a TODO?
| Would a patch to move the TFF* fla
On 3 Mar 2008 22:40:21 -, <[EMAIL PROTECTED]> wrote:
> Snapshot gcc-4.1-20080303 is now available on
> ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20080303/
> and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
>
> This snapshot has been generated from the GCC 4.1 SVN bran
On Mon, Mar 3, 2008 at 7:16 PM, Peter A. Felvegi
<[EMAIL PROTECTED]> wrote:
> hello,
>
> i've found this in the known non-bugs list
> (http://gcc.gnu.org/bugs.html#known), after running into the issue. gcc
> 3.4-4.2 gives a compile error, but 4.3 compiles it. is this a
> regression, or the rule
On Fri, Mar 7, 2008 at 10:54 AM, Tom Tromey <[EMAIL PROTECTED]> wrote:
> > "Manuel" == Manuel López-Ibáñez <[EMAIL PROTECTED]> writes:
>
> Manuel> Here is a patch that give us caret diagnostics in C/C++.
>
> Nice.
>
> Manuel> The third approach would be to store an offset and when
> Manuel>
On Fri, Mar 7, 2008 at 11:53 AM, Richard Guenther
<[EMAIL PROTECTED]> wrote:
> On Fri, Mar 7, 2008 at 4:54 PM, Tom Tromey <[EMAIL PROTECTED]> wrote:
> > > "Manuel" == Manuel López-Ibáñez <[EMAIL PROTECTED]> writes:
> >
> > Manuel> Here is a patch that give us caret diagnostics in C/C++.
>
On Fri, Mar 7, 2008 at 9:06 PM, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
> Tom Tromey <[EMAIL PROTECTED]> writes:
>
> > Ian suggested that we delete this information after the FE is
> > finished. This makes sense, I think, from a memory-saving
> > perspective. But, that means we will get di
On 08 Mar 2008 15:39:20 +0100, Andi Kleen <[EMAIL PROTECTED]> wrote:
> Ian Lance Taylor <[EMAIL PROTECTED]> writes:
>
> >Another approach would be to only use the carets for parse errors,
> >which is where they are the most helpful.
>
> And preprocessor if possible
Yes, definitely.
On Wed, Mar 12, 2008 at 7:00 PM, Manuel López-Ibáñez
<[EMAIL PROTECTED]> wrote:
> On 07/03/2008, Tom Tromey <[EMAIL PROTECTED]> wrote:
> > > "Manuel" == Manuel López-Ibáñez <[EMAIL PROTECTED]> writes:
>
> > Manuel> The third approach would be to store an offset and when
> > Manuel> generati
On Wed, Mar 12, 2008 at 11:00 PM, Chris Lattner <[EMAIL PROTECTED]> wrote:
>
>
> On Mar 12, 2008, at 5:07 PM, Manuel López-Ibáñez wrote:
>
> > On 08/03/2008, Chris Lattner <[EMAIL PROTECTED]> wrote:
> >>
> >> clang points into the original input buffer that was lexed from.
> >> This
> >> requ
On Sat, Mar 8, 2008 at 7:36 PM, Gerald Pfeifer <[EMAIL PROTECTED]> wrote:
> On Mon, 3 Mar 2008, Gabriel Dos Reis wrote:
> > Do we still want to keep this branch alive?
>
> Looking at the changes that were made in the last three months still,
> it seems the branch is stil
On Fri, Mar 14, 2008 at 7:31 PM, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
>
> "Gabriel Dos Reis" <[EMAIL PROTECTED]> writes:
>
> > On Sat, Mar 8, 2008 at 7:36 PM, Gerald Pfeifer <[EMAIL PROTECTED]> wrote:
> >> On Mon, 3 Mar 2008, Gabriel Do
First, many thanks to Ian for stepping forward to make this happen.
On Thu, Jun 19, 2008 at 1:55 AM, Kaveh R. GHAZI <[EMAIL PROTECTED]> wrote:
> On Thu, 19 Jun 2008, Kaveh R. GHAZI wrote:
>
>> [...] I believe some work could be done (maybe even on mainline) to
>> activate -Wc++-compat during boots
On Thu, Jun 19, 2008 at 3:10 AM, Kaveh R. GHAZI <[EMAIL PROTECTED]> wrote:
> On Thu, 19 Jun 2008, Gabriel Dos Reis wrote:
>
>> Main offenders (last time I checked) seem be to
>> (1) middle end and back end files who play `enum inheritance' tricks.
>> (2) us
On Wed, Jun 18, 2008 at 1: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 Thu, Jun 19, 2008 at 7:24 AM, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
>> The reason I'm asking is that a fresh build o gcc-in-cxx dies on my machine
>> with
>> complains that `program' has conflicting declarations: once in
>> libcpp.h as having
>> C++ linkage, once in toplev.h with a C dec
On Thu, Jun 19, 2008 at 5:08 PM, Jonathan Wakely <[EMAIL PROTECTED]> wrote:
> 2008/6/18 Mark Mitchell:
>>> * I don't think the pedwarn in joust() in cp/call.c should be a
>>> permerror, is this a GNU extension?
>>> if (warn)
>>>{
>>> pedwarn ("\
>>> ISO C++ says th
On Sun, Jun 22, 2008 at 6:24 PM, Bruno Haible <[EMAIL PROTECTED]> wrote:
> Dear Ian,
>
> A comment regarding the GCC-in-C++ idea. In slide 16 you merely answer
>
> "C++ is too complicated!"
>
> with
>
> "Maintainers will ensure that gcc continues to be maintainable."
>
> C++ has, for example, 12
On Mon, Jun 23, 2008 at 6:14 AM, Bruno Haible <[EMAIL PROTECTED]> wrote:
> Arnaud Charlet wrote:
>> One possibility is to do what we do for Ada: have a style/coding checker
>> built into the compiler (C++ front-end) as a special switch, and enable this
>> switch during bootstrap, so that any such c
On Tue, Jun 24, 2008 at 5:47 AM, Bruno Haible <[EMAIL PROTECTED]> wrote:
> Gabriel Dos Reis wrote:
>> There is a subset of C++ templates stable enough over the years, that can be
>> used without fear, uncertainty and doubt.
>
> Absolutely. Can you specify this "
On Tue, Jun 24, 2008 at 6:20 AM, Bruno Haible <[EMAIL PROTECTED]> wrote:
>
> What is the level of C++ that "new developers" need to master, in order to
> understand the code in general and to fix bugs in average areas?
>
> Bruno
What is covered in `Accelerated C++' by A. Koenig should be enough, I
On Wed, Jun 25, 2008 at 9:04 AM, Basile STARYNKEVITCH
<[EMAIL PROTECTED]> wrote:
> Chris Jefferson wrote:
>>
>> Could someone point me towards what is necessary to add STL containers
>> to the garbage collector?
>>
>> One big problem with garbage collecting in C++ is the need to run
>> destructors.
On Wed, Jun 25, 2008 at 9:49 AM, Andrew Haley <[EMAIL PROTECTED]> wrote:
> Richard Guenther wrote:
>> On Wed, Jun 25, 2008 at 4:04 PM, Andrew Haley <[EMAIL PROTECTED]> wrote:
>>> Hans-Peter Nilsson wrote:
> Date: Tue, 24 Jun 2008 10:36:15 +0100
> From: Andrew Haley <[EMAIL PROTECTED]>
>
On Wed, Jun 25, 2008 at 10:43 AM, Andrew Haley <[EMAIL PROTECTED]> wrote:
> Gabriel Dos Reis wrote:
>> On Wed, Jun 25, 2008 at 9:49 AM, Andrew Haley <[EMAIL PROTECTED]> wrote:
>>> Richard Guenther wrote:
>
>>> The C++ standard calls this a type pun, so
On Wed, Jun 25, 2008 at 10:48 AM, Andrew Pinski <[EMAIL PROTECTED]> wrote:
> On Wed, Jun 25, 2008 at 8:38 AM, Richard Guenther
> <[EMAIL PROTECTED]> wrote:
>> Hmmm, does C++0x add some type-reflection? ;)
>
> Yes but I don't see how we can use it in C++03/C++98 code. Compiling
> GCC 4.5 (or 5.0) w
>
> Meantime, patch below bootstrapped with --with-gc=zone on
> x86_64-unknown-linux-gnu. Okay for mainline?
>
yes, this looks good.
Thanks for doing this.
-- Gaby
On Fri, Jul 4, 2008 at 11:02 AM, Pádraig Brady <[EMAIL PROTECTED]> wrote:
> While trying to compile coreutils with -Wextra,
> I noticed many warnings due to automatic variables
> initialized with { 0, }.
>
> As I understand it, since C90 the above will initialize
> [all members of] the type to that
On Mon, Jul 7, 2008 at 4:48 AM, Dave Korn <[EMAIL PROTECTED]> wrote:
> Kaveh R. GHAZI wrote on 06 July 2008 23:36:
>
>> * gcc.c (execute): Fix -Wc++-compat warning.
>
>
> Kaveh, am I right in inferring from recent list traffic that you've taken
> on a whole load of c-vs-c++ compatibility wor
On Tue, Jul 8, 2008 at 3:48 AM, Angelo Graziosi
<[EMAIL PROTECTED]> wrote:
> Ian Lance Taylor ha scritto:
>>
>> This is OK, with a ChangeLog entry, if it passes bootstrap with the
>> appropriate configure option.
>
>
> The following bootstraps rev. 137613, having configured as
>
> ${gcc_dir}/config
On Wed, Jul 9, 2008 at 6:50 PM, Ben Elliston <[EMAIL PROTECTED]> wrote:
>> In this case, I argue that this code is always compiled with a C
>> compiler, and should never be compiled by a C++ compiler. Therefore,
>> I believe it is wrong for this code to be compiled with the
>> -Wc++-compat warning
On Wed, Aug 13, 2008 at 12:52 PM, Aldy Hernandez <[EMAIL PROTECTED]> wrote:
>
> It seems to me that the only approach here would be to provide caret
> diagnostics, because reconstructing the original sources from GENERIC
> seems like a loosing proposition.
Hi Aldy,
I agree with your analysis.
On Wed, Aug 13, 2008 at 2:16 PM, Joseph S. Myers
<[EMAIL PROTECTED]> wrote:
> On Wed, 13 Aug 2008, Aldy Hernandez wrote:
>
> I think it would certainly be reasonable to print for
> anything unsupported instead of broken diagnostics, and to reclassify all
> such bugs as wishlist requests for certai
On Thu, Aug 14, 2008 at 7:39 AM, Joseph S. Myers
<[EMAIL PROTECTED]> wrote:
> On Thu, 14 Aug 2008, Manuel López-Ibáñez wrote:
>
> I don't think the option should necessarily just be boolean; once choice
> that may make sense would be caret diagnostics for the first diagnostic
> from an input file o
On Thu, Aug 14, 2008 at 12:14 PM, Aldy Hernandez <[EMAIL PROTECTED]> wrote:
>> * In the near future, make -fdiagnostics-show-caret the default at
>> least while in experimental mode or at least during stages1 and 2.
>> When making a release -fno-diagnostics-show-caret would be the
>> default. Do th
On Thu, Aug 14, 2008 at 11:52 AM, Tom Tromey <[EMAIL PROTECTED]> wrote:
>> "Joseph" == Joseph S Myers <[EMAIL PROTECTED]> writes:
> I'd like to see carets on by default as part of a major release -- say
> GCC 5.0. (First mention!!)
100% agreed.
-- Gaby
Paolo Carlini <[EMAIL PROTECTED]> writes:
| Michael Veksler wrote:
|
| > What do you think?
|
| I think that the "current" solution is very, very old, and "heaven"
| knows how many others didn't work at the time on some "exotic"
| platforms. I would suggest filing a PR and CCing Benjamin.
The "
"Benjamin Kosnik" <[EMAIL PROTECTED]> writes:
| I've been waiting to revisit this issue until we have correct
| alignment support for template objects (std::aligned_storage, etc.)
| in g++. Then, we can use array_allocator to deal with this stuff in a
| much more transparent and C++ friendly way.
Mark Mitchell <[EMAIL PROTECTED]> writes:
| The GCC SC is still discussing a few of the finer points of the
| transition to GPLv3.
Thanks for the update!
[...]
| 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
David Edelsohn <[EMAIL PROTECTED]> writes:
| > 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 version number for a mere license
| Do
Richard Smith <[EMAIL PROTECTED]> writes:
| 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 line example
On Fri, 27 Jul 2007, Richard Smith wrote:
| Gabriel Dos Reis wrote:
|
| > On Wednesday July 18, 2007 I brought factual evidence to
| > that claim by showing g++ behaviour on all of the examples
| > discussed (including those from the "decltype" proposal).
| > (All I
On Fri, 27 Jul 2007, Richard Smith wrote:
| > | The general philosophy in the current ABI would seem to be
| > | that the expression is encoded in terms of its template
| > | parameters, and not with the evaluated expression with the
| > | subsituted argument.
| >
| > That is correct. For a compi
On Wed, 1 Aug 2007, Mark Mitchell wrote:
| Volker Reichelt wrote:
|
| > 2007-03-26 Dirk Mueller <[EMAIL PROTECTED]>
| >
| >* parser.c (cp_parser_member_declaration): Pedwarn
| >about stray semicolons after member declarations.
| >
|
| > It makes
| >
| > struct A
| > {
|
"Joseph S. Myers" <[EMAIL PROTECTED]> writes:
| On Thu, 23 Aug 2007, Ian Lance Taylor wrote:
|
| > I think we should revert the patch, and continue permitting the
| > bitwise operations on vector float.
| >
| > There seem to be solid reasons to permit this, and no very strong ones
| > to prohibi
Joe Buck <[EMAIL PROTECTED]> writes:
| On Sep 7, 2007, at 1:53 PM, Martin Jambor wrote:
| > [ giving operator new the malloc property ]
|
| On Fri, Sep 07, 2007 at 06:30:33PM -0700, Chris Lattner wrote:
| > It is unclear whether this is safe. Nothing in the standard AFAIK
| > requires the oper
"Richard Guenther" <[EMAIL PROTECTED]> writes:
| On 9/8/07, Chris Lattner <[EMAIL PROTECTED]> wrote:
| > I understand, but allowing users to override new means that the actual
| > implementation may not honor the aliasing guarantees of attribute
| > malloc.
|
| Well, you can argue that all hell b
Joe Buck <[EMAIL PROTECTED]> writes:
| On Sat, Sep 08, 2007 at 04:33:50PM -0500, Gabriel Dos Reis wrote:
| > "Richard Guenther" <[EMAIL PROTECTED]> writes:
| >
| > | On 9/8/07, Chris Lattner <[EMAIL PROTECTED]> wrote:
| > | > I understand, but allowing
Martin Jambor <[EMAIL PROTECTED]> writes:
[...]
| The reason why I believe the patch is safe not only in practice but
| also in principle
However, I do not believe it is sufficient. The reason being that
if the user does not include a header that pulls in that declaration,
then that 'mallo
Mark Mitchell <[EMAIL PROTECTED]> writes:
[...]
| This seems like a useful optimization to me, and I understand that it
| will work 99.99% of the time
Except for people writing allocators :-)
-- Gaby
"Richard Guenther" <[EMAIL PROTECTED]> writes:
[...]
| > It's worse than that:
| >
| > char *pool;
| > void set_pool(char *p) { pool = p; }
| > void *operator new(size_t s) { // return stuff from pool. }
| >
| > bool f() {
| > char *p = new char[1024];
| > set_pool (p);
| >
"Richard Guenther" <[EMAIL PROTECTED]> writes:
[...]
| I don't know of any place we would use such information. At least
|
| int *p = new int;
| int *q = new int;
| if (p == q)
|
| cannot be simplified as both pointers may be NULL?
The above does not use the no-throw operator new, so n
"Richard Guenther" <[EMAIL PROTECTED]> writes:
[...]
| > I think I'm getting confused. Perhaps you could sum up in a single
| > email the argument for why putting this attribute in our standard
| > headers is safe, even in view of possible replacement in user programs?
|
| My argument goes like
"Andrew Pinski" <[EMAIL PROTECTED]> writes:
| On 9/7/07, Chris Lattner <[EMAIL PROTECTED]> wrote:
|
| > It is unclear whether this is safe. Nothing in the standard AFAIK
| > requires the operator new be implemented in terms of malloc, and
| > users are allowed to override it.
|
| I was looking
On Thu, 13 Sep 2007, Andrew Pinski wrote:
| On 13 Sep 2007 19:37:27 -0500, Gabriel Dos Reis <[EMAIL PROTECTED]> wrote:
| > Do you believe that allocator is prohibited by the C++ standard?
|
| Yes just because it points to another object at that point.
I'm afraid that is to
Jason Merrill <[EMAIL PROTECTED]> writes:
| But in any case, nobody has code that relies on getting an error from
| a previous version of the compiler that would be broken by moving to
| 4.3. Only regressions on valid code seem serious enough to me to
| warrant blocking a release.
I strongly agre
Joe Buck <[EMAIL PROTECTED]> writes:
| On Wed, Oct 24, 2007 at 12:15:03PM -0700, Andrew Pinski wrote:
| > On 10/24/07, John Gateley <[EMAIL PROTECTED]> wrote:
| > > I don't think it is undefined code. The class has no virtual functions,
| > > and the variable argument function doesn't need to know
Joe Buck <[EMAIL PROTECTED]> writes:
| On Wed, Oct 24, 2007 at 05:32:12PM -0700, Mark Mitchell wrote:
| > Richard Guenther wrote:
| > > 2007-10-18 Benjamin Kosnik <[EMAIL PROTECTED]>
| > >
| > > Removal of pre-ISO C++ items from include/backwards.
| > > * include/Makefile.am (ba
On Fri, 26 Oct 2007, skaller wrote:
|
| On Thu, 2007-10-25 at 07:59 -0500, Gabriel Dos Reis wrote:
|
| > 'deprecated' in the standard does not carry much semantics weight,
| > unless the feature is also removed. But, even then we would have to
| > worry about existing code
On Fri, 26 Oct 2007, skaller wrote:
|
| On Thu, 2007-10-25 at 11:37 -0400, Robert Dewar wrote:
| > skaller wrote:
| >
| > > I think this is the wrong idea. Deprecated does carry a lot
| > > of weight. It allows a new compiler without a legacy
| > > to elide the feature and specify it is ISO comp
On Fri, 26 Oct 2007, skaller wrote:
|
| On Thu, 2007-10-25 at 12:40 -0500, Gabriel Dos Reis wrote:
|
| > | I think this is the wrong idea. Deprecated does carry a lot
| > | of weight. It allows a new compiler without a legacy
| > | to elide the feature and specify it is ISO
On Thu, 25 Oct 2007, Jonathan Wakely wrote:
| On 25/10/2007, Gerald Pfeifer <[EMAIL PROTECTED]> wrote:
| > On Thu, 25 Oct 2007, Andrew Pinski wrote:
| > > Well technically these headers have been deprecated since at least 3.2
| > > (maybe even back in 3.0) with them producing a warning. So I don'
On Fri, 26 Oct 2007, skaller wrote:
| I should point out retaining 'old' features can create a
| significant maintenance burden for gcc developers,
In this specific case, what are they?
-- Gaby
On Fri, 26 Oct 2007, skaller wrote:
|
| On Thu, 2007-10-25 at 20:34 -0500, Gabriel Dos Reis wrote:
| > On Fri, 26 Oct 2007, skaller wrote:
| >
| > | I should point out retaining 'old' features can create a
| > | significant maintenance burden for gcc developers,
| >
"Dep, Khushil (GE Money)" <[EMAIL PROTECTED]> writes:
| I'm not sure that a plugin system will encourage more research and
| development. Anyone who even contemplates getting into the this field
| isn't going to be someone who is easily disuaded by challenges and
| obstacles.
I beg to disagree --
Robert Dewar <[EMAIL PROTECTED]> writes:
| It's interestinng to note that in the Ada world, there is an ISO
| standard for plugins, which is compiler/vendor neutral (at least
| in theory, in practice there are some implementation dependencies).
| That's the ASIS interface (Ada Semantic Interface S
On Sun, 18 Nov 2007, Robert Dewar wrote:
| Richard Kenner wrote:
| > > Robert Dewar <[EMAIL PROTECTED]> writes:
| > >
| > > | It's interestinng to note that in the Ada world, there is an ISO
| > > | standard for plugins, which is compiler/vendor neutral (at least
| > > | in theory, in practice the
On Sun, 18 Nov 2007, Robert Dewar wrote:
| Let's take an example, suppose we want to write a semantic analysis
| tool (e.g. the Mozilla style checker mentioned earlier). For Ada,
| we can write an ASIS application and we need to know NOTHING AT ALL
| about the internals of the compiler we are usin
1201 - 1300 of 1308 matches
Mail list logo
