On Wed, Jul 13, 2011 at 8:37 AM, Richard Henderson wrote:
> On 07/13/2011 08:35 AM, H.J. Lu wrote:
>> On Wed, Jul 13, 2011 at 8:27 AM, Richard Henderson wrote:
>>> On 07/13/2011 07:02 AM, H.J. Lu wrote:
Hi Richard,
Is my patch OK?
>>>
>>> No, I don't think it is.
>>>
>>
>> What is
On Wed, Jul 13, 2011 at 11:50 AM, H.J. Lu wrote:
> On Wed, Jul 13, 2011 at 10:12 AM, Rainer Orth
> wrote:
>> Richard Henderson writes:
>>
>>> On 07/13/2011 09:57 AM, Rainer Orth wrote:
Do you think the revised crtfastmath patch is safe enough to commit
together to avoid this mess?
>>>
Hi Diego
The previous patch was done with svn merge.
This new version is done with svnmerge.py. Again tested with
make check-g++ RUNTESTFLAGS="--target_board=arm-sim/thumb/arch=armv7-a
dg.exp=anon-ns1.C"
make check-g++ RUNTESTFLAGS="dg.exp=anon-ns1.C"
BTW, there are some unexpected property cha
Hi all,
This patch was approved by Ian :
http://sourceware.org/ml/binutils/2011-07/msg00136.html. I have
synced plugin-api.h to gcc with the following patch in rev.176260
* plugin-api.h
(ld_plugin_section): New struct.
(ld_plugin_get_section_count): New typedef.
One minor note, you will need to update doc/invoke.texi to document the new
switch before checkin: -ftree-reassoc-width=
--
Michael Meissner, IBM
5 Technology Place Drive, M/S 2757, Westford, MA 01886-3141, USA
meiss...@linux.vnet.ibm.com fax +1 (978) 399-6899
Rainer,
I have successfully bootstrapped and tested the toplevel libgcc patch on
IA64 HP-UX. When trying to build IA64 Linux the bootstrap failed with:
/wsp/sje/gcc_git/gcc-ia64-debian-linux-gnu-gcc/ia64-debian-linux-gnu/bin/ar rc
libgcc.a $objects
/wsp/sje/gcc_git/gcc-ia64-debian-linux-gnu-g
On Wed, Jul 13, 2011 at 4:34 PM, Richard Guenther
wrote:
> On Wed, Jul 13, 2011 at 3:13 PM, Andreas Krebbel
> wrote:
>> Hi,
>>
>> the widening_mul pass might increase the number of multiplications in
>> the code by transforming
>>
>> a = b * c
>> d = a + 2
>> e = a + 3
>>
>> into:
>>
>> d = b * c
On Thu, Jul 07, 2011 at 03:14:02PM -0400, David Edelsohn wrote:
> On Thu, Jul 7, 2011 at 11:53 AM, Richard Guenther
> wrote:
>
> > Well, that's up to the target maintainers to decide, maybe
> > -mno-nested-functions instead?
>
> Is -mno-nested-functions or -mno-nested-function-pointers too
> C-c
This disables a check generated in VMS emulation mode (-gnatdm) for 32-bit
targets since it confuses the RTL middle-end for no real benefit.
Tested on i586-suse-linux, applied on the mainline.
2011-07-13 Eric Botcazou
* gcc-interface/utils.c (build_vms_descriptor32): Skip the 32-bit
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'gcc' has been submitted
by the German team of translators. The file is available at:
http://translationproject.org/latest/gcc/de.po
(This file, 'gcc-4.6.1.de.po', has just
Hi,
The problem here is that the type of the POINTER_PLUS_EXPR is
incorrect and also the non folded version leaks to the IR. This patch
fixes those two problems and fixes the ICE.
OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions.
Thanks,
Andrew Pinski
2011-07-13 Andrew Pin
This patch adds support for running the full G++ testsuite in C++0x
mode, apart from any tests that explicitly specify -std=c++98. To do
this, either 'make check-c++0x' in the gcc build subdirectory. 'make
check-c++' at the top level build directory will now run the tests in
both C++98 and C+
On Wed, Jul 13, 2011 at 01:36:03PM -0600, Tom Tromey wrote:
> I wrote a gdb patch for this. I've appended it in case you want to try
> it out; it is against git master. I tried it a little on an executable
> Jakub sent me and it seems to work fine.
Thanks.
> It is no trouble to change this patc
On 07/13/2011 09:14 AM, Georg-Johann Lay wrote:
> gcc/
> * config/avr/elf.h (TARGET_ASM_SELECT_SECTION): Remove,
> i.e. use default_elf_select_section.
> (TARGET_HAVE_SWITCHABLE_BSS_SECTIONS): Remove.
> (READONLY_DATA_SECTION_ASM_OP): Remove.
> (TARGET_ASM_NAMED_SECTIO
2011/7/13 Michael Meissner :
> I just ran a spec 2006 run on the powerpc (32-bit) last night setting the
> reassociation to 2. I do see a win in bwaves, but unfortunately it is not
> enough of a win, and it is still a regression to GCC 4.5. However, I see some
> regressions in 3 other benchmarks
Bernd Schmidt wrote:
> On 07/13/11 21:22, Ulrich Weigand wrote:
> > several builtin-bitops-1.c tests have been failing recently on SPU
> > since the new clrsb builtin is not supported.
>
> That's odd, it should just have picked the libgcc function rather than
> causing test failures. Why didn't th
> "Jakub" == Jakub Jelinek writes:
Jakub> Currently .debug_macinfo is prohibitively large, because it doesn't
Jakub> allow for any kind of merging of duplicate debug information.
Jakub> This patch is an RFC for extensions that allow it to bring it down
Jakub> to manageable levels.
I wrote a
On 07/13/11 21:22, Ulrich Weigand wrote:
> Hello,
>
> several builtin-bitops-1.c tests have been failing recently on SPU
> since the new clrsb builtin is not supported.
That's odd, it should just have picked the libgcc function rather than
causing test failures. Why didn't that happen?
Bernd
Hello,
several builtin-bitops-1.c tests have been failing recently on SPU
since the new clrsb builtin is not supported.
This patch fixes this by:
- installing the libgcc __clrsbdi2 routine into optabs
(which doesn't happen automatically on SPU since word_mode is TImode)
- providing an in-line
Alexandre Oliva wrote:
> * config/spu/spu.c (spu_flag_var_tracking): Drop.
> (TARGET_DELAY_VARTRACK): Define.
> (spu_var_tracking): New.
> (spu_machine_dependent_reorg): Call it.
> (asm_file_start): Don't save and override flag_var_tracking.
This change caused crashe
On Wed, Jul 13, 2011 at 10:12 AM, Rainer Orth
wrote:
> Richard Henderson writes:
>
>> On 07/13/2011 09:57 AM, Rainer Orth wrote:
>>> Do you think the revised crtfastmath patch is safe enough to commit
>>> together to avoid this mess?
>>
>> Probably.
>
> Ok. I'll will take this on me to get us ou
Ok.
Paolo
On Wed, Jul 13, 2011 at 19:17, Thomas Schwinge wrote:
> Hallo!
>
> On Wed, 13 Jul 2011 18:23:50 +0200, Paolo Bonzini wrote:
>> On 07/13/2011 06:13 PM, Thomas Schwinge wrote:
>> > Alternatively, gcc_GAS_CHECK_FEATURE could be changed to emit the
>> > temporary file by using a shell her
As reported in the PR, LIB_THREAD_LDFLAGS_SPEC (effectively
-L/usr/lib/lwp(/64)? -R/usr/lib/lwp(/64)? to make use of the alternate
thread library on Solaris 8, which also provides the only implementation
of __tls_get_addr) could be overridden by the regular -L flags from the
%D spec for 64-bit comp
On Wed, Jul 13, 2011 at 9:54 AM, Paolo Bonzini wrote:
Why? Certainly Y = 8 has 31-bit (or less) precision. So it has the same
representation in SImode and DImode, and the test above on XEXP (x, 1)
succeeds.
>>>
>>> And then we permute conversion and addition, which leads to the is
I just ran a spec 2006 run on the powerpc (32-bit) last night setting the
reassociation to 2. I do see a win in bwaves, but unfortunately it is not
enough of a win, and it is still a regression to GCC 4.5. However, I see some
regressions in 3 other benchmarks (I tend to omit differences of less t
Hallo!
On Wed, 13 Jul 2011 18:23:50 +0200, Paolo Bonzini wrote:
> On 07/13/2011 06:13 PM, Thomas Schwinge wrote:
> > Alternatively, gcc_GAS_CHECK_FEATURE could be changed to emit the
> > temporary file by using a shell here-doc, which is what AC_TRY_COMPILE is
> > doing, for example.
>
> Change
Richard Henderson writes:
> On 07/13/2011 09:57 AM, Rainer Orth wrote:
>> Do you think the revised crtfastmath patch is safe enough to commit
>> together to avoid this mess?
>
> Probably.
Ok. I'll will take this on me to get us out of this mess. It has
survived i386-pc-solaris2.11, sparc-sun-s
On 07/13/2011 09:57 AM, Rainer Orth wrote:
> Do you think the revised crtfastmath patch is safe enough to commit
> together to avoid this mess?
Probably.
> +# -frandom-seed is necessary to keep the mangled name of the constructor on
> +# Tru64 Unix stable, but harmless otherwise.
Instead of impl
Hi!
Currently .debug_macinfo is prohibitively large, because it doesn't
allow for any kind of merging of duplicate debug information.
This patch is an RFC for extensions that allow it to bring it down
to manageable levels. The ideas for the first shrinking come from Jason
and/or Roland I think f
On 07/13/2011 06:13 AM, Andreas Krebbel wrote:
> + force_operand (gen_rtx_fmt_ee (code, mode,
> +gen_raw_REG (mode, LAST_VIRTUAL_REGISTER + 1),
> +gen_raw_REG (mode, LAST_VIRTUAL_REGISTER + 2)),
> + NULL_RTX);
> + break;
> + c
Richard Henderson writes:
> On 07/11/2011 10:26 AM, Rainer Orth wrote:
>> There's one other question here: alpha/t-crtfm uses
>> -frandom-seed=gcc-crtfastmath with this comment:
>>
>> # FIXME drow/20061228 - I have preserved this -frandom-seed option
>> # while migrating this rule from the GCC d
>>> Why? Certainly Y = 8 has 31-bit (or less) precision. So it has the same
>>> representation in SImode and DImode, and the test above on XEXP (x, 1)
>>> succeeds.
>>
>> And then we permute conversion and addition, which leads to the issue you
>> raised above. In another word, the current code
On Tue, Jul 12, 2011 at 9:34 AM, Richard Sandiford
wrote:
> PR 48183 is caused by the fact that we don't really support integers
> (or least integer constants) wider than 2*HOST_BITS_PER_WIDE_INT:
>
> http://gcc.gnu.org/ml/gcc-patches/2011-03/msg01220.html
>
> However, such constants shouldn't b
On Wed, Jul 13, 2011 at 18:39, H.J. Lu wrote:
>> Why? Certainly Y = 8 has 31-bit (or less) precision. So it has the same
>> representation in SImode and DImode, and the test above on XEXP (x, 1)
>> succeeds.
>
> And then we permute conversion and addition, which leads to the issue you
> raised
On Wed, Jul 13, 2011 at 9:13 AM, Paolo Bonzini wrote:
> On 07/11/2011 05:54 PM, H.J. Lu wrote:
>>
>> The key is the
>> >
>> > XEXP (x, 1) == convert_memory_address_addr_space
>> > (to_mode, XEXP (x, 1), as)
>> >
>> > test. It ensures basically that the constant has 31-bit
Hello!
Attached patch converts several places where string match or regexp on
$target_triplet is used with istarget. The patch also removes quotes
around target string.
2011-07-13 Uros Bizjak
* lib/g++.exp (g++_init): Use istarget. Remove target_triplet global.
* lib/obj-c+
On 07/13/2011 06:13 PM, Thomas Schwinge wrote:
Alternatively, gcc_GAS_CHECK_FEATURE could be changed to emit the
temporary file by using a shell here-doc, which is what AC_TRY_COMPILE is
doing, for example.
Change instead echo ifelse(...) > conftest.s to
AS_ECHO([m4_if(...)]) > conftest.s
i
This patch removes some special treatment from avr/elf.h
which is actually not needed. The only target supported
by avr is ELF and the defaults for READONLY_DATA_SECTION_ASM_OP,
TARGET_HAVE_SWITCHABLE_BSS_SECTIONS, and TARGET_ASM_SELECT_SECTION
are fine.
Using default for TARGET_ASM_SELECT_SECTIO
On 07/11/2011 05:54 PM, H.J. Lu wrote:
The key is the
>
> XEXP (x, 1) == convert_memory_address_addr_space
>(to_mode, XEXP (x, 1), as)
>
> test. It ensures basically that the constant has 31-bit precision, because
> otherwise the constant would change from e.g. (const_i
Hallo!
Diffing the make log of a build of GCC with SHELL not explicitly set
(thus /bin/sh, which is bash) and one with SHELL=/bin/dash, I found the
following unexpected difference:
-checking assembler for eh_frame optimization... yes
+checking assembler for eh_frame optimization... buggy
On 07/13/2011 08:35 AM, H.J. Lu wrote:
> On Wed, Jul 13, 2011 at 8:27 AM, Richard Henderson wrote:
>> On 07/13/2011 07:02 AM, H.J. Lu wrote:
>>> Hi Richard,
>>>
>>> Is my patch OK?
>>
>> No, I don't think it is.
>>
>
> What is your suggestion?
Promote the return value. If that means it doesn't
On 07/13/2011 07:39 AM, H.J. Lu wrote:
>>* config/i386/i386.c (x86_output_mi_thunk): Support ptr_mode
>>!= Pmode.
>>
>>* config/i386/i386.md (*addsi_1_zext): Renamed to ...
>>(addsi_1_zext): This.
Ok, except,
>> + if (Pmode == DImode && ptr_mode == SImode)
On Wed, Jul 13, 2011 at 8:27 AM, Richard Henderson wrote:
> On 07/13/2011 07:02 AM, H.J. Lu wrote:
>> Hi Richard,
>>
>> Is my patch OK?
>
> No, I don't think it is.
>
What is your suggestion?
--
H.J.
On 07/13/2011 07:02 AM, H.J. Lu wrote:
> Hi Richard,
>
> Is my patch OK?
No, I don't think it is.
r~
Hi Frank,
> On Mon, Jul 11, 2011 at 06:34:27PM +0200, Rainer Orth wrote:
>> [...]
>> On the other hand, there's the question why tree-mudflap.c tries to
>> create a constructor with a non-default priority on a platform with
>> SUPPORTS_INIT_PRIORITY == 0 or at all [...]
>
> For the "at all" part,
Richard Guenther wrote:
> On Wed, Jul 13, 2011 at 3:13 PM, Andreas Krebbel
> wrote:
>> Hi,
>>
>> the widening_mul pass might increase the number of multiplications in
>> the code by transforming
>>
>> a = b * c
>> d = a + 2
>> e = a + 3
>>
>> into:
>>
>> d = b * c + 2
>> e = b * c + 3
>>
>> under
"Jan Beulich" writes:
Rainer Orth 07/13/11 4:34 PM >>>
>>which variant would you prefer: obsoletion now and removal in 4.8 or
>>immediate removal?
>
> Both are fine with me, so unless someone else objects immediate removal
> would seem better given it had been pretty much unmaintained.
Rig
Hi, Rainer -
On Mon, Jul 11, 2011 at 06:34:27PM +0200, Rainer Orth wrote:
> [...]
> On the other hand, there's the question why tree-mudflap.c tries to
> create a constructor with a non-default priority on a platform with
> SUPPORTS_INIT_PRIORITY == 0 or at all [...]
For the "at all" part, I beli
Hi, Rainer -
> When testing libmudflap on Solaris 8, 9, and 10 with GNU ld, I found a
> couple of testsuite failures:
> [...]
> Ok for mainline?
Yes, thank you!
- FChE
Hi Richard, Uros,
Is this patch OK?
Thanks.
H.J.
---
On Sun, Jul 10, 2011 at 6:47 PM, H.J. Lu wrote:
> On Sat, Jul 9, 2011 at 3:58 PM, H.J. Lu wrote:
>> On Sat, Jul 9, 2011 at 3:43 PM, Richard Henderson wrote:
>>> On 07/09/2011 02:36 PM, H.J. Lu wrote:
Hi,
Thunk is in ptr_
On Wed, Jul 13, 2011 at 3:13 PM, Andreas Krebbel
wrote:
> Hi,
>
> the widening_mul pass might increase the number of multiplications in
> the code by transforming
>
> a = b * c
> d = a + 2
> e = a + 3
>
> into:
>
> d = b * c + 2
> e = b * c + 3
>
> under the assumption that an FMA instruction is n
Jan,
Rainer Orth 07/12/11 6:46 PM >>>
>>On the other hand, maybe it's time to obsolete or even immediately
>>remove the netware port: there is no listed maintainer, no testsuite
>>results at least back to 2007 (if any were ever posted), and the only
>>netware-related change that hasn't been
On 07/13/2011 10:06 AM, Jakub Jelinek wrote:
--- gcc/testsuite/lib/dg-pch.exp.jj 2011-01-03 18:58:03.0 +0100
+++ gcc/testsuite/lib/dg-pch.exp2011-07-12 23:13:50.943670171 +0200
- dg-test -keep-output "./$bname$suffix" "$otherflags $flags" ""
+ dg-test -keep-output
On Wed, Jul 13, 2011 at 09:56:58AM -0400, Jason Merrill wrote:
> On 07/12/2011 07:46 PM, Jakub Jelinek wrote:
> >The aim is to include just (or primarily) code generation affecting options
> >explicitly passed on the command line. So that the merging actually works,
> >options or arguments which i
On 07/07/11 21:02, Bernd Schmidt wrote:
> This corrects an error in store_multiple_operation. We're only
> generating the writeback version of the instruction on Thumb-1, so
> that's where we must make sure the base register isn't also stored.
>
> The ARMv7 manual is unfortunately not totally clea
Hi Richard,
Is my patch OK?
Thanks.
H.J.
On Sun, Jul 10, 2011 at 6:14 PM, H.J. Lu wrote:
> On Sun, Jul 10, 2011 at 5:48 PM, Richard Henderson wrote:
>> On 07/10/2011 03:01 PM, H.J. Lu wrote:
>>> We only want to promote function parameters passed/returned in register.
>>> But I can't tel
On 07/12/2011 07:46 PM, Jakub Jelinek wrote:
The aim is to include just (or primarily) code generation affecting options
explicitly passed on the command line. So that the merging actually works,
options or arguments which include filenames or paths shouldn't be added,
on Roland's request -D*/-U
Jan,
> I would also preffer libgcov to go into its own toplevel directory,
> especially because there are plans to add non-stdlib i/o into it i.e.
> for kernel profiling. that way it would be handy to have libgcov
> as a toplevel library with its own configure that allows it to be build
> indepen
Richard Guenther wrote:
> 2011-07-13 Richard Guenther
>
> * tree-vrp.c (simplify_conversion_using_ranges): Make sure
> the final type is integral.
This fixes the spu-elf build failure.
Thanks,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ul
On Wed, Jul 13, 2011 at 3:17 PM, H.J. Lu wrote:
> PING.
>> 2011-07-10 H.J. Lu
>>
>> * config/i386/i386.c (ix86_promote_function_mode): New.
>> (TARGET_PROMOTE_FUNCTION_MODE): Likewise.
You have discussed this with rth, the final approval should be from him.
Uros.
PING.
On Sun, Jul 10, 2011 at 12:43 PM, H.J. Lu wrote:
> On Sun, Jul 10, 2011 at 7:32 AM, Uros Bizjak wrote:
>> On Sat, Jul 9, 2011 at 11:28 PM, H.J. Lu wrote:
>>
>>> X32 psABI requires promoting pointers to Pmode when passing/returning
>>> in registers. OK for trunk?
>>>
>>> Thanks.
>>>
>>> H
Hi,
the widening_mul pass might increase the number of multiplications in
the code by transforming
a = b * c
d = a + 2
e = a + 3
into:
d = b * c + 2
e = b * c + 3
under the assumption that an FMA instruction is not more expensive
than a simple add. This certainly isn't always true. While e.g
This is a patch to fix PR49487.
As Denis will be off-line for some time, it'd be great if
a global reviewer would review it. It appears that he is
the only AVR maintainer who approves patches.
The reason for the ICE is as explained in the PR:
Rotate pattern use "X" as constraint for an operand
> D.1962_5 = (void *) D.1963_3;
>>
>> test.i:3:1: internal compiler error: verify_gimple failed
>>
>> Any thoughts?
>
> Fix in testing.
>
> Richard.
>
> 2011-07-13 Richard Guenther
>
> * tree-vrp.c (simplify_conversion_using_ranges): Make
On Tue, 2011-07-12 at 11:50 -0500, William J. Schmidt wrote:
> Ilya, thanks for posting this! This patch is useful also on powerpc64.
> Applying it solved a performance degradation with bwaves due to loss of
> reassociation somewhere between 4.5 and 4.6 (still tracking it down).
> When we apply -f
2011/7/13 Richard Guenther :
> On Wed, Jul 13, 2011 at 1:08 PM, Kai Tietz wrote:
>> 2011/7/13 Richard Guenther :
>>> On Wed, Jul 13, 2011 at 11:04 AM, Kai Tietz wrote:
Sorrty, the TRUTH_NOT_EXPR isn't here the point at all. The underlying
issue is that fold-const re-inttroduces TRUTH_AN
On Sun, 3 Jul 2011, Thomas Klein wrote:
> Ye Joey wrote:
> > Thomas,
> >
> > I think your are working on a very useful feature. I have ARM MCU
> > applications running of out stack space and resulting strange
> > behaviors silently. I'd like to try your patch and probably give
> > further comm
On Wed, Jul 13, 2011 at 1:08 PM, Kai Tietz wrote:
> 2011/7/13 Richard Guenther :
>> On Wed, Jul 13, 2011 at 11:04 AM, Kai Tietz wrote:
>>> Sorrty, the TRUTH_NOT_EXPR isn't here the point at all. The underlying
>>> issue is that fold-const re-inttroduces TRUTH_AND/OR and co.
>>
>> I'm very sure it
On Wed, Jul 13, 2011 at 03:12, Guozhi Wei wrote:
> Hi
>
> This patch fixes a testing error on arm backend. It has been tested on both
> x86 and arm target with following commands.
>
> make check-g++ RUNTESTFLAGS="--target_board=arm-sim/thumb/arch=armv7-a
> dg.exp=anon-ns1.C"
> make check-g++ RUNT
Richard Sandiford writes:
> tree-vect-loop-manip.c assumes there is an alias if:
I meant _unless_.
> ((store_ptr_0 + store_segment_length_0) < load_ptr_0)
> || (load_ptr_0 + load_segment_length_0) < store_ptr_0))
>
> which means that contiguous arrays are unnecessarily considered to al
On Wed, Jul 13, 2011 at 1:00 PM, Richard Sandiford
wrote:
> tree-vect-loop-manip.c assumes there is an alias if:
>
> ((store_ptr_0 + store_segment_length_0) < load_ptr_0)
> || (load_ptr_0 + load_segment_length_0) < store_ptr_0))
>
> which means that contiguous arrays are unnecessarily cons
2011/7/13 Richard Guenther :
> On Wed, Jul 13, 2011 at 11:04 AM, Kai Tietz wrote:
>> Sorrty, the TRUTH_NOT_EXPR isn't here the point at all. The underlying
>> issue is that fold-const re-inttroduces TRUTH_AND/OR and co.
>
> I'm very sure it doesn't re-constrct TRUTH_ variants out of thin air
> whe
On Wed, Jul 13, 2011 at 12:56 PM, Kai Tietz wrote:
> 2011/7/13 Richard Guenther :
>> On Wed, Jul 13, 2011 at 11:00 AM, Kai Tietz wrote:
>>> Hello,
>>>
>>> this patch fixes that for replaced uses, we call fold_stmt_inplace.
>>> Additionally
>>> it adds to fold_gimple_assign the canonical form for
On Wed, Jul 13, 2011 at 12:39 PM, Kai Tietz wrote:
> 2011/7/13 Richard Guenther :
>> On Wed, Jul 13, 2011 at 9:33 AM, Kai Tietz wrote:
>>> Hello,
>>>
>>> This patch adds support to fold_binary_loc for one-bit precision
>>> typed bitwise-or expression.
>>
>> Seems to be a fallout of the missing TR
On Tue, Jul 12, 2011 at 6:55 PM, Kai Tietz wrote:
> Hello,
>
> As discussed on IRC, I reuse here the do_dce flag to choose folding
> direction within BB.
>
> Bootstrapped and regression tested for all standard-languages (plus
> Ada and Obj-C++) on host x86_64-pc-linux-gnu.
>
> Ok for apply?
The t
tree-vect-loop-manip.c assumes there is an alias if:
((store_ptr_0 + store_segment_length_0) < load_ptr_0)
|| (load_ptr_0 + load_segment_length_0) < store_ptr_0))
which means that contiguous arrays are unnecessarily considered to alias.
This patch changes the "<" to "<=". Tested on x8
2011/7/13 Richard Guenther :
> On Wed, Jul 13, 2011 at 11:00 AM, Kai Tietz wrote:
>> Hello,
>>
>> this patch fixes that for replaced uses, we call fold_stmt_inplace.
>> Additionally
>> it adds to fold_gimple_assign the canonical form for X !=/== 1 -> X ==/!= 0
>> for
>> X with one-bit precision
On Wed, Jul 13, 2011 at 11:18 AM, Ilya Enkovich wrote:
> 2011/7/13 Jakub Jelinek :
>>
>> I disagree. Widening would result in worse code in most cases, as you need
>> to sign extend all the operands. On the other side, I doubt you can
>> actually usefully use the undefinedness of signed overflow
On Wed, Jul 13, 2011 at 11:04 AM, Kai Tietz wrote:
> Sorrty, the TRUTH_NOT_EXPR isn't here the point at all. The underlying
> issue is that fold-const re-inttroduces TRUTH_AND/OR and co.
I'm very sure it doesn't re-constrct TRUTH_ variants out of thin air
when you present it with BIT_ variants as
On Wed, Jul 13, 2011 at 11:00 AM, Kai Tietz wrote:
> Hello,
>
> this patch fixes that for replaced uses, we call fold_stmt_inplace.
> Additionally
> it adds to fold_gimple_assign the canonical form for X !=/== 1 -> X ==/!= 0
> for
> X with one-bit precision type.
>
> ChangeLog gcc/
>
> 2011-07-1
2011/7/13 Richard Guenther :
> On Wed, Jul 13, 2011 at 9:33 AM, Kai Tietz wrote:
>> Hello,
>>
>> This patch adds support to fold_binary_loc for one-bit precision
>> typed bitwise-or expression.
>
> Seems to be a fallout of the missing TRUTH_NOT conversion as well.
>
>> ChangeLog
>>
>> 2011-07-13
On Wed, Jul 13, 2011 at 9:36 AM, Kai Tietz wrote:
> Hello,
>
> This patch adds support to fold_unary_loc for one-bit precision
> typed bitwise-not expression.
Similar ...
> ChangeLog
>
> 2011-07-13 Kai Tietz
>
> * fold-const.c (fold_unary_loc): Add
> support for one-bit bitwise-
On Wed, Jul 13, 2011 at 9:34 AM, Kai Tietz wrote:
> Hello,
>
> This patch adds support to fold_binary_loc for one-bit precision
> typed bitwise-and expression.
Similar ... your patch descriptions are useless btw.
> ChangeLog
>
> 2011-07-13 Kai Tietz
>
> * fold-const.c (fold_binary_loc)
On Wed, Jul 13, 2011 at 9:34 AM, Kai Tietz wrote:
> Hello,
>
> This patch adds support to fold_binary_loc for one-bit precision
> typed bitwise-xor expression.
Similar - we don't want to build a TRUTH_NOT_EXPR from a BIT_XOR_EXPR.
> ChangeLog
>
> 2011-07-13 Kai Tietz
>
> * fold-const.c
On Wed, Jul 13, 2011 at 9:33 AM, Kai Tietz wrote:
> Hello,
>
> This patch adds support to fold_binary_loc for one-bit precision
> typed bitwise-or expression.
Seems to be a fallout of the missing TRUTH_NOT conversion as well.
> ChangeLog
>
> 2011-07-13 Kai Tietz
>
> * fold-const.c (fol
On Wed, Jul 13, 2011 at 9:33 AM, Kai Tietz wrote:
> Hello,
>
> This patch adds support to fold_truth_andor for one-bit precision
> typed bitwise-binary and bitwise-not expressions.
Quickly checking some testcases shows we already perform all
the foldings in other places. So please _always_ check
On Wed, Jul 13, 2011 at 9:32 AM, Kai Tietz wrote:
> Hello,
>
> This patch adds support to fold_range_test and to fold_truthop for
> one-bit precision
> typed bitwise-binary and bitwise-not expressions.
This looks reasonable but I'd like to see testcases excercising the
foldings (by scanning the .
On 05/25/11 02:29, Vladimir Makarov wrote:
>> http://gcc.gnu.org/ml/gcc-patches/2011-05/msg00750.html
> Ok. But changelog entry for sched_change_pattern is absent.
I've committed this with a slight change in sched_change_pattern;
another patch I'm working on showed a need to also clear the cached
Hi Thomas,
>> i[34567]86-*-linux* | x86_64-*-linux* | \
>>i[34567]86-*-kfreebsd*-gnu | x86_64-*-kfreebsd*-gnu | \
>>i[34567]86-*-gnu*)
>> -tmake_file="${tmake_file} i386/t-fprules-softfp
>> soft-fp/t-softfp i386/t-linux"
>> ;;
>
> This also removes i3
Paolo Bonzini writes:
> On 07/12/2011 06:45 PM, Rainer Orth wrote:
>> +crt0.o: $(srcdir)/config/i386/netware-crt0.c
>> +$(crt_commpile) $(CRTSTUFF_T_CFLAGS) -c $<
>
> Typo here. Otherwise looks good, thanks.
Fixed and installed.
Thanks.
Rainer
--
-
Hallo Rainer!
On Tue, 12 Jul 2011 19:22:51 +0200, Rainer Orth
wrote:
> 2011-07-09 Rainer Orth
>
> gcc: [...]
> * config.gcc ([...]
> (i[34567]86-*-darwin*): Remove i386/t-fprules-softfp,
> soft-fp/t-softfp from tmake_file.
> (i[34567]86-*-linux*): Likewise.
>
2011/7/13 Jakub Jelinek :
>
> I disagree. Widening would result in worse code in most cases, as you need
> to sign extend all the operands. On the other side, I doubt you can
> actually usefully use the undefinedness of signed overflow for a series of
> 3 or more operands of the associative opera
On Wed, Jul 13, 2011 at 01:01:59PM +0400, Ilya Enkovich wrote:
> > Well, if it is clearly a win to reassociate, you can always reassociate
> > them by doing arithmetics in corresponding unsigned type and afterwards
> > converting back to the signed type.
>
> You are right. But in this case we agai
On 12 July 2011 22:07, Ramana Radhakrishnan
wrote:
> Hi Dave,
Hi Ramana,
Thanks for the review.
> Could you split this further into a patch that deals with the
> case for disabling MCR memory barriers for Thumb1 so that it
> maybe backported to the release branches ? I have commented inline
>
Sorrty, the TRUTH_NOT_EXPR isn't here the point at all. The underlying
issue is that fold-const re-inttroduces TRUTH_AND/OR and co. To avoid
it, it needs to learn to handle 1-bit precision folding for those
bitwise-operation on 1-bit integer types special.
As gimple replies on this FE fold for now
On Wed, Jul 13, 2011 at 10:42:41AM +0200, Richard Guenther wrote:
> I suppose generic tuning is of less importance for AVX as
> people need to enable that manually anyway (and will possibly
> do so only via means of -march=native).
Yeah, but if somebody does compile with -mavx -mtune=generic,
I'd
>
> Well, if it is clearly a win to reassociate, you can always reassociate
> them by doing arithmetics in corresponding unsigned type and afterwards
> converting back to the signed type.
>
> Jakub
>
You are right. But in this case we again make all operands have
wrap-around type and thus d
Hello,
this patch fixes that for replaced uses, we call fold_stmt_inplace. Additionally
it adds to fold_gimple_assign the canonical form for X !=/== 1 -> X ==/!= 0 for
X with one-bit precision type.
ChangeLog gcc/
2011-07-13 Kai Tietz
* gimple-fold.c (fold_gimple_assign): Add normali
On Wed, Jul 13, 2011 at 9:32 AM, Kai Tietz wrote:
> Hello,
>
> I split my old patch into 8 speparate pieces for easier review. These patches
> are a prerequist for enabling boolification of comparisons in gimplifier and
> the necessary type-cast preserving in gimple from/to boolean-type.
>
> This
On Wed, Jul 13, 2011 at 3:00 AM, H.J. Lu wrote:
> Hi,
>
> -mfused-madd is deprecated and -mfma is undocumented. This patch
> removes -mfused-madd and documents -mfma. OK for trunk?
Ok.
Thanks,
Richard.
> Thanks.
>
> H.J.
> ---
> 2011-07-12 H.J. Lu
>
> * doc/invoke.texi (x86): Remove
1 - 100 of 116 matches
Mail list logo
