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.
Paolo
On 07/12/2011 06:37 PM, Rainer Orth wrote:
The next easy step in toplevel libgcc migration is moving
i386/crtprec.c. I noticed that -mpc{32, 64, 80} wasn't supported on
Solaris/x86 yet and corrected that. The only testcase using the switch
was adapted to also do so on Darwin/x86 (which already
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 patch adds support to fold_truth_not_expr for one-bit
Hello,
This patch adds support to fold_range_test and to fold_truthop for
one-bit precision
typed bitwise-binary and bitwise-not expressions.
ChangeLog
2011-07-13 Kai Tietz kti...@redhat.com
* fold-const.c (fold_range_test): Add
support for one-bit bitwise operations.
Hello,
This patch adds support to fold_truth_andor for one-bit precision
typed bitwise-binary and bitwise-not expressions.
ChangeLog
2011-07-13 Kai Tietz kti...@redhat.com
* fold-const.c (fold_truth_andor): Add
support for one-bit bitwise operations.
Bootstrapped and
Hello,
This patch adds support to fold_binary_loc for one-bit precision
typed bitwise-and expression.
ChangeLog
2011-07-13 Kai Tietz kti...@redhat.com
* fold-const.c (fold_binary_loc): Add
support for one-bit bitwise-and optimizeation.
Bootstrapped and regression tested with
Hello,
This patch adds support to fold_unary_loc for one-bit precision
typed bitwise-not expression.
ChangeLog
2011-07-13 Kai Tietz kti...@redhat.com
* fold-const.c (fold_unary_loc): Add
support for one-bit bitwise-not optimizeation.
Bootstrapped and regression tested with
Hello,
This patch adds new truth_value_type_p function, which has in contrast
to truth_value_p the ability to detect also bitwise-operation with boolean
characteristics. This patch has to be applied first for this series, but
it requires the other patches as prerequist of this series.
Hello William,
However, it does not fix http://gcc.gnu.org/PR45671, which surprises me
as it was marked as a duplicate of this one. Any thoughts on why this
isn't sufficient to reassociate the linear chain of adds?
Test case:
int myfunction (int a, int b, int c, int d, int e, int f, int
Ilya, please mention PR middle-end/44382
in ChangeLog.
Thanks for notice. Here is corrected ChangeLog:
gcc/
2011-07-12 Enkovich Ilya ilya.enkov...@intel.com
PR middle-end/44382
* target.def (reassociation_width): New hook.
* doc/tm.texi.in (reassociation_width): New
On Wed, Jul 13, 2011 at 11:52:25AM +0400, Ilya Enkovich wrote:
However, it does not fix http://gcc.gnu.org/PR45671, which surprises me
as it was marked as a duplicate of this one. Any thoughts on why this
isn't sufficient to reassociate the linear chain of adds?
Test case:
int
the final type is integral.
* gcc.dg/torture/20110713-1.c: New testcase.
Index: gcc/tree-vrp.c
===
--- gcc/tree-vrp.c (revision 176224)
+++ gcc/tree-vrp.c (working copy)
@@ -7353,6 +7353,8
On 12/07/11 12:11, Bernd Schmidt wrote:
On 07/12/11 13:04, Andrew Stubbs wrote:
On 12/07/11 11:35, Georg-Johann Lay wrote:
+(define_insn *mulsu
+ [(set (match_operand:HI 0
register_operand =r)
+(mult:HI (sign_extend:HI (match_operand:QI 1
register_operand
On Tue, Jul 12, 2011 at 11:56 PM, Richard Henderson r...@redhat.com wrote:
On 07/12/2011 02:22 PM, harsha.jaga...@amd.com wrote:
We would like to propose changing AVX generic mode tuning to generate 128-bit
AVX instead of 256-bit AVX.
You indicate a 3% reduction on bulldozer with avx256.
How
Hello!
Please don't use -m32/-m64 in testcases directly.
You should use
/* { dg-do compile { target { ! ia32 } } } */
for 32bit insns and
/* { dg-do compile { target { ia32 } } } */
for 64bit insns.
Also, there is no need to add -mtune if -march is already specified.
-mtune will follow
On Wed, Jul 13, 2011 at 3:00 AM, H.J. Lu hongjiu...@intel.com 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 hongjiu...@intel.com
*
On Wed, Jul 13, 2011 at 9:32 AM, Kai Tietz ktiet...@googlemail.com 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
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 kti...@redhat.com
* gimple-fold.c
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 disable
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
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
On 12 July 2011 22:07, Ramana Radhakrishnan
ramana.radhakrish...@linaro.org 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
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 again make
2011/7/13 Jakub Jelinek ja...@redhat.com:
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
Hallo Rainer!
On Tue, 12 Jul 2011 19:22:51 +0200, Rainer Orth r...@cebitec.uni-bielefeld.de
wrote:
2011-07-09 Rainer Orth r...@cebitec.uni-bielefeld.de
gcc: [...]
* config.gcc ([...]
(i[34567]86-*-darwin*): Remove i386/t-fprules-softfp,
soft-fp/t-softfp from
Paolo Bonzini bonz...@gnu.org 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
--
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 i386/t-linux from
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
On Wed, Jul 13, 2011 at 9:32 AM, Kai Tietz ktiet...@googlemail.com 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
On Wed, Jul 13, 2011 at 9:33 AM, Kai Tietz ktiet...@googlemail.com 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
On Wed, Jul 13, 2011 at 9:33 AM, Kai Tietz ktiet...@googlemail.com 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
On Wed, Jul 13, 2011 at 9:34 AM, Kai Tietz ktiet...@googlemail.com 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
On Wed, Jul 13, 2011 at 9:34 AM, Kai Tietz ktiet...@googlemail.com 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 kti...@redhat.com
On Wed, Jul 13, 2011 at 9:36 AM, Kai Tietz ktiet...@googlemail.com 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 kti...@redhat.com
* fold-const.c (fold_unary_loc): Add
2011/7/13 Richard Guenther richard.guent...@gmail.com:
On Wed, Jul 13, 2011 at 9:33 AM, Kai Tietz ktiet...@googlemail.com 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
On Wed, Jul 13, 2011 at 11:00 AM, Kai Tietz ktiet...@googlemail.com 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/
On Wed, Jul 13, 2011 at 11:04 AM, Kai Tietz ktiet...@googlemail.com 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
On Wed, Jul 13, 2011 at 11:18 AM, Ilya Enkovich enkovich@gmail.com wrote:
2011/7/13 Jakub Jelinek ja...@redhat.com:
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
2011/7/13 Richard Guenther richard.guent...@gmail.com:
On Wed, Jul 13, 2011 at 11:00 AM, Kai Tietz ktiet...@googlemail.com 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 ==/!=
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
On Tue, Jul 12, 2011 at 6:55 PM, Kai Tietz ktiet...@googlemail.com 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
On Wed, Jul 13, 2011 at 12:39 PM, Kai Tietz ktiet...@googlemail.com wrote:
2011/7/13 Richard Guenther richard.guent...@gmail.com:
On Wed, Jul 13, 2011 at 9:33 AM, Kai Tietz ktiet...@googlemail.com wrote:
Hello,
This patch adds support to fold_binary_loc for one-bit precision
typed bitwise-or
On Wed, Jul 13, 2011 at 12:56 PM, Kai Tietz ktiet...@googlemail.com wrote:
2011/7/13 Richard Guenther richard.guent...@gmail.com:
On Wed, Jul 13, 2011 at 11:00 AM, Kai Tietz ktiet...@googlemail.com wrote:
Hello,
this patch fixes that for replaced uses, we call fold_stmt_inplace.
2011/7/13 Richard Guenther richard.guent...@gmail.com:
On Wed, Jul 13, 2011 at 11:04 AM, Kai Tietz ktiet...@googlemail.com 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
On Wed, Jul 13, 2011 at 1:00 PM, Richard Sandiford
rdsandif...@googlemail.com 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
Richard Sandiford rdsandif...@googlemail.com 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
On Wed, Jul 13, 2011 at 03:12, Guozhi Wei car...@google.com 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
On Wed, Jul 13, 2011 at 1:08 PM, Kai Tietz ktiet...@googlemail.com wrote:
2011/7/13 Richard Guenther richard.guent...@gmail.com:
On Wed, Jul 13, 2011 at 11:04 AM, Kai Tietz ktiet...@googlemail.com wrote:
Sorrty, the TRUTH_NOT_EXPR isn't here the point at all. The underlying
issue is that
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 comments
I also
2011/7/13 Richard Guenther richard.guent...@gmail.com:
On Wed, Jul 13, 2011 at 1:08 PM, Kai Tietz ktiet...@googlemail.com wrote:
2011/7/13 Richard Guenther richard.guent...@gmail.com:
On Wed, Jul 13, 2011 at 11:04 AM, Kai Tietz ktiet...@googlemail.com wrote:
Sorrty, the TRUTH_NOT_EXPR isn't
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
* tree-vrp.c (simplify_conversion_using_ranges): Make sure
the final type is integral.
* gcc.dg/torture/20110713-1.c: New testcase.
Index: gcc/tree-vrp.c
===
--- gcc/tree-vrp.c (revision 176224
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
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
PING.
On Sun, Jul 10, 2011 at 12:43 PM, H.J. Lu hjl.to...@gmail.com wrote:
On Sun, Jul 10, 2011 at 7:32 AM, Uros Bizjak ubiz...@gmail.com wrote:
On Sat, Jul 9, 2011 at 11:28 PM, H.J. Lu hongjiu...@intel.com wrote:
X32 psABI requires promoting pointers to Pmode when passing/returning
in
On Wed, Jul 13, 2011 at 3:17 PM, H.J. Lu hjl.to...@gmail.com wrote:
PING.
2011-07-10 H.J. Lu hongjiu...@intel.com
* 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
Richard Guenther wrote:
2011-07-13 Richard Guenther rguent...@suse.de
* 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
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
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
Hi Richard,
Is my patch OK?
Thanks.
H.J.
On Sun, Jul 10, 2011 at 6:14 PM, H.J. Lu hjl.to...@gmail.com wrote:
On Sun, Jul 10, 2011 at 5:48 PM, Richard Henderson r...@redhat.com wrote:
On 07/10/2011 03:01 PM, H.J. Lu wrote:
We only want to promote function parameters passed/returned in
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 clear
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 include
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
Jan,
Rainer Orth r...@cebitec.uni-bielefeld.de 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
On Wed, Jul 13, 2011 at 3:13 PM, Andreas Krebbel
kreb...@linux.vnet.ibm.com 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
Hi Richard, Uros,
Is this patch OK?
Thanks.
H.J.
---
On Sun, Jul 10, 2011 at 6:47 PM, H.J. Lu hjl.to...@gmail.com wrote:
On Sat, Jul 9, 2011 at 3:58 PM, H.J. Lu hjl.to...@gmail.com wrote:
On Sat, Jul 9, 2011 at 3:43 PM, Richard Henderson r...@redhat.com wrote:
On 07/09/2011 02:36 PM, H.J. Lu
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, 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 believe
Jan Beulich jbeul...@novell.com writes:
Rainer Orth r...@cebitec.uni-bielefeld.de 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
Richard Guenther wrote:
On Wed, Jul 13, 2011 at 3:13 PM, Andreas Krebbel
kreb...@linux.vnet.ibm.com 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
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, I believe
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~
On Wed, Jul 13, 2011 at 8:27 AM, Richard Henderson r...@redhat.com 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: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)
if (Pmode !=
On 07/13/2011 08:35 AM, H.J. Lu wrote:
On Wed, Jul 13, 2011 at 8:27 AM, Richard Henderson r...@redhat.com 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
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/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_int
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
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
in
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 ubiz...@gmail.com
* lib/g++.exp (g++_init): Use istarget. Remove target_triplet global.
On Wed, Jul 13, 2011 at 9:13 AM, Paolo Bonzini bonz...@gnu.org 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
On Wed, Jul 13, 2011 at 18:39, H.J. Lu hjl.to...@gmail.com 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
On Tue, Jul 12, 2011 at 9:34 AM, Richard Sandiford
richard.sandif...@linaro.org 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,
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 permutes
Richard Henderson r...@redhat.com 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
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;
+ case
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
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
Richard Henderson r...@redhat.com 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,
Hallo!
On Wed, 13 Jul 2011 18:23:50 +0200, Paolo Bonzini bonz...@gnu.org 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.
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
On Wed, Jul 13, 2011 at 9:54 AM, Paolo Bonzini bonz...@gnu.org 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
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
Ok.
Paolo
On Wed, Jul 13, 2011 at 19:17, Thomas Schwinge tho...@schwinge.name wrote:
Hallo!
On Wed, 13 Jul 2011 18:23:50 +0200, Paolo Bonzini bonz...@gnu.org wrote:
On 07/13/2011 06:13 PM, Thomas Schwinge wrote:
Alternatively, gcc_GAS_CHECK_FEATURE could be changed to emit the
temporary
On Wed, Jul 13, 2011 at 10:12 AM, Rainer Orth
r...@cebitec.uni-bielefeld.de wrote:
Richard Henderson r...@redhat.com 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
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 crashes
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
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
Jakub == Jakub Jelinek ja...@redhat.com 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
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 that
1 - 100 of 115 matches
Mail list logo
