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
OK.
Jason
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
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
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
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
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
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
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.
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
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/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
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
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
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
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
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: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 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
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
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
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
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
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 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
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, 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
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 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
(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 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
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
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
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
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
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
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
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_
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
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
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 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
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 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
> 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,
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
> +/* 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
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/
101 - 148 of 148 matches
Mail list logo
