On Thu, Jul 28, 2011 at 4:55 AM, 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 x32. O
On Thu, Jul 28, 2011 at 5:48 AM, H.J. Lu wrote:
> 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
On Wed, Jul 27, 2011 at 11:29 PM, Jakub Jelinek wrote:
>> > Guys, with write approval, could you please commit that?
>> >
>>
>> I checked it in for you.
>
> Unfortunately many of the new tests fail with old assembler, because
> the builtin in check_effective_target_bmi is optimized away (ignored,
Ping
--
Thanks, K
On Mon, Jun 20, 2011 at 4:43 PM, H.J. Lu wrote:
> Hi,
>
> This patch removes ix86/avx branch and mentions avx2 branch. OK
> to install?
>
>
> H.J.
>
> Index: svn.html
> ===
> RCS file: /cvs/gcc/wwwdocs/htdocs
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 -
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
PR target/47715
* config/i386/i386.c (get_thread_pointer): Use ptr_m
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
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 Mon, Jul 18, 2011 at 8:21 AM, Rainer Orth
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
> http://gcc.gnu.org/ml/gcc-patches/2011-07/msg00927.html
On Wed, Jul 27, 2011 at 1:30 AM, Alan Modra 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, David
On Wed, Jul 27, 2011 at 1:25 PM, Paolo Bonzini 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 happen
>
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 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) i
> -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)
>
> >
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 the
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 agai
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 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 wa
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 DW_FORM_d
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
> 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 of the new t
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 HAVE_s
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 wil
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 have
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 (more
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
PR c++/49813
* include/c_globa
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
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
comm
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
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 sm
When setting gloog_error, graphite should continue code generation
without early returns, as otherwise the SSA representation would not
be complete. So set the new expression to integer_zero_node, that
would not require more SSA updates, and continue code generation as
nothing happened.
Regstrapp
Yes.
Jeffrey Yasskin 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 wrote:
> Ok.
>
> Jeffrey Yasskin wrote:
>
> Hi Jason. Paolo suggested I ping you directly abo
Okay, then here is an updated patch
updated ChangeLog entry:
2011-07-26 Kirill Yukhin
PR target/49547
* config.gcc (i[34567]86-*-*): Replace abmintrin.h with
lzcntintrin.h.
(x86_64-*-*): Likewise.
* config/i386/i386.opt (mlzcnt): New.
* config/i3
On Wed, Jul 27, 2011 at 7:37 AM, Sebastian Pop wrote:
> 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.
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
inste
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 (
Rainer Orth 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 separate program, and the c
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
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.
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 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 (
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 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
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
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
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?
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"))
>> +
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
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
> +;; "*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 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.
>
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 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
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 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
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/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~
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 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
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
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
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
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-
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
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.
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")
>> +
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?
>
>
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
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 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
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 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 "
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
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
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
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
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 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 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 ==
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:
>
Ulrich,
> ChangeLog:
>
> * lib/target-supports.exp (check_effective_target_mmap): Use
> check_function_available.
Ok, thanks.
Rainer
--
-
Rainer Orth, Center for Biotechnology, Bielefeld University
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 ++
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
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.
> >>>
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, 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 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_
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.
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
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
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
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
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
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
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
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 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 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
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 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
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
1 - 100 of 136 matches
Mail list logo
