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 could be simplified pretty
much.
I adjusted names for
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
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 ja...@redhat.com wrote:
Ok.
Jeffrey Yasskin jyass...@google.com wrote:
Hi Jason. Paolo suggested I ping you directly
On Wed, Jul 27, 2011 at 9:05 AM, Kirill Yukhin kirill.yuk...@gmail.com 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
On Wed, Jul 27, 2011 at 6:31 AM, H.J. Lu hongjiu...@intel.com 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
On Tue, Jul 26, 2011 at 6:56 PM, Ulrich Weigand uweig...@de.ibm.com 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
On Tue, Jul 26, 2011 at 8:07 PM, Sebastian Pop seb...@gmail.com wrote:
On Tue, Jul 26, 2011 at 08:30, Richard Guenther
richard.guent...@gmail.com 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
On Wed, Jul 27, 2011 at 8:33 AM, Kai Tietz ktiet...@googlemail.com 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
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 think
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.
*
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
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
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
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 kirill.yuk...@intel.com
*
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 a little
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
Okay,
Uros, thanks for correcting me. Here is updated Changelogs and patch.
ChangeLog entry:
2011-07-27 Kirill Yukhin kirill.yuk...@intel.com
PR target/49547
* config/i386/abmintrin.h (head): Check if __LZCNT__ is defined.
(__lzcnt): Rename to ...
(__lzcnt32):
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.
01_pr43513.3.patch
Ulrich,
ChangeLog:
* lib/target-supports.exp (check_effective_target_mmap): Use
check_function_available.
Ok, thanks.
Rainer
--
-
Rainer Orth, Center for Biotechnology, Bielefeld University
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
richard.guent...@gmail.com wrote:
On Tue, Jul 26, 2011 at 7:38 PM, Jason Merrill ja...@redhat.com 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
Today is the 27th, not 26th so the Changelog should be:
2011-07-27 Paulo J. Matos paulo.ma...@csr.com
* 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
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 kirill.yuk...@intel.com
* gcc.target/i386/i386.exp (check_effective_target_bmi): New.
* gcc.target/i386/bmi-andn-1.c: New test.
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 kti...@redhat.com
* 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.
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 hjl.to...@gmail.com
On Wed, Jul 27, 2011 at 8:45 AM, Kirill Yukhin kirill.yuk...@gmail.com 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
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?
I think you
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:
* 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:
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 paulo.ma...@csr.com
* 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
+++
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
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 against current
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 only
Hello!
There is no way symbol_operand uses non-DI or non-SI modes on x86.
2011-07-27 Uros Bizjak ubiz...@gmail.com
* 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
2011/7/26 Richard Sandiford richard.sandif...@linaro.org:
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
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
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 ubiz...@gmail.com wrote:
On Wed, Jul 27, 2011 at 5:02 PM, Kirill Yukhin kirill.yuk...@gmail.com
wrote:
Thanks, for inputs.
Sure,
On Mon, Jul 25, 2011 at 2:58 AM, Paolo Bonzini bonz...@gnu.org 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.
On Mon, Jul 25, 2011 at 10:07 AM, Aldy Hernandez al...@redhat.com 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_VISIBLE_P
Rainer Orth r...@cebitec.uni-bielefeld.de writes:
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
On 07/27/2011 12:03 PM, Richard Henderson wrote:
Please disable the relevant tests too.
sure.
if ((icode != CODE_FOR_nothing) (model == MEMMODEL_SEQ_CST ||
model == MEMMODEL_ACQ_REL))
+ #ifdef HAVE_sync_mem_thread_fence
+ emit_mem_thread_fence
Hi!
As the testcase shows, 4.6 generates invalid
jmp *$baz
insn which fails to assemble with -O2 -mcmodel=large. This has been fixed
by Uros on the trunk already, but with a larger patch, this patch just
backports the addition of the z constraint and uses it in all call patterns
On Wed, Jul 27, 2011 at 7:37 AM, Sebastian Pop seb...@gmail.com wrote:
Hi,
I will commit this patch to trunk after regstrap.
Sebastian
2011-07-23 Sebastian Pop sebastian@amd.com
PR middle-end/45450
* graphite-poly.c (apply_poly_transforms): Disable legality check
Okay, then here is an updated patch
updated ChangeLog entry:
2011-07-26 Kirill Yukhin kirill.yuk...@intel.com
PR target/49547
* config.gcc (i[34567]86-*-*): Replace abmintrin.h with
lzcntintrin.h.
(x86_64-*-*): Likewise.
* config/i386/i386.opt (mlzcnt):
Yes.
Jeffrey Yasskin jyass...@google.com wrote:
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 ja...@redhat.com wrote:
Ok.
Jeffrey Yasskin jyass...@google.com wrote:
This caused:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49875
The assembler sequence on ia32 was a bit different.
H.J. Can you try this on your end? If it fixes the problem, I will
commit as obvious.
Aldy
PR middle-end/49875
* c-c++-common/cxxbitfields-4.c: Check for
On Wed, Jul 27, 2011 at 01:51:04PM -0500, Aldy Hernandez wrote:
This caused:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49875
The assembler sequence on ia32 was a bit different.
H.J. Can you try this on your end? If it fixes the problem, I will
commit as obvious.
You could test it
On 07/27/11 13:55, Jakub Jelinek wrote:
On Wed, Jul 27, 2011 at 01:51:04PM -0500, Aldy Hernandez wrote:
This caused:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49875
The assembler sequence on ia32 was a bit different.
H.J. Can you try this on your end? If it fixes the problem, I will
Martin Jambor wrote:
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
Hi,
these are the library bits of the issue, with a workaround in place for
the weird std::isinf issue described in the audit trail. Tested
x86_64-linux multilib, committed to mainline.
Paolo.
///
2011-07-27 Paolo Carlini paolo.carl...@oracle.com
PR c++/49813
See discussion at http://gcc.gnu.org/ml/fortran/2011-07/msg00281.html
and see PR 45586.
This patch fixes the test case of the PR by properly using the
nonrestricted type for pointer components. Before, the test case failed
(ICE) in some tree checking. While the ICE only affects the trunk
Hello,
The patch below implements a new flag to warn when a typedef defined
in a function is unused. The warning is -Wunused-local-typedef, is
active for the C and C++ FEs and is intended for trunk.
With this patch the compiler caught a few spots of unused local
typedefs in libstdc++ that I
http://gcc.gnu.org/ml/gcc-patches/2011-07/msg02391.html
Richard Henderson schrieb:
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
On 07/27/2011 11:17 AM, Andrew MacLeod wrote:
On 07/27/2011 12:03 PM, Richard Henderson wrote:
Please disable the relevant tests too.
sure.
if ((icode != CODE_FOR_nothing) (model == MEMMODEL_SEQ_CST ||
model == MEMMODEL_ACQ_REL))
+ #ifdef
On Wed, Jul 27, 2011 at 10:46:06AM -0700, H.J. Lu wrote:
On Wed, Jul 27, 2011 at 10:26 AM, Kirill Yukhin kirill.yuk...@gmail.com
wrote:
Sharp eye! Thanks.
Updated patch is attached.
Guys, with write approval, could you please commit that?
I checked it in for you.
Unfortunately many
Hi!
As the attached testcase shows, we were generating invalid DWARF 3
for -gdwarf-3 for large DW_AT_data_member_location offsets.
Unlike DWARF 2, DWARF 3 allows DW_AT_data_member_location to be
either constant, block or loclistptr class, and for this combination
it has a note there that
On Wed, 27 Jul 2011, Andrew MacLeod wrote:
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
On 07/27/2011 07:29 PM, H.J. Lu wrote:
If IRNORE_ADDRESS_WRAP_AROUND is TRUE, we
+ also permute the conversion and addition of a constant. It is used to
+ optimize cases where overflow of base + constant offset won't happen or
+ its behavior is implementation-defined for a given target.
On 07/27/2011 06:17 PM, Joseph S. Myers 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 against current
Hi!
Apparently gdb (and not very unlikely other consumers) weren't able to
handle arbitrary location descriptions in DW_AT_data_member_location,
and my recent optimization to try to optimize e.g. DW_OP_plus_uconst
into equivalent, but shorter sequence of more operations apparently
doesn't work
-Original Message-
From: Georg-Johann Lay [mailto:a...@gjlay.de]
Sent: Wednesday, July 27, 2011 3:00 PM
To: Richard Henderson
Cc: Weddington, Eric; gcc-patches@gcc.gnu.org; Anatoly Sokolov; Denis
Chertykov
Subject: Re: [Patch,AVR]: PR49687 (better widening 32-bit mul)
Fair
On Wednesday 27 July 2011 22:39:20 Tobias Burnus wrote:
See discussion at http://gcc.gnu.org/ml/fortran/2011-07/msg00281.html
and see PR 45586.
This patch fixes the test case of the PR by properly using the
nonrestricted type for pointer components. Before, the test case failed
(ICE) in
Mikael Morin wrote:
Build and regtested on x86-64-linux.
OK for the trunk? What about backporting to 4.6 and to 4.5?
OK for trunk and 4.6.
4.5 doesn't have the gfc_nonrestricted_type function, so it's not worth the
bother IMO (unless you feel like backporting Michael's patch ;-) ).
Thanks for
On Wed, Jul 27, 2011 at 1:25 PM, Paolo Bonzini bonz...@gnu.org wrote:
On 07/27/2011 07:29 PM, H.J. Lu wrote:
If IRNORE_ADDRESS_WRAP_AROUND is TRUE, we
+ also permute the conversion and addition of a constant. It is used to
+ optimize cases where overflow of base + constant offset won't
On Wed, Jul 27, 2011 at 1:30 AM, Alan Modra amo...@gmail.com wrote:
* config/rs6000/linux-unwind.h (frob_update_context __powerpc64__):
Leave r2 REG_UNSAVED if stopped on the instruction that saves r2
in a plt call stub. Do restore r2 if stopped on bctrl.
Okay.
Thanks,
On Mon, Jul 18, 2011 at 8:21 AM, Rainer Orth
r...@cebitec.uni-bielefeld.de wrote:
The following two libgcc patches have seen almost no comments, and
certainly neither testing or review in a week:
CFT: [build] Move fp-bit support to toplevel libgcc
TLS on X32 is almost identical to TLS on x86-64. The only difference is
x32 address space is 32bit. That means TLS symbols can be in either
SImode or DImode with upper 32bit zero. This patch updates
tls_global_dynamic_64 to support x32. OK for trunk?
Thanks.
H.J.
---
2011-07-27 H.J. Lu
On Wed, Jul 27, 2011 at 07:55:08PM -0700, H.J. Lu wrote:
TLS on X32 is almost identical to TLS on x86-64. The only difference is
x32 address space is 32bit. That means TLS symbols can be in either
SImode or DImode with upper 32bit zero. This patch updates
tls_global_dynamic_64 to support
Hi,
In x32, thread pointer is 32bit and choice of segment register for the
thread base ptr load should be based on TARGET_64BIT. This patch
implements it. OK for trunk?
Thanks.
H.J.
---
2011-07-27 H.J. Lu hongjiu...@intel.com
PR target/47715
* config/i386/i386.c
Hi,
We should only expand strlen to Pmode. Otherwise, we got
[hjl@gnu-6 ilp32-38]$ cat x.i
char one[50] = ijk;
int
main (void)
{
return __builtin_strlen (one) != 3;
}
[hjl@gnu-6 ilp32-38]$ /export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -S -o
Ping
--
Thanks, K
On Mon, Jun 20, 2011 at 4:43 PM, H.J. Lu hongjiu...@intel.com wrote:
Hi,
This patch removes ix86/avx branch and mentions avx2 branch. OK
to install?
H.J.
Index: svn.html
===
RCS file:
73 matches
Mail list logo
