Rainer Orth writes:
> After this change, I'm seeing another issue: most 32-bit go execution
> tests fail like this on Solaris 11/x86:
>
> /vol/gcc/src/hg/trunk/local/libgo/runtime/malloc.goc:366: libgo assertion
> failure
> FAIL: go.go-torture/execute/array-1.go execution, -O0
>
> Running the
On 10/31/2011 03:23 PM, Jakub Jelinek wrote:
On Sat, Oct 29, 2011 at 03:53:37PM +0200, Toon Moene wrote:
I wonder whether it will work with the attached Fortran routine - it
sure would mean a boost to the 18%+ heaviest CPU user in our code.
Would be nice to cut down slightly this testcase
Rainer Orth writes:
> * The message points to the wrong line due to a broken test: malloc.goc
> has:
>
> p = runtime_SysReserve((void*)(0x00f8ULL<<32), bitmap_size +
> arena_size);
> if(p == nil)
> runtime_throw("runtime: cannot reserve arena v
I'm considering the following. Does anyone believe this i386/i486 decision
re DImode is a mistake? Should I limit that to Pentium by checking cmpxchg?
r~
diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
index 7ce57d8..7d28e43 100644
--- a/gcc/config/i386/i386.md
+++ b/gcc/config/i
* optabs.c (expand_atomic_store): Use create_fixed_operand for
atomic_store optab. Don't try to fall back to sync_lock_release.
---
The create_fixed_operand thinko is obvious. The sync_lock_release is
more subtle. The target is allowed to support only storing 0/1 with
the test_a
Uros Bizjak writes:
> It turned out that the EpollEvent definition in
> libgo/syscalls/epoll/socket_epoll.go is non-portable (if not outright
> dangerous...). The definition does have a FIXME comment, but does not
> take into account the effects of __attribute__((__packed__)) from
> system header
In my implementation of the C++11 list-initialization proposal, I also
implemented an extension that allowed for deduction of
std::initializer_list<...> for a template type parameter, so that people
could try it out and see what they thought. This extension didn't make
it into C++11, so I'm sw
Here's what I'm checking in:
commit 6e82dfcf49c92195b5d4bc4b522207b92bad554f
Author: Jason Merrill
Date: Mon Oct 31 01:21:49 2011 -0400
* include/Makefile.am (install-freestanding-headers): Install
c++0x_warning.h.
* libsupc++/initializer_list: Include it.
diff --git a/libstdc+
On 10/31/2011 01:57 PM, Jason Merrill wrote:
On 10/31/2011 06:39 AM, Paolo Carlini wrote:
Great. When you commit it, you can as well add 'PR c++/50920' to the
ChangeLog!
OK, here's what I'm checking in. There are a lot more instances of C++0x
in comments and cxx_dialect checks, but I'm not goi
This patch is for google-main only.
Tested with bootstrap and regression tests.
Print unroll and peel factors along with loop source position under -fopt-info.
Teresa
2011-10-31 Teresa Johnson
* common.opt (fopt-info): Disable -fopt-info by default.
* loop-unroll.c (report_
On 10/31/2011 03:29 PM, Jakub Jelinek wrote:
> * config/i386/sse.md (fixuns_trunc2): New
> expander.
Ok.
r~
On Mon, Oct 31, 2011 at 5:31 PM, Jakub Jelinek wrote:
> On Mon, Oct 31, 2011 at 05:23:58PM -0500, Quentin Neill wrote:
>> Interested parties should view these threads from three years ago:
>> http://gcc.gnu.org/ml/gcc-patches/2008-11/threads.html#00145
>> http://gcc.gnu.org/ml/gcc-patches/2008-12/
On Mon, Oct 31, 2011 at 5:32 PM, Peter Bergner wrote:
> Ok, attached below is the updated patch that passes bootstrap and regtesting
> that only enables the new link stack code for 32-bit compiles. However,
> talking with Alan, he mentioned we just have to mark the opd entry weak
> and that will
On Mon, Oct 31, 2011 at 05:23:58PM -0500, Quentin Neill wrote:
> Interested parties should view these threads from three years ago:
> http://gcc.gnu.org/ml/gcc-patches/2008-11/threads.html#00145
> http://gcc.gnu.org/ml/gcc-patches/2008-12/threads.html#00174
>
> Testing on x86_64, okay to commit if
Hi!
This allows to vectorize float -> uint conversion.
To convert V{4,8}SFmode op0 to V{4,8}SImode target, it emits:
V{4,8}SFmode mask = op0 >= { INT_MAX + 1U + .0f, INT_MAX + 1U + .0f, ... }
// non-signalling GE
V{4,8}SFmode tmp1 = mask & { 2.0f * INT_MIN, 2.0f * INT_MIN, ... }
V{4,8}SF
Hi,
This patch moves f16c intrinsics out of immintrin.h into their own
header f16cintrin.h
Interested parties should view these threads from three years ago:
http://gcc.gnu.org/ml/gcc-patches/2008-11/threads.html#00145
http://gcc.gnu.org/ml/gcc-patches/2008-12/threads.html#00174
Testing on x86_6
I noticed this while working on vcond patterns for sparc.
Committed to trunk.
gcc/
* config/sparc/sparc.md (cmask patterns): Allow zero operand.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@180715
138bc75d-0d04-0410-961f-82ee72b054a4
---
gcc/ChangeLog |2 ++
gcc/co
Rainer Orth writes:
> the only issue I've found on Solaris is the use of pthread_yield, which
> doesn't exist even on Solaris 11. The following patch checks for this,
> and falls back to thr_yield if available.
Rather than that patch, I changed the code to use sched_yield rather
than pthread_yi
Rainer Orth writes:
> /vol/gcc/src/hg/trunk/local/libgo/go/syscall/errstr_nor.go:22:8: error:
> referenc
> e to undefined name 'libc_strerror'
> make[4]: *** [syscall/syscall.lo] Error 1
Sorry about that. I thought I had tested that, but evidently not.
Fixed like so. Committed to mainline.
From: Jakub Jelinek
Date: Mon, 31 Oct 2011 11:26:40 +0100
> Or alternatively you could remove the whole if (! !next_note ...)
> next_note = NULL_RTX; stmt and move your cache to a global var and
> clear it when reaching end of function (like
> e.g. last_var_location_insn is cleared in dwarf2out_e
On Oct 31, 2011, at 2:10 PM, niXman wrote:
> This is patch is implement the std::thread::hardware_concurrency().
[ general comment ] Ick, this isn't what I'd call clean. Maybe a porting
header inclusion that defines a static inline pthread_num_processors_np when on
those system that don't have
Rainer Orth writes:
> Ian,
>
>> I committed this patch which should fix this problem. Bootstrapped and
>> ran Go testsuite on x86_64-unknown-linux-gnu.
>
> thanks, but this is not enough:
>
> nawk: syntax error at source line 173
> context is
> ([^ >>> ]*)$", <<< cparam) == 0) {
> na
On 10/31/2011 09:32 PM, Jason Merrill wrote:
On 10/31/2011 04:24 PM, Paolo Carlini wrote:
Sure. Note anyway, that bits/c++config.h is already included, elsewhere
too in libsupc++.
I guess the other option would be to add it to
install-freestanding-headers.
Of course. I think Benjamin followed i
On Fri, 2011-10-28 at 15:37 -0400, David Edelsohn wrote:
> On Fri, Oct 28, 2011 at 12:36 PM, Peter Bergner wrote:
>
> > So David, do we even want to bother trying to support this on -m64
> > given the only cpu that needs this is a 32-bit only cpu? If so, I
> > can try and work with Alan to figur
On 10/31/2011 02:10 PM, niXman wrote:
> +#elif definen(_GLIBCXX_USE_GET_NPROCS)
Typo.
r~
Hi,
> This is patch is implement the std::thread::hardware_concurrency().
> Tested on pthreads-win32/winpthreads on windows OS, and on Linux/FreeBSD.
Please send library patches to the library mailing list too. Also, always parch
mainline first: actually in the latter the function is alread impl
Here is a patch that updates libgo to use gcc's internal libtool
version. I've only retained config/go.m4 for now.
http://trippelsdorf.de/Use-gcc-s-libtool-in-libgo.patch.bz2
---
libgo/Makefile.in |9 +-
libgo/aclocal.m4| 10 +-
libgo/config/libtool.m4 | 7516 ---
Hi all.
This is patch is implement the std::thread::hardware_concurrency().
Tested on pthreads-win32/winpthreads on windows OS, and on Linux/FreeBSD.
diff --git a/libstdc++-v3/src/thread.cc b/libstdc++-v3/src/thread.cc
index 09e7fc5..3eacb06 100644
--- a/libstdc++-v3/src/thread.cc
+++ b/libstd
This is an updated version of the libtool update patch. It fixes the
--with-sysroot clash by reverting commit 3334f7ed5851ef1 in libtools.
I've also included Rainer's 64bit Solaris patch.
http://trippelsdorf.de/update-to-libtool-2.4.2-and-regenerate.patch.bz2
---
boehm-gc/Makefile.in
On 10/31/2011 09:29 PM, Jason Merrill wrote:
On 10/31/2011 04:09 PM, Paolo Carlini wrote:
... so today I noticed the c_inhibit_evaluation_warnings use in
cp_convert_and_check and occurred to me that we could use the existing
mechanism for this warning too?
The below still passes checking and my
> > > We would like to propose changing AVX generic mode tuning to
> generate
> > 128-bit
> > > AVX instead of 256-bit AVX.
> >
> > You indicate a 3% reduction on bulldozer with avx256.
> > How does avx128 compare to -mno-avx -msse4.2?
>
> We see these % differences going from SSE42 to AVX128 to A
On 10/31/2011 04:24 PM, Paolo Carlini wrote:
Sure. Note anyway, that bits/c++config.h is already included, elsewhere
too in libsupc++.
I guess the other option would be to add it to install-freestanding-headers.
Jason
On 10/31/2011 04:09 PM, Paolo Carlini wrote:
... so today I noticed the c_inhibit_evaluation_warnings use in
cp_convert_and_check and occurred to me that we could use the existing
mechanism for this warning too?
The below still passes checking and my small set of tests...
I notice that this pa
On 10/31/2011 01:15 PM, Jakub Jelinek wrote:
> Hi!
>
> On Mon, Oct 31, 2011 at 12:43:14PM -0700, Richard Henderson wrote:
>> Renaming all of the insn patterns as needed to the standard
>> optab forms. Sadly, only one of the builtins is unused by
>> the various header files, so most of
On 10/31/2011 09:17 PM, Jason Merrill wrote:
On 10/31/2011 04:07 PM, Paolo Carlini wrote:
On 10/31/2011 08:37 PM, Jason Merrill wrote:
I have on occasion been confused by silently
becoming empty in C++98 mode. OK for trunk?
For c++98, I think we should use the usual:
#ifndef __GXX_EXPERIMENT
On 10/30/2011 10:54 AM, Richard Guenther wrote:
> On Sun, Oct 30, 2011 at 9:27 AM, Tom de Vries wrote:
>> On 10/30/2011 09:20 AM, Tom de Vries wrote:
>>> Richard,
>>>
>>> I have a fix for PR50878.
>>
>> Sorry, with patch this time.
>
> Ok for now, but see Davids mail and the complexity issue with
On 10/31/2011 04:07 PM, Paolo Carlini wrote:
On 10/31/2011 08:37 PM, Jason Merrill wrote:
I have on occasion been confused by silently
becoming empty in C++98 mode. OK for trunk?
For c++98, I think we should use the usual:
#ifndef __GXX_EXPERIMENTAL_CXX0X__
# include
#else
which we have in
Hi!
On Mon, Oct 31, 2011 at 12:43:14PM -0700, Richard Henderson wrote:
> Renaming all of the insn patterns as needed to the standard
> optab forms. Sadly, only one of the builtins is unused by
> the various header files, so most of them must stay around.
Thanks. Here is a patch that
... so today I noticed the c_inhibit_evaluation_warnings use in
cp_convert_and_check and occurred to me that we could use the existing
mechanism for this warning too?
The below still passes checking and my small set of tests...
What do you think?
Thanks,
Paolo.
//
Ind
On 10/31/2011 08:37 PM, Jason Merrill wrote:
I have on occasion been confused by silently
becoming empty in C++98 mode. OK for trunk?
For c++98, I think we should use the usual:
#ifndef __GXX_EXPERIMENTAL_CXX0X__
# include
#else
which we have in place elsewhere. Or we have special reasons f
On 10/31/2011 12:44 PM, 3dw...@verizon.net wrote:
For string and character literals, we can still just build up a call; we
only need to walk the overload list here for numeric literals.
I found that if you don't walk the overload list for chars, a char could be
routed to the operator taking wc
It does on my side:
=== g++ Summary ===
# of expected passes 122
I have no other change over the source.
Woah I hereby profess my love for Richard and Patrick. That didn't
sound, right, but whatever... During the weekend they apparently fixed
the rest of the bug I've been working on
I checked in the generic portion of Dmitry Plotnikov's patch
to the vectorizer and optabs that enables this patch. The ARM
portion of his patch is still outstanding, awaiting approval.
This allows this target hook to be removed from other targets.
Can I talk you into doing a similar patch for rs
I have on occasion been confused by silently becoming
empty in C++98 mode. OK for trunk?
Jason
commit 3d7ac3e4d8bb54921eb3e1f70b1a42a165ba4f5b
Author: Jason Merrill
Date: Mon Oct 31 01:21:49 2011 -0400
* libsupc++/initializer_list: Copy C++0x #error from
bits/c++0x_warning.h.
di
On 10/31/2011 03:21 PM, Aldy Hernandez wrote:
On 10/31/11 13:54, Patrick Marlier wrote:
This fixes the g++ pr45940-4 failure. I think it is due to the latest
merge.
Tested on i686. (I cannot test it yet on x86-64, I hope to get access to
a 64 bit soon...)
Patrick.
2011-10-31 Patrick Marlier
On 10/31/11 13:54, Patrick Marlier wrote:
This fixes the g++ pr45940-4 failure. I think it is due to the latest
merge.
Tested on i686. (I cannot test it yet on x86-64, I hope to get access to
a 64 bit soon...)
Patrick.
2011-10-31 Patrick Marlier
* ipa-inline.c: Adjust how cannot_inline is set
Hi,
here's an updated version of my patch that gets rid of _commit along
with a section in the manual describing data consistency and
durability issues.
See also the thread starting at
http://gcc.gnu.org/ml/fortran/2011-10/msg00079.html
and the latest mail in that thread with my current thinkin
This fixes the g++ pr45940-4 failure. I think it is due to the latest merge.
Tested on i686. (I cannot test it yet on x86-64, I hope to get access to
a 64 bit soon...)
Patrick.
2011-10-31 Patrick Marlier
* ipa-inline.c: Adjust how cannot_inline is set.
Index: ipa-inline.c
This is a fix for optimization flaw when dividing int by 2.
There is really no need for a library call. Costs of [U]DIV/[U]MOD are adjusted
to take into account the costs of CONST_INT operands that must be loaded for
division by means of libgcc call.
There are some new combiner patterns suffixed
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/28/11 15:07, Alexandre Oliva wrote:
> An assertion check meant to verify that var loc expansions that
> didn't involve VALUEs (say constants, REGs, etc) didn't push values
> onto the dependency stack failed in an expansion of the argp reg,
> beca
Rainer Orth writes:
> I made a quick comparison of the libtool.m4 in libgo/config with the
> 2.4.2 version: the only relevant change seems to be an instance of
> AC_PROG_GO, which also lives in go.m4. Ian will know why that
> additional copy is necessary.
The version of AC_PROG_GO in libgo/conf
On 10/21/2011 03:52 PM, Jason Merrill wrote:
On 10/21/2011 03:11 PM, Marc Glisse wrote:
Note that at least clang now defines __cplusplus to its new C++11 value
(in experimental C++0X mode only). Apparently they switched around last
June and say they are not the only ones. So if you want to follo
On 10/31/2011 06:39 AM, Paolo Carlini wrote:
Great. When you commit it, you can as well add 'PR c++/50920' to the
ChangeLog!
OK, here's what I'm checking in. There are a lot more instances of
C++0x in comments and cxx_dialect checks, but I'm not going to worry
about those now.
Tested x86_6
On Fri, Oct 28, 2011 at 11:21:23AM +0200, Richard Guenther wrote:
> On Thu, Oct 27, 2011 at 9:54 PM, Martin Jambor wrote:
> > Hi,
> >
> > On Thu, Oct 27, 2011 at 11:06:02AM +0200, Richard Guenther wrote:
> >> On Thu, Oct 27, 2011 at 1:22 AM, Martin Jambor wrote:
> >> > Hi,
> >> >
> >> > I've been
Hi,
How does it work to warn in convert_like_real instead?
the problem is that (expr, totype) can be a lot of different things for
which we want to warn, can be a zero and a pointer for assignments, but,
when totype is a BOOLEAN_TYPE expr can be an EQ_EXPR or NEQ_EXPR and
then the operands var
>
> Oct 31, 2011 11:56:59 AM, ja...@redhat.com wrote:
>
> On 10/30/2011 01:13 PM, Ed Smith-Rowland wrote:
> > + /* Look for a literal operator taking the exact type of numeric argument
> > + as the literal value. */
>
> Is this right? Do numeric literals only get here with type unsigned
Ian Lance Taylor writes:
> This patch updates the Go library to the most recent weekly release. I
> think the only potential portability issues here are the use of the
> ipv6_mreq struct. I'm not entirely sure the new exp/terminal package is
> portable, but it might be.
>
> I have not included
On 10/30/2011 01:13 PM, Ed Smith-Rowland wrote:
+ /* Look for a literal operator taking the exact type of numeric argument
+ as the literal value. */
Is this right? Do numeric literals only get here with type unsigned
long long or long double?
+ while (fns)
{
tree tmpl_a
Hi,
I'd like to revert the fix for PR 45723 that was committed previously
for the following reasons:
- Using stat("/path/to/file", ...) to infer something about an open
file descriptor is racy.
- As I argued in http://gcc.gnu.org/ml/fortran/2011-10/msg00133.html ,
I think the best approach is to
On Mon, Oct 31, 2011 at 03:23:32PM +0100, Jakub Jelinek wrote:
> Would be nice to cut down slightly this testcase into just one or two loops
> that are vectorized and turn it into a runtime testcase which verifies
> the vectorization was correct.
Here is one such testcase (though, in your case the
On Sun, Oct 30, 2011 at 01:29, Janne Blomqvist
wrote:
> On Sat, Oct 29, 2011 at 18:35, Mikael Morin wrote:
>> On Saturday 29 October 2011 14:43:22 Mikael Morin wrote:
>>> > FWIW, it seems ifort 12.0 uses "UNDEFINED" in this case; I suppose a
>>> > case could be made for using the same. Comments?
How does it work to warn in convert_like_real instead?
Jason
> Ok if you move the clearing to after
>
> /* Generate a new name for the new version. */
> DECL_NAME (new_decl) = clone_function_name (old_decl, clone_name);
> SET_DECL_ASSEMBLER_NAME (new_decl, DECL_NAME (new_decl));
> SET_DECL_RTL (new_decl, NULL);
>
> using new_decl directly, thus add
So I'm at the point where I'm reasonably happy with this work. This
patch doesn't do anything particularly clever regarding our
shrink-wrap implementation. We still only insert one copy of the
prologue, and one of the epilogue in thread_prologue_and_epilogue.
All it really does is replaces Bernd'
On Sat, Oct 29, 2011 at 03:53:37PM +0200, Toon Moene wrote:
> I wonder whether it will work with the attached Fortran routine - it
> sure would mean a boost to the 18%+ heaviest CPU user in our code.
It didn't do anything, but only because I used a bad approach in
vect_check_gather. I have been u
Markus Trippelsdorf writes:
> By popular demand, I've prepared a patch that updates the in-tree
> libtool to version 2.4.2. It is needed for lto-bootstrap with
> -fno-fat-lto-objects and FreeBSD10.x versions.
> It's a pretty big update as you can see by the following diffstat. I
> cannot attach
>2011-09-26 Jakub Jelinek
>
> * rtl.h (const_tiny_rtx): Change into array of 4 x MAX_MACHINE_MODE
> from 3 x MAX_MACHINE_MODE.
> (CONSTM1_RTX): Define.
> * emit-rtl.c (const_tiny_rtx): Change into array of 4 x MAX_MACHINE_MODE
> from 3 x MAX_MACHINE_MODE.
> (g
Fixes after davidxl review.
The patch is for google/main branch.
2011-10-31 Dmitriy Vyukov
* gcc/doc/invoke.texi:
* gcc/tree-tsan.c (enum tsan_ignore_type):
(struct bb_data):
(struct mop_desc):
(struct tsan_ignore_desc):
(lookup_name):
(
Tobias Burnus wrote:
I had also a glance at the patch - and it looks reasonable; in
particular, I failed to generate a failing test case.
Actually, the test case is *not* OK.
If one compiles the original test case of the PR (or your
workshare2.f90) with "-O" and looks at "-fdump-tree-original
On 31 October 2011 13:23, Jakub Jelinek wrote:
> On Mon, Oct 31, 2011 at 01:14:25PM +0200, Ira Rosen wrote:
>> > --- gcc/tree-vect-stmts.c.jj 2011-10-28 16:21:06.0 +0200
>> > +++ gcc/tree-vect-stmts.c 2011-10-31 10:27:57.0 +0100
>> > @@ -2446,7 +2446,10 @@ vectorizable_shi
On Mon, Oct 31, 2011 at 01:14:25PM +0200, Ira Rosen wrote:
> > --- gcc/tree-vect-stmts.c.jj 2011-10-28 16:21:06.0 +0200
> > +++ gcc/tree-vect-stmts.c 2011-10-31 10:27:57.0 +0100
> > @@ -2446,7 +2446,10 @@ vectorizable_shift (gimple stmt, gimple_
> > optab = optab_for_
On 31 October 2011 11:53, Jakub Jelinek wrote:
> On Sun, Oct 30, 2011 at 12:38:32AM -0400, David Miller wrote:
>> gcc.dg/pr48616.c segfaults on sparc as of a day or two ago
>>
>> vectorizable_shift() crashes because op1_vectype is NULL and
>> we hit this code path:
>>
>> /* Vector shifted by vec
On Sun, Oct 30, 2011 at 09:55:42PM -0400, David Miller wrote:
> --- a/gcc/dwarf2out.c
> +++ b/gcc/dwarf2out.c
> @@ -20149,7 +20151,35 @@ dwarf2out_var_location (rtx loc_note)
>if (var_loc_p && !DECL_P (NOTE_VAR_LOCATION_DECL (loc_note)))
> return;
>
> - next_real = next_real_insn (loc_n
On 10/25/2011 06:56 PM, Richard Earnshaw wrote:
On 24/10/11 14:30, Sebastian Huber wrote:
Hello,
what about the attached patch based on the original patch provided by Bernd
Schmidt with modifications suggested by Richard Earnshaw.
pr49641.patch
* config/arm/arm.c (store_multiple_se
On 10/31/2011 06:26 AM, Jason Merrill wrote:
Here's my start at adjusting things to use the C++11 name; feel free
to run with it.
Great. When you commit it, you can as well add 'PR c++/50920' to the
ChangeLog!
Paolo.
On Fri, Oct 28, 2011 at 07:07:18PM -0200, Alexandre Oliva wrote:
> for gcc/ChangeLog
> from Alexandre Oliva
>
> PR debug/50869
> * cselib.c (cfa_base_preserved_regno): Initialize.
> (cselib_expand_value_rtx_1): Don't expand it.
> * var-tracking.c (vt_expand_var_loc_chai
On Sun, Oct 30, 2011 at 12:38:32AM -0400, David Miller wrote:
> gcc.dg/pr48616.c segfaults on sparc as of a day or two ago
>
> vectorizable_shift() crashes because op1_vectype is NULL and
> we hit this code path:
>
> /* Vector shifted by vector. */
> if (!scalar_shift_arg)
> {
> op
> I'm suggesting a new patch, as attached. Before reload_completed, we
> directly return 0 upon nlabel == NULL, which should be identical with
> old behavior, while asserting fail if after reload (where we assume the
> simple_return/return distinction is required).
>
> This should ensure better tha
On 2011/10/25 02:04 AM, Bernd Schmidt wrote:
> On 10/24/11 20:02, Chung-Lin Tang wrote:
>> On 2011/10/18 04:03 PM, Eric Botcazou wrote:
thread_prologue_and_epilogue_insns should detect all cases where a
return insn can be created. So any CFG cleanup that runs before it does
not need
> -Original Message-
> From: Kai Tietz [mailto:ktiet...@googlemail.com]
> Sent: Thursday, October 27, 2011 5:36 PM
> To: Jiangning Liu
> Cc: Michael Matz; Richard Guenther; Kai Tietz; gcc-patches@gcc.gnu.org;
> Richard Henderson
> Subject: Re: [patch tree-optimization]: Improve handling o
On Mon, Oct 31, 2011 at 12:26 AM, Jason Merrill wrote:
> Here's my start at adjusting things to use the C++11 name; feel free to run
> with it.
>
> Looking at it again, I think adding __GXX_EXPERIMENTAL_CXX11__ is a mistake,
> we should just set __cplusplus to the C++11 value.
I tend to agree. T
81 matches
Mail list logo
