Re: [PATCH] Handle MIPS EVA
Moore, Catherine catherine_mo...@mentor.com writes: @@ -16376,6 +16377,12 @@ Use (do not use) MT Multithreading instructions. @opindex mno-mcu Use (do not use) the MIPS MCU ASE instructions. +@item -meva +@itemx -mno-eva +@opindex meva +@opindex mno-eva +Use (do not use) the MIPS EVA instructions. Please spell it out here too, for consistency: Use (do not use) the MIPS Enhanced Virtual Addressing instructions. OK with that change, thanks. Richard
[Fortran, committed] Fix bugs in the dg-* directives in the test suite (was: testsuite oddities)
Manfred Schwarb wrote: I did some tests for unbalanced curly braces in the gfortran testsuite and got quite some output, see attached patch. additionally, - corrected dg-do run issues (double space) I think some of the test cases might to it on purpose: dg-do run causes the test case to run only once while dg-do run runs multiple times with different options. If the testcase is supposed to test the run-time library, calling it multiple times is pointless. Admittedly, using two spaces is an ugly hack, but creating a dg-do run-single is difficult. Those test cases are rather quick, hence, running multiple times, keeping the double space version or doing the latter but adding a comment all work. - dg-flags should be dg-options - string adjustments needed after fixing curly braces Thanks for the patches! Committed as http://gcc.gnu.org/r199636 Tobias
Minor tweak to extract_bit_field_1
For the larger-than-a-word case, store_bit_field_1 factors out the processing order into a 'backwards' local variable: unsigned int backwards = WORDS_BIG_ENDIAN fieldmode != BLKmode; and uses it consistently afterward. There is the symmetrical processing in extract_bit_field_1 and it doesn't factor out the processing order. Tested on PowerPC/Linux, applied on the mainline as obvious. 2013-06-04 Eric Botcazou ebotca...@adacore.com * expmed.c (extract_bit_field_1): In the larger-than-a-word case, factor out the processing order as in store_bit_field_1. -- Eric BotcazouIndex: expmed.c === --- expmed.c (revision 199590) +++ expmed.c (working copy) @@ -1486,6 +1486,7 @@ extract_bit_field_1 (rtx str_rtx, unsign This is because the most significant word is the one which may be less than full. */ + unsigned int backwards = WORDS_BIG_ENDIAN; unsigned int nwords = (bitsize + (BITS_PER_WORD - 1)) / BITS_PER_WORD; unsigned int i; rtx last; @@ -1503,13 +1504,14 @@ extract_bit_field_1 (rtx str_rtx, unsign if I is 1, use the next to lowest word; and so on. */ /* Word number in TARGET to use. */ unsigned int wordnum - = (WORDS_BIG_ENDIAN + = (backwards ? GET_MODE_SIZE (GET_MODE (target)) / UNITS_PER_WORD - i - 1 : i); /* Offset from start of field in OP0. */ - unsigned int bit_offset = (WORDS_BIG_ENDIAN - ? MAX (0, ((int) bitsize - ((int) i + 1) - * (int) BITS_PER_WORD)) + unsigned int bit_offset = (backwards + ? MAX ((int) bitsize - ((int) i + 1) + * BITS_PER_WORD, + 0) : (int) i * BITS_PER_WORD); rtx target_part = operand_subword (target, wordnum, 1, VOIDmode); rtx result_part @@ -1541,7 +1543,7 @@ extract_bit_field_1 (rtx str_rtx, unsign for (i = nwords; i total_words; i++) emit_move_insn (operand_subword (target, -WORDS_BIG_ENDIAN ? total_words - i - 1 : i, +backwards ? total_words - i - 1 : i, 1, VOIDmode), const0_rtx); }
[PING] 3 patches for review
[RFC] Allow functions calling mcount before prologue to be leaf functions http://gcc.gnu.org/ml/gcc-patches/2013-04/msg00993.html [PATCH] PR57377: Fix mnemonic attribute http://gcc.gnu.org/ml/gcc-patches/2013-05/msg01364.html [PATCH] Doc: Add documentation for the mnemonic attribute http://gcc.gnu.org/ml/gcc-patches/2013-05/msg01436.html Bye, -Andreas-
Re: [AArch64, PATCH 1/5] Improve MOVI handling (Change interface of aarch64_simd_valid_immediate)
On 3 June 2013 17:31, Ian Bolton ian.bol...@arm.com wrote: 13-06-03 Ian Bolton ian.bol...@arm.com * config/aarch64/aarch64.c (aarch64_simd_valid_immediate): Change return type to bool for prototype. (aarch64_legitimate_constant_p): Check for true instead of not -1. (aarch64_simd_valid_immediate): Fix up each return to return a bool. (aarch64_simd_immediate_valid_for_move): Update retval for bool. OK /Marcu
Re: [AArch64, PATCH 2/5] Improve MOVI handling (Remove wrapper function)
On 3 June 2013 17:31, Ian Bolton ian.bol...@arm.com wrote: 13-06-03 Ian Bolton ian.bol...@arm.com * config/aarch64/aarch64.c (aarch64_simd_valid_immediate): No longer static. (aarch64_simd_immediate_valid_for_move): Remove. (aarch64_simd_scalar_immediate_valid_for_move): Update call. (aarch64_simd_make_constant): Update call. (aarch64_output_simd_mov_immediate): Update call. * config/aarch64/aarch64-protos.h (aarch64_simd_valid_immediate): Add prototype. * config/aarch64/constraints.md (Dn): Update call. OK /Marcus
Re: [AArch64, PATCH 3/5] Improve MOVI handling (Don't update RTX operand in-place)
On 3 June 2013 17:32, Ian Bolton ian.bol...@arm.com wrote:
2013-06-03 Ian Bolton ian.bol...@arm.com
* config/aarch64/aarch64.c (simd_immediate_info): Struct to hold
information completed by aarch64_simd_valid_immediate.
(aarch64_legitimate_constant_p): Update arguments.
(aarch64_simd_valid_immediate): Work with struct rather than many
pointers.
(aarch64_simd_scalar_immediate_valid_for_move): Update arguments.
(aarch64_simd_make_constant): Update arguments.
(aarch64_output_simd_mov_immediate): Work with struct rather than
many pointers. Output immediate directly rather than as operand.
* config/aarch64/aarch64-protos.h (aarch64_simd_valid_immediate):
Update prototype.
* config/aarch64/constraints.md (Dn): Update arguments.
+struct simd_immediate_info {
+ rtx value;
I think that brace should be on a new line, otherwise OK.
/Marcus
Re: [AArch64, PATCH 4/5] Improve MOVI handling (Other minor clean-up)
On 3 June 2013 17:34, Ian Bolton ian.bol...@arm.com wrote: 2013-06-03 Ian Bolton ian.bol...@arm.com * config/aarch64/aarch64.c (simd_immediate_info): Remove element_char member. (sizetochar): Return signed char. (aarch64_simd_valid_immediate): Remove elchar and other unnecessary variables. (aarch64_output_simd_mov_immediate): Take rtx instead of rtx. Calculate element_char as required. * config/aarch64/aarch64-protos.h: Update and move prototype for aarch64_output_simd_mov_immediate. * config/aarch64/aarch64-simd.md (*aarch64_simd_movmode): Update arguments. OK /Marcus
Re: [AArch64, PATCH 5/5] Improve MOVI handling (Fix invalid assembler bug)
On 3 June 2013 17:35, Ian Bolton ian.bol...@arm.com wrote: 2013-06-03 Ian Bolton ian.bol...@arm.com gcc/ * config/aarch64/aarch64.md (*movmode_aarch64): Call into function to generate MOVI instruction. * config/aarch64/aarch64.c (aarch64_simd_container_mode): New function. (aarch64_preferred_simd_mode): Turn into wrapper. (aarch64_output_scalar_simd_mov_immediate): New function. * config/aarch64/aarch64-protos.h: Add prototype for above. testsuite/ * gcc.target/aarch64/movi_1.c: New test. OK /Marcus
Re: *ping* - Re: [Patch, Fortran] Enable FINALization/poly dealloc for allocatables
Le 03/06/2013 12:22, Tobias Burnus a écrit : * PING * Attached is just a re-diff. OK for the trunk? Hello, it looks good; one question below... diff --git a/gcc/fortran/trans-decl.c b/gcc/fortran/trans-decl.c index 100ec18..7521dee 100644 --- a/gcc/fortran/trans-decl.c +++ b/gcc/fortran/trans-decl.c @@ -3872,7 +3892,8 @@ gfc_trans_deferred_vars (gfc_symbol * proc_sym, gfc_wrapped_block * block) /* Deallocate when leaving the scope. Nullifying is not needed. */ - if (!sym-attr.result !sym-attr.dummy) + if (!sym-attr.result !sym-attr.dummy +!sym-ns-proc_name-attr.is_main_program) No check for !sym-attr.save here? There are several places through the patch where we check whether a variable needs end of scope automatic deallocation. Might be worth factoring the checks to a common predicate. The patch is OK in any case; thanks. Mikael
RE: [PATCH libgcc] Fix ARM uclinux libgcc config order issue
Ping^2?
Rebase it to trunk. Is it OK for trunk, 4.8 and 4.7?
Thanks!
-Zhenqiang
diff --git a/libgcc/config.host b/libgcc/config.host
index 0247bb0..d791797 100644
--- a/libgcc/config.host
+++ b/libgcc/config.host
@@ -331,10 +331,10 @@ arm*-*-linux*)# ARM GNU/Linux with
ELF
;;
arm*-*-uclinux*) # ARM ucLinux
tmake_file=${tmake_file} t-fixedpoint-gnu-prefix
+ tmake_file=$tmake_file arm/t-arm arm/t-elf t-softfp-sfdf
t-softfp-excl arm/t-softfp t-softfp
tmake_file=${tmake_file} arm/t-bpabi
tm_file=$tm_file arm/bpabi-lib.h
unwind_header=config/arm/unwind-arm.h
- tmake_file=$tmake_file arm/t-arm arm/t-elf t-softfp-sfdf
t-softfp-excl arm/t-softfp t-softfp
extra_parts=$extra_parts crti.o crtn.o
;;
arm*-*-eabi* | arm*-*-symbianelf* | arm*-*-rtems*)
-Original Message-
From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
ow...@gcc.gnu.org] On Behalf Of Zhenqiang Chen
Sent: Monday, March 04, 2013 4:26 PM
To: gcc-patches@gcc.gnu.org
Subject: RE: [PATCH libgcc] Fix ARM uclinux libgcc config order issue
Ping?
Thanks!
-Zhenqiang
-Original Message-
From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
ow...@gcc.gnu.org] On Behalf Of Zhenqiang Chen
Sent: Friday, January 11, 2013 5:21 PM
To: gcc-patches@gcc.gnu.org
Subject: [PATCH libgcc] Fix ARM uclinux libgcc config order issue
Hi,
The patch is to adjust ARM uclinux libgcc config order of arm/t-bpabi
and
t-
arm since LIB1ASMFUNCS defined in t-bpabi is overridden in t-arm.
Is it OK for trunk, 4.8 and 4.7?
Thanks!
-Zhenqiang
2012-03-11 Zhenqiang Chen zhenqiang.c...@arm.com
* config.host (arm*-*-uclinux*): Move arm/t-arm before arm/t-
bpabi.
diff --git a/libgcc/config.host b/libgcc/config.host index
ffd047f..eb65941
100644
--- a/libgcc/config.host
+++ b/libgcc/config.host
@@ -332,10 +332,10 @@ arm*-*-linux*)# ARM
GNU/Linux with
ELF
;;
arm*-*-uclinux*) # ARM ucLinux
tmake_file=${tmake_file} t-fixedpoint-gnu-prefix
+ tmake_file=$tmake_file arm/t-arm arm/t-elf t-softfp-sfdf
t-softfp-excl arm/t-softfp t-softfp
tmake_file=${tmake_file} arm/t-bpabi
tm_file=$tm_file arm/bpabi-lib.h
unwind_header=config/arm/unwind-arm.h
- tmake_file=$tmake_file arm/t-arm arm/t-elf t-softfp-sfdf
t-softfp-excl arm/t-softfp t-softfp
extra_parts=$extra_parts crti.o crtn.o
;;
arm*-*-eabi* | arm*-*-symbianelf* | arm*-*-rtems*)
Re: *ping* - Re: [Patch, Fortran] Enable FINALization/poly dealloc for allocatables
Mikael Morin wrote:
+++ b/gcc/fortran/trans-decl.c
@@ -3872,7 +3892,8 @@ gfc_trans_deferred_vars (gfc_symbol * proc_sym,
gfc_wrapped_block * block)
/* Deallocate when leaving the scope. Nullifying is not
needed. */
- if (!sym-attr.result !sym-attr.dummy)
+ if (!sym-attr.result !sym-attr.dummy
+ !sym-ns-proc_name-attr.is_main_program)
No check for !sym-attr.save here?
The code is in a big if block which has:
if (!sym-attr.save gfc_option.flag_max_stack_var_size != 0)
{
There are several places through the patch where we check whether a
variable needs end of scope automatic deallocation. Might be worth
factoring the checks to a common predicate.
Probably yes. One other case which needs some refactoring* is allocate:
We currently immediately distinguish between arrays and scalars - and
only the scalar code handles allocate(character(len=5) :: str) - the
array code duplicates part of the code, but not fully.
The patch is OK in any case; thanks.
Thanks for the review!
Tobias
* To my surprise, the word refactor/refactoring does not exist in
Marriam Webbster, nor in the Oxford Dictionary of English (or
oxfordreference.com). On the other hand, it has a wikipedia page,
thousands of book and article titles, dating back to the 60s and
seemingly it is more widely used since the 1990s/2000s.
Re: [PATCH] Improve folding of bitwise ops on booleans
On Mon, Jun 3, 2013 at 6:05 PM, Jeff Law l...@redhat.com wrote:
On 06/03/2013 02:24 AM, Richard Biener wrote:
On Fri, May 31, 2013 at 10:18 PM, Jeff Law l...@redhat.com wrote:
This is an implementation to fix a missed optimization pointed out to me
by
Kai.
In all these examples, assume a b are single bit types.
~a b -- a b
For a signed 1-bit type you'll have values -1, 0 and clearly
0 -1
is false while ~0 -1 is non-zero.
Sigh. Yes.
So I believe you have to restrict these transforms to signed 1-bit values
or adjust the folding appropriately. Besides that, ...
a ~b -- b a
~a || b -- a = b
a ~b -- b = a
I wonder if these are really a simplification if the result is not used
exclusively in a conditional jump. Because for setting a register
to a b you'll likely get worse code than using ~a b (given that
many ISAs have a and-not instruction). Of course you may argue
that's a bug in the RTL / target piece (getting different code for
a b vs. ~a b) and a b is shorter on the tree level.
The gimple optimizers should be looking to simplify things to the fullest
extent possible at the gimple level and let the backend make the
determination to use and-not if such an insn is available.
The counter to that argument of leaving it to the backend to recover the
and-not for is that the backend doesn't typically see these as single bit
operations which makes turning the relational back into an and-not sequence
considerably more difficult.
Do we consider this enough of an issue to want to avoid going down this
path? (in which case we'll file the example code as a missed-opt PR and
attach the code and pointer to this thread for future reference)
I agree that gimple optimizers should simplify things as much as possible.
Still we try to not generate regressions on the way. So as an intermediate
guard I'd make sure the result of the bitwise op is only used in a GIMPLE_COND
(which means we can forward the resulting compare directly into the
GIMPLE_COND).
A comment should explain why we restrict the transform.
+static bool
+simplify_bitwise_binary_boolean (gimple_stmt_iterator *gsi,
+enum tree_code code,
+tree op0, tree op1)
+{
+ gimple op0_def_stmt = SSA_NAME_DEF_STMT (op0);
+
+ if (!is_gimple_assign (op0_def_stmt)
+ || (gimple_assign_rhs_code (op0_def_stmt) != BIT_NOT_EXPR))
+return false;
+
+ tree x = gimple_assign_rhs1 (op0_def_stmt);
+ if (TREE_CODE (x) == SSA_NAME
+ INTEGRAL_TYPE_P (TREE_TYPE (x))
+ TYPE_PRECISION (TREE_TYPE (x)) == 1)
Do these transforms not work for BOOLEAN_TYPE as well?
Yes. Booleans are integral types with a single bit of precision, right? So
this check should allow boolean types. What am I missing?
We have BOOLEAN_TYPEs that do not have a TYPE_PRECISION of one
(but still are two-valued, and we assume those values are 0 and != 0 (eh)).
So there is code that treats BOOLEAN_TYPEs the same as TYPE_PRECISION
one types and there is code that does not (for example bitwise not is not
equal to truth not on such types).
Richard.
+{
+ gimple stmt = gsi_stmt (*gsi);
+ gimple_assign_set_rhs1 (stmt, x);
+ gimple_assign_set_rhs2 (stmt, op1);
+ gimple_assign_set_rhs_code (stmt, code == BIT_AND_EXPR ? LT_EXPR :
LE_EXPR);
+ update_stmt (gsi_stmt (*gsi));
No need to query gsi_stmt again, it cannot change.
I'd have to check on that; I think this was cribbed from another
transformation in tree-ssa-reassoc.
Re: [PATCH] Improve folding of bitwise ops on booleans
On Mon, Jun 3, 2013 at 8:34 PM, Jeff Law l...@redhat.com wrote: On 06/03/2013 12:32 PM, Kai Tietz wrote: 2013/6/3 Jeff Law l...@redhat.com: On 06/03/2013 11:00 AM, Richard Henderson wrote: On 06/03/2013 09:37 AM, Kai Tietz wrote: foo: .seh_endprologue cmpb%cl, %dl seta%al ret .seh_endproc .p2align 4,,15 .globl boo .defboo;.scl2; .type 32; .endef .seh_proc boo boo: .seh_endprologue movl%ecx, %eax notl%eax andl%edx, %eax andl$1, %eax ret Try arm or s390 or ppc for significantly different results. I'm starting to wonder if we could delay make a choice about using a relational or bit ops until gimple-rtl expansion. I haven't seen any secondary benefits, so deferring to a later point where we might be able to query the backend's capabilities might make sense. jeff Well, a secondary benefit I see in area of BC-optimization. But I agree that this operation should go along gimple-rtl transformation. And at same place BC-optimization should happen. Let's table it for now then. Ironically I was just looking at moving one of the branch-cost transformations out of fold-const.c. We're going to have to build out some infrastructure to make that happen. I'll withdraw the patch and just submit a missed optimization PR and xfailed testsuite for this issue. The transform is worthwhile if there is secondary benefit of being able to forward the result into a test instruction (GIMPLE_COND or condition in a COND_EXPR). Richard. jeff
Re: [GOOGLE] More strict checking for call args
On Tue, Jun 4, 2013 at 2:55 AM, Dehao Chen de...@google.com wrote:
Hi,
This patch was committed to google branch. But I think it is of
general interest. So is it ok for trunk?
Thanks,
Dehao
gcc/ChangeLog:
2013-06-03 Dehao Chen de...@google.com
*gimple-low.c (gimple_check_call_args): Restrict the call_arg check to
contain same number of args.
Index: gcc/gimple-low.c
===
--- gcc/gimple-low.c (revision 199570)
+++ gcc/gimple-low.c (working copy)
@@ -243,6 +243,8 @@ gimple_check_call_args (gimple stmt, tree fndecl)
!fold_convertible_p (DECL_ARG_TYPE (p), arg)))
return false;
}
+ if (p != NULL)
+ return false;
Please add a comment here, like
/* Not enough parameters to the function call. */
if (p != NULL)
return false;
note that I believe we can deal with this situation just fine during inlining,
we just leave the parameters uninitialized.
So - why do you think the test is a good idea? The whole function should
ideally be not necessary and is just there to avoid situations we cannot
deal with during inlining.
Richard.
}
else if (parms)
{
Re: [PATCH, libcpp] Do not decrease highest_location if the included file has be included twice.
Dehao Chen de...@google.com a écrit:
So, I'd say that in this hunk of your patch:
@@ -1002,7 +1002,8 @@ _cpp_stack_include (cpp_reader *pfile, const char
linemap_add is not called) or we were included from the
command-line. */
if (file-pchname == NULL file-err_no == 0
- type != IT_CMDLINE type != IT_DEFAULT)
+ type != IT_CMDLINE type != IT_DEFAULT
+ !(file-cmacro file-cmacro-type == NT_MACRO))
Maybe you should test:
should_stack_file (pfile, file, type == IT_IMPORT)
rather than testing the last conjunction you added? This is because
there are many conditions that could make the header to not be loaded,
besides the one you are testing. Would this work in your environment?
I tried to apply this change, but it failed several PCH related
regression tests.
Of course ... sigh.
So, should_stack_file apparently sets some state to (among other things)
flag files loaded via #import as 'imported'. And using it here prevents
the file to be really imported later. That kind of things. And some
the pch related failures involve using #import. So my idea was a bad
one.
So how about this patch then?
diff --git a/libcpp/files.c b/libcpp/files.c
index 5c5a0b9..be80be3 100644
--- a/libcpp/files.c
+++ b/libcpp/files.c
@@ -983,6 +983,7 @@ _cpp_stack_include (cpp_reader *pfile, const char *fname,
int angle_brackets,
{
struct cpp_dir *dir;
_cpp_file *file;
+ bool stacked;
dir = search_path_head (pfile, fname, angle_brackets, type);
if (!dir)
@@ -993,19 +994,26 @@ _cpp_stack_include (cpp_reader *pfile, const char *fname,
int angle_brackets,
if (type == IT_DEFAULT file == NULL)
return false;
- /* Compensate for the increment in linemap_add that occurs in
- _cpp_stack_file. In the case of a normal #include, we're
- currently at the start of the line *following* the #include. A
- separate source_location for this location makes no sense (until
- we do the LC_LEAVE), and complicates LAST_SOURCE_LINE_LOCATION.
- This does not apply if we found a PCH file (in which case
- linemap_add is not called) or we were included from the
- command-line. */
+ /* Compensate for the increment in linemap_add that occurs if
+ _cpp_stack_file actually stacks the file. In the case of a
+ normal #include, we're currently at the start of the line
+ *following* the #include. A separate source_location for this
+ location makes no sense (until we do the LC_LEAVE), and
+ complicates LAST_SOURCE_LINE_LOCATION. This does not apply if we
+ found a PCH file (in which case linemap_add is not called) or we
+ were included from the command-line. */
if (file-pchname == NULL file-err_no == 0
type != IT_CMDLINE type != IT_DEFAULT)
pfile-line_table-highest_location--;
- return _cpp_stack_file (pfile, file, type == IT_IMPORT);
+ stacked = _cpp_stack_file (pfile, file, type == IT_IMPORT);
+
+ if (!stacked)
+/* _cpp_stack_file didn't stack the file, so let's rollback the
+ compensation dance we performed above. */
+pfile-line_table-highest_location++;
+
+ return stacked;
}
/* Could not open FILE. The complication is dependency output. */
It passes bootstrap on x86_64-unknown-linux-gnu for all,ada,obj{c,c++}
here but then I don't know if it fixes the issue on you giant input
file.
If it does and if the maintainers think it can go in, I'll let you
handle the ChangeLog and commit.
Cheers.
--
Dodji
[PATCH][ARM][1/n] Partial IT block deprecation in ARMv8 AArch32
Hi all, IT blocks in ARMv8 AArch32 Thumb mode are somewhat restricted. They cannot contain more than one instruction, and that one instruction has to be a 16-bit variant of a restricted subset of instructions. ARMv7 IT blocks that don't fit in this category are allowed by ARMv8, but are deprecated. This patch is the first in a series to get gcc to stop generating the deprecated forms for ARMv8. It creates a command line option, -mrestrict-it, that can be used to enable this new behaviour for earlier architecture variants, as well as switch it off for ARMv8 (via -mno-restrict-it). The new behaviour is controlled by a new variable, arm_restrict_it. We stop the merging of cond_execs into multi-instruction IT blocks when arm_restrict_it is enabled. Bootstrapped on a Cortex-A15, regtested arm-none-eabi on qemu and a model. Ok for trunk? Thanks, Kyrill 2013-06-04 Kyrylo Tkachov kyrylo.tkac...@arm.com * config/arm/arm.c (MAX_INSN_PER_IT_BLOCK): New macro. (arm_option_override): Override arm_restrict_it where appropriate. (thumb2_final_prescan_insn): Use MAX_INSN_PER_IT_BLOCK. * config/arm/arm.opt (mrestrict-it): New command-line option. 01-options.patch Description: Binary data
[RS6000] LE SFmode constants in toc
ppc64 SFmode constants in the TOC occupy the first word of a dword. For little-endian, we don't need to shift left. Bootstrapped etc. and committed as obvious revision 199646. * config/rs6000/rs6000.c (output_toc): Correct little-endian float constant output. Index: gcc/config/rs6000/rs6000.c === --- gcc/config/rs6000/rs6000.c (revision 199644) +++ gcc/config/rs6000/rs6000.c (working copy) @@ -22574,7 +22574,10 @@ output_toc (FILE *file, rtx x, int labelno, enum m fputs (DOUBLE_INT_ASM_OP, file); else fprintf (file, \t.tc FS_%lx[TC],, l 0x); - fprintf (file, 0x%lx\n, l 0x); + if (WORDS_BIG_ENDIAN) + fprintf (file, 0x%lx\n, l 0x); + else + fprintf (file, 0x%lx\n, l 0x); return; } else -- Alan Modra Australia Development Lab, IBM
[RS6000] Enable long-double support for little-endian
This enables long double support for little-endian. It assumes we keep the same ordering as big-endian, ie. the first double is the larger magnitude or inf/nan. Bootstrapped powerpc64-linux. OK to apply? * config/rs6000/ibm-ldouble.c: Enable for little-endian. Index: libgcc/config/rs6000/ibm-ldouble.c === --- libgcc/config/rs6000/ibm-ldouble.c (revision 199174) +++ libgcc/config/rs6000/ibm-ldouble.c (working copy) @@ -42,10 +42,10 @@ represented as (1.0, +0.0) or (1.0, -0.0), and the low part of a NaN is don't-care. - This code currently assumes big-endian. */ + This code currently assumes the most significant double is in + the lower numbered register or lower addressed memory. */ -#if (!defined (__LITTLE_ENDIAN__) \ - (defined (__MACH__) || defined (__powerpc__) || defined (_AIX))) +#if defined (__MACH__) || defined (__powerpc__) || defined (_AIX) #define fabs(x) __builtin_fabs(x) #define isless(x, y) __builtin_isless (x, y) -- Alan Modra Australia Development Lab, IBM
Re: [RS6000] Enable long-double support for little-endian
On Tue, Jun 4, 2013 at 9:11 AM, Alan Modra amo...@gmail.com wrote: This enables long double support for little-endian. It assumes we keep the same ordering as big-endian, ie. the first double is the larger magnitude or inf/nan. Bootstrapped powerpc64-linux. OK to apply? * config/rs6000/ibm-ldouble.c: Enable for little-endian. Index: libgcc/config/rs6000/ibm-ldouble.c === --- libgcc/config/rs6000/ibm-ldouble.c (revision 199174) +++ libgcc/config/rs6000/ibm-ldouble.c (working copy) @@ -42,10 +42,10 @@ represented as (1.0, +0.0) or (1.0, -0.0), and the low part of a NaN is don't-care. - This code currently assumes big-endian. */ + This code currently assumes the most significant double is in + the lower numbered register or lower addressed memory. */ -#if (!defined (__LITTLE_ENDIAN__) \ - (defined (__MACH__) || defined (__powerpc__) || defined (_AIX))) +#if defined (__MACH__) || defined (__powerpc__) || defined (_AIX) #define fabs(x) __builtin_fabs(x) #define isless(x, y) __builtin_isless (x, y) This is okay as an interim solution. Thanks, David
Re: [RS6000] LE SFmode constants in toc
On Tue, Jun 4, 2013 at 9:05 AM, Alan Modra amo...@gmail.com wrote: ppc64 SFmode constants in the TOC occupy the first word of a dword. For little-endian, we don't need to shift left. Bootstrapped etc. and committed as obvious revision 199646. * config/rs6000/rs6000.c (output_toc): Correct little-endian float constant output. Okay. Thanks, David
[RS6000] -mfp-in-toc
This patch allows the user to specify -mfp-in-toc/-msum-in-toc options
without being overridden when -fsection-anchors or -mcmodel != small
is in effect. I also change the default to -mno-fp-in-toc for
-mcmodel=medium, because -mcmodel=medium ought to be able to address
constants anywhere from the toc pointer, and putting them in their
usual constant sections (.rodata.cst4 and .rodata.cst8) allow them to
be merged at link time. For -mcmodel=large we keep the default as
-mfp-in-toc because large code model requires a toc entry to address
any constant outside the TOC.
The patch also allows -mcmodel=medium toc relative addressing for
CONSTANT_POOL_ADDRESS_P constants (the very sort we get from
force_const_mem when -mno-fp-in-toc), and allows combine to merge the
low-part of the address calculation with the load/store from memory.
I'm not sure now why I had this disabled, perhaps there was a problem
when we split toc refs early. Bootstrapped and regression tested
powerpc64-linux. OK to apply?
* config/rs6000/rs6000.c (rs6000_option_override_internal): Don't
override user -mfp-in-toc.
(legitimate_constant_pool_address_p): Assume sufficent alignment
on all CONSTANT_POOL_ADDRESS_P constants, not just those put in
the TOC.
(use_toc_relative_ref): Allow CONSTANT_POOL_ADDRESS_P constants
for -mcmodel=medium.
* config/rs6000/linux64.h (SUBSUBTARGET_OVERRIDE_OPTIONS): Don't
override user -mfp-in-toc or -msum-in-toc. Default to
-mno-fp-in-toc for -mcmodel=medium.
Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c (revision 199646)
+++ gcc/config/rs6000/rs6000.c (working copy)
@@ -3042,7 +3042,8 @@ rs6000_option_override_internal (bool global_init_
/* Place FP constants in the constant pool instead of TOC
if section anchors enabled. */
- if (flag_section_anchors)
+ if (flag_section_anchors
+ !global_options_set.x_TARGET_NO_FP_IN_TOC)
TARGET_NO_FP_IN_TOC = 1;
if (TARGET_DEBUG_REG || TARGET_DEBUG_TARGET)
@@ -5617,7 +5618,8 @@ legitimate_constant_pool_address_p (const_rtx x, e
{
return (toc_relative_expr_p (x, strict)
(TARGET_CMODEL != CMODEL_MEDIUM
- || constant_pool_expr_p (XVECEXP (tocrel_base, 0, 0))
+ || (GET_CODE (XVECEXP (tocrel_base, 0, 0)) == SYMBOL_REF
+ CONSTANT_POOL_ADDRESS_P (XVECEXP (tocrel_base, 0, 0)))
|| mode == QImode
|| offsettable_ok_by_alignment (XVECEXP (tocrel_base, 0, 0),
INTVAL (tocrel_offset), mode)));
@@ -6504,7 +6506,6 @@ use_toc_relative_ref (rtx sym)
ASM_OUTPUT_SPECIAL_POOL_ENTRY_P (get_pool_constant (sym),
get_pool_mode (sym)))
|| (TARGET_CMODEL == CMODEL_MEDIUM
- !CONSTANT_POOL_ADDRESS_P (sym)
SYMBOL_REF_LOCAL_P (sym)));
}
Index: gcc/config/rs6000/linux64.h
===
--- gcc/config/rs6000/linux64.h (revision 199644)
+++ gcc/config/rs6000/linux64.h (working copy)
@@ -136,8 +136,11 @@ extern int dot_symbols;
SET_CMODEL (CMODEL_MEDIUM); \
if (rs6000_current_cmodel != CMODEL_SMALL)\
{ \
- TARGET_NO_FP_IN_TOC = 0; \
- TARGET_NO_SUM_IN_TOC = 0; \
+ if (!global_options_set.x_TARGET_NO_FP_IN_TOC) \
+ TARGET_NO_FP_IN_TOC \
+ = rs6000_current_cmodel == CMODEL_MEDIUM; \
+ if (!global_options_set.x_TARGET_NO_SUM_IN_TOC) \
+ TARGET_NO_SUM_IN_TOC = 0; \
} \
} \
} \
--
Alan Modra
Australia Development Lab, IBM
Re: [PATCH][ARM][1/n] Partial IT block deprecation in ARMv8 AArch32
On Tue, 4 Jun 2013, Kyrylo Tkachov wrote: It creates a command line option, -mrestrict-it, that can be used to Command-line options need documenting in invoke.texi. -- Joseph S. Myers jos...@codesourcery.com
Re: [GOOGLE] More strict checking for call args
On Tue, Jun 4, 2013 at 3:56 AM, Richard Biener
richard.guent...@gmail.com wrote:
On Tue, Jun 4, 2013 at 2:55 AM, Dehao Chen de...@google.com wrote:
Hi,
This patch was committed to google branch. But I think it is of
general interest. So is it ok for trunk?
Thanks,
Dehao
gcc/ChangeLog:
2013-06-03 Dehao Chen de...@google.com
*gimple-low.c (gimple_check_call_args): Restrict the call_arg check to
contain same number of args.
Index: gcc/gimple-low.c
===
--- gcc/gimple-low.c (revision 199570)
+++ gcc/gimple-low.c (working copy)
@@ -243,6 +243,8 @@ gimple_check_call_args (gimple stmt, tree fndecl)
!fold_convertible_p (DECL_ARG_TYPE (p), arg)))
return false;
}
+ if (p != NULL)
+ return false;
Please add a comment here, like
/* Not enough parameters to the function call. */
if (p != NULL)
return false;
note that I believe we can deal with this situation just fine during inlining,
we just leave the parameters uninitialized.
So - why do you think the test is a good idea? The whole function should
ideally be not necessary and is just there to avoid situations we cannot
deal with during inlining.
This check is necessary when profile does not match. E.g. if an
indirect call target profile is targeting to an incorrect callee, this
patch can make sure it's verified before actually transforming code.
This could happen is you use an out-of-date profile to optimize for
new code.
Dehao
Richard.
}
else if (parms)
{
Re: [ada, build] host/target configuration
On Jun 3, 2013, at 22:59 , Olivier Hainque hain...@adacore.com wrote: I suggest another approach: if there are significant differences between the run-time systems, they ought to be preserved in the canonical target names. So, adjust config.sub so that it preserve them, and then we can decide based on the canonical target name only. Can we do that without adding loads of instances of this canonical names in all the switch/case statements around ? The idea was trying not to go there because this is a maintenance pain, essentially pointless if the only differences are a couple of Ada RTS unit selections. I can't help but thinking there might be something else that would deserve using a different canonical name. I need to dig in further to determine. Olivier
RE: [PATCH][ARM][1/n] Partial IT block deprecation in ARMv8 AArch32
Hi Joseph, It creates a command line option, -mrestrict-it, that can be used to Command-line options need documenting in invoke.texi. I've added some documentation in invoke.texi Confirmed that documentation builds ok. Thanks, Kyrill 2013-06-04 Kyrylo Tkachov kyrylo.tkac...@arm.com * config/arm/arm.c (MAX_INSN_PER_IT_BLOCK): New macro. (arm_option_override): Override arm_restrict_it where appropriate. (thumb2_final_prescan_insn): Use MAX_INSN_PER_IT_BLOCK. * config/arm/arm.opt (mrestrict-it): New command-line option. * doc/invoke.texi: Document -mrestrict-it. 01-options.patch Description: Binary data
Re: [GOOGLE] More strict checking for call args
Richard's question is that inlining should deal with extra arguments
just fine -- those paths (the insane profile case) won't be executed
anyway. Do you have a case showing otherwise (i.e., the mismatch
upsets the compiler?)
David
On Tue, Jun 4, 2013 at 8:07 AM, Dehao Chen de...@google.com wrote:
On Tue, Jun 4, 2013 at 3:56 AM, Richard Biener
richard.guent...@gmail.com wrote:
On Tue, Jun 4, 2013 at 2:55 AM, Dehao Chen de...@google.com wrote:
Hi,
This patch was committed to google branch. But I think it is of
general interest. So is it ok for trunk?
Thanks,
Dehao
gcc/ChangeLog:
2013-06-03 Dehao Chen de...@google.com
*gimple-low.c (gimple_check_call_args): Restrict the call_arg check to
contain same number of args.
Index: gcc/gimple-low.c
===
--- gcc/gimple-low.c (revision 199570)
+++ gcc/gimple-low.c (working copy)
@@ -243,6 +243,8 @@ gimple_check_call_args (gimple stmt, tree fndecl)
!fold_convertible_p (DECL_ARG_TYPE (p), arg)))
return false;
}
+ if (p != NULL)
+ return false;
Please add a comment here, like
/* Not enough parameters to the function call. */
if (p != NULL)
return false;
note that I believe we can deal with this situation just fine during
inlining,
we just leave the parameters uninitialized.
So - why do you think the test is a good idea? The whole function should
ideally be not necessary and is just there to avoid situations we cannot
deal with during inlining.
This check is necessary when profile does not match. E.g. if an
indirect call target profile is targeting to an incorrect callee, this
patch can make sure it's verified before actually transforming code.
This could happen is you use an out-of-date profile to optimize for
new code.
Dehao
Richard.
}
else if (parms)
{
RE: [patch, testsuite, cilk] Fix cilk tests for simulators
-Original Message-
From: Steve Ellcey [mailto:sell...@mips.com]
Sent: Monday, June 03, 2013 6:31 PM
To: Jeff Law
Cc: Iyer, Balaji V; gcc-patches@gcc.gnu.org
Subject: Re: [patch, testsuite, cilk] Fix cilk tests for simulators
On Mon, 2013-06-03 at 13:47 -0600, Jeff Law wrote:
On 06/03/2013 01:27 PM, Iyer, Balaji V wrote:
I am OK with Steve's changes in most cases. In a few cases, I am
using it as a parameter to pass into tests. On a top-level, the main
reason why I used argc, and argv is that, I want to make sure the
compiler will never do things like constant propagation, and it will
pass it as a variable.
So use Jakub's trick, or define non-inlinable functions which return
suitable tables.
We simply can't use argc/argv in the manner in which those tests do
and I'd rather clean up the test to avoid argc/argv than support two
paths through the test, one with argc/argv, one without.
jeff
I'll leave fixing the tests to Balaji then instead of doing it myself since
that way
he can be sure that they are testing what he wants to test.
Attached, please find a patch that will remove the cilk plus array notation
test's dependency on argc and argv of main function. Here is the changelog
entry.
2013-06-04 Balaji V. Iyer balaji.v.i...@intel.com
* c-c++-common/cilk-plus/AN/array_test1.c (main): Replaced argc, argv
parameters with void.
(main2): Removed argc parameter.
* c-c++-common/cilk-plus/AN/array_test2.c (main2): Likewise.
(main): Replaced argc, argv parameters with void.
* c-c++-common/cilk-plus/AN/array_test_ND.c (main): Likewise.
(main2): Removed argc parameter.
* c-c++-common/cilk-plus/AN/builtin_fn_custom.c (main): Replaced argc
argv parameters with void. Added __asm volatile to avoid optimization
on argc, if necessary.
* c-c++-common/cilk-plus/AN/builtin_fn_mutating (main): Likewise.
* c-c++-common/cilk-plus/AN/builtin_func_double.c (main): Likewise.
* c-c++-common/cilk-plus/AN/builtin_func_double2.c (main): Likewise.
* c-c++-common/cilk-plus/AN/conditional.c (main): Likewise.
* c-c++-common/cilk-plus/AN/exec-once.c (main): Likewise.
* c-c++-common/cilk-plus/AN/exec-once2.c (main): Likewise.
* c-c++-common/cilk-plus/AN/fn_ptr.c (main): Likewise.
* c-c++-common/cilk-plus/AN/gather-scatter-errors.c (main): Likewise.
* c-c++-common/cilk-plus/AN/gather_scatter.c (main): Likewise.
* c-c++-common/cilk-plus/AN/misc.c (main): Likewise.
* c-c++-common/cilk-plus/AN/parser_errors.c (main): Likewise.
* c-c++-common/cilk-plus/AN/parser_errors2.c (main): Likewise.
* c-c++-common/cilk-plus/AN/parser_errors3.c (main): Likewise.
* c-c++-common/cilk-plus/AN/parser_errors4.c (main): Likewise.
* c-c++-common/cilk-plus/AN/rank_mismatch2.c (main): Likewise.
* c-c++-common/cilk-plus/AN/sec_implicit_ex.c (main): Likewise.
* c-c++-common/cilk-plus/AN/sec_reduce_return.c (main): Likewise.
* c-c++-common/cilk-plus/AN/test_builtin_return.c (main): Likewise.
* c-c++-common/cilk-plus/AN/vla.c (main): Likewise.
* c-c++-common/cilk-plus/AN/comma-exp.c (main): Replaced argc, argv
parameters with void.
(main2): Removed argc parameter.
* c-c++-common/cilk-plus/AN/if_test.c (main2): Likewise.
(main): Replaced argc, argv parameters with void.
* c-c++-common/cilk-plus/AN/fp_triplet_values (main2): Replace argc,
argv parameters with void. Also renamed this function as main, and
delete the existing main.
* c-c++-common/cilk-plus/AN/sec_implicit.c (main2): Likewise.
* c-c++-common/cilk-plus/AN/sec_implicit2.c (main2): Likewise.
* c-c++-common/cilk-plus/AN/sec_reduce_max_min_ind.c (main2): Likewise.
So, is it Ok for trunk?
Thanks,
Balaji V. Iyer.
Steve Ellcey
sell...@mips.com
diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
old mode 100644
new mode 100755
index e0f75fd..5a2f360
Binary files a/gcc/testsuite/ChangeLog and b/gcc/testsuite/ChangeLog differ
diff --git a/gcc/testsuite/c-c++-common/cilk-plus/AN/array_test1.c
b/gcc/testsuite/c-c++-common/cilk-plus/AN/array_test1.c
index bdd271a..e4f1ea8 100644
--- a/gcc/testsuite/c-c++-common/cilk-plus/AN/array_test1.c
+++ b/gcc/testsuite/c-c++-common/cilk-plus/AN/array_test1.c
@@ -3,23 +3,17 @@
#include stdlib.h
-int main2 (int argc, char **argv);
+int main2 (char **argv);
-int main(int argc, char **argv)
+int main(void)
{
- int x = 0;
- if (argc == 1)
-{
- const char *array[] = {a.out, 5};
- x = main2 (2, (char **)array);
-}
- else
-x = main2 (argc, argv);
-
+ int x = 0;
+ const char *array[] = {a.out, 5};
+ x = main2 ((char **)array);
return x;
}
-int main2 (int argc, char **argv)
+int main2 (char **argv)
{
int array[10],
Re: [patch, testsuite, cilk] Fix cilk tests for simulators
On 06/04/2013 10:30 AM, Iyer, Balaji V wrote: -Original Message- From: Steve Ellcey [mailto:sell...@mips.com] Sent: Monday, June 03, 2013 6:31 PM To: Jeff Law Cc: Iyer, Balaji V; gcc-patches@gcc.gnu.org Subject: Re: [patch, testsuite, cilk] Fix cilk tests for simulators On Mon, 2013-06-03 at 13:47 -0600, Jeff Law wrote: On 06/03/2013 01:27 PM, Iyer, Balaji V wrote: I am OK with Steve's changes in most cases. In a few cases, I am using it as a parameter to pass into tests. On a top-level, the main reason why I used argc, and argv is that, I want to make sure the compiler will never do things like constant propagation, and it will pass it as a variable. So use Jakub's trick, or define non-inlinable functions which return suitable tables. We simply can't use argc/argv in the manner in which those tests do and I'd rather clean up the test to avoid argc/argv than support two paths through the test, one with argc/argv, one without. jeff I'll leave fixing the tests to Balaji then instead of doing it myself since that way he can be sure that they are testing what he wants to test. Attached, please find a patch that will remove the cilk plus array notation test's dependency on argc and argv of main function. Here is the changelog entry. 2013-06-04 Balaji V. Iyer balaji.v.i...@intel.com * c-c++-common/cilk-plus/AN/array_test1.c (main): Replaced argc, argv parameters with void. (main2): Removed argc parameter. * c-c++-common/cilk-plus/AN/array_test2.c (main2): Likewise. (main): Replaced argc, argv parameters with void. * c-c++-common/cilk-plus/AN/array_test_ND.c (main): Likewise. (main2): Removed argc parameter. * c-c++-common/cilk-plus/AN/builtin_fn_custom.c (main): Replaced argc argv parameters with void. Added __asm volatile to avoid optimization on argc, if necessary. * c-c++-common/cilk-plus/AN/builtin_fn_mutating (main): Likewise. * c-c++-common/cilk-plus/AN/builtin_func_double.c (main): Likewise. * c-c++-common/cilk-plus/AN/builtin_func_double2.c (main): Likewise. * c-c++-common/cilk-plus/AN/conditional.c (main): Likewise. * c-c++-common/cilk-plus/AN/exec-once.c (main): Likewise. * c-c++-common/cilk-plus/AN/exec-once2.c (main): Likewise. * c-c++-common/cilk-plus/AN/fn_ptr.c (main): Likewise. * c-c++-common/cilk-plus/AN/gather-scatter-errors.c (main): Likewise. * c-c++-common/cilk-plus/AN/gather_scatter.c (main): Likewise. * c-c++-common/cilk-plus/AN/misc.c (main): Likewise. * c-c++-common/cilk-plus/AN/parser_errors.c (main): Likewise. * c-c++-common/cilk-plus/AN/parser_errors2.c (main): Likewise. * c-c++-common/cilk-plus/AN/parser_errors3.c (main): Likewise. * c-c++-common/cilk-plus/AN/parser_errors4.c (main): Likewise. * c-c++-common/cilk-plus/AN/rank_mismatch2.c (main): Likewise. * c-c++-common/cilk-plus/AN/sec_implicit_ex.c (main): Likewise. * c-c++-common/cilk-plus/AN/sec_reduce_return.c (main): Likewise. * c-c++-common/cilk-plus/AN/test_builtin_return.c (main): Likewise. * c-c++-common/cilk-plus/AN/vla.c (main): Likewise. * c-c++-common/cilk-plus/AN/comma-exp.c (main): Replaced argc, argv parameters with void. (main2): Removed argc parameter. * c-c++-common/cilk-plus/AN/if_test.c (main2): Likewise. (main): Replaced argc, argv parameters with void. * c-c++-common/cilk-plus/AN/fp_triplet_values (main2): Replace argc, argv parameters with void. Also renamed this function as main, and delete the existing main. * c-c++-common/cilk-plus/AN/sec_implicit.c (main2): Likewise. * c-c++-common/cilk-plus/AN/sec_implicit2.c (main2): Likewise. * c-c++-common/cilk-plus/AN/sec_reduce_max_min_ind.c (main2): Likewise. So, is it Ok for trunk? Yes. This is fine for the trunk. Funny, it looks like we were both waiting on Steve's feedback from your updated test. Jeff
Re: [GOOGLE] Unrestrict early inline restrictions for AutoFDO
Patch updated to set the iteration threshold to 10 for AutoFDO.
Performance test shows ok.
OK for google-4_8 branch?
Thanks,
Dehao
Index: gcc/ipa-inline.c
===
--- gcc/ipa-inline.c (revision 199593)
+++ gcc/ipa-inline.c (working copy)
@@ -2161,8 +2161,7 @@ early_inliner (void)
{
/* We iterate incremental inlining to get trivial cases of indirect
inlining. */
- while ((flag_auto_profile
- || iterations PARAM_VALUE (PARAM_EARLY_INLINER_MAX_ITERATIONS))
+ while (iterations PARAM_VALUE (PARAM_EARLY_INLINER_MAX_ITERATIONS)
early_inline_small_functions (node))
{
timevar_push (TV_INTEGRATION);
Index: gcc/opts.c
===
--- gcc/opts.c (revision 199593)
+++ gcc/opts.c (working copy)
@@ -784,6 +784,10 @@ finish_options (struct gcc_options *opts, struct g
opts-x_param_values, opts_set-x_param_values);
}
+ if (opts-x_flag_auto_profile)
+maybe_set_param_value (PARAM_EARLY_INLINER_MAX_ITERATIONS, 10,
+ opts-x_param_values, opts_set-x_param_values);
+
if (opts-x_flag_lto)
{
#ifdef ENABLE_LTO
Re: [Fortran, committed] Fix bugs in the dg-* directives in the test suite (was: testsuite oddities)
On Jun 4, 2013, at 12:37 AM, Tobias Burnus bur...@net-b.de wrote: I think some of the test cases might to it on purpose: dg-do run causes the test case to run only once while dg-do run runs multiple times with different options. If the testcase is supposed to test the run-time library, calling it multiple times is pointless. Admittedly, using two spaces is an ugly hack, :-o, The things we never knew. Anyway, use of hacks like this, should result in the hack being documented. At least then we can find them with find-grep in emacs, and know about it. I'm not in favor of using hacks like this, I don't endorse it. If someone wants to approve such a patch in their part of the test suite, that's fine with me. but creating a dg-do run-single is difficult. Well, my first question is, why can't test cases that run in a context that means, run multiple times, be moved from that context, to a context that means, run once? Seems straight forward. In the C test suite, that would be moving from \*torture to \* (other than torture), usually. If fortran doesn't have a run once context, seems reasonable to create one, I'd recommend doing this once there are 20 or more test cases that use the hack.
Re: [Fortran, committed] Fix bugs in the dg-* directives in the test suite (was: testsuite oddities)
[ sorry for the dup ] On Jun 4, 2013, at 12:37 AM, Tobias Burnus bur...@net-b.de wrote: I think some of the test cases might to it on purpose: dg-do run causes the test case to run only once while dg-do run runs multiple times with different options. If the testcase is supposed to test the run-time library, calling it multiple times is pointless. Admittedly, using two spaces is an ugly hack, :-o, The things we never knew. Anyway, use of hacks like this, should result in the hack being documented. At least then we can find them with find-grep in emacs, and know about it. I'm not in favor of using hacks like this, I don't endorse it. If someone wants to approve such a patch in their part of the test suite, that's fine with me. but creating a dg-do run-single is difficult. Well, my first question is, why can't test cases that run in a context that means, run multiple times, be moved from that context, to a context that means, run once? Seems straight forward. In the C test suite, that would be moving from \*torture to \* (other than torture), usually. If fortran doesn't have a run once context, seems reasonable to create one, I'd recommend doing this once there are 20 or more test cases that use the hack.
Re: [GOOGLE] Unrestrict early inline restrictions for AutoFDO
ok.
David
On Tue, Jun 4, 2013 at 9:51 AM, Dehao Chen de...@google.com wrote:
Patch updated to set the iteration threshold to 10 for AutoFDO.
Performance test shows ok.
OK for google-4_8 branch?
Thanks,
Dehao
Index: gcc/ipa-inline.c
===
--- gcc/ipa-inline.c (revision 199593)
+++ gcc/ipa-inline.c (working copy)
@@ -2161,8 +2161,7 @@ early_inliner (void)
{
/* We iterate incremental inlining to get trivial cases of indirect
inlining. */
- while ((flag_auto_profile
- || iterations PARAM_VALUE (PARAM_EARLY_INLINER_MAX_ITERATIONS))
+ while (iterations PARAM_VALUE (PARAM_EARLY_INLINER_MAX_ITERATIONS)
early_inline_small_functions (node))
{
timevar_push (TV_INTEGRATION);
Index: gcc/opts.c
===
--- gcc/opts.c (revision 199593)
+++ gcc/opts.c (working copy)
@@ -784,6 +784,10 @@ finish_options (struct gcc_options *opts, struct g
opts-x_param_values, opts_set-x_param_values);
}
+ if (opts-x_flag_auto_profile)
+maybe_set_param_value (PARAM_EARLY_INLINER_MAX_ITERATIONS, 10,
+ opts-x_param_values, opts_set-x_param_values);
+
if (opts-x_flag_lto)
{
#ifdef ENABLE_LTO
Re: [PATCH, libcpp] Do not decrease highest_location if the included file has be included twice.
Hi, Dodji,
Thanks for helping update the patch. The new patch passed all
regression test and can fix the problem in my huge source file. I
added ChangeLog entry to the patch. Could any libcpp maintainers help
check if it is ok for trunk?
Thanks,
Dehao
libcpp/ChangeLog:
2013-06-04 Dehao Chen de...@google.com
* files.c (_cpp_stack_include): Fix the highest_location when header
file is guarded by #ifndef and is included twice.
Index: libcpp/files.c
===
--- libcpp/files.c (revision 199570)
+++ libcpp/files.c (working copy)
@@ -983,6 +983,7 @@ _cpp_stack_include (cpp_reader *pfile, const char
{
struct cpp_dir *dir;
_cpp_file *file;
+ bool stacked;
dir = search_path_head (pfile, fname, angle_brackets, type);
if (!dir)
@@ -993,19 +994,26 @@ _cpp_stack_include (cpp_reader *pfile, const char
if (type == IT_DEFAULT file == NULL)
return false;
- /* Compensate for the increment in linemap_add that occurs in
- _cpp_stack_file. In the case of a normal #include, we're
- currently at the start of the line *following* the #include. A
- separate source_location for this location makes no sense (until
- we do the LC_LEAVE), and complicates LAST_SOURCE_LINE_LOCATION.
- This does not apply if we found a PCH file (in which case
- linemap_add is not called) or we were included from the
- command-line. */
+ /* Compensate for the increment in linemap_add that occurs if
+ _cpp_stack_file actually stacks the file. In the case of a
+ normal #include, we're currently at the start of the line
+ *following* the #include. A separate source_location for this
+ location makes no sense (until we do the LC_LEAVE), and
+ complicates LAST_SOURCE_LINE_LOCATION. This does not apply if we
+ found a PCH file (in which case linemap_add is not called) or we
+ were included from the command-line. */
if (file-pchname == NULL file-err_no == 0
type != IT_CMDLINE type != IT_DEFAULT)
pfile-line_table-highest_location--;
- return _cpp_stack_file (pfile, file, type == IT_IMPORT);
+ stacked = _cpp_stack_file (pfile, file, type == IT_IMPORT);
+
+ if (!stacked)
+/* _cpp_stack_file didn't stack the file, so let's rollback the
+ compensation dance we performed above. */
+pfile-line_table-highest_location++;
+
+ return stacked;
}
/* Could not open FILE. The complication is dependency output. */
Re: [Fortran, committed] Fix bugs in the dg-* directives in the test suite
Mike Stump wrote: :-o, The things we never knew. Anyway, use of hacks like this, should result in the hack being documented. At least then we can find them with find-grep in emacs, and know about it. I'm not in favor of using hacks like this, I don't endorse it. If someone wants to approve such a patch in their part of the test suite, that's fine with me. I think only cray_pointers_2.f90 strictly requires it as it takes quite long and, thus, caused problems on one system. See: http://gcc.gnu.org/ml/fortran/2011-01/msg00089.html but creating a dg-do run-single is difficult. [...] If fortran doesn't have a run once context, seems reasonable to create one, I'd recommend doing this once there are 20 or more test cases that use the hack. Maybe one should create a run-once context - to save some testing time. However, the number of test cases with dg-do run is a low one digit number. (Admittedly, I have no idea why the default gfortran.dg/dg.exp runs multiple times - and also not what's the exact purpose of gfortran.fortran-torture.) Tobias
Re: [PATCH, updated] Vtable pointer verification, C++ front end changes (patch 1 of 3)
On 05/24/2013 12:15 PM, Caroline Tice wrote: Changes to g++spec.c only affect the g++ driver, not the gcc driver. Are you sure this is what you want? Can't you handle this stuff directly in the specs like address sanitizer does? I haven't seen a response to this comment. It seems correct to only update the g++ driver, since this option only does things for C++ programs. But people don't always compile C++ programs with the g++ driver; the gcc driver works fine for programs that don't require libstdc++. I'm not sure what address sanitizer does directly in the specs...Which specs would these be? SANITIZER_EARLY_SPEC and SANITIZER_SPEC in gcc.c. Originally I was not doing anything with the specs, and so I didn't want to have to add a special link command, to link in a special library whenever the fvtable-verify option is used. Now that I've started changing the specs anyway, I suppose I could go ahead and put this in its own separate library and add a link option. Is that really the way I should go with this? I think so, yes. These changes should not be necessary. Just set DECL_ONE_ONLY on the vtable map variables. I am sorry to disagree with you, but you are incorrect. The second change can be eliminated (the one that adds SECTION_LINKONCE to flags), but the first change above is necessary. What the first bit of code does is to ensure that each vtable map variable gets its own unique comdat name. When I tried removing this code, it put all the vtable map variables into the same section with a single comdat name. Ah, I see. Then that's a bug that ought to be fixed: resolve_unique_section needs to deal better with decls with both DECL_SECTION_NAME and DECL_ONE_ONLY set. But I guess for now let's leave your code as it is with a FIXME note. + /* We need to check value and find the bit where we + have something with 2 arguments, the first + argument of which is an ADDR_EXPR and the second + argument of which is an INTEGER_CST. */ + + while (value TREE_OPERAND_LENGTH (value) == 1 + TREE_CODE (TREE_OPERAND (value, 0)) == ADDR_EXPR) +value = TREE_OPERAND (value, 0); The comment doesn't match the code; you're testing for something with one operand. And it seems strange to test for anything with one operand. I will update the comment. Are you sure that's the right fix? What is the purpose of this code? The comment sounds like you want to strip away an offset relative to a vtable pointer and get the actual vtable. Testing for length 1 won't accomplish that for you. + (vtable_decl = get_vtbl_decl_for_binfo (base_binfo)) + !(DECL_VTABLE_OR_VTT_P (vtable_decl) +DECL_CONSTRUCTION_VTABLE_P (vtable_decl))) get_vtbl_decl_for_binfo will never return a construction vtable. When I tried removing that condition, my thunk test failed. When I add it back, the test passes again. Failed how? I'm puzzled. All that check could do would be to avoid registering a construction vtable, which should be harmless anyway. +create_undef_reference_to___vtv_init (tree init_routine_body) Why do we need this, given that we'll already have references to the various registration functions? This inserts a reference to a symbol that will only be resolved if the proper libraries are linked in. It is a way to make sure that, if some library did not get linked in properly, we get a link time failure rather than a run time failure. Won't the references to the registration functions also cause link time failures? + vtv_finish_verification___constructor_init_function (init_routine_body); + allocate_struct_function (current_function_decl, false); Why the allocate_struct_function? If you're doing something that needs cfun to be set, push_cfun (DECL_STRUCT_FUNCTION (current_function_decL)); would be better, but I don't see anything that would need it. If I omit allocate_struct_function and do nothing else, I get an ICE in gimplify_function_tree (a few lines further down). (It actually fails on an assert from push_cfun, which is called from gimplify_function_tree). I think this is breaking because you set current_function_decl. It ought to work better if you leave it unset and let gimplify_function_tree set it for you. Jason
RE: [PATCH] pr57457
-Original Message-
From: Jeff Law [mailto:l...@redhat.com]
Sent: Monday, June 03, 2013 3:07 PM
To: Iyer, Balaji V
Cc: gcc-patches@gcc.gnu.org; Steve Ellcey
Subject: Re: [PATCH] pr57457
On 05/31/2013 12:01 PM, Iyer, Balaji V wrote:
-Original Message- From: gcc-patches-ow...@gcc.gnu.org
[mailto:gcc-patches- ow...@gcc.gnu.org] On Behalf Of Jeff Law Sent:
Friday, May 31, 2013 11:50 AM To: Iyer, Balaji V Cc:
gcc-patches@gcc.gnu.org; Steve Ellcey Subject: Re: [PATCH] pr57457
On 05/31/2013 07:54 AM, Iyer, Balaji V wrote:
Hello Everyone, This patch will fix a bug reported in PR57457.
One of the array notation
function was not checking for NULL_TREE before accessing its fields.
This patch should fix that issue. A test case is also added.
Is this OK for trunk?
Here are the ChangeLog Entries:
gcc/c/ChangeLog 2013-05-31 Balaji V. Iyer balaji.v.i...@intel.com
* c-array-notation.c (is_cilkplus_reduce_builtin): Added a check for
NULL_TREE parameter input.
gcc/testsuite/ChangeLog 2013-05-31 Balaji V. Iyer
balaji.v.i...@intel.com
PR c/57457 * c-c++-common/cilk-plus/AN/pr57457.c: New testcase.
So what you need to do is explain how you got into this function with
a NULL fndecl and why that's OK.
Hi Jeff, I looked into it, and there is another function call called
inform_declaration, and that does exactly what I did (i.e. check for
NULL fundecl before accessing its fields). From what I can tell,
fundecl will be NULL_TREE if a function declaration is a function
pointer.
The problematical calls are coming from convert_arguments which is a bit
inconsistent in how it handles a null FUNDECL. In some places it checks it
direction in convert_arguments and avoids certain actions. In other places
the
callee checks.
The code looks like it's screaming to be simplified. Neither flag_cilkplus
nor
FUNDECL change inside the main loop in convert_arguments, so the first thing
I'd ponder is pulling that condition out of the loop. And after doing that
we a
similar condition being used to suppress warnings just after the loop. I
wonder if
we could have something like
if (flag_enable_cilkplus
fundecl
is_cilkplus_reduction_builtin (fundecl))
return vec_safe_length (values);
before the loop, then eliminate the the test inside the loop and just after
the
loop.
That simplifies the code a bit and should fix this problem unless I'm missing
something?
Yes, that does simplify the whole thing. Here is an updated ChangeLog and patch
(with testcode) attached. So, is it Ok for trunk?
gcc/testsuite/ChangeLog
2013-06-04 Balaji V. Iyer balaji.v.i...@intel.com
PR C/57457
* c-c++-common/cilk-plus/AN/pr57457.c: New test.
gcc/c/ChangeLog
2013-06-04 Balaji V. Iyer balaji.v.i...@intel.com
* c-typeck.c (convert_arguments): Moved checking of builtin cilkplus
reduction functions outside the for-loop. Also, added a check if the
fundecl is non-NULL.
Thanks,
Balaji V. Iyer.
jeff
diff --git a/gcc/c/c-typeck.c b/gcc/c/c-typeck.c
index e5e1455..91ce67a 100644
--- a/gcc/c/c-typeck.c
+++ b/gcc/c/c-typeck.c
@@ -2942,6 +2942,8 @@ convert_arguments (tree typelist, vectree, va_gc
*values,
break;
}
}
+ if (flag_enable_cilkplus fundecl is_cilkplus_reduce_builtin (fundecl))
+return vec_safe_length (values);
/* Scan the given expressions and types, producing individual
converted arguments. */
@@ -2959,17 +2961,6 @@ convert_arguments (tree typelist, vectree, va_gc
*values,
bool npc;
tree parmval;
- // FIXME: I assume this code is here to handle the overloaded
- // behavior of the __sec_reduce* builtins, and avoid giving
- // argument mismatch warnings/errors. We should probably handle
- // this with the resolve_overloaded_builtin infrastructure.
- /* If the function call is a builtin function call, then we do not
-worry about it since we break them up into its equivalent later and
-we do the appropriate checks there. */
- if (flag_enable_cilkplus
- is_cilkplus_reduce_builtin (fundecl))
- continue;
-
if (type == void_type_node)
{
if (selector)
diff --git a/gcc/testsuite/c-c++-common/cilk-plus/AN/pr57457.c
b/gcc/testsuite/c-c++-common/cilk-plus/AN/pr57457.c
new file mode 100644
index 000..68a1fd8
--- /dev/null
+++ b/gcc/testsuite/c-c++-common/cilk-plus/AN/pr57457.c
@@ -0,0 +1,39 @@
+/* { dg-do compile } */
+/* { dg-options -fcilkplus } */
+
+/* This test has no array notation components in it and thus should compile
+ fine without crashing. */
+
+typedef unsigned int size_t;
+typedef int (*__compar_fn_t) (const void *, const void *);
+extern void *bsearch (const void *__key, const void *__base,
+ size_t __nmemb, size_t __size, __compar_fn_t
+ __compar)
+ __attribute__
Re: [PATCH] Basic support for MIPS r5900
Jürgen Urban juergenur...@gmx.de writes: Hello Richard, Thanks, looks good. The comments I have are only minor and seemed easier to spell out as a revised patch, attached below. The changes are: * removing the config.sub bit, which looked redundant. We already have the up-to-date upstream config.sub. * removing the target_cpu_default setting. I realise this was taken from mips64-elf, but it was redundant here, there, and elsewhere. I've just committed a patch to remove the existing cases. * removing the TUNE_5900 definition. I prefer not to define these kinds of macro until they're used. * removing the ISA_HAS_LDC1_SDC1 setting. I realise what you did describes the reality of the processor, but the problem is that the patch doesn't provide an alternative for 64-bit loads and stores when -mfp64 is used. That combination also isn't rejected, so we're likely to get an internal compiler error instead. This change shouldn't affect the soft-float case you describe. It also shouldn't be important for the single-float code. * tweaking the mips_reorg_process_insns comment slightly * fixing a few minor formatting issues Does this version look OK to you? I'll commit it if so. This is OK and the generated code is still working on the PS2 in my test run. Thanks, now applied. FWIW, the Cygnus/Red Hat version of the port just stuck with the R5900 behaviour and made GCC understand it (MODE_HAS_* various other bits). This code was then updated and extended for the SPU. I'd have expected the support to be in reasonably good shape because of the SPU. I assume that you mean the cell processor of the PS3 and not the Sound Processing Unit of the PS2. :-) The macros MODE_HAS_* in the GCC look promising. You've probably already seen it, but there's also spu_single_format. Richard
Re: [PATCH] pr57457
On 06/04/2013 11:37 AM, Iyer, Balaji V wrote:
Yes, that does simplify the whole thing. Here is an updated ChangeLog
and patch (with testcode) attached. So, is it Ok for trunk?
gcc/testsuite/ChangeLog 2013-06-04 Balaji V. Iyer
balaji.v.i...@intel.com
PR C/57457 * c-c++-common/cilk-plus/AN/pr57457.c: New test.
gcc/c/ChangeLog 2013-06-04 Balaji V. Iyer
balaji.v.i...@intel.com
* c-typeck.c (convert_arguments): Moved checking of builtin cilkplus
reduction functions outside the for-loop. Also, added a check if
the fundecl is non-NULL.
OK. This looks good. Please install.
As a follow-up, don't we need to do something with the test after the
loop as well:
if (typetail != 0 TREE_VALUE (typetail) != void_type_node)
{
/* If array notation is used and Cilk Plus is enabled, then we do not
worry about this error now. We will handle them in a later
place. */
if (!flag_enable_cilkplus
|| !is_cilkplus_reduce_builtin (fundecl))
{
error_at (input_location,
too few arguments to function %qE, function);
inform_declaration (fundecl);
return -1;
}
}
ISTM we need to check for a NULL FUNDECL here too.
jeff
Re: [PATCH] Improve folding of bitwise ops on booleans
On 06/04/2013 04:45 AM, Richard Biener wrote: Yes. Booleans are integral types with a single bit of precision, right? So this check should allow boolean types. What am I missing? We have BOOLEAN_TYPEs that do not have a TYPE_PRECISION of one (but still are two-valued, and we assume those values are 0 and != 0 (eh)). So there is code that treats BOOLEAN_TYPEs the same as TYPE_PRECISION one types and there is code that does not (for example bitwise not is not equal to truth not on such types). Good grief. For a boolean with a TYPE_PRECISION != 1, I think we can apply the transformations if the type is unsigned. Once the type is signed I think we'd lose. Do you have any sample code which would create a boolean type with a precision other than 1? jeff
Re: [PATCH] Improve folding of bitwise ops on booleans
2013/6/4 Jeff Law l...@redhat.com: On 06/04/2013 04:45 AM, Richard Biener wrote: Yes. Booleans are integral types with a single bit of precision, right? So this check should allow boolean types. What am I missing? We have BOOLEAN_TYPEs that do not have a TYPE_PRECISION of one (but still are two-valued, and we assume those values are 0 and != 0 (eh)). So there is code that treats BOOLEAN_TYPEs the same as TYPE_PRECISION one types and there is code that does not (for example bitwise not is not equal to truth not on such types). Good grief. For a boolean with a TYPE_PRECISION != 1, I think we can apply the transformations if the type is unsigned. Once the type is signed I think we'd lose. Do you have any sample code which would create a boolean type with a precision other than 1? jeff AFAI recall, the boolean-type in Ada has 8-bit precision. I think we have to omit this transformations for any boolean-type with type-precision not equal to 1. Ada uses the other values for sanity-check AFAIR. Kai
Re: [patch] PR 57362
Hi,
Sorry for the long delay. Test case added and patch attached. OK to commit?
Thanks
Sri
On Wed, May 22, 2013 at 5:14 PM, H.J. Lu hjl.to...@gmail.com wrote:
On Wed, May 22, 2013 at 4:20 PM, Sriraman Tallam tmsri...@google.com wrote:
Hi,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57362
This ICE reported here happens because the array storing the
function versions that should be processed is not indexed correctly.
This patch fixes this. This only happens when some versions cannot be
dispatched because a dispatcher for that is not available or is an
invalid target.
Is this alright?
Thanks,
Sri
PR 57362
* config/i386/i386.c (dispatch_function_versions): Use
actual_versions to index into
function_version_info.
Index: config/i386/i386.c
===
--- config/i386/i386.c (revision 199219)
+++ config/i386/i386.c (working copy)
@@ -29061,10 +29061,10 @@ dispatch_function_versions (tree dispatch_decl,
if (predicate_chain == NULL_TREE)
continue;
+ function_version_info [actual_versions].version_decl = version_decl;
+ function_version_info [actual_versions].predicate_chain =
predicate_chain;
+ function_version_info [actual_versions].dispatch_priority = priority;
actual_versions++;
- function_version_info [ix - 1].version_decl = version_decl;
- function_version_info [ix - 1].predicate_chain = predicate_chain;
- function_version_info [ix - 1].dispatch_priority = priority;
}
/* Sort the versions according to descending order of dispatch priority.
The
You should also add the testcase in PR57362.
--
H.J.
Index: config/i386/i386.c
===
--- config/i386/i386.c (revision 199662)
+++ config/i386/i386.c (working copy)
@@ -29357,10 +29357,11 @@ dispatch_function_versions (tree dispatch_decl,
if (predicate_chain == NULL_TREE)
continue;
+ function_version_info [actual_versions].version_decl = version_decl;
+ function_version_info [actual_versions].predicate_chain
+= predicate_chain;
+ function_version_info [actual_versions].dispatch_priority = priority;
actual_versions++;
- function_version_info [ix - 1].version_decl = version_decl;
- function_version_info [ix - 1].predicate_chain = predicate_chain;
- function_version_info [ix - 1].dispatch_priority = priority;
}
/* Sort the versions according to descending order of dispatch priority. The
Index: testsuite/g++.dg/ext/pr57362.C
===
--- testsuite/g++.dg/ext/pr57362.C (revision 0)
+++ testsuite/g++.dg/ext/pr57362.C (revision 0)
@@ -0,0 +1,199 @@
+/* { dg-do compile { target i?86-*-* x86_64-*-* } } */
+/* { dg-require-ifunc } */
+
+__attribute__((target(default)))
+int foo(void) { return 1; }
+__attribute__((target(128bit-long-double)))
+int foo(void) { return 1; }
+__attribute__((target(80387)))
+int foo(void) { return 1; }
+__attribute__((target(96bit-long-double)))
+int foo(void) { return 1; }
+__attribute__((target(long-double-80)))
+int foo(void) { return 1; }
+__attribute__((target(long-double-64)))
+int foo(void) { return 1; }
+__attribute__((target(accumulate-outgoing-args)))
+int foo(void) { return 1; }
+__attribute__((target(align-double)))
+int foo(void) { return 1; }
+__attribute__((target(align-stringops)))
+int foo(void) { return 1; }
+__attribute__((target(fancy-math-387)))
+int foo(void) { return 1; }
+__attribute__((target(force-drap)))
+int foo(void) { return 1; }
+__attribute__((target(fp-ret-in-387)))
+int foo(void) { return 1; }
+__attribute__((target(hard-float)))
+int foo(void) { return 1; }
+__attribute__((target(ieee-fp)))
+int foo(void) { return 1; }
+__attribute__((target(inline-all-stringops)))
+int foo(void) { return 1; }
+__attribute__((target(inline-stringops-dynamically)))
+int foo(void) { return 1; }
+__attribute__((target(intel-syntax)))
+int foo(void) { return 1; }
+__attribute__((target(ms-bitfields)))
+int foo(void) { return 1; }
+__attribute__((target(no-align-stringops)))
+int foo(void) { return 1; }
+__attribute__((target(no-fancy-math-387)))
+int foo(void) { return 1; }
+__attribute__((target(no-push-args)))
+int foo(void) { return 1; }
+__attribute__((target(no-red-zone)))
+int foo(void) { return 1; }
+__attribute__((target(omit-leaf-frame-pointer)))
+int foo(void) { return 1; }
+__attribute__((target(pc32)))
+int foo(void) { return 1; }
+__attribute__((target(pc64)))
+int foo(void) { return 1; }
+__attribute__((target(pc80)))
+int foo(void) { return 1; }
+__attribute__((target(push-args)))
+int foo(void) { return 1; }
+__attribute__((target(red-zone)))
+int foo(void) { return 1; }
+__attribute__((target(rtd)))
+int foo(void) { return 1; }
+__attribute__((target(soft-float)))
+int foo(void) { return 1; }
RE: [PATCH] pr57457
-Original Message-
From: Jeff Law [mailto:l...@redhat.com]
Sent: Tuesday, June 04, 2013 2:07 PM
To: Iyer, Balaji V
Cc: gcc-patches@gcc.gnu.org; Steve Ellcey
Subject: Re: [PATCH] pr57457
On 06/04/2013 11:37 AM, Iyer, Balaji V wrote:
Yes, that does simplify the whole thing. Here is an updated ChangeLog
and patch (with testcode) attached. So, is it Ok for trunk?
gcc/testsuite/ChangeLog 2013-06-04 Balaji V. Iyer
balaji.v.i...@intel.com
PR C/57457 * c-c++-common/cilk-plus/AN/pr57457.c: New test.
gcc/c/ChangeLog 2013-06-04 Balaji V. Iyer balaji.v.i...@intel.com
* c-typeck.c (convert_arguments): Moved checking of builtin cilkplus
reduction functions outside the for-loop. Also, added a check if the
fundecl is non-NULL.
OK. This looks good. Please install.
As a follow-up, don't we need to do something with the test after the loop as
well:
if (typetail != 0 TREE_VALUE (typetail) != void_type_node)
{
/* If array notation is used and Cilk Plus is enabled, then we do not
worry about this error now. We will handle them in a later place.
*/
if (!flag_enable_cilkplus
|| !is_cilkplus_reduce_builtin (fundecl))
{
error_at (input_location,
too few arguments to function %qE, function);
inform_declaration (fundecl);
return -1;
}
}
ISTM we need to check for a NULL FUNDECL here too.
Actually, you can eliminate the entire if-statement (i.e. remove if-statement
and make the body unconditional). This is because, if flag_enable_cilkplus is
true and is_cilkplus_reduce_builtin (fundecl) is true, then it would have
returned vec_safe_length(values) and will not even get to this point in the
first place. So, this is technically equivalent to if (1). So, can I remove
that and check it in also? It passes all my regression tests.
Thanks,
Balaji V. Iyer.
jeff
Re: [PATCH] Improve folding of bitwise ops on booleans
On 06/03/2013 08:23 AM, Kai Tietz wrote: Btw there is one optimization in this context which might be something worth here too. -X - X for 1-bit typed X (signed doesn't matter here). I've had a hell of a time trying to trigger a case where this isn't already handled. Samples welcome.
[patch, libgfortran, configure] Cross-compile support for libgfortran
This patch allows me to build libgfortran for a cross-compiling toolchain
using newlib. Currently the checks done by AC_CHECK_FUNCS_ONCE fail with
my toolchain because the compile/link fails due to the configure script not
using the needed linker script in the link command. The check for with_newlib
is how libjava deals with the problem and it fixes my build problems.
My only concern is defining HAVE_STRTOLD, strtold exists in my newlib but
I am not sure if that is true for all newlib builds. I didn't see any
flags that I could easily use to check for long double support in the
libgfortran configure.ac, but it seems to assume that the type exists.
OK to checkin?
Steve Ellcey
sell...@mips.com
2013-06-04 Steve Ellcey sell...@mips.com
* configure.ac (AC_CHECK_FUNCS_ONCE): Put into if statement.
diff --git a/libgfortran/configure.ac b/libgfortran/configure.ac
index 7d97fed..4a00470 100644
--- a/libgfortran/configure.ac
+++ b/libgfortran/configure.ac
@@ -261,13 +261,27 @@ GCC_HEADER_STDINT(gstdint.h)
AC_CHECK_MEMBERS([struct stat.st_blksize, struct stat.st_blocks, struct
stat.st_rdev])
# Check for library functions.
-AC_CHECK_FUNCS_ONCE(getrusage times mkstemp strtof strtold snprintf \
-ftruncate chsize chdir getlogin gethostname kill link symlink sleep ttyname \
-alarm access fork execl wait setmode execve pipe dup2 close \
-strcasestr getrlimit gettimeofday stat fstat lstat getpwuid vsnprintf dup \
-getcwd localtime_r gmtime_r getpwuid_r ttyname_r clock_gettime \
-readlink getgid getpid getppid getuid geteuid umask getegid \
-secure_getenv __secure_getenv)
+if test x${with_newlib} = xyes; then + # We are being configured with a
cross compiler. AC_REPLACE_FUNCS
+ # may not work correctly, because the compiler may not be able to
+ # link executables.
+ AC_DEFINE(HAVE_MKSTEMP, 1, [Define if you have mkstemp.])
+ AC_DEFINE(HAVE_STRTOF, 1, [Define if you have strtof.])
+ AC_DEFINE(HAVE_STRTOLD, 1, [Define if you have strtold.])
+ AC_DEFINE(HAVE_SNPRINTF, 1, [Define if you have snprintf.])
+ AC_DEFINE(HAVE_STRCASESTR, 1, [Define if you have strcasestr.])
+ AC_DEFINE(HAVE_VSNPRINTF, 1, [Define if you have vsnprintf.])
+ AC_DEFINE(HAVE_LOCALTIME_R, 1, [Define if you have localtime_r.])
+ AC_DEFINE(HAVE_GMTIME_R, 1, [Define if you have gmtime_r.])
+else
+ AC_CHECK_FUNCS_ONCE(getrusage times mkstemp strtof strtold snprintf \
+ ftruncate chsize chdir getlogin gethostname kill link symlink sleep ttyname
\
+ alarm access fork execl wait setmode execve pipe dup2 close \
+ strcasestr getrlimit gettimeofday stat fstat lstat getpwuid vsnprintf dup \
+ getcwd localtime_r gmtime_r getpwuid_r ttyname_r clock_gettime \
+ readlink getgid getpid getppid getuid geteuid umask getegid \
+ secure_getenv __secure_getenv)
+fi
# Check strerror_r, cannot be above as versions with two and three arguments
exist
LIBGFOR_CHECK_STRERROR_R
Re: GCC does not support *mmintrin.h with function specific opts
Ping.
On Thu, May 23, 2013 at 2:41 PM, Sriraman Tallam tmsri...@google.com wrote:
Ping, for review of ipa-inline.c change.
Sri
On Mon, May 20, 2013 at 11:04 AM, Sriraman Tallam tmsri...@google.com wrote:
On Fri, May 17, 2013 at 11:21 PM, Jakub Jelinek ja...@redhat.com wrote:
On Fri, May 17, 2013 at 09:00:21PM -0700, Sriraman Tallam wrote:
--- ipa-inline.c (revision 198950)
+++ ipa-inline.c (working copy)
@@ -374,7 +374,33 @@ can_early_inline_edge_p (struct cgraph_edge *e)
return false;
}
if (!can_inline_edge_p (e, true))
-return false;
+{
+ enum availability avail;
+ struct cgraph_node *callee
+= cgraph_function_or_thunk_node (e-callee, avail);
+ /* Flag an error when the inlining cannot happen because of target
option
+ mismatch but the callee is marked as always_inline. In -O0 mode
+ this will go undetected because the error flagged in
+ expand_call_inline in tree-inline.c might not execute and the
+ inlining will not happen. Then, the linker could complain about a
+ missing body for the callee if it turned out that the callee was
+ also marked gnu_inline with extern inline keyword as bodies of
such
+ functions are not generated. */
+ if ((!optimize
+|| flag_no_inline)
This should be if ((!optimize || flag_no_inline) on one line.
I'd prefer also the testcase for the ICEs, something like:
/* Test case to check if AVX intrinsics and function specific target
optimizations work together. Check by including x86intrin.h */
/* { dg-do compile } */
/* { dg-options -O2 -mno-sse -mno-avx } */
#include x86intrin.h
__m256 a, b, c;
void __attribute__((target (avx)))
foo (void)
{
a = _mm256_and_ps (b, c);
}
and another testcase that does:
/* { dg-do compile } */
#pragma GCC target (mavx) /* { dg-error whatever } */
Otherwise it looks good to me, but I'd prefer the i?86 maintainers to review
it too (and Honza for ipa-inline.c?).
Honza, could you please take a look at the ipa-inline.c fix? I will
split the patches and submit after Honza's review. I will also make
the changes mentioned.
Thanks
Sri
Jakub
Re: [PATCH] tree-ssa-structalias.c: make call_stmt_vars static
On 06/04/2013 03:29 PM, David Malcolm wrote: call_stmt_vars is only used inside of tree-ssa-structalias.c, so it can be made static. Successfully bootstrapped on x86_64-unknown-linux-gnu (using gcc-4.7.2-2.fc17.x86_64). OK for trunk? 2013-06-04 David Malcolm dmalc...@redhat.com * tree-ssa-structalias.c (call_stmt_vars): Make static. OK. Please install. Thanks, Jeff
Re: [patch] Fix parsing bug in validate_patches.py
On 2013-05-31 14:47 , Brooks Moses wrote: Index: contrib/testsuite-management/validate_failures.py === --- contrib/testsuite-management/validate_failures.py(revision 199390) +++ contrib/testsuite-management/validate_failures.py(working copy) @@ -120,7 +120,7 @@ def __init__(self, summary_line, ordinal=-1): try: self.attrs = '' - if '|' in summary_line: + if '|' in summary_line and not _VALID_TEST_RESULTS_REX.match(summary_line): OK with this predicate factored into a predicate function (maybe SummaryLineHasAttributes?) Thanks. Diego.
Fix two ICEs seen in Mozilla LTO build
Hi,
my changes to visibility flag broke on Mozilla in two interesting way. First
is ICE in get_alias_symbol. Until now I was not aware that C++ FE can create
same body aliases for external symbols. Most of the symtab code deals with it
as with weakrefs that works by accident rather than design. I have patch in
queue to clean this up, but since I decided to rewrite it once again, I am
fixing
at least this ICE.
The other is latent problem in can_refer_from_this_unit_p that expect symtab
nodes
to exist for everything at ltrans stage while they are in fact removed by
symtab_remove_unreachable_nodes
Bootstrapped/regtested x86_64-linux.
Honza
2013-06-04 Jan Hubicka j...@suse.cz
* lto-cgraph.c (get_alias_symbol): Remove weakref sanity check.
(input_node, input_varpool_node): Handle correctly external same
body aliases.
* ipa.c (symtab_remove_unreachable_nodes): Do not remove external
nodes at ltrans stage.
Index: lto-cgraph.c
===
*** lto-cgraph.c(revision 199608)
--- lto-cgraph.c(working copy)
*** static tree
*** 918,924
get_alias_symbol (tree decl)
{
tree alias = lookup_attribute (alias, DECL_ATTRIBUTES (decl));
- gcc_assert (lookup_attribute (weakref, DECL_ATTRIBUTES (decl)));
return get_identifier (TREE_STRING_POINTER
(TREE_VALUE (TREE_VALUE (alias;
}
--- 921,926
*** input_node (struct lto_file_decl_data *f
*** 1008,1014
node-thunk.virtual_value = virtual_value;
node-thunk.virtual_offset_p = (type 4);
}
! if (node-symbol.alias !node-symbol.analyzed)
node-symbol.alias_target = get_alias_symbol (node-symbol.decl);
return node;
}
--- 1010,1017
node-thunk.virtual_value = virtual_value;
node-thunk.virtual_offset_p = (type 4);
}
! if (node-symbol.alias !node-symbol.analyzed
!lookup_attribute (weakref, DECL_ATTRIBUTES (node-symbol.decl)))
node-symbol.alias_target = get_alias_symbol (node-symbol.decl);
return node;
}
*** input_varpool_node (struct lto_file_decl
*** 1050,1056
DECL_EXTERNAL (node-symbol.decl) = 1;
TREE_STATIC (node-symbol.decl) = 0;
}
! if (node-symbol.alias !node-symbol.analyzed)
node-symbol.alias_target = get_alias_symbol (node-symbol.decl);
ref = streamer_read_hwi (ib);
/* Store a reference for now, and fix up later to be a pointer. */
--- 1054,1061
DECL_EXTERNAL (node-symbol.decl) = 1;
TREE_STATIC (node-symbol.decl) = 0;
}
! if (node-symbol.alias !node-symbol.analyzed
!lookup_attribute (weakref, DECL_ATTRIBUTES (node-symbol.decl)))
node-symbol.alias_target = get_alias_symbol (node-symbol.decl);
ref = streamer_read_hwi (ib);
/* Store a reference for now, and fix up later to be a pointer. */
Index: ipa.c
===
*** ipa.c (revision 199608)
--- ipa.c (working copy)
*** symtab_remove_unreachable_nodes (bool be
*** 387,393
for (vnode = varpool_first_variable (); vnode; vnode = vnext)
{
vnext = varpool_next_variable (vnode);
! if (!vnode-symbol.aux)
{
if (file)
fprintf (file, %s, varpool_node_name (vnode));
--- 387,397
for (vnode = varpool_first_variable (); vnode; vnode = vnext)
{
vnext = varpool_next_variable (vnode);
! if (!vnode-symbol.aux
! /* For can_refer_decl_in_current_unit_p we want to track for
!all external variables if they are defined in other partition
!or not. */
! (!flag_ltrans || !DECL_EXTERNAL (vnode-symbol.decl)))
{
if (file)
fprintf (file, %s, varpool_node_name (vnode));
Re: [GOOGLE] More strict checking for call args
attached is a testcase that would cause problem when source has changed: $ g++ test.cc -O2 -fprofile-generate -DOLD $ ./a.out $ g++ test.cc -O2 -fprofile-use test.cc:34:1: internal compiler error: in operator[], at vec.h:815 } ^ 0x512740 vectree_node*, va_heap, vl_embed::operator[](unsigned int) ../../gcc/vec.h:815 0x512740 vectree_node*, va_heap, vl_ptr::operator[](unsigned int) ../../gcc/vec.h:1244 0xf24464 vectree_node*, va_heap, vl_embed::operator[](unsigned int) ../../gcc/vec.h:815 0xf24464 vectree_node*, va_heap, vl_ptr::operator[](unsigned int) ../../gcc/vec.h:1244 0xf24464 ipa_get_indirect_edge_target_1 ../../gcc/ipa-cp.c:1535 0x971b9a estimate_edge_devirt_benefit ../../gcc/ipa-inline-analysis.c:2757 0x973f59 estimate_edge_size_and_time ../../gcc/ipa-inline-analysis.c:2789 0x973f59 estimate_calls_size_and_time ../../gcc/ipa-inline-analysis.c:2842 0x97429f estimate_node_size_and_time ../../gcc/ipa-inline-analysis.c:2929 0x976077 do_estimate_edge_size(cgraph_edge*) ../../gcc/ipa-inline-analysis.c:3472 0x97614f estimate_edge_size ../../gcc/ipa-inline.h:274 0x97614f estimate_edge_growth ../../gcc/ipa-inline.h:286 0x97614f do_estimate_growth_1 ../../gcc/ipa-inline-analysis.c:3582 0x7e41df cgraph_for_node_and_aliases ../../gcc/cgraph.c:1777 0x976675 do_estimate_growth(cgraph_node*) ../../gcc/ipa-inline-analysis.c:3596 0xf314ea estimate_growth ../../gcc/ipa-inline.h:261 0xf314ea inline_small_functions ../../gcc/ipa-inline.c:1432 0xf314ea ipa_inline ../../gcc/ipa-inline.c:1797 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions. test.cc Description: Binary data
[C++ Patch] PR 51908
Hi,
this ICE on valid happens in the cp_parser_abort_tentative_parse called
at the end of cp_parser_decltype_expr. I started seriously looking into
it when I noticed that a variant of the testcase not using variadic
templates is fine, thus I concentrated on
cp_parser_parameter_declaration and noticed an inconsistency in the
following comment and the code implementing it:
/* After seeing a decl-specifier-seq, if the next token is not a
- (, there is no possibility that the code is a valid
+ ( nor '...', there is no possibility that the code is a valid
expression. Therefore, if parsing tentatively, we commit at
this point. */
clearly in the case at issue of decl-specifier-seq followed by ellipsis
we may be parsing a perfectly valid declaration.
Tested x86_64-linux, as usual.
Thanks,
Paolo.
/cp
2013-06-05 Paolo Carlini paolo.carl...@oracle.com
PR c++/51908
* parser.c (cp_parser_parameter_declaration): Do not commit to
tentative parse after a decl-specifier-seq followed by ellipsis.
/testsuite
2013-06-05 Paolo Carlini paolo.carl...@oracle.com
PR c++/51908
* g++.dg/cpp0x/variadic144.C: New.
Index: cp/parser.c
===
--- cp/parser.c (revision 199675)
+++ cp/parser.c (working copy)
@@ -17887,7 +17887,7 @@ cp_parser_parameter_declaration (cp_parser *parser
parser-default_arg_ok_p = false;
/* After seeing a decl-specifier-seq, if the next token is not a
-(, there is no possibility that the code is a valid
+( nor '...', there is no possibility that the code is a valid
expression. Therefore, if parsing tentatively, we commit at
this point. */
if (!parser-in_template_argument_list_p
@@ -17901,7 +17901,8 @@ cp_parser_parameter_declaration (cp_parser *parser
!parser-in_type_id_in_expr_p
cp_parser_uncommitted_to_tentative_parse_p (parser)
cp_lexer_next_token_is_not (parser-lexer, CPP_OPEN_BRACE)
- cp_lexer_next_token_is_not (parser-lexer, CPP_OPEN_PAREN))
+ cp_lexer_next_token_is_not (parser-lexer, CPP_OPEN_PAREN)
+ cp_lexer_next_token_is_not (parser-lexer, CPP_ELLIPSIS))
cp_parser_commit_to_tentative_parse (parser);
/* Parse the declarator. */
declarator_token_start = token;
Index: testsuite/g++.dg/cpp0x/variadic144.C
===
--- testsuite/g++.dg/cpp0x/variadic144.C(revision 0)
+++ testsuite/g++.dg/cpp0x/variadic144.C(working copy)
@@ -0,0 +1,8 @@
+// PR c++/51908
+// { dg-do compile { target c++11 } }
+
+struct foo
+{
+ template typename Ret, typename... Args
+ operator decltype(static_castRet (*)(Args...)(nullptr)) () const;
+};
Re: [PATCH] tree-ssa-structalias.c: make call_stmt_vars static
On Tue, 2013-06-04 at 15:43 -0600, Jeff Law wrote: On 06/04/2013 03:29 PM, David Malcolm wrote: call_stmt_vars is only used inside of tree-ssa-structalias.c, so it can be made static. Successfully bootstrapped on x86_64-unknown-linux-gnu (using gcc-4.7.2-2.fc17.x86_64). OK for trunk? 2013-06-04 David Malcolm dmalc...@redhat.com * tree-ssa-structalias.c (call_stmt_vars): Make static. OK. Please install. Thanks; committed to SVN trunk as r199679.
Re: [PATCH] Improve folding of bitwise ops on booleans
However, in looking at it, if we rewrite the code to have come from
comparisons:
snip
_Bool bfoo_cmp (long w, long x, long y, long z)
{
_Bool a = (w x);
_Bool b = (y z);
_Bool r = ~a b;
return r;
}
We get:
snip
.L.bfoo_cmp:
cmpd 6,3,4
cmpd 7,5,6
mfcr 3,2
rlwinm 3,3,25,1
mfcr 6,1
rlwinm 6,6,29,1
andc 3,6,3
blr
It is a bit better on 32-bit:
bfoo_cmp:
cmpw 7,3,4
cmpw 6,5,6
mfcr 3
rlwinm 6,3,25,1
rlwinm 3,3,29,1
andc 3,6,3
blr
And it would have been nice to use the logcal comparison operations
in the CR
register unit (i.e. doing a crandc in the CR unit rather than
moving the value
from a CR to a GPR -- cmpd/mfcr/rlwinm instructions).
We cannot avoid an mfcr then, either. It would be one machine
instruction shorter though (but can be more expensive to execute,
on some CPUs).
That you get two MFCRs on 64-bit is a target bug.
Segher
Re: [PATCH] Improve folding of bitwise ops on booleans
On Tue, Jun 4, 2013 at 6:42 PM, Segher Boessenkool
seg...@kernel.crashing.org wrote:
However, in looking at it, if we rewrite the code to have come from
comparisons:
snip
_Bool bfoo_cmp (long w, long x, long y, long z)
{
_Bool a = (w x);
_Bool b = (y z);
_Bool r = ~a b;
return r;
}
We get:
snip
.L.bfoo_cmp:
cmpd 6,3,4
cmpd 7,5,6
mfcr 3,2
rlwinm 3,3,25,1
mfcr 6,1
rlwinm 6,6,29,1
andc 3,6,3
blr
It is a bit better on 32-bit:
bfoo_cmp:
cmpw 7,3,4
cmpw 6,5,6
mfcr 3
rlwinm 6,3,25,1
rlwinm 3,3,29,1
andc 3,6,3
blr
And it would have been nice to use the logcal comparison operations in the
CR
register unit (i.e. doing a crandc in the CR unit rather than moving the
value
from a CR to a GPR -- cmpd/mfcr/rlwinm instructions).
We cannot avoid an mfcr then, either. It would be one machine
instruction shorter though (but can be more expensive to execute,
on some CPUs).
That you get two MFCRs on 64-bit is a target bug.
Not true there. If you look at the 64bit output you will see you are
using the one cr mfcr version in 64bit while you are grabbing the full
cr in the 32bit. It depends on the processor but the one cr might be
better.
Thanks,
Andrew
Segher
[PATCH] tsan.c: mark tsan_atomic_table as constant
The table of struct tsan_map_atomic within tsan.c is never modified, so
it can be marked as const.
Successfully bootstrapped on x86_64-unknown-linux-gnu (using
gcc-4.7.2-2.fc17.x86_64).
OK for trunk?
2013-06-05 David Malcolm dmalc...@redhat.com
* tsan.c (tsan_atomic_table): Make const.
Index: gcc/tsan.c
===
--- gcc/tsan.c (revision 199679)
+++ gcc/tsan.c (working copy)
@@ -198,7 +198,7 @@
/* Table how to map sync/atomic builtins to their corresponding
tsan equivalents. */
-static struct tsan_map_atomic
+static const struct tsan_map_atomic
{
enum built_in_function fcode, tsan_fcode;
enum tsan_atomic_action action;
[PATCH] Remove unused pass_update_address_taken
If I'm reading things right, pass_update_address_taken is never actually
used.
Deleting it, I was able to still successfully bootstrap on
x86_64-unknown-linux-gnu (using gcc-4.7.2-2.fc17.x86_64).
The use of the pass appears to have been removed in:
http://gcc.gnu.org/r164525
Should I remove it from trunk?
2013-06-05 David Malcolm dmalc...@redhat.com
* tree-pass.h (pass_update_address_taken): Remove.
* tree-ssa.c (pass_update_address_taken): Remove.
Index: gcc/tree-pass.h
===
--- gcc/tree-pass.h (revision 199679)
+++ gcc/tree-pass.h (working copy)
@@ -487,7 +487,6 @@
extern struct gimple_opt_pass pass_release_ssa_names;
extern struct gimple_opt_pass pass_early_inline;
extern struct gimple_opt_pass pass_inline_parameters;
-extern struct gimple_opt_pass pass_update_address_taken;
extern struct gimple_opt_pass pass_convert_switch;
/* The root of the compilation pass tree, once constructed. */
Index: gcc/tree-ssa.c
===
--- gcc/tree-ssa.c (revision 199679)
+++ gcc/tree-ssa.c (working copy)
@@ -2129,23 +2129,3 @@
BITMAP_FREE (suitable_for_renaming);
timevar_pop (TV_ADDRESS_TAKEN);
}
-
-struct gimple_opt_pass pass_update_address_taken =
-{
- {
- GIMPLE_PASS,
- addressables, /* name */
- OPTGROUP_NONE,/* optinfo_flags */
- NULL, /* gate */
- NULL, /* execute */
- NULL, /* sub */
- NULL, /* next */
- 0, /* static_pass_number */
- TV_ADDRESS_TAKEN, /* tv_id */
- PROP_ssa,/* properties_required */
- 0, /* properties_provided */
- 0, /* properties_destroyed */
- 0, /* todo_flags_start */
- TODO_update_address_taken /* todo_flags_finish */
- }
-};
[arm/embedded-4_7-branch] Merge with gcc-4_7-branch 199638
Committed as 199680
Re: [PATCH] Improve folding of bitwise ops on booleans
We cannot avoid an mfcr then, either. It would be one machine instruction shorter though (but can be more expensive to execute, on some CPUs). That you get two MFCRs on 64-bit is a target bug. Not true there. If you look at the 64bit output you will see you are using the one cr mfcr version in 64bit while you are grabbing the full cr in the 32bit. It depends on the processor but the one cr might be better. Yes, and it's still a bug. Or three: 1) GCC uses the all-fields instruction instead of the one-field form unless you use -mmfcrf (or -mcpu=power4, etc.), although the one-field mfcr works fine on all CPUs and is never slower (I'm not talking about mfocrf; just the plain mfcr instruction); 2) There is a define_peephole to combine two mfcr's into one (search rs6000.md for 3 cycle delay); for the example code, one of the results ends up as SI and the other as DI, and the peephole will not trigger on that; 3) That peephole should not be enabled with -mmfcrf, and of course it should not be a peephole at all! Without bug 2), you'd see the same behaviour on 64-bit as on 32-bit. Segher
Re: [PATCH] Improve folding of bitwise ops on booleans
1) GCC uses the all-fields instruction instead of the one-field form unless you use -mmfcrf (or -mcpu=power4, etc.), although the one-field mfcr works fine on all CPUs and is never slower (I'm not talking about mfocrf; just the plain mfcr instruction); Ugh, need more coffee, forget about this one. Sorry. Segher
Re: [PATCH] pr57457
On 06/04/13 12:58, Iyer, Balaji V wrote: Actually, you can eliminate the entire if-statement (i.e. remove if-statement and make the body unconditional). This is because, if flag_enable_cilkplus is true and is_cilkplus_reduce_builtin (fundecl) is true, then it would have returned vec_safe_length(values) and will not even get to this point in the first place. So, this is technically equivalent to if (1). So, can I remove that and check it in also? It passes all my regression tests. I originally thought it could be eliminated as well, but after further reflection I couldn't convince myself it'd do the right thing for the case when flag_enable_cilkplus is true but is_cilkplus_reduce_builtin was false. Note that triggering that code my be nontrivial, AFAICT we're suppressing a diagnostic. So you're going to need to write invalid code to get into that condition at the bottom of the loop at all. jeff
RE: [PATCH] pr57457
-Original Message- From: Jeff Law [mailto:l...@redhat.com] Sent: Tuesday, June 04, 2013 11:49 PM To: Iyer, Balaji V Cc: gcc-patches@gcc.gnu.org; Steve Ellcey Subject: Re: [PATCH] pr57457 On 06/04/13 12:58, Iyer, Balaji V wrote: Actually, you can eliminate the entire if-statement (i.e. remove if-statement and make the body unconditional). This is because, if flag_enable_cilkplus is true and is_cilkplus_reduce_builtin (fundecl) is true, then it would have returned vec_safe_length(values) and will not even get to this point in the first place. So, this is technically equivalent to if (1). So, can I remove that and check it in also? It passes all my regression tests. I originally thought it could be eliminated as well, but after further reflection I couldn't convince myself it'd do the right thing for the case when flag_enable_cilkplus is true but is_cilkplus_reduce_builtin was false. Note that triggering that code my be nontrivial, AFAICT we're suppressing a diagnostic. So you're going to need to write invalid code to get into that condition at the bottom of the loop at all. OK, I will create one tomorrow morning. Thanks, Balaji V. Iyer. jeff
Re: [google gcc-4_7,gcc-4_8,integration] Add bounds checks to vectorbool
Paul Pluzhnikov ppluzhni...@google.com writes: Keying off NDEBUG rather than __OPTIMIZE__ seems like a more consistent approach -- if you want assert()s, then you probably also want these checks. That's a bad idea. NDEBUG (Be really slow unless the user has positively defined this macro, whose use is rare enough that many people will not even be aware of it) should be used less, not more. The __OPTIMIZE__ is far superior, because it happens automatically when the user specifies any optimization option. -miles -- Guilt, n. The condition of one who is known to have committed an indiscretion, as distinguished from the state of him who has covered his tracks.
