On Mon, Dec 12, 2011 at 06:05:57PM -0800, Sriraman Tallam wrote:
> Do not vectorize loops on Core2 that need to use unaligned
> vector load/stores.
> * tree-vect-stmts.c (is_slow_vect_unaligned_load_store): New function.
> (vect_analyze_stmt): Check if the vectorizable load/
> +/* Returns true if the vector load/store is unaligned and if
> + unaligned vector load/stores are slow. */
document STMT.
>
> +static bool
> +is_slow_vect_unaligned_load_store (gimple stmt)
> +{
> + stmt_vec_info stmt_info;
> + struct data_reference *dr = NULL;
> +
> + /* Are unaligned l
gcc-patches-ow...@gcc.gnu.org wrote on 13/12/2011 04:05:57 AM:
> On core2, unaligned vector load/store using movdqu is a very slow
operation.
> Experiments show it is six times slower than movdqa (aligned) and this is
> irrespective of whether the resulting data happens to be aligned or not.
> F
> And even this is insufficient, since you need to distinguish between multiple
> integer vector sizes and multiple fp vector sizes, aka AVX vs AVX2.
Should we introduce checks for each possible vector datatype (e.g.
vect_8byte_int_available, vect_16byte_int_available,
vect_32byte_int_available,
On 12/12/2011 08:00 PM, Andrew Pinski wrote:
On Mon, Dec 12, 2011 at 6:53 PM, Sandra Loosemore
wrote:
The test case in the attached patch gets stuck in an infinite loop in
find_comparison_args in CSE when compiled for MIPS at -O2. This bug has
been present at least as far back as GCC 4.5 and
Richard,
If you don't want to grab the L2 cache line size directly, could you
default to 32 bytes on PPC32 and 128 bytes on PPC64 (__powerpc64__) ?
Thanks, David
On Mon, Dec 12, 2011 at 8:16 PM, Richard Henderson wrote:
> One more try for ppc-linux plus ppc-darwin.
>
> I've taken care of the CA
On Mon, Dec 12, 2011 at 6:53 PM, Sandra Loosemore
wrote:
> The test case in the attached patch gets stuck in an infinite loop in
> find_comparison_args in CSE when compiled for MIPS at -O2. This bug has
> been present at least as far back as GCC 4.5 and probably much earlier than
> that.
>
> The
The test case in the attached patch gets stuck in an infinite loop in
find_comparison_args in CSE when compiled for MIPS at -O2. This bug has
been present at least as far back as GCC 4.5 and probably much earlier
than that.
The problem is that the inner loop over equivalences in the hash tabl
On core2, unaligned vector load/store using movdqu is a very slow operation.
Experiments show it is six times slower than movdqa (aligned) and this is
irrespective of whether the resulting data happens to be aligned or not.
For Corei7, there is no performance difference between the two and on AMDs
Hi,
This patch adds just octeon2 scheduling to GCC, it does not add
support for using the indexed based loads (which I am going to submit
separate).
OK? Bootstrapped and tested on mips64-linux-gnu (also tested with
-march=octeon2).
gcc/ChangeLog:
* config/mips/mips-cpus.def: Add Octeon2.
* conf
Ian,
As discussed several months ago, libgo will not run on mips because it
references the x86 specific system calls iopl() and ioperm(). These
system calls do not exist in mips*-linux, so we move them to new
368/amd64 specific libcall_linux_*.go files.
The attached patch was tested on x86_
One more try for ppc-linux plus ppc-darwin.
I've taken care of the CALL thing and the register naming thing
since last attempt.
This patch should apply vs mainline, but failing that please use
git://repo.or.cz/gcc/rth.git rth/tm-next
which is what I actually tested.
r~
diff --git a/libitm/c
Jonathan Wakely writes:
How about "...; suggest adding the using keyword"?
>>>
>>> That sounds like the compiler is suggesting that the user suggests
>>> doing that!
>>
>> It is similar to "suggest parentheses ...".
>
> Good point, that's not correct English either, but it would be consistent
Four small patches relative to the last set.
(1) Big thinko in how to set the EQ condition from the strex results.
And surprisingly that wrong condition PASSES a large portion of the
testsuite, by running through the ll/sc loop twice, with the first
time being truly successful and the
Rainer Orth writes:
> Ian Lance Taylor writes:
>
>> Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu. Tested
>> both with and without -fsplit-stack support. Committed to mainline.
>
> Once Go bootstrap works again on Solaris, I notice that there are many
> 64-bit testsuite failure
I committed a patch to libgo to update the release weekly.2011-11-18 in
the master library. As usual this patch is too large to include here in
its entirety. I've just included the changes to files specific to
libgo. Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu.
Committed to mai
On 12/12/2011 02:20 PM, Steve Ellcey wrote:
> /wsp/sje/gcc_reg/src/trunk/gcc/testsuite/gfortran.dg/maxloc_bounds_5.f90: In
> function 'foo':
> /wsp/sje/gcc_reg/src/trunk/gcc/testsuite/gfortran.dg/maxloc_bounds_5.f90:6:0:
> internal compiler error: in gsi_for_stmt, at gimple-iterator.c:560
> Pleas
On Mon, Dec 12, 2011 at 3:04 PM, Hans-Peter Nilsson
wrote:
> (Please don't forget to CC gcc-patches on replies. Thanks.)
>
>> From: Dmitriy Vyukov
>> Date: Mon, 12 Dec 2011 14:43:10 +0100
>
>> Fix flags for edges from/to entry/exit basic blocks.
>> W/o this patch I hit internal asserts when tryi
(Please don't forget to CC gcc-patches on replies. Thanks.)
> From: Dmitriy Vyukov
> Date: Mon, 12 Dec 2011 14:43:10 +0100
> Fix flags for edges from/to entry/exit basic blocks.
> W/o this patch I hit internal asserts when trying to
> split the edge from entry block.
>
> Index: gcc/cgraphunit.
On Thursday 08 December 2011 11:48:32 Rainer Orth wrote:
> Mike Frysinger writes:
> > Building newer libiberty for s390x targets fails with relocation errors:
> > libiberty/pic/libiberty.a(hashtab.o): In function 'htab_create':
> >
> > libiberty/hashtab.c:408:(.text+0x5e4): relocation
On 12/12/2011 04:59 PM, Fabien Chêne wrote:
I don't think so, if DECL_DEPENDENT_P is set, the target decl cannot
be determined.
Ah, I see. The patch is OK.
Jason
On Mon, 2011-12-12 at 12:02 -0800, Richard Henderson wrote:
> On 12/12/2011 08:59 AM, Steve Ellcey wrote:
> > Richard,
> >
> > I am hitting an assert in expand_vec_perm_even_odd on IA64 HP-UX with
> > your patch.
>
> Try this version.
>
>
> r~
I was able to bootstrap but while testing I am get
2011/12/12 Jason Merrill :
> On 12/11/2011 09:00 AM, Fabien Chêne wrote:
>>
>> Here, we weren't creating a typename_type for a dependent type
>> introduced by a using declaration. A USING_DECL was not recording the
>> fact that it refers to a dependent type, so I've created a new macro
>> USING_DEC
On Mon, Dec 12, 2011 at 12:41 PM, Paolo Carlini
wrote:
> On 12/12/2011 09:37 PM, Easwaran Raman wrote:
>>
>> Thanks for the comments Paolo. I have attached the new patch. I have
>> bumped the version to 3.4.18
>
> You shouldn't: 4.7 is not out yet, thus no reason to increase the minor
> version be
sure, OK, thanks for catching this leak.
Ayal.
On Mon, Dec 12, 2011 at 8:25 AM, Revital Eres wrote:
> Hello,
>
>> OK for 3.7?
>
> Sorry, I meant GCC 4.7.0...
>
> Thanks,
> Revital
On Mon, Dec 12, 2011 at 10:15 PM, Quentin Neill
wrote:
>>> I'm testing the patch in
>>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48743#c4 against trunk
>>
>>
>> --cut here--
>> --- gcc-4.7-20110521/gcc/config/i386/driver-i386.c.~1~ 2011-01-06
>> 23:59:46.0 +0100
>> +++ gcc-4.7-2011052
On Mon, Dec 12, 2011 at 3:00 PM, Uros Bizjak wrote:
> Hello!
>
>> I'm testing the patch in
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48743#c4 against trunk
>
>
> --cut here--
> --- gcc-4.7-20110521/gcc/config/i386/driver-i386.c.~1~ 2011-01-06
> 23:59:46.0 +0100
> +++ gcc-4.7-20110521
The following patch solves PR 21617 which is described on
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21617.
Just adding number of necessary hard registers solves the problem but
creates 2% SPEC2000 perlbmk degradation on x86. Fortunately, removing
allocno class comparison removes the degrada
Hello!
> I'm testing the patch in
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48743#c4 against trunk
--cut here--
--- gcc-4.7-20110521/gcc/config/i386/driver-i386.c.~1~ 2011-01-06
23:59:46.0 +0100
+++ gcc-4.7-20110521/gcc/config/i386/driver-i386.c.~1~ 2011-05-22
16:05:41.0 +0
On 12/12/2011 09:28 AM, Jakub Jelinek wrote:
> PR rtl-optimization/51495
> * function.c (thread_prologue_and_epilogue_insns): Don't add
> to bb_tail basic blocks that have EDGE_COMPLEX predecessor edges
> from basic blocks not needing prologue.
>
> * gcc.c-torture/com
On 12/12/2011 09:01 AM, Jakub Jelinek wrote:
> 2011-12-12 Jakub Jelinek
>
> PR tree-optimization/51481
> * gimple-fold.c (gimple_fold_call): Call
> maybe_clean_or_replace_eh_stmt. Avoid optimization if stmt has EH
> edges, but gimple_fold_builtin result can't throw.
>
On 12/12/2011 12:07 AM, Jakub Jelinek wrote:
> Which is why introducing
> vect_multiple_sizes_32B_16B (for -mno-prefer-128) and
> vect_multiple_sizes_16B_32B (for -mprefer-128) and using it in the tests
> could solve it.
And even this is insufficient, since you need to distinguish between multiple
On 12/12/2011 09:37 PM, Easwaran Raman wrote:
Thanks for the comments Paolo. I have attached the new patch. I have
bumped the version to 3.4.18
You shouldn't: 4.7 is not out yet, thus no reason to increase the minor
version beyond the current 17.
and used _ZdlPv[jmy] in gnu.ver. I have
also
Thanks for the comments Paolo. I have attached the new patch. I have
bumped the version to 3.4.18 and used _ZdlPv[jmy] in gnu.ver. I have
also added the symbol to baseline_symbols.txt of other targets.
-Easwaran
2011-12-11 Easwaran Raman
* common.opt (fsized-delete): New
Hi,
I'm testing the patch in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48743#c4 against trunk
Is this considered okay for stage3?
If so, okay to commit after bootstrap testing on x86_64?
--
Quentin
Hi,
This fixes a latent issue in arm_print_operand where we would have
generated a 128 bit alignment hint for any neon instruction that used
the %A notation for printing memory addresses.
Given that you can never have the load of a 64 bit quantity with an
128 bit alignment (indeed the list of ins
On 12/12/2011 08:59 AM, Steve Ellcey wrote:
> Richard,
>
> I am hitting an assert in expand_vec_perm_even_odd on IA64 HP-UX with
> your patch.
Try this version.
r~
commit 33c2ab861e7fea4b6c3fc6e64c43f6d94eff4dfb
Author: Richard Henderson
Date: Mon Dec 5 12:59:16 2011 -0800
ia64: Impleme
On Dec 7, 2011, at 3:59 AM, Georg-Johann Lay wrote:
> In principle, test case pr45830.c works for target avr, but there is an issue
> with the -ftree-switch-conversion optimization activated at higher
> optimization
> levels: It transforms code size into .data usage and thus exceeds AVRs' RAM
> si
On 12/11/2011 09:00 AM, Fabien Chêne wrote:
Here, we weren't creating a typename_type for a dependent type
introduced by a using declaration. A USING_DECL was not recording the
fact that it refers to a dependent type, so I've created a new macro
USING_DECL_TYPENAME_P to record that information (u
Hi,
committed as obvious.
2011-12-12 Janne Blomqvist
* gfortran.dg/nested_modules_2.f90: Tighten test.
Index: gfortran.dg/nested_modules_2.f90
===
--- gfortran.dg/nested_modules_2.f90(revision 182257)
+++ gfortran.
http://gcc.gnu.org/ml/gcc-patches/2011-12/msg00474.html
Georg-Johann Lay wrote:
> In principle, test case pr45830.c works for target avr, but there is an issue
> with the -ftree-switch-conversion optimization activated at higher
> optimization
> levels: It transforms code size into .data usage an
Ian Lance Taylor writes:
> Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu. Tested
> both with and without -fsplit-stack support. Committed to mainline.
Once Go bootstrap works again on Solaris, I notice that there are many
64-bit testsuite failures, which have been introduced be
This patch to libgo brings over a patch I just committed to the master
library. It deletes a temporary directory and file created during a
test. Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu.
Committed to mainline.
Ian
diff -r 864416b061a9 libgo/go/net/http/filetransport_test.go
Uros Bizjak writes:
> For some reason I get this failure on alphaev68-pc-linux-gnu:
>
> --- FAIL: runtime_test.TestGcSys (4.64 seconds)
> using 64 MB
> using too much memory: 64 MB
I see the same on Solaris/x86:
--- FAIL: runtime_test.TestGcSys (2.76 seconds)
using 63 MB
2011/12/12 Paolo Carlini :
> On 12/12/2011 06:45 PM, Marc Glisse wrote:
>>
>> Actually, g++ currently simply ignores the linkage as part of function
>> types, so this shouldn't have any effect.
>
> Also note that other systems have been using libsupc++ (without using the
> whole C++ lib), and I don
On 12/12/2011 06:45 PM, Marc Glisse wrote:
Actually, g++ currently simply ignores the linkage as part of function
types, so this shouldn't have any effect.
Also note that other systems have been using libsupc++ (without using
the whole C++ lib), and I don't think we should play dirty games here
OK.
Jason
On Mon, 12 Dec 2011, Paolo Carlini wrote:
On 12/12/2011 04:28 PM, Paolo Carlini wrote:
Hi,
Ok. By looking at this, it might be better to use here a define - as you
mentioned. As I would need to copy here namespace too.
Ok, thanks. Let's make sure nothing can possibly change for != mingw, we
On 12/12/2011 04:28 PM, Paolo Carlini wrote:
Hi,
Ok. By looking at this, it might be better to use here a define - as
you mentioned. As I would need to copy here namespace too.
Ok, thanks. Let's make sure nothing can possibly change for != mingw,
we don't want to take risks at this time.
For t
Hi!
On this testcase we ICE starting from
http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=181188
because one of the basic blocks we add to bb_tail has EDGE_ABNORMAL
edge (computed goto) from a basic block that doesn't need prologue.
We try to duplicate the basic block and finally redirect that ED
On 12/12/11 16:28, Andrew Stubbs wrote:
> On 07/12/11 13:42, Richard Earnshaw wrote:
>> So it looks like the code generated for core registers with thumb2 is
>> pretty rubbish (no real surprise there -- to get the best code you need
>> to make use of the fact that on ARM a shift by a small negative
This is not correct. First, _ITM_getTMCloneOrIrrevocable should never
appear in a __transaction_atomic (_ITM_getTMClone is ok).
But the problem here is that it fails to detect the clone because of the
alias. This is why we end up with a call to _ITM_getTMCloneOrIrrevocable.
Ah, I see.
Please
> > This patch just removes/restructures some of the doxygen markup to
> > avoid warnings when generating the documentation. Most of the
> > libstdc++ headers are pretty doxygen clean now.
>
> By the way, I recently made this feature request for Doxygen:
>
> https://bugzilla.gnome.org/show_bug.c
On 12/12/2011 11:19 AM, Aldy Hernandez wrote:
Yes the testcase attached in the PR works for me but I can't change the
status because I am not the reporter (nor admin).
I will close it.
Ok thanks.
However, the testcase I have added g++.dg/tm/ctor-used.C fails. I can
fill another PR but I f
On 12/12/2011 09:03 AM, Michael Matz wrote:
> Hmpf, I would have simply committed without a re-approval, but if you
> think it's necessary I'll wait.
The revised patch is ok too.
r~
Hi!
On
extern void baz (int);
template
void
f7 (int i, int x, int y)
{
#pragma omp parallel for
for (i = x - 10; i <= y + 10; i += N)
baz (i);
}
part of libgomp.c++/for-2.C testcase we now ICE, because the increment
expression contains IMPLICIT_CONV_EXPR. Fixed by also using
cp_parser_omp_
Hi,
On Mon, 12 Dec 2011, Jakub Jelinek wrote:
> Ok. So, I'm happy with your changes and rth already acked the tree-eh.c
> side, so can we just get an ack on these cfgexpand.c changes? Thanks.
Hmpf, I would have simply committed without a re-approval, but if you
think it's necessary I'll wait
ok for google/main.
David
http://codereview.appspot.com/5483046/
Hi!
In gimple_fold_call (called from fold_stmt from replace_uses_by from cfg
cleanup) we weren't calling maybe_clean_or_replace_eh_stmt, so when
we've replaced a printf call (which can throw) with puts (which can throw
too), nothing would update EH stmts. It would be problematic calling
gimple_pu
Richard,
I am hitting an assert in expand_vec_perm_even_odd on IA64 HP-UX with
your patch.
Using gcc.c-torture/compile/900116-1.c as a test case and compiling at
-O3 I get:
x.c: In function 'zloop':
x.c:3:1: internal compiler error: in expand_vec_perm_even_odd, at
config/ia64/ia64.c:11145
Please
Hi!
On ARM because -fstrict-volatile-bitfields is on we get a warning about
volatile access to unaligned field, this patch adds -w to avoid failing
because of that warning. Regtested on x86_64-linux and i686-linux
and with arm cross on the given testcase, committed as obvious.
2011-12-12 Jakub
Hi!
When idx is smaller than VEC_length (which happens when some pseudo
is set more than once in the tail call sequence), we should try to grow
the vector to smaller size than it has.
Bootstrapped/regtested on x86_64-linux and i686-linux, tested in arm cross
on the testcase mentioned in the PR wi
On Mon, Dec 12, 2011 at 05:29:09PM +0100, Michael Matz wrote:
> On Mon, 12 Dec 2011, Jakub Jelinek wrote:
> > Just I wonder:
> > 1) what if a bb contains no real insns (I know, they should be optimized
> >out, but do we assert that etc.?) - then the EXECUTE_IF_SET_IN_BITMAP
> >loop just wou
Hi,
On Mon, 12 Dec 2011, Jakub Jelinek wrote:
> Looks cleaner, yes.
> Just I wonder:
> 1) what if a bb contains no real insns (I know, they should be optimized
>out, but do we assert that etc.?) - then the EXECUTE_IF_SET_IN_BITMAP
>loop just wouldn't be done. Perhaps that is fine, it wou
On 07/12/11 13:42, Richard Earnshaw wrote:
So it looks like the code generated for core registers with thumb2 is
pretty rubbish (no real surprise there -- to get the best code you need
to make use of the fact that on ARM a shift by a small negative number
(< -128) will give zero. This gives us
On 11-12-12 11:18 , dvyu...@google.com wrote:
I've done full 3 stage build for all front-ends, then 'make bootstrap',
then diff output of 'make check-gcc -j16 RUNTESTFLAGS="dg.exp"' with
non-modified version. Everything passed successfully. All that on
Linux/amd64.
OK, thanks. That's enough.
On Mon, Dec 12, 2011 at 04:18:29PM +, Iain Sandoe wrote:
> thus is everyone reasonably happy with?
>
> Index: gcc/testsuite/c-c++-common/cxxbitfields-3.c
> ===
> --- gcc/testsuite/c-c++-common/cxxbitfields-3.c (revision 1822
Yes the testcase attached in the PR works for me but I can't change the
status because I am not the reporter (nor admin).
I will close it.
However, the testcase I have added g++.dg/tm/ctor-used.C fails. I can
fill another PR but I found this problem thanks to the PR testcase.
If you mean t
On 12 Dec 2011, at 15:47, Jakub Jelinek wrote:
On Mon, Dec 12, 2011 at 04:20:57PM +0100, Dominique Dhumieres wrote:
I'm fine with whatever you guys come up with...
Likewise. I have no preference. Whatever gets approved is ok
with me.
So let's pick the Iain's proposal:
Index: gcc/tests
On Mon, Dec 12, 2011 at 03:46:01PM +0100, Michael Matz wrote:
> > I had to tweak a little bit the expander conflict checking, because
> > if we have a BB with two incoming EH edges and clobber stmts from both
> > sunk into its beginning, then it would consider both variables (a and b
> > above) to
Hi,
On Fri, 9 Dec 2011, Georg-Johann Lay wrote:
> This is pretty much straight forward, and I don't understand the problems with
> - canonicalize stuff
> - optimize on canonicalized representation
> - lower canonicalized representation to best RTL
I don't think anyone would reject patches that d
On Mon, Dec 12, 2011 at 04:20:57PM +0100, Dominique Dhumieres wrote:
> > > I'm fine with whatever you guys come up with...
> >
> > Likewise. I have no preference. Whatever gets approved is ok with me.
>
> So let's pick the Iain's proposal:
>
> Index: gcc/testsuite/c-c++-common/cxxbitfields-3.c
Hi,
Ok. By looking at this, it might be better to use here a define - as
you mentioned. As I would need to copy here namespace too.
Ok, thanks. Let's make sure nothing can possibly change for != mingw, we
don't want to take risks at this time.
Paolo.
On 12 December 2011 12:42, Kai Tietz wrote:
>
> PR libstdc++/511135
> * libsupc++/cxxabi.h (__cxxabi_dtor_type): New type.
ChangeLog needs to be updated for the new type name (whether it ends
up being __cxa_dtor_type or something else).
2011/12/12 Paolo Carlini :
> Hi,
>
>> On Mon, 12 Dec 2011, Kai Tietz wrote:
>>
>>> Index: gcc/libstdc++-v3/libsupc++/cxxabi.h
>>> ===
>>> --- gcc.orig/libstdc++-v3/libsupc++/cxxabi.h
>>> +++ gcc/libstdc++-v3/libsupc++/cxxabi.h
>>> @@ -
> > I'm fine with whatever you guys come up with...
>
> Likewise. I have no preference. Whatever gets approved is ok with me.
So let's pick the Iain's proposal:
Index: gcc/testsuite/c-c++-common/cxxbitfields-3.c
===
--- gcc/testsui
Hi Richard,
Comments inline below..
On Sat, Dec 10, 2011 at 03:21:23PM -0800, Richard Henderson wrote:
> ---
> libitm/Makefile.am |3 +
> libitm/Makefile.in | 20 +++--
> libitm/config/arm/hwcap.cc | 67 +
> libitm/config/arm
On 12/11/11 16:51, Mike Stump wrote:
On Dec 9, 2011, at 11:45 AM, Aldy Hernandez wrote:
How about the patch below?
I'm fine with whatever you guys come up with...
Likewise. I have no preference. Whatever gets approved is ok with me.
I have committed attached patch for
http://gcc.gnu.org/gcc-4.7/changes.html#fortran
Tobias
Index: changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.7/changes.html,v
retrieving revision 1.67
diff -u -p -r1.67 changes.html
---
Hello,
On Fri, 9 Dec 2011, Jakub Jelinek wrote:
> I had to tweak a little bit the expander conflict checking, because
> if we have a BB with two incoming EH edges and clobber stmts from both
> sunk into its beginning, then it would consider both variables (a and b
> above) to be live at the same
On Mon, Dec 12, 2011 at 08:43, Dmitriy Vyukov wrote:
> Fix flags for edges from/to entry/exit basic blocks.
> W/o this patch I hit internal asserts when trying to
> split the edge from entry block.
Please specify how you tested it
(http://gcc.gnu.org/contribute.html#testing). OK for trunk, if
te
On Mon, Dec 12, 2011 at 5:25 AM, Paolo Carlini wrote:
>> I think being able to detect a final class is good enough for now,
>> until we find out if there are real problems being encountered as
>> people make more use of C++11.
>
> Maybe. But in my opinion we should not rush. Something is wrong he
Hi,
On Mon, 12 Dec 2011, Kai Tietz wrote:
Index: gcc/libstdc++-v3/libsupc++/cxxabi.h
===
--- gcc.orig/libstdc++-v3/libsupc++/cxxabi.h
+++ gcc/libstdc++-v3/libsupc++/cxxabi.h
@@ -51,6 +51,10 @@
#include
#include
+#ifndef _GLIBCXX
> Any update?
I will look into it today, but anyway I think it is stage1 material, so we have
some time to progress on it.
Honza
This is for google-main branch.
Fix compiler warnings in ThreadSanitizer tests.
Index: gcc/testsuite/ChangeLog.google-main
===
--- gcc/testsuite/ChangeLog.google-main (revision 182235)
+++ gcc/testsuite/ChangeLog.google-main (working
On Mon, 12 Dec 2011, Kai Tietz wrote:
Index: gcc/libstdc++-v3/libsupc++/cxxabi.h
===
--- gcc.orig/libstdc++-v3/libsupc++/cxxabi.h
+++ gcc/libstdc++-v3/libsupc++/cxxabi.h
@@ -51,6 +51,10 @@
#include
#include
+#ifndef _GLIBCXX_USE_
On Windows, the 'Count attribute was very slow in "Annex D" mode. This patch
fixes that efficiency problem. "Annex D" mode is invoked if there is a pragma
Task_Dispatching_Policy (FIFO_Within_Priorities).
Tested on i686-pc-mingw, committed on trunk
2011-12-12 Bob Duff
* s-taprop-mingw
Fix flags for edges from/to entry/exit basic blocks.
W/o this patch I hit internal asserts when trying to
split the edge from entry block.
Index: gcc/cgraphunit.c
===
--- gcc/cgraphunit.c(revision 182237)
+++ gcc/cgraphunit.c(
On Mon, Dec 12, 2011 at 12:40 PM, Eric Botcazou wrote:
>> Well, I can live with this change (though I cannot approve anything).
>> On the other hand, the real underlying problem is that expander cannot
>> handle unaligned MEM_REFs where strict alignment is required. SRA is
>> of course much more
On 12/12/2011 02:21 PM, Diego Novillo wrote:
Ah, right. I missed the ABI implications.
For possible inclusion in mainline too, things don't seem completely ok:
nothing should be added to the baseline and very likely the export
should be adjusted to accommodate for different size_t on the variou
2011/12/12 Paolo Carlini :
> PS: remember to adjust the Copyright years of eh_throw.cc and unwind-cxx.h.
> I would also mention the PR in the os_* files.
>
> Paolo.
Thanks for the reminder about copyright. Added comment about pr and
added copyright year to files not mentioning 2011.
Applied at re
On Mon, Dec 12, 2011 at 08:17, Paolo Carlini wrote:
> On 12/12/2011 02:14 PM, Diego Novillo wrote:
>>
>> On Sun, Dec 11, 2011 at 19:05, Easwaran Raman wrote:
>>
>>> Bootstraps and no test regressions. OK for google/gcc-4_6 branch?
>>
>> Any reason not to put this in google/main for future trunk i
On 12/12/2011 02:14 PM, Diego Novillo wrote:
On Sun, Dec 11, 2011 at 19:05, Easwaran Raman wrote:
Bootstraps and no test regressions. OK for google/gcc-4_6 branch?
Any reason not to put this in google/main for future trunk inclusion.
Should this be backported to gcc-4_6-branch?
Note that back
PS: remember to adjust the Copyright years of eh_throw.cc and
unwind-cxx.h. I would also mention the PR in the os_* files.
Paolo.
On Sun, Dec 11, 2011 at 19:05, Easwaran Raman wrote:
> Bootstraps and no test regressions. OK for google/gcc-4_6 branch?
Any reason not to put this in google/main for future trunk inclusion.
Should this be backported to gcc-4_6-branch?
Diego.
Hi,
So updated patch is:
Looks good to me. I guess that in principle we could try to have a macro
which is the typedef itself, but what you tested seems good enough to
resolve the PR.
Thanks,
Paolo.
2011/12/12 Paolo Carlini :
> On 12/12/2011 01:19 PM, Kai Tietz wrote:
>>
>> Well, this is mainly caused by different feature-set of runtimes. We
>> could solve things here also by probing for specific runtimes and so
>> using just on configure tree.
>
> Ah, thus, it's *not* true that mingw32, at va
On 12/12/2011 01:19 PM, Kai Tietz wrote:
Well, this is mainly caused by different feature-set of runtimes. We
could solve things here also by probing for specific runtimes and so
using just on configure tree.
Ah, thus, it's *not* true that mingw32, at variance with mingw32-w64, is
only used for
On Mon, Dec 12, 2011 at 02:16:04PM +0200, Ira Rosen wrote:
> Michael Zolotukhin wrote on 12/12/2011
> 01:57:09 PM:
>
> >
> > By the way, how could we check if '-mprefer-avx128' was specified from
> > target-supports.exp?
> >
>
> If I understand your question correctly, you can use check-flags (s
2011/12/12 Paolo Carlini :
> On 12/12/2011 12:58 PM, Kai Tietz wrote:
>>
>> Fine, nevertheless the test in os-config file for __i386__ is required, as
>> just for IA 32-bit this calling convention is for interest. Neither x64 nor
>> ARM etc requires it.
>
> So - just out of curiosity, ultimately yo
1 - 100 of 148 matches
Mail list logo
