Thanks for inputs! I'll do it today.
Just ine point.
How AVX is connected to LZCNT features?
AVX requires OS support since it has wider registers etc.
LZCNT need no support from OS side, so from my point of view it is
redundant to check in lzcnt-check.h presence of AVX support from OS
side.
Or I g
Thanks. I'll commit to trunk in the morning when I can be around to
watch for breakage.
Is this also ok for gcc-4_6-branch?
On Tue, Jul 26, 2011 at 7:16 PM, Jason Merrill wrote:
> Ok.
>
> Jeffrey Yasskin wrote:
>
> Hi Jason. Paolo suggested I ping you directly about this patch for the
> C++ par
On Wed, Jul 27, 2011 at 9:05 AM, Kirill Yukhin wrote:
> Thanks for inputs! I'll do it today.
>
> Just ine point.
> How AVX is connected to LZCNT features?
> AVX requires OS support since it has wider registers etc.
> LZCNT need no support from OS side, so from my point of view it is
> redundant to
On 07/26/2011 10:11 PM, Daniel Carrera wrote:
The attached patch fixes PR 49755, allowing GFortran to behave
correctly when faced with multiple allocations:
Ok for trunk?
* trans-array.c (gfc_array_init_size): New parameter "desciptor_block".
Typo: desc(r)iptor_block.
* tran
On Tue, 26 Jul 2011, Sebastian Pop wrote:
> On Tue, Jul 26, 2011 at 10:56, Sebastian Pop wrote:
> > On Tue, Jul 26, 2011 at 10:43, Richard Guenther wrote:
> >> Please make graphite more robust instead.
> >
> > Ok, in this case, what about setting gloog_error and stopping the code
> > generation
On Wed, Jul 27, 2011 at 6:31 AM, H.J. Lu wrote:
> The offsetted memory references always work for x32. OK for trunk?
No, this is the same issue as in [1]. Please fix the assembler to
zero-extend this relocation.
[1] http://gcc.gnu.org/ml/gcc-patches/2011-07/msg01825.html
Uros,
On Tue, Jul 26, 2011 at 6:56 PM, Ulrich Weigand wrote:
> Michael Matz wrote:
>> On Tue, 26 Jul 2011, Michael Matz wrote:
>> > On Tue, 26 Jul 2011, Ulrich Weigand wrote:
>> >
>> > > > Well, REG_ATTRS->decl is again a decl, not an SSA name. I suppose
>> > > > we'd need to pick a conservative REGNO_
On Tue, Jul 26, 2011 at 8:07 PM, Sebastian Pop wrote:
> On Tue, Jul 26, 2011 at 08:30, Richard Guenther
> wrote:
>> I suppose we also need to allow POINTER_TYPE_P here (but then
>> treat it like an unsigned variable of the same width).
>
> Updated patch. Ok for trunk after regstrap?
+ uns
On Wed, Jul 27, 2011 at 8:33 AM, Kai Tietz wrote:
> I adjusted logic in patch for interger zero/all-one case for bit
> and/or. By simply copying the variable operand to destination,
> without checking for valid ranges for and-expression with all-ones and
> or-expression with zero operand, logic
On Tue, 2011-07-26 at 21:20 -0400, Andrew MacLeod wrote:
> This patch is simply the documentation for extend.texi which adds a
> section about the new memory model __sync_mem routines. I've supplied
> the .info output since its easier to read, followed by the patch
>
> OK for the branch?
I thi
On 07/27/2011 09:58 AM, Tobias Burnus wrote:
Typo: desc(r)iptor_block.
Fixed.
You can combine changes different functions in a single file as in
* trans-openmp.c (gfc_omp_clause_default_ctor,
gfc_omp_clause_copy_ctor, gfc_trans_omp_array_reduction): ...
Fixed.
* gfortran.dg/multiple_allo
Hello,
this patch allows the function attributes sysv_abi/ms_abi also for 32-bit.
Additionally it allows the switch -mabi for 32-bit i386 targets, too.
This patch completes the GNU/MS abi switching support for 32-bit. Main
difference for 32-bit is the caller/callee pops hidden aggregate pointe
Hi!
During testing of a backport I've realized that -fverbose-asm is another
gcc option that doesn't make sense to preserve in DW_AT_producer, it doesn't
affect the generated code, just how the assembly is commented.
Tested on x86_64-linux, committed as obvious to trunk:
2011-07-27 Jakub Jelinek
Hello,
this patch correct the function meltgc_string_hex_md5sum_file_sequence,
it now returns the same than "cat myfile1 myfile2 ... | md5sum".
fread was not correctly used + it looks like you can't mix function
md5_process_bytes and md5_process_blocks.
Pierre Vittet
Index: gcc/melt-runtime.c
On Tue, 2011-07-19 at 01:22 +0200, Torvald Riegel wrote:
> On Tue, 2011-07-19 at 01:19 +0200, Torvald Riegel wrote:
> > On Sat, 2011-07-09 at 16:30 +0200, Torvald Riegel wrote:
> > > The attached patch makes flat nesting the default, while still
> > > supporting closed nesting on demand (for user-c
Hi Richard,
I have a patch set for bug 43513 - The stack pointer is adjusted twice.
01_pr43513.3.patch
02_pr43513.3.test.patch
03_pr43513.3.mudflap.patch
The patch set has been bootstrapped and reg-tested on x86_64.
I will sent out the patches individually.
The patch replaces a vla __builtin_a
On 07/27/2011 01:50 PM, Tom de Vries wrote:
> Hi Richard,
>
> I have a patch set for bug 43513 - The stack pointer is adjusted twice.
>
> 01_pr43513.3.patch
> 02_pr43513.3.test.patch
> 03_pr43513.3.mudflap.patch
>
> The patch set has been bootstrapped and reg-tested on x86_64.
>
> I will sent o
On 07/27/2011 01:50 PM, Tom de Vries wrote:
> Hi Richard,
>
> I have a patch set for bug 43513 - The stack pointer is adjusted twice.
>
> 01_pr43513.3.patch
> 02_pr43513.3.test.patch
> 03_pr43513.3.mudflap.patch
>
> The patch set has been bootstrapped and reg-tested on x86_64.
>
> I will sent o
On 07/27/2011 01:54 PM, Tom de Vries wrote:
> On 07/27/2011 01:50 PM, Tom de Vries wrote:
>> Hi Richard,
>>
>> I have a patch set for bug 43513 - The stack pointer is adjusted twice.
>>
>> 01_pr43513.3.patch
>> 02_pr43513.3.test.patch
>> 03_pr43513.3.mudflap.patch
>>
>> The patch set has been boots
Sorry, for misunderstanding I've introduced with error in my comment.
Your inputs are fixed. Since they don't touch sources, just testsuite,
I am posting only tesuite/ChangeLog updated entry.
tesuite/ChangeLog entry:
2011-07-27 Kirill Yukhin
* gcc.target/i386/i386.exp (check_effective_
On 07/27/2011 01:50 PM, Tom de Vries wrote:
> Hi Richard,
>
> I have a patch set for bug 43513 - The stack pointer is adjusted twice.
>
> 01_pr43513.3.patch
> 02_pr43513.3.test.patch
> 03_pr43513.3.mudflap.patch
>
> The patch set has been bootstrapped and reg-tested on x86_64.
>
> I will sent o
Hello,
this patch handles for canonicalize_cond_expr_cond the case, that we have an
type-cast from boolean-type.
ChangeLog
2011-07-27 Kai Tietz
* gimple.c (canonicalize_cond_expr_cond): Handle cast
from boolean-type case.
Bootstrapped and regression tested on x86_64-pc-linux
Hi,
While looking at why we have so many moves between VFP and core
registers, I came across a situation in LU.c from scimark where we
load values into core registers transfer them to the VFP registers and
then use them in a VFP multiply instructions. Given that we should
prefer FPmode values in F
On Wed, 27 Jul 2011, Tom de Vries wrote:
> On 07/27/2011 01:50 PM, Tom de Vries wrote:
> > Hi Richard,
> >
> > I have a patch set for bug 43513 - The stack pointer is adjusted twice.
> >
> > 01_pr43513.3.patch
> > 02_pr43513.3.test.patch
> > 03_pr43513.3.mudflap.patch
> >
> > The patch set has
n Wed, Jul 27, 2011 at 12:59 PM, Kai Tietz wrote:
> Hello,
>
> this patch handles for canonicalize_cond_expr_cond the case, that we have an
> type-cast from boolean-type.
>
> ChangeLog
>
> 2011-07-27 Kai Tietz
>
> * gimple.c (canonicalize_cond_expr_cond): Handle cast
> from boolea
On Wed, Jul 27, 2011 at 01:50:47PM +0300, Tom de Vries wrote:
> I have a patch set for bug 43513 - The stack pointer is adjusted twice.
>
> 01_pr43513.3.patch
> 02_pr43513.3.test.patch
> 03_pr43513.3.mudflap.patch
>
> The patch set has been bootstrapped and reg-tested on x86_64.
>
> I will sent
On Wed, Jul 27, 2011 at 12:56 PM, Kirill Yukhin wrote:
> Sorry, for misunderstanding I've introduced with error in my comment.
> Your inputs are fixed. Since they don't touch sources, just testsuite,
> I am posting only tesuite/ChangeLog updated entry.
> tesuite/ChangeLog entry:
> 2011-07-27 Kir
Ping. (Re-tested this Monday.)
Thanks,
Martin
On Mon, Jul 11, 2011 at 11:58:32AM +0200, Martin Jambor wrote:
> Hi,
>
> since (same body) aliases have their own cgraph_nodes, the check for
> them in cgraph_redirect_edge_call_stmt_to_callee is now unnecessary
> because e->callee is now the alias
On Wed, Jul 27, 2011 at 6:14 AM, H.J. Lu wrote:
> For x32, movabs is only supported with register and constant operands.
> OK for trunk?
As said on the PR49798, assembler should handle R_X86_64_64 relocations
Anyway, the x86_64_movabs_operand predicate can be simplified to
clearly show what it
Hello,
this patch removes from gimple-fold the dead-code about
TRUTH_AND/TRUTH_OR-expression checks.
ChangeLog
* gimple-fold.c (or_comparisons_1): Remove TRUTH_AND/OR
expression handling.
(and_var_with_comparison_1): Likewise.
Bootstrapped and regression tested on host
Joseph S. Myers wrote:
> On Tue, 26 Jul 2011, Georg-Johann Lay wrote:
>
>> I once ran into trouble because there seems to be no clear
>> separation between undefinedness in C and undefinedness in RTL
>>
>> Starting thread from here,
>> http://gcc.gnu.org/ml/gcc-help/2010-06/msg00191.html
>>
>> t
I had long meant to support -mcpu=native on my targets. Now I finally
got around to implementing it.
The following patch does so for -mcpu=native/-mtune=native on Tru64
UNIX, using getsysinfo(2). A non-bootstrap C-only build is currently
running, the options above work as expected.
Ok for mainl
Hello!
2011-07-27 Uros Bizjak
* gcc.target/i386/avx-os-support.h: New.
* gcc.target/i386/avx-check.h: Include avx-os-support.h
(main): Check avx_os_support before the test is run.
* gcc.target/i386/aes-avx-check.h: Ditto.
* gcc.target/i386/pclmul-avx-che
Martin Jambor wrote:
> OK, this is what I have just committed as revision 176797 after
> re-testing.
Thanks, this has fixed the forwprop-5.c regression on spu-elf on mainline.
I'm seeing the same failure on the 4.6 branch -- would this patch also be
appropriate there?
Thanks,
Ulrich
--
Dr.
On Wed, Jul 27, 2011 at 4:40 AM, Uros Bizjak wrote:
> On Wed, Jul 27, 2011 at 6:14 AM, H.J. Lu wrote:
>
>> For x32, movabs is only supported with register and constant operands.
>> OK for trunk?
>
> As said on the PR49798, assembler should handle R_X86_64_64 relocations
>
> Anyway, the x86_64_mov
i would like to see more testing on other platforms. this is a large
patch. but otherwise it looks ok.
On 07/27/2011 08:26 AM, Dimitrios Apostolou wrote:
Hello list,
attached is a fairly intrusive patch that replaces many bitmaps in DF
with HARD_REG_SETs. Tested on i386 - no regressions (bes
On Wed, Jul 27, 2011 at 1:49 PM, Kai Tietz wrote:
> Hello,
>
> this patch removes from gimple-fold the dead-code about
> TRUTH_AND/TRUTH_OR-expression checks.
>
> ChangeLog
>
> * gimple-fold.c (or_comparisons_1): Remove TRUTH_AND/OR
> expression handling.
> (and_var_with_comp
On Wed, Jul 27, 2011 at 1:06 AM, Uros Bizjak wrote:
> On Wed, Jul 27, 2011 at 6:31 AM, H.J. Lu wrote:
>
>> The offsetted memory references always work for x32. OK for trunk?
>
> No, this is the same issue as in [1]. Please fix the assembler to
> zero-extend this relocation.
>
It is about addres
Hi,
On Wed, Jul 27, 2011 at 02:34:59PM +0200, Ulrich Weigand wrote:
> Martin Jambor wrote:
>
> > OK, this is what I have just committed as revision 176797 after
> > re-testing.
>
> Thanks, this has fixed the forwprop-5.c regression on spu-elf on mainline.
>
> I'm seeing the same failure on the
On Wed, Jul 27, 2011 at 2:44 PM, H.J. Lu wrote:
> On Wed, Jul 27, 2011 at 1:06 AM, Uros Bizjak wrote:
>> On Wed, Jul 27, 2011 at 6:31 AM, H.J. Lu wrote:
>>
>>> The offsetted memory references always work for x32. OK for trunk?
>>
>> No, this is the same issue as in [1]. Please fix the assembler
On 07/27/2011 04:42 AM, Torvald Riegel wrote:
On Tue, 2011-07-26 at 21:20 -0400, Andrew MacLeod wrote:
This patch is simply the documentation for extend.texi which adds a
section about the new memory model __sync_mem routines. I've supplied
the .info output since its easier to read, followed by
On Wed, Jul 27, 2011 at 5:53 AM, Uros Bizjak wrote:
> On Wed, Jul 27, 2011 at 2:44 PM, H.J. Lu wrote:
>> On Wed, Jul 27, 2011 at 1:06 AM, Uros Bizjak wrote:
>>> On Wed, Jul 27, 2011 at 6:31 AM, H.J. Lu wrote:
>>>
The offsetted memory references always work for x32. OK for trunk?
>>>
>>> N
On Wed, Jul 27, 2011 at 3:00 PM, H.J. Lu wrote:
>> Pmode is still in DImode and DImode addresses are *valid* addresses.
>> For the testcase from PR,
>> expand generates SImode symbol that is later extended to DImode and
>> handled through movabs.
>>
>> Your patch just papers over this fact. Pleas
Martin Jambor wrote:
> On Wed, Jul 27, 2011 at 02:34:59PM +0200, Ulrich Weigand wrote:
> > I'm seeing the same failure on the 4.6 branch -- would this patch also be
> > appropriate there?
>
> You're right, it should be applied to the 4.6 branch too. Since you
> have the setup to thest it, can you
http://gcc.gnu.org/ml/gcc-patches/2011-07/msg02113.html
Weddington, Eric wrote:
>
>> -Original Message-
>> From: Georg-Johann Lay
>>
>> This means that a pure __mulsi3 will have 30+30+20 = 80 bytes (+18).
>>
>> If all functions are used they occupy 116 bytes (-4), so they actually
>> save
On Wed, Jul 27, 2011 at 3:09 PM, Uros Bizjak wrote:
> On Wed, Jul 27, 2011 at 3:00 PM, H.J. Lu wrote:
>
>>> Pmode is still in DImode and DImode addresses are *valid* addresses.
>>> For the testcase from PR,
>>> expand generates SImode symbol that is later extended to DImode and
>>> handled throug
On Wed, Jul 27, 2011 at 6:09 AM, Uros Bizjak wrote:
> On Wed, Jul 27, 2011 at 3:00 PM, H.J. Lu wrote:
>
>>> Pmode is still in DImode and DImode addresses are *valid* addresses.
>>> For the testcase from PR,
>>> expand generates SImode symbol that is later extended to DImode and
>>> handled throug
This is a first cut at supporting -mcpu=native/-mtune=native on
Solaris/SPARC. Unlike it's Tru64 UNIX/Alpha and IRIX/MIPS (to be
submitted soon) counterparts, it's a bit more involved:
* There's no support for -mcpu=native in the SPARC port yet.
* Access to the %ver register is privileged, so we
Okay,
Uros, thanks for correcting me. Here is updated Changelogs and patch.
ChangeLog entry:
2011-07-27 Kirill Yukhin
PR target/49547
* config/i386/abmintrin.h (head): Check if __LZCNT__ is defined.
(__lzcnt): Rename to ...
(__lzcnt32): ... this.
* confi
Hi,
I've implemented a dozen of tests which cover BMI extensions
testsuite/ChangeLog entry:
2011-07-27 Yukhin Kirill
* gcc.target/i386/i386.exp (check_effective_target_bmi): New.
* gcc.target/i386/bmi-bextr-1.c: New test.
* gcc.target/i386/bmi-bextr-1a.c: Likewise.
On 07/27/2011 02:12 PM, Richard Guenther wrote:
> On Wed, 27 Jul 2011, Tom de Vries wrote:
>
>> On 07/27/2011 01:50 PM, Tom de Vries wrote:
>>> Hi Richard,
>>>
>>> I have a patch set for bug 43513 - The stack pointer is adjusted twice.
>>>
>>> 01_pr43513.3.patch
>>> 02_pr43513.3.test.patch
>>> 03_
On Wed, Jul 27, 2011 at 7:06 AM, Kirill Yukhin wrote:
> Okay,
> Uros, thanks for correcting me. Here is updated Changelogs and patch.
>
> ChangeLog entry:
> 2011-07-27 Kirill Yukhin
>
> PR target/49547
> * config/i386/abmintrin.h (head): Check if __LZCNT__ is defined.
> (__
On Wed, Jul 27, 2011 at 7:08 AM, Kirill Yukhin wrote:
> Hi,
> I've implemented a dozen of tests which cover BMI extensions
>
> testsuite/ChangeLog entry:
> 2011-07-27 Yukhin Kirill
>
> * gcc.target/i386/i386.exp (check_effective_target_bmi): New.
> * gcc.target/i386/bmi-bextr-1.c:
On Wed, 27 Jul 2011, Tom de Vries wrote:
> On 07/27/2011 02:12 PM, Richard Guenther wrote:
> > On Wed, 27 Jul 2011, Tom de Vries wrote:
> >
> >> On 07/27/2011 01:50 PM, Tom de Vries wrote:
> >>> Hi Richard,
> >>>
> >>> I have a patch set for bug 43513 - The stack pointer is adjusted twice.
> >>>
There is a typo in the internal documentation. This patch fixes this.
Please let me know if the patch is not in the required format.
PMatos
2011-07-26 Paulo J. Matos
* Fix internal documentation typo. TERGET should be TARGET.
diff --git a/gcc/doc/tm.texi b/gcc/doc/tm.texi
index 09753
Hi,
I will commit this patch to trunk after regstrap.
Sebastian
2011-07-23 Sebastian Pop
PR middle-end/45450
* graphite-poly.c (apply_poly_transforms): Disable legality check
after an openscop read.
---
gcc/ChangeLog |6 ++
gcc/graphite-poly.c |6 ++
Ulrich,
> ChangeLog:
>
> * lib/target-supports.exp (check_effective_target_mmap): Use
> check_function_available.
Ok, thanks.
Rainer
--
-
Rainer Orth, Center for Biotechnology, Bielefeld University
Good point, I forgot about ABM's another instruction - popcnt.
I'll do.
Thanks, K
On Wed, Jul 27, 2011 at 6:20 PM, H.J. Lu wrote:
> On Wed, Jul 27, 2011 at 7:06 AM, Kirill Yukhin
> wrote:
>> Okay,
>> Uros, thanks for correcting me. Here is updated Changelogs and patch.
>>
>> ChangeLog entry:
>
On Tue, Jul 26, 2011 at 7:38 PM, Jason Merrill wrote:
> On 07/26/2011 10:32 AM, Aldy Hernandez wrote:
>>
>>> I think the adjustment above is intended to match the adjustment of the
>>> address by bitregion_start/BITS_PER_UNIT, but the above seems to assume
>>> that bitregion_start%BITS_PER_UNIT ==
On Wed, Jul 27, 2011 at 3:28 PM, Uros Bizjak wrote:
Pmode is still in DImode and DImode addresses are *valid* addresses.
For the testcase from PR,
expand generates SImode symbol that is later extended to DImode and
handled through movabs.
Your patch just papers over
On 07/27/2011 04:57 AM, Rainer Orth wrote:
> The following patch does so for -mcpu=native/-mtune=native on Tru64
> UNIX, using getsysinfo(2). A non-bootstrap C-only build is currently
> running, the options above work as expected.
I hadn't realized that the =native detection wasn't being done
via
On Wed, Jul 27, 2011 at 4:52 PM, Richard Guenther
wrote:
> On Tue, Jul 26, 2011 at 7:38 PM, Jason Merrill wrote:
>> On 07/26/2011 10:32 AM, Aldy Hernandez wrote:
>>>
I think the adjustment above is intended to match the adjustment of the
address by bitregion_start/BITS_PER_UNIT, but the
Today is the 27th, not 26th so the Changelog should be:
2011-07-27 Paulo J. Matos
* Fix internal documentation typo. TERGET should be TARGET.
On 27/07/11 15:21, Paulo J. Matos wrote:
There is a typo in the internal documentation. This patch fixes this.
Please let me know if the patch i
Thanks, for inputs.
Sure, lzcnt useless here. I am updated and tested BMI detection in test driver.
testuite/ChageLog entry:
2011-07-27 Yukhin Kirill
* gcc.target/i386/i386.exp (check_effective_target_bmi): New.
* gcc.target/i386/bmi-andn-1.c: New test.
* gcc.target/i38
On Wed, Jul 27, 2011 at 4:56 PM, Richard Guenther
wrote:
> On Wed, Jul 27, 2011 at 4:52 PM, Richard Guenther
> wrote:
>> On Tue, Jul 26, 2011 at 7:38 PM, Jason Merrill wrote:
>>> On 07/26/2011 10:32 AM, Aldy Hernandez wrote:
> I think the adjustment above is intended to match the adjust
On 07/27/2011 06:21 AM, Georg-Johann Lay wrote:
> +(define_insn_and_split "*mulsi3"
> + [(set (match_operand:SI 0 "pseudo_register_operand"
> "=r")
> +(mult:SI (match_operand:SI 1 "pseudo_register_operand"
> "r")
> + (match_operand:SI 2 "
This is a draft patch that biases the reassociation machinery so that
each iteration of an accumulator pattern in a loop is independent of the
other iterations. This addresses a problem identified as an accidental
side effect of the bug observed in PR tree-optimization/49749. This
patch reverses
On 07/27/2011 02:12 AM, Kai Tietz wrote:
> 2011-07-27 Kai Tietz
>
> * config/i386/i386.c (ix86_option_override_internal): Allow -mabi
> for 32-bit, too.
> (ix86_handle_abi_attribute): Allow function attributes ms_abi/sysv_abi
> in 32-bit mode, too.
> * do
Just have a closer look to ABM intrinsics support in GCC
Seems, we have popcnt support in separate file: popcntintrin.h
So, after I move lzcnt intrinsics to lzcntintrin.h, abmintrin will
become useless and have to be removed at all
K
On Wed, Jul 27, 2011 at 6:20 PM, H.J. Lu wrote:
> On Wed, Jul
On Wed, Jul 27, 2011 at 8:45 AM, Kirill Yukhin wrote:
> Just have a closer look to ABM intrinsics support in GCC
> Seems, we have popcnt support in separate file: popcntintrin.h
>
> So, after I move lzcnt intrinsics to lzcntintrin.h, abmintrin will
> become useless and have to be removed at all
W
Hi,
On Wed, 27 Jul 2011, Richard Guenther wrote:
> > > I don't think it is safe to try to get at the VLA type the way you do.
> >
> > I don't understand in what way it's not safe. Do you mean I don't manage to
> > find
> > the type always, or that I find the wrong type, or something else?
>
>
Richard Henderson wrote:
> On 07/27/2011 06:21 AM, Georg-Johann Lay wrote:
>> +(define_insn_and_split "*mulsi3"
>> + [(set (match_operand:SI 0 "pseudo_register_operand"
>> "=r")
>> +(mult:SI (match_operand:SI 1 "pseudo_register_operand"
>> "r")
>> +
On 07/26/2011 06:20 PM, Andrew MacLeod wrote:
> * __sync_mem_compare_exchange has the skeleton in place, but not the
> guts. There are some issues that rth and I will work out later, I
> just don't want to hold up the rest of the patch for that. Right now
> it will fail the compare_exchange tests.
On 07/26/2011 06:20 PM, Andrew MacLeod wrote:
> * gcc.dg/sync-mem-{1-5}.c: Remove.
> * gcc.dg/sync-mem.h: Remove.
> * gcc.dg/sync-mem-compare-exchange-{1-5}.c: New functional tests.
> * gcc.dg/sync-mem-exchange-{1-5}.c: New functional tests.
> * gcc.dg/sync-mem-fence.c
Hi,
On Wed, 27 Jul 2011, William J. Schmidt wrote:
> +static long
> +propagate_rank (long rank, tree op)
> +{
> + long phi_prop_rank = phi_propagation_rank (op);
> +
> + if (phi_prop_rank)
> +return MAX (rank, phi_prop_rank);
> +
> + return MAX (rank, get_rank (op));
> +}
I know it's pre-
Than as it is ABM header, it should include two headers: lzcntinrin.h
and popcntintrin.h
But again, it seems useless to me. If we cannot remove empty header,
let it stay empty...
K
On Wed, Jul 27, 2011 at 7:53 PM, H.J. Lu wrote:
> On Wed, Jul 27, 2011 at 8:45 AM, Kirill Yukhin
> wrote:
>> Jus
There is a mistake in the comment for get_last_value in combine.c. This
patch fixes this.
PMatos
2011-07-27 Paulo J. Matos
* Fix comment if get_last_value in combine.c.
diff --git a/gcc/combine.c b/gcc/combine.c
index 4dbf022..affb509 100644
--- a/gcc/combine.c
+++ b/gcc/combine.c
@@ -1
This patch is to finalize the work on PR49313, i.e. better libgcc
implementation of some functions like bswap, counting zeros,
parity and popcount.
These functions are already implemented in libgcc.
This patch now provides a better integration of these functions:
the calls are no more emit as ord
On Wed, 27 Jul 2011, Dimitrios Apostolou wrote:
> --- gcc/target.h 2011-04-06 11:08:17 +
> +++ gcc/target.h 2011-07-27 10:27:56 +
> @@ -50,6 +50,7 @@
> #define GCC_TARGET_H
>
> #include "tm.h"
> +#include "hard-reg-set.h"
> #include "insn-modes.h"
Please send a patch agains
On Fri, Jul 22, 2011 at 01:00:09AM +0200, Tobias Grosser wrote:
> Hi,
>
> I propose to switch to the official cloog.org cloog version with isl backend
> and
> at the same time to remove support for both CLooG-PPL legacy as well as
> CLooG-Parma.
>
> We want to switch to cloog-isl as it is the on
On 07/26/2011 06:20 PM, Andrew MacLeod wrote:
> * doc/extend.texi (__sync_mem_*) : Document all the atomic builtin
> functions which deal with memory models.
Ok.
r~
Hello!
There is no way symbol_operand uses non-DI or non-SI modes on x86.
2011-07-27 Uros Bizjak
* config/i386/i386.c (ix86_expand_move): Do not explicitly check
the mode of symbolic_opreand RTXes.
Tested on x86_64-pc-linux-gnu {,-m32}. Committed to mainline SVN.
Uros.
Inde
On 07/27/2011 09:12 AM, Georg-Johann Lay wrote:
> PR target/49313
> * config/avr/libgcc.S (__ffshi2): Don't skip 2-word instruction.
> (__ctzsi2): Result for 0 may be undefined.
> (__ctzhi2): Result for 0 may be undefined.
> (__popcounthi2): Don't clobber r30. Use __po
Here's the last of my patches to support -march=native, this time for
IRIX. It uses the getenvent(3) family of functions since /proc/cpuinfo
is Linux-only. The patch itself is pretty straight forward, the basic
approach has been tested in a separate program, and the code compiles :-)
I'm waiting
On Tue, Jul 26, 2011 at 09:34, Richard Guenther wrote:
> Truncating -1 doesn't matter - it matters that if you perform any
> unsigned arithmetic in arbitrary precision signed arithmetic that
> you properly truncate after each operation to simulate unsigned
> twos-complement wrapping semantic. And
On 07/27/2011 08:57 AM, Georg-Johann Lay wrote:
>> > You'll probably end up with quite a few register classes
>> > out of this, but hopefully reload can do a better job than
>> > you can manually...
> Agreed.
>
> insns that will benefit are insns with two input operands that
> commute, i.e. mulsi
On Wed, Jul 27, 2011 at 5:02 PM, Kirill Yukhin wrote:
> Thanks, for inputs.
> Sure, lzcnt useless here. I am updated and tested BMI detection in test
> driver.
>
> testuite/ChageLog entry:
> 2011-07-27 Yukhin Kirill
>
> * gcc.target/i386/i386.exp (check_effective_target_bmi): New.
>
> +;; "*ashluqihiqi3.mem"
> +;; "*ashlsqihiqi3.mem"
> +(define_insn_and_split "*ashlqihiqi3.mem"
> + [(set (match_operand:QI 0 "memory_operand" "=m")
> +(subreg:QI (ashift:HI (any_extend:HI (match_operand:QI 1
> "register_operand" "r"))
> + (match_operand:QI 2
On Wed, Jul 27, 2011 at 6:12 PM, Kirill Yukhin wrote:
> Than as it is ABM header, it should include two headers: lzcntinrin.h
> and popcntintrin.h
>
> But again, it seems useless to me. If we cannot remove empty header,
> let it stay empty...
>
> K
>
> On Wed, Jul 27, 2011 at 7:53 PM, H.J. Lu wro
On Wed, Jul 27, 2011 at 9:49 AM, Uros Bizjak wrote:
> On Wed, Jul 27, 2011 at 6:12 PM, Kirill Yukhin
> wrote:
>> Than as it is ABM header, it should include two headers: lzcntinrin.h
>> and popcntintrin.h
>>
>> But again, it seems useless to me. If we cannot remove empty header,
>> let it stay e
Richard Henderson wrote:
>> +;; "*ashluqihiqi3.mem"
>> +;; "*ashlsqihiqi3.mem"
>> +(define_insn_and_split "*ashlqihiqi3.mem"
>> + [(set (match_operand:QI 0 "memory_operand" "=m")
>> +(subreg:QI (ashift:HI (any_extend:HI (match_operand:QI 1
>> "register_operand" "r"))
>> +
Anyway, I don't think a --param is appropriate to control a flag whether
to allow store data-races to be created. Why not use a regular option instead?
I don't care either way. What -foption-name do you suggest?
2011/7/26 Richard Sandiford :
> Note that on ARM, the comparison and loop counter addition can happen
> as a single parallel:
Certainly, I notice such "subs" ARM instructions. IMHO, this pattern seems to
appear rarely in real loops. For loops without doloop_end pattern we have to
make the follow
On 07/27/2011 05:27 PM, Richard Guenther wrote:
> On Wed, 27 Jul 2011, Tom de Vries wrote:
>
>> On 07/27/2011 02:12 PM, Richard Guenther wrote:
>>> On Wed, 27 Jul 2011, Tom de Vries wrote:
>>>
On 07/27/2011 01:50 PM, Tom de Vries wrote:
> Hi Richard,
>
> I have a patch set for bug
On 07/27/2011 01:08 PM, Aldy Hernandez wrote:
Anyway, I don't think a --param is appropriate to control a flag whether
to allow store data-races to be created. Why not use a regular
option instead?
I don't care either way. What -foption-name do you suggest?
Well, I suggested a -f option se
Sharp eye! Thanks.
Updated patch is attached.
Guys, with write approval, could you please commit that?
Thans, K
On Wed, Jul 27, 2011 at 8:46 PM, Uros Bizjak wrote:
> On Wed, Jul 27, 2011 at 5:02 PM, Kirill Yukhin
> wrote:
>
>> Thanks, for inputs.
>> Sure, lzcnt useless here. I am updated and t
On Mon, Jul 25, 2011 at 2:58 AM, Paolo Bonzini wrote:
> On 07/13/2011 07:48 PM, H.J. Lu wrote:
>>
>> Here is the patch. OK for trunk?
>
> Again, at least you should explain clearly _why_ you need
> ignore_address_wrap_around. You said elsewhere x32 should be first clean,
> then fast.
>
>> if (
Oh, and
INNERDECL is the actual object being referenced.
|| (!ptr_deref_may_alias_global_p (innerdecl)
is surely not what you want. That asks if *innerdecl is global memory.
I suppose you want is_global_var (innerdecl)? But with
&& (DECL_THREAD_LOCAL_P (innerdecl)
On Wed, Jul 27, 2011 at 10:26 AM, Kirill Yukhin wrote:
> Sharp eye! Thanks.
> Updated patch is attached.
> Guys, with write approval, could you please commit that?
>
I checked it in for you.
Thanks.
--
H.J.
On Mon, Jul 25, 2011 at 10:07 AM, Aldy Hernandez wrote:
> On 07/22/11 13:44, Jason Merrill wrote:
>>
>> On 07/18/2011 08:02 AM, Aldy Hernandez wrote:
>>>
>>> + /* If other threads can't see this value, no need to restrict
>>> stores. */
>>> + if (ALLOW_STORE_DATA_RACES
>>> + || !DECL_THREAD_VISIBL
1 - 100 of 136 matches
Mail list logo
