On 11/08/2011 03:22 PM, Paolo Carlini wrote:
I believe that the core issue is pretty clear: -Wno-narrowing disables a C++
only warning but somehow we are passing it also in a few C compiler
invocations, thus the driver warns.
No, it's accepted by the C front end too, it just has no effect. I
On 11/06/2011 09:14 PM, Miles Bader wrote:
Hmm, has he been contacted recently? The original patch was from ages
ago...
Yes, I've been in communication with him and the FSF. I expect this to
be sorted out soon so we can put in the patch.
Jason
On 11/11/2011 07:02 AM, Christian Jönsson wrote:
revision r181278 gives me a bootstrap/build error on cygwin for gcc
trunk like this
I've now conditioned those functions on the macro being defined. Does
that fix it for you?
Jason
PR, please.
Jason
On 10/10/2011 08:07 PM, Gabriel Dos Reis wrote:
PODness has changed from C++98.
Class layout in the ABI still uses the C++98 definition of POD.
Jason
On 01/05/2012 01:38 PM, Joe Buck wrote:
Class layout in the ABI still uses the C++98 definition of POD.
But does this actually matter?
Yes, since PODness affects the use of tail padding. But it isn't a
source of ABI incompatibility since "POD for the purpose of layout"
isn't changing.
Ja
On 01/12/2012 02:16 PM, Benjamin Kosnik wrote:
As it turns out, the mangling changes don't really impact the explicit
instantiations compiled in to libstdc++.so. So, it seems possible to say
Right, so people can use -fabi-version=0 and still use the installed
libstdc++.
I think a compelling
On 01/12/2012 03:17 PM, Jonathan Wakely wrote:
And if we are going to do that, shouldn't it be ASAP? Otherwise we'll
not be able to change anything significant in .so.7 once it's
available in 4.7 and we'll have to create a .so.8 for more changes..
Wait, what? Are you planning to move to .so.7
On 07/09/2009 12:32 AM, Janis Johnson wrote:
Given that libstdc++ is used with compilers other than G++, is it
allowable to depend on non-standard C++ compiler support?
Seems reasonable to me, but we may want to standardize the support in
the ABI.
Jason
On 07/14/2009 07:35 PM, Janis Johnson wrote:
What's the forum for discussions about the C++ ABI?
cxx-abi-...@codesourcery.com
Jason
On 07/17/2009 03:26 PM, Richard Guenther wrote:
Where can this be fixed? I currently have a hack to not strip
restrict qualifiers in decay_conversion, but that feels a little
too hackish. What's the important piece of decay_conversion
that is necessary for indirect refs?
Well, I'd start by ma
On 07/23/2009 08:26 AM, Larry Evans wrote:
etags: Warning: "--language" option is obsolete; use
"--language-force" instead
etags: Unknown language "none" in "language" option
etags: Unknown option: --include
It works fine for me with etags from GNU emacs 22.3.
Oh, and BTW, does anyone find et
On 07/28/2009 10:47 AM, Ed Smith-Rowland wrote:
We need a gcc branch for concepts.
Probably, if someone is working on them, just as for any ongoing project.
That leaves open the question of whether the ConceptGCC branch is the
one.
No. Doug felt that much of ConceptGCC needed to be rewritt
On 07/29/2009 06:27 AM, Adam Butcher wrote:
Esben Mose Hansen writes:
I am completely new to gcc hacking, just
dying to get lambda into gcc 4.5 :)
Me too on both counts!
Great! Please feel free to ask me any questions you have directly. Do
you have copyright assignments on file yet? I
On 08/03/2009 08:32 AM, Larry Evans wrote:
While trying to track down the cause of:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40092
I encountered what may be an error. In pt.c around
line 2493, there's this:
if (TYPE_P (t) )
cp_walk_tree (&TYPE_CONTEXT (t), &find_parameter_packs_r, ppd, ppd
On 08/03/2009 09:36 PM, Adam Butcher wrote:
Thanks. I haven't any copyright assignments on file -- this is my first
dabbling with gcc and I've been doing it
mostly to experiment with C++ lambda support and non-standard extensions such
as polymorphic lambda support.
OK. We'll need an assignm
On 08/04/2009 09:35 AM, John Freeman wrote:
In my opinion, lambdas are not intended as just a shortcut to writing a
function object class. This is why our proposal did not require that
lambdas be implemented as classes; it is simply one implementation.
(Awaiting word to see if this is still the
On 08/04/2009 04:52 AM, Adam Butcher wrote:
Yes sorry about that. I appreciate the issue. I had taken a branch of trunk
and applied the lambda changes to it to
keep only lambda changes on my working branch (allowing simpler future
rebaseing). There were a number of things I
had to change to
On 08/04/2009 10:17 AM, John Freeman wrote:
Reiterating, to allow more freedom in implementation, we can just say it
"behaves as" a template, rather than "is" a template.
I don't see the difference. As long as they work the same, the compiler
is free to do whatever it wants internally.
Jaso
On 08/10/2009 09:00 AM, Dodji Seketeli wrote:
It seems the git mirror git://gcc.gnu.org/git/gcc.git didn't sync'ed to
the gcc svn tree since last Friday as git fetch wont grab any bits newer
than that date. Cloning from that address works OK though. It's just that
the bits are a bit old.
I was
A few comments:
/* XXX: Any way to get current location? */
input_location
The following examples produce
equivalent functions:
1. [] (auto x, auto& y, auto const& z) { return x + y + z; }
2. [] (X x, Y& y, Z const& z) {
return x + y + z; }
3. [] (auto x, Y& y, auto const&
On 08/11/2009 11:20 AM, Adam Butcher wrote:
Ah okay. Would it be worth enhancing the tree-vec interface to include block
reallocation with size doubling and end
marking to allow for more efficient reallocation?
I don't think so; I expect that would end up being less space-efficient,
since in
On 08/15/2009 10:12 AM, Jerry Quinn wrote:
Bootstrap comparison failure!
>[...]
(write_nested_name): Add a fake anonymous namespace scope if
true.
What I assume is going on here is that use of anonymous namespaces can
break bitwise comparison, because get_file_function_name uses a r
On 08/18/2009 11:43 AM, Richard Henderson wrote:
Would it be helpful to reserve a leading character (say, "*") that means
that strcmp should not apply, but rather pointer identity? Thus a class
foo that is intended to be local, as opposed to forced local via
RTLD_LOCAL, can just use "*foo" and no
On 08/20/2009 11:36 PM, Ian Lance Taylor wrote:
Ironically, -freorder-blocks-and-partition, which seems tailor-made to
fix this, is disabled when exception handling is used.
This is no longer true:
2009-08-07 Jakub Jelinek
...
* opts.c: Include except.h.
(decode_options): Al
On 08/03/2009 04:09 PM, Pedro Lamarão wrote:
Current trunk (revision 150381) fails to bootstrap with the following
configuration:
.../../trunk/libcpp/../include/libiberty.h:106: error: new declaration
‘char* basename(const char*)’
/usr/include/string.h:601: error: ambiguates old declaration ‘c
On 08/15/2009 10:12 AM, Jerry Quinn wrote:
Building with --enable-build-with-cxx fails to bootstrap as follows:
Comparing stages 2 and 3
warning: gcc/cc1plus-checksum.o differs
warning: gcc/cc1-checksum.o differs
Bootstrap comparison failure!
x86_64-unknown-linux-gnu/32/libstdc++-v3/libsupc++/eh
On 08/26/2009 05:36 PM, Ralf Wildenhues wrote:
* Jason Merrill wrote on Wed, Aug 26, 2009 at 10:32:05PM CEST:
The problem is that AC_CHECK_DECLS gets confused by overloaded
functions, and glibc 2.10 has overloaded declarations of basename
and some other string functions for const-correctness
On 09/10/2009 03:45 PM, Sergey Sadovnikov wrote:
1. Lambda and template type deduction.
A patch I've been holding off on committing happens to fix this bug.
This is surprising, as I thought it was just a code cleanup. I guess
I'll go ahead and commit it soon.
2. Lambdas and result_of or s
On 09/12/2009 08:11 PM, Jason Merrill wrote:
On 09/10/2009 03:45 PM, Sergey Sadovnikov wrote:
1. Lambda and template type deduction.
A patch I've been holding off on committing happens to fix this bug.
This is surprising, as I thought it was just a code cleanup. I guess
I'll go
On 08/31/2009 12:57 AM, Jerry Quinn wrote:
On Thu, 2009-08-27 at 00:24 -0400, Jason Merrill wrote:
Do you know why r149964 makes a difference?
I understand now. The patch changed the anonymous namespace name to use
get_file_function_name in all cases, where previously we were using the
On 09/14/2009 11:54 AM, Jason Merrill wrote:
I think the way to go with this is to revert the compiler bits of
r149964, not mess with mangle.c at all, and insert the initial * if the
typeinfo name won't have TREE_PUBLIC set, since that's precisely the
property we want to mirror in
On 09/21/2009 02:43 PM, Jerry Quinn wrote:
Another approach could be to use 2 different names for anonymous
namespaces that should and should not be compared by pointer. I don't
like the speed implications, but it might work.
Any type that involves the anonymous namespace should be compared by
On 09/22/2009 07:04 AM, Jerry Quinn wrote:
On Mon, 2009-09-21 at 13:06 -0400, Jason Merrill wrote:
On 09/14/2009 11:54 AM, Jason Merrill wrote:
I think the way to go with this is to revert the compiler bits of
r149964, not mess with mangle.c at all, and insert the initial * if the
typeinfo
On 09/23/2009 09:22 AM, Jerry Quinn wrote:
I'm not really sure how everything fits together here. Am I missing
something obvious?
I notice that you're missing the fix_string_type that tinfo_name does.
But I'd rather not duplicate the code that creates the STRING_CST;
better to delay the call
On 09/20/2009 08:07 AM, Dave Korn wrote:
Richard Guenther wrote:
On Sun, 20 Sep 2009, Dave Korn wrote:
BTW, why don't we call this more-flexible-stage-3 "stage 2" any more? It
sounds a lot like the way that's still described on develop.html.
Because "New functionality may not be introdu
On 09/22/2009 10:16 PM, Kenny Simpson wrote:
Will the lambda branch be merged into 4.5?
Yes.
Jason
On 09/15/2009 12:35 PM, Chris Lattner wrote:
The second major feature of Blocks vs c++ lambdas is that they can be
"copied onto the heap". This allows things like "Grand Central Dispatch"
to work: you can write code that executes blocks asynchronously or on
other threads/work queues (after the fu
On 09/24/2009 11:22 AM, Chris Lattner wrote:
Can the lambda (containing X) be copied and put onto a queue? What is
its type?
As you said, the lambda has a unique anonymous type. If you want to put
multiple lambdas into a container, you can use std::function as the
element type.
Jason
The SVN book
(http://svnbook.red-bean.com/nightly/en/svn.branchmerge.basicmerging.html)
suggests deleting feature branches that have been merged into the trunk;
I think this would help to reduce the clutter in the branches directory
and avoid confusion with people expecting to find ongoing deve
On 09/25/2009 12:55 PM, Joseph S. Myers wrote:
Do we believe any future conversion to another version control system
(that might have a more structured notion of what is a branch than it
simply being a directory used in a certain way) would continue to make the
history of such branches readily av
On 09/29/2009 04:23 PM, Janis Johnson wrote:
The PowerPC 32-bit ELF ABI says that a struct is passed as a pointer
to an object or a copy of the object. Classes are treated the same
as classes. Does the C++ ABI have rules about classes like
std::complex that would cause them to be treated differ
On 09/15/2009 02:22 PM, Mark Zweers wrote:
While experimenting with "Defaulted and deleting functions" on my brand-newly
downloaded gcc-4.5 compiler, I've noticed the following: the order of '=default' and
'=delete' matters with template member functions.
I'm about to check in a fix for this,
On 10/05/2009 11:09 AM, Larry Evans wrote:
The work in 4.5 on O(1) template instantiation lookup time is already
showing benefits:
Glad to hear it!
Jason
On 10/12/2009 10:22 AM, Paolo Bonzini wrote:
Yep. Anyone deleting dead branches should add a link to the last "live"
version in branches.html. It seems easier to me to move them under
branches/dead, and possibly create branches/merged.
Multiple directory levels under branches/ confuse git-svn;
On 10/12/2009 05:17 PM, Andrew Pinski wrote:
That seems like a huge bug in git-svn because we already use multiple
directory levels under branches. Hint ibm and redhat and debain.
Yep, that's why I said "expand". I've thought about fixing that aspect
of git-svn, but I'm not sure how it would
On 10/12/2009 09:05 PM, Michael Matz wrote:
I don't think we should necessarily limit ourself by bugs in foreign tools
if it reduces useful information. What about a new top-level directory
dead-branches/, not under branches/ but parallel to it? Should be easy to
exempt from git-svn handling, s
On 10/13/2009 08:50 PM, Ben Elliston wrote:
I found that svn log works well if you do this:
svn log svn+ssh://b...@gcc.gnu.org/svn/gcc | less
Which in recent versions of svn can also be written
svn log ^/ |less
if you're in an SVN working directory.
Jason
On 10/26/2009 07:14 AM, Jakub Jelinek wrote:
-/* Generate the mangled representation of TYPE for the typeinfo name.
*/
+/* Generate the mangled representation of TYPE. */
const char *
-mangle_type_string_for_rtti (const tree type)
+mangle_type_string (const tree type)
Why this change?
Thi
On 10/28/2009 07:29 AM, Jerry Quinn wrote:
+ length = strlen (name);
+ if (mark_private)
+ name_string = build_string (length + 1, buf);
+ else
+name_string = build_string (length + 1, name);
These two calls shouldn't be using the same length. I think the +1 in
the old code was un
On 10/29/2009 01:06 AM, Jerry Quinn wrote:
And here is the latest patch.
This one is OK, thanks.
Jason
On 10/30/2009 09:20 AM, Richard Guenther wrote:
On Fri, Oct 30, 2009 at 2:15 PM, Paolo Carlini wrote:
Richard Guenther wrote:
where you replaced build_string (strlen (name) + 1, name) with
build_string (strlen (name), name). I don't know if this renders the
ABIs incompatible, but I doubt it -
On 10/30/2009 06:27 PM, Paolo Carlini wrote:
Thanks. So I went ahead and reapplied the patch with the +1 fixed, after
having double checked that the testsuites are now fine.
The lengths do still need to be different on the two code paths, though.
You added back the NULL for the normal case, b
Here's the fix I'm checking in for the * path.
Jason
commit 16463ef55164d4668d6f1eeb150974452e1dbe58
Author: Jason Merrill
Date: Sat Oct 31 18:10:17 2009 -0400
* rtti.c (tinfo_name): Fix lengths for private case.
diff --git a/gcc/cp/rtti.c b/gcc/cp/rtti.c
index 2926f97..c7af
The G++ mangling of SIMD vector types (SSE, Altivec, etc.) is
fundamentally broken as it doesn't currently encode the size of the
vector, only the element type. So overloading of different size vectors
fails. It seems when I implemented this I was modeling the Altivec
__vector qualifier, whic
On 11/12/2009 11:14 AM, Ulrich Drepper wrote:
On 11/12/2009 07:24 AM, Jason Merrill wrote:
c) Use -fabi-version=2.1.
I'd favor this if you can emit aliases with the old names wherever this
is possible and currently done.
I suppose if we unconditionally use the new mangling and emit a
On 11/12/2009 11:50 AM, Ulrich Drepper wrote:
On 11/12/2009 08:35 AM, Jason Merrill wrote:
I'd favor this if you can emit aliases with the old names wherever this
is possible and currently done.
I suppose if we unconditionally use the new mangling and emit a weak
alias with the old man
On 11/12/2009 01:18 PM, Mark Mitchell wrote:
b) Take over -fabi-version=3 and bump the template arg change to v4.
I'm not sure what "take over" means, but I think this change should be
in v4. People might be using v3, and we shouldn't break their world.
Introducing 2.1, or a separate flag, see
On 11/12/2009 04:32 PM, Mark Mitchell wrote:
I understand the argument, but it sounds overly complicated. Or else
not complicated enough. If we no longer think that a linear progression
of ABI versions is sufficient, then we should have switches for picking
your point in the multi-dimensional s
On 11/12/2009 04:48 PM, Mark Mitchell wrote:
So, do you consider ABIv3 there only as a theoretical conformance
option? In other words, not something we're going to make the default
in any forseeable future? (Those aren't meant to be rhetorical
questions -- I'm just asking.)
That has been my t
On 11/12/2009 05:19 PM, Mark Mitchell wrote:
So, I still tend to think that the best thing is to put the vector stuff
into v4, and switch that on when we update libstdc++. I think your
suggest is coherent and well-reasoned, but it seems like a lot of
complexity to deal with a template corner cas
The git mirror seems to have stopped updating today.
Jason
On 11/18/2009 07:59 AM, Dave Korn wrote:
Is it valid for the context to be NULL here?
It doesn't make sense to have a [cd]tor with null DECL_CONTEXT, but
dump_function_decl should probably be more resilient, for use during
debugging when things may be in an intermediate state.
Jason
On 11/17/2009 09:36 AM, Larry Evans wrote:
Could g++ provide this feature? How hard would it be to implement.
It probably wouldn't be difficult to implement, but I'd want someone to
champion the extension with the C++ committee as well. Have you asked
Doug Gregor what he thinks? I assume th
On 12/01/2009 09:02 AM, Rainer Emrich wrote:
C:/MinGW/i686-pc/i686-pc/i686-pc/gcc-4.5.0/mingw/lib/libppl.a(Polyhedron_widenings.o):Polyhedron_widenings.cc:(.text$_ZN23Parma_Polyhedra_Library3BoxINS_8IntervalI10__gmp_exprIA1_12__mpq_structS4_ENS_25Interval_Restriction_NoneINS_20Interval_Info_Bitse
On 12/01/2009 09:02 AM, Rainer Emrich wrote:
C:/MinGW/i686-pc/i686-pc/i686-pc/gcc-4.5.0/mingw/lib/libppl.a(Polyhedron_widenings.o):Polyhedron_widenings.cc:(.text$_ZN23Parma_Polyhedra_Library3BoxINS_8IntervalI10__gmp_exprIA1_12__mpq_structS4_ENS_25Interval_Restriction_NoneINS_20Interval_Info_Bitse
To fix PR 12909 with minimal ABI breakage, I'd like to be able to just
hang extra symbols off the cgraph node for a variable or function and
have them all emitted together. I could do this with the existing alias
mechanisms, but they involve additional DECLs for the aliases. Does it
seem reas
On 02/05/2010 05:56 PM, Jan Hubicka wrote:
But without the DECLs there would be absolutely no way to reffer to these
within current unit, so I guess cgraph don't need to care about them much
(i.e. they can just be some list assigned to node or decl).
Right, they would just be for binary compati
I periodically get bitten by bug 34115: a compiler configured without
--with-arch on i686-pc-linux-gnu doesn't support atomics. I think we
would only need to bump the default to i486 to get atomic support. Can
we reconsider the default for 4.5?
Jason
On 02/18/2010 07:46 PM, Joseph S. Myers wrote:
On Thu, 18 Feb 2010, Jason Merrill wrote:
I periodically get bitten by bug 34115: a compiler configured without
--with-arch on i686-pc-linux-gnu doesn't support atomics. I think we would
only need to bump the default to i486 to get atomic su
On 02/18/2010 07:46 PM, Joseph S. Myers wrote:
On Thu, 18 Feb 2010, Jason Merrill wrote:
I periodically get bitten by bug 34115: a compiler configured without
--with-arch on i686-pc-linux-gnu doesn't support atomics. I think we would
only need to bump the default to i486 to get atomic su
On 02/25/2010 05:37 AM, Paolo Bonzini wrote:
Since this is build patch, it also needs OK from build maintainer (CCd).
There are plenty of global reviewers in the CC list. :-)
Yep, I've just been trying to get people who might know why the status
quo is the way it is to weigh in before I appr
On 04/06/2010 09:39 AM, Kirill A. Shutemov wrote:
On Tue, Apr 6, 2010 at 3:16 PM, Jakub Jelinek wrote:
The GCC 4.5 release branch has been finally created today.
Please, add gcc-4_5-branch to git mirror.
Done.
Jason
Rodolfo Lima wrote:
When the time to get the hands dirty arrives, I'll need to know if
somebody's working off-branch on some parts to avoid unnecessary work.
I don't think anyone is working on it at the moment; since Apple hired
Doug Gregor he isn't working on GCC at all anymore.
I also kno
Ed Smith-Rowland wrote:
In my efforts to build C++-0X library components I've noticed that
constexpr member variables are used in several places. I was unable to
implement these as intended and reverted to const accessors.
It seems like the intent is sort of a static const function except tha
-pedantic-errors will make it an error.
I don't feel strongly about whether these should be pedwarn or something
stronger, but I note that libstdc++ wants to use variadic templates in
the default mode, so we can't just disable them entirely.
Jason
Simon Hill wrote:
C) Lastly, it would be nice if someone could indicate whether a
finished and fully functional version of this project would be likely
to make it into the mainline as I have seen requests for its
functionality many times, including on this mailing list, and it has
no downside:
-
Chris Lattner wrote:
On Apr 10, 2009, at 1:55 PM, Jason Merrill wrote:
My impression is that the C++ committee generally feel that exception
specifications are a failed feature, and nobody is particularly
interested in fixing them.
Have you seen this?
http://www.open-std.org/JTC1/SC22/WG21
Bernie Innocenti wrote:
On 06/07/09 12:40, Ralf Wildenhues wrote:
Is this mirror an independent conversion from the infradead one (i.e., I
have to throw away the repo and re-download a full repo? Or can I reuse
objects)?
It's an independent mirror, and I wouldn't recommend switching to it y
Bernie Innocenti wrote:
I won't re-create the repository from scratch, then.
re-creating it from scratch should be fine as long as the metadata uses
svn+ssh://gcc.gnu.org/svn/gcc. I'd think that
git svn clone -s file://path/to/svn/root \
--rewrite-root=svn+ssh://gcc.gnu.org/svn/gcc
would
On 06/11/2009 03:07 AM, Bernie Innocenti wrote:
6) As Daniel said, we are indeed already mirroring all branches from
the SVN repository. But those go to remotes/foo rather than foo,
which most likely *your* git fetches aren't configured to consider.
Mine are. I ignore all heads in gcc
On 06/15/2009 10:28 AM, Rafael Espindola wrote:
It fails with
$ git config --add remote.origin.fetch '+refs/remotes/*:refs/remotes/origin/*'
That's not my section; my contribution starts at
Alternative git-svn procedure (Jason Merrill)
Jason
On 06/15/2009 01:22 PM, Bernie Innocenti wrote:
On 06/15/09 16:28, Rafael Espindola wrote:
It fails with
$ git config --add remote.origin.fetch '+refs/remotes/*:refs/remotes/origin/*'
$ git fetch
fatal: refs/remotes/origin/gcc-4_0-branch tracks both
refs/remotes/gcc-4_0-branch and refs/heads/gc
Incidentally, I notice that branches in subdirectories of branches/ are
still broken; i.e. ARM apple redhat suse ubuntu, maybe others. I give
instructions on the GitMirror page for how to deal with that, but I
wonder if it's possible to set it up properly on the mirror instead.
Jason
I also notice a few remotes with @ in them like milepost-bra...@129596
which seem to be git-svn artifacts.
Jason
On 06/16/2009 03:51 PM, Bernie Innocenti wrote:
Yes, but which one should die? Will cloners get confused by a
repository where the master branch is missing?
clone will get whatever branch is currently active in the cloned
repository, doesn't matter what it's called.
Currently master is out
On 06/20/2009 04:38 AM, Bernie Innocenti wrote:
On 06/20/09 04:59, Jason Merrill wrote:
Any thoughts on what to do about the non-branch directories under
branches/? The complete set is ARM apple csl dead gcj ibm ix86 suse
ubuntu. The only solution I can think of would be to specifically
On 05/11/2010 10:30 AM, H.J. Lu wrote:
I created a branch for 256bit vectorizer, branches/vect256/. Richard
and I will work on it to extend vectorizer to 256bit.
Jason, can you include it in git mirror? We can drop the ix86 branch
in git since there are several branches under branches/ix86.
I
On 05/11/2010 11:21 AM, H.J. Lu wrote:
On Tue, May 11, 2010 at 7:49 AM, Jason Merrill wrote:
git config --add remote.origin.fetch
refs/remotes/vect256:refs/remotes/origin/vect256
git config --add svn-remote.svn.fetch
branches/vect256:refs/remotes/origin/vect256
I was hoping
git
On 05/11/2010 02:28 PM, H.J. Lu wrote:
It isn't very clear that refs/heads was changed to refs/remotes.
Sure. The git-svn mirror puts everything under refs/remotes, then the
git mirror maintainers manually create the equivalent of symbolic links
under refs/heads for some branches.
I don't
On 05/20/2010 08:18 AM, Peter Dimov wrote:
On 05/20/2010 01:55 PM, Paolo Carlini wrote:
It's uglier because the code above doesn't work for functions,
By the way, do you have a specific testcase in mind?
Because addressof_fn_test.cpp, part of Boost, passes...
This is probably a g++/gcc exte
On 09/20/2010 09:58 AM, Rodrigo Rivas wrote:
This patch tries to implement the C++0x featue "Forward declarations
for enums" aka "opaque enum declarations":
Great! BTW, please send C++ patches to gcc-patches and CC me so that I
see them right away; I tend to fall behind on the mailing lists.
On 09/20/2010 07:06 PM, Rodrigo Rivas wrote:
Are you sure? As I said in other post, I am no longer sure that the
C++0x draft forbids the type definition in this context.
But I'm no expert in standarese, so I'm still undecided.
It took me some searching, but yes, it does:
"A type-specifier-seq
On 10/02/2010 01:50 PM, Rodrigo Rivas wrote:
I would change cp_parser_range_for to use cp_parser_decl_specifier_seq
> instead of cp_parser_type_specifier_seq and then wait to complain about
> defining a type until after we've seen the ':'.
I already tried that, but it didn't work. It seemed to m
On 09/17/2010 02:25 AM, Ed Smith-Rowland wrote:
I am slowly working on user defined literals for C++-0x.
Thanks! Please send future patches to gcc-patches and me directly.
Looking over your patch, I see you're doing a significant amount of it
in the parser, which is incorrect; the draft says
On 10/04/2010 10:59 AM, Rodrigo Rivas wrote:
Admittedly, this is not a "trailing_return_type", but AFAICT it has
exactly the same restrictions.
The restrictions are slightly different; in the case of a trailing return
type a class-specifier is not one of the expansions, so we don't treat a {
as
On 10/04/2010 02:16 PM, 3dw...@verizon.net wrote:
You shouldn't be able to call it as just _foo(1.2L); an operator name is
different from a normal function name.
According to 13.5.8/7 :
[ Note: literal operators and literal operator templates are usually invoked
implicitly through user-defi
On 11/05/2010 09:03 PM, Gabriel Dos Reis wrote:
I'm looking into std::bitset with respect to constexpr issue.
My understanding has always been that one can use the
syntax `member()' to value-initialize an array data member
`member'.
I believe so.
Jason
Currently, the middle end seems to use the same rules for handling
constant overflow of integer arithmetic and conversion between integer
types: set TREE_OVERFLOW on the INTEGER_CST if the type is signed and
the value doesn't fit in the target type. But this doesn't seem to
match the C/C++ sta
On 11/07/2010 11:11 PM, Ian Lance Taylor wrote:
C99 6.2.5 paragraph 9 says "A computation involving unsigned operands
can never overflow, because a result that cannot be represented by the
resulting unsigned integer type is reduced modulo the number that is one
greater than the largest value that
201 - 300 of 528 matches
Mail list logo
