Re: [PATCH, ARM] Fix for pr65924
Hi Yvan, On 29/04/15 09:57, Yvan Roux wrote: Hi, here is the patch for PR65924, only tested on the original testcase so far. Can you please double check that the problem doesn't appear in the other patterns you touched with your cleanup patch? i.e. that you don't do match_operand on an out-of-bounds operand number? Thanks, Kyrill Thanks Yvan gcc/ 2015-04-29 Yvan Roux yvan.r...@linaro.org PR target/65924 * config/arm/thumb2.md (*thumb2_addsi3_compare0_scratch): Fix operand number in type attribute expression. gcc/testsuite/ 2015-04-29 Yvan Roux yvan.r...@linaro.org PR target/65924 gcc.target/arm/pr65924.c: New test.
[rs6000] Fix compare debug failure on AIX
You can easily get -fcompare-debug failures on AIX with small functions, in
fact you get the failure for the empty function:
void foo (void) {}
eric@polaris:~/build/gcc/powerpc-ibm-aix7.1 gcc/xgcc -Bgcc -S t.c -O -
fcompare-debug
xgcc: error: t.c: -fcompare-debug failure (length)
Fixed thusly, tested on powerpc-ibm-aix7.1, OK for the mainline?
2015-04-29 Eric Botcazou ebotca...@adacore.com
* config/rs6000/rs6000.c (rs6000_stack_info): For XCOFF, replace test
on debug info with test on optimization to decide stack pushing.
2015-04-29 Eric Botcazou ebotca...@adacore.com
* gcc.dg/empty3.c: New test.
--
Eric BotcazouIndex: config/rs6000/rs6000.c
===
--- config/rs6000/rs6000.c (revision 222439)
+++ config/rs6000/rs6000.c (working copy)
@@ -21932,8 +21932,8 @@ rs6000_stack_info (void)
/* Determine if we need to allocate any stack frame:
For AIX we need to push the stack if a frame pointer is needed
- (because the stack might be dynamically adjusted), if we are
- debugging, if we make calls, or if the sum of fp_save, gp_save,
+ (because the stack might be dynamically adjusted), if we are not
+ optimizing, if we make calls, or if the sum of fp_save, gp_save,
and local variables are more than the space needed to save all
non-volatile registers: 32-bit: 18*8 + 19*4 = 220 or 64-bit: 18*8
+ 18*8 = 288 (GPR13 reserved).
@@ -21950,7 +21950,7 @@ rs6000_stack_info (void)
else if (frame_pointer_needed)
info_ptr-push_p = 1;
- else if (TARGET_XCOFF write_symbols != NO_DEBUG)
+ else if (TARGET_XCOFF !optimize)
info_ptr-push_p = 1;
else/* { dg-options -O -fcompare-debug } */
void foo (void) {}
Re: [rs6000] Fix compare debug failure on AIX
On Apr 29, 2015, at 3:22 AM, Eric Botcazou ebotca...@adacore.com wrote:
You can easily get -fcompare-debug failures on AIX with small functions, in
fact you get the failure for the empty function:
void foo (void) {}
eric@polaris:~/build/gcc/powerpc-ibm-aix7.1 gcc/xgcc -Bgcc -S t.c -O -
fcompare-debug
xgcc: error: t.c: -fcompare-debug failure (length)
Fixed thusly, tested on powerpc-ibm-aix7.1, OK for the mainline?
2015-04-29 Eric Botcazou ebotca...@adacore.com
* config/rs6000/rs6000.c (rs6000_stack_info): For XCOFF, replace test
on debug info with test on optimization to decide stack pushing.
We might want to check if doing -Og and not just -O0.
Thanks,
Andrew
2015-04-29 Eric Botcazou ebotca...@adacore.com
* gcc.dg/empty3.c: New test.
--
Eric Botcazou
p.diff
empty3.c
Re: [PATCH, ARM] Fix for pr65924
Hi Kyrill, On 29 April 2015 at 12:06, Kyrill Tkachov kyrylo.tkac...@arm.com wrote: Hi Yvan, On 29/04/15 09:57, Yvan Roux wrote: Hi, here is the patch for PR65924, only tested on the original testcase so far. Can you please double check that the problem doesn't appear in the other patterns you touched with your cleanup patch? i.e. that you don't do match_operand on an out-of-bounds operand number? Sure, I just re-check all the patterns and there is no other issue. Cheers, Yvan Thanks, Kyrill Thanks Yvan gcc/ 2015-04-29 Yvan Roux yvan.r...@linaro.org PR target/65924 * config/arm/thumb2.md (*thumb2_addsi3_compare0_scratch): Fix operand number in type attribute expression. gcc/testsuite/ 2015-04-29 Yvan Roux yvan.r...@linaro.org PR target/65924 gcc.target/arm/pr65924.c: New test.
Re: OMP_CLAUSES with clauses in operand 0
On Wed, Apr 29, 2015 at 01:13:29PM +0200, Thomas Schwinge wrote: On Wed, 29 Apr 2015 11:32:31 +0200, Jakub Jelinek ja...@redhat.com wrote: Yeah, it is a non-starter, it has unnecessary runtime overhead everywhere where it is used. Huh. OMP_CLAUSES is currently used in a dozen places in cp/cp-gimplify.c, cp/pt.c, and gimplify.c. I've been expecting my changed code to be well-optimizable, for the compiler already knows TREE_CODE(NODE) in a lot of these places. Doing a quick before (1)/after (2) comparison test with -g -O2 on x86_64 GNU/Linux using GCC 4.8.3, the object file sizes are as follows: textdata bss dec hex filename 37027 0 16 3704390b3 1/build-gcc/gcc/cp/cp-gimplify.o 36307 0 16 363238de3 2/build-gcc/gcc/cp/cp-gimplify.o textdata bss dec hex filename 458742 0 136 458878 7007e 1/build-gcc/gcc/cp/pt.o 458630 0 136 458766 7000e 2/build-gcc/gcc/cp/pt.o textdata bss dec hex filename 166056 0 48 166104 288d8 1/build-gcc/gcc/gimplify.o 166200 0 48 166248 28968 2/build-gcc/gcc/gimplify.o ..., so actually smaller for the first two files. Admittedly, there is a 144 bytes (0.0867 %) size increase in gimplify.o, and I have not measured the actual runtime overhead (which I'm totally expecting to be in the noise, but...), so I'm assuming that my proposal to keep the interface simple does not pay for the presumed runtime overhead, so I guess I'm posting this patch just for the archives... I really don't understand how you could get smaller code out of that, that doesn't make any sense. And I don't see where it would make sense to share the same code for handling the standalone directives and directives with associated blocks, in all the places I've looked at you want a different code. And in many cases you don't have just a single TREE_CODE, but multiple, likely all of them from the same category (either all of them smaller/equal or all larger than OMP_SINGLE), but VRP doesn't have to be able to fix up the weirdnesses. So yes, I really prefer OMP_STANDALONE_CLAUSES over OMP_CLAUSES for everything. And, tree checking which is on by default should catch this properly, it was just a matter of tests not being written when they should have been. Jakub
Re: OMP_CLAUSES with clauses in operand 0
Hi! On Wed, 29 Apr 2015 11:32:31 +0200, Jakub Jelinek ja...@redhat.com wrote: Yeah, it is a non-starter, it has unnecessary runtime overhead everywhere where it is used. Huh. OMP_CLAUSES is currently used in a dozen places in cp/cp-gimplify.c, cp/pt.c, and gimplify.c. I've been expecting my changed code to be well-optimizable, for the compiler already knows TREE_CODE(NODE) in a lot of these places. Doing a quick before (1)/after (2) comparison test with -g -O2 on x86_64 GNU/Linux using GCC 4.8.3, the object file sizes are as follows: textdata bss dec hex filename 37027 0 16 3704390b3 1/build-gcc/gcc/cp/cp-gimplify.o 36307 0 16 363238de3 2/build-gcc/gcc/cp/cp-gimplify.o textdata bss dec hex filename 458742 0 136 458878 7007e 1/build-gcc/gcc/cp/pt.o 458630 0 136 458766 7000e 2/build-gcc/gcc/cp/pt.o textdata bss dec hex filename 166056 0 48 166104 288d8 1/build-gcc/gcc/gimplify.o 166200 0 48 166248 28968 2/build-gcc/gcc/gimplify.o ..., so actually smaller for the first two files. Admittedly, there is a 144 bytes (0.0867 %) size increase in gimplify.o, and I have not measured the actual runtime overhead (which I'm totally expecting to be in the noise, but...), so I'm assuming that my proposal to keep the interface simple does not pay for the presumed runtime overhead, so I guess I'm posting this patch just for the archives... --- gcc/tree.h +++ gcc/tree.h @@ -1200,7 +1200,9 @@ extern void protected_set_expr_location (tree, location_t); #define OMP_BODY(NODE) \ TREE_OPERAND (TREE_RANGE_CHECK (NODE, OACC_PARALLEL, OMP_CRITICAL), 0) #define OMP_CLAUSES(NODE) \ - TREE_OPERAND (TREE_RANGE_CHECK (NODE, OACC_PARALLEL, OMP_SINGLE), 1) + ((TREE_CODE (NODE) = OMP_SINGLE) \ + ? TREE_OPERAND (TREE_RANGE_CHECK (NODE, OACC_PARALLEL, OMP_SINGLE), 1) \ + : TREE_OPERAND (TREE_RANGE_CHECK (NODE, OACC_CACHE, OMP_TARGET_UPDATE), 0)) #define OACC_PARALLEL_BODY(NODE) \ TREE_OPERAND (OACC_PARALLEL_CHECK (NODE), 0) If that's not been obvious, I favor code readability (one generic OMP_CLAUSES interface instead of having both OMP_CLAUSES and OMP_CLAUSES_STANDALONE) over a tiny code size regression, but you seem to think differently, set a different policy for code changes, which I'll have to yield to. Grüße, Thomas pgpbO21Daph6t.pgp Description: PGP signature
Re: Use wi:: in canon_condition
Jeff Law l...@redhat.com writes: On 04/28/2015 07:49 AM, Richard Sandiford wrote: Fix a simple case where we can generalise the CONST_INT handling to all integer constants (CONST_DOUBLE or CONST_WIDE_INT). Tested on x86_64-linux-gnu. OK to install? Thanks, Richard gcc/ * loop-iv.c (canon_condition): Generalize to all types of integer constant. OK. Thanks, applied. If you have some test/code where this generalization helps, then it'd be greatly appreciated if you could add it as a test to the test suite. This was just by inspection, so unfortunately I don't have any testcases. Just trying to gradually reduce the specialness of host integers. Richard
[gomp4.1] Initial support for some OpenMP 4.1 construct parsing
Hi!
Here is what I've committed to gomp-4_1-branch, a new branch for OpenMP 4.1
support. The intent is to develop OpenMP 4.1 support on the branch and
merge to trunk either when OpenMP 4.1 standard is released, or when
sufficiently close to the release, ideally before end of stage1.
I'll probably work on taskloop construct next.
2015-04-29 Jakub Jelinek ja...@redhat.com
gcc/
* gimple.h (enum gf_mask): Increment GF_OMP_TARGET_KIND_MASK
to 15 from 7. Add GF_OMP_TARGET_KIND_ENTER_DATA and
GF_OMP_TARGET_KIND_EXIT_DATA, renumber GF_OMP_TARGET_KIND_OACC*.
* tree.h (OMP_ORDERED_CLAUSES, OMP_TARGET_ENTER_DATA_CLAUSES,
OMP_TARGET_EXIT_DATA_CLAUSES, OMP_CLAUSE_NUM_TASKS_EXPR,
OMP_CLAUSE_GRAINSIZE_EXPR, OMP_CLAUSE_PRIORITY_EXPR,
OMP_CLAUSE_ORDERED_EXPR): Define.
* tree.def (OMP_TASKLOOP, OMP_TARGET_ENTER_DATA,
OMP_TARGET_EXIT_DATA): New tree codes.
(OMP_ORDERED): Add second operand - OMP_ORDERED_CLAUSES. Move
before OMP_SINGLE, so that OMP_CLAUSES can be used on it too.
* gimplify.c (gimplify_scan_omp_clauses): Handle
OMP_CLAUSE_{PRIORITY,GRAINSIZE,NUM_TASKS,NOGROUP,THREADS,SIMD,SIMDLEN}
clauses.
(gimplify_adjust_omp_clauses): Likewise.
(gimplify_omp_target_update): Handle OMP_TARGET_ENTER_DATA
and OMP_TARGET_EXIT_DATA.
(gimplify_expr): Likewise.
* tree.c (omp_clause_num_ops): Change OMP_CLAUSE_ORDERED operand
count to 1 from 0. Add entries for
OMP_CLAUSE_{PRIORITY,GRAINSIZE,NUM_TASKS,NOGROUP,THREADS,SIMD}.
(omp_clause_code_name): Add names for
OMP_CLAUSE_{PRIORITY,GRAINSIZE,NUM_TASKS,NOGROUP,THREADS,SIMD}
clauses.
(walk_tree_1): Handle
OMP_CLAUSE_{PRIORITY,GRAINSIZE,NUM_TASKS,NOGROUP,THREADS,SIMD}
clauses. Handle OMP_CLAUSE_ORDERED as other 1 operand clauses.
* tree-nested.c (convert_nonlocal_omp_clauses): Handle
OMP_CLAUSE_{PRIORITY,GRAINSIZE,NUM_TASKS,NOGROUP,THREADS,SIMD,SIMDLEN}
clauses.
(convert_local_omp_clauses): Likewise.
* gimple-pretty-print.c (dump_gimple_omp_target): Handle
GF_OMP_TARGET_KIND_ENTER_DATA and GF_OMP_TARGET_KIND_EXIT_DATA.
* tree-core.h (enum omp_clause_code): Add
OMP_CLAUSE_{PRIORITY,GRAINSIZE,NUM_TASKS,NOGROUP,THREADS,SIMD}.
(enum omp_clause_depend_kind): Add OMP_CLAUSE_DEPEND_{SOURCE,SINK}.
* omp-low.c (scan_sharing_clauses): Handle
OMP_CLAUSE_{PRIORITY,GRAINSIZE,NUM_TASKS,NOGROUP,THREADS,SIMD,SIMDLEN}
clauses.
(check_omp_nesting_restrictions): Handle
GF_OMP_TARGET_KIND_ENTER_DATA and GF_OMP_TARGET_KIND_EXIT_DATA.
Formatting fixes.
(expand_omp_target): Handle GF_OMP_TARGET_KIND_ENTER_DATA and
GF_OMP_TARGET_KIND_EXIT_DATA.
(build_omp_regions_1, make_gimple_omp_edges): Likewise.
(lower_omp_target): Likewise. Don't assert is_gimple_omp_oacc
for certain OpenMP 4.1 map kinds + modifiers.
* tree-pretty-print.c (dump_omp_clause): Handle
OMP_CLAUSE_ORDERED_EXPR on OMP_CLAUSE_ORDERED. Handle
OMP_CLAUSE_DEPEND_SOURCE on OMP_CLAUSE_DEPEND. Adjust printing
OpenMP 4.1 new map kinds and modifiers. Handle
OMP_CLAUSE_{PRIORITY,GRAINSIZE,NUM_TASKS,NOGROUP,THREADS,SIMD}
clauses.
(dump_generic_node): Handle OMP_{TASKLOOP,TARGET_{ENTER,EXIT}_DATA}.
Dump OMP_ORDERED_CLAUSES for OMP_ORDERED.
gcc/c-family/
* c-omp.c (c_finish_omp_ordered): Add CLAUSES argument, adjust
for building 2 operand tree instead of single operand tree.
(c_omp_split_clauses): Add taskloop simd splitting support.
* c-pragma.h (enum pragma_kind): Add PRAGMA_OMP_TASKLOOP.
(enum pragma_omp_clause): Add
PRAGMA_OMP_CLAUSE_{PRIORITY,GRAINSIZE,NUM_TASKS,NOGROUP,THREADS,SIMD}.
* c-common.h (enum c_omp_clause_split): Add C_OMP_CLAUSE_SPLIT_TASKLOOP
as alias to C_OMP_CLAUSE_SPLIT_FOR.
(c_finish_omp_ordered): Adjust prototype for CLAUSES argument addition.
gcc/c/
* c-typeck.c (c_finish_omp_clauses): Allow NULL OMP_CLAUSE_DECL
for OMP_CLAUSE_DEPEND_SOURCE. Diagnose simdlen safelen. Handle
OMP_CLAUSE_{PRIORITY,GRAINSIZE,NUM_TASKS,NOGROUP,THREADS,SIMD}
clauses.
* c-parser.c (c_parser_pragma): Handle PRAGMA_OMP_ORDERED.
(c_parser_omp_clause_name): Handle grainsize, nogroup, num_tasks,
priority, simd and threads clauses.
(c_parser_omp_clause_num_tasks, c_parser_omp_clause_grainsize,
c_parser_omp_clause_priority): New functions.
(c_parser_omp_clause_ordered): Handle parsing of optional argument.
(c_parser_omp_clause_nogroup, c_parser_omp_clause_orderedkind):
New functions.
(c_parser_omp_clause_depend): Handle parsing of depend(source)
and partially handle depend(sink:vec).
(c_parser_omp_clause_map): Parse optional
Re: [PATCH] gimple-walk.c #include TLC
On 29 April 2015 at 11:00, Richard Biener richard.guent...@gmail.com wrote:
On Wed, Apr 29, 2015 at 10:01 AM, Bernhard Reutner-Fischer
rep.dot@gmail.com wrote:
Hi there,
I noticed that gimple-walk.c has a creative list of #includes.
Furthermore, in walk_gimple_asm parse_{in,out}put_constraint was called
even if neither allows_mem, allows_reg nor is_inout were used -- i.e. if
wi is NULL -- and the return value of the constraint parsing was not
taken into account which looks wrong or at least odd. Note that several
other spots in the tree do ignore the parse_{in,out}put_constraint return
values and should be adjusted too AFAIU. Otherwise we might attempt
(and use!) to extract information from otherwise illegal constraints,
it seems?
Bootstrapped and regtested on x86_64-unknown-linux with no regressions.
Ok for trunk?
Ok.
r222569.
Thanks!
Re: [PATCH, ARM] Fix for pr65924
On 29/04/15 11:43, Yvan Roux wrote: Hi Kyrill, On 29 April 2015 at 12:06, Kyrill Tkachov kyrylo.tkac...@arm.com wrote: Hi Yvan, On 29/04/15 09:57, Yvan Roux wrote: Hi, here is the patch for PR65924, only tested on the original testcase so far. Can you please double check that the problem doesn't appear in the other patterns you touched with your cleanup patch? i.e. that you don't do match_operand on an out-of-bounds operand number? Sure, I just re-check all the patterns and there is no other issue. Thanks, Ok for trunk then as it fixes a build failure. Kyrill Cheers, Yvan Thanks, Kyrill Thanks Yvan gcc/ 2015-04-29 Yvan Roux yvan.r...@linaro.org PR target/65924 * config/arm/thumb2.md (*thumb2_addsi3_compare0_scratch): Fix operand number in type attribute expression. gcc/testsuite/ 2015-04-29 Yvan Roux yvan.r...@linaro.org PR target/65924 gcc.target/arm/pr65924.c: New test.
Re: [PATCH][AARCH64]Add ACLE 2.0 predefined macros: __ARM_ALIGN_MAX_PWR and __ARM_ALIGN_MAX_STACK_PWR
On 29 April 2015 at 01:24, Andrew Pinski pins...@gmail.com wrote: On Tue, Dec 16, 2014 at 2:19 AM, Renlin Li renlin...@arm.com wrote: Hi all, This is a simple patch to add another two ACLE 2.0 predefined macros into aarch64 backend. They are __ARM_ALIGN_MAX_PWR and __ARM_ALIGN_MAX_STACK_PWR. Currently, those two values are hard-wired to 16. The following clauses from ACLE 2.0 documentation indicate the meaning of those two macros: The macro __ARM_ALIGN_MAX_STACK_PWR indicates (as the exponent of a power of 2) the maximum available stack alignment. The macro __ARM_ALIGN_MAX_PWR indicates (as the exponent of a power of 2) the maximum available alignment of static data. aarch64-none-elf target is tested on on the model. No new regression. Is it Okay for trunk? Have you tested these alignments? That is have we tested 65536 alignment for both stack and static data? I suspect the stack alignment that is support is not 64k but much smaller. And the supported static data alignment is much larger, maybe 20 or more. Looks to me __ARM_ALIGN_MAX_STACK_PWR can be lifted to 2^16 without issue. GCC won't gripe about the static data alignment until 2^29. Aside from the latter being rather conservative I think we should add a test case to the testsuite for each. RenLin can you prep a testcase? /Marcus
Re: C++ PATCH for c++/50800 (ICE with may_alias and templates)
On 2015.04.28 at 10:42 -0400, Jason Merrill wrote:
On 04/23/2015 01:45 PM, H.J. Lu wrote:
On Thu, Apr 23, 2015 at 8:52 AM, Jason Merrill ja...@redhat.com wrote:
We try to strip attributes that aren't reflected in mangling from template
arguments, but were failing to do that in this case. Fixed by making
strip_typedefs strip such attributes as well.
Tested x86_64-pc-linux-gnu, applying to trunk.
This caused:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65865
This turned out to be because of a thinko in apply_identity_attributes;
we weren't actually applying the identity attributes. Fixed thus.
I'm getting hundreds of new warnings when building LLVM, e.g.:
trippels@gcc2-power8 Sema % cat AttributeList.ii
template typename struct A;
template typename _Up struct A_Up * { typedef _Up type; };
template typename T struct B { typedef typename AT::type type; };
template typename struct C;
template typename From struct Cconst From {
typedef typename BFrom::type SimpleType;
};
template class struct D { typedef int ret_type; };
template class From struct F {
typedef typename Dtypename CFrom::SimpleType::ret_type ret_type;
};
template class, class Y typename FY::ret_type cast(Y );
class CompoundStmt;
class alignas(8) Stmt {
Stmt *Children[];
CompoundStmt *getBlock() const { castCompoundStmt(Children[0]); }
};
trippels@gcc2-power8 Sema % g++ -c -std=c++11 AttributeList.ii
AttributeList.ii: In instantiation of ‘struct FStmt* const’:
AttributeList.ii:12:51: required by substitution of ‘templateclass, class Y
typename FY::ret_type cast(Y) [with template-parameter-1-1 = CompoundStmt;
Y = Stmt* const]’
AttributeList.ii:16:66: required from here
AttributeList.ii:10:62: warning: ignoring attributes applied to ‘Stmt’ after
definition [-Wattributes]
typedef typename Dtypename CFrom::SimpleType::ret_type ret_type;
^
AttributeList.ii:10:62: warning: ignoring attributes on template argument
‘CStmt* const::SimpleType {aka Stmt}’
--
Markus
Re: [gomp4.1] Initial support for some OpenMP 4.1 construct parsing
Hi Jakub!
(I have not yet read any version of the OpenMP 4.1 standard.)
On Wed, 29 Apr 2015 13:14:06 +0200, Jakub Jelinek ja...@redhat.com wrote:
--- gcc/tree.def.jj 2015-04-29 10:58:01.663745452 +0200
+++ gcc/tree.def 2015-04-29 11:34:18.293302684 +0200
+/* OpenMP - #pragma omp target enter data [clause1 ... clauseN]
+ Operand 0: OMP_TARGET_ENTER_DATA_CLAUSES: List of clauses. */
+DEFTREECODE (OMP_TARGET_ENTER_DATA, omp_target_enter_data, tcc_statement,
1)
+
+/* OpenMP - #pragma omp target exit data [clause1 ... clauseN]
+ Operand 0: OMP_TARGET_EXIT_DATA_CLAUSES: List of clauses. */
+DEFTREECODE (OMP_TARGET_EXIT_DATA, omp_target_exit_data, tcc_statement, 1)
;-) Heh, OpenMP catching up with OpenACC?
--- gcc/c/c-parser.c.jj 2015-04-29 10:59:20.760504260 +0200
+++ gcc/c/c-parser.c 2015-04-29 11:03:04.641991095 +0200
map ( variable-list )
map-kind:
- alloc | to | from | tofrom */
+ alloc | to | from | tofrom
+
+ OpenMP 4.1:
+ map-kind:
+ alloc | to | from | tofrom | delete
+
+ map ( always [,] map-kind: variable-list ) */
Funnily, OpenACC 2.5 is said to be dropping the always semantics that
OpenMP 4.1 is now adding... That is, OpenACC 2.5's copy will then be
the same as present_or_copy, and so on.
static tree
c_parser_omp_target_data (location_t loc, c_parser *parser)
{
- tree stmt = make_node (OMP_TARGET_DATA);
- TREE_TYPE (stmt) = void_type_node;
-
- OMP_TARGET_DATA_CLAUSES (stmt)
+ tree clauses
= c_parser_omp_all_clauses (parser, OMP_TARGET_DATA_CLAUSE_MASK,
#pragma omp target data);
+ if (find_omp_clause (clauses, OMP_CLAUSE_MAP) == NULL_TREE)
+{
+ error_at (loc,
+ %#pragma omp target data% must contain at least one
+ %map% clause);
+ return NULL_TREE;
+}
+
+ tree stmt = make_node (OMP_TARGET_DATA);
+ TREE_TYPE (stmt) = void_type_node;
+ OMP_TARGET_DATA_CLAUSES (stmt) = clauses;
Even if it doesn't make a lot of sense, my reading of OpenMP 4.0 has been
that a target data construct without any map clauses is still valid.
(But I have not verified that now.)
--- gcc/omp-low.c.jj 2015-04-29 10:58:01.489748182 +0200
+++ gcc/omp-low.c 2015-04-29 11:03:04.646991017 +0200
@@ -8994,6 +9017,11 @@ expand_omp_target (struct omp_region *re
case GF_OMP_TARGET_KIND_UPDATE:
start_ix = BUILT_IN_GOMP_TARGET_UPDATE;
break;
+case GF_OMP_TARGET_KIND_ENTER_DATA:
+case GF_OMP_TARGET_KIND_EXIT_DATA:
+ /* FIXME */
+ start_ix = BUILT_IN_GOMP_TARGET_UPDATE;
+ break;
Actually, I've also wondered (but never verified) whether all of the
OpenACC enter, exit, and update constructs can be implemented via the
same libgomp API.
@@ -11488,6 +11520,9 @@ lower_omp_target (gimple_stmt_iterator *
default:
gcc_unreachable ();
}
+ /* FIXME: Temporary hack. */
+ if (talign_shift == 3)
+ tkind = ~GOMP_MAP_FLAG_FORCE;
gcc_checking_assert (tkind
(HOST_WIDE_INT_C (1U) talign_shift));
talign = ceil_log2 (talign);
Assuming you'll be changing the relevant functions' APIs, and assigning
new ABI versions, don't forget to also drop the unused offload_table
formal parameter (assuming that it remains unused).
--- gcc/tree-pretty-print.c.jj2015-04-29 10:58:01.663745452 +0200
+++ gcc/tree-pretty-print.c 2015-04-29 11:03:04.648990986 +0200
@@ -550,22 +560,22 @@ dump_omp_clause (pretty_printer *pp, tre
pp_string (pp, tofrom);
break;
case GOMP_MAP_FORCE_ALLOC:
- pp_string (pp, force_alloc);
+ pp_string (pp, always,alloc);
break;
case GOMP_MAP_FORCE_TO:
- pp_string (pp, force_to);
+ pp_string (pp, always,to);
break;
case GOMP_MAP_FORCE_FROM:
- pp_string (pp, force_from);
+ pp_string (pp, always,from);
break;
case GOMP_MAP_FORCE_TOFROM:
- pp_string (pp, force_tofrom);
+ pp_string (pp, always,tofrom);
break;
case GOMP_MAP_FORCE_PRESENT:
pp_string (pp, force_present);
break;
case GOMP_MAP_FORCE_DEALLOC:
- pp_string (pp, force_dealloc);
+ pp_string (pp, always,delete);
break;
case GOMP_MAP_FORCE_DEVICEPTR:
pp_string (pp, force_deviceptr);
Makes some sense to me to use the same always,* syntax also for the
other force_* ones, given that these are artificial (non-OpenACC)
descriptions anyway.
Grüße,
Thomas
pgpjMXZF07u4u.pgp
Description: PGP signature
Re: [patch] Perform anonymous constant propagation during inlining
On Wed, Apr 29, 2015 at 11:50 AM, Eric Botcazou ebotca...@adacore.com wrote:
Historically the pragma Inline_Always of GNAT had been implemented in the FE
because the RTL inliner and then the Tree inliner weren't invoked at -O0 or
powerful enough to inline some constructs. But this approach had drawbacks,
especially wrt debug info. These restrictions were gradually lifted and now
the pragma is entirely piggybacked on the Tree inliner.
This went mostly OK, except for a few cases where intrisinc operations that
used to be reasonably handled at -O0 now generate awful code, the typical
example being a modulus or division instrinsic by a power-of-2 generating a
fully-fledged modulus or division instruction instead of a simple shift.
Therefore the attached patch implements anonymous constant propagation in the
inliner to fix the code quality regression.
Tested on x86_64-suse-linux, OK for the mainline?
Hmm, special-casing this in the inliner looks odd to me. ISTR the inliner
already propagates constant parameters to immediate uses, so I guess
you run into the casting case you handle specially.
But then if any constant propagation is ok at -O0 why not perform full-fledged
constant propagation (with !DECL_IGNORED_P vars as a propagation barrier)
as a regular SSA pass? That is, if you'd had a Inline_Always function like
int foo (int i)
{
return (i + 1) / i;
}
you'd not get the desired result as the i + 1 stmt wouldn't be folded
and thus the (i + 1) / i stmt wouldn't either.
That said - why does RTL optimization not save you here anyway?
After all, it is responsible for turning divisions into shifts.
Soo - if you use the existing CCP pass and make surely_varying_stmt_p
return true for defs of !DECL_IGNORED_P stmts at -O0 (strictly needed to make
setting vars in gdb possible) and somehow arrange for ccp to run at -O0...
It might help other obscure cases with inline-asms to behave consistently
with -O0 vs. -On as well.
Richard.
2015-04-29 Eric Botcazou ebotca...@adacore.com
* tree-inline.c (remap_gimple_op_r): Do anonymous constant
propagation.
(copy_bb): Fold conversions of constants immediately.
2015-04-29 Eric Botcazou ebotca...@adacore.com
* gnat.dg/inline12.adb: New test.
--
Eric Botcazou
Re: [PATCH, RFC]: Next stage1, refactoring: propagating rtx subclasses
On 28.04.2015 16:46, Richard Sandiford wrote:
+inline void rtx_jump_insn::set_jump_target (rtx_insn *target) +{
+ JUMP_LABEL(this) = target;
Fixed.
Could these two operate on rtx_code_labels rather than rtx_insns?
Indeed, right now [set_]jump_target are not used with NOTE's, so I could
promote the type to rtx_code_label with no regressions.
Long line -- can break before (CASE_LABEL
Fixed. Others too. Rechecked with contrib/check_GNU_style.sh (no
warnings, except one special case in gcc/recog.h).
On 28.04.2015 20:08, Jeff Law wrote:
Agreed. These corner cases are precisely the kinds of things we
want to be identifying and cleaning up as we go. I haven't looked
at the updated patch yet, but if there isn't a comment about this
case, then there should be.
Done.
Needs a ChangeLog. I know it's a bit tedious... But please include
it. It makes patch review easier, and we need one for the ChangeLog
file anyway.
Attached.
In general, probably more as_a conversions than I'd like. But that
may be unavoidable at this point. On a positive note, I do see some
going away as you strengthen various return and parameter types.
Also some conversions are, perhaps, unavoidable when they come right
after a check, so the type is indeed narrowed.
I probably would have done separate patches for the std::swap
changes. They're not really related to the rtx subclasses work.
OK, sending 2 separate patches. Note that they a not commutative:
std::swap should be applied before the main one, because one of the
swaps in do_compare_rtx_and_jump uses a single temporary variable of
type rtx for swapping labels and for storing generic rtl expressions
(this could be worked around, of course, but I think that would be just
a waste of time).
I'm not sure why you added indention in expand_expr_real_2's switch
statement. It certainly makes the patch harder to review. I'm going
to assume there was a good reason for the new {} pair and added
indention.
Sorry for that. I had to introduce a couple of variables, and I decided
to limit their scope in order to make their use less error-prone.
--
Regards,
Mikhail Maltsev
gcc/ChangeLog:
2015-04-29 Mikhail Maltsev malts...@gmail.com
Promote types of RTL expressions to more derived ones.
* bb-reorder.c (set_edge_can_fallthru_flag): Use rtx_jump_insn where
feasible.
(fix_up_fall_thru_edges): Likewise.
(fix_crossing_conditional_branches): Likewise. Promote jump targets
from to rtx_insn to rtx_code_label where feasible.
* bt-load.c (move_btr_def): Remove as-a cast of the value returned by
gen_move_insn (returned type changed to rtx_insn).
* builtins.c (expand_errno_check): Fix arguments of
do_compare_rtx_and_jump (now expects rtx_code_label).
(expand_builtin_acc_on_device): Likewise.
* cfgcleanup.c (try_simplify_condjump): Add cast when calling
invert_jump (now exprects rtx_jump_insn).
* cfgexpand.c (label_rtx_for_bb): Promote return type to
rtx_code_label.
(construct_init_block): Use rtx_code_label.
* cfgrtl.c (block_label): Promote return type to rtx_code_label.
(try_redirect_by_replacing_jump): Use cast to rtx_jump_insn when
calling redirect_jump.
(patch_jump_insn): Likewise.
(redirect_branch_edge): Likewise.
(force_nonfallthru_and_redirect): Likewise.
(fixup_reorder_chain): Explicitly use rtx_jump_insn instead of rtx_insn
when suitable.
(rtl_lv_add_condition_to_bb): Update call of do_compare_rtx_and_jump.
* cfgrtl.h: Promote return type of block_label to rtx_code_label.
* config/i386/i386.c (ix86_emit_cmove): Explicitly use rtx_code_label
to store the value retured by gen_label_rtx.
* dojump.c (jumpifnot): Promote argument type from rtx to
rtx_code_label.
(jumpifnot_1): Likewise.
(jumpif): Likewise.
(jumpif_1): Likewise.
(do_jump_1): Likewise.
(do_jump): Likewise. Use rtx_code_label when feasible.
(do_jump_by_parts_greater_rtx): Likewise.
(do_jump_by_parts_zero_rtx): Likewise.
(do_jump_by_parts_equality_rtx): Likewise.
(do_compare_rtx_and_jump): Likewise.
* dojump.h: Update function prototypes.
* dse.c (emit_inc_dec_insn_before): Remove case (gen_move_insn now
returns rtx_insn).
* emit-rtl.c (emit_label_before): Promote return type to
rtx_code_label.
(emit_label): Likewise.
* except.c (sjlj_emit_dispatch_table): Use jump_target_rtx.
* explow.c (emit_stack_save): Update for new return type of
gen_move_insn.
(emit_stack_restore): Likewise.
* expmed.c (emit_store_flag_force): Fix calls of
do_compare_rtx_and_jump.
(do_cmp_and_jump): Likewise.
* expr.c (expand_expr_real_2): Likewise. Promote some local variables
from rtx to rtx_code_label.
[Fortran, Patch] (RFC, Coarray) Implement TS18508's EVENTS
Dear all,
attached patch fixes a bug and implements EVENTS. I think the patch is
finished, but I still have to extend the test cases, to re-read the
patch and to write a changelog. As I am not sure how soon I will able
to do so, I follow the paradigm: release soon, release often and post
it here. Comments and reviews are welcome.
The patch fixes two bug in the errmsg handling, found by Alessandro:
I don't pass on the address of the actual argument and in libcaf_single,
I copy only 8 characters (sizeof pointer) instead of all of the the
characters of the error message.
Regarding events: Events is a way to permit barrier/locking-free
programming: One sends the finished data to an other image and then
tells that image that the data is there (event post(msg_var[idx])).
That image can then either wait for the event by querying the status
on the local variable (event wait(msg_var)) or only check the status
and if it is not ready do something else (e.g. another iteration);
that's done via call event_query(msg_var, count).
Technically, event_post works like atomic_add(msg_var[idx], 1) and
event_query like atomic_ref(msg_var, count). event_wait is the same
as event_query plus a spin/sleep loop waiting for the status change,
followed by an atomic_add(msg_var, -until_count). Except that
event_post/event_wait are image control statements. (Otherwise it
could happen that the event is there before the data for which the
event has been posted.)
Regarding the implementation in this patch, the limitations are the
same as for locking: Currently, neither lock_type nor event_type
variables are permitted as (nonallocatable) components
of a derived type - and type extension of them also not yet supported.*
The spec can be found at http://bitly.com/sc22wg5 - 2015 - TS draft
or directly at
http://isotc.iso.org/livelink/livelink?func=llobjId=17064344objAction=Open
Tobias
* Doing so is not really difficult but I need to handle cases like
the following. For allocatable with SOURCE= I also need to handle
it with polymorphic types.
type t1
type(event_type) :: EV
type(lock_type) :: LK
end type1
type t2
type(t1) :: a(5)
end type t2
type t3
type(t2) :: b(8)
end type t3
type(t3), save :: caf(3)[*]
For those, I need to call _gfortran_caf_register for
caf(:)%b(:)%a(:)%ev and caf(:)%b(:)%a(:)%lk
Looping though all array references.
Similar for
type(t3), allocatable :: caf2(:)[:]
allocate(caf2(n)[*])
for the allocate call.
gcc/fortran/check.c | 54 +++
gcc/fortran/dump-parse-tree.c | 27
gcc/fortran/expr.c| 13 ++
gcc/fortran/gfortran.h| 8 +-
gcc/fortran/gfortran.texi | 141 --
gcc/fortran/interface.c | 31 +++-
gcc/fortran/intrinsic.c | 7 +
gcc/fortran/intrinsic.h | 2 +
gcc/fortran/iresolve.c| 8 ++
gcc/fortran/iso-fortran-env.def | 5 +
gcc/fortran/match.c | 199 ++
gcc/fortran/match.h | 2 +
gcc/fortran/module.c | 8 +-
gcc/fortran/parse.c | 69 -
gcc/fortran/resolve.c | 94 ++--
gcc/fortran/st.c | 2 +
gcc/fortran/trans-decl.c | 28 +++-
gcc/fortran/trans-expr.c | 8 +-
gcc/fortran/trans-intrinsic.c | 150 +++
gcc/fortran/trans-stmt.c | 163 +
gcc/fortran/trans-stmt.h | 1 +
gcc/fortran/trans-types.c | 5 +
gcc/fortran/trans.c | 17 ++-
gcc/fortran/trans.h | 7 +-
gcc/testsuite/gfortran.dg/coarray/event_1.f90 | 51 +++
gcc/testsuite/gfortran.dg/coarray/event_2.f90 | 89
26 files changed, 1151 insertions(+), 38 deletions(-)
diff --git a/gcc/fortran/check.c b/gcc/fortran/check.c
index cdb5ff1..d3570b3 100644
--- a/gcc/fortran/check.c
+++ b/gcc/fortran/check.c
@@ -1151,6 +1151,60 @@ gfc_check_atomic_cas (gfc_expr *atom, gfc_expr *old, gfc_expr *compare,
bool
+gfc_check_event_query (gfc_expr *event, gfc_expr *count, gfc_expr *stat)
+{
+ if (event-ts.type != BT_DERIVED
+ || event-ts.u.derived-from_intmod != INTMOD_ISO_FORTRAN_ENV
+ || event-ts.u.derived-intmod_sym_id != ISOFORTRAN_EVENT_TYPE)
+{
+ gfc_error (EVENT argument at %L to the intrinsic EVENT_QUERY
+ shall be of type EVENT_TYPE, event-where);
+ return false;
+}
+
+ if (!scalar_check (event, 0))
+return false;
+
+ if (!gfc_check_vardef_context (count, false, false, false, NULL))
+{
+ gfc_error (COUNT argument of the EVENT_QUERY intrinsic function at %L
+ shall be definable, count-where);
+ return false;
+}
[PATCH] Some SLP with gaps related fixes
These are bugfixes that prepare handling of SLP loads with gaps
and more SLP permutation kinds.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2015-04-29 Richard Biener rguent...@suse.de
* tree-vect-data-refs.c (vect_analyze_group_access): Properly
compute GROUP_SIZE for basic-block SLP.
* tree-vect-slp.c (vect_get_place_in_interleaving_chain): Properly
take into account gaps.
(vect_get_mask_element): Properly reject references to previous
vectors.
(vect_transform_slp_perm_load): Likewise.
Index: gcc/tree-vect-data-refs.c
===
*** gcc/tree-vect-data-refs.c (revision 222514)
--- gcc/tree-vect-data-refs.c (working copy)
*** vect_analyze_group_access (struct data_r
*** 2245,2251
}
if (groupsize == 0)
! groupsize = count;
GROUP_SIZE (vinfo_for_stmt (stmt)) = groupsize;
if (dump_enabled_p ())
--- 2271,2277
}
if (groupsize == 0)
! groupsize = count + gaps;
GROUP_SIZE (vinfo_for_stmt (stmt)) = groupsize;
if (dump_enabled_p ())
Index: gcc/tree-vect-slp.c
===
*** gcc/tree-vect-slp.c (revision 222514)
--- gcc/tree-vect-slp.c (working copy)
*** vect_get_place_in_interleaving_chain (gi
*** 223,230
{
if (next_stmt == stmt)
return result;
- result++;
next_stmt = GROUP_NEXT_ELEMENT (vinfo_for_stmt (next_stmt));
}
while (next_stmt);
--- 223,231
{
if (next_stmt == stmt)
return result;
next_stmt = GROUP_NEXT_ELEMENT (vinfo_for_stmt (next_stmt));
+ if (next_stmt)
+ result += GROUP_GAP (vinfo_for_stmt (next_stmt));
}
while (next_stmt);
*** vect_get_mask_element (gimple stmt, int
*** 3008,3013
--- 3033,3050
/* Adjust the value in case it's a mask for second and third vectors. */
*current_mask_element -= mask_nunits * (*number_of_mask_fixes - 1);
+ if (*current_mask_element 0)
+ {
+ if (dump_enabled_p ())
+ {
+ dump_printf_loc (MSG_MISSED_OPTIMIZATION, vect_location,
+ permutation requires past vector );
+ dump_gimple_stmt (MSG_MISSED_OPTIMIZATION, TDF_SLIM, stmt, 0);
+ dump_printf (MSG_MISSED_OPTIMIZATION, \n);
+ }
+ return false;
+ }
+
if (*current_mask_element mask_nunits)
*needs_first_vector = true;
*** vect_transform_slp_perm_load (slp_tree n
*** 3178,3184
number_of_mask_fixes, mask_fixed,
needs_first_vector))
return false;
! gcc_assert (current_mask_element 2 * nunits);
mask[index++] = current_mask_element;
if (index == nunits)
--- 3215,3222
number_of_mask_fixes, mask_fixed,
needs_first_vector))
return false;
! gcc_assert (current_mask_element = 0
! current_mask_element 2 * nunits);
mask[index++] = current_mask_element;
if (index == nunits)
Re: Mostly rewrite genrecog
I think it's been the case for a while that parallel builds of GCC tend to serialise around the compilation of insn-recog.c, especially with higher --enable-checking settings. This patch tries to speed that up by replacing most of genrecog with a new algorithm. I can confirm this, especially with --enable-checking=rtl. Also, the code is all goto-based, which makes it rather hard to step through. Do you mean the code in genrecog.c or the generated code in insn-recog.c? The patch deals with these as follows: 1. Detect subpatterns that differ only by mode, code and/or integer (e.g. unspec number) and split them out into a common routine. 2. Match the shape of the instruction first, in terms of codes, integers and vector lengths, and only then check the modes, predicates and dups. When checking the shape, handle SET_SRCs before SET_DESTs. In practice this seems to greatly reduce the amount of backtracking. 3. Have one local variable per rtx position. I tested the patch with and without the change and it helped a lot with rtl-checking builds without seeming to affect release builds much either way. As far as debuggability goes, the new code avoids gotos and just uses natural control flow. See below. The headline stat is that a stage 3 --enable-checking=yes,rtl,df build of insn-recog.c on my box goes from 7m43s to 2m2s (using the same stage 2 compiler). The corresponding --enable-checking=release change is from 49s to 24s (less impressive, as expected). The first figure is quite impressive, great work! PS. I've attached the new genrecog.c since the diff version is unreadable. Small request: you didn't change a single line of the head comment, yet the size of the file is doubled. Could you add a sketch of the algorithm to the head comment, e.g. by copy-and-pasting the above part of your message? The old code contained a couple of DEBUG_FUNCTIONs but the new one doesn't. -- Eric Botcazou
Re: [PATCH] Remove some restrictions on loop shape in tree-if-conv.c
Sorry, I realize I forgot to attach the patch to the original email, this
followed a couple of minutes later in message 553f91b9.7050...@arm.com at
https://gcc.gnu.org/ml/gcc-patches/2015-04/msg01745.html .
Cheers, Alan
Jeff Law wrote:
On 04/28/2015 07:55 AM, Alan Lawrence wrote:
Tree if-conversion currently bails out for loops that (a) contain nested
loops; (b) have more than one exit; (c) where the exit block (source of
the exit edge) does not dominate the loop latch; (d) where the exit
block is the loop header, or there are statements after the exit.
This patch removes restrictions (c) and (d). The intuition is that, for
(c), if (P) {... if (Q) break;} is equivalent to if (P) {...}; if
(PQ) break; and this is mostly handled by existing code for
propagating conditions. For (d), if (P) break; stmts is equivalent to
if (!P) stmts; if (P) break; - this requires inserting the predicated
stmts before the branch rather than after.
Mostly thus this patch is just removing assumptions about when we
do/don't need to store predicates. One 'gotcha' was in some test cases
the latch block passed into if-conversion is non-empty; in such cases,
if-conversion will now restore good form by moving the statement into
the exit block (predicated with !exit-condition).
The condition on dominance in add_to_predicate_list, I haven't quite
managed to convince myself is right; we _do_ want to store a predicate
for the latch block to handle the above case, but I'm not totally sure
of the postdominance condition - I think it may store conditions in
cases where we don't really need to (e.g. for (;;) { ... if (P) { for
(;;) ; } } which might look nested but isn't, and has no route to the
function exit). However, storing conditions when we don't need to, is
OK, unlike failing to store when we do need to ;).
A simple example of the patch at work:
int
foo ()
{
for (int i = 0; i N ; i++)
{
int m = (a[i] i) ? 5 : 4;
b[i] = a[i] * m;
}
}
compiled at -O3, -fdump-tree-ivcanon shows this immediately before
tree-if-conversion:
...function entry, variables, etc...
bb 2:
_10 = a[0];
goto bb 6;
bb 3:
_5 = a[i_9];
_6 = _5 i_9;
if (_6 != 0)
goto bb 5;
else
goto bb 4;
bb 4:
bb 5:
# m_14 = PHI 5(3), 4(4)
bb 6:
# m_2 = PHI m_14(5), 4(2)
# _15 = PHI _5(5), _10(2)
# i_16 = PHI i_9(5), 0(2)
# ivtmp_13 = PHI ivtmp_3(5), 32(2)
_7 = m_2 * _15;
b[i_16] = _7;
i_9 = i_16 + 1;
ivtmp_3 = ivtmp_13 - 1;
if (ivtmp_3 != 0)
goto bb 3;
else
goto bb 7;
which previously was not if-converted. With this patch:
bb 2:
_10 = a[0];
goto bb 4;
bb 3:
bb 4:
# m_2 = PHI m_14(3), 4(2)
# _15 = PHI _5(3), _10(2)
# i_16 = PHI i_9(3), 0(2)
# ivtmp_13 = PHI ivtmp_3(3), 32(2)
_7 = m_2 * _15;
b[i_16] = _7;
i_9 = i_16 + 1;
ivtmp_3 = ivtmp_13 - 1;
_5 = a[i_9];
_6 = _5 i_9;
m_14 = _6 != 0 ? 5 : 4;
if (ivtmp_3 != 0)
goto bb 3;
else
goto bb 5;
bb 5:
return;
(Unfortunately the vectorizer still doesn't handle this loop either, but
that's another issue/patch...)
Bootstrapped + check-gcc on x86_64-unknown-linux-gnu and
aarch64-none-linux-gnu.
Cross-tested check-gcc on aarch64-none-elf.
I'm investigating impact on benchmarks - on AArch64 Spec2k6, this
touches a number of object files, leading to an overall slight decrease
in the number of instructions, but no change that looks significant
(specifically, no more or less vectorization).
Is this OK for trunk?
ENOPATCH
jeff
Re: Fix OpenMP's target update directive in templated code
Hi Jakub!
On Wed, 29 Apr 2015 10:53:32 +0200, Jakub Jelinek ja...@redhat.com wrote:
On Tue, Apr 28, 2015 at 08:45:50PM +0200, Thomas Schwinge wrote:
I guess nobody so far ;-) has been using OpenMP's target update directive
in templated code -- OK to commit the following, and to which branches
(4.9, 5, trunk)?
Seems I've missed testcases for target {,update,data} in templates indeed,
generally for C++ I'm trying to add testcases for templates, both when
relevant types are type dependent and whey aren't.
gcc/cp/
* pt.c (tsubst_expr) OMP_TARGET_UPDATE: Use
OMP_TARGET_UPDATE_CLAUSES instead of OMP_CLAUSES.
gcc/testsuite/
* g++.dg/gomp/tpl-target-update.C: New file.
This is ok for trunk, 5.2 and 4.9.3, thanks for fixing that.
Committed in r222564, r222565, r222566, respectively.
Grüße,
Thomas
pgp95WUjpPpsS.pgp
Description: PGP signature
New template for 'cpplib' made available
Hello, gentle maintainer. This is a message from the Translation Project robot. (If you have any questions, send them to coordina...@translationproject.org.) A new POT file for textual domain 'cpplib' has been made available to the language teams for translation. It is archived as: http://translationproject.org/POT-files/cpplib-5.1.0.pot Whenever you have a new distribution with a new version number ready, containing a newer POT file, please send the URL of that distribution tarball to the address below. The tarball may be just a pretest or a snapshot, it does not even have to compile. It is just used by the translators when they need some extra translation context. Below is the URL which has been provided to the translators of your package. Please inform the translation coordinator, at the address at the bottom, if this information is not current: https://ftp.gnu.org/gnu/gcc/gcc-5.1.0/gcc-5.1.0.tar.bz2 Translated PO files will later be automatically e-mailed to you. Thank you for all your work, The Translation Project robot, in the name of your translation coordinator. coordina...@translationproject.org
New template for 'gcc' made available
Hello, gentle maintainer. This is a message from the Translation Project robot. (If you have any questions, send them to coordina...@translationproject.org.) A new POT file for textual domain 'gcc' has been made available to the language teams for translation. It is archived as: http://translationproject.org/POT-files/gcc-5.1.0.pot Whenever you have a new distribution with a new version number ready, containing a newer POT file, please send the URL of that distribution tarball to the address below. The tarball may be just a pretest or a snapshot, it does not even have to compile. It is just used by the translators when they need some extra translation context. Below is the URL which has been provided to the translators of your package. Please inform the translation coordinator, at the address at the bottom, if this information is not current: https://ftp.gnu.org/gnu/gcc/gcc-5.1.0/gcc-5.1.0.tar.bz2 Translated PO files will later be automatically e-mailed to you. Thank you for all your work, The Translation Project robot, in the name of your translation coordinator. coordina...@translationproject.org
Re: [PATCH][PR65818][bootstrap,hppa] Return side-effect free result in gimplify_va_arg_internal
On Tue, Apr 28, 2015 at 10:29 PM, Tom de Vries tom_devr...@mentor.com wrote:
On 28-04-15 12:34, Richard Biener wrote:
On Mon, Apr 27, 2015 at 5:04 PM, Tom de Vries tom_devr...@mentor.com
wrote:
On 27-04-15 15:40, Richard Biener wrote:
On Mon, Apr 27, 2015 at 3:06 PM, Tom de Vries tom_devr...@mentor.com
wrote:
On 27-04-15 10:17, Richard Biener wrote:
This patch fixes that by gimplifying the address expression of the
mem-ref
returned by the target hook (borrowing code from gimplify_expr, case
MEM_REF).
Bootstrapped and reg-tested on x86_64.
Bootstrapped and reg-tested on hppa2.0w-hp-hpux11.11.
OK for trunk?
Hmm, that assert looks suspicious...
Can't you simply always do
gimplify_expr (expr, pre_p, post_p, is_gimple_lvalue, fb_lvalue);
It's a bit counter-intuitive for me, using is_gimple_lvalue for
something
(the result of va_arg) we use as rvalue.
Yeah, choosing that was done because you could assert it's a MEM_REF
and tree-stdarg eventually builds a WITH_SIZE_EXPR around it.
It would possibly be easier to simply inline gimplify_va_arg_internal
at its use and only gimplify the assignment. Though in that case the
original code probably worked - just in the lhs == NULL case it didn't,
which hints at a better place for the fix - in expand_ifn_va_arg_1 do
if (lhs != NULL_TREE)
{
...
}
else
gimplify_expr (expr, pre, post, is_gimple_val, fb_either);
So ... if you can re-try that one it's pre-approved.
Using that proposed patch, we run into the following problem.
Consider this testcase with ignored-result-va_arg:
...
#include stdarg.h
void
f2 (int i, ...)
{
va_list ap;
va_start (ap, i);
va_arg (ap, long);
va_end (ap);
}
...
after gimplify_va_arg_internal we have:
...
(gdb) call debug_generic_expr (expr)
*(long int * {ref-all}) addr.2
...
In a bit more detail:
...
(gdb) call debug_tree (expr)
mem_ref 0x765ea1b8
type integer_type 0x764a77e0 long int DI
size integer_cst 0x764a3ca8 constant 64
unit size integer_cst 0x764a3cc0 constant 8
align 64 symtab 0 alias set -1 canonical type 0x764a77e0
precision 64 min integer_cst 0x764a3f30 -9223372036854775808 max
integer_cst 0x764a3f48 9223372036854775807
pointer_to_this pointer_type 0x765e0498
arg 0 nop_expr 0x765cbb60
type pointer_type 0x765e0498 type integer_type
0x764a77e0
long int
public static unsigned DI size integer_cst 0x764a3ca8
64
unit size integer_cst 0x764a3cc0 8
align 64 symtab 0 alias set -1 canonical type
0x765e0498
arg 0 var_decl 0x765e32d0 addr.2 type pointer_type
0x764c2150
used unsigned ignored DI file stdarg-1.c line 4 col 1 size
integer_cst 0x764a3ca8 64 unit size integer_cst 0x764a3cc0 8
align 64 context function_decl 0x765c21b0 f2
arg 1 integer_cst 0x765e64e0 type pointer_type 0x765e0498
constant 0
...
During 'gimplify_expr (expr, pre, post, is_gimple_val, fb_either)' we
ICE
here:
...
8886 gcc_assert ((*gimple_test_f) (*expr_p));
...
At this point expr is:
...
(gdb) call debug_generic_expr (*expr_p)
*addr.2
...
In more detail:
...
(gdb) call debug_tree (*expr_p)
mem_ref 0x765ea1e0
type void_type 0x764c2000 void VOID
align 8 symtab 0 alias set -1 canonical type 0x764c2000
pointer_to_this pointer_type 0x764c2150
arg 0 var_decl 0x765e32d0 addr.2
type pointer_type 0x764c2150 type void_type 0x764c2000
void
sizes-gimplified public unsigned DI
size integer_cst 0x764a3ca8 constant 64
unit size integer_cst 0x764a3cc0 constant 8
align 64 symtab 0 alias set -1 canonical type 0x764c2150
pointer_to_this pointer_type 0x764c9bd0
used unsigned ignored DI file stdarg-1.c line 4 col 1 size
integer_cst 0x764a3ca8 64 unit size integer_cst 0x764a3cc0 8
align 64 context function_decl 0x765c21b0 f2
arg 1 integer_cst 0x764c10c0 type pointer_type 0x764c2150
constant 0
...
The memref is now VOID type. And that's not a gimple_val:
...
(gdb) p is_gimple_val (*expr_p)
$1 = false
...
On which target? I can't seem to reproduce on x86_64 or i?86. I also
can't see how this
could happen.
Reproduced using attached patch on top of r222537, for target x86_64, with
and without -m32.
Ok, I see now. The gimplifier seems to be confused with fb_lvalue.
all is_gimple_addressable ()s are already is_gimple_lvalue so
Index: gcc/gimplify.c
===
--- gcc/gimplify.c (revision 222537)
+++ gcc/gimplify.c (working copy)
@@ -8844,15 +8844,9 @@ gimplify_expr (tree *expr_p, gimple_seq
rvalue. */
if ((fallback fb_lvalue)
OMP_CLAUSES with clauses in operand 0 (was: Fix OpenMP's target update directive in templated code)
Hi Jakub! On Wed, 29 Apr 2015 10:53:32 +0200, Jakub Jelinek ja...@redhat.com wrote: On Tue, Apr 28, 2015 at 08:45:50PM +0200, Thomas Schwinge wrote: That said, what is the preferred approach to add support for OACC_ENTER_DATA, OACC_EXIT_DATA, OACC_UPDATE? I'm not sure hard-coding TREE_OPERAND (t, 0) in gcc/cp/pt.c:tsubst_expr is the way to go, and also duplicating the OMP_TARGET_UPDATE code for each of the three OACC_* doesn't sound appealing -- especially given that we just switched on the respective tree code, so the O*_CHECK of the respective O*_CLAUSES macro is completely redundant. Is it OK to extend gcc/tree.h:OMP_CLAUSES so that it can also be used for tree codes that keep clauses in operand 0, and then use that here (and also in gcc/gimplify.c:gimplify_omp_target_update, for example)? How could it work when it is operand 1 on some and operand 0 in others. Something like (untested): #define OMP_CLAUSES(NODE) \ - TREE_OPERAND (TREE_RANGE_CHECK (NODE, OACC_PARALLEL, OMP_SINGLE), 1) \ + (tree_code (NODE) = OMP_SINGLE) \ + ? TREE_OPERAND (TREE_RANGE_CHECK (NODE, OACC_PARALLEL, OMP_SINGLE), 1) \ + : TREE_OPERAND (TREE_RANGE_CHECK (NODE, OACC_CACHE, OMP_TARGET_UPDATE), 0) Rationale: I'm not expecting another variant to be added later on (clauses are either in operand 0 or 1). Encoding explicit tree code (ordering) assuptions is already done with the usage of TREE_RANGE_CHECK macros, so the additional tree code check doesn't make this much worse. It has the benefit of offering the same known OMP_CLAUSES interface. Yet, if that's a non-starter, I'll pursue this one: IMHO, if you want to reuse the same code for OMP_TARGET_UPDATE, various OACC_* standalone directives (and OMP_TARGET_ENTER_DATA/OMP_TARGET_EXIT_DATA in OpenMP 4.1), then you should make sure they are consecutive in target.def (tree.def; we've already made sure they're grouped consecutively.) and define OMP_STANDALONE_CLAUSES or OMP_TARGET_STANDALONE_CLAUSES as a range check between OMP_TARGET_UPDATE and the last OpenACC directive without body, just clauses. Grüße, Thomas pgpStG6NDIEr5.pgp Description: PGP signature
Re: gcc/c-family/c-pragma.h:pragma_omp_clause (was: Pragma parsing)
On Tue, Apr 28, 2015 at 06:59:12PM +0200, Thomas Schwinge wrote:
We're getting ready to submit patches extending the C/C++ front ends for
the remaining OpenACC clauses, and given the current layout of
gcc/c-family/c-pragma.h:pragma_omp_clause, we're then at 69 unique
clauses, which is more than the 64-bit bitmask limit.
[...] I understand,
for example, PRAGMA_OMP_CLAUSE_REDUCTION to just be a numeric
representation of the reduction string [...]
Should we now further split parsing of Cilk+/OpenACC/OpenMP pragmas (but
I think you and I agreed that we don't want to go that route), or
revisist Chung-Lin's std::bitset proposal (see below), or something else?
Regarding std::bitset, you've been worried about performance,
http://news.gmane.org/find-root.php?message_id=%3C20141218142942.GM1667%40tucnak.redhat.com%3E,
but I'm not sure about this: aren't these code paths only exercised for
pragma parsing, and aren't there really only ever one handful (or, a few)
of pragmas per source code file, so this could hardly be an observable
performance hit?
As I said earlier, I run into this during OpenMP 4.1 work too. The
std::bitset variant generates significantly larger code to what I've
bootstrapped/regtested on x86_64-linux and i686-linux and committed to
trunk. Furthermore, there are severe issues with including STL headers
in the middle of GCC include files, and not even C++14 allows bitsets to be
readably initialized (...set(X).set(Y).set(Z).set(W) doesn't IMHO count).
2015-04-29 Jakub Jelinek ja...@redhat.com
* c-common.h (omp_clause_mask): Unconditionally define as a class.
Use uint64_t instead of unsigned HOST_WIDE_INT and 64 instead of
HOST_BITS_PER_WIDE_INT.
--- gcc/c-family/c-common.h.jj 2015-04-11 15:55:57.0 +0200
+++ gcc/c-family/c-common.h 2015-04-29 10:19:17.629643284 +0200
@@ -1096,16 +1096,11 @@ extern void pp_dir_change (cpp_reader *,
extern bool check_missing_format_attribute (tree, tree);
/* In c-omp.c */
-#if HOST_BITS_PER_WIDE_INT = 64
-typedef unsigned HOST_WIDE_INT omp_clause_mask;
-# define OMP_CLAUSE_MASK_1 ((omp_clause_mask) 1)
-#else
struct omp_clause_mask
{
inline omp_clause_mask ();
- inline omp_clause_mask (unsigned HOST_WIDE_INT l);
- inline omp_clause_mask (unsigned HOST_WIDE_INT l,
- unsigned HOST_WIDE_INT h);
+ inline omp_clause_mask (uint64_t l);
+ inline omp_clause_mask (uint64_t l, uint64_t h);
inline omp_clause_mask operator = (omp_clause_mask);
inline omp_clause_mask operator |= (omp_clause_mask);
inline omp_clause_mask operator ~ () const;
@@ -1115,7 +1110,7 @@ struct omp_clause_mask
inline omp_clause_mask operator (int);
inline bool operator == (omp_clause_mask) const;
inline bool operator != (omp_clause_mask) const;
- unsigned HOST_WIDE_INT low, high;
+ uint64_t low, high;
};
inline
@@ -1124,14 +1119,13 @@ omp_clause_mask::omp_clause_mask ()
}
inline
-omp_clause_mask::omp_clause_mask (unsigned HOST_WIDE_INT l)
+omp_clause_mask::omp_clause_mask (uint64_t l)
: low (l), high (0)
{
}
inline
-omp_clause_mask::omp_clause_mask (unsigned HOST_WIDE_INT l,
- unsigned HOST_WIDE_INT h)
+omp_clause_mask::omp_clause_mask (uint64_t l, uint64_t h)
: low (l), high (h)
{
}
@@ -1177,18 +1171,17 @@ inline omp_clause_mask
omp_clause_mask::operator (int amount)
{
omp_clause_mask ret;
- if (amount = HOST_BITS_PER_WIDE_INT)
+ if (amount = 64)
{
ret.low = 0;
- ret.high = low (amount - HOST_BITS_PER_WIDE_INT);
+ ret.high = low (amount - 64);
}
else if (amount == 0)
ret = *this;
else
{
ret.low = low amount;
- ret.high = (low (HOST_BITS_PER_WIDE_INT - amount))
-| (high amount);
+ ret.high = (low (64 - amount)) | (high amount);
}
return ret;
}
@@ -1197,17 +1190,16 @@ inline omp_clause_mask
omp_clause_mask::operator (int amount)
{
omp_clause_mask ret;
- if (amount = HOST_BITS_PER_WIDE_INT)
+ if (amount = 64)
{
- ret.low = high (amount - HOST_BITS_PER_WIDE_INT);
+ ret.low = high (amount - 64);
ret.high = 0;
}
else if (amount == 0)
ret = *this;
else
{
- ret.low = (high (HOST_BITS_PER_WIDE_INT - amount))
-| (low amount);
+ ret.low = (high (64 - amount)) | (low amount);
ret.high = high amount;
}
return ret;
@@ -1225,8 +1217,7 @@ omp_clause_mask::operator != (omp_clause
return low != b.low || high != b.high;
}
-# define OMP_CLAUSE_MASK_1 omp_clause_mask (1)
-#endif
+#define OMP_CLAUSE_MASK_1 omp_clause_mask (1)
enum c_omp_clause_split
{
Jakub
[PATCH][PR65893] Move pass_stdarg to after pass_dce in pass_all_optimizations
Hi, After moving the expansion of va_arg from gimplification to pass_stdarg, we execute less optimization passes on the expanded va_arg. For example, in PR65893 the optimized-dump code for a va_arg expansion for aarch64 is less optimal than it was before, because pass_tree_ifcombine is no longer executed for the expanded va_arg. This patch fixes the problem by moving pass_stdarg a bit earlier, to after pass_dce: ... NEXT_PASS (pass_vrp); NEXT_PASS (pass_chkp_opt); NEXT_PASS (pass_dce); + NEXT_PASS (pass_stdarg); NEXT_PASS (pass_call_cdce); NEXT_PASS (pass_cselim); NEXT_PASS (pass_copy_prop); NEXT_PASS (pass_tree_ifcombine); NEXT_PASS (pass_phiopt); NEXT_PASS (pass_tail_recursion); NEXT_PASS (pass_ch); - NEXT_PASS (pass_stdarg); NEXT_PASS (pass_lower_complex); NEXT_PASS (pass_sra); NEXT_PASS (pass_rename_ssa_copies); ... Bootstrapped and reg-tested on x86_64. OK for trunk? Thanks, - Tom Move pass_stdarg to after pass_dce in pass_all_optimizations 2015-04-29 Tom de Vries t...@codesourcery.com PR tree-optimization/65893 * passes.def (pass_all_optimizations): Move pass_stdarg to after pass_dce. --- gcc/passes.def | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gcc/passes.def b/gcc/passes.def index 6dce141..32213e8 100644 --- a/gcc/passes.def +++ b/gcc/passes.def @@ -172,6 +172,7 @@ along with GCC; see the file COPYING3. If not see NEXT_PASS (pass_vrp); NEXT_PASS (pass_chkp_opt); NEXT_PASS (pass_dce); + NEXT_PASS (pass_stdarg); NEXT_PASS (pass_call_cdce); NEXT_PASS (pass_cselim); NEXT_PASS (pass_copy_prop); @@ -179,7 +180,6 @@ along with GCC; see the file COPYING3. If not see NEXT_PASS (pass_phiopt); NEXT_PASS (pass_tail_recursion); NEXT_PASS (pass_ch); - NEXT_PASS (pass_stdarg); NEXT_PASS (pass_lower_complex); NEXT_PASS (pass_sra); NEXT_PASS (pass_rename_ssa_copies); -- 1.9.1
Re: Fix OpenMP's target update directive in templated code
On Tue, Apr 28, 2015 at 08:45:50PM +0200, Thomas Schwinge wrote:
I guess nobody so far ;-) has been using OpenMP's target update directive
in templated code -- OK to commit the following, and to which branches
(4.9, 5, trunk)?
Seems I've missed testcases for target {,update,data} in templates indeed,
generally for C++ I'm trying to add testcases for templates, both when
relevant types are type dependent and whey aren't.
gcc/cp/
* pt.c (tsubst_expr) OMP_TARGET_UPDATE: Use
OMP_TARGET_UPDATE_CLAUSES instead of OMP_CLAUSES.
gcc/testsuite/
* g++.dg/gomp/tpl-target-update.C: New file.
This is ok for trunk, 5.2 and 4.9.3, thanks for fixing that.
That said, what is the preferred approach to add support for
OACC_ENTER_DATA, OACC_EXIT_DATA, OACC_UPDATE? I'm not sure hard-coding
TREE_OPERAND (t, 0) in gcc/cp/pt.c:tsubst_expr is the way to go, and also
duplicating the OMP_TARGET_UPDATE code for each of the three OACC_*
doesn't sound appealing -- especially given that we just switched on
the respective tree code, so the O*_CHECK of the respective O*_CLAUSES
macro is completely redundant. Is it OK to extend gcc/tree.h:OMP_CLAUSES
so that it can also be used for tree codes that keep clauses in operand
0, and then use that here (and also in
gcc/gimplify.c:gimplify_omp_target_update, for example)?
How could it work when it is operand 1 on some and operand 0 in others.
IMHO, if you want to reuse the same code for OMP_TARGET_UPDATE,
various OACC_* standalone directives (and
OMP_TARGET_ENTER_DATA/OMP_TARGET_EXIT_DATA in OpenMP 4.1), then
you should make sure they are consecutive in target.def and
define OMP_STANDALONE_CLAUSES or OMP_TARGET_STANDALONE_CLAUSES as
a range check between OMP_TARGET_UPDATE and the last OpenACC directive
without body, just clauses.
Jakub
[PATCH, ARM] Fix for pr65924
Hi,
here is the patch for PR65924, only tested on the original testcase so far.
Thanks
Yvan
gcc/
2015-04-29 Yvan Roux yvan.r...@linaro.org
PR target/65924
* config/arm/thumb2.md (*thumb2_addsi3_compare0_scratch): Fix operand
number in type attribute expression.
gcc/testsuite/
2015-04-29 Yvan Roux yvan.r...@linaro.org
PR target/65924
gcc.target/arm/pr65924.c: New test.
diff --git a/gcc/config/arm/thumb2.md b/gcc/config/arm/thumb2.md
index 4f9faac..2c91542 100644
--- a/gcc/config/arm/thumb2.md
+++ b/gcc/config/arm/thumb2.md
@@ -1305,7 +1305,7 @@
[(set_attr conds set)
(set_attr length 2,4)
- (set (attr type) (if_then_else (match_operand 2 const_int_operand )
+ (set (attr type) (if_then_else (match_operand 1 const_int_operand )
(const_string alus_imm)
(const_string alus_sreg)))]
)
diff --git a/gcc/testsuite/gcc.target/arm/pr65924.c
b/gcc/testsuite/gcc.target/arm/pr65924.c
new file mode 100644
index 000..746749f
--- /dev/null
+++ b/gcc/testsuite/gcc.target/arm/pr65924.c
@@ -0,0 +1,8 @@
+/* { dg-do compile } */
+/* { dg-options -O2 -mthumb } */
+
+int a, b, c;
+int fn1() {
+ if (b + a 0)
+c = 0;
+}
[RFC]: Remove Mem/address type assumption in combiner
Hi Jeff/Segher,
Restarting the discussion on the GCC combiner assumption about Memory/address
type.
Ref: https://gcc.gnu.org/ml/gcc-patches/2015-01/msg01298.html
https://gcc.gnu.org/ml/gcc/2015-04/msg00028.html
While working on the test case in PR 63949, I came across the below code in
combine.c: make_compound_operation.
--snip---
/* Select the code to be used in recursive calls. Once we are inside an
address, we stay there. If we have a comparison, set to COMPARE,
but once inside, go back to our default of SET. */
next_code = (code == MEM ? MEM
: ((code == PLUS || code == MINUS)
SCALAR_INT_MODE_P (mode)) ? MEM
: ((code == COMPARE || COMPARISON_P (x))
XEXP (x, 1) == const0_rtx) ? COMPARE
: in_code == COMPARE ? SET : in_code);
---snip--
When we see an RTX code with PLUS or MINUS then it is treated as MEM/address
type (we are inside address RTX).
Is there any significance on that assumption? I removed this assumption and
the test case in the PR 63949 passed.
diff --git a/gcc/combine.c b/gcc/combine.c
index 5c763b4..945abdb 100644
--- a/gcc/combine.c
+++ b/gcc/combine.c
@@ -7703,8 +7703,6 @@ make_compound_operation (rtx x, enum rtx_code in_code)
but once inside, go back to our default of SET. */
next_code = (code == MEM ? MEM
- : ((code == PLUS || code == MINUS)
- SCALAR_INT_MODE_P (mode)) ? MEM
: ((code == COMPARE || COMPARISON_P (x))
XEXP (x, 1) == const0_rtx) ? COMPARE
: in_code == COMPARE ? SET : in_code);
On X86_64, it passes bootstrap and regression tests.
But on Aarch64 the test in PR passed, but I got a few test case failures.
Tests that now fail, but worked before:
gcc.target/aarch64/adds1.c scan-assembler adds\tw[0-9]+, w[0-9]+, w[0-9]+, lsl 3
gcc.target/aarch64/adds1.c scan-assembler adds\tx[0-9]+, x[0-9]+, x[0-9]+, lsl 3
gcc.target/aarch64/adds3.c scan-assembler-times adds\tx[0-9]+, x[0-9]+, x[0-9]+,
sxtw 2
gcc.target/aarch64/extend.c scan-assembler add\tw[0-9]+,.*uxth #?1
gcc.target/aarch64/extend.c scan-assembler add\tx[0-9]+,.*uxtw #?3
gcc.target/aarch64/extend.c scan-assembler sub\tw[0-9]+,.*uxth #?1
gcc.target/aarch64/extend.c scan-assembler sub\tx[0-9]+,.*uxth #?1
gcc.target/aarch64/extend.c scan-assembler sub\tx[0-9]+,.*uxtw #?3
gcc.target/aarch64/subs1.c scan-assembler subs\tw[0-9]+, w[0-9]+, w[0-9]+, lsl 3
gcc.target/aarch64/subs1.c scan-assembler subs\tx[0-9]+, x[0-9]+, x[0-9]+, lsl 3
gcc.target/aarch64/subs3.c scan-assembler-times subs\tx[0-9]+, x[0-9]+, x[0-9]+,
sxtw 2
Based on in_code , If it is of MEM type combiner converts shifts to
multiply operations.
--snip--
switch (code)
{
case ASHIFT:
/* Convert shifts by constants into multiplications if inside
an address. */
if (in_code == MEM CONST_INT_P (XEXP (x, 1))
INTVAL (XEXP (x, 1)) HOST_BITS_PER_WIDE_INT
INTVAL (XEXP (x, 1)) = 0
SCALAR_INT_MODE_P (mode))
---snip
There are few patterns based on multiplication operations in Aarch64 backend
which are used to match with the pattern combiner generated.
Now those patterns have to be fixed to use SHIFTS. Also need to see any impact
on other targets.
But before that I wanted to check if the assumption in combiner, can simply
be removed ?
Regards,
Venkat.
PS: I am starting a new thread since I no more have access to Linaro ID from
where I sent the earlier mail.
[PATCH] XFAIL PR65917
The testcase gcc.dg/tree-ssa/20030922-2.c FAILs on m68k (and possibly
elsewhere), not on x86_64 though.
So on x86_64 ifcombine has removed the if but after dom1 we still have
_14 = *_13;
if (_8 != _14)
goto bb 3;
else
goto bb 5;
bb 3:
target_bb.1_15 = target_bb;
_16 = _8 != target_bb.1_15;
_17 = _14 == target_bb.1_15;
_18 = _16 _17;
if (_18 != 0)
which shows that running ifcombine before DOM might not be the best idea.
It also shows that the testcase should disable ifcombine to really test
what it was supposed to test. And then it also fails on x86_64.
VRP does optimize this case because it has a more powerful way to track
equivalences (and does a quadratic job in trying to simplify compares
using
all equivalences of the lhs vs all equivalences of the rhs).
Which is another hint at the fact that DOM maybe shouldn't treat
equivalences
derived from conditionals in the SSA_VALUE table where you can't really
record
both _14 = target_bb.1_15 and target_bb.1_15 = _14 (which would get you a
nice cycle there).
For the existing way of DOM handlign this I don't see anything in the
testcase
that could be used to build a new heuristic (in fact another heuristic
would say that what we do now is good -- _14 dies at the point where we
build the equivalency, target_bb.1_15 does not, so we don't want to
propagate
_14 because that will increase its lifetime!)
So the following fixes the testcase to also FAIL on x86_64 and
XFAILs it.
Tested on x86_64, applied.
Richard.
2015-04-29 Richard Biener rguent...@suse.de
PR tree-optimization/65917
* gcc.dg/tree-ssa/20030922-2.c: Disable ifcombine and XFAIL.
Index: gcc/testsuite/gcc.dg/tree-ssa/20030922-2.c
===
--- gcc/testsuite/gcc.dg/tree-ssa/20030922-2.c (revision 222560)
+++ gcc/testsuite/gcc.dg/tree-ssa/20030922-2.c (working copy)
@@ -1,5 +1,5 @@
/* { dg-do compile } */
-/* { dg-options -O1 -fdump-tree-dom1 } */
+/* { dg-options -O1 -fdump-tree-dom1 -fdisable-tree-ifcombine } */
struct rtx_def;
typedef struct rtx_def *rtx;
@@ -20,5 +20,9 @@ rgn_rank (rtx insn1, rtx insn2)
}
/* There should be two IF conditionals. */
-/* { dg-final { scan-tree-dump-times if 2 dom1 } } */
+/* This now fails as it requires a very specific decision of DOM which
+ SSA name to record as a copy of the other when DOM derives copies
+ from temporary equivalences. The heuristics there no longer do
+ the correct thing. VRP still optimizes this testcase. */
+/* { dg-final { scan-tree-dump-times if 2 dom1 { xfail *-*-* } } } */
/* { dg-final { cleanup-tree-dump dom1 } } */
Re: [PATCH] gimple-walk.c #include TLC
On Wed, Apr 29, 2015 at 10:01 AM, Bernhard Reutner-Fischer
rep.dot@gmail.com wrote:
Hi there,
I noticed that gimple-walk.c has a creative list of #includes.
Furthermore, in walk_gimple_asm parse_{in,out}put_constraint was called
even if neither allows_mem, allows_reg nor is_inout were used -- i.e. if
wi is NULL -- and the return value of the constraint parsing was not
taken into account which looks wrong or at least odd. Note that several
other spots in the tree do ignore the parse_{in,out}put_constraint return
values and should be adjusted too AFAIU. Otherwise we might attempt
(and use!) to extract information from otherwise illegal constraints,
it seems?
Bootstrapped and regtested on x86_64-unknown-linux with no regressions.
Ok for trunk?
Ok.
Thanks,
Richard.
gcc/ChangeLog:
* gimple-walk.c: Prune duplicate or unneeded includes.
(walk_gimple_asm): Only call parse_input_constraint or
parse_output_constraint if their findings are used.
Honour parse_input_constraint and parse_output_constraint
result.
diff --git a/gcc/gimple-walk.c b/gcc/gimple-walk.c
index 45ff859..53462b5 100644
--- a/gcc/gimple-walk.c
+++ b/gcc/gimple-walk.c
@@ -2,75 +2,69 @@
Copyright (C) 2007-2015 Free Software Foundation, Inc.
Contributed by Aldy Hernandez al...@redhat.com
This file is part of GCC.
GCC is free software; you can redistribute it and/or modify it under
the terms of the GNU General Public License as published by the Free
Software Foundation; either version 3, or (at your option) any later
version.
GCC is distributed in the hope that it will be useful, but WITHOUT ANY
WARRANTY; without even the implied warranty of MERCHANTABILITY or
FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
for more details.
You should have received a copy of the GNU General Public License
along with GCC; see the file COPYING3. If not see
http://www.gnu.org/licenses/. */
#include config.h
#include system.h
#include coretypes.h
#include tm.h
#include hash-set.h
-#include machmode.h
#include vec.h
#include double-int.h
#include input.h
#include alias.h
#include symtab.h
-#include wide-int.h
#include inchash.h
#include tree.h
-#include fold-const.h
-#include stmt.h
#include predict.h
#include hard-reg-set.h
-#include input.h
#include function.h
-#include basic-block.h
-#include tree-ssa-alias.h
-#include internal-fn.h
#include gimple-expr.h
#include is-a.h
+#include tree-ssa-alias.h
+#include basic-block.h
+#include fold-const.h
#include gimple.h
#include gimple-iterator.h
#include gimple-walk.h
-#include gimple-walk.h
-#include demangle.h
+#include stmt.h
/* Walk all the statements in the sequence *PSEQ calling walk_gimple_stmt
on each one. WI is as in walk_gimple_stmt.
If walk_gimple_stmt returns non-NULL, the walk is stopped, and the
value is stored in WI-CALLBACK_RESULT. Also, the statement that
produced the value is returned if this statement has not been
removed by a callback (wi-removed_stmt). If the statement has
been removed, NULL is returned.
Otherwise, all the statements are walked and NULL returned. */
gimple
walk_gimple_seq_mod (gimple_seq *pseq, walk_stmt_fn callback_stmt,
walk_tree_fn callback_op, struct walk_stmt_info *wi)
{
gimple_stmt_iterator gsi;
for (gsi = gsi_start (*pseq); !gsi_end_p (gsi); )
{
tree ret = walk_gimple_stmt (gsi, callback_stmt, callback_op, wi);
if (ret)
{
/* If CALLBACK_STMT or CALLBACK_OP return a value, WI must exist
to hold it. */
@@ -107,71 +101,76 @@ walk_gimple_seq (gimple_seq seq, walk_stmt_fn
callback_stmt,
/* Helper function for walk_gimple_stmt. Walk operands of a GIMPLE_ASM. */
static tree
walk_gimple_asm (gasm *stmt, walk_tree_fn callback_op,
struct walk_stmt_info *wi)
{
tree ret, op;
unsigned noutputs;
const char **oconstraints;
unsigned i, n;
const char *constraint;
bool allows_mem, allows_reg, is_inout;
noutputs = gimple_asm_noutputs (stmt);
oconstraints = (const char **) alloca ((noutputs) * sizeof (const char *));
if (wi)
wi-is_lhs = true;
for (i = 0; i noutputs; i++)
{
op = gimple_asm_output_op (stmt, i);
constraint = TREE_STRING_POINTER (TREE_VALUE (TREE_PURPOSE (op)));
oconstraints[i] = constraint;
- parse_output_constraint (constraint, i, 0, 0, allows_mem,
allows_reg,
- is_inout);
if (wi)
- wi-val_only = (allows_reg || !allows_mem);
+ {
+ if (parse_output_constraint (constraint, i, 0, 0, allows_mem,
+ allows_reg, is_inout))
+ wi-val_only = (allows_reg || !allows_mem);
+ }
ret = walk_tree (TREE_VALUE (op), callback_op, wi, NULL);
Re: OMP_CLAUSES with clauses in operand 0 (was: Fix OpenMP's target update directive in templated code)
On Wed, Apr 29, 2015 at 11:28:55AM +0200, Thomas Schwinge wrote: Yet, if that's a non-starter, I'll pursue this one: Yeah, it is a non-starter, it has unnecessary runtime overhead everywhere where it is used. Jakub
[patch] Perform anonymous constant propagation during inlining
Historically the pragma Inline_Always of GNAT had been implemented in the FE
because the RTL inliner and then the Tree inliner weren't invoked at -O0 or
powerful enough to inline some constructs. But this approach had drawbacks,
especially wrt debug info. These restrictions were gradually lifted and now
the pragma is entirely piggybacked on the Tree inliner.
This went mostly OK, except for a few cases where intrisinc operations that
used to be reasonably handled at -O0 now generate awful code, the typical
example being a modulus or division instrinsic by a power-of-2 generating a
fully-fledged modulus or division instruction instead of a simple shift.
Therefore the attached patch implements anonymous constant propagation in the
inliner to fix the code quality regression.
Tested on x86_64-suse-linux, OK for the mainline?
2015-04-29 Eric Botcazou ebotca...@adacore.com
* tree-inline.c (remap_gimple_op_r): Do anonymous constant propagation.
(copy_bb): Fold conversions of constants immediately.
2015-04-29 Eric Botcazou ebotca...@adacore.com
* gnat.dg/inline12.adb: New test.
--
Eric Botcazou-- { dg-do compile }
with System.Storage_Elements; use System, System.Storage_Elements;
function Inline12 return Natural is
A : Address := Inline12'Code_Address;
begin
while A mod Address'Alignment /= 0 loop
A := A + 1;
end loop;
return Natural (A - Inline12'Code_Address);
end;
-- { dg-final { scan-assembler-not mod|div } }Index: tree-inline.c
===
--- tree-inline.c (revision 222439)
+++ tree-inline.c (working copy)
@@ -898,7 +898,19 @@ remap_gimple_op_r (tree *tp, int *walk_s
if (TREE_CODE (*tp) == SSA_NAME)
{
- *tp = remap_ssa_name (*tp, id);
+ tree t = remap_ssa_name (*tp, id);
+ /* Perform anonymous constant propagation, this makes it possible to
+ generate reasonable code even at -O0 for operators implemented as
+ inline functions. */
+ if (TREE_CODE (t) == SSA_NAME
+ SSA_NAME_DEF_STMT (t)
+ (!SSA_NAME_VAR (t) || DECL_IGNORED_P (SSA_NAME_VAR (t)))
+ gimple_assign_copy_p (SSA_NAME_DEF_STMT (t))
+ is_gimple_min_invariant
+ (gimple_assign_rhs1 (SSA_NAME_DEF_STMT (t
+ *tp = gimple_assign_rhs1 (SSA_NAME_DEF_STMT (t));
+ else
+ *tp = t;
*walk_subtrees = 0;
return NULL;
}
@@ -1965,7 +1977,7 @@ copy_bb (copy_body_data *id, basic_block
/* Statements produced by inlining can be unfolded, especially
when we constant propagated some operands. We can't fold
- them right now for two reasons:
+ them right now in the general case for two reasons:
1) folding require SSA_NAME_DEF_STMTs to be correct
2) we can't change function calls to builtins.
So we just mark statement for later folding. We mark
@@ -1974,7 +1986,10 @@ copy_bb (copy_body_data *id, basic_block
foldable indirectly are updated. If this turns out to be
expensive, copy_body can be told to watch for nontrivial
changes. */
- if (id-statements_to_fold)
+ if (gimple_assign_cast_p (stmt)
+ is_gimple_min_invariant (gimple_assign_rhs1 (stmt)))
+ fold_stmt (copy_gsi);
+ else if (id-statements_to_fold)
id-statements_to_fold-add (stmt);
/* We're duplicating a CALL_EXPR. Find any corresponding
Re: Refactor gcc/tree-vectorize.c:vectorize_loops
On Tue, Apr 28, 2015 at 09:53:24PM -0600, Jeff Law wrote:
On 04/28/2015 08:20 PM, Aditya K wrote:
Hi,
This is a small patch where I moved a portion of code from the function
vectorize_loops outside to improve readability.
Please see the patch attached and give comments for improvements.
You need to add a comment for the new function. These function comments
should describe what the function does, in terms of its arguments and return
value (if any).
With a function comment, this refactoring would be fine.
--- a/gcc/tree-vectorizer.c
+++ b/gcc/tree-vectorizer.c
@@ -399,6 +399,39 @@ fold_loop_vectorized_call (gimple g, tree value)
}
}
+static void
+set_uid_loop_bbs(loop_vec_info loop_vinfo, gimple loop_vectorized_call)
The formatting is incorrect too, missing space before ( here.
+{
+tree arg = gimple_call_arg (loop_vectorized_call, 1);
Lines should be indented by 2 spaces rather than after {
+basic_block *bbs;
+unsigned int i;
+struct loop *scalar_loop = get_loop (cfun, tree_to_shwi (arg));
+
+LOOP_VINFO_SCALAR_LOOP (loop_vinfo) = scalar_loop;
+gcc_checking_assert (vect_loop_vectorized_call
+(LOOP_VINFO_SCALAR_LOOP (loop_vinfo))
+ == loop_vectorized_call);
+bbs = get_loop_body (scalar_loop);
+for (i = 0; i scalar_loop-num_nodes; i++)
+ {
+basic_block bb = bbs[i];
+gimple_stmt_iterator gsi;
+for (gsi = gsi_start_phis (bb); !gsi_end_p (gsi);
+ gsi_next (gsi))
With the refactoring, this for should fit on one line.
+ {
+gimple phi = gsi_stmt (gsi);
+gimple_set_uid (phi, 0);
+ }
+for (gsi = gsi_start_bb (bb); !gsi_end_p (gsi);
+ gsi_next (gsi))
Likewise.
if (loop_vectorized_call)
- {
+ set_uid_loop_bbs(loop_vinfo, loop_vectorized_call);
Again, missing space before (. And you are using only spaces
when a tab plus two spaces should be used.
Jakub
[PATCH] PR target/48904 x86_64-knetbsd-gnu missing defs
2012-09-21 H.J. Lu hongjiu...@intel.com
PR target/48904
* config.gcc (x86_64-*-knetbsd*-gnu): Add i386/knetbsd-gnu64.h.
* config/i386/knetbsd-gnu64.h: New file
Signed-off-by: Bernhard Reutner-Fischer rep.dot@gmail.com
---
This fixes config-list.mk all-gcc for x86_64-knetbsd-gnu.
Ok for trunk?
gcc/config.gcc |2 +-
gcc/config/i386/knetbsd-gnu64.h | 27 +++
2 files changed, 28 insertions(+), 1 deletion(-)
create mode 100644 gcc/config/i386/knetbsd-gnu64.h
diff --git a/gcc/config.gcc b/gcc/config.gcc
index a1df043..77ef473 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -1517,7 +1517,7 @@ x86_64-*-linux* | x86_64-*-kfreebsd*-gnu |
x86_64-*-knetbsd*-gnu)
tm_file=${tm_file} kfreebsd-gnu.h i386/kfreebsd-gnu64.h
;;
x86_64-*-knetbsd*-gnu)
- tm_file=${tm_file} knetbsd-gnu.h
+ tm_file=${tm_file} knetbsd-gnu.h i386/knetbsd-gnu64.h
;;
esac
tmake_file=${tmake_file} i386/t-linux64
diff --git a/gcc/config/i386/knetbsd-gnu64.h b/gcc/config/i386/knetbsd-gnu64.h
new file mode 100644
index 000..d621bbe
--- /dev/null
+++ b/gcc/config/i386/knetbsd-gnu64.h
@@ -0,0 +1,27 @@
+/* Definitions for AMD x86-64 running kNetBSD-based GNU systems with ELF format
+ Copyright (C) 2012
+ Free Software Foundation, Inc.
+
+This file is part of GCC.
+
+GCC is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation; either version 3, or (at your option)
+any later version.
+
+GCC is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+GNU General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with GCC; see the file COPYING3. If not see
+http://www.gnu.org/licenses/. */
+
+#define GNU_USER_LINK_EMULATION32 elf_i386
+#define GNU_USER_LINK_EMULATION64 elf_x86_64
+#define GNU_USER_LINK_EMULATIONX32 elf32_x86_64
+
+#define GNU_USER_DYNAMIC_LINKER32 /lib/ld.so.1
+#define GNU_USER_DYNAMIC_LINKER64 /lib/ld-knetbsd-x86-64.so.1
+#define GNU_USER_DYNAMIC_LINKERX32 /lib/ld-knetbsd-x32.so.1
--
1.7.10.4
[PATCH] gimple-walk.c #include TLC
Hi there,
I noticed that gimple-walk.c has a creative list of #includes.
Furthermore, in walk_gimple_asm parse_{in,out}put_constraint was called
even if neither allows_mem, allows_reg nor is_inout were used -- i.e. if
wi is NULL -- and the return value of the constraint parsing was not
taken into account which looks wrong or at least odd. Note that several
other spots in the tree do ignore the parse_{in,out}put_constraint return
values and should be adjusted too AFAIU. Otherwise we might attempt
(and use!) to extract information from otherwise illegal constraints,
it seems?
Bootstrapped and regtested on x86_64-unknown-linux with no regressions.
Ok for trunk?
gcc/ChangeLog:
* gimple-walk.c: Prune duplicate or unneeded includes.
(walk_gimple_asm): Only call parse_input_constraint or
parse_output_constraint if their findings are used.
Honour parse_input_constraint and parse_output_constraint
result.
diff --git a/gcc/gimple-walk.c b/gcc/gimple-walk.c
index 45ff859..53462b5 100644
--- a/gcc/gimple-walk.c
+++ b/gcc/gimple-walk.c
@@ -2,75 +2,69 @@
Copyright (C) 2007-2015 Free Software Foundation, Inc.
Contributed by Aldy Hernandez al...@redhat.com
This file is part of GCC.
GCC is free software; you can redistribute it and/or modify it under
the terms of the GNU General Public License as published by the Free
Software Foundation; either version 3, or (at your option) any later
version.
GCC is distributed in the hope that it will be useful, but WITHOUT ANY
WARRANTY; without even the implied warranty of MERCHANTABILITY or
FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
for more details.
You should have received a copy of the GNU General Public License
along with GCC; see the file COPYING3. If not see
http://www.gnu.org/licenses/. */
#include config.h
#include system.h
#include coretypes.h
#include tm.h
#include hash-set.h
-#include machmode.h
#include vec.h
#include double-int.h
#include input.h
#include alias.h
#include symtab.h
-#include wide-int.h
#include inchash.h
#include tree.h
-#include fold-const.h
-#include stmt.h
#include predict.h
#include hard-reg-set.h
-#include input.h
#include function.h
-#include basic-block.h
-#include tree-ssa-alias.h
-#include internal-fn.h
#include gimple-expr.h
#include is-a.h
+#include tree-ssa-alias.h
+#include basic-block.h
+#include fold-const.h
#include gimple.h
#include gimple-iterator.h
#include gimple-walk.h
-#include gimple-walk.h
-#include demangle.h
+#include stmt.h
/* Walk all the statements in the sequence *PSEQ calling walk_gimple_stmt
on each one. WI is as in walk_gimple_stmt.
If walk_gimple_stmt returns non-NULL, the walk is stopped, and the
value is stored in WI-CALLBACK_RESULT. Also, the statement that
produced the value is returned if this statement has not been
removed by a callback (wi-removed_stmt). If the statement has
been removed, NULL is returned.
Otherwise, all the statements are walked and NULL returned. */
gimple
walk_gimple_seq_mod (gimple_seq *pseq, walk_stmt_fn callback_stmt,
walk_tree_fn callback_op, struct walk_stmt_info *wi)
{
gimple_stmt_iterator gsi;
for (gsi = gsi_start (*pseq); !gsi_end_p (gsi); )
{
tree ret = walk_gimple_stmt (gsi, callback_stmt, callback_op, wi);
if (ret)
{
/* If CALLBACK_STMT or CALLBACK_OP return a value, WI must exist
to hold it. */
@@ -107,71 +101,76 @@ walk_gimple_seq (gimple_seq seq, walk_stmt_fn
callback_stmt,
/* Helper function for walk_gimple_stmt. Walk operands of a GIMPLE_ASM. */
static tree
walk_gimple_asm (gasm *stmt, walk_tree_fn callback_op,
struct walk_stmt_info *wi)
{
tree ret, op;
unsigned noutputs;
const char **oconstraints;
unsigned i, n;
const char *constraint;
bool allows_mem, allows_reg, is_inout;
noutputs = gimple_asm_noutputs (stmt);
oconstraints = (const char **) alloca ((noutputs) * sizeof (const char *));
if (wi)
wi-is_lhs = true;
for (i = 0; i noutputs; i++)
{
op = gimple_asm_output_op (stmt, i);
constraint = TREE_STRING_POINTER (TREE_VALUE (TREE_PURPOSE (op)));
oconstraints[i] = constraint;
- parse_output_constraint (constraint, i, 0, 0, allows_mem, allows_reg,
- is_inout);
if (wi)
- wi-val_only = (allows_reg || !allows_mem);
+ {
+ if (parse_output_constraint (constraint, i, 0, 0, allows_mem,
+ allows_reg, is_inout))
+ wi-val_only = (allows_reg || !allows_mem);
+ }
ret = walk_tree (TREE_VALUE (op), callback_op, wi, NULL);
if (ret)
return ret;
}
n = gimple_asm_ninputs (stmt);
for (i = 0; i n; i++)
{
op = gimple_asm_input_op (stmt, i);
constraint = TREE_STRING_POINTER (TREE_VALUE
Re: [PATCH][PR65893] Move pass_stdarg to after pass_dce in pass_all_optimizations
On Wed, Apr 29, 2015 at 10:52 AM, Tom de Vries tom_devr...@mentor.com wrote: Hi, After moving the expansion of va_arg from gimplification to pass_stdarg, we execute less optimization passes on the expanded va_arg. For example, in PR65893 the optimized-dump code for a va_arg expansion for aarch64 is less optimal than it was before, because pass_tree_ifcombine is no longer executed for the expanded va_arg. This patch fixes the problem by moving pass_stdarg a bit earlier, to after pass_dce: ... NEXT_PASS (pass_vrp); NEXT_PASS (pass_chkp_opt); NEXT_PASS (pass_dce); + NEXT_PASS (pass_stdarg); NEXT_PASS (pass_call_cdce); NEXT_PASS (pass_cselim); NEXT_PASS (pass_copy_prop); NEXT_PASS (pass_tree_ifcombine); NEXT_PASS (pass_phiopt); NEXT_PASS (pass_tail_recursion); NEXT_PASS (pass_ch); - NEXT_PASS (pass_stdarg); NEXT_PASS (pass_lower_complex); NEXT_PASS (pass_sra); NEXT_PASS (pass_rename_ssa_copies); ... Bootstrapped and reg-tested on x86_64. OK for trunk? Ok. Thanks, Richard. Thanks, - Tom
Re: [PATCH 3/8] add default for PCC_BITFIELD_TYPE_MATTERS
spawn /daten/aranym/gcc/gcc-20150429/Build/gcc/xgcc
-B/daten/aranym/gcc/gcc-20150429/Build/gcc/
/daten/aranym/gcc/gcc-20150429/gcc/testsuite/objc/execute/bf-1.m
-fno-diagnostics-show-caret -fdiagnostics-color=never -w -O0 -fgnu-runtime
-I/daten/aranym/gcc/gcc-20150429/gcc/testsuite/../../libobjc
-B/daten/aranym/gcc/gcc-20150429/Build/m68k-linux/./libobjc/.libs
-L/daten/aranym/gcc/gcc-20150429/Build/m68k-linux/./libobjc/.libs -lobjc -lm -o
/daten/aranym/gcc/gcc-20150429/Build/gcc/testsuite/objc/bf-1.x0
PASS: objc/execute/bf-1.m compilation, -O0 -fgnu-runtime
Executing on aranym: OMP_NUM_THREADS=2
LD_LIBRARY_PATH=.::/daten/aranym/gcc/gcc-20150429/Build/gcc:/daten/aranym/gcc/gcc-20150429/Build/m68k-linux/./libobjc/.libs
timeout 600 /daten/aranym/gcc/gcc-20150429/Build/gcc/testsuite/objc/bf-1.x0
(timeout = 300)
Executed /daten/aranym/gcc/gcc-20150429/Build/gcc/testsuite/objc/bf-1.x0,
status 1
Output: type = {class_vars=#fc{?=b0i2b2i3b5i12}c}
ivar 'isa', type '#', offset 0d
ivar 'f', type 'f', offset 4d
ivar 'a', type 'c', offset 8d
ivar 'flags', type '{?=ib0i2jb2i3kb5i12}', offset 9d
ivar 'c', type 'c', offset 12d
real ivar 'isa' offset 0d
computed type '#fc{?=b0i2b2i3b5i12}c}' offset 0
real ivar 'f' offset 4d
computed type 'fc{?=b0i2b2i3b5i12}c}' offset 4
real ivar 'a' offset 8d
computed type 'c{?=b0i2b2i3b5i12}c}' offset 8
real ivar 'flags' offset 9d
computed type '{?=b0i2b2i3b5i12}c}' offset 10
offset 9d and computed position 10 don't match on ivar 'flags' (i = 3)
child process exited abnormally
FAIL: objc/execute/bf-1.m execution, -O0 -fgnu-runtime
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
And now for something completely different.
Re: [PATCH 5/13] microblaze musl support
On 04/27/2015 07:35 AM, Szabolcs Nagy wrote: On 20/04/15 19:54, Szabolcs Nagy wrote: Set up dynamic linker name for microblaze. Patch v2. (undef MUSL_DYNAMIC_LINKER that comes from config/linux.h) gcc/Changelog: 2015-04-24 Gregor Richards gregor.richa...@uwaterloo.ca * config/microblaze/linux.h (MUSL_DYNAMIC_LINKER): Define. (DYNAMIC_LINKER): Change. Are you building with both glibc and musl to verify these patches? -- Michael Eagerea...@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: [gomp4.1] Initial support for some OpenMP 4.1 construct parsing
On Wed, Apr 29, 2015 at 01:52:24PM +0200, Thomas Schwinge wrote:
Hi Jakub!
(I have not yet read any version of the OpenMP 4.1 standard.)
There is no OpenMP 4.1 standard, just the public TR3 released in November
last year, and then some non-public WIP.
+ tree stmt = make_node (OMP_TARGET_DATA);
+ TREE_TYPE (stmt) = void_type_node;
+ OMP_TARGET_DATA_CLAUSES (stmt) = clauses;
Even if it doesn't make a lot of sense, my reading of OpenMP 4.0 has been
that a target data construct without any map clauses is still valid.
(But I have not verified that now.)
Yes, it is valid in OpenMP 4.0. But in GCC we're just supporting the latest
standard, there is no -fopenmp={2.5,3.0,3.1,4.0,4.1} like there is
-std=c{89,99,11}.
--- gcc/omp-low.c.jj2015-04-29 10:58:01.489748182 +0200
+++ gcc/omp-low.c 2015-04-29 11:03:04.646991017 +0200
@@ -8994,6 +9017,11 @@ expand_omp_target (struct omp_region *re
case GF_OMP_TARGET_KIND_UPDATE:
start_ix = BUILT_IN_GOMP_TARGET_UPDATE;
break;
+case GF_OMP_TARGET_KIND_ENTER_DATA:
+case GF_OMP_TARGET_KIND_EXIT_DATA:
+ /* FIXME */
+ start_ix = BUILT_IN_GOMP_TARGET_UPDATE;
+ break;
Actually, I've also wondered (but never verified) whether all of the
OpenACC enter, exit, and update constructs can be implemented via the
same libgomp API.
Well, the behavior is different. The draft requires only alloc or to
(or always, variants) for enter data and only from or delete (or always,
variants) for exit data, so in theory it is possible to figure that from
the call without extra args, but not so for update - enter data is supposed
to increment reference counts, exit data decrement. And, we'll need new
arguments for async (pass through info that it is async (nowait) or sync,
and the depend clause address(es)).
@@ -11488,6 +11520,9 @@ lower_omp_target (gimple_stmt_iterator *
default:
gcc_unreachable ();
}
+ /* FIXME: Temporary hack. */
+ if (talign_shift == 3)
+ tkind = ~GOMP_MAP_FLAG_FORCE;
gcc_checking_assert (tkind
(HOST_WIDE_INT_C (1U) talign_shift));
talign = ceil_log2 (talign);
Assuming you'll be changing the relevant functions' APIs, and assigning
new ABI versions, don't forget to also drop the unused offload_table
formal parameter (assuming that it remains unused).
Yeah, we'll need new GOMP_target{,_data,_end_data,_update} replacements.
--- gcc/tree-pretty-print.c.jj 2015-04-29 10:58:01.663745452 +0200
+++ gcc/tree-pretty-print.c 2015-04-29 11:03:04.648990986 +0200
@@ -550,22 +560,22 @@ dump_omp_clause (pretty_printer *pp, tre
pp_string (pp, tofrom);
break;
case GOMP_MAP_FORCE_ALLOC:
- pp_string (pp, force_alloc);
+ pp_string (pp, always,alloc);
break;
case GOMP_MAP_FORCE_TO:
- pp_string (pp, force_to);
+ pp_string (pp, always,to);
break;
case GOMP_MAP_FORCE_FROM:
- pp_string (pp, force_from);
+ pp_string (pp, always,from);
break;
case GOMP_MAP_FORCE_TOFROM:
- pp_string (pp, force_tofrom);
+ pp_string (pp, always,tofrom);
break;
case GOMP_MAP_FORCE_PRESENT:
pp_string (pp, force_present);
break;
case GOMP_MAP_FORCE_DEALLOC:
- pp_string (pp, force_dealloc);
+ pp_string (pp, always,delete);
break;
case GOMP_MAP_FORCE_DEVICEPTR:
pp_string (pp, force_deviceptr);
Makes some sense to me to use the same always,* syntax also for the
other force_* ones, given that these are artificial (non-OpenACC)
descriptions anyway.
Ok. Are the GOMP_MAP_FORCE_* artificial too? If yes, I can change that
to GOMP_MAP_ALWAYS_*.
Anyway, for most of the further 4.1 offloading I'll defer to Ilya Verbin and
Kyrill as agreed privately on IRC, I'll focus for now on the task / doacross
etc. stuff for now (and, hopefully if enough of the OpenACC stuff is merged
in soon, restart work on the OpenMP 4.0 / NVPTX offloading too, but that not
on this branch).
Jakub
[Patch, fortran, pr65548, 2nd take] [5/6 Regression] gfc_conv_procedure_call
Hi all,
after the first patch to fix the issue reported in the pr, some more issues were
reported, which are now fixed by this new patch, aka the 2nd take.
The patch modifies the gfc_trans_allocate() in order to pre-evaluate all source=
expressions. It no longer rejects array valued source= expressions, but just
uses gfc_conv_expr_descriptor () for most of them. Furthermore, is the allocate
now again able to allocate arrays of strings. This feature previously slipped
my attention.
Although the reporter has not yet reported, that the patch fixes his issue, I
like to post it for review, because there are more patches in my pipeline, that
depend on this one.
Bootstraps and regtests ok on x86_64-linux-gnu/F21.
Ok, for trunk?
Regards,
Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
pr65548_2.clog
Description: Binary data
diff --git a/gcc/fortran/trans-stmt.c b/gcc/fortran/trans-stmt.c
index 53e9bcc..1e435be 100644
--- a/gcc/fortran/trans-stmt.c
+++ b/gcc/fortran/trans-stmt.c
@@ -5148,14 +5148,11 @@ gfc_trans_allocate (gfc_code * code)
TREE_USED (label_finish) = 0;
}
- /* When an expr3 is present, try to evaluate it only once. In most
- cases expr3 is invariant for all elements of the allocation list.
- Only exceptions are arrays. Furthermore the standards prevent a
- dependency of expr3 on the objects in the allocate list. Therefore
- it is safe to pre-evaluate expr3 for complicated expressions, i.e.
- everything not a variable or constant. When an array allocation
- is wanted, then the following block nevertheless evaluates the
- _vptr, _len and element_size for expr3. */
+ /* When an expr3 is present evaluate it only once. The standards prevent a
+ dependency of expr3 on the objects in the allocate list. An expr3 can
+ be pre-evaluated in all cases. One just has to make sure, to use the
+ correct way, i.e., to get the descriptor or to get a reference
+ expression. */
if (code-expr3)
{
bool vtab_needed = false;
@@ -5168,75 +5165,86 @@ gfc_trans_allocate (gfc_code * code)
al = al-next)
vtab_needed = (al-expr-ts.type == BT_CLASS);
- /* A array expr3 needs the scalarizer, therefore do not process it
- here. */
- if (code-expr3-expr_type != EXPR_ARRAY
- (code-expr3-rank == 0
- || code-expr3-expr_type == EXPR_FUNCTION)
- (!code-expr3-symtree
- || !code-expr3-symtree-n.sym-as)
- !gfc_is_class_array_ref (code-expr3, NULL))
- {
- /* When expr3 is a variable, i.e., a very simple expression,
+ /* When expr3 is a variable, i.e., a very simple expression,
then convert it once here. */
- if ((code-expr3-expr_type == EXPR_VARIABLE)
- || code-expr3-expr_type == EXPR_CONSTANT)
- {
- if (!code-expr3-mold
- || code-expr3-ts.type == BT_CHARACTER
- || vtab_needed)
- {
- /* Convert expr3 to a tree. */
- gfc_init_se (se, NULL);
- se.want_pointer = 1;
- gfc_conv_expr (se, code-expr3);
- if (!code-expr3-mold)
- expr3 = se.expr;
- else
- expr3_tmp = se.expr;
- expr3_len = se.string_length;
- gfc_add_block_to_block (block, se.pre);
- gfc_add_block_to_block (post, se.post);
- }
- /* else expr3 = NULL_TREE set above. */
- }
- else
+ if (code-expr3-expr_type == EXPR_VARIABLE
+ || code-expr3-expr_type == EXPR_ARRAY
+ || code-expr3-expr_type == EXPR_CONSTANT)
+ {
+ if (!code-expr3-mold
+ || code-expr3-ts.type == BT_CHARACTER
+ || vtab_needed)
{
- /* In all other cases evaluate the expr3 and create a
- temporary. */
+ /* Convert expr3 to a tree. */
gfc_init_se (se, NULL);
- if (code-expr3-rank != 0
- code-expr3-expr_type == EXPR_FUNCTION
- code-expr3-value.function.isym)
+ /* For all simple expression just get the descriptor or the
+ reference, respectively, depending on the rank of the expr. */
+ if (code-expr3-rank != 0)
gfc_conv_expr_descriptor (se, code-expr3);
else
gfc_conv_expr_reference (se, code-expr3);
- if (code-expr3-ts.type == BT_CLASS)
- gfc_conv_class_to_class (se, code-expr3,
- code-expr3-ts,
- false, true,
- false, false);
+ if (!code-expr3-mold)
+ expr3 = se.expr;
+ else
+ expr3_tmp = se.expr;
+ expr3_len = se.string_length;
gfc_add_block_to_block (block, se.pre);
gfc_add_block_to_block (post, se.post);
- /* Prevent aliasing, i.e., se.expr may be already a
+ }
+ /* else expr3 = NULL_TREE set above. */
+ }
+ else
+ {
+ /* In all other cases evaluate the expr3 and create a
+ temporary. */
+ gfc_init_se (se, NULL);
+ /* For more complicated expression, the decision when to get the
+ descriptor and when to get a reference is depending on more
+ conditions. The descriptor is only retrieved for functions
+ that are intrinsic, elemental user-defined and known, or neither
+ of the two, or are
[PATCH, testsuite]: Add ieee options to gfortran.dg/namelist_87.f90
Hello!
This test uses NaN, so it has to be compiled with ieee options.
2015-04-29 Uros Bizjak ubiz...@gmail.com
* gfortran.dg/namelist_87.f90: Use dg-add-options ieee.
Tested on alphaev68-linux-gnu and committed to mainline.
Uros.
Index: gfortran.dg/namelist_87.f90
===
--- gfortran.dg/namelist_87.f90 (revision 222558)
+++ gfortran.dg/namelist_87.f90 (working copy)
@@ -1,4 +1,5 @@
! { dg-do run }
+! { dg-add-options ieee }
!
! PR fortran/56743
!
Re: [PATCH][AARCH64]Use shl for vec_shr_mode rtx pattern.
On 28 April 2015 at 16:41, Renlin Li renlin...@arm.com wrote: Hi all, unsigned shift left dosen't support immediate shift. Previouly, gcc will generate asm instruction like this: ushl d1, d0, 32, which is not a legal insn and will be rejected by assembler. This patch change the use of ushl in vec_shr_mode into shl. A test case is added, and it passes on both aarch64-none-elf and aarch64_be-none-elf tool-chain. Okay to commit? Regards, Renlin Li gcc/ChangeLog: 2015-04-28 Renlin Li renlin...@arm.com * config/aarch64/aarch64-simd.md (vec_shr_mode): Use shl. gcc/testsuite/ChangeLog: 2015-04-28 Renlin Li renlin...@arm.com Alan Lawrence alan.lawre...@arm.com * gcc.target/aarch64/vect-reduc-or_1.c: New. I think there is another issue here, this change: if (BYTES_BIG_ENDIAN) - return ushl %d0, %d1, %2; + return shl %d0, %d1, %2; else return ushr %d0, %d1, %2; is in the context of: (define_insn vec_shr_mode [(set (match_operand:VD 0 register_operand =w) (lshiftrt:VD (match_operand:VD 1 register_operand w) (match_operand:SI 2 immediate_operand i)))] The RTL describes a right shift of the bits within each element in the vector while the optab expects a right shift of the elements within the vector? /Marcus
Re: [PATCH 3/3] Fix indentation issues seen by -Wmisleading-indentation
Hello, Le 29/04/2015 02:02, David Malcolm a écrit : diff --git a/gcc/fortran/parse.c b/gcc/fortran/parse.c index 2c7c554..30e4eab 100644 --- a/gcc/fortran/parse.c +++ b/gcc/fortran/parse.c @@ -4283,7 +4283,7 @@ parse_oacc_structured_block (gfc_statement acc_st) unexpected_eof (); else if (st != acc_end_st) gfc_error (Expecting %s at %C, gfc_ascii_statement (acc_end_st)); - reject_statement (); + reject_statement (); } while (st != acc_end_st); I think this one is a bug; there should be braces around 'gfc_error' and 'reject_statement'. At least that's the pattern in 'parse_oacc_loop', and how the 'unexpected_statement' function is used. Author CC'ed in any case. Mikael
[C++ Patch] PR 64667
Hi,
Jonathan noticed in the audit trail the probably his work for c++/18016
could be easily extended to handle references: simply looking through
INDIRECT_REFs appears to do the trick. Tested x86_64-linux.
Thanks,
Paolo.
/cp
2015-04-29 Paolo Carlini paolo.carl...@oracle.com
PR c++/64667
* init.c (perform_member_init): Handle references for -Winit-self.
/testsuite
2015-04-29 Paolo Carlini paolo.carl...@oracle.com
PR c++/64667
* g++.dg/warn/Winit-self-3.C: New.
Index: cp/init.c
===
--- cp/init.c (revision 222561)
+++ cp/init.c (working copy)
@@ -625,6 +625,9 @@ perform_member_init (tree member, tree init)
TREE_CHAIN (init) == NULL_TREE)
{
tree val = TREE_VALUE (init);
+ /* Handle references. */
+ if (TREE_CODE (val) == INDIRECT_REF)
+ val = TREE_OPERAND (val, 0);
if (TREE_CODE (val) == COMPONENT_REF TREE_OPERAND (val, 1) == member
TREE_OPERAND (val, 0) == current_class_ref)
warning_at (DECL_SOURCE_LOCATION (current_function_decl),
Index: testsuite/g++.dg/warn/Winit-self-3.C
===
--- testsuite/g++.dg/warn/Winit-self-3.C(revision 0)
+++ testsuite/g++.dg/warn/Winit-self-3.C(working copy)
@@ -0,0 +1,26 @@
+// PR c++/64667
+// { dg-options -Winit-self }
+
+class A
+{
+public:
+ A(const A) : a(a) {} // { dg-warning initialized with itself }
+private:
+ int a;
+};
+
+class B
+{
+public:
+ B(const B) : b(b) {} // { dg-warning initialized with itself }
+private:
+ int* b;
+};
+
+class C
+{
+public:
+ C(const C) : c(c) {} // { dg-warning initialized with itself }
+private:
+ int c;
+};
RE: [RFC: Patch, PR 60158] gcc/varasm.c : Pass actual alignment value to output_constant_pool_2
-Original Message- From: Jeff Law [mailto:l...@redhat.com] Sent: Wednesday, April 29, 2015 4:01 AM To: Dharmakan Rohit-B30502; gcc-patches@gcc.gnu.org; rguent...@suse.de; Jakub Jelinek Cc: Alan Modra; David Edelsohn; Wienskoski Edmar-RA8797 Subject: Re: [RFC: Patch, PR 60158] gcc/varasm.c : Pass actual alignment value to output_constant_pool_2 On 04/28/2015 12:38 PM, rohitarul...@freescale.com wrote: -Original Message- From: Jeff Law [mailto:l...@redhat.com] Sent: Tuesday, April 28, 2015 11:48 PM To: Dharmakan Rohit-B30502; gcc-patches@gcc.gnu.org; rguent...@suse.de; Jakub Jelinek Cc: Alan Modra; David Edelsohn; Wienskoski Edmar-RA8797 Subject: Re: [RFC: Patch, PR 60158] gcc/varasm.c : Pass actual alignment value to output_constant_pool_2 On 04/28/2015 03:44 AM, rohitarul...@freescale.com wrote: Ping. -Original Message- From: Dharmakan Rohit-B30502 Sent: Friday, March 27, 2015 7:57 PM To: gcc-patches@gcc.gnu.org; rguent...@suse.de; Jakub Jelinek Cc: Alan Modra; David Edelsohn; Wienskoski Edmar-RA8797; Dharmakan Rohit-B30502 Subject: RE: [RFC: Patch, PR 60158] gcc/varasm.c : Pass actual alignment value to output_constant_pool_2 Hi, I would like to resubmit these patches for comments. The previous detailed discussion is available in the below mentioned link. https://gcc.gnu.org/ml/gcc-patches/2014-04/msg01679.html https://gcc.gnu.org/ml/gcc-patches/2014-05/msg00489.html The issue is still reproducible on GCC v4.8 branch. I have tested both the attached patches with e500v2 tool chain on GCC v4.8 branch [rev 221667] and GCC trunk [rev 221310] with no regressions. Patch1 [gcc.fix_pr60158_fixup_table_fsf_1]: Pass actual alignment value to output_constant_pool_2. Patch2 [gcc.fix_pr60158_fixup_table_fsf_2]: Use the alignment data available in the first argument (constant_descriptor_rtx) of output_constant_pool_1. (Note: this generates .align directive twice). Are you asking for both patches to be applied or just one? Just one, needed your comments on which would be better. Just wanted to be sure. Particularly since I could make a case for either or both. I think this is the better patch: https://gcc.gnu.org/ml/gcc-patches/2014- 05/msg00489/gcc.fix_pr60158_fixup_table-fsf The change I would request would be to add some comments. So before this code: output_constant_pool_1 (desc, 1); A comment about why passing 1 for the alignment is OK here (because all the data is already aligned, so no need to realign it). And for this change: - output_constant_pool_2 (desc-mode, x, align); + output_constant_pool_2 (desc-mode, x, desc-align); I would suggest a comment why we're using desc-align rather than align. You'll probably want/need to refer back to the call where 1 is passed for the alignment in that comment. With those two comments added, and a fresh bootstrap regression test on the trunk, it'll be good to go. Jeff, I have made the changes as per your comments and attached the patch. If the patch is OK, I will proceed with the regression tests. Regards, Rohit gcc.fix_pr60158_fixup_table_trunk_fsf Description: gcc.fix_pr60158_fixup_table_trunk_fsf
New French PO file for 'gcc' (version 5.1.0)
Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'gcc' has been submitted by the French team of translators. The file is available at: http://translationproject.org/latest/gcc/fr.po (This file, 'gcc-5.1.0.fr.po', has just now been sent to you in a separate email.) All other PO files for your package are available in: http://translationproject.org/latest/gcc/ Please consider including all of these in your next release, whether official or a pretest. Whenever you have a new distribution with a new version number ready, containing a newer POT file, please send the URL of that distribution tarball to the address below. The tarball may be just a pretest or a snapshot, it does not even have to compile. It is just used by the translators when they need some extra translation context. The following HTML page has been updated: http://translationproject.org/domain/gcc.html If any question arises, please contact the translation coordinator. Thank you for all your work, The Translation Project robot, in the name of your translation coordinator. coordina...@translationproject.org
Re: Help needed debugging std::is_convertible problem (PR 65760)
On 17/04/15 01:03 +0200, Daniel Krügler wrote:
2015-04-16 14:33 GMT+02:00 Jonathan Wakely jwakely@gmail.com:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65760
I don't understand why commenting out *any one* of the lines marked
(1), (2), (3), (4) causes this to compile:
#include functional
struct C {
C() = default;
C(std::functionC(int)); // (1)
C(std::functionC(int, int)); // (2)
template class T C operator () (T); // (3)
template class T C operator () (T, T); // (4)
};
My current understanding of the state of affairs is still complete in
some details, but let me still throw in my 2 cents: The compiler sees
an object of C constructed by an rvalue of C. Now we have - in
addition to the copy/move constructors - two corresponding pairs of
function call operator and converting constructor to consider. Let me
simplify the situation a bit more by removing the additional layer of
template deduction of the call operators to:
struct C
{
C() = default;
C(std::functionC(int)); // (1)
C(std::functionC(int, int)); // (2)
C operator()(int); // (3)
C operator()(int, int); // (4)
};
In the presence of all four members the compiler is allowed (I think
by [temp.inst] p7) to instantiate one or both of the different
std::function specializations, because it has to respect possible
conversions. When this happens, the converting template constructor
declaration of std::function also needs to be instantiated. While
doing this, we come to the point where within the SFINAE condition
std::is_convertibleC, C needs to be instantiated, effectively
leading to a situation that we have two different contexts, in which
the compiler needs to evaluate the result the self-conversion of C, C
never becoming completed to realize that during that attempt.
If *any* of the four members is missing, we don't have the situation
that two conversion sequences based on function template deduction
need to be partially ordered, we have only the non-template copy/move
constructor against exactly one possible function template. For this
to order, the compiler doesn't require instantiation of the converting
constructor of std::function.
[...]
Nonetheless, my understanding of your fix is that it actually is not
conforming to what the standard currently requires (This seems to
match you own thinking expressed above), because [func.wrap.func.con]
p8 requires:
shall not participate in overload resolution unless f is Callable
(20.9.12.2) for argument types ArgTypes... and return type R.
and if we unroll this against the definition Callable (ending in
[func.require] p2) we finally end up in a required test whether the
return type of the invokable thingee has a value of
std::is_convertibleC, C::value == true (C has the role of the return
type R). This is so, *even*, if LWG issue
http://cplusplus.github.io/LWG/lwg-active.html#2420
would be fixed as described, because we have no void return type involved here.
My current position is that we presumably have a Standard Library
issue lurking around, because I see no way how any library can
implement std::function without breaking this seemingly valid example
case. Either the Standard Library needs to express stronger
constraints on the return type R of std::functionR(ArgTypes...) (so
to make the example invalid), or - what I would currently prefer - the
library would need to reduce the SFINAE constraints of the
std::function template constructor basically ending in not requiring
that R is complete, or in other words: not requiring the final part of
the Callable test involving the implicit conversion of the functor
result to the described result type R of
std::functionR(ArgTypes...).
To follow the intention of std::functions design, the Library could
require that when the constructor definition of
templateclass F function(F);
becomes instantiated, the current SFINAE requirements are to be
tested, possibly making this definition instantiation ill-formed.
Summarizing this, I consider your suggested resolution as useful for
practical reasons.
While I agree with Daniel that my suggested fix may not be strictly
conforming, I think it is worth doing anyway, so I'm committing it.
Tested powerpc64le-linux, committed to trunk.
commit bc3d6d30fd620ea1d7d286512f983a7a1ddb99c0
Author: Jonathan Wakely jwak...@redhat.com
Date: Fri Apr 17 13:25:42 2015 +0100
PR libstdc++/65760
* include/std/functional (__check_func_return_type): Use is_same to
avoid using _is_convertible on incomplete types.
* testsuite/20_util/function/65760.cc: New.
diff --git a/libstdc++-v3/include/std/functional b/libstdc++-v3/include/std/functional
index e9d48e4..946cf63 100644
--- a/libstdc++-v3/include/std/functional
+++ b/libstdc++-v3/include/std/functional
@@ -1962,7 +1962,7 @@ _GLIBCXX_MEM_FN_TRAITS(, false_type, true_type)
templatetypename _From, typename _To
using __check_func_return_type
- = __or_is_void_To, is_convertible_From, _To;
+ =
Re: C PATCH to reject va_arg (ap, void) (PR c/65901)
On Tue, Apr 28, 2015 at 09:07:09PM -0600, Martin Sebor wrote:
The error message in the test cases below isn't quite right.
The type of the aggregates isn't undefined, it's incomplete.
Looking at the function, I wonder if the first argument
should be EXPR rather than than NULL_TREE? Alternatively,
experimenting with other cases where GCC diagnoses invalid
uses of incomplete type, I see that it issues:
invalid application of %qs to incomplete type %qT
which might work even better here since we could name the
expression (va_arg).
Yeah, I haven't concerned myself with the exact wording of the error
message much, and I agree it could be improved. But passing down the
EXPR would mean that the compiler outputs 'ap' has an incomplete type
and that looks wrong as well. I think I'm going to apply the following
tomorrow if I hear no objections (and it passes testing). Thanks for noticing.
(And I think c_incomplete_type_error deserves some TLC; I'll post a separate
patch.)
2015-04-29 Marek Polacek pola...@redhat.com
* c-typeck.c (c_build_va_arg): Clarify the error message.
* gcc.dg/pr65901.c (foo): Adjust dg-error.
diff --git gcc/c/c-typeck.c gcc/c/c-typeck.c
index c58e918..028d2f81 100644
--- gcc/c/c-typeck.c
+++ gcc/c/c-typeck.c
@@ -12645,14 +12645,17 @@ c_build_qualified_type (tree type, int type_quals)
tree
c_build_va_arg (location_t loc, tree expr, tree type)
{
- if (warn_cxx_compat TREE_CODE (type) == ENUMERAL_TYPE)
-warning_at (loc, OPT_Wc___compat,
- C++ requires promoted type, not enum type, in %va_arg%);
- if (type == error_mark_node || !COMPLETE_TYPE_P (type))
+ if (error_operand_p (type))
+return error_mark_node;
+ else if (!COMPLETE_TYPE_P (type))
{
- c_incomplete_type_error (NULL_TREE, type);
+ error_at (loc, second argument to %va_arg% is of incomplete
+ type %qT, type);
return error_mark_node;
}
+ else if (warn_cxx_compat TREE_CODE (type) == ENUMERAL_TYPE)
+warning_at (loc, OPT_Wc___compat,
+ C++ requires promoted type, not enum type, in %va_arg%);
return build_va_arg (loc, expr, type);
}
diff --git gcc/testsuite/gcc.dg/pr65901.c gcc/testsuite/gcc.dg/pr65901.c
index 8708a1e..b40eea3 100644
--- gcc/testsuite/gcc.dg/pr65901.c
+++ gcc/testsuite/gcc.dg/pr65901.c
@@ -9,8 +9,8 @@ union U;
void
foo (__builtin_va_list ap)
{
- __builtin_va_arg (ap, void); /* { dg-error invalid use of void expression
} */
- __builtin_va_arg (ap, struct S); /* { dg-error invalid use of undefined
type } */
- __builtin_va_arg (ap, enum E); /* { dg-error invalid use of undefined
type } */
- __builtin_va_arg (ap, union U); /* { dg-error invalid use of undefined
type } */
+ __builtin_va_arg (ap, void); /* { dg-error second argument to .va_arg. is
of incomplete type .void. } */
+ __builtin_va_arg (ap, struct S); /* { dg-error second argument to .va_arg.
is of incomplete type .struct S. } */
+ __builtin_va_arg (ap, enum E); /* { dg-error second argument to .va_arg.
is of incomplete type .enum E. } */
+ __builtin_va_arg (ap, union U); /* { dg-error second argument to .va_arg.
is of incomplete type .union U. } */
}
Marek
[PATCH] Use consistent naming in libstdcxx/v6/xmethods.py
Hi.
This patch splits out from the patch for 65839 the consistent naming
suggested here.
https://gcc.gnu.org/ml/libstdc++/2015-04/msg00155.html
Regression tested on amd64-linux.
Ok to commit?
2015-04-29 Doug Evans d...@google.com
Use consistent naming for value type attributes.
* python/libstdcxx/v6/xmethods.py (ArrayWorkerBase): Rename _valtype
to _val_type.
(ArraySizeWorker, ArrayEmptyWorker): Ditto.
(ArrayFrontWorker, ArrayBackWorker): Ditto.
(ArrayAtWorker, ArraySubscriptWorker): Ditto.
(DequeWorkerBase): Rename elemtype to val_type.
(ForwardListWorkerBase): Rename _elem_type to _val_type.
(ForwardListFrontWorker): Ditto. And rename elem_address to
val_address.
(ForwardListMethodsMatcher): Rename elem_type to val_type.
(VectorWorkerBase): Rename _elemtype to _val_type.
Index: xmethods.py
===
--- xmethods.py (revision 222551)
+++ xmethods.py (working copy)
@@ -29,17 +29,17 @@ class LibStdCxxXMethod(gdb.xmethod.XMethod):
# Xmethods for std::array
class ArrayWorkerBase(gdb.xmethod.XMethodWorker):
-def __init__(self, valtype, size):
-self._valtype = valtype
+def __init__(self, val_type, size):
+self._val_type = val_type
self._size = size
def null_value(self):
nullptr = gdb.parse_and_eval('(void *) 0')
-return nullptr.cast(self._valtype.pointer()).dereference()
+return nullptr.cast(self._val_type.pointer()).dereference()
class ArraySizeWorker(ArrayWorkerBase):
-def __init__(self, valtype, size):
-ArrayWorkerBase.__init__(self, valtype, size)
+def __init__(self, val_type, size):
+ArrayWorkerBase.__init__(self, val_type, size)
def get_arg_types(self):
return None
@@ -48,8 +48,8 @@ class ArraySizeWorker(ArrayWorkerBase):
return self._size
class ArrayEmptyWorker(ArrayWorkerBase):
-def __init__(self, valtype, size):
-ArrayWorkerBase.__init__(self, valtype, size)
+def __init__(self, val_type, size):
+ArrayWorkerBase.__init__(self, val_type, size)
def get_arg_types(self):
return None
@@ -58,8 +58,8 @@ class ArrayEmptyWorker(ArrayWorkerBase):
return (int(self._size) == 0)
class ArrayFrontWorker(ArrayWorkerBase):
-def __init__(self, valtype, size):
-ArrayWorkerBase.__init__(self, valtype, size)
+def __init__(self, val_type, size):
+ArrayWorkerBase.__init__(self, val_type, size)
def get_arg_types(self):
return None
@@ -71,8 +71,8 @@ class ArrayFrontWorker(ArrayWorkerBase):
return self.null_value()
class ArrayBackWorker(ArrayWorkerBase):
-def __init__(self, valtype, size):
-ArrayWorkerBase.__init__(self, valtype, size)
+def __init__(self, val_type, size):
+ArrayWorkerBase.__init__(self, val_type, size)
def get_arg_types(self):
return None
@@ -84,8 +84,8 @@ class ArrayBackWorker(ArrayWorkerBase):
return self.null_value()
class ArrayAtWorker(ArrayWorkerBase):
-def __init__(self, valtype, size):
-ArrayWorkerBase.__init__(self, valtype, size)
+def __init__(self, val_type, size):
+ArrayWorkerBase.__init__(self, val_type, size)
def get_arg_types(self):
return gdb.lookup_type('std::size_t')
@@ -97,8 +97,8 @@ class ArrayAtWorker(ArrayWorkerBase):
return obj['_M_elems'][index]
class ArraySubscriptWorker(ArrayWorkerBase):
-def __init__(self, valtype, size):
-ArrayWorkerBase.__init__(self, valtype, size)
+def __init__(self, val_type, size):
+ArrayWorkerBase.__init__(self, val_type, size)
def get_arg_types(self):
return gdb.lookup_type('std::size_t')
@@ -139,8 +139,8 @@ class ArrayMethodsMatcher(gdb.xmethod.XMethodMatch
# Xmethods for std::deque
class DequeWorkerBase(gdb.xmethod.XMethodWorker):
-def __init__(self, elemtype):
-self._bufsize = (512 / elemtype.sizeof) or 1
+def __init__(self, val_type):
+self._bufsize = (512 / val_type.sizeof) or 1
def size(self, obj):
first_node = obj['_M_impl']['_M_start']['_M_node']
@@ -232,8 +232,8 @@ class DequeMethodsMatcher(gdb.xmethod.XMethodMatch
# Xmethods for std::forward_list
class ForwardListWorkerBase(gdb.xmethod.XMethodMatcher):
-def __init__(self, elem_type, node_type):
-self._elem_type = elem_type
+def __init__(self, val_type, node_type):
+self._val_type = val_type
self._node_type = node_type
def get_arg_types(self):
@@ -246,8 +246,8 @@ class ForwardListEmptyWorker(ForwardListWorkerBase
class ForwardListFrontWorker(ForwardListWorkerBase):
def __call__(self, obj):
node = obj['_M_impl']['_M_head']['_M_next'].cast(self._node_type)
-elem_address = node['_M_storage']['_M_storage'].address
-return
[PATCH] PR ld/18355: --enable-shared doesn't work
When bfd is configured as a shared library, we need to configure zlib
with --enable-host-shared since zlib is used by bfd. Any comments,
feedbacks, objections?
H.J.
--
PR ld/18355
* Makefile.def: Add extra_configure_flags to host zlib.
* configure.ac (extra_host_zlib_configure_flags): New. Set
to --enable-host-shared When bfd is to be built as shared
library. AC_SUBST.
* Makefile.in: Regenerated.
* configure: Likewise.
---
Makefile.def | 4 +++-
Makefile.in | 20 +---
configure| 10 ++
configure.ac | 9 +
4 files changed, 35 insertions(+), 8 deletions(-)
diff --git a/Makefile.def b/Makefile.def
index 4e76450..4394188 100644
--- a/Makefile.def
+++ b/Makefile.def
@@ -104,7 +104,9 @@ host_modules= { module= readline; };
host_modules= { module= sid; };
host_modules= { module= sim; };
host_modules= { module= texinfo; no_install= true; };
-host_modules= { module= zlib; no_install=true; no_check=true; bootstrap=true;
};
+host_modules= { module= zlib; no_install=true; no_check=true;
+ bootstrap=true;
+ extra_configure_flags='@extra_host_zlib_configure_flags@';};
host_modules= { module= gdb; };
host_modules= { module= expect; };
host_modules= { module= guile; };
diff --git a/Makefile.in b/Makefile.in
index cc05f7b..8ae261f 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -26714,7 +26714,7 @@ configure-zlib:
$$s/$$module_srcdir/configure \
--srcdir=$${topdir}/$$module_srcdir \
$(HOST_CONFIGARGS) --build=${build_alias} --host=${host_alias} \
- --target=${target_alias} \
+ --target=${target_alias} @extra_host_zlib_configure_flags@ \
|| exit 1
@endif zlib
@@ -26749,7 +26749,8 @@ configure-stage1-zlib:
$(HOST_CONFIGARGS) --build=${build_alias} --host=${host_alias} \
--target=${target_alias} \
\
- $(STAGE1_CONFIGURE_FLAGS)
+ $(STAGE1_CONFIGURE_FLAGS) \
+ @extra_host_zlib_configure_flags@
@endif zlib-bootstrap
.PHONY: configure-stage2-zlib maybe-configure-stage2-zlib
@@ -26782,7 +26783,8 @@ configure-stage2-zlib:
$(HOST_CONFIGARGS) --build=${build_alias} --host=${host_alias} \
--target=${target_alias} \
--with-build-libsubdir=$(HOST_SUBDIR) \
- $(STAGE2_CONFIGURE_FLAGS)
+ $(STAGE2_CONFIGURE_FLAGS) \
+ @extra_host_zlib_configure_flags@
@endif zlib-bootstrap
.PHONY: configure-stage3-zlib maybe-configure-stage3-zlib
@@ -26815,7 +26817,8 @@ configure-stage3-zlib:
$(HOST_CONFIGARGS) --build=${build_alias} --host=${host_alias} \
--target=${target_alias} \
--with-build-libsubdir=$(HOST_SUBDIR) \
- $(STAGE3_CONFIGURE_FLAGS)
+ $(STAGE3_CONFIGURE_FLAGS) \
+ @extra_host_zlib_configure_flags@
@endif zlib-bootstrap
.PHONY: configure-stage4-zlib maybe-configure-stage4-zlib
@@ -26848,7 +26851,8 @@ configure-stage4-zlib:
$(HOST_CONFIGARGS) --build=${build_alias} --host=${host_alias} \
--target=${target_alias} \
--with-build-libsubdir=$(HOST_SUBDIR) \
- $(STAGE4_CONFIGURE_FLAGS)
+ $(STAGE4_CONFIGURE_FLAGS) \
+ @extra_host_zlib_configure_flags@
@endif zlib-bootstrap
.PHONY: configure-stageprofile-zlib maybe-configure-stageprofile-zlib
@@ -26881,7 +26885,8 @@ configure-stageprofile-zlib:
$(HOST_CONFIGARGS) --build=${build_alias} --host=${host_alias} \
--target=${target_alias} \
--with-build-libsubdir=$(HOST_SUBDIR) \
- $(STAGEprofile_CONFIGURE_FLAGS)
+ $(STAGEprofile_CONFIGURE_FLAGS) \
+ @extra_host_zlib_configure_flags@
@endif zlib-bootstrap
.PHONY: configure-stagefeedback-zlib maybe-configure-stagefeedback-zlib
@@ -26914,7 +26919,8 @@ configure-stagefeedback-zlib:
$(HOST_CONFIGARGS) --build=${build_alias} --host=${host_alias} \
--target=${target_alias} \
--with-build-libsubdir=$(HOST_SUBDIR) \
- $(STAGEfeedback_CONFIGURE_FLAGS)
+ $(STAGEfeedback_CONFIGURE_FLAGS) \
+ @extra_host_zlib_configure_flags@
@endif zlib-bootstrap
diff --git a/configure b/configure
index 97250fa..426eece 100755
--- a/configure
+++ b/configure
@@ -643,6 +643,7 @@ CXXFLAGS_FOR_TARGET
CFLAGS_FOR_TARGET
DEBUG_PREFIX_CFLAGS_FOR_TARGET
SYSROOT_CFLAGS_FOR_TARGET
+extra_host_zlib_configure_flags
extra_host_libiberty_configure_flags
stage1_languages
extra_linker_plugin_flags
@@ -6585,15 +6586,24 @@ fi
# Sometimes we have special requirements for the host libiberty.
extra_host_libiberty_configure_flags=
+extra_host_zlib_configure_flags=
case $configdirs in
* lto-plugin * | * libcc1 *)
# When these are to be built as shared libraries, the same applies to
# libiberty.
extra_host_libiberty_configure_flags=--enable-shared
;;
+ * bfd *)
+# When bfd is to be built as a shared library, the same
Re: OMP_CLAUSES with clauses in operand 0
Hi!
On Wed, 29 Apr 2015 17:28:54 +0200, Jakub Jelinek ja...@redhat.com wrote:
On Wed, Apr 29, 2015 at 05:25:39PM +0200, Thomas Schwinge wrote:
Done. (I also reverted the gcc/cp/pt.c:tsubst_expr change which
motivated this patch; will include that with the patch adding support for
C++ templates usage with OpenACC directives.) OK for trunk?
Ok, thanks.
Committed in r222580:
commit 95cfd3918aef02196f24de30a1e7cbd34e45e827
Author: tschwinge tschwinge@138bc75d-0d04-0410-961f-82ee72b054a4
Date: Wed Apr 29 15:44:41 2015 +
Add OMP_STANDALONE_CLAUSES.
gcc/
* tree.h (OMP_STANDALONE_CLAUSES): New macro.
* gimplify.c (gimplify_omp_workshare): Use it.
gcc/c/
* c-parser.c (c_parser_oacc_enter_exit_data): Use
OMP_STANDALONE_CLAUSES.
gcc/cp/
* parser.c (cp_parser_oacc_enter_exit_data): Use
OMP_STANDALONE_CLAUSES.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@222580
138bc75d-0d04-0410-961f-82ee72b054a4
---
gcc/ChangeLog|5 +
gcc/c/ChangeLog |5 +
gcc/c/c-parser.c |5 +
gcc/cp/ChangeLog |5 +
gcc/cp/parser.c |5 +
gcc/gimplify.c | 13 +
gcc/tree.h |6 ++
7 files changed, 28 insertions(+), 16 deletions(-)
diff --git gcc/ChangeLog gcc/ChangeLog
index 4fb5490..11cb62a 100644
--- gcc/ChangeLog
+++ gcc/ChangeLog
@@ -1,3 +1,8 @@
+2015-04-29 Thomas Schwinge tho...@codesourcery.com
+
+ * tree.h (OMP_STANDALONE_CLAUSES): New macro.
+ * gimplify.c (gimplify_omp_workshare): Use it.
+
2015-04-29 Richard Sandiford richard.sandif...@arm.com
* Makefile.in (build/genrecog.o): Depend on inchash.h.
diff --git gcc/c/ChangeLog gcc/c/ChangeLog
index 9c769ca..6d8dbb1 100644
--- gcc/c/ChangeLog
+++ gcc/c/ChangeLog
@@ -1,3 +1,8 @@
+2015-04-29 Thomas Schwinge tho...@codesourcery.com
+
+ * c-parser.c (c_parser_oacc_enter_exit_data): Use
+ OMP_STANDALONE_CLAUSES.
+
2015-04-28 Marek Polacek pola...@redhat.com
* c-parser.c (c_parser_binary_expression): Remove duplicate line.
diff --git gcc/c/c-parser.c gcc/c/c-parser.c
index cc8a4e3..bf0e4c57 100644
--- gcc/c/c-parser.c
+++ gcc/c/c-parser.c
@@ -12154,10 +12154,7 @@ c_parser_oacc_enter_exit_data (c_parser *parser, bool
enter)
stmt = enter ? make_node (OACC_ENTER_DATA) : make_node (OACC_EXIT_DATA);
TREE_TYPE (stmt) = void_type_node;
- if (enter)
-OACC_ENTER_DATA_CLAUSES (stmt) = clauses;
- else
-OACC_EXIT_DATA_CLAUSES (stmt) = clauses;
+ OMP_STANDALONE_CLAUSES (stmt) = clauses;
SET_EXPR_LOCATION (stmt, loc);
add_stmt (stmt);
}
diff --git gcc/cp/ChangeLog gcc/cp/ChangeLog
index 3ee050c..9442faa 100644
--- gcc/cp/ChangeLog
+++ gcc/cp/ChangeLog
@@ -1,3 +1,8 @@
+2015-04-29 Thomas Schwinge tho...@codesourcery.com
+
+ * parser.c (cp_parser_oacc_enter_exit_data): Use
+ OMP_STANDALONE_CLAUSES.
+
2015-04-29 Paolo Carlini paolo.carl...@oracle.com
PR c++/64667
diff --git gcc/cp/parser.c gcc/cp/parser.c
index 4ea2ca2..cfb512b 100644
--- gcc/cp/parser.c
+++ gcc/cp/parser.c
@@ -31606,10 +31606,7 @@ cp_parser_oacc_enter_exit_data (cp_parser *parser,
cp_token *pragma_tok,
stmt = enter ? make_node (OACC_ENTER_DATA) : make_node (OACC_EXIT_DATA);
TREE_TYPE (stmt) = void_type_node;
- if (enter)
-OACC_ENTER_DATA_CLAUSES (stmt) = clauses;
- else
-OACC_EXIT_DATA_CLAUSES (stmt) = clauses;
+ OMP_STANDALONE_CLAUSES (stmt) = clauses;
SET_EXPR_LOCATION (stmt, pragma_tok-location);
add_stmt (stmt);
return stmt;
diff --git gcc/gimplify.c gcc/gimplify.c
index 1d5341e..9ce3dd9 100644
--- gcc/gimplify.c
+++ gcc/gimplify.c
@@ -7411,34 +7411,31 @@ gimplify_omp_workshare (tree *expr_p, gimple_seq *pre_p)
static void
gimplify_omp_target_update (tree *expr_p, gimple_seq *pre_p)
{
- tree expr = *expr_p, clauses;
+ tree expr = *expr_p;
int kind;
gomp_target *stmt;
switch (TREE_CODE (expr))
{
case OACC_ENTER_DATA:
- clauses = OACC_ENTER_DATA_CLAUSES (expr);
kind = GF_OMP_TARGET_KIND_OACC_ENTER_EXIT_DATA;
break;
case OACC_EXIT_DATA:
- clauses = OACC_EXIT_DATA_CLAUSES (expr);
kind = GF_OMP_TARGET_KIND_OACC_ENTER_EXIT_DATA;
break;
case OACC_UPDATE:
- clauses = OACC_UPDATE_CLAUSES (expr);
kind = GF_OMP_TARGET_KIND_OACC_UPDATE;
break;
case OMP_TARGET_UPDATE:
- clauses = OMP_TARGET_UPDATE_CLAUSES (expr);
kind = GF_OMP_TARGET_KIND_UPDATE;
break;
default:
gcc_unreachable ();
}
- gimplify_scan_omp_clauses (clauses, pre_p, ORT_WORKSHARE);
- gimplify_adjust_omp_clauses (pre_p, clauses);
- stmt = gimple_build_omp_target (NULL, kind, clauses);
+ gimplify_scan_omp_clauses (OMP_STANDALONE_CLAUSES (expr), pre_p,
+ORT_WORKSHARE);
+ gimplify_adjust_omp_clauses (pre_p, OMP_STANDALONE_CLAUSES (expr));
+ stmt = gimple_build_omp_target (NULL, kind, OMP_STANDALONE_CLAUSES
[debug-early] adjust tests for new defined/used warnings
This fixes the remaining regressions. With the new design for
check_global_declaration*(), we diagnose many more warnings and so far,
no false positives.
Committed to branch.
commit 7aeb35184b29f3c67470b63fcf107b54f075ffd7
Author: Aldy Hernandez al...@redhat.com
Date: Wed Apr 29 09:43:48 2015 -0700
Adjust tests with defined/used warnings.
diff --git a/gcc/objc/objc-gnu-runtime-abi-01.c
b/gcc/objc/objc-gnu-runtime-abi-01.c
index b096fb9..cdf77b2 100644
--- a/gcc/objc/objc-gnu-runtime-abi-01.c
+++ b/gcc/objc/objc-gnu-runtime-abi-01.c
@@ -500,6 +500,8 @@ build_selector_table_decl (void)
temp = build_array_type (objc_selector_template, NULL_TREE);
UOBJC_SELECTOR_TABLE_decl = start_var_decl (temp, _OBJC_SELECTOR_TABLE);
+ /* Squash `defined but not used' warning check_global_declaration. */
+ TREE_USED (UOBJC_SELECTOR_TABLE_decl) = 1;
OBJCMETA (UOBJC_SELECTOR_TABLE_decl, objc_meta, meta_base);
}
diff --git a/gcc/testsuite/g++.dg/torture/pr46383.C
b/gcc/testsuite/g++.dg/torture/pr46383.C
index 2b61039..e4810c5 100644
--- a/gcc/testsuite/g++.dg/torture/pr46383.C
+++ b/gcc/testsuite/g++.dg/torture/pr46383.C
@@ -69,9 +69,9 @@ template class Tr, class Derived, class Element, class
Previous, class Triangu
Mesher_level(Previous_level previous)
: previous_level(previous)
{ }
- Vertex_handle insert(Point p, Zone z) ;
- Zone conflicts_zone(const Point p, Element e) ;
- Element get_next_element() ;
+ Vertex_handle insert(Point p, Zone z) ; // { dg-warning used but never
defined }
+ Zone conflicts_zone(const Point p, Element e) ; // { dg-warning used but
never defined }
+ Element get_next_element() ; // { dg-warning used but never defined }
template class Mesh_visitor void before_insertion(Element e, const Point
p, Zone zone, Mesh_visitor visitor) {
visitor.before_insertion(e, p, zone);
}
@@ -171,7 +171,7 @@ template typename Tr struct
Triangulation_mesher_level_traits_3
tr.is_infinite(f) ;
new_facetfalse(f);
}
-template bool remove_from_complex_if_not_in_restricted_Delaunay void
new_facet (const Facet f) ;
+template bool remove_from_complex_if_not_in_restricted_Delaunay void
new_facet (const Facet f) ; // { dg-warning used but never defined }
void after_insertion_handle_opposite_facet (const Facet f) {
after_insertion_handle_incident_facet (f);
}
diff --git a/gcc/testsuite/gfortran.dg/intent_out_8.f90
b/gcc/testsuite/gfortran.dg/intent_out_8.f90
index 674d833..6360314 100644
--- a/gcc/testsuite/gfortran.dg/intent_out_8.f90
+++ b/gcc/testsuite/gfortran.dg/intent_out_8.f90
@@ -10,7 +10,7 @@ end type t
contains
- subroutine foo(x)
+ subroutine foo(x) ! { dg-warning defined but not used }
type(t), intent(out) :: x
end subroutine
diff --git a/gcc/testsuite/gfortran.dg/warn_target_lifetime_3.f90
b/gcc/testsuite/gfortran.dg/warn_target_lifetime_3.f90
index 9113a88..749f987 100644
--- a/gcc/testsuite/gfortran.dg/warn_target_lifetime_3.f90
+++ b/gcc/testsuite/gfortran.dg/warn_target_lifetime_3.f90
@@ -10,7 +10,7 @@ subroutine test
integer, target :: t
p = t
contains
- subroutine sub()
+ subroutine sub() ! { dg-warning defined but not used }
if (p /= 0) return
end subroutine
end subroutine
@@ -22,7 +22,7 @@ contains
integer, target :: t2
p2 = t2 ! { dg-warning Pointer at .1. in pointer assignment might
outlive the pointer target }
contains
-subroutine sub()
+subroutine sub() ! { dg-warning defined but not used }
if (p2 /= 0) return
end subroutine
end subroutine
diff --git a/gcc/toplev.c b/gcc/toplev.c
index 43e1577..3155595 100644
--- a/gcc/toplev.c
+++ b/gcc/toplev.c
@@ -505,6 +505,8 @@ wrapup_global_declarations (tree *vec, int len)
void
check_global_declaration (tree decl)
{
+ // ?? Perhaps we should avoid all DECL_ARTIFICIALs here?
+
/* Warn about any function declared static but not defined. We don't
warn about variables, because many programs have static variables
that exist only to get some text into the object file. */
Re: [PATCH] Fix size type for cold partition names (hot-cold function partitioning)
Hello! 2015-03-27 Caroline Tice cmt...@google.com * final.c (final_scan_insn): Change 'cold_function_name' to 'cold_partition_name' and make it a global variable; also output assembly to give it a 'FUNC' type, if appropriate. * varasm.c (cold_partition_name): Declare and initialize global variable. (assemble_start_function): Re-set value for cold_partition_name. (assemble_end_function): Output assembly to calculate size of cold partition, and associate size with name, if appropriate. * varash.h (cold_partition_name): Add extern declaration for global variable. * testsuite/gcc.dg/tree-prof/cold_partition_label.c: Add dg-final-use to scan assembly for cold partition name and size. This patch caused PR 65929 [1]. Targets are (ab)using ASM_DECLARE_FUNCTION_NAME and ASM_DECLARE_FUNCTION_SIZE for more things that their name suggests. As shown in the PR, some directives that are generated through these macros apply only to real functions, not to parts of function in the middle of the function. In the particular case in the PR, assembler doesn't tolerate nested function declaration. I suggest to revert the patch for now, until side effects of the patch are resolved. [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65929 Uros.
Re: [PATCH] libstdc++: Fix list.cc xmethods test.
On Mon, Apr 27, 2015 at 3:41 PM, Jonathan Wakely jwakely@gmail.com wrote: On 27 April 2015 at 23:33, Doug Evans wrote: Hi. While we should eventually get the xmethods to handle cxx11, this patch fixes the current failure. The xmethod matcher doesn't currently handle __cxx11 in the type name. Adding cxx11 support can be a follow up patch. Agreed. And when that's done we should backport it to the gcc-5-branch too. Ok to commit? OK for trunk, thanks Tested the same patch on the gcc 5.0 branch. Just double checking ... ok to apply there too? btw, the test is currently marked as unsupported by the test run. I don't know what would be involved in marking it as failing instead, but I noticed this happening a lot while I was working with this code. I can imagine more failures going unnoticed because of this.
Re: [PATCH] libstdc++: Fix list.cc xmethods test.
On 29 April 2015 at 17:04, Doug Evans wrote: Tested the same patch on the gcc 5.0 branch. Just double checking ... ok to apply there too? Yes, OK for the branch too. btw, the test is currently marked as unsupported by the test run. I don't know what would be involved in marking it as failing instead, but I noticed this happening a lot while I was working with this code. I can imagine more failures going unnoticed because of this. That's due to: (*): Shared library is missing debugging information.^M skipping: (*): Shared library is missing debugging information.^M list.gdb:10: Error in sourced command file:^M Cannot evaluate function -- may be inlined^M skipping: list.gdb:10: Error in sourced command file:^M skipping: Cannot evaluate function -- may be inlined^M UNSUPPORTED: libstdc++-xmethods/list.cc But I can't say anything more useful than that.
Re: OMP_CLAUSES with clauses in operand 0
Hi Jakub!
On Wed, 29 Apr 2015 16:36:24 +0200, Jakub Jelinek ja...@redhat.com wrote:
On Wed, Apr 29, 2015 at 04:31:32PM +0200, Thomas Schwinge wrote:
So yes, I really prefer OMP_STANDALONE_CLAUSES over OMP_CLAUSES for
everything.
Like this (for trunk)?
commit 300e28fce192cb56d73cb61f787872643030f0bf
Author: Thomas Schwinge tho...@codesourcery.com
Date: Wed Apr 29 16:18:49 2015 +0200
Add OMP_STANDALONE_CLAUSES.
gcc/
* tree.h (OACC_CACHE_CLAUSES, OACC_DECLARE_CLAUSES)
(OACC_ENTER_DATA_CLAUSES, OACC_EXIT_DATA_CLAUSES)
(OACC_UPDATE_CLAUSES, OMP_TARGET_UPDATE_CLAUSES): Merge into...
(OMP_STANDALONE_CLAUSES): ... this new macro. Adjust all users.
I would keep the specific *_CLAUSES macros, just add
OMP_STANDALONE_CLAUSES and change the uses only if you are dealing with
multiple different codes. That will match OMP_CLAUSES vs. OMP_FOR_CLAUSES,
OMP_PARALLEL_CLAUSES etc.
My (non-explicit) rationale has been:
--- gcc/c/c-parser.c
+++ gcc/c/c-parser.c
@@ -11987,7 +11987,7 @@ c_parser_oacc_cache (location_t loc, c_parser
*parser)
stmt = make_node (OACC_CACHE);
We have just created a OACC_CACHE node here...
TREE_TYPE (stmt) = void_type_node;
- OACC_CACHE_CLAUSES (stmt) = clauses;
+ OMP_STANDALONE_CLAUSES (stmt) = clauses;
..., so there is no point in checking here that we're indeed dealing
specifically with an OACC_CACHE node.
So, drop hunks like this.
@@ -12155,10 +12155,7 @@ c_parser_oacc_enter_exit_data (c_parser *parser,
bool enter)
stmt = enter ? make_node (OACC_ENTER_DATA) : make_node (OACC_EXIT_DATA);
TREE_TYPE (stmt) = void_type_node;
- if (enter)
-OACC_ENTER_DATA_CLAUSES (stmt) = clauses;
- else
-OACC_EXIT_DATA_CLAUSES (stmt) = clauses;
+ OMP_STANDALONE_CLAUSES (stmt) = clauses;
SET_EXPR_LOCATION (stmt, loc);
add_stmt (stmt);
}
And just keep ones like this.
Done. (I also reverted the gcc/cp/pt.c:tsubst_expr change which
motivated this patch; will include that with the patch adding support for
C++ templates usage with OpenACC directives.) OK for trunk?
commit 82e588b6d62f9e7254e76a3dfcc46efceb2075a5
Author: Thomas Schwinge tho...@codesourcery.com
Date: Wed Apr 29 17:08:17 2015 +0200
Add OMP_STANDALONE_CLAUSES.
gcc/
* tree.h (OMP_STANDALONE_CLAUSES): New macro.
* gimplify.c (gimplify_omp_workshare): Use it.
gcc/c/
* c-parser.c (c_parser_oacc_enter_exit_data): Use
OMP_STANDALONE_CLAUSES.
gcc/cp/
* parser.c (cp_parser_oacc_enter_exit_data): Use
OMP_STANDALONE_CLAUSES.
---
gcc/c/c-parser.c |5 +
gcc/cp/parser.c |5 +
gcc/gimplify.c | 13 +
gcc/tree.h |6 ++
4 files changed, 13 insertions(+), 16 deletions(-)
diff --git gcc/c/c-parser.c gcc/c/c-parser.c
index f5e2ac2c..015de7f 100644
--- gcc/c/c-parser.c
+++ gcc/c/c-parser.c
@@ -12155,10 +12155,7 @@ c_parser_oacc_enter_exit_data (c_parser *parser, bool
enter)
stmt = enter ? make_node (OACC_ENTER_DATA) : make_node (OACC_EXIT_DATA);
TREE_TYPE (stmt) = void_type_node;
- if (enter)
-OACC_ENTER_DATA_CLAUSES (stmt) = clauses;
- else
-OACC_EXIT_DATA_CLAUSES (stmt) = clauses;
+ OMP_STANDALONE_CLAUSES (stmt) = clauses;
SET_EXPR_LOCATION (stmt, loc);
add_stmt (stmt);
}
diff --git gcc/cp/parser.c gcc/cp/parser.c
index 4ea2ca2..cfb512b 100644
--- gcc/cp/parser.c
+++ gcc/cp/parser.c
@@ -31606,10 +31606,7 @@ cp_parser_oacc_enter_exit_data (cp_parser *parser,
cp_token *pragma_tok,
stmt = enter ? make_node (OACC_ENTER_DATA) : make_node (OACC_EXIT_DATA);
TREE_TYPE (stmt) = void_type_node;
- if (enter)
-OACC_ENTER_DATA_CLAUSES (stmt) = clauses;
- else
-OACC_EXIT_DATA_CLAUSES (stmt) = clauses;
+ OMP_STANDALONE_CLAUSES (stmt) = clauses;
SET_EXPR_LOCATION (stmt, pragma_tok-location);
add_stmt (stmt);
return stmt;
diff --git gcc/gimplify.c gcc/gimplify.c
index c68bd47..bda62ce 100644
--- gcc/gimplify.c
+++ gcc/gimplify.c
@@ -7427,34 +7427,31 @@ gimplify_omp_workshare (tree *expr_p, gimple_seq *pre_p)
static void
gimplify_omp_target_update (tree *expr_p, gimple_seq *pre_p)
{
- tree expr = *expr_p, clauses;
+ tree expr = *expr_p;
int kind;
gomp_target *stmt;
switch (TREE_CODE (expr))
{
case OACC_ENTER_DATA:
- clauses = OACC_ENTER_DATA_CLAUSES (expr);
kind = GF_OMP_TARGET_KIND_OACC_ENTER_EXIT_DATA;
break;
case OACC_EXIT_DATA:
- clauses = OACC_EXIT_DATA_CLAUSES (expr);
kind = GF_OMP_TARGET_KIND_OACC_ENTER_EXIT_DATA;
break;
case OACC_UPDATE:
- clauses = OACC_UPDATE_CLAUSES (expr);
kind = GF_OMP_TARGET_KIND_OACC_UPDATE;
break;
case OMP_TARGET_UPDATE:
- clauses = OMP_TARGET_UPDATE_CLAUSES (expr);
kind = GF_OMP_TARGET_KIND_UPDATE;
break;
default:
gcc_unreachable ();
}
Re: [PATCH] Tidy up locking for libgomp OpenACC entry points
Hi Julian! On Fri, 24 Apr 2015 18:13:08 +0100, Julian Brown jul...@codesourcery.com wrote: On Thu, 23 Apr 2015 18:41:34 +0200 Thomas Schwinge tho...@codesourcery.com wrote: On Wed, 22 Apr 2015 19:42:43 +0100, Julian Brown jul...@codesourcery.com wrote: This patch is an attempt to fix some potential race conditions with accesses to shared data structures from multiple concurrent threads in libgomp's OpenACC entry points. Tests look OK (with offloading to NVidia PTX). How did you test to get some confidence in the locking being sufficient? Merely by running the existing tests and via inspection, sadly. I'm not sure how much value we'd get from implementing an exhaustive threading testsuite at this stage: I guess testcases will be easier to come by in the future if/when people start to use e.g. OpenMP and OpenACC together. ;-) The poor person to be the first to actually exercise all that code... Thanks for your explanations and the rework. Re-tested (libgomp), results look OK. OK to apply now? OK, thanks! Grüße, Thomas pgp6oCMUj9Siy.pgp Description: PGP signature
Re: [RFC]: Remove Mem/address type assumption in combiner
On 04/29/2015 11:03 AM, Segher Boessenkool wrote: Right. It would be good if you could find out for what targets it matters. The thing is, if a target expects only the patterns as combine used to make them, it will regress (as you've seen on aarch64); but it will regress _silently_. Which isn't so nice. But before that I wanted to check if the assumption in combiner, can simply be removed ? Seeing for what targets / patterns it makes a difference would tell us the answer to that, too :-) Right. ANd that was one of the two general directions I recommended earlier this week ;-) 1. Figure out if this code still matters at all. 2. If the code still matters, accurately track if we're inside a MEM so that things canonicalize correctly. jeff
Re: [PATCH, i386]: Fix PR 65871, bzhi builtin/intrinsic wrongly assumes bzhi instruction doesn't set the ZF flag
On Wed, Apr 29, 2015 at 09:02:16PM +0200, Uros Bizjak wrote:
Hello!
Attached patch implements a CCZ-only setting pattern for a couple of
BMI[,2] intrinsics.
What about the case when the result is used, but also tested for zero or
non-zero? Like e.g.
int bar (void);
int foo (unsigned int x, unsigned int y)
{
int v = __builtin_ia32_bextr_u32 (x, y);
if (v)
return v;
return bar ();
}
Jakub
Re: [PATCH, i386]: Fix PR 65871, bzhi builtin/intrinsic wrongly assumes bzhi instruction doesn't set the ZF flag
On Wed, Apr 29, 2015 at 9:23 PM, Jakub Jelinek ja...@redhat.com wrote:
On Wed, Apr 29, 2015 at 09:02:16PM +0200, Uros Bizjak wrote:
Hello!
Attached patch implements a CCZ-only setting pattern for a couple of
BMI[,2] intrinsics.
What about the case when the result is used, but also tested for zero or
non-zero? Like e.g.
int bar (void);
int foo (unsigned int x, unsigned int y)
{
int v = __builtin_ia32_bextr_u32 (x, y);
if (v)
return v;
return bar ();
}
Yes, I have considered this usage, but it would require *another*
pattern. I don't think it is worth just to have one test insn less...
Uros.
Re: [RFC]: Remove Mem/address type assumption in combiner
On 04/29/2015 03:25 AM, Kumar, Venkataramanan wrote: Hi Jeff/Segher, When we see an RTX code with PLUS or MINUS then it is treated as MEM/address type (we are inside address RTX). Is there any significance on that assumption? I removed this assumption and the test case in the PR 63949 passed. When appearing inside a MEM, we have different canonicalization rules. The comment in make_compound_operation clearly indicates that the PLUS/MINUS support is a hack. However, I'm pretty sure it was strictly for getting better code than for correctness. One path forward is to properly track if we're in a MEM, at which point the hack for PLUS/MINUS could probably just go away. diff --git a/gcc/combine.c b/gcc/combine.c index 5c763b4..945abdb 100644 --- a/gcc/combine.c +++ b/gcc/combine.c @@ -7703,8 +7703,6 @@ make_compound_operation (rtx x, enum rtx_code in_code) but once inside, go back to our default of SET. */ next_code = (code == MEM ? MEM - : ((code == PLUS || code == MINUS) - SCALAR_INT_MODE_P (mode)) ? MEM : ((code == COMPARE || COMPARISON_P (x)) XEXP (x, 1) == const0_rtx) ? COMPARE : in_code == COMPARE ? SET : in_code); On X86_64, it passes bootstrap and regression tests. But on Aarch64 the test in PR passed, but I got a few test case failures. Tests that now fail, but worked before: gcc.target/aarch64/adds1.c scan-assembler adds\tw[0-9]+, w[0-9]+, w[0-9]+, lsl 3 gcc.target/aarch64/adds1.c scan-assembler adds\tx[0-9]+, x[0-9]+, x[0-9]+, lsl 3 So that test seems to want to verify that you can generate a shift-add type instruction. I suspect the others are similar. I'd be curious to see the .combine dump as well as the final assembly for this test. Which is a strong hint that we should be looking at target with shift-add style instructions. ARM, AArch64, HPPA, x86 come immediately to mind. There are few patterns based on multiplication operations in Aarch64 backend which are used to match with the pattern combiner generated. Now those patterns have to be fixed to use SHIFTS. Also need to see any impact on other targets. But before that I wanted to check if the assumption in combiner, can simply be removed ? Given what I'm seeing now, I doubt it can simply be removed at this point (which is a change in my position) since ports with these shift-add style instructions have probably been tuned to work with existing combine behaviour. We may need to do a deep test across various targets to identify those affected and fix them. jeff
Re: [patch] Rewrite check_global_declarations() generically
On 04/28/2015 09:01 PM, Aldy Hernandez wrote: The approach looks good to me. - analyze_functions (); + analyze_functions (true); In the C++ front end at least we comment anonymous boolean arguments, i.e. analyze_functions (/*first_time*/true); Let's do that here, too. Similarly for the calls to referred_to_p (false). + /* ?? Why are we looking at TREE_USED? Shouldn't the call to +referred_to_p above be enough? Apparently not, because the +`__unused__' attribute is not being considered for +referred_to_p. */ Seems like you answered your question. :) + /* Global ctors and dtors are called by the runtime. */ + (TREE_CODE (decl) != FUNCTION_DECL + || (!DECL_STATIC_CONSTRUCTOR (decl) + !DECL_STATIC_DESTRUCTOR (decl))) Maybe check snode-needed_p instead? Jason
Re: [PATCH] Use consistent naming in libstdcxx/v6/xmethods.py
On 29/04/15 09:49 -0700, Doug Evans wrote: Hi. This patch splits out from the patch for 65839 the consistent naming suggested here. https://gcc.gnu.org/ml/libstdc++/2015-04/msg00155.html Regression tested on amd64-linux. Ok to commit? Thanks for doing this, OK to commit.
Re: [PATCH] Fix size type for cold partition names (hot-cold function partitioning)
Thank you; I will work with your suggestions and try to get a new patch done soon. -- Caroline Tice cmt...@google.com On Wed, Apr 29, 2015 at 11:34 AM, Uros Bizjak ubiz...@gmail.com wrote: On Wed, Apr 29, 2015 at 7:47 PM, Uros Bizjak ubiz...@gmail.com wrote: On Wed, Apr 29, 2015 at 7:38 PM, Caroline Tice cmt...@google.com wrote: The attached patch can revert the previous patch, if that is the way we should proceed on this. If you want me to apply the reversion, please let me know. I would be happy to fix to the problem, rather than just reverting the patch, but I do not have expertise in assembly language on other platforms, so I would need some help, if anyone would be interested in helping me? How about adding ASM_DECLARE_COLD_FUNCTION_NAME and ASM_DECLARE_COLD_FUNCTION_SIZE? If these are defined, they can be used instead, and targets are free to define them in any way. Something like the attached prototype RFC patch. Using this patch, readelf -sW returns: Symbol table '.symtab' contains 18 entries: Num:Value Size TypeBind Vis Ndx Name 0: 0 NOTYPE LOCAL DEFAULT UND 1: 0 SECTION LOCAL DEFAULT1 2: 0 SECTION LOCAL DEFAULT3 3: 0 SECTION LOCAL DEFAULT4 4: 0 SECTION LOCAL DEFAULT5 5: 0 SECTION LOCAL DEFAULT6 6: 0 SECTION LOCAL DEFAULT8 7: 8 FUNCLOCAL DEFAULT6 main.cold.0 8: 0 SECTION LOCAL DEFAULT 10 9: 0 SECTION LOCAL DEFAULT 13 10: 0 SECTION LOCAL DEFAULT 12 11: 312 FUNCGLOBAL DEFAULT [other: 88] 8 main 12: 0008 160 OBJECT GLOBAL DEFAULT COM buf 13: 0 NOTYPE GLOBAL DEFAULT UND memset 14: 44 FUNCGLOBAL DEFAULT [other: 88] 1 sub2 15: 0 NOTYPE GLOBAL DEFAULT UND strcmp 16: 0 NOTYPE GLOBAL DEFAULT UND exit 17: 0 NOTYPE GLOBAL DEFAULT UND abort Uros.
Re: [PATCH] Fix size type for cold partition names (hot-cold function partitioning)
On Wed, Apr 29, 2015 at 7:38 PM, Caroline Tice cmt...@google.com wrote: The attached patch can revert the previous patch, if that is the way we should proceed on this. If you want me to apply the reversion, please let me know. I would be happy to fix to the problem, rather than just reverting the patch, but I do not have expertise in assembly language on other platforms, so I would need some help, if anyone would be interested in helping me? How about adding ASM_DECLARE_COLD_FUNCTION_NAME and ASM_DECLARE_COLD_FUNCTION_SIZE? If these are defined, they can be used instead, and targets are free to define them in any way. Uros.
Re: [PATCH] [libstdc++/65839] whatis support for xmethods
On Tue, Apr 28, 2015 at 5:16 AM, Jonathan Wakely jwak...@redhat.com wrote:
On 27/04/15 15:44 -0700, Doug Evans wrote:
PR libstdc++/65839
* python/libstdcxx/v6/xmethods.py (get_bool_type): New function.
Replace all lookups of bool with this.
(get_std_size_type): New function. Replace all lookups of
std::size_t
with this.
(ArrayWorkerBase): Rename arg valtype to elem_type for
consistency,
I'd say ArrayWorkerBase's _valtype is correct and deque and vector are
wrong to use _elemtype.
C++ containers use value_type for the type of the container objects.
Smart pointers use element_type for the type of the owned object. So
using _valtype for containers and _elemtype for unique_ptr would be
consistent with the C++ library types.
Hi.
Here's v2.
It's assumes the naming cleanup patch has been applied.
https://gcc.gnu.org/ml/libstdc++/2015-04/msg00183.html
Regression tested on amd64-linux.
2015-04-29 Doug Evans d...@google.com
PR libstdc++/65839
* python/libstdcxx/v6/xmethods.py (get_bool_type): New function.
Replace all lookups of bool with this.
(get_std_size_type): New function. Replace all lookups of std::size_t
with this.
(*Worker): New method get_result_type.
(DequeWorkerBase.__init__): New arg val_type. All callers updated.
(ListWorkerBase.__init__): New arg val_type. All callers updated.
(UniquePtrGetWorker.__init__): New arg elem_type. All callers updated.
Delete setting of name, enabled.
(UniquePtrDerefWorker.__init__): New arg elem_type. All callers
updated. Delete setting of name.
(UniquePtrMethodsMatcher): Rewrite for consistency with all other
libstdc++ xmethod matchers.
* testsuite/libstdc++-xmethods/array.cc: Add whatis tests.
* testsuite/libstdc++-xmethods/associative-containers.cc: Ditto.
* testsuite/libstdc++-xmethods/deque.cc: Ditto.
* testsuite/libstdc++-xmethods/forwardlist.cc: Ditto.
* testsuite/libstdc++-xmethods/list.cc: Ditto.
* testsuite/libstdc++-xmethods/unique_ptr.cc: Ditto.
* testsuite/libstdc++-xmethods/vector.cc: Ditto.
Index: python/libstdcxx/v6/xmethods.py
===
--- python/libstdcxx/v6/xmethods.py
+++ python/libstdcxx/v6/xmethods.py
@@ -21,6 +21,12 @@ import re
matcher_name_prefix = 'libstdc++::'
+def get_bool_type():
+return gdb.lookup_type('bool')
+
+def get_std_size_type():
+return gdb.lookup_type('std::size_t')
+
class LibStdCxxXMethod(gdb.xmethod.XMethod):
def __init__(self, name, worker_class):
gdb.xmethod.XMethod.__init__(self, name)
@@ -44,6 +50,9 @@ class ArraySizeWorker(ArrayWorkerBase):
def get_arg_types(self):
return None
+def get_result_type(self, obj):
+return get_std_size_type()
+
def __call__(self, obj):
return self._size
@@ -54,6 +63,9 @@ class ArrayEmptyWorker(ArrayWorkerBase):
def get_arg_types(self):
return None
+def get_result_type(self, obj):
+return get_bool_type()
+
def __call__(self, obj):
return (int(self._size) == 0)
@@ -64,6 +76,9 @@ class ArrayFrontWorker(ArrayWorkerBase):
def get_arg_types(self):
return None
+def get_result_type(self, obj):
+return self._val_type
+
def __call__(self, obj):
if int(self._size) 0:
return obj['_M_elems'][0]
@@ -77,6 +92,9 @@ class ArrayBackWorker(ArrayWorkerBase):
def get_arg_types(self):
return None
+def get_result_type(self, obj):
+return self._val_type
+
def __call__(self, obj):
if int(self._size) 0:
return obj['_M_elems'][self._size - 1]
@@ -88,7 +106,10 @@ class ArrayAtWorker(ArrayWorkerBase):
ArrayWorkerBase.__init__(self, val_type, size)
def get_arg_types(self):
-return gdb.lookup_type('std::size_t')
+return get_std_size_type()
+
+def get_result_type(self, obj, index):
+return self._val_type
def __call__(self, obj, index):
if int(index) = int(self._size):
@@ -101,7 +122,10 @@ class ArraySubscriptWorker(ArrayWorkerBa
ArrayWorkerBase.__init__(self, val_type, size)
def get_arg_types(self):
-return gdb.lookup_type('std::size_t')
+return get_std_size_type()
+
+def get_result_type(self, obj, index):
+return self._val_type
def __call__(self, obj, index):
if int(self._size) 0:
@@ -140,6 +164,7 @@ class ArrayMethodsMatcher(gdb.xmethod.XM
class DequeWorkerBase(gdb.xmethod.XMethodWorker):
def __init__(self, val_type):
+self._val_type = val_type
self._bufsize = (512 / val_type.sizeof) or 1
def size(self, obj):
@@ -158,6 +183,9 @@ class DequeEmptyWorker(DequeWorkerBase):
def get_arg_types(self):
return None
+def get_result_type(self,
Contents of PO file 'cpplib-5.1.0.sv.po'
cpplib-5.1.0.sv.po.gz Description: Binary data The Translation Project robot, in the name of your translation coordinator. coordina...@translationproject.org
[C PATCH] c_incomplete_type_error TLC
This patch cleans up c_incomplete_type_error a bit: today, we should prefer
using %qT over %%s %E% (the code is largely intact since 1992), and second,
we should print the type if we can. The invalid use of incomplete typedef
error wasn't tested at all, so I'm also adding a test to exercise that code
path.
Bootstrapped/regtested on x86_64-linux, ok for trunk?
2015-04-29 Marek Polacek pola...@redhat.com
* c-typeck.c (c_incomplete_type_error): Refactor to use %qT. Print
the type of a decl.
* gcc.dg/incomplete-typedef-1.c: New test.
diff --git gcc/c/c-typeck.c gcc/c/c-typeck.c
index c58e918..cc4acf7 100644
--- gcc/c/c-typeck.c
+++ gcc/c/c-typeck.c
@@ -229,15 +229,13 @@ require_complete_type (tree value)
void
c_incomplete_type_error (const_tree value, const_tree type)
{
- const char *type_code_string;
-
/* Avoid duplicate error message. */
if (TREE_CODE (type) == ERROR_MARK)
return;
if (value != 0 (TREE_CODE (value) == VAR_DECL
|| TREE_CODE (value) == PARM_DECL))
-error (%qD has an incomplete type, value);
+error (%qD has an incomplete type %qT, value, type);
else
{
retry:
@@ -246,15 +244,8 @@ c_incomplete_type_error (const_tree value, const_tree type)
switch (TREE_CODE (type))
{
case RECORD_TYPE:
- type_code_string = struct;
- break;
-
case UNION_TYPE:
- type_code_string = union;
- break;
-
case ENUMERAL_TYPE:
- type_code_string = enum;
break;
case VOID_TYPE:
@@ -280,11 +271,10 @@ c_incomplete_type_error (const_tree value, const_tree
type)
}
if (TREE_CODE (TYPE_NAME (type)) == IDENTIFIER_NODE)
- error (invalid use of undefined type %%s %E%,
- type_code_string, TYPE_NAME (type));
+ error (invalid use of undefined type %qT, type);
else
/* If this type has a typedef-name, the TYPE_NAME is a TYPE_DECL. */
- error (invalid use of incomplete typedef %qD, TYPE_NAME (type));
+ error (invalid use of incomplete typedef %qT, type);
}
}
diff --git gcc/testsuite/gcc.dg/incomplete-typedef-1.c
gcc/testsuite/gcc.dg/incomplete-typedef-1.c
index e69de29..622bf65 100644
--- gcc/testsuite/gcc.dg/incomplete-typedef-1.c
+++ gcc/testsuite/gcc.dg/incomplete-typedef-1.c
@@ -0,0 +1,12 @@
+/* { dg-do compile } */
+/* { dg-options } */
+
+typedef struct S TS;
+typedef union U TU;
+
+void
+foo (void)
+{
+ (TS) { }; /* { dg-error invalid use of incomplete typedef } */
+ (TU) { }; /* { dg-error invalid use of incomplete typedef } */
+}
Marek
Re: [PATCH] Fix size type for cold partition names (hot-cold function partitioning)
On Wed, Apr 29, 2015 at 7:47 PM, Uros Bizjak ubiz...@gmail.com wrote:
On Wed, Apr 29, 2015 at 7:38 PM, Caroline Tice cmt...@google.com wrote:
The attached patch can revert the previous patch, if that is the way
we should proceed on this. If you want me to apply the reversion,
please let me know.
I would be happy to fix to the problem, rather than just reverting the
patch, but I do not have expertise in assembly language on other
platforms, so I would need some help, if anyone would be interested in
helping me?
How about adding ASM_DECLARE_COLD_FUNCTION_NAME and
ASM_DECLARE_COLD_FUNCTION_SIZE? If these are defined, they can be used
instead, and targets are free to define them in any way.
Something like the attached prototype RFC patch. Using this patch,
readelf -sW returns:
Symbol table '.symtab' contains 18 entries:
Num:Value Size TypeBind Vis Ndx Name
0: 0 NOTYPE LOCAL DEFAULT UND
1: 0 SECTION LOCAL DEFAULT1
2: 0 SECTION LOCAL DEFAULT3
3: 0 SECTION LOCAL DEFAULT4
4: 0 SECTION LOCAL DEFAULT5
5: 0 SECTION LOCAL DEFAULT6
6: 0 SECTION LOCAL DEFAULT8
7: 8 FUNCLOCAL DEFAULT6 main.cold.0
8: 0 SECTION LOCAL DEFAULT 10
9: 0 SECTION LOCAL DEFAULT 13
10: 0 SECTION LOCAL DEFAULT 12
11: 312 FUNCGLOBAL DEFAULT [other: 88] 8 main
12: 0008 160 OBJECT GLOBAL DEFAULT COM buf
13: 0 NOTYPE GLOBAL DEFAULT UND memset
14: 44 FUNCGLOBAL DEFAULT [other: 88] 1 sub2
15: 0 NOTYPE GLOBAL DEFAULT UND strcmp
16: 0 NOTYPE GLOBAL DEFAULT UND exit
17: 0 NOTYPE GLOBAL DEFAULT UND abort
Uros.
Index: config/elfos.h
===
--- config/elfos.h (revision 222585)
+++ config/elfos.h (working copy)
@@ -284,6 +284,17 @@ see the files COPYING3 and COPYING.RUNTIME respect
while (0)
#endif
+#ifndef ASM_DECLARE_COLD_FUNCTION_NAME
+#define ASM_DECLARE_COLD_FUNCTION_NAME(FILE, NAME, DECL) \
+ do \
+{ \
+ ASM_OUTPUT_TYPE_DIRECTIVE (FILE, NAME, function); \
+ ASM_DECLARE_RESULT (FILE, DECL_RESULT (DECL)); \
+ ASM_OUTPUT_FUNCTION_LABEL (FILE, NAME, DECL);\
+} \
+ while (0)
+#endif
+
/* Write the extra assembler code needed to declare an object properly. */
#ifdef HAVE_GAS_GNU_UNIQUE_OBJECT
@@ -358,6 +369,16 @@ see the files COPYING3 and COPYING.RUNTIME respect
while (0)
#endif
+#ifndef ASM_DECLARE_COLD_FUNCTION_SIZE
+#define ASM_DECLARE_COLD_FUNCTION_SIZE(FILE, FNAME, DECL) \
+ do \
+{ \
+ if (!flag_inhibit_size_directive)\
+ ASM_OUTPUT_MEASURED_SIZE (FILE, FNAME); \
+} \
+ while (0)
+#endif
+
/* A table of bytes codes used by the ASM_OUTPUT_ASCII and
ASM_OUTPUT_LIMITED_STRING macros. Each byte in the table
corresponds to a particular byte value [0..255]. For any
Index: final.c
===
--- final.c (revision 222585)
+++ final.c (working copy)
@@ -2235,10 +2235,10 @@ final_scan_insn (rtx_insn *insn, FILE *file, int o
{
cold_function_name
= clone_function_name (current_function_decl, cold);
-#ifdef ASM_DECLARE_FUNCTION_NAME
- ASM_DECLARE_FUNCTION_NAME (asm_out_file,
-IDENTIFIER_POINTER
(cold_function_name),
-current_function_decl);
+#ifdef ASM_DECLARE_COLD_FUNCTION_NAME
+ ASM_DECLARE_COLD_FUNCTION_NAME
+ (asm_out_file, IDENTIFIER_POINTER (cold_function_name),
+current_function_decl);
#else
ASM_OUTPUT_LABEL (asm_out_file,
IDENTIFIER_POINTER (cold_function_name));
Index: varasm.c
===
--- varasm.c(revision 222585)
+++ varasm.c(working copy)
@@ -1864,11 +1864,10 @@ assemble_end_function (tree decl, const char *fnna
save_text_section = in_section;
switch_to_section (unlikely_text_section ());
-#ifdef ASM_DECLARE_FUNCTION_SIZE
+#ifdef ASM_DECLARE_COLD_FUNCTION_SIZE
New Swedish PO file for 'cpplib' (version 5.1.0)
Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'cpplib' has been submitted by the Swedish team of translators. The file is available at: http://translationproject.org/latest/cpplib/sv.po (This file, 'cpplib-5.1.0.sv.po', has just now been sent to you in a separate email.) All other PO files for your package are available in: http://translationproject.org/latest/cpplib/ Please consider including all of these in your next release, whether official or a pretest. Whenever you have a new distribution with a new version number ready, containing a newer POT file, please send the URL of that distribution tarball to the address below. The tarball may be just a pretest or a snapshot, it does not even have to compile. It is just used by the translators when they need some extra translation context. The following HTML page has been updated: http://translationproject.org/domain/cpplib.html If any question arises, please contact the translation coordinator. Thank you for all your work, The Translation Project robot, in the name of your translation coordinator. coordina...@translationproject.org
Re: [PATCH] Fix size type for cold partition names (hot-cold function partitioning)
The attached patch can revert the previous patch, if that is the way
we should proceed on this. If you want me to apply the reversion,
please let me know.
I would be happy to fix to the problem, rather than just reverting the
patch, but I do not have expertise in assembly language on other
platforms, so I would need some help, if anyone would be interested in
helping me?
-- Caroline Tice
cmt...@google.com
ChangeLog (gcc):
2015-04-29 Caroline Tice cmt...@google.com
Revert patch from 2015-04-27
* final.c (final_scan_insn): Remove code to output
cold_function_name as a function type in assembly.
* varasm.c (cold_function_name): Remove global declaration.
(assemble_start_function): Remove code to re-set
cold_function_name.
(assemble_end_function): Do not output side of cold
partition.
ChangLog (gcc/testsuite):
2015-04-29 Caroline Tice cmt...@google.com
Revert patch from 2015-04-27
* gcc.dg/tree-prof/cold_partition_label.c: Do not check
for cold partition size.
On Wed, Apr 29, 2015 at 9:33 AM, Uros Bizjak ubiz...@gmail.com wrote:
Hello!
2015-03-27 Caroline Tice cmt...@google.com
* final.c (final_scan_insn): Change 'cold_function_name' to
'cold_partition_name' and make it a global variable; also output
assembly to give it a 'FUNC' type, if appropriate.
* varasm.c (cold_partition_name): Declare and initialize global
variable.
(assemble_start_function): Re-set value for cold_partition_name.
(assemble_end_function): Output assembly to calculate size of cold
partition, and associate size with name, if appropriate.
* varash.h (cold_partition_name): Add extern declaration for global
variable.
* testsuite/gcc.dg/tree-prof/cold_partition_label.c: Add dg-final-use
to scan assembly for cold partition name and size.
This patch caused PR 65929 [1].
Targets are (ab)using ASM_DECLARE_FUNCTION_NAME and
ASM_DECLARE_FUNCTION_SIZE for more things that their name suggests. As
shown in the PR, some directives that are generated through these
macros apply only to real functions, not to parts of function in the
middle of the function.
In the particular case in the PR, assembler doesn't tolerate nested
function declaration.
I suggest to revert the patch for now, until side effects of the patch
are resolved.
[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65929
Uros.
Index: gcc/final.c
===
--- gcc/final.c (revision 222584)
+++ gcc/final.c (working copy)
@@ -2233,16 +2233,10 @@
suffixing cold to the original function's name. */
if (in_cold_section_p)
{
- cold_function_name
+ tree cold_function_name
= clone_function_name (current_function_decl, cold);
-#ifdef ASM_DECLARE_FUNCTION_NAME
- ASM_DECLARE_FUNCTION_NAME (asm_out_file,
- IDENTIFIER_POINTER (cold_function_name),
- current_function_decl);
-#else
ASM_OUTPUT_LABEL (asm_out_file,
IDENTIFIER_POINTER (cold_function_name));
-#endif
}
break;
Index: gcc/testsuite/gcc.dg/tree-prof/cold_partition_label.c
===
--- gcc/testsuite/gcc.dg/tree-prof/cold_partition_label.c (revision 222584)
+++ gcc/testsuite/gcc.dg/tree-prof/cold_partition_label.c (working copy)
@@ -35,6 +35,4 @@
return 0;
}
-/* { dg-final-use { scan-assembler foo\[._\]+cold\[\._\]+0 } } */
-/* { dg-final-use { scan-assembler size\[ \ta-zA-Z0-0\]+foo\[._\]+cold\[\._\]+0 } } */
/* { dg-final-use { cleanup-saved-temps } } */
Index: gcc/varasm.c
===
--- gcc/varasm.c (revision 222584)
+++ gcc/varasm.c (working copy)
@@ -187,13 +187,6 @@
at the cold section. */
bool in_cold_section_p;
-/* The following global holds the function name for the code in the
- cold section of a function, if hot/cold function splitting is enabled
- and there was actually code that went into the cold section. A
- pseudo function name is needed for the cold section of code for some
- debugging tools that perform symbolization. */
-tree cold_function_name = NULL_TREE;
-
/* A linked list of all the unnamed sections. */
static GTY(()) section *unnamed_sections;
@@ -1726,7 +1719,6 @@
ASM_GENERATE_INTERNAL_LABEL (tmp_label, LCOLDE, const_labelno);
crtl-subsections.cold_section_end_label = ggc_strdup (tmp_label);
const_labelno++;
- cold_function_name = NULL_TREE;
}
else
{
@@ -1864,12 +1856,6 @@
save_text_section = in_section;
switch_to_section (unlikely_text_section ());
-#ifdef ASM_DECLARE_FUNCTION_SIZE
- if (cold_function_name != NULL_TREE)
- ASM_DECLARE_FUNCTION_SIZE (asm_out_file,
- IDENTIFIER_POINTER (cold_function_name),
- decl);
-#endif
ASM_OUTPUT_LABEL
Re: [PATCH] [libstdc++/65839] whatis support for xmethods
On 29/04/15 10:57 -0700, Doug Evans wrote: On Tue, Apr 28, 2015 at 5:16 AM, Jonathan Wakely jwak...@redhat.com wrote: On 27/04/15 15:44 -0700, Doug Evans wrote: PR libstdc++/65839 * python/libstdcxx/v6/xmethods.py (get_bool_type): New function. Replace all lookups of bool with this. (get_std_size_type): New function. Replace all lookups of std::size_t with this. (ArrayWorkerBase): Rename arg valtype to elem_type for consistency, I'd say ArrayWorkerBase's _valtype is correct and deque and vector are wrong to use _elemtype. C++ containers use value_type for the type of the container objects. Smart pointers use element_type for the type of the owned object. So using _valtype for containers and _elemtype for unique_ptr would be consistent with the C++ library types. Hi. Here's v2. It's assumes the naming cleanup patch has been applied. https://gcc.gnu.org/ml/libstdc++/2015-04/msg00183.html Regression tested on amd64-linux. Looks good, OK for trunk, thanks. If you want to fix this on the branch too then the renaming patch and this one are both OK for the gcc-5-branch as well.
[PATCH, i386]: Fix PR 65871, bzhi builtin/intrinsic wrongly assumes bzhi instruction doesn't set the ZF flag
Hello!
Attached patch implements a CCZ-only setting pattern for a couple of
BMI[,2] intrinsics.
2015-04-29 Uros Bizjak ubiz...@gmail.com
PR target/65871
* config/i386/i386.md (*bmi_bextr_mode_cczonly): New pattern.
(*bmi2_bzhi_mode3_1_cczonly): Ditto.
testsuite/ChangeLog:
2015-04-29 Uros Bizjak ubiz...@gmail.com
PR target/65871
* gcc.target/i386/pr65871-1.c: New test
* gcc.target/i386/pr65871-2.c: Ditto.
Patch was bootstrapped and regression tested on x86_64-linux-gnu
{,-m32} and was committed to mainline SVN.
Uros.
Index: config/i386/i386.md
===
--- config/i386/i386.md (revision 222585)
+++ config/i386/i386.md (working copy)
@@ -12594,6 +12594,20 @@
(set_attr btver2_decode direct, double)
(set_attr mode MODE)])
+(define_insn *bmi_bextr_mode_cczonly
+ [(set (reg:CCZ FLAGS_REG)
+ (compare:CCZ
+ (unspec:SWI48 [(match_operand:SWI48 1 nonimmediate_operand r,m)
+(match_operand:SWI48 2 register_operand r,r)]
+ UNSPEC_BEXTR)
+ (const_int 0)))
+ (clobber (match_scratch:SWI48 0 =r,r))]
+ TARGET_BMI
+ bextr\t{%2, %1, %0|%0, %1, %2}
+ [(set_attr type bitmanip)
+ (set_attr btver2_decode direct, double)
+ (set_attr mode MODE)])
+
(define_insn *bmi_blsi_mode
[(set (match_operand:SWI48 0 register_operand =r)
(and:SWI48
@@ -12667,6 +12681,7 @@
(set_attr mode MODE)])
(define_mode_attr k [(SI k) (DI q)])
+
(define_insn *bmi2_bzhi_mode3_1
[(set (match_operand:SWI48 0 register_operand =r)
(zero_extract:SWI48
@@ -12682,6 +12697,23 @@
(set_attr prefix vex)
(set_attr mode MODE)])
+(define_insn *bmi2_bzhi_mode3_1_cczonly
+ [(set (reg:CCZ FLAGS_REG)
+ (compare:CCZ
+ (zero_extract:SWI48
+ (match_operand:SWI48 1 nonimmediate_operand rm)
+ (umin:SWI48
+ (zero_extend:SWI48 (match_operand:QI 2 register_operand r))
+ (match_operand:SWI48 3 const_int_operand n))
+ (const_int 0))
+ (const_int 0)))
+ (clobber (match_scratch:SWI48 0 =r))]
+ TARGET_BMI2 INTVAL (operands[3]) == MODE_SIZE * BITS_PER_UNIT
+ bzhi\t{%k2, %1, %0|%0, %1, %k2}
+ [(set_attr type bitmanip)
+ (set_attr prefix vex)
+ (set_attr mode MODE)])
+
(define_insn bmi2_pdep_mode3
[(set (match_operand:SWI48 0 register_operand =r)
(unspec:SWI48 [(match_operand:SWI48 1 register_operand r)
Index: testsuite/gcc.target/i386/pr65871-1.c
===
--- testsuite/gcc.target/i386/pr65871-1.c (revision 0)
+++ testsuite/gcc.target/i386/pr65871-1.c (working copy)
@@ -0,0 +1,12 @@
+/* { dg-do compile } */
+/* { dg-options -O2 -mbmi } */
+
+int foo (unsigned int x, unsigned int y)
+{
+ if (__builtin_ia32_bextr_u32 (x, y))
+return 1;
+
+ return 0;
+}
+
+/* { dg-final { scan-assembler-not test } } */
Index: testsuite/gcc.target/i386/pr65871-2.c
===
--- testsuite/gcc.target/i386/pr65871-2.c (revision 0)
+++ testsuite/gcc.target/i386/pr65871-2.c (working copy)
@@ -0,0 +1,12 @@
+/* { dg-do compile } */
+/* { dg-options -O2 -mbmi2 } */
+
+int foo (unsigned int x, unsigned int y)
+{
+ if (__builtin_ia32_bzhi_si (x, y))
+return 1;
+
+ return 0;
+}
+
+/* { dg-final { scan-assembler-not test } } */
Re: [RFC]: Remove Mem/address type assumption in combiner
On 04/29/2015 03:25 AM, Kumar, Venkataramanan wrote: Hi Jeff/Segher, Restarting the discussion on the GCC combiner assumption about Memory/address type. Ref: https://gcc.gnu.org/ml/gcc-patches/2015-01/msg01298.html https://gcc.gnu.org/ml/gcc/2015-04/msg00028.html Regards, Venkat. PS: I am starting a new thread since I no more have access to Linaro ID from where I sent the earlier mail. Funny, I sent mail just a few days ago trying to get this restarted, but it went to your Linaro address. I'll forward it separately. Jeff
Re: [PATCH 3/8] add default for PCC_BITFIELD_TYPE_MATTERS
Trevor Saunders tbsau...@tbsaunde.org writes: it passes for me on x86_64-linux after that commit, what platform is this? Any one with #undef PCC_BITFIELD_TYPE_MATTERS. See libobjc/encoding.c. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different.
Re: [PATCH] gfortran testsuite: implicitly cleanup-modules
On Thu, 23 Apr 2015, Bernhard Reutner-Fischer wrote: I've done the above some time ago, dejagnu = 1.5.2 has a libdirs variable so i'd like to propose to: - Bump the required dejagnu version for gcc-6 to (let's say) 1.5.3 1.5.2 is only a few months old. I suggest waiting until a given version is widely present in long-term-support GNU/Linux distributions before requiring it. -- Joseph S. Myers jos...@codesourcery.com
Re: [PATCH] Refactor handle_section_attribute to reduce nesting and distinguish error cases
On 04/26/2015 07:09 PM, Josh Triplett wrote: handle_section_attribute contains many levels of nested conditionals and branching code flow paths, with the error cases sometimes in the else case and sometimes in the if case. Simplify the code flow into a series of potential failure cases ending with the successful path, with no nesting and no else clauses. --- I do not have commit access; if you approve, please commit. This cleanup will help enable a larger patch enhancing the section attribute. gcc/Changelog entry: 2014-08-24 Josh Triplett j...@joshtriplett.org * c-family/c-common.c (handle_section_attribute): Refactor to reduce nesting and distinguish between error cases. Installed on the trunk. WRT the larger patch, if you don't have a copyright assignment on file with the FSF, you should get that process started. ass...@gnu.org. jeff
Re: [PATCH 5/14][AArch64] Add basic fp16 support
On Wed, 22 Apr 2015, Alan Lawrence wrote: [Resending with correct in-reply-to header] This adds basic support for moving __fp16 values around, passing and returning, and operating on them by promoting to 32-bit floats. Also a few scalar testcases. I'd think it would be desirable to share tests between ARM and AArch64 as far as possible (where applicable to both - so not the tests for the alternative format, and some of the gcc.target/arm/fp16-* tests using scan-assembler might need adapting to work for AArch64). To the extent that the ARM implementation follows an old specification and AArch64 is following newer ACLE, of course, this might require ARM to be updated to follow newer ACLE before tests can be shared. (For example, the older specification implemented for ARM includes double rounding when converting from double to fp16, but ACLE specifies single rounding.) Longer term, I'd hope the aim would be for semantics to follow TS 18661-3 (DTS ballot recently passed), using the standard name _Float16 (and FLT_EVAL_METHOD == 32 as the nearest equivalent of the promotions to float). -- Joseph S. Myers jos...@codesourcery.com
Re: [PATCH 3/8] add default for PCC_BITFIELD_TYPE_MATTERS
On Wed, Apr 29, 2015 at 02:35:39PM +0200, Andreas Schwab wrote:
spawn /daten/aranym/gcc/gcc-20150429/Build/gcc/xgcc
-B/daten/aranym/gcc/gcc-20150429/Build/gcc/
/daten/aranym/gcc/gcc-20150429/gcc/testsuite/objc/execute/bf-1.m
-fno-diagnostics-show-caret -fdiagnostics-color=never -w -O0 -fgnu-runtime
-I/daten/aranym/gcc/gcc-20150429/gcc/testsuite/../../libobjc
-B/daten/aranym/gcc/gcc-20150429/Build/m68k-linux/./libobjc/.libs
-L/daten/aranym/gcc/gcc-20150429/Build/m68k-linux/./libobjc/.libs -lobjc -lm
-o /daten/aranym/gcc/gcc-20150429/Build/gcc/testsuite/objc/bf-1.x0
PASS: objc/execute/bf-1.m compilation, -O0 -fgnu-runtime
Executing on aranym: OMP_NUM_THREADS=2
LD_LIBRARY_PATH=.::/daten/aranym/gcc/gcc-20150429/Build/gcc:/daten/aranym/gcc/gcc-20150429/Build/m68k-linux/./libobjc/.libs
timeout 600 /daten/aranym/gcc/gcc-20150429/Build/gcc/testsuite/objc/bf-1.x0
(timeout = 300)
Executed /daten/aranym/gcc/gcc-20150429/Build/gcc/testsuite/objc/bf-1.x0,
status 1
Output: type = {class_vars=#fc{?=b0i2b2i3b5i12}c}
ivar 'isa', type '#', offset 0d
ivar 'f', type 'f', offset 4d
ivar 'a', type 'c', offset 8d
ivar 'flags', type '{?=ib0i2jb2i3kb5i12}', offset 9d
ivar 'c', type 'c', offset 12d
real ivar 'isa' offset 0d
computed type '#fc{?=b0i2b2i3b5i12}c}' offset 0
real ivar 'f' offset 4d
computed type 'fc{?=b0i2b2i3b5i12}c}' offset 4
real ivar 'a' offset 8d
computed type 'c{?=b0i2b2i3b5i12}c}' offset 8
real ivar 'flags' offset 9d
computed type '{?=b0i2b2i3b5i12}c}' offset 10
offset 9d and computed position 10 don't match on ivar 'flags' (i = 3)
child process exited abnormally
FAIL: objc/execute/bf-1.m execution, -O0 -fgnu-runtime
it passes for me on x86_64-linux after that commit, what platform is
this?
Trev
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
And now for something completely different.
Re: [PATCH] Fix size type for cold partition names (hot-cold function partitioning)
Here is a new patch to update the cold name partition so that it will
only be treated like a function name and be given a size on the
architectures that specifically define macros for such.
I also updated the test case to try to only test on the appropriate
architectures. I am not sure I got the target triples correct for
this, so I would appreciate some extra attention to that in the
review. I have tested this new patch on my workstation and it works
as intended. I am in the process of bootstrapping with the new patch.
Assuming that the bootstrap passes, is this ok to commit?
-- Caroline Tice
cmt...@google.com
ChangeLog (gcc):
2015-04-29 Caroline Tice cmt...@google.com
PR 65929
* config/elfos.h (ASM_DECLARE_COLD_FUNCTION_NAME): New macro definition.
(ASM_DECLARE_COLD_FUNCTION_SIZE): New macro definition.
* final.c (final_scan_insn): Use ASM_DECLARE_COLD_FUNCTION_NAME
instead of ASM_DECLARE_FUNCTION_NAME for cold partition name.
* varasm.c (assemble_end_function): Use ASM_DECLARE_COLD_FUNCTION_SIZE
instead of ASM_DECLARE_FUNCTION_SIZE for cold partition size.
ChangeLog (testsuite):
2015-04-29 Caroline Tice cmt...@google.com
PR 65929
* gcc.dg/tree-prof/cold_partition_label.c: Only check for cold
partition size on certain targets.
On Wed, Apr 29, 2015 at 11:59 AM, Caroline Tice cmt...@google.com wrote:
Thank you; I will work with your suggestions and try to get a new
patch done soon.
-- Caroline Tice
cmt...@google.com
On Wed, Apr 29, 2015 at 11:34 AM, Uros Bizjak ubiz...@gmail.com wrote:
On Wed, Apr 29, 2015 at 7:47 PM, Uros Bizjak ubiz...@gmail.com wrote:
On Wed, Apr 29, 2015 at 7:38 PM, Caroline Tice cmt...@google.com wrote:
The attached patch can revert the previous patch, if that is the way
we should proceed on this. If you want me to apply the reversion,
please let me know.
I would be happy to fix to the problem, rather than just reverting the
patch, but I do not have expertise in assembly language on other
platforms, so I would need some help, if anyone would be interested in
helping me?
How about adding ASM_DECLARE_COLD_FUNCTION_NAME and
ASM_DECLARE_COLD_FUNCTION_SIZE? If these are defined, they can be used
instead, and targets are free to define them in any way.
Something like the attached prototype RFC patch. Using this patch,
readelf -sW returns:
Symbol table '.symtab' contains 18 entries:
Num:Value Size TypeBind Vis Ndx Name
0: 0 NOTYPE LOCAL DEFAULT UND
1: 0 SECTION LOCAL DEFAULT1
2: 0 SECTION LOCAL DEFAULT3
3: 0 SECTION LOCAL DEFAULT4
4: 0 SECTION LOCAL DEFAULT5
5: 0 SECTION LOCAL DEFAULT6
6: 0 SECTION LOCAL DEFAULT8
7: 8 FUNCLOCAL DEFAULT6 main.cold.0
8: 0 SECTION LOCAL DEFAULT 10
9: 0 SECTION LOCAL DEFAULT 13
10: 0 SECTION LOCAL DEFAULT 12
11: 312 FUNCGLOBAL DEFAULT [other: 88] 8
main
12: 0008 160 OBJECT GLOBAL DEFAULT COM buf
13: 0 NOTYPE GLOBAL DEFAULT UND memset
14: 44 FUNCGLOBAL DEFAULT [other: 88] 1
sub2
15: 0 NOTYPE GLOBAL DEFAULT UND strcmp
16: 0 NOTYPE GLOBAL DEFAULT UND exit
17: 0 NOTYPE GLOBAL DEFAULT UND abort
Uros.
Index: gcc/config/elfos.h
===
--- gcc/config/elfos.h (revision 222584)
+++ gcc/config/elfos.h (working copy)
@@ -284,6 +284,22 @@
while (0)
#endif
+/* Write the extra assembler code needed to declare the name of a
+ cold function partition properly. Some svr4 assemblers need to also
+ have something extra said about the function's return value. We
+ allow for that here. */
+
+#ifndef ASM_DECLARE_COLD_FUNCTION_NAME
+#define ASM_DECLARE_COLD_FUNCTION_NAME(FILE, NAME, DECL) \
+ do\
+{\
+ ASM_OUTPUT_TYPE_DIRECTIVE (FILE, NAME, function); \
+ ASM_DECLARE_RESULT (FILE, DECL_RESULT (DECL)); \
+ ASM_OUTPUT_FUNCTION_LABEL (FILE, NAME, DECL); \
+}\
+ while (0)
+#endif
+
/* Write the extra assembler code needed to declare an object properly. */
#ifdef HAVE_GAS_GNU_UNIQUE_OBJECT
@@ -358,6 +374,17 @@
while (0)
#endif
+/* This is how to declare the size of a cold function partition. */
+#ifndef ASM_DECLARE_COLD_FUNCTION_SIZE
+#define ASM_DECLARE_COLD_FUNCTION_SIZE(FILE, FNAME, DECL) \
+ do\
+{\
+ if (!flag_inhibit_size_directive)\
+ ASM_OUTPUT_MEASURED_SIZE (FILE, FNAME); \
+}\
+ while (0)
+#endif
+
/* A
libgo patch committed: Support -buildmode=c-archive
The upcoming Go 1.5 release of the gc compiler adds support for go
build -buildmode=c-archive. This can be used to build Go code into
an archive (a .a file) that can be linked with a non-Go program, such
that the non-Go program can call into Go code. This patch adds
support for that to gccgo.
I'm going to commit this patch to the GCC 5 branch as well. This will
permit the Go 1.5 go tool to be used with the GCC 5.2 and later. That
way people won't have to wait for GCC 6. This patch seems safe to me
and passes all my testing.
Bootstrapped and ran Go tests and gc cgo tests on
x86_64-unknown-linux-gnu. Committed to mainline and GCC 5 branch.
Ian
diff -r ae8a4c892d42 libgo/Makefile.am
--- a/libgo/Makefile.am Fri Apr 24 15:07:55 2015 -0700
+++ b/libgo/Makefile.am Wed Apr 29 13:41:41 2015 -0700
@@ -105,7 +105,7 @@
toolexeclib_LIBRARIES = libgobegin-llgo.a
else
toolexeclib_LTLIBRARIES = libgo.la
-toolexeclib_LIBRARIES = libgobegin.a libnetgo.a
+toolexeclib_LIBRARIES = libgobegin.a libgolibbegin.a libnetgo.a
endif
toolexeclibgo_DATA = \
@@ -2036,6 +2036,11 @@
libgobegin_a_CFLAGS = $(AM_CFLAGS) -fPIC
libgobegin_llgo_a_CFLAGS = $(AM_CFLAGS) -fPIC
+libgolibbegin_a_SOURCES = \
+ runtime/go-libmain.c
+
+libgolibbegin_a_CFLAGS = $(AM_CFLAGS) -fPIC
+
libnetgo_a_SOURCES = $(go_netgo_files)
libnetgo_a_LIBADD = netgo.o
@@ -2067,7 +2072,7 @@
BUILDNETGO = \
$(MKDIR_P) $(@D); \
files=`echo $^ | sed -e 's/[^ ]*\.gox//g'`; \
- $(GOCOMPILE) -I . -c -fgo-pkgpath=net -o $@ $$files
+ $(GOCOMPILE) -I . -c -fPIC -fgo-pkgpath=net -o $@ $$files
GOTESTFLAGS =
GOBENCH =
diff -r ae8a4c892d42 libgo/runtime/go-cgo.c
--- a/libgo/runtime/go-cgo.cFri Apr 24 15:07:55 2015 -0700
+++ b/libgo/runtime/go-cgo.cWed Apr 29 13:41:41 2015 -0700
@@ -8,6 +8,9 @@
#include go-alloc.h
#include interface.h
#include go-panic.h
+#include go-type.h
+
+extern void __go_receive (ChanType *, Hchan *, byte *);
/* Prepare to call from code written in Go to code written in C or
C++. This takes the current goroutine out of the Go scheduler, as
@@ -86,6 +89,15 @@
runtime_exitsyscall ();
+ if (runtime_g ()-ncgo == 0)
+{
+ /* The C call to Go came from a thread not currently running any
+Go. In the case of -buildmode=c-archive or c-shared, this
+call may be coming in before package initialization is
+complete. Wait until it is. */
+ __go_receive (NULL, runtime_main_init_done, NULL);
+}
+
mp = runtime_m ();
if (mp-needextram)
{
@@ -177,3 +189,65 @@
__go_panic (e);
}
+
+/* Used for _cgo_wait_runtime_init_done. This is based on code in
+ runtime/cgo/gcc_libinit.c in the master library. */
+
+static pthread_cond_t runtime_init_cond = PTHREAD_COND_INITIALIZER;
+static pthread_mutex_t runtime_init_mu = PTHREAD_MUTEX_INITIALIZER;
+static _Bool runtime_init_done;
+
+/* This is called by exported cgo functions to ensure that the runtime
+ has been initialized before we enter the function. This is needed
+ when building with -buildmode=c-archive or similar. */
+
+void
+_cgo_wait_runtime_init_done (void)
+{
+ int err;
+
+ if (__atomic_load_n (runtime_init_done, __ATOMIC_ACQUIRE))
+return;
+
+ err = pthread_mutex_lock (runtime_init_mu);
+ if (err != 0)
+abort ();
+ while (!__atomic_load_n (runtime_init_done, __ATOMIC_ACQUIRE))
+{
+ err = pthread_cond_wait (runtime_init_cond, runtime_init_mu);
+ if (err != 0)
+ abort ();
+}
+ err = pthread_mutex_unlock (runtime_init_mu);
+ if (err != 0)
+abort ();
+}
+
+/* This is called by runtime_main after the Go runtime is
+ initialized. */
+
+void
+_cgo_notify_runtime_init_done (void)
+{
+ int err;
+
+ err = pthread_mutex_lock (runtime_init_mu);
+ if (err != 0)
+abort ();
+ __atomic_store_n (runtime_init_done, 1, __ATOMIC_RELEASE);
+ err = pthread_cond_broadcast (runtime_init_cond);
+ if (err != 0)
+abort ();
+ err = pthread_mutex_unlock (runtime_init_mu);
+ if (err != 0)
+abort ();
+}
+
+// runtime_iscgo is set to true if some cgo code is linked in.
+// This is done by a constructor in the cgo generated code.
+_Bool runtime_iscgo;
+
+// runtime_cgoHasExtraM is set on startup when an extra M is created
+// for cgo. The extra M must be created before any C/C++ code calls
+// cgocallback.
+_Bool runtime_cgoHasExtraM;
diff -r ae8a4c892d42 libgo/runtime/go-libmain.c
--- /dev/null Thu Jan 01 00:00:00 1970 +
+++ b/libgo/runtime/go-libmain.cWed Apr 29 13:41:41 2015 -0700
@@ -0,0 +1,114 @@
+/* go-libmain.c -- the startup function for a Go library.
+
+ Copyright 2015 The Go Authors. All rights reserved.
+ Use of this source code is governed by a BSD-style
+ license that can be found in the LICENSE file. */
+
+#include config.h
+
+#include errno.h
+#include pthread.h
+#include stdlib.h
+#include time.h
+#include unistd.h
+
+#include runtime.h
+#include go-alloc.h
+#include array.h
+#include arch.h
+#include
Re: [Patch/rtl-expand] Take tree range info into account to improve LSHIFT_EXP expanding
Jeff Law writes: On 04/27/2015 02:21 PM, Jiong Wang wrote: Jeff, Sorry, I can't understand the meaning of overlap between t_low and low, assume right in right value means the opposite of left not correct. So what you mean is t_low and low share the same pseudo regiser? My concern is sharing the same pseudo or memory location. But thinking more about it, the shifted value has to have range information, so it must have been an SSA_NAME, right? If so, then it can't overlap with the destination, so this is a non-issue. Sorry for the confusion. Thanks for the light. By looking at related code, looks like even it's SSA_NAME, it's still possible to share the same pseudo given the destination is in the same SSA map parition after ssa name coleascing? I've never liked the model of storing into TARGET when it's convenient. Because storing into TARGET is totally optional, it means the callers have to check if the value was stored into TARGET or not. Sadly that model has been in the expanders as long as I can remember. So I think this can go forward once we resolve the case where expand_variable_shift returns its value in something other than the passed in target. OK. I will rework the patch, and I found there is a function named expand_doubleword_shift which looks like a more natural place to do this optimization, although it's hard to get range info there. I will do further explore on this. -- Regards, Jiong
Re: [C PATCH] c_incomplete_type_error TLC
On 04/29/2015 12:51 PM, Marek Polacek wrote: This patch cleans up c_incomplete_type_error a bit: today, we should prefer using %qT over %%s %E% (the code is largely intact since 1992), and second, we should print the type if we can. The invalid use of incomplete typedef error wasn't tested at all, so I'm also adding a test to exercise that code path. Bootstrapped/regtested on x86_64-linux, ok for trunk? 2015-04-29 Marek Polacek pola...@redhat.com * c-typeck.c (c_incomplete_type_error): Refactor to use %qT. Print the type of a decl. * gcc.dg/incomplete-typedef-1.c: New test. OK. jeff
RE: [PATCH v4][MIPS] fix CRT_CALL_STATIC_FUNCTION macro
-Original Message- From: Petar Jovanovic [mailto:petar.jovano...@rt-rk.com] Sent: Friday, April 24, 2015 10:51 AM Subject: [PATCH v4][MIPS] fix CRT_CALL_STATIC_FUNCTION macro gcc/ChangeLog: 2015-04-21 Petar Jovanovic petar.jovano...@rt-rk.com * config/mips/mips.h (CRT_CALL_STATIC_FUNCTION): Fix the macro to use la/jalr instead of jal. gcc/testsuite/ChangeLog: 2015-04-21 Petar Jovanovic petar.jovano...@rt-rk.com * gcc.target/mips/call-from-init.c: New test. * gcc.target/mips/mips.exp: Add section_start to Thank you, Petar. I have now committed this patch. Catherine
Re: C++ PATCH for c++/50800 (ICE with may_alias and templates)
On 04/29/2015 07:41 AM, Markus Trippelsdorf wrote:
I'm getting hundreds of new warnings when building LLVM, e.g.:
Whoops. Fixed thus.
commit 7da5a68ba55cd49c46ff9ac547df59248bd90f7d
Author: Jason Merrill ja...@redhat.com
Date: Wed Apr 29 16:04:08 2015 -0400
PR c++/50800
* tree.c (apply_identity_attributes): Fix handling of classes.
diff --git a/gcc/cp/tree.c b/gcc/cp/tree.c
index d00f0d7..ec9be8c 100644
--- a/gcc/cp/tree.c
+++ b/gcc/cp/tree.c
@@ -1187,6 +1187,13 @@ apply_identity_attributes (tree result, tree attribs, bool *remove_attributes)
tree new_attribs = NULL_TREE;
tree *p = new_attribs;
+ if (OVERLOAD_TYPE_P (result))
+{
+ /* On classes and enums all attributes are ingrained. */
+ gcc_assert (attribs == TYPE_ATTRIBUTES (result));
+ return result;
+}
+
for (tree a = attribs; a; a = TREE_CHAIN (a))
{
const attribute_spec *as
diff --git a/gcc/testsuite/g++.dg/cpp0x/alignas3.C b/gcc/testsuite/g++.dg/cpp0x/alignas3.C
new file mode 100644
index 000..aa62e5a
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/alignas3.C
@@ -0,0 +1,20 @@
+// PR c++/50800
+// { dg-do compile { target c++11 } }
+
+template typename struct A;
+template typename _Up struct A_Up * { typedef _Up type; };
+template typename T struct B { typedef typename AT::type type; };
+template typename struct C;
+template typename From struct Cconst From {
+ typedef typename BFrom::type SimpleType;
+};
+template class struct D { typedef int ret_type; };
+template class From struct F {
+ typedef typename Dtypename CFrom::SimpleType::ret_type ret_type;
+};
+template class, class Y typename FY::ret_type cast(Y );
+class CompoundStmt;
+class alignas(8) Stmt {
+ Stmt *Children[1];
+ CompoundStmt *getBlock() const { castCompoundStmt(Children[0]); }
+};
RE: [Patch, MIPS] Change mips4 default processor to r10K
-Original Message- From: Matthew Fortune [mailto:matthew.fort...@imgtec.com] Sent: Tuesday, April 28, 2015 2:38 PM Steve Ellcey sell...@imgtec.com writes: 2015-04-28 Steve Ellcey sell...@imgtec.com * config/mips/mips-cpus.def: (mips4): Change default processor from PROCESSOR_R8000 to PROCESSOR_R1. Ok with me. I'd like Catherine to have the chance to raise any concerns though. This change is OK with me, as well. Catherine
Re: [PATCH, i386]: Fix PR 65871, bzhi builtin/intrinsic wrongly assumes bzhi instruction doesn't set the ZF flag
On Wed, Apr 29, 2015 at 9:02 PM, Uros Bizjak ubiz...@gmail.com wrote:
Hello!
Attached patch implements a CCZ-only setting pattern for a couple of
BMI[,2] intrinsics.
These two insns are three operand instructions, and some peephole2
patterns were not prepared for this. Please note that clobbered
register can be different than input registers. Attached patch fixes
this omission.
2015-04-29 Uros Bizjak ubiz...@gmail.com
PR target/65871
* config/i386/i386.md (*bmi_bextr_mode_cczonly): New pattern.
(*bmi2_bzhi_mode3_1_cczonly): Ditto.
(setcc+movzbl peephole2): Check also clobbered reg.
(setcc+andl peephole2): Ditto.
Tested on x86_64-linux-gnu {,-m32} and committed to mainline SVN.
Uros.
Index: config/i386/i386.md
===
--- config/i386/i386.md (revision 222590)
+++ config/i386/i386.md (working copy)
@@ -11567,7 +11567,9 @@
(zero_extend (match_dup 1)))]
(peep2_reg_dead_p (3, operands[1])
|| operands_match_p (operands[1], operands[3]))
-! reg_overlap_mentioned_p (operands[3], operands[0])
+! reg_overlap_mentioned_p (operands[3], operands[0])
+! (GET_CODE (operands[4]) == CLOBBER
+ reg_mentioned_p (operands[3], operands[4]))
[(parallel [(set (match_dup 5) (match_dup 0))
(match_dup 4)])
(set (strict_low_part (match_dup 6))
@@ -11610,7 +11612,9 @@
(clobber (reg:CC FLAGS_REG))])]
(peep2_reg_dead_p (3, operands[1])
|| operands_match_p (operands[1], operands[3]))
-! reg_overlap_mentioned_p (operands[3], operands[0])
+! reg_overlap_mentioned_p (operands[3], operands[0])
+! (GET_CODE (operands[4]) == CLOBBER
+ reg_mentioned_p (operands[3], operands[4]))
[(parallel [(set (match_dup 5) (match_dup 0))
(match_dup 4)])
(set (strict_low_part (match_dup 6))
New Danish PO file for 'gcc' (version 5.1.0)
Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'gcc' has been submitted by the Danish team of translators. The file is available at: http://translationproject.org/latest/gcc/da.po (This file, 'gcc-5.1.0.da.po', has just now been sent to you in a separate email.) All other PO files for your package are available in: http://translationproject.org/latest/gcc/ Please consider including all of these in your next release, whether official or a pretest. Whenever you have a new distribution with a new version number ready, containing a newer POT file, please send the URL of that distribution tarball to the address below. The tarball may be just a pretest or a snapshot, it does not even have to compile. It is just used by the translators when they need some extra translation context. The following HTML page has been updated: http://translationproject.org/domain/gcc.html If any question arises, please contact the translation coordinator. Thank you for all your work, The Translation Project robot, in the name of your translation coordinator. coordina...@translationproject.org
Re: [Patch/rtl-expand] Take tree range info into account to improve LSHIFT_EXP expanding
On 04/29/2015 03:36 PM, Jiong Wang wrote: Jeff Law writes: On 04/27/2015 02:21 PM, Jiong Wang wrote: Jeff, Sorry, I can't understand the meaning of overlap between t_low and low, assume right in right value means the opposite of left not correct. So what you mean is t_low and low share the same pseudo regiser? My concern is sharing the same pseudo or memory location. But thinking more about it, the shifted value has to have range information, so it must have been an SSA_NAME, right? If so, then it can't overlap with the destination, so this is a non-issue. Sorry for the confusion. Thanks for the light. By looking at related code, looks like even it's SSA_NAME, it's still possible to share the same pseudo given the destination is in the same SSA map parition after ssa name coleascing? If they're the same size and have non-overlapping lifetimes, then yes, they could be the same pseudo. That ought to be easy to check. Thankfully we don't have to worry about MEMs, which is a harder check. OK. I will rework the patch, and I found there is a function named expand_doubleword_shift which looks like a more natural place to do this optimization, although it's hard to get range info there. I will do further explore on this. Sounds good. jeff
Go patch committed: Fix escape analysis for multi-result calls
This patch from Chris Manghane fixes the handling of multi-result
calls in escape analysis. Bootstrapped and ran Go testsuite on
x86_64-unknown-linux-gnu. Committed to mainline.
Ian
diff -r 76359c093067 go/escape.cc
--- a/go/escape.cc Wed Apr 29 15:09:15 2015 -0700
+++ b/go/escape.cc Wed Apr 29 15:27:38 2015 -0700
@@ -989,21 +989,21 @@
Named_object* lhs_no = this-resolve_var_reference(assn-lhs());
Named_object* rhs_no = this-resolve_var_reference(assn-rhs());
- if (assn-rhs()-is_composite_literal()
- || assn-rhs()-heap_expression() != NULL)
- this-handle_composite_literal(var, assn-rhs());
- else if (assn-rhs()-call_result_expression() != NULL)
+ Expression* rhs = assn-rhs();
+ if (rhs-is_composite_literal()
+ || rhs-heap_expression() != NULL)
+ this-handle_composite_literal(var, rhs);
+
+ if (rhs-call_result_expression() != NULL)
{
// V's initialization will be a call result if
// V, V1 := call(VAR).
// There are no useful edges to make from V, but we want
// to make sure we handle the call that references VAR.
- Expression* call =
- assn-rhs()-call_result_expression()-call();
- this-handle_call(var, call);
+ rhs = rhs-call_result_expression()-call();
}
- else if (assn-rhs()-call_expression() != NULL)
- this-handle_call(var, assn-rhs());
+ if (rhs-call_expression() != NULL)
+ this-handle_call(var, rhs);
// If there is no standalone variable on the rhs, this could be a
// binary expression, which isn't interesting for analysis or a
@@ -1038,8 +1038,12 @@
break;
case Statement::STATEMENT_EXPRESSION:
- this-handle_call(var,
- p-statement-expression_statement()-expr());
+ {
+ Expression* call = p-statement-expression_statement()-expr();
+ if (call-call_result_expression() != NULL)
+ call = call-call_result_expression()-call();
+ this-handle_call(var, call);
+ }
break;
case Statement::STATEMENT_GO:
@@ -1064,10 +1068,17 @@
else if (cond-binary_expression() != NULL)
{
Binary_expression* comp = cond-binary_expression();
- if (comp-left()-call_expression() != NULL)
- this-handle_call(var, comp-left());
- if (comp-right()-call_expression() != NULL)
- this-handle_call(var, comp-right());
+ Expression* left = comp-left();
+ Expression* right = comp-right();
+
+ if (left-call_result_expression() != NULL)
+ left = left-call_result_expression()-call();
+ if (left-call_expression() != NULL)
+ this-handle_call(var, left);
+ if (right-call_result_expression() != NULL)
+ right = right-call_result_expression()-call();
+ if (right-call_expression() != NULL)
+ this-handle_call(var, right);
}
}
break;
@@ -1092,16 +1103,10 @@
// composite literal.
this-handle_composite_literal(decl_no, init);
}
- else if (init-call_result_expression() != NULL)
- {
- // V's initialization will be a call result if
- // V, V1 := call(VAR).
- // There's no useful edges to make from V or V1, but we want
- // to make sure we handle the call that references VAR.
- Expression* call = init-call_result_expression()-call();
- this-handle_call(var, call);
- }
- else if (init-call_expression() != NULL)
+
+ if (init-call_result_expression() != NULL)
+ init = init-call_result_expression()-call();
+ if (init-call_expression() != NULL)
this-handle_call(var, init);
}
break;
@@ -1148,18 +1153,46 @@
if (lhs_no == NULL)
break;
- if (assn-rhs()-func_expression() != NULL)
+ Expression* rhs = assn-rhs();
+ if (rhs-temporary_reference_expression() != NULL)
+ rhs = rhs-temporary_reference_expression()-statement()-init();
+ if (rhs == NULL)
+ break;
+
+ if (rhs-call_result_expression() != NULL)
+ rhs = rhs-call_result_expression()-call();
+ if (rhs-call_expression() != NULL)
+ {
+ // It's not clear what variables we are trying to find references to
+ // so just use the arguments to this call.
+ Expression_list* args =
Re: [PATCH 3/8] add default for PCC_BITFIELD_TYPE_MATTERS
On 04/29/2015 03:55 PM, Andreas Schwab wrote: Trevor Saunders tbsau...@tbsaunde.org writes: it passes for me on x86_64-linux after that commit, what platform is this? Any one with #undef PCC_BITFIELD_TYPE_MATTERS. See libobjc/encoding.c. Can't you just answer the question Andreas instead of making Trevor go looking around? You already have this information, why make his job harder? Trevor, try m68k-elf cross. jeff
Re: [C/C++ PATCH] Implement -Wshift-negative-value (PR c/65179)
On Mon, 27 Apr 2015, Marek Polacek wrote:
trigger by default. One change is that we reject programs that use shift with
undefined behavior in a context where a constant expression is required, thus
e.g. enum E { A = -1 0 };
But I hope that's reasonable.
That seems appropriate (for C99 and above).
But if someone explicitly uses -Wshift-negative-value, I'd expect that to
produce the warnings (as opposed to the rejections where a constant
expression is required) even in C90 mode. That is, for the warnings, I
think flag_isoc99 should maybe affect the default (whether -Wextra enables
the warning, or whatever such approach gets taken), but not whether
-Wshift-negative-value, given that the option has been enabled, produces
warnings.
--
Joseph S. Myers
jos...@codesourcery.com
Re: [PATCH 3/8] add default for PCC_BITFIELD_TYPE_MATTERS
On Wed, Apr 29, 2015 at 04:00:47PM -0600, Jeff Law wrote: On 04/29/2015 03:55 PM, Andreas Schwab wrote: Trevor Saunders tbsau...@tbsaunde.org writes: it passes for me on x86_64-linux after that commit, what platform is this? Any one with #undef PCC_BITFIELD_TYPE_MATTERS. See libobjc/encoding.c. Can't you just answer the question Andreas instead of making Trevor go looking around? You already have this information, why make his job harder? actually pointing out libojc/encoding.c was more useful since that makes it pretty clear the ifndef PCC_BITFIELD_TYPE_MATTERS there just needs to be changed to #if ! Trevor, try m68k-elf cross. ok, lets see if I can get this to work (its an execution test that breaks, so I'll need to setup binutils and qemu) Trev jeff
Re: [PATCH 3/8] add default for PCC_BITFIELD_TYPE_MATTERS
On 04/29/2015 04:25 PM, Trevor Saunders wrote: On Wed, Apr 29, 2015 at 04:00:47PM -0600, Jeff Law wrote: On 04/29/2015 03:55 PM, Andreas Schwab wrote: Trevor Saunders tbsau...@tbsaunde.org writes: it passes for me on x86_64-linux after that commit, what platform is this? Any one with #undef PCC_BITFIELD_TYPE_MATTERS. See libobjc/encoding.c. Can't you just answer the question Andreas instead of making Trevor go looking around? You already have this information, why make his job harder? actually pointing out libojc/encoding.c was more useful since that makes it pretty clear the ifndef PCC_BITFIELD_TYPE_MATTERS there just needs to be changed to #if ! In that case, Andreas, please accept my apologies. jeff
Go patch committed: Propagate escape info from closures to enclosed variables
This patch from Chris Manghane fixes the Go frontend to propagate
escape information from closures to the enclosed variables to which
they refer. Bootstrapped and ran Go testsuite on
x86_64-unknown-linux-gnu. Committed to mainline.
Ian
diff -r 0010ef165479 go/escape.cc
--- a/go/escape.cc Wed Apr 29 14:28:30 2015 -0700
+++ b/go/escape.cc Wed Apr 29 15:07:47 2015 -0700
@@ -1276,8 +1276,22 @@
Node* m = worklist.front();
worklist.pop_front();
- for (std::setNode*::iterator n = m-edges().begin();
- n != m-edges().end();
+ std::setNode* reachable = m-edges();
+ if (m-object()-is_function()
+ m-object()-func_value()-needs_closure())
+ {
+ // If a closure escapes everything it closes over also escapes.
+ Function* closure = m-object()-func_value();
+ for (size_t i = 0; i closure-closure_field_count(); i++)
+ {
+ Named_object* enclosed = closure-enclosing_var(i);
+ Node* enclosed_node = this-lookup_connection_node(enclosed);
+ go_assert(enclosed_node != NULL);
+ reachable.insert(enclosed_node);
+ }
+ }
+ for (std::setNode*::iterator n = reachable.begin();
+ n != reachable.end();
++n)
{
// If an object can be reached from a node with ESCAPE_GLOBAL,
@@ -1296,7 +1310,7 @@
p != this-named_connection_nodes_.end();
++p)
{
- if (p-second-connection_node()-escape_state() == Node::ESCAPE_ARG)
+ if (p-second-connection_node()-escape_state() Node::ESCAPE_NONE)
worklist.push_back(p-second);
}
@@ -1305,15 +1319,30 @@
Node* m = worklist.front();
worklist.pop_front();
- for (std::setNode*::iterator n = m-edges().begin();
- n != m-edges().end();
+ std::setNode* reachable = m-edges();
+ if (m-object()-is_function()
+ m-object()-func_value()-needs_closure())
+ {
+ // If a closure escapes everything it closes over also escapes.
+ Function* closure = m-object()-func_value();
+ for (size_t i = 0; i closure-closure_field_count(); i++)
+ {
+ Named_object* enclosed = closure-enclosing_var(i);
+ Node* enclosed_node = this-lookup_connection_node(enclosed);
+ go_assert(enclosed_node != NULL);
+ reachable.insert(enclosed_node);
+ }
+ }
+ for (std::setNode*::iterator n = reachable.begin();
+ n != reachable.end();
++n)
{
// If an object can be reached from a node with ESCAPE_ARG,
// it is ESCAPE_ARG or ESCAPE_GLOBAL.
- if ((*n)-connection_node()-escape_state() Node::ESCAPE_ARG)
+ Node::Escapement_lattice e = m-connection_node()-escape_state();
+ if ((*n)-connection_node()-escape_state() e)
{
- (*n)-connection_node()-set_escape_state(Node::ESCAPE_ARG);
+ (*n)-connection_node()-set_escape_state(e);
worklist.push_back(*n);
}
}
diff -r 0010ef165479 go/gogo.h
--- a/go/gogo.h Wed Apr 29 14:28:30 2015 -0700
+++ b/go/gogo.h Wed Apr 29 15:07:47 2015 -0700
@@ -1042,6 +1042,11 @@
this-is_unnamed_type_stub_method_ = true;
}
+ // Return the amount of enclosed variables in this closure.
+ size_t
+ closure_field_count() const
+ { return this-closure_fields_.size(); }
+
// Add a new field to the closure variable.
void
add_closure_field(Named_object* var, Location loc)
Re: [PATCH 3/8] add default for PCC_BITFIELD_TYPE_MATTERS
On 04/29/2015 04:25 PM, Trevor Saunders wrote: On Wed, Apr 29, 2015 at 04:00:47PM -0600, Jeff Law wrote: On 04/29/2015 03:55 PM, Andreas Schwab wrote: Trevor Saunders tbsau...@tbsaunde.org writes: it passes for me on x86_64-linux after that commit, what platform is this? Any one with #undef PCC_BITFIELD_TYPE_MATTERS. See libobjc/encoding.c. Can't you just answer the question Andreas instead of making Trevor go looking around? You already have this information, why make his job harder? actually pointing out libojc/encoding.c was more useful since that makes it pretty clear the ifndef PCC_BITFIELD_TYPE_MATTERS there just needs to be changed to #if ! Trevor, try m68k-elf cross. ok, lets see if I can get this to work (its an execution test that breaks, so I'll need to setup binutils and qemu) I've actually got a aranym m68k emulator here... So I can do native bootstrapping and testing for m68k linux. If you want me to test something, just let me know -- FWIW, it takes a week or so to bootstrap ;-) jeff
Re: [PATCH 0/13] Add musl support to GCC
On Wed, 29 Apr 2015, Szabolcs Nagy wrote: only affects [u]int_fastN_t types (on 64bit systems for N=16,32 musl uses int but glibc uses long) i can fix glibc-stdint.h, but it's yet another way in which the compiler is tied to a particular libc. (using musl-stdint.h would be nicer, but that would require more changes i think, i have a fix now where the glibc-stdint.h types depend on OPTION_MUSL, but i still have to make sure OPTION_MUSL is always defined when this header is used). (i'd prefer if the compiler did not know about these types, but the standard requires them in stdatomic.h without including stdint.h and in stdint.h in freestanding mode, i'm not sure if there is a workaround without depending on libc) The compiler also needs to know these types for the Fortran C bindings. -- Joseph S. Myers jos...@codesourcery.com
[C++ Patch] PR 61683
Hi,
this seems pretty straightforward given the grammar. Tested x86_64-linux.
Thanks,
Paolo.
/cp
2015-04-30 Paolo Carlini paolo.carl...@oracle.com
PR c++/61683
* parser.c (cp_parser_mem_initializer): Allow for decltype-specifier.
/testsuite
2015-04-30 Paolo Carlini paolo.carl...@oracle.com
PR c++/61683
* g++.dg/cpp0x/decltype-base1.C: New.
Index: cp/parser.c
===
--- cp/parser.c (revision 222599)
+++ cp/parser.c (working copy)
@@ -12776,6 +12776,7 @@ cp_parser_mem_initializer (cp_parser* parser)
mem-initializer-id:
:: [opt] nested-name-specifier [opt] class-name
+ decltype-specifier (C++11)
identifier
Returns a TYPE indicating the class to be initializer for the first
@@ -12838,14 +12839,18 @@ cp_parser_mem_initializer_id (cp_parser* parser)
/*is_declaration=*/true);
/* Otherwise, we could also be looking for an ordinary identifier. */
cp_parser_parse_tentatively (parser);
- /* Try a class-name. */
- id = cp_parser_class_name (parser,
-/*typename_keyword_p=*/true,
-/*template_keyword_p=*/false,
-none_type,
-/*check_dependency_p=*/true,
-/*class_head_p=*/false,
-/*is_declaration=*/true);
+ if (cp_lexer_next_token_is_decltype (parser-lexer))
+/* Try a decltype-specifier. */
+id = cp_parser_decltype (parser);
+ else
+/* Otherwise, try a class-name. */
+id = cp_parser_class_name (parser,
+ /*typename_keyword_p=*/true,
+ /*template_keyword_p=*/false,
+ none_type,
+ /*check_dependency_p=*/true,
+ /*class_head_p=*/false,
+ /*is_declaration=*/true);
/* If we found one, we're done. */
if (cp_parser_parse_definitely (parser))
return id;
Index: testsuite/g++.dg/cpp0x/decltype-base1.C
===
--- testsuite/g++.dg/cpp0x/decltype-base1.C (revision 0)
+++ testsuite/g++.dg/cpp0x/decltype-base1.C (working copy)
@@ -0,0 +1,8 @@
+// PR c++/61683
+// { dg-do compile { target c++11 } }
+
+struct A {};
+A a;
+struct B : A {
+ B(): decltype(a)() {}
+};
Re: [PATCH 3/8] add default for PCC_BITFIELD_TYPE_MATTERS
On Wed, Apr 29, 2015 at 04:29:26PM -0600, Jeff Law wrote: On 04/29/2015 04:25 PM, Trevor Saunders wrote: On Wed, Apr 29, 2015 at 04:00:47PM -0600, Jeff Law wrote: On 04/29/2015 03:55 PM, Andreas Schwab wrote: Trevor Saunders tbsau...@tbsaunde.org writes: it passes for me on x86_64-linux after that commit, what platform is this? Any one with #undef PCC_BITFIELD_TYPE_MATTERS. See libobjc/encoding.c. Can't you just answer the question Andreas instead of making Trevor go looking around? You already have this information, why make his job harder? actually pointing out libojc/encoding.c was more useful since that makes it pretty clear the ifndef PCC_BITFIELD_TYPE_MATTERS there just needs to be changed to #if ! Trevor, try m68k-elf cross. ok, lets see if I can get this to work (its an execution test that breaks, so I'll need to setup binutils and qemu) I've actually got a aranym m68k emulator here... So I can do native bootstrapping and testing for m68k linux. If you want me to test something, just let me know -- FWIW, it takes a week or so to bootstrap ;-) Well the fix is just this diff --git a/libobjc/encoding.c b/libobjc/encoding.c index 7333908..20ace46 100644 --- a/libobjc/encoding.c +++ b/libobjc/encoding.c @@ -1167,7 +1167,7 @@ objc_layout_structure_next_member (struct objc_struct_layout *layout) /* Record must have at least as much alignment as any field. Otherwise, the alignment of the field within the record is meaningless. */ -#ifndef PCC_BITFIELD_TYPE_MATTERS +#if !PCC_BITFIELD_TYPE_MATTERS layout-record_align = MAX (layout-record_align, desired_align); #else /* PCC_BITFIELD_TYPE_MATTERS */ if (*type == _C_BFLD) I looked at the .i built for m68k-linux-elf before and after the patch and it does what I expect it should do and is a pretty obvious part that should go with the rest of this patch. Obviously something else should be done in the long run at least to separate gcc and libobjc configuration, but I can't see an argument for that patch not being ok for now so I'm inclined to check it in with the current level of testing. Trev jeff
