On 11/02/2011 12:05 AM, Gabriel Dos Reis wrote:
And I think that "your code won't work in C++11" is
a warning that most C++ programmers will be interested in if they are asking
for warnings.
Even when -std=c++03 -Wall or -std=c++98 -Wall?
Yes. -Wc++0x-compat has been part of -Wall for almo
Uros Bizjak writes:
>> The problem with your proposal is that the output would be invalid Go,
>> because it would attempt to define the name _aa twice. However, it does
>> seem plausible that in most scenarios of this type it would be more
>> useful for -fdump-go-spec to generate
>>
>> const _aa
On Tue, Nov 01, 2011 at 02:00:25PM -0500, Peter Bergner wrote:
> (get_ppc476_thunk_name): New function.
> (rs6000_code_end): Likewise.
rs6000.c:27968:1: error: 'void rs6000_code_end()' defined but not used
[-Werror=unused-function]
cc1plus: all warnings being treated as errors
Bootst
Ooops, noticed some minor bits when I was regenerating the docs. Some
of the TR2 man pages needed munging, and the c++config bits for
versioning TR2 needed to go in.
tested x86/linux
best,
benjamin
2011-11-02 Benjamin Kosnik
* include/bits/c++config: Add tr2 to versioned namespaces.
Ok for google/main when the option is documented in doc/invoke.texi
and a Changlog file is provided.
David
On Tue, Nov 1, 2011 at 5:24 PM, wrote:
> So, do you have any other suggestions before the first commit?
>
> http://codereview.appspot.com/5272048/
>
On Tue, Nov 1, 2011 at 8:11 PM, Jason Merrill wrote:
> On 11/01/2011 03:48 PM, Gabriel Dos Reis wrote:
>>
>> On Tue, Nov 1, 2011 at 12:54 PM, Jason Merrill wrote:
>>>
>>> Paolo Carlini's patch to add -Wnarrowing to -Wc++0x-compat (and thus
>>> -Wall)
>>> broke bootstrap because of narrowing warni
Add merging of static_decls in bindings. Due to the current
structure, this change is currently only effective at namespace scope.
Consequently, there are no changes to test status. We may need to
make all bindings merged by default.
Index: gcc/cp/ChangeLog.pph
2011-11-01 Lawrence Crowl
On 11/01/2011 11:15 AM, Richard Henderson wrote:
On 11/01/2011 04:56 AM, Andrew MacLeod wrote:
well, the reason for it was so that __atomic_store can be used as a
replacement for sync_lock_release on such targets...
And what was your replacement for sync_test_and_set?
If you don't have that pa
Hi,
This patch is to fix PR38644 in ARM back-end. OK for trunk?
For every detail, please refer to
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38644.
ChangeLog:
2011-11-2 Jiangning Liu
PR rtl-optimization/38644
* config/arm/arm.c (thumb1_expand_epilogue): Add memory barrier
On 2 November 2011 00:53, Jonathan Wakely wrote:
> The first is that packaged_task's template constructors should
> be restricted to prevent them from being chosen to copy a
> packaged_task object
While submitting that issue to the LWG chair I realised the constraint
should use decay instead of re
On 11/01/2011 03:48 PM, Gabriel Dos Reis wrote:
On Tue, Nov 1, 2011 at 12:54 PM, Jason Merrill wrote:
Paolo Carlini's patch to add -Wnarrowing to -Wc++0x-compat (and thus -Wall)
broke bootstrap because of narrowing warnings, so I'd like to add
-Wno-narrowing to the stage 2+ warning flags. Is t
Committed under the "brought in via a merge" rule.
2011-11-01 DJ Delorie
* config.sub: Update to version 2011-10-29 (added rl78)
Imports this change:
2011-10-29 DJ Delorie
* config.sub (rl78): New.
This patch implements
http://lwg.github.com/issues/lwg-active.html#2067 which has Ready
status, as well as fixing two new issues I've reported in the past few
hours. The first is that packaged_task's template constructors should
be restricted to prevent them from being chosen to copy a
packaged_ta
Committed to trunk.
gcc/
* config/sparc/sparc.c (vector_init_faligndata): New function.
(sparc_expand_vector_init): Use it for V4HImode on VIS1.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@180752
138bc75d-0d04-0410-961f-82ee72b054a4
---
gcc/ChangeLog|3 +++
On Tue, 1 Nov 2011, Marc Glisse wrote:
> On Sun, 21 Aug 2011, Matthias Klose wrote:
>
> > On 08/20/2011 09:51 PM, Matthias Klose wrote:
> > > Multiarch [1] is the term being used to refer to the capability of a
> > > system to
> > > install and run applications of multiple different binary target
> (1) Are there really live v7 still around?
>
> At least with v8 we have SWAP, with which we can implement the full
> __atomic_exchange pattern sans hackery. We can't do that with just
> LDSTUB.
I think that we can drop v7 support at this point but not v8 because of Leon.
--
Eric Botca
> I've now committed the patch on 4.6 also. I did need to apply the
> following patch from Bernd in order to test the 4.6 branch tip
> successfully, since without it my build blew up in glibc with an error
> in final.c:
>
> http://gcc.gnu.org/ml/gcc-patches/2011-09/msg00454.html
>
> Maybe that pa
On Tue, Nov 1, 2011 at 11:00 PM, Jakub Jelinek wrote:
> On Tue, Nov 01, 2011 at 10:33:07PM +0100, Uros Bizjak wrote:
>> We have a nice utility function that can be used in int->float
>> splitter constraints.
>>
>> 2011-11-01 Uros Bizjak
>>
>> * config/i386/i386.md (splitters for int-float
Hi,
the patch below is the second (and last) revived type-based
devirtualization patch that did not make it to 4.6. It deals with
virtual calls from the function in which the there is also the object
declaration:
void foo()
{
A a;
a.foo ();
}
Normally, the front-end would do the devirtuali
On 26/10/11 10:15, Richard Earnshaw wrote:
Here's an updated patch that makes no generalizations.
OK?
Yep
Committed.
Andrew
On Tue, Nov 01, 2011 at 10:33:07PM +0100, Uros Bizjak wrote:
> We have a nice utility function that can be used in int->float
> splitter constraints.
>
> 2011-11-01 Uros Bizjak
>
> * config/i386/i386.md (splitters for int-float conversion): Use
> reg_or_subregno in splitter constra
Dear Tobias,
On 2011-11-01 22:33, Tobias Burnus wrote:
Regarding the tree-walking issue: I think it is a general issue which
could also affect other things. I really wonder why we haven't been
bitten by it before. However, it might be that we hit those problems and
fixed them by "re"-resolving
Dear all, dear Paul,
(For gcc-patch@ readers: gfortran has issues with tree walking: During
traversal it does not touch all tree nodes if the function called during
traversal adds new nodes to the tree - as this will rebalance the tree.
This causes a regression with my recently posted RFC patc
Hello!
We have a nice utility function that can be used in int->float
splitter constraints.
2011-11-01 Uros Bizjak
* config/i386/i386.md (splitters for int-float conversion): Use
reg_or_subregno in splitter constraints.
Bootstrapped and regression tested on x86_64-pc-linux-gn
On Sat, Oct 29, 2011 at 1:06 AM, Matt wrote:
> On Sat, 29 Oct 2011, Maxim Kuvyrkov wrote:
>
>>> I like this variant a lot better than the last one - still it lacks any
>>> analysis-based justification for iteration (see my reply to Matt on
>>> what I discussed with Honza).
>>
>> Yes, having a way
Dear Mikael,
> PS: I hereby confess my failure to not split the patch too much. :-(
I hereby confess my failure to find anything to which I could gripe,
let alone object!
The patch can only be described as a tour de force. Not only is there
a lot of it - 6160 lines with context on - but it is
From: Richard Henderson
Date: Tue, 01 Nov 2011 13:48:26 -0700
> (2) Can we have the kernel implement some {SWAP,CAS}{4,8} primitives (possibly
> via a special trap) that we can export from libgcc, as we do for ARM, PA,
> & SH?
>
> I believe that would allow all of the non-embedded linux
Hi,
On Tue, Nov 01, 2011 at 10:37:10AM +0100, Richard Guenther wrote:
> On Mon, Oct 31, 2011 at 5:58 PM, Martin Jambor wrote:
> > 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,
On 11/01/2011 01:20 PM, David Miller wrote:
> Unfortunately, this is not true.
>
> Otherwise we could change the 32-bit default code generation to
> v9 from v7 under Linux.
For v7, pa-risc, and sh, we originally allowed the test_and_set and
lock_release patterns to do non-obvious things with 0/1
Le 28/10/2011 17:41, Iain Sandoe a écrit :
This is unreviewed for 2 weeks.
I am sure that this issue will be affecting Ada on Darwin10/11 with
the latest toolchains.
It's actually under discussion and is pretty subtle, so delicate. Thanks
for your patience.
Arno
Hi,
On Fri, Oct 28, 2011 at 04:06:20PM -0700, Matt wrote:
>
...
>
> I agree (of course). Having the knob will be very useful for testing
> and determining the acceptance criteria for the later "smartness".
> While terminating early would be a nice optimization, the feature is
> still intrinsical
From: Richard Henderson
Date: Tue, 01 Nov 2011 08:15:51 -0700
> Given that I believe that essentially all Sparcs still running
> are actually v9 and have native CAS, I think we can ignore this
> problem entirely.
Unfortunately, this is not true.
Otherwise we could change the 32-bit default code
Hello!
Fix a typo.
2011-10-30 Uros Bizjak
PR target/50940
* config/i386/i386.md (floatsi2_vector_sse_with_temp splitter):
Compare mode with V4SFmode, not V4SImode.
Tested on x86_64-pc-linux-gnu, committed to mainline SVN.
Uros.
Index: config/i386/i386.md
On Tue, Nov 1, 2011 at 12:54 PM, Jason Merrill wrote:
> Paolo Carlini's patch to add -Wnarrowing to -Wc++0x-compat (and thus -Wall)
> broke bootstrap because of narrowing warnings, so I'd like to add
> -Wno-narrowing to the stage 2+ warning flags. Is this the best way to do
> that?
why do we wan
On Tue, Nov 1, 2011 at 12:41 PM, Diego Novillo wrote:
> On 11-11-01 15:34 , Xinliang David Li wrote:
>
>>> Right before pass_expand? In init_optimization_passes(), look for
>>> NEXT_PASS
>>> (pass_expand). That's RTL generation. Somewhere before that.
>>>
>>
>> Why?
>
> The idea was to experime
On Sun, 21 Aug 2011, Matthias Klose wrote:
On 08/20/2011 09:51 PM, Matthias Klose wrote:
Multiarch [1] is the term being used to refer to the capability of a system to
install and run applications of multiple different binary targets on the same
system. The idea and name of multiarch dates bac
On 11-11-01 15:34 , Xinliang David Li wrote:
Right before pass_expand? In init_optimization_passes(), look for NEXT_PASS
(pass_expand). That's RTL generation. Somewhere before that.
Why?
The idea was to experiment where to best place ASAN to avoid
instrumenting too much. If we schedule
On Tue, Nov 1, 2011 at 12:26 PM, Martin Jambor wrote:
> Hi,
>
> sorry that I'm not using the fancy web tool but I do not want to use
> my google account and gmail address in particular for work-related
> stuff.
>
> On Tue, Nov 01, 2011 at 06:05:46PM +, davi...@google.com wrote:
>>
>
> ...
>
>>
On Tue, Nov 1, 2011 at 12:16 PM, Diego Novillo wrote:
> On 11-11-01 15:11 , konstantin.s.serebry...@gmail.com wrote:
>>
>> Diego mentioned that we can move the asan pass somewhere to the very
>> end, just before lowering to RTL.
>> Where would be this blessed place?
>> Does it still have TARGET_ME
On 11-11-01 15:26 , Martin Jambor wrote:
Hi,
sorry that I'm not using the fancy web tool but I do not want to use
my google account and gmail address in particular for work-related
stuff.
No worries. You do not need to use the web tool at all. You can simply
reply to these messages.
As lo
Hi,
sorry that I'm not using the fancy web tool but I do not want to use
my google account and gmail address in particular for work-related
stuff.
On Tue, Nov 01, 2011 at 06:05:46PM +, davi...@google.com wrote:
>
...
>
> http://codereview.appspot.com/5303083/diff/1/gcc/tree-tsan.c#newcode6
On Tue, Nov 1, 2011 at 2:35 PM, Jakub Jelinek wrote:
>> > Similarly to the V{4,8}SFmode -> unsigned V{4,8}SImode conversion
>> > support for AVX this one adds V{2,4}DFmode -> unsigned V{4,8}SImode
>> > conversion.
>> >
>> > Ok for trunk?
>>
>> Please put expander function into i386.c. IMO, this e
On 11-11-01 15:11 , konstantin.s.serebry...@gmail.com wrote:
Diego mentioned that we can move the asan pass somewhere to the very
end, just before lowering to RTL.
Where would be this blessed place?
Does it still have TARGET_MEM_REF?
Right before pass_expand? In init_optimization_passes(), loo
On Mon, 2011-10-31 at 19:05 -0400, David Edelsohn wrote:
> Okay, go ahead with PPC64 support as well. Hopefully no one ever will
> have to use it. That implies the option should not explicitly
> reference ppc476.
Ok, for completeness, I attached what I committed below, which includes
the support
On Fri, 28 Oct 2011 11:53:41 +0100
Julian Brown wrote:
> On Tue, 25 Oct 2011 14:49:09 +0200
> Eric Botcazou wrote:
>
> > These labels are on the nonlocal_goto_handler_labels chain. You
> > presumably just need to apply the same treatment to them in
> > set_initial_label_offsets as the one appl
Hi,
the attached patch changes the backtracing functionality, which is
used to print a stack trace before aborting when something goes
belly-up, to use the stack unwinding functionality provided by libgcc
instead of using the glibc backtrace_symbols and backtrace_symbols_fd
functions, or the "psta
http://codereview.appspot.com/5303083/diff/1/gcc/tree-tsan.c
File gcc/tree-tsan.c (right):
http://codereview.appspot.com/5303083/diff/1/gcc/tree-tsan.c#newcode432
gcc/tree-tsan.c:432: /* Builds either (__tsan_shadow_stack += 1) or
(__tsan_shadow_stack -= 1) expression
Line too long.
http://code
Paolo Carlini's patch to add -Wnarrowing to -Wc++0x-compat (and thus
-Wall) broke bootstrap because of narrowing warnings, so I'd like to add
-Wno-narrowing to the stage 2+ warning flags. Is this the best way to
do that?
Jason
diff --git a/gcc/configure.ac b/gcc/configure.ac
index d63acea..6f
On Nov 1, 2011, at 10:13 AM, Jonathan Wakely wrote:
>> I suspect on some systems, this would be a runtime value so, no fixed
>> constant could ever work.
>
> It's a constant for identifying the sysctl, not a constant for the
> number of processors e.g. (untested)
Ah, never mind, ignore me.
http://codereview.appspot.com/5303083/diff/3002/gcc/tree-tsan.c
File gcc/tree-tsan.c (right):
http://codereview.appspot.com/5303083/diff/3002/gcc/tree-tsan.c#newcode1075
gcc/tree-tsan.c:1075: for (eidx = 0; VEC_iterate (edge, exit_bb->preds,
eidx, e); eidx++)
Use FOR_EACH_EDGE macro
http://code
On 1 November 2011 17:06, Mike Stump wrote:
> On Nov 1, 2011, at 8:55 AM, Jonathan Wakely wrote:
>> Is there a reason you used "hw.ncpu" not the constant HW_NCPU ?
>
> I suspect on some systems, this would be a runtime value so, no fixed
> constant could ever work.
It's a constant for identi
On Nov 1, 2011, at 8:55 AM, Jonathan Wakely wrote:
> Is there a reason you used "hw.ncpu" not the constant HW_NCPU ?
I suspect on some systems, this would be a runtime value so, no fixed
constant could ever work.
that means some existing bugs get exposed. Your previous version
simply skipped the target mem refs. You will need to debug the
problem a little more.
David
On Tue, Nov 1, 2011 at 5:26 AM, wrote:
> On 2011/10/31 06:08:34, davidxl wrote:
>>
>> http://codereview.appspot.com/5303083/diff/1/gcc/pa
On Nov 1, 2011, at 4:27 AM, Andrew Haley wrote:
> On 10/30/2011 01:51 PM, Gerald Pfeifer wrote:
>> Why not just declare
>> that building from the same directory is not support and have one
>> simple set of instructions that always works, as opposed to "this
>> ought to work with snapshots but not w
On Tue, 1 Nov 2011, Joseph S. Myers wrote:
>> + # Check for C library flavor since GNU/Linux platforms use different
>> + # configuration directories depending on the C library in use.
> I think this is a case that is definitely referring to platforms using the
> Linux kernel and not restricted
On 1 November 2011 16:01, Jonathan Wakely wrote:
> On 1 November 2011 15:57, niXman wrote:
>>> What header is required for pthread_num_processors_np?
>> pthread.h
>
> OK.
>
> This assumes that Pthreads is the only abstraction available on __hpux
> (i.e. that if _GLIBCXX_HAS_GTHREADS is true then we
On Tue, 1 Nov 2011, Gerald Pfeifer wrote:
> - # Check for C library flavor since Linux platforms use different
> configuration
> - # directories depending on the C library in use.
> + # Check for C library flavor since GNU/Linux platforms use different
> + # configuration directories dependin
On 1 November 2011 15:57, niXman wrote:
>> What header is required for pthread_num_processors_np?
> pthread.h
OK.
This assumes that Pthreads is the only abstraction available on __hpux
(i.e. that if _GLIBCXX_HAS_GTHREADS is true then we have already
included ):
+#if defined(PTW32_VERSION) || \
+
Any comments on the expectation, or implementation of signal-fence below?
Should I make the distinction between the memory models here at all?
At minimum there's another typo in the ifdef section; we really need to
minimize those...
r~
diff --git a/gcc/builtins.c b/gcc/builtins.c
index 756070f..
Ok. I correct it.
2011/11/1 Jonathan Wakely :
> I've put gcc-patches@ back in the CC list and removed gcc@
>
>
> On 1 November 2011 15:35, niXman wrote:
>>> Er, the macro _GLIBCXX_NPROCS already handles
>>> the case sysconf(_SC_NPROCESSORS_ONLN).
>>> It looks like you actually want to remove the m
> What header is required for pthread_num_processors_np?
pthread.h
> Also, you should include before calling sysctlbyname.
On the right - yes.
sysctlbyname() implicitly included in some header files.
Is there a reason you used "hw.ncpu" not the constant HW_NCPU ?
On 1 November 2011 15:47, Jonathan Wakely wrote:
> I've put gcc-patches@ back in the CC list and removed gcc@
Oops, *now* I've removed gcc@
> On 1 November 2011 15:35, niXman wrote:
>>> Er, the macro _GLIBCXX_NPROCS already handles
>>> the case sysconf(_SC_NPROCESSORS_ONLN).
>>> It looks like yo
I've put gcc-patches@ back in the CC list and removed gcc@
On 1 November 2011 15:35, niXman wrote:
>> Er, the macro _GLIBCXX_NPROCS already handles
>> the case sysconf(_SC_NPROCESSORS_ONLN).
>> It looks like you actually want to remove the macro
>> _GLIBCXX_NPROCS completely.
>
> Fixed.
No, this
With what exactly do you don't accept this patch?
2011/11/1 Jonathan Wakely :
> On 1 November 2011 11:54, Marc Glisse wrote:
>> On Tue, 1 Nov 2011, niXman wrote:
>>
>>> diff --git a/libstdc++-v3/src/thread.cc b/libstdc++-v3/src/thread.cc
>>> index 09e7fc5..6feda4d 100644
>>> --- a/libstdc++-v3/sr
On Tue, Nov 01, 2011 at 12:57:22AM +1030, Alan Modra wrote:
> Bits left to do
> - limit size of duplicated tails
Done here. Also fixes a hole in that I took no notice of
targetm.cannot_copy_insn_p when duplicating tails.
One interesting result is that the tail duplication actually reduces
the te
On 1 November 2011 11:54, Marc Glisse wrote:
> On Tue, 1 Nov 2011, niXman wrote:
>
>> diff --git a/libstdc++-v3/src/thread.cc b/libstdc++-v3/src/thread.cc
>> index 09e7fc5..6feda4d 100644
>> --- a/libstdc++-v3/src/thread.cc
>> +++ b/libstdc++-v3/src/thread.cc
>> @@ -112,10 +112,20 @@ _GLIBCXX_BEGIN
On 11/01/2011 06:35 AM, Jakub Jelinek wrote:
> ... disadvantage is that the stmts in the new
> pattern are now in vcmppd; vandpd; vaddpd; vcmppd; vandpd; vaddpd order
> instead of vcmppd; vcmppd; vandpd; vandpd; vaddpd; vaddpd; (not sure why
> the scheduler didn't change it, but on the other side i
On Mon, 31 Oct 2011, Markus Trippelsdorf wrote:
> 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.
For the record, older versions of libtool have reference
Applied, based on ongoing exchange with RMS.
Gerald
2011-10-31 Gerald Pfeifer
* acinclude.m4 (GLIBCXX_CONFIGURE): Refer to GNU/Linux.
* configure: Regenerate.
Index: acinclude.m4
===
--- acinclude.m4(rev
...at least somwhat, and also to then serve as a better template
for the following release.
Sort ARM, MIPS and picochip alphabetically, add an anchor for MIPS.
Comment out empty sections.
Applied.
Gerald
Index: changes.html
===
RCS
On 11/01/2011 04:56 AM, Andrew MacLeod wrote:
> well, the reason for it was so that __atomic_store can be used as a
> replacement for sync_lock_release on such targets...
And what was your replacement for sync_test_and_set?
If you don't have that pair, you don't have a replacement.
> Im just con
That does not fix the fact that the status is not up-to-date, but
makes things more consistent and easier to carry along in case of
future updates.
Applied.
Gerald
2011-11-01 Gerald Pfeifer
* status.html: Use instead of fake tables.
Index: status.html
=
OK.
Jason
On 10/29/2011 05:07 PM, Eric Botcazou wrote:
DR 1082 changed the rules for implicitly declared copy constructors and
assignment operators in the presence of move ctor/op= such that if
either move operation is present, instead of being suppressed the copy
operations will still be declared, but as
Hi Richard,
Once we have a uniform way to emit notes to either stderr or dump, as
you and David had discussed in the earlier thread, we can merge these
two messages. The advantage with the new messages, besides going to
stderr, is that the source position information is being emitted since
it is a
On Tue, Nov 01, 2011 at 11:16:07AM +0100, Uros Bizjak wrote:
> On Tue, Nov 1, 2011 at 10:07 AM, Jakub Jelinek wrote:
>
> > Similarly to the V{4,8}SFmode -> unsigned V{4,8}SImode conversion
> > support for AVX this one adds V{2,4}DFmode -> unsigned V{4,8}SImode
> > conversion.
> >
> > Ok for trunk
Hi,
Here is a patch which fixes redundant zero extensions problem. Issue
is resolved by expanding implicit_zee pass functionality to cover zero
and sign extends of different modes. Could please someone review it?
Bootstrapped and checked on linux-x86_64.
Thanks,
Ilya
---
2011-11-01 Enkovich Ily
On 11/01/2011 12:50 AM, Richard Henderson wrote:
* 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 i
On Tue, 1 Nov 2011, niXman wrote:
diff --git a/libstdc++-v3/src/thread.cc b/libstdc++-v3/src/thread.cc
index 09e7fc5..6feda4d 100644
--- a/libstdc++-v3/src/thread.cc
+++ b/libstdc++-v3/src/thread.cc
@@ -112,10 +112,20 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
unsigned int
thread::hardware_concurre
On 10/30/2011 01:51 PM, Gerald Pfeifer wrote:
> Why not just declare
> that building from the same directory is not support and have one
> simple set of instructions that always works, as opposed to "this
> ought to work with snapshots but not with direct checkouts"?
That's right. Is there ever a
Hi,
With the recent patches for __restrict__, the outer loop in
gcc.dg/vect/no-scevccp-outer-6-global.c is now vectorizable, because
it doesn't require loop versioning for alias anymore. The comment in
the test is probably obsolete, and checking for widen-mult doesn't
make much sense, because the
On 11/01/2011 12:33 PM, niXman wrote:
Rechecked.
Stylistically, you are missing a lot of spaces around the operators, eg:
return (count > 0) ? count : 0;
also, patches are always submitted with a ChangeLog entry.
Do you have already a Copyright assignment in place? I'm asking in
general,
Hi,
attached patch committed to trunk as obvious after regtesting.
2011-11-01 Janne Blomqvist
* io/io.h (next_available_newunit): Remove prototype.
* io/unit.h (next_available_newunit): Make variable static,
initialize it.
(init_units): Don't initialize next_av
Rechecked.
diff --git a/libstdc++-v3/src/thread.cc b/libstdc++-v3/src/thread.cc
index 09e7fc5..6feda4d 100644
--- a/libstdc++-v3/src/thread.cc
+++ b/libstdc++-v3/src/thread.cc
@@ -112,10 +112,20 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
unsigned int
thread::hardware_concurrency() noexcept
{
-
Hello!
> > 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
Hi,
this is what I finished testing and I'm submitting for review. In the
meanwhile I found another place, in build_ptrmemfunc, which requires
internally using nullptr_node, otherwise we have a duplicate diagnostics
for member function pointers; also, simplified a tad the
cp_build_binary_op b
On Tue, Nov 1, 2011 at 10:07 AM, Jakub Jelinek wrote:
> Similarly to the V{4,8}SFmode -> unsigned V{4,8}SImode conversion
> support for AVX this one adds V{2,4}DFmode -> unsigned V{4,8}SImode
> conversion.
>
> Ok for trunk?
Please put expander function into i386.c. IMO, this expander can be
bett
2011/11/1 Georg-Johann Lay :
> Denis Chertykov schrieb:
>>
>> 2011/10/31 Georg-Johann Lay:
>>
>>> Since beginning of time, BRANCH_COST was set to 0 so that some
>>> optimization
>>> passes make code happily jumping around. The patch introduces a new
>>> command
>>> line option for that; mainly beca
On Thu, Oct 27, 2011 at 6:42 PM, Uros Bizjak wrote:
>> 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 mig
On Tue, Nov 1, 2011 at 1:46 AM, Teresa Johnson wrote:
> 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 (f
On Mon, Oct 31, 2011 at 9:36 PM, Jagasia, Harsha wrote:
>> > > 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?
On Mon, Oct 31, 2011 at 9:19 PM, Tom de Vries wrote:
> 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.
>>
On Mon, Oct 31, 2011 at 5:58 PM, Martin Jambor wrote:
> 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:2
Denis Chertykov schrieb:
2011/10/31 Georg-Johann Lay:
Since beginning of time, BRANCH_COST was set to 0 so that some optimization
passes make code happily jumping around. The patch introduces a new command
line option for that; mainly because I don't know the rationale behind setting
BRANCH_COS
Use -Aleon to enable binutils sparc-leon architecture. The leon-arch
binutils GAS has umul/smul and casa enabled.
Signed-off-by: Konrad Eisele
---
gcc/config/sparc/sparc.h |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/gcc/config/sparc/sparc.h b/gcc/config/sparc/spar
Hi!
Similarly to the V{4,8}SFmode -> unsigned V{4,8}SImode conversion
support for AVX this one adds V{2,4}DFmode -> unsigned V{4,8}SImode
conversion.
Ok for trunk?
2011-11-01 Jakub Jelinek
* config/i386/sse.md (ssepackfltmode): New mode attr.
(vec_pack_ufix_trunc_): New expan
This patch makes emit_inc_dec_insn_before use add3_insn / gen_move_insn
so that the appropriate expanders are used to create the new instructions,
and for dse it use the available register liveness information to check
that no live fixed hard register, like a flags register, is clobbered in the
pr
I really wanted to make this work using the define_expand rtl to
generate the pattern, but I ran into two problems:
1) In addition to mode "GCM", we also need to iterate over "P" mode
for the sake of the rtl of fpcmp and cmask. So we'd get dups in
the insn output files.
2) I couldn't subs
2011/10/31 Georg-Johann Lay :
> 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.
>
> T
100 matches
Mail list logo
