Re: [PATCH 1/2] gcc symbol database
Please allow me to resend former sample:
#define Z(a) a
#define Y Z
#define X(p) p + Y
X(1)(2);
The flow is:
1) `X' -- leader macro token by macro_start_expand.
2) `(', `1', `)' -- macro tokens, by cb_lex_token.
3) macro_end_arg.
4) `1', `+' -- macro replacement tokens, by symdb_cpp_token.
5) `(', `2', `)' -- macro tokens, by cb_lex_token.
6) macro_end_arg.
7) `2' -- macro replacement tokens, by symdb_cpp_token.
8) macro_end_expand.
The thing I emphasized here is cb_lex_token is set by macro_start_expand
intern -- it isn't valid anytime. So
buff = funlike_invocation_p (pfile, node, &pragma_buff,
...
if (buff == NULL)
{
...
}
if macro_start_expand is moved to the clause block `buff != NULL', it's too
later to set cb_lex_token because funlike_invocation_p has read some macro
tokens.
Of course I can remove macro_end_arg totally, because from the sample, it's the
fact that macro tokens aren't always before any macro replacement tokens. But
macro_end_expand must be prepared to deal with cancel case.
BTW, currently it isn't necessary to my plugin to collect macro tokens, so if
gcc doesn't support collect macro token event, macro_start_expand and
macro_end_expand can be moved into enter_macro_context and _cpp_pop_context
individually.
Yunfeng
Re: [Patch/RFC] SEH exceptions for Win64
On Jul 16, 2012, at 6:28 PM, Richard Henderson wrote:
> On 07/13/2012 07:13 AM, Tristan Gingold wrote:
>> +_Unwind_RaiseException (struct _Unwind_Exception *exc)
>> +{
>> + memset (exc->private_, 0, sizeof (exc->private_));
>> +
>> + RaiseException (STATUS_GCC_THROW, 0, 1, (ULONG_PTR *)&exc);
>
> We almost certainly didn't want pointer-to-pointer...
I was about to say that this is an obvious typo, but no, this code is correct
AFAIK.
The declaration of RaiseException is:
void
WINAPI RaiseException(
__in DWORD dwExceptionCode,
__in DWORD dwExceptionFlags,
__in DWORD nNumberOfArguments,
__in const ULONG_PTR *lpArguments
);
That is, the last argument is an array of arguments to be copied into the
exception record.
In our case, the start of the array is &exc, and its length is 1.
So, the first element of ExceptionInformation will be exc.
Should I add a comment ?
Tristan.
Re: [patch][rfc] Clean up CFG dumping
On Mon, Jul 16, 2012 at 09:55:30PM +0200, Steven Bosscher wrote:
>On Mon, Jul 16, 2012 at 5:57 PM, Steven Bosscher wrote:
>> Hello,
>>
>> There are comments in basic-block.h that advise to update certain
>> parts of the compiler if a new edge flag or basic block flag is added:
>>
>> -/* Always update the table in cfg.c dump_edge_info. */
>>
>> and
>>
>> - Always update the table in cfg.c dump_bb_info. */
>>
>> Apparently this is not enough, because there are more places where the
>> BB flags are dumped. For instance, cfg.c:dump_cfg_bb_info does not
>> handle BB_MODIFIED, BB_VISITED, and BB_IN_TRANSACTION, and
>> dump_bb_info doesn't even exist in cfg.c (it's in cfgrtl.c). The flags
>> also aren't documented very well in the code.
>>
>> Furthermore, there are multiple places where "common" (i.e. IR
>> agnostic) basic block information is dumped, with some functions
>> taking TDF_* flags and others not, some functions taking a FILE as the
>> first argument and others as the second argument, etc. In short:
>> Unnecessarily messy.
>>
>> The attached patch cleans up the worst of it:
>>
>> * A new file cfg-flags.def is used to define the BB_* and EDGE_*
>> flags. The names are the full string of the name of the flag in
>> uppercase, that's a change from before. I can add a separate name
>> field to DEF_EDGE_FLAG and DEF_BB_FLAG if necessary.
>>
>> * Now that there is dumpfile.h for the TDF_* masks, it's easier to use
>> them everywhere. I have added one new flag to dump with the ";;"
>> prefix (I think it should be used in more places, but that's something
>> for later, perhaps).
>>
>> * All basic block header/footer and edge dumping is consolidated in
>> dump_edge_info and dump_bb_info. This affects GIMPLE dump the most,
>> because it uses a different form of dumping for basic block
>> predecessors and successors. I expect some fall-out in the test suite
>> (patterns that no longer match) that I'll have to address before the
>> patch is ready for mainline.
>>
>> * Slim RTL printing is better integrated: print_rtl_with_bb takes
>> flags and uses dump_rtl_slim if TDF_SLIM is passed. The same happens
>> in rtl_dump_bb, which always dumps non-slim RTL without this patch.
>>
>> Bootstrapped on powerpc64-unknown-linux-gnu. Testing will probably
>> reveal some test suite pattern mismatches, and I also still want to
>> bootstrap&test this on x86_64.
>> I'd like to hear what people think of the cfg-flags.def change.
>
>As it turns out, the test suite passes without new regressions on
>powerpc64-unknown-linux-gnu and on x86_64-unknown-linux-gnu.
>Apparently there aren't any patterns checking edge or bb info. Good
>for me :-)
s/anem/name/g
>> * tree-cfg.c (gimple_can_merge_blocks_p): Use EDGE_COMPLEX.
I take it you added EDGE_ABNORMAL_CALL on purpose?
>> (dump_bb_info): Removed and re-incarnated in cfg.c.
+ if (flags & TDF_COMMENT)
+ fputs (";; ", outf);
This emits an ugly trailing space, perhaps we can remove this now?
+ fprintf (outf, "%s prev block ", s_indent);
+ if (bb->prev_bb)
+ fprintf (outf, "%d, ", bb->prev_bb->index);
+ else
+ fprintf (outf, "(nil), ");
+ fprintf (outf, "next block ");
+ if (bb->next_bb)
+ fprintf (outf, "%d", bb->next_bb->index);
+
+ fputs (", flags:", outf);
This looks like it could emit oddly spaced output, think
"next block , flags:\n".
It would be nice to alway have the required spaces _before_ the
actual string in this function, imho.
cheers,
Re: [gimplefe] Construction of individual gimple statements for gimple_cond and gimple_label
On Wed, Jul 11, 2012 at 10:51:02AM +0530, Sandeep Soni wrote:
>The patch adds support for creating individual gimple statements for
>the gimple_cond and gimple_label statements.
>
>Diego, I need your help in generalizing to include all possible cases
>of these statements.
>
>Here is the ChangeLog
>
>2012-07-10 Sandeep Soni
>
> * parser.c (gp_parse_expect_op1): Tidy. Returns tree operand.
> Update all callers.
> (gp_parse_expect_op2): Likewise.
> (gp_parse_expect_true_label): Tidy. Returns a label.
> Update all callers.
> (gp_parse_expect_false_label): Likewise.
> (gp_parse_cond_stmt): Tidy. Creates and returns a gimple cond
> statement.
> (gp_parse_label_stmt): Creates and returns the gimple label statement.
>
>
>And the patch
>Index: gcc/gimple/parser.c
>===
>--- gcc/gimple/parser.c(revision 188546)
>+++ gcc/gimple/parser.c(working copy)
>
>-static void
>+static tree
> gp_parse_expect_op1 (gimple_parser *parser)
> {
> const gimple_token *next_token;
> next_token = gl_consume_token (parser->lexer);
>+ tree op1 = NULL_TREE;
I'm curious if the coding conventions were relaxed to allow for variable
declarations that are not at the beginning of a function or scope?
You seem to do this pretty often in the gimplefe..
cheers,
[Patch, Fortran] PR 49265 - allow :: for "procedure :: list"
Fortran 2008 now also allows the "::" in module interfaces: "[module]
procedure [::] procedure-name-list"
The bug is also a sign for bad quality assurance as we previously only
fixed the issue for "module procedure" and not also for "procedure".
Build and regtested on x86-64-linux.
OK for the trunk?
Tobias
2012-07-17 Tobias Burnus
Steven G. Kargl
PR fortran/49265
* decl.c (match_procedure_in_interface): Support "::" for
Fortran 2008 and later.
2012-07-17 Tobias Burnus
PR fortran/49265
* gfortran.dg/module_procedure_double_colon_3.f90: New.
* gfortran.dg/module_procedure_double_colon_4.f90: New.
diff --git a/gcc/fortran/decl.c b/gcc/fortran/decl.c
index c3644b6..c6ba43e 100644
--- a/gcc/fortran/decl.c
+++ b/gcc/fortran/decl.c
@@ -5108,6 +5113,7 @@ match_procedure_in_interface (void)
match m;
gfc_symbol *sym;
char name[GFC_MAX_SYMBOL_LEN + 1];
+ locus old_locus;
if (current_interface.type == INTERFACE_NAMELESS
|| current_interface.type == INTERFACE_ABSTRACT)
@@ -5116,6 +5122,19 @@ match_procedure_in_interface (void)
return MATCH_ERROR;
}
+ /* Check if the F2008 optional double colon appears. */
+ gfc_gobble_whitespace ();
+ old_locus = gfc_current_locus;
+ if (gfc_match ("::") == MATCH_YES)
+{
+ if (gfc_notify_std (GFC_STD_F2008, "Fortran 2008: double colon in "
+ "MODULE PROCEDURE statement at %L", &old_locus)
+ == FAILURE)
+ return MATCH_ERROR;
+}
+ else
+gfc_current_locus = old_locus;
+
for(;;)
{
m = gfc_match_name (name);
--- /dev/null 2012-07-17 07:28:04.995717470 +0200
+++ gcc/gcc/testsuite/gfortran.dg/module_procedure_double_colon_3.f90 2012-07-17 09:02:29.0 +0200
@@ -0,0 +1,16 @@
+! { dg-do compile }
+! { dg-options "-std=f2003" }
+!
+! PR fortran/49265
+!
+! Contributed by Erik Toussaint
+!
+module m1
+ implicit none
+ interface foo
+ procedure :: bar ! { dg-error "Fortran 2008: double colon in MODULE PROCEDURE statement" }
+ end interface
+contains
+ subroutine bar
+ end subroutine
+end module
--- /dev/null 2012-07-17 07:28:04.995717470 +0200
+++ gcc/gcc/testsuite/gfortran.dg/module_procedure_double_colon_4.f90 2012-07-17 09:07:04.0 +0200
@@ -0,0 +1,16 @@
+! { dg-do compile }
+! { dg-options "-std=f2008" }
+!
+! PR fortran/49265
+!
+! Contributed by Erik Toussaint
+!
+module m1
+ implicit none
+ interface foo
+ procedure :: bar ! "::" is valid since Fortran 2008
+ end interface
+contains
+ subroutine bar
+ end subroutine
+end module
[Patch, Fortran] PR53985 add missing case to -Wc-binding-type
gfortran always warned for BIND(C) procedures if one used "integer",
"integer(4)" etc. instead of "integer(c_int)". While the latter is
surely more portable than the former, all of them are identical on
nearly all systems. Hence, the other versions are rahter widely used.
In order to reduce the clutter due to default warnings, since GCC 4.8
there is a new warning -Wc-binding-type, which is turned off by default.
However, for some reason, it misses the most common case. That's now
fixed in the attachment. I also corrected the wording.
Build and regtested on x86-64-gnu-linux.
OK for the trunk?
Tobias
2012-07-17 Tobias Burnus
PR fortran/53985
* decl.c (gfc_verify_c_interop_param): Make warning conditional
on -Wc-binding-type works and improve the wording.
2012-07-17 Tobias Burnus
PR fortran/53985
* gfortran.dg/bind_c_usage_26.f90: New.
* gfortran.dg/bind_c_procs.f03: Add dg-options "-Wc-binding-type".
* gfortran.dg/bind_c_usage_13.f03: Ditto.
* gfortran.dg/bind_c_usage_18.f90: Ditto.
* gfortran.dg/interop_params.f03: Ditto.
diff --git a/gcc/fortran/decl.c b/gcc/fortran/decl.c
index c3644b6..c6ba43e 100644
--- a/gcc/fortran/decl.c
+++ b/gcc/fortran/decl.c
@@ -1027,8 +1032,8 @@ gfc_verify_c_interop_param (gfc_symbol *sym)
"because it is polymorphic",
sym->name, &(sym->declared_at),
sym->ns->proc_name->name);
- else
- gfc_warning ("Variable '%s' at %L is a parameter to the "
+ else if (gfc_option.warn_c_binding_type)
+ gfc_warning ("Variable '%s' at %L is a dummy argument of the "
"BIND(C) procedure '%s' but may not be C "
"interoperable",
sym->name, &(sym->declared_at),
--- /dev/null 2012-07-17 07:28:04.995717470 +0200
+++ gcc/gcc/testsuite/gfortran.dg/bind_c_usage_26.f90 2012-07-17 09:05:56.0 +0200
@@ -0,0 +1,14 @@
+! { dg-do compile }
+!
+! PR fortran/53985
+!
+! Check that the (default) -Wno-c-binding-type works
+! and no warning is printed.
+!
+! With -Wc-binding-type, one gets:
+! Warning: Variable 'x' at (1) is a dummy argument to the BIND(C) procedure
+! 'test' but may not be C interoperable )
+!
+subroutine test(x) bind(C)
+ integer :: x
+end subroutine test
diff --git a/gcc/testsuite/gfortran.dg/bind_c_procs.f03 b/gcc/testsuite/gfortran.dg/bind_c_procs.f03
index eaf0672..3bb6ea3 100644
--- a/gcc/testsuite/gfortran.dg/bind_c_procs.f03
+++ b/gcc/testsuite/gfortran.dg/bind_c_procs.f03
@@ -1,4 +1,5 @@
! { dg-do compile }
+! { dg-options "-Wc-binding-type" }
module bind_c_procs
use, intrinsic :: iso_c_binding, only: c_int
diff --git a/gcc/testsuite/gfortran.dg/bind_c_usage_13.f03 b/gcc/testsuite/gfortran.dg/bind_c_usage_13.f03
index d89963d..b8c2261 100644
--- a/gcc/testsuite/gfortran.dg/bind_c_usage_13.f03
+++ b/gcc/testsuite/gfortran.dg/bind_c_usage_13.f03
@@ -1,5 +1,5 @@
! { dg-do compile }
-! { dg-options "-fdump-tree-original" }
+! { dg-options "-fdump-tree-original -Wc-binding-type" }
!
! PR fortran/34079
! Character bind(c) arguments shall not pass the length as additional argument
diff --git a/gcc/testsuite/gfortran.dg/bind_c_usage_18.f90 b/gcc/testsuite/gfortran.dg/bind_c_usage_18.f90
index 2bce215..ede9f60 100644
--- a/gcc/testsuite/gfortran.dg/bind_c_usage_18.f90
+++ b/gcc/testsuite/gfortran.dg/bind_c_usage_18.f90
@@ -1,4 +1,5 @@
! { dg-do compile }
+! { dg-options "-Wc-binding-type" }
!
! PR fortran/38160
!
diff --git a/gcc/testsuite/gfortran.dg/interop_params.f03 b/gcc/testsuite/gfortran.dg/interop_params.f03
index ea3dada..6eafba0 100644
--- a/gcc/testsuite/gfortran.dg/interop_params.f03
+++ b/gcc/testsuite/gfortran.dg/interop_params.f03
@@ -1,4 +1,5 @@
! { dg-do compile }
+! { dg-options "-Wc-binding-type" }
module interop_params
use, intrinsic :: iso_c_binding
[Patch, Fortran] PR52101 Fix obsolescent warning
gfortran warns (with -std=) for the obsolescence of
character*5 ...
which is correct. However, it also warns when using
character name*5
which is not (yet) obsolescent.
Fixed by the attached patch. In comment 5 you find Steve's version of
the patch, which I only saw after writing my patch. The only difference
seems to be the name of the parameter. Steve uses "entity_decl".
Build and regtested on x86-64-gnu-linux.
OK for the trunk?
Tobias
2012-07-17 Tobias Burnus
PR fortran/52101
* decl.c (match_char_length): Extra argument, show obsolenscent
warning only if *length is used after the typename.
(variable_decl, gfc_match_char_spec): Update call
2012-07-17 Tobias Burnus
PR fortran/52101
* gfortran.dg/oldstyle_4.f90: New.
diff --git a/gcc/fortran/decl.c b/gcc/fortran/decl.c
index c3644b6..c6ba43e 100644
--- a/gcc/fortran/decl.c
+++ b/gcc/fortran/decl.c
@@ -723,7 +727,7 @@ syntax:
char_len_param_value in parenthesis. */
static match
-match_char_length (gfc_expr **expr, bool *deferred)
+match_char_length (gfc_expr **expr, bool *deferred, bool obsolenscent_check)
{
int length;
match m;
@@ -739,8 +743,9 @@ match_char_length (gfc_expr **expr, bool *deferred)
if (m == MATCH_YES)
{
- if (gfc_notify_std (GFC_STD_F95_OBS, "Obsolescent feature: "
- "Old-style character length at %C") == FAILURE)
+ if (obsolenscent_check
+ && gfc_notify_std (GFC_STD_F95_OBS, "Obsolescent feature: "
+ "Old-style character length at %C") == FAILURE)
return MATCH_ERROR;
*expr = gfc_get_int_expr (gfc_default_integer_kind, NULL, length);
return m;
@@ -1849,7 +1854,7 @@ variable_decl (int elem)
if (current_ts.type == BT_CHARACTER)
{
- switch (match_char_length (&char_len, &cl_deferred))
+ switch (match_char_length (&char_len, &cl_deferred, false))
{
case MATCH_YES:
cl = gfc_new_charlen (gfc_current_ns, NULL);
@@ -2411,7 +2416,7 @@ gfc_match_char_spec (gfc_typespec *ts)
/* Try the old-style specification first. */
old_char_selector = 0;
- m = match_char_length (&len, &deferred);
+ m = match_char_length (&len, &deferred, true);
if (m != MATCH_NO)
{
if (m == MATCH_YES)
--- /dev/null 2012-07-17 07:28:04.995717470 +0200
+++ gcc/gcc/testsuite/gfortran.dg/oldstyle_4.f90 2012-07-17 08:49:00.0 +0200
@@ -0,0 +1,13 @@
+! { dg-do compile }
+! { dg-options "-std=f95" }
+!
+! PR fortran/52101
+!
+! Contributed by John Harper
+!
+program foo
+ character*10 s! { dg-warning "Obsolescent feature: Old-style character length" }
+ charactert*10 ! Still okay
+ s = 'foo'
+ t = 'bar'
+end program foo
Re: [Patch, Fortran] PR 49265 - allow :: for "procedure :: list"
Hi Tobias, > Fortran 2008 now also allows the "::" in module interfaces: "[module] > procedure [::] procedure-name-list" > > The bug is also a sign for bad quality assurance as we previously only fixed > the issue for "module procedure" and not also for "procedure". > > Build and regtested on x86-64-linux. > OK for the trunk? certainly ok. Thanks for the fix! Cheers, Janus
Re: [gimplefe] Construction of individual gimple statements for gimple_cond and gimple_label
On Tue, Jul 17, 2012 at 1:22 PM, Bernhard Reutner-Fischer wrote: > > I'm curious if the coding conventions were relaxed to allow for variable > declarations that are not at the beginning of a function or scope? > > You seem to do this pretty often in the gimplefe.. > > cheers, Not really. I guess, I am the one at fault for this. I will ensure the existing code is fixed so that the conventions are followed. Thanks for pointing it out. -- Cheers Sandy
Re: Fix PR c++/19351 (operator new[] overflow)
On 06/26/2012 04:29 PM, Florian Weimer wrote: Bootstrapped and tested on x86_86-unknown-linux-gnu, with no new regressions (this time including Java). Okay for trunk? Ping? -- Florian Weimer / Red Hat Product Security Team
Re: [Patch, Fortran] PR52101 Fix obsolescent warning
Hi, > gfortran warns (with -std=) for the obsolescence of > character*5 ... > which is correct. However, it also warns when using > character name*5 > which is not (yet) obsolescent. > > Fixed by the attached patch. In comment 5 you find Steve's version of the > patch, which I only saw after writing my patch. The only difference seems to > be the name of the parameter. Steve uses "entity_decl". > > Build and regtested on x86-64-gnu-linux. > OK for the trunk? I think this is also ok (and close to obvious). Thanks! Btw, I am about to commit a cleanup patch regarding gfc_notify_std (any minute now) ... Cheers, Janus
Re: [PATCH 1/2] gcc symbol database
Yunfeng ZHANG writes:
> Please allow me to resend former sample:
> #define Z(a) a
> #define Y Z
> #define X(p) p + Y
> X(1)(2);
> The flow is:
> 1) `X' -- leader macro token by macro_start_expand.
> 2) `(', `1', `)' -- macro tokens, by cb_lex_token.
> 3) macro_end_arg.
> 4) `1', `+' -- macro replacement tokens, by symdb_cpp_token.
> 5) `(', `2', `)' -- macro tokens, by cb_lex_token.
> 6) macro_end_arg.
> 7) `2' -- macro replacement tokens, by symdb_cpp_token.
> 8) macro_end_expand.
>
> The thing I emphasized here is cb_lex_token is set by macro_start_expand
> intern -- it isn't valid anytime.
It took me a couple of minutes to understand what you meant here, so
please let me re-phrase to make sure I got it.
You are saying that the callback function of the cb_lex_token event is
set by the callback function of the macro_start_expand event.
Is that correct?
> So
> buff = funlike_invocation_p (pfile, node, &pragma_buff,
> ...
> if (buff == NULL)
> {
> ...
> }
> if macro_start_expand is moved to the clause block `buff != NULL', it's too
> later to set cb_lex_token because funlike_invocation_p has read some macro
> tokens.
Then for function-like macros, you can move the call to
macro_start_expand into funlike_invocation_p, right before it calls
collect_args (collect_args is the function that reads the macro
arguments).
And this makes me wonder why you'd need the second parameter of
macro_start_expand (the token). I believe you should have all the
information you need with the first, second, and last parameter. As I
said in my previous email, you can get the file offset of the token in
your client code by doing 'file_offset = line + column'. So that token
should not be needed. Thus, calling macro_start_expand from inside
funlike_invocation_p once you are sure the expansion of the macro is
going to take place, is possible.
For non-function-like macros, you can call macro_start_expand after the block
if (macro->fun_like)
{
inside enter_macro_context.
> Of course I can remove macro_end_arg totally, because from the sample, it's
> the
> fact that macro tokens aren't always before any macro replacement tokens. But
> macro_end_expand must be prepared to deal with cancel case.
I still think that with the plan above, you don't need any cancel case
because macro_start_expand is going to be called only when we know the
macro is going to be expanded.
--
Dodji
[Patch ARM] Turn on sched-pressure by default on the ARM architecture.
Hi,
After benchmarking on a number of cores and measuring good
improvements across the board on the Cortex-A9 , on some cores
(Cortex M) we saw no great improvements but no regressions either, we
should just turn this on by default for the ARM port as in general it
appears to give us a good win. Theoretically there's no reason why
this will not benefit us by default on single issue machines as it
prevents the first sched pass from having excessive register pressure.
I have turned this on by default for O1_PLUS level of optimization so
that if someone uses -O1 -fschedule-insns they get the benefit of
having sched-pressure on by default.
Applied.
Thanks,
Ramana
2012-07-17 Ramana Radhakrishnan
Ulrich Weigand
* common/config/arm/arm-common.c (arm_option_optimization_table):
Enable -fsched-pressure by default while optimizing.
* config/arm/arm.c (arm_option_override): Use the alternate scheduler
pressure algorithm by default.
Index: gcc/common/config/arm/arm-common.c
===
--- gcc/common/config/arm/arm-common.c (revision 189562)
+++ gcc/common/config/arm/arm-common.c (working copy)
@@ -35,6 +35,7 @@
/* Enable section anchors by default at -O1 or higher. */
{ OPT_LEVELS_1_PLUS, OPT_fsection_anchors, NULL, 1 },
{ OPT_LEVELS_1_PLUS, OPT_fomit_frame_pointer, NULL, 1 },
+{ OPT_LEVELS_1_PLUS, OPT_fsched_pressure, NULL, 1 },
{ OPT_LEVELS_NONE, 0, NULL, 0 }
};
Index: gcc/config/arm/arm.c
===
--- gcc/config/arm/arm.c(revision 189562)
+++ gcc/config/arm/arm.c(working copy)
@@ -2009,6 +2009,11 @@
global_options.x_param_values,
global_options_set.x_param_values);
+ /* Use the alternative scheduling-pressure algorithm by default. */
+ maybe_set_param_value (PARAM_SCHED_PRESSURE_ALGORITHM, 2,
+ global_options.x_param_values,
+ global_options_set.x_param_values);
+
/* Register global variables with the garbage collector. */
arm_add_gc_roots ();
}
Re: [patch][rfc] Clean up CFG dumping
On Mon, Jul 16, 2012 at 9:55 PM, Steven Bosscher wrote: > On Mon, Jul 16, 2012 at 5:57 PM, Steven Bosscher > wrote: >> Hello, >> >> There are comments in basic-block.h that advise to update certain >> parts of the compiler if a new edge flag or basic block flag is added: >> >> -/* Always update the table in cfg.c dump_edge_info. */ >> >> and >> >> - Always update the table in cfg.c dump_bb_info. */ >> >> Apparently this is not enough, because there are more places where the >> BB flags are dumped. For instance, cfg.c:dump_cfg_bb_info does not >> handle BB_MODIFIED, BB_VISITED, and BB_IN_TRANSACTION, and >> dump_bb_info doesn't even exist in cfg.c (it's in cfgrtl.c). The flags >> also aren't documented very well in the code. >> >> Furthermore, there are multiple places where "common" (i.e. IR >> agnostic) basic block information is dumped, with some functions >> taking TDF_* flags and others not, some functions taking a FILE as the >> first argument and others as the second argument, etc. In short: >> Unnecessarily messy. >> >> The attached patch cleans up the worst of it: >> >> * A new file cfg-flags.def is used to define the BB_* and EDGE_* >> flags. The names are the full string of the name of the flag in >> uppercase, that's a change from before. I can add a separate name >> field to DEF_EDGE_FLAG and DEF_BB_FLAG if necessary. >> >> * Now that there is dumpfile.h for the TDF_* masks, it's easier to use >> them everywhere. I have added one new flag to dump with the ";;" >> prefix (I think it should be used in more places, but that's something >> for later, perhaps). >> >> * All basic block header/footer and edge dumping is consolidated in >> dump_edge_info and dump_bb_info. This affects GIMPLE dump the most, >> because it uses a different form of dumping for basic block >> predecessors and successors. I expect some fall-out in the test suite >> (patterns that no longer match) that I'll have to address before the >> patch is ready for mainline. >> >> * Slim RTL printing is better integrated: print_rtl_with_bb takes >> flags and uses dump_rtl_slim if TDF_SLIM is passed. The same happens >> in rtl_dump_bb, which always dumps non-slim RTL without this patch. >> >> Bootstrapped on powerpc64-unknown-linux-gnu. Testing will probably >> reveal some test suite pattern mismatches, and I also still want to >> bootstrap&test this on x86_64. >> I'd like to hear what people think of the cfg-flags.def change. > > As it turns out, the test suite passes without new regressions on > powerpc64-unknown-linux-gnu and on x86_64-unknown-linux-gnu. > Apparently there aren't any patterns checking edge or bb info. Good > for me :-) > > OK for trunk? Nice. Ok! Thanks, Richard. > Ciao! > Steven > > > > > > > > >> * dumpfile.h (TDF_COMMENT): New define. >> * basic-block.h (EDGE_FALLTHRU, EDGE_ABNORMAL, EDGE_ABNORMAL_CALL, >> EDGE_EH, EDGE_FAKE, EDGE_DFS_BACK, EDGE_CAN_FALLTHRU, >> EDGE_IRREDUCIBLE_LOOP, EDGE_SIBCALL, EDGE_LOOP_EXIT, EDGE_TRUE_VALUE, >> EDGE_FALSE_VALUE, EDGE_EXECUTABLE, EDGE_CROSSING, EDGE_PRESERVE): >> Move to new file cfg-flags.h. >> (enum cfg_edge_flags): New enum, using cfg-flags.h. >> (EDGE_ALL_FLAGS): Compute value automatically. >> (BB_NEW, BB_REACHABLE, BB_IRREDUCIBLE_LOOP, BB_SUPERBLOCK, >> BB_DISABLE_SCHEDULE, BB_HOT_PARTITION, BB_COLD_PARTITION, >> BB_DUPLICATED, BB_NON_LOCAL_GOTO_TARGET, BB_RTL, >> BB_FORWARDER_BLOCK, BB_NONTHREADABLE_BLOCK, BB_MODIFIED, BB_VISITED, >> BB_IN_TRANSACTION): Move to new file cfg-flags.h. >> (enum bb_flags): Rename to cfg_bb_flags. Use cfg-flags.h. >> (BB_ALL_FLAGS): New, compute value automatically. >> (dump_bb_info): Update prototype. >> (dump_edge_info): Update prototype. >> * cfg-flags.h: New file. >> * cfg.c (dump_edge_info): Take flags argument. Be verbose only if >> TDF_DETAILS and not TDF_SLIM. Include cfg-flags.h for bitnames. >> Check that the edge flags are within the range of EDGE_ALL_FLAGS. >> (debug_bb): Update dump_bb call. >> (dump_cfg_bb_info): Remove. >> (dump_bb_info): New function. Use cfg-flags.h for bitnames. >> Adjust verbosity using TDF_* flags. Check that the basic block flags >> are within the range of BB_ALL_FLAGS. >> (brief_dump_cfg): Use dump_bb_info instead of dump_cfg_bb_info. >> * cfghooks.h (struct cfghooks): Update dump_bb hook, take a FILE >> first for consistency with other dump functions. >> (dump_bb): Update prototype accordingly. >> * cfghooks.c: Include dumpfile.h. >> (verify_flow_info): Update dump_edge_info calls. >> (dump_bb): Take a flags argument and pass it around. >> Use dump_bb_info to dump common information about a basic block. >> (dump_flow_info): Moved here from cfgrtl.c. Make IL agnostic. >> (debug_flow_info): Moved her
[aarch64] Remove __ARM_EABI__ code.
I committed this patch to the aarch64 branch to remove unused __ARM_EABI__ gated code. MarcusIndex: libgcc/config/aarch64/sfp-machine.h === --- libgcc/config/aarch64/sfp-machine.h (revision 189563) +++ libgcc/config/aarch64/sfp-machine.h (revision 189564) @@ -78,43 +78,3 @@ # define strong_alias(name, aliasname) _strong_alias(name, aliasname) # define _strong_alias(name, aliasname) \ extern __typeof (name) aliasname __attribute__ ((alias (#name))); - -#ifdef __ARM_EABI__ -/* Rename functions to their EABI names. */ -/* The comparison functions need wrappers for EABI semantics, so - leave them unmolested. */ -#define __negsf2 __aeabi_fneg -#define __subsf3 __aeabi_fsub -#define __addsf3 __aeabi_fadd -#define __floatunsisf __aeabi_ui2f -#define __floatsisf __aeabi_i2f -#define __floatundisf __aeabi_ul2f -#define __floatdisf __aeabi_l2f -#define __mulsf3 __aeabi_fmul -#define __divsf3 __aeabi_fdiv -#define __unordsf2 __aeabi_fcmpun -#define __fixsfsi __aeabi_f2iz -#define __fixunssfsi __aeabi_f2uiz -#define __fixsfdi __aeabi_f2lz -#define __fixunssfdi __aeabi_f2ulz -#define __floatdisf __aeabi_l2f - -#define __negdf2 __aeabi_dneg -#define __subdf3 __aeabi_dsub -#define __adddf3 __aeabi_dadd -#define __floatunsidf __aeabi_ui2d -#define __floatsidf __aeabi_i2d -#define __extendsfdf2 __aeabi_f2d -#define __truncdfsf2 __aeabi_d2f -#define __floatundidf __aeabi_ul2d -#define __floatdidf __aeabi_l2d -#define __muldf3 __aeabi_dmul -#define __divdf3 __aeabi_ddiv -#define __unorddf2 __aeabi_dcmpun -#define __fixdfsi __aeabi_d2iz -#define __fixunsdfsi __aeabi_d2uiz -#define __fixdfdi __aeabi_d2lz -#define __fixunsdfdi __aeabi_d2ulz -#define __floatdidf __aeabi_l2d - -#endif /* __ARM_EABI__ */ Index: libgcc/ChangeLog.aarch64 === --- libgcc/ChangeLog.aarch64 (revision 189563) +++ libgcc/ChangeLog.aarch64 (revision 189564) @@ -1,3 +1,7 @@ +2012-07-17 Marcus Shawcroft + + * config/aarch64/sfp-machine.h (__ARM_EABI__): Remove. + 2012-06-08 Jim MacArthur * config.host
[Ada] Add new debug procedure psloc
Add a new debug procedure psloc, to display a source location.
Tested on x86_64-pc-linux-gnu, committed on trunk
2012-07-17 Tristan Gingold
* treepr.ads (psloc): Declare.
* treepr.adb (psloc): New debug procedure to print a sloc.
(Print_Sloc): New procedure, from ...
(Print_Node_Subtree): ... this. Call Print_Sloc.
Index: treepr.adb
===
--- treepr.adb (revision 189565)
+++ treepr.adb (working copy)
@@ -6,7 +6,7 @@
-- --
-- B o d y --
-- --
--- Copyright (C) 1992-2011, Free Software Foundation, Inc. --
+-- Copyright (C) 1992-2012, Free Software Foundation, Inc. --
-- --
-- GNAT is free software; you can redistribute it and/or modify it under --
-- terms of the GNU General Public License as published by the Free Soft- --
@@ -188,6 +188,9 @@
-- level and the bars used to link list elements). In addition, for lines
-- other than the first, an additional character Prefix_Char is output.
+ procedure Print_Sloc (Loc : Source_Ptr);
+ -- Print the human readable representation of Loc
+
function Serial_Number (Id : Int) return Nat;
-- Given a Node_Id, List_Id or Elist_Id, returns the previously assigned
-- serial number, or zero if no serial number has yet been assigned.
@@ -887,7 +890,6 @@
Field_To_Be_Printed : Boolean;
Prefix_Str_Char : String (Prefix_Str'First .. Prefix_Str'Last + 1);
- Sfile : Source_File_Index;
Fmt : UI_Format;
begin
@@ -933,20 +935,7 @@
Print_Str (Prefix_Str_Char);
Print_Str ("Sloc = ");
- if Sloc (N) = Standard_Location then
-Print_Str ("Standard_Location");
-
- elsif Sloc (N) = Standard_ASCII_Location then
-Print_Str ("Standard_ASCII_Location");
-
- else
-Sfile := Get_Source_File_Index (Sloc (N));
-Print_Int (Int (Sloc (N)) - Int (Source_Text (Sfile)'First));
-Write_Str (" ");
-Write_Location (Sloc (N));
- end if;
-
- Print_Eol;
+ Print_Sloc (Sloc (N));
end if;
-- Print Chars field if present
@@ -1397,6 +1386,30 @@
Print_Term;
end Print_Node_Subtree;
+
+ -- Print_Sloc --
+
+
+ procedure Print_Sloc (Loc : Source_Ptr) is
+ Sfile : Source_File_Index;
+
+ begin
+ if Loc = Standard_Location then
+ Print_Str ("Standard_Location");
+
+ elsif Loc = Standard_ASCII_Location then
+ Print_Str ("Standard_ASCII_Location");
+
+ else
+ Sfile := Get_Source_File_Index (Loc);
+ Print_Int (Int (Loc) - Int (Source_Text (Sfile)'First));
+ Write_Str (" ");
+ Write_Location (Loc);
+ end if;
+
+ Print_Eol;
+ end Print_Sloc;
+
---
-- Print_Str --
---
@@ -1524,6 +1537,16 @@
Print_Node (N, Label, ' ');
end Print_Tree_Node;
+ ---
+ -- psloc --
+ ---
+
+ procedure psloc (Loc : Source_Ptr) is
+ begin
+ Phase := Printing;
+ Print_Sloc (Loc);
+ end psloc;
+
-- pt --
Index: treepr.ads
===
--- treepr.ads (revision 189565)
+++ treepr.ads (working copy)
@@ -6,7 +6,7 @@
-- --
-- S p e c --
-- --
--- Copyright (C) 1992-2011, Free Software Foundation, Inc. --
+-- Copyright (C) 1992-2012, Free Software Foundation, Inc. --
-- --
-- GNAT is free software; you can redistribute it and/or modify it under --
-- terms of the GNU General Public License as published by the Free Soft- --
@@ -71,6 +71,10 @@
pragma Export (Ada, ppp);
-- Same as Print_Node_Subtree
+ procedure psloc (Loc : Source_Ptr);
+ pragma Export (Ada, psloc);
+ -- Prints the sloc Loc
+
-- The following are no longer needed; you can use pp or ppp instead
procedure pe (E : Elist_Id);
[PATCH] Avoid zext/sext directly from hard registers during expansion (PR rtl-optimization/53942)
Hi!
The following testcase ICEs on i?86, because combiner sees a zero extension
of the likely spilled cx register generated during expansion and as it is
not a simple register move, propagates it into a use many insns later in the
function, enlarging thus the lifetime of the hard register and causing RA
failure on a register in between the two that needs to use that particular
hard register.
cant_combine_insn_p only special cases simple register moves out of or into
likely spilled hard registers. The following patch fixes it by using
roughly the same condition to decide if it is ok to emit a zero or sign
extension directly from the hard register or if it is better to first copy
the hard register into a pseudo (then combiner (and fwprop etc.) seem to do
the right thing).
Bootstrapped/regtested on x86_64-linux and i686-linux, on both I've verified
it doesn't affect code generation for cc1plus (appart from function.o
obviously), libstdc++.so and libgcj.so. Ok for trunk (and perhaps after a
while for the 4.7 branch)?
2012-07-17 Jakub Jelinek
PR rtl-optimization/53942
* function.c (assign_parm_setup_reg): Avoid zero/sign extension
directly from likely spilled non-fixed hard registers, move them
to pseudo first.
* gcc.dg/pr53942.c: New test.
--- gcc/function.c.jj 2012-06-25 08:38:26.0 +0200
+++ gcc/function.c 2012-07-16 13:41:52.847928315 +0200
@@ -2988,11 +2988,26 @@ assign_parm_setup_reg (struct assign_par
&& insn_operand_matches (icode, 1, op1))
{
enum rtx_code code = unsignedp ? ZERO_EXTEND : SIGN_EXTEND;
- rtx insn, insns;
+ rtx insn, insns, t = op1;
HARD_REG_SET hardregs;
start_sequence ();
- insn = gen_extend_insn (op0, op1, promoted_nominal_mode,
+ /* If op1 is a hard register that is likely spilled, first
+force it into a pseudo, otherwise combiner might extend
+its lifetime too much. */
+ if (GET_CODE (t) == SUBREG)
+ t = SUBREG_REG (t);
+ if (REG_P (t)
+ && HARD_REGISTER_P (t)
+ && ! TEST_HARD_REG_BIT (fixed_reg_set, REGNO (t))
+ && targetm.class_likely_spilled_p (REGNO_REG_CLASS (REGNO (t
+ {
+ t = gen_reg_rtx (GET_MODE (op1));
+ emit_move_insn (t, op1);
+ }
+ else
+ t = op1;
+ insn = gen_extend_insn (op0, t, promoted_nominal_mode,
data->passed_mode, unsignedp);
emit_insn (insn);
insns = get_insns ();
--- gcc/testsuite/gcc.dg/pr53942.c.jj 2012-06-15 19:53:34.312404791 +0200
+++ gcc/testsuite/gcc.dg/pr53942.c 2012-07-17 11:26:48.863053287 +0200
@@ -0,0 +1,34 @@
+/* PR rtl-optimization/53942 */
+/* { dg-do compile } */
+/* { dg-options "-O2" } */
+/* { dg-additional-options "-mtune=pentium2" { target { { i?86-*-* x86_64-*-*
} && ia32 } } } */
+
+struct S
+{
+ unsigned short w[3];
+ unsigned int x, y;
+};
+
+struct S *baz (void);
+
+__attribute__ ((noinline))
+static unsigned char
+foo (struct S *x, unsigned char y)
+{
+ unsigned char c = 0;
+ unsigned char v = x->w[0];
+ c |= v;
+ v = ((x->w[1]) & (1 << y)) ? 1 : 0;
+ c |= v << 1;
+ v = ((x->w[2]) & 0xff) & (1 << y);
+ c |= v << 2;
+ return c;
+}
+
+void
+bar (void)
+{
+ struct S *s = baz ();
+ s->x = foo (s, 6);
+ s->y = foo (s, 7);
+}
Jakub
[Ada] Consistent tree decoration to import C++ classes
For consistency, entity Ada.Tags.Prim_Ptr must be decorated with attribute Is_Dispatch_Table_Entity to help the backend generating code for dispatching calls. This decoration was missing in CPP_Types thus causing problems in some architectures (for example, IA-64/Linux). Tested on x86_64-pc-linux-gnu, committed on trunk 2012-07-17 Javier Miranda * exp_disp.adb (Make_DT): Remove decoration of Ada.Tags entities. (Make_Tags): Add decoration of Ada.Tags entities. Index: exp_disp.adb === --- exp_disp.adb(revision 189565) +++ exp_disp.adb(working copy) @@ -6255,12 +6255,6 @@ Elmt : Elmt_Id; begin --- Ensure that entities Prim_Ptr and Predef_Prims_Table_Ptr have --- the decoration required by the backend - -Set_Is_Dispatch_Table_Entity (RTE (RE_Prim_Ptr)); -Set_Is_Dispatch_Table_Entity (RTE (RE_Predef_Prims_Table_Ptr)); - -- Object declarations Elmt := First_Elmt (DT_Decl); @@ -7137,6 +7131,12 @@ Set_Ekind(DT_Ptr, E_Variable); Set_Related_Type (DT_Ptr, Typ); + -- Ensure that entities Prim_Ptr and Predef_Prims_Table_Ptr have + -- the decoration required by the backend + + Set_Is_Dispatch_Table_Entity (RTE (RE_Prim_Ptr)); + Set_Is_Dispatch_Table_Entity (RTE (RE_Predef_Prims_Table_Ptr)); + -- For CPP types there is no need to build the dispatch tables since -- they are imported from the C++ side. If the CPP type has an IP then -- we declare now the variable that will store the copy of the C++ tag.
Re: [Patch, Fortran] gfc_notify_std cleanup
On 07/17/2012 11:42 AM, Janus Weil wrote:
here is a patch which makes 'gfc_notify_std' print the relevant
version of the Fortran standard automatically when issuing
errors/warnings. Up to now this had to be done manually and was
forgotten (or inconsistent)
I think the patch is a good idea. Some comments from glancing at the patch.
-error_print (_("Error:"), _(gmsgid), argp);
+strcpy (buffer, "Error:");
This seems to break internationalization.
+case GFC_STD_F2008_TS:
+ strcat (buffer, " TS 29113:");
+ break;
That's currently correct. However, there is another post-Fortran 2008
Technical Specification in preparation. (Coarray extensions.)* How
should be handled? "TS 29113 or TS 12345:"?
+case GFC_STD_LEGACY:
+ strcat (buffer, " Extension:");
I'd prefer something like "Legacy extension:" (Or "Legacy:").
"Extension" makes it very hard to find the flag in the compiler to
enable this feature (-std=legacy). Recall that the default -std=gnu
doesn't include legacy.
+ strcat (buffer, " Fortran 2008 obsolescent feature:");
I'd rather have something like "Obsolescent since Fortran 2008:".
Especially when using -std=f2015,* the wording seems to be not ideal.
Additionally, your patch won't work with internationalization. For
"Fortran 2008" that's probably okay, but for this one, I think it should
be translatable.
Tobias
* Coarrays and Fortran 2015: See schedule at
ftp://ftp.nag.co.uk/sc22wg5/N1901-N1950/N1925.txt
Requirements document for the Coarray TS:
ftp://ftp.nag.co.uk/sc22wg5/N1901-N1950/N1930.txt
[Ada] Fix potential access violation in Adjust routine
Tested on x86_64-pc-linux-gnu, committed on trunk 2012-07-17 Pascal Obry * s-regexp.adb (Adjust): Fix access violation in Adjust. Index: s-regexp.adb === --- s-regexp.adb(revision 189565) +++ s-regexp.adb(working copy) @@ -6,7 +6,7 @@ -- -- -- B o d y -- -- -- --- Copyright (C) 1999-2010, AdaCore -- +-- Copyright (C) 1999-2012, AdaCore -- -- -- -- GNAT is free software; you can redistribute it and/or modify it under -- -- terms of the GNU General Public License as published by the Free Soft- -- @@ -100,10 +100,12 @@ Tmp : Regexp_Access; begin - Tmp := new Regexp_Value (Alphabet_Size => R.R.Alphabet_Size, - Num_States=> R.R.Num_States); - Tmp.all := R.R.all; - R.R := Tmp; + if R.R /= null then + Tmp := new Regexp_Value (Alphabet_Size => R.R.Alphabet_Size, + Num_States=> R.R.Num_States); + Tmp.all := R.R.all; + R.R := Tmp; + end if; end Adjust; -
[Ada] Contracts on imported subprograms
Currently pre/postconditions are enforced by means of expansions in the body
of the corresponding subprogram. If the subprogram is imported there is no
available body on which to insert the checking code, and thr user should be
warned that the contracts will not be enforced.
THe command:
gcc -c -gnat12 -gnata hello.ads
must yield:
hello.ads:7:13:
warning: pre/post conditions on imported subprogram are not enforced
hello.ads:12:13:
warning: pre/post conditions on imported subprogram are not enforced
---
with Ada.Containers.Indefinite_Doubly_Linked_Lists;
with Ada.Finalization; use Ada.Finalization;
with Interfaces.C; use Interfaces.C;
package Hello is
function F2 (I : Interfaces.C.int) return Interfaces.C.int
with Pre => I /= 10,
Post => F2'Result /= 0;
pragma Import (C, F2, "f");
function F (I : Interfaces.C.int) return Interfaces.C.int
with Pre => I /= 10,
Post => F'Result /= 0,
Import,
Convention => C,
External_Name => "f";
end Hello;
Tested on x86_64-pc-linux-gnu, committed on trunk
2012-07-17 Ed Schonberg
* freeze.adb (Freeze_Entity): Warn if an imported subprogram
has pre/post conditions, because these will not be enforced.
Index: freeze.adb
===
--- freeze.adb (revision 189565)
+++ freeze.adb (working copy)
@@ -3026,6 +3026,21 @@
end if;
end if;
end;
+
+ -- Pre/Post conditions are implemented through a subprogram in
+ -- the corresponding body, and therefore are not checked on an
+ -- imported subprogram for which the body is not available.
+
+ if Is_Subprogram (E)
+ and then Is_Imported (E)
+ and then Present (Contract (E))
+ and then Present (Spec_PPC_List (Contract (E)))
+ then
+ Error_Msg_NE ("pre/post conditions on imported subprogram "
+ & "are not enforced?",
+ E, Spec_PPC_List (Contract (E)));
+ end if;
+
end if;
-- Must freeze its parent first if it is a derived subprogram
[Ada] Minor tweak to expanded code for transient objects
This change makes it so that the finalization blocks generated for controlled transient objects, as well the final raise statement, are all wrapped into a block, so as to make it easier for the back-end to understand the construct. No functional changes. Tested on x86_64-pc-linux-gnu, committed on trunk 2012-07-17 Eric Botcazou * exp_ch7.adb (Process_Transient_Objects): Put all the finalization blocks and the final raise statement into a wrapper block. Index: exp_ch7.adb === --- exp_ch7.adb (revision 189565) +++ exp_ch7.adb (working copy) @@ -4390,6 +4390,7 @@ Obj_Id: Entity_Id; Obj_Ref : Node_Id; Obj_Typ : Entity_Id; + Prev_Fin : Node_Id := Empty; Stmt : Node_Id; Stmts : List_Id; Temp_Id : Entity_Id; @@ -4428,7 +4429,6 @@ Fin_Decls := New_List; Build_Object_Declarations (Fin_Data, Fin_Decls, Loc); - Insert_List_Before_And_Analyze (First_Object, Fin_Decls); Built := True; end if; @@ -4560,15 +4560,25 @@ Exception_Handlers => New_List ( Build_Exception_Handler (Fin_Data; - Insert_After_And_Analyze (Last_Object, Fin_Block); + -- The single raise statement must be inserted after all the + -- finalization blocks. And we put everything into a wrapper + -- block to clearly expose the construct to the back-end. - -- The raise statement must be inserted after all the - -- finalization blocks. + if Present (Prev_Fin) then + Insert_Before_And_Analyze (Prev_Fin, Fin_Block); + else + Insert_After_And_Analyze (Last_Object, +Make_Block_Statement (Loc, + Declarations => Fin_Decls, + Handled_Statement_Sequence => +Make_Handled_Sequence_Of_Statements (Loc, + Statements => New_List (Fin_Block; - if No (Last_Fin) then Last_Fin := Fin_Block; end if; + Prev_Fin := Fin_Block; + -- When the associated node is an array object, the expander may -- sometimes generate a loop and create transient objects inside -- the loop.
[Ada] Fix to 64-bit atomic operation failures on ppc-linux
This patch fixes failures due to the use of 64-bit atomic operations on ppc-linux. Undo of the previous patch for 64-bit atomic operations only. Note: this does NOT address the failure on ppc-darwin, which will be addressed by another patch soon. Tested on x86_64-pc-linux-gnu, committed on trunk 2012-07-17 Vincent Pucci * s-atopri.adb (Lock_Free_Try_Write_X): Atomic_Compare_Exchange_X replaced by Sync_Compare_And_Swap_X. (Lock_Free_Try_Write_64): Removed. * s-atopri.ads (Sync_Compare_And_Swap_X): Replaces previous routine Atomic_Compare_Exchange_X. (Lock_Free_Read_64): Renaming of Atomic_Load_64. (Lock_Free_Try_Write_64): Renaming of Sync_Compare_And_Swap_64. Index: s-atopri.adb === --- s-atopri.adb(revision 189565) +++ s-atopri.adb(working copy) @@ -44,7 +44,7 @@ begin if Expected /= Desired then - Actual := Atomic_Compare_Exchange_8 (Ptr, Expected, Desired); + Actual := Sync_Compare_And_Swap_8 (Ptr, Expected, Desired); if Actual /= Expected then Expected := Actual; @@ -68,7 +68,7 @@ begin if Expected /= Desired then - Actual := Atomic_Compare_Exchange_16 (Ptr, Expected, Desired); + Actual := Sync_Compare_And_Swap_16 (Ptr, Expected, Desired); if Actual /= Expected then Expected := Actual; @@ -92,7 +92,7 @@ begin if Expected /= Desired then - Actual := Atomic_Compare_Exchange_32 (Ptr, Expected, Desired); + Actual := Sync_Compare_And_Swap_32 (Ptr, Expected, Desired); if Actual /= Expected then Expected := Actual; @@ -102,28 +102,4 @@ return True; end Lock_Free_Try_Write_32; - - - -- Lock_Free_Try_Write_64 -- - - - function Lock_Free_Try_Write_64 - (Ptr : Address; - Expected : in out uint64; - Desired : uint64) return Boolean - is - Actual : uint64; - - begin - if Expected /= Desired then - Actual := Atomic_Compare_Exchange_64 (Ptr, Expected, Desired); - - if Actual /= Expected then -Expected := Actual; -return False; - end if; - end if; - - return True; - end Lock_Free_Try_Write_64; end System.Atomic_Primitives; Index: s-atopri.ads === --- s-atopri.ads(revision 189565) +++ s-atopri.ads(working copy) @@ -62,16 +62,36 @@ -- GCC built-in atomic primitives -- - function Atomic_Compare_Exchange_8 + function Atomic_Load_8 + (Ptr : Address; + Model : Mem_Model := Seq_Cst) return uint8; + pragma Import (Intrinsic, Atomic_Load_8, "__atomic_load_1"); + + function Atomic_Load_16 + (Ptr : Address; + Model : Mem_Model := Seq_Cst) return uint16; + pragma Import (Intrinsic, Atomic_Load_16, "__atomic_load_2"); + + function Atomic_Load_32 + (Ptr : Address; + Model : Mem_Model := Seq_Cst) return uint32; + pragma Import (Intrinsic, Atomic_Load_32, "__atomic_load_4"); + + function Atomic_Load_64 + (Ptr : Address; + Model : Mem_Model := Seq_Cst) return uint64; + pragma Import (Intrinsic, Atomic_Load_64, "__atomic_load_8"); + + function Sync_Compare_And_Swap_8 (Ptr : Address; Expected : uint8; Desired : uint8) return uint8; pragma Import (Intrinsic, - Atomic_Compare_Exchange_8, + Sync_Compare_And_Swap_8, "__sync_val_compare_and_swap_1"); -- ??? Should use __atomic_compare_exchange_1 (doesn't work yet): - -- function Atomic_Compare_Exchange_8 + -- function Sync_Compare_And_Swap_8 --(Ptr : Address; -- Expected : Address; -- Desired : uint8; @@ -79,53 +99,33 @@ -- Success_Model : Mem_Model := Seq_Cst; -- Failure_Model : Mem_Model := Seq_Cst) return Boolean; -- pragma Import (Intrinsic, - -- Atomic_Compare_Exchange_8, + -- Sync_Compare_And_Swap_8, -- "__atomic_compare_exchange_1"); - function Atomic_Compare_Exchange_16 + function Sync_Compare_And_Swap_16 (Ptr : Address; Expected : uint16; Desired : uint16) return uint16; pragma Import (Intrinsic, - Atomic_Compare_Exchange_16, + Sync_Compare_And_Swap_16, "__sync_val_compare_and_swap_2"); - function Atomic_Compare_Exchange_32 + function Sync_Compare_And_Swap_32 (Ptr : Address; Expected : uint32; Desired : uint32) return uint32; pragma Import (Intrinsic, - Atomic_Compare_Exchange_32, + Sync_Compare_And_Swap_32, "__sync_val_compare_and_s
[Ada] gnatmake -s -gnatn1 always recompiles
This patch ensures that when -gnatn1 is used gnatmake -s will not always recompile. Tested on x86_64-pc-linux-gnu, committed on trunk 2012-07-17 Vincent Celier * switch-m.adb (Normalize_Compiler_Switches): Recognize new switches -gnatn1 and -gnatn2. Index: switch-m.adb === --- switch-m.adb(revision 189565) +++ switch-m.adb(working copy) @@ -6,7 +6,7 @@ -- -- -- B o d y -- -- -- --- Copyright (C) 2001-2011, Free Software Foundation, Inc. -- +-- Copyright (C) 2001-2012, Free Software Foundation, Inc. -- -- -- -- GNAT is free software; you can redistribute it and/or modify it under -- -- terms of the GNU General Public License as published by the Free Soft- -- @@ -236,7 +236,7 @@ -- One-letter switches when 'a' | 'A' | 'b' | 'B' | 'c' | 'C' | 'E' | 'f' | - 'F' | 'g' | 'h' | 'H' | 'I' | 'L' | 'n' | 'N' | + 'F' | 'g' | 'h' | 'H' | 'I' | 'L' | 'N' | 'o' | 'p' | 'P' | 'q' | 'Q' | 'r' | 's' | 'S' | 't' | 'u' | 'U' | 'v' | 'x' | 'X' | 'Z' => Storing (First_Stored) := C; @@ -423,6 +423,24 @@ return; end if; + -- -gnatn may be -gnatn, -gnatn1 or -gnat2 + + when 'n' => + Last_Stored := First_Stored; + Storing (Last_Stored) := 'n'; + Ptr := Ptr + 1; + + if Ptr <= Max + and then Switch_Chars (Ptr) in '1' .. '2' + then +Last_Stored := Last_Stored + 1; +Storing (Last_Stored) := Switch_Chars (Ptr); +Ptr := Ptr + 1; + end if; + + Add_Switch_Component + (Storing (Storing'First .. Last_Stored)); + -- -gnatR may be followed by '0', '1', '2' or '3', -- then by 's'
[Ada] Fix nit in raise-gcc.c
In some cases, a cleanup action was missed.
No reduced testcase found.
Tested on x86_64-pc-linux-gnu, committed on trunk
2012-07-17 Tristan Gingold
* raise-gcc.c (get_call_site_action_for): Remove useless init
expression for p.
(get_action_description_for): Do not overwrite action->kind.
Index: raise-gcc.c
===
--- raise-gcc.c (revision 189565)
+++ raise-gcc.c (working copy)
@@ -710,7 +710,7 @@
else
{
_uleb128_t cs_lp, cs_action;
- const unsigned char *p = region->call_site_table;
+ const unsigned char *p;
/* Let the caller know there may be an action to take, but let it
determine the kind. */
@@ -947,13 +947,16 @@
passed (to follow the ABI). */
if (!(uw_phase & _UA_FORCE_UNWIND))
{
+ enum action_kind act;
+
/* See if the filter we have is for an exception which
matches the one we are propagating. */
_Unwind_Ptr choice = get_ttype_entry_for (region, ar_filter);
- action->kind = is_handled_by (choice, gnat_exception);
- if (action->kind != nothing)
+ act = is_handled_by (choice, gnat_exception);
+ if (act != nothing)
{
+ action->kind = act;
action->ttype_filter = ar_filter;
return;
}
[PATCH 1/2] if-to-switch conversion pass
Richard, attached patch implements an if-to-switch conversion tree pass pass_if_to_switch. I will follow up this email with an infrastructure patch that provides double_int_popcount and popcount_hwi. The pass detects chains of ifs like this: ... : ... if (D.1993_3 == 32) goto ; else goto ; : if (D.1993_3 == 13) goto ; else goto ; : if (D.1993_3 == 10) goto ; else goto ; : if (D.1993_3 == 9) goto ; else goto ; ... and converts them into a switch statement: ... : ... switch (D.1993_3) , case 9: , case 10: , case 13: , case 32: > ... There are 2 motivations to convert chains of ifs to switches (as discussed in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46935 ): - to reduce the control flow graph - to take advantage of the efficient shift-and-bit-test implementations of switches This pass takes the first approach as optimization measure, so it doesn't test if the resulting switch can be converted into a shift-and-bit-test implementation. pass_if_to_switch is on by default at O2 and higher, and controlled by -ftree-if-to-switch-conversion. The pass works as follows: - it analyzes all bbs - it forms if-chains out of bbs - it transforms if-chains into switches The pass is run twice, once before pass_convert_switch, and once after pass_pre. By running it before pass_convert_switch, we take advantage of the shift-and-bit-test implementation of switches (the conversion has recently been moved from pass_expand to pass_convert_switch). By running it after pass_pre, we take advantage of blocks collapsed by tail merging, creating opportunities for if-to-switch conversion. Test-case if-to-switch-5.c (the example from PR14799) is transformed into a switch by the second run of the pass, not the first. Perhaps instead of the second run of pass_if_to_switch, we could run tail-merge (maybe without using gvn?) before the first run of pass_if_to_switch. That would also allow if-to-switch-5.c to be converted to a shift-and-bit-test. For all the new test-cases, the if-chain is transformed into a switch by the pass. For test-cases if-to-switch.c, if-to-switch-2.c and if-to-switch-4.c the if-chains are subsequently transformed into shift-and-bit-tests. The if-chain from the test-case if-to-switch-3.c (the example from PR46935) is transformed into the following switch: ... switch (cD.1707_2(D)) , case 0 ... 32: , case 34: , case 39: , case 44: , case 46: , case 58: , case 59 ... 60: , case 62: , case 92: > ... This switch is currently not transformed into a shift-and-bit-test since the resulting range is too large, but the divide-and-conquer approach mentioned in http://gcc.gnu.org/ml/gcc-patches/2012-06/msg01960.html could split off the 0..32 test and implement the rest as shift-and-bit-test. Bootstrapped and reg-tested (Ada inclusive) on x86_64. OK for trunk? Thanks, - Tom 2012-07-17 Tom de Vries * tree-if-switch-conversion.c: New pass. * tree-pass.h (pass_if_to_switch): Declare. * common.opt (ftree-if-to-switch-conversion): New switch. * opts.c (default_options_table): Set flag_tree_if_to_switch_conversion at -O2 and higher. * passes.c (init_optimization_passes): Use new pass. * doc/invoke.texi (-ftree-if-to-switch-conversion): New item. (Optimization Options, option -O2): Add -ftree-if-to-switch-conversion. * Makefile.in (OBJS): Add tree-if-switch-conversion.o. (tree-if-switch-conversion.o): New rule. * gcc.dg/if-to-switch.c: New test. * gcc.dg/if-to-switch.c-2: Same. * gcc.dg/if-to-switch.c-3: Same. * gcc.dg/if-to-switch.c-4: Same. * gcc.dg/if-to-switch.c-5: Same. * gcc.dg/tree-ssa/vrp33.c: Run with -fno-tree-if-to-switch-conversion. * gcc.dg/tree-ssa/vrp63.c: Same. * gcc.dg/tree-ssa/vrp64.c: Same. Index: gcc/tree-pass.h === --- gcc/tree-pass.h (revision 189508) +++ gcc/tree-pass.h (working copy) @@ -577,6 +577,7 @@ extern struct gimple_opt_pass pass_early extern struct gimple_opt_pass pass_inline_parameters; extern struct gimple_opt_pass pass_update_address_taken; extern struct gimple_opt_pass pass_convert_switch; +extern struct gimple_opt_pass pass_if_to_switch; /* The root of the compilation pass tree, once constructed. */ extern struct opt_pass *all_passes, *all_small_ipa_passes, *all_lowering_passes, Index: gcc/tree-if-switch-conversion.c === --- /dev/null (new file) +++ gcc/tree-if-switch-conversion.c (revision 0) @@ -0,0 +1,1218 @@ +/* Convert a chain of if statements into a switch statement. + Copyright (C) 2010, 2011, 2012 Free Software Foundation, Inc. + Contributed by Tom de Vries + +This file is part of GCC. + +
Re: [PING] Re: [RFC, ivopts] fix bugs in ivopts address cost computation
On Wed, Jul 4, 2012 at 6:35 PM, Sandra Loosemore wrote: > On 06/05/2012 10:34 AM, Sandra Loosemore wrote: > >> 2012-06-05 Sandra Loosemore >> >> gcc/ >> * tree-ssa-loop-ivopts.c (comp_cost): Make complexity field >> signed. >> Update comments to indicate this is for addressing mode >> complexity. >> (new_cost): Make signedness of parameters match comp_cost fields. >> (compare_costs): Prefer higher complexity, not lower, per >> documentation >> of TARGET_ADDRESS_COST. >> (multiplier_allowed_in_address_p): Use (+ (* reg1 ratio) reg2) to >> probe for valid ratios, rather than just (* reg1 ratio). >> (get_address_cost): Rewrite to eliminate precomputation and >> caching. >> Use target's address cost for autoinc forms if possible. Only >> attempt >> sym_present -> var_present cost conversion if the sym_present >> form >> is not legitimate; amortize setup cost over loop iterations. >> Adjust complexity computation. >> (get_computation_cost_at): Adjust call to get_address_cost. Do >> not >> mess with complexity for non-address expressions. >> (determine_use_iv_cost_address): Initialize can_autoinc. >> (autoinc_possible_for_pair): Likewise. > > > On 06/13/2012 01:52 PM, Sandra Loosemore wrote: >> >> >> Might somebody be willing to review the patch as posted? > > > Ping? Original post with patch is here: > > http://gcc.gnu.org/ml/gcc-patches/2012-06/msg00319.html Can you update the patch and numbers based on what Bill did for straight-line strength reduction which re-uses this analysis/caching part? Thanks, Richard. > -Sandra >
[aarch64] Omit lsl #0 on movi and movn
I've committed this patch to the aarch64 branch to suppress the output
of an lsl #0 suffix on movi and mvni instructions.
MarcusIndex: gcc/ChangeLog.aarch64
===
--- gcc/ChangeLog.aarch64 (revision 189570)
+++ gcc/ChangeLog.aarch64 (working copy)
@@ -1,3 +1,9 @@
+2012-07-17 Marcus Shawcroft
+
+ * config/aarch64/aarch64-simd.md (*aarch64_simd_mov):
+ Do not emit lsl for a shift of 0.
+ (*aarch64_simd_mov): Likwise.
+
2012-07-04 Tejas Belagod
* config/aarch64/aarch64-linux.h (LINUX_TARGET_LINK_SPEC): Rename
Index: gcc/config/aarch64/aarch64-simd.md
===
--- gcc/config/aarch64/aarch64-simd.md (revision 189570)
+++ gcc/config/aarch64/aarch64-simd.md (working copy)
@@ -398,23 +398,26 @@
int width;
static char templ[40];
int shift = 0, mvn = 0;
+ const char *mnemonic;
+ int length = 0;
is_valid =
aarch64_simd_immediate_valid_for_move (operands[1], mode,
&operands[1], &width, &widthc,
&mvn, &shift);
gcc_assert (is_valid != 0);
- if (mvn == 0)
- {
- if (widthc != 'd')
- snprintf (templ, sizeof (templ), "movi\t%%0.%d%c, %%1, lsl %d ",
- 64 / width, widthc, shift);
- else
- snprintf (templ, sizeof (templ), "movi\t%%d0, %%1");
- }
+
+ mnemonic = mvn ? "mvni" : "movi";
+ if (widthc != 'd')
+ length += snprintf (templ, sizeof (templ),
+ "%s\t%%0.%d%c, %%1",
+ mnemonic, 64 / width, widthc);
else
- snprintf (templ, sizeof (templ), "mvni\t%%0.%d%c, %%1, lsl %d",
- 64 / width, widthc, shift);
+ length += snprintf (templ, sizeof (templ), "%s\t%%d0, %%1", mnemonic);
+
+ if (shift != 0)
+ length += snprintf (templ + length, sizeof (templ) - length,
+ ", lsl %d", shift);
return templ;
}
default: gcc_unreachable ();
@@ -454,12 +457,14 @@
&operands[1], &width, &widthc,
&mvn, &shift);
gcc_assert (is_valid != 0);
- if (mvn == 0)
- snprintf (templ, sizeof (templ), "movi\t%%0.%d%c, %%1, lsl %d ",
+ if (shift)
+ snprintf (templ, sizeof (templ), "%s\t%%0.%d%c, %%1, lsl %d",
+ mvn ? "mvni" : "movi",
128 / width, widthc, shift);
else
- snprintf (templ, sizeof (templ), "mvni\t%%0.%d%c, %%1, lsl %d",
- 128 / width, widthc, shift);
+ snprintf (templ, sizeof (templ), "%s\t%%0.%d%c, %%1",
+ mvn ? "mvni" : "movi",
+ 128 / width, widthc);
return templ;
}
default: gcc_unreachable ();
Re: [PATCH 2/2] if-to-switch conversion pass -- infrastructure
On 17/07/12 13:21, Tom de Vries wrote:
> attached patch implements an if-to-switch conversion tree pass
> pass_if_to_switch. I will follow up this email with an infrastructure patch
> that
> provides double_int_popcount and popcount_hwi.
Bootstrapped and reg-tested (Ada inclusive) on x86_64, with pass_if_to_switch as
only client.
OK for trunk?
Thanks,
- Tom
2012-07-16 Tom de Vries
* double-int.h (double_int_popcount): New inline function.
* hwint.c (popcount_hwi): New function.
* hwint.h (popcount_hwi): Declare function. New inline function.
Index: gcc/double-int.h
===
--- gcc/double-int.h (revision 189508)
+++ gcc/double-int.h (working copy)
@@ -284,6 +284,14 @@ double_int_equal_p (double_int cst1, dou
return cst1.low == cst2.low && cst1.high == cst2.high;
}
+/* Return number of set bits of CST. */
+
+static inline int
+double_int_popcount (double_int cst)
+{
+ return popcount_hwi (cst.high) + popcount_hwi (cst.low);
+}
+
/* Legacy interface with decomposed high/low parts. */
Index: gcc/hwint.c
===
--- gcc/hwint.c (revision 189508)
+++ gcc/hwint.c (working copy)
@@ -107,6 +107,22 @@ ffs_hwi (unsigned HOST_WIDE_INT x)
return 1 + floor_log2 (x & -x);
}
+/* Return the number of set bits in X. */
+
+int
+popcount_hwi (unsigned HOST_WIDE_INT x)
+{
+ int i, ret = 0;
+
+ for (i = 0; i < sizeof (x); i += 1)
+{
+ ret += x & 1;
+ x >>= 1;
+}
+
+ return ret;
+}
+
#endif /* GCC_VERSION < 3004 */
Index: gcc/hwint.h
===
--- gcc/hwint.h (revision 189508)
+++ gcc/hwint.h (working copy)
@@ -179,6 +179,9 @@ extern int clz_hwi (unsigned HOST_WIDE_I
extern int ctz_hwi (unsigned HOST_WIDE_INT x);
extern int ffs_hwi (unsigned HOST_WIDE_INT x);
+/* Return the number of set bits in X. */
+extern int popcount_hwi (unsigned HOST_WIDE_INT x);
+
/* Return log2, or -1 if not exact. */
extern int exact_log2 (unsigned HOST_WIDE_INT);
@@ -231,6 +234,18 @@ ffs_hwi (unsigned HOST_WIDE_INT x)
# endif
}
+static inline int
+popcount_hwi (unsigned HOST_WIDE_INT x)
+{
+# if HOST_BITS_PER_WIDE_INT == HOST_BITS_PER_LONG
+ return __builtin_popcountl (x);
+# elif HOST_BITS_PER_WIDE_INT == HOST_BITS_PER_LONGLONG
+ return __builtin_popcountll (x);
+# else
+ return __builtin_popcount (x);
+# endif
+}
+
static inline int
floor_log2 (unsigned HOST_WIDE_INT x)
{
Re: [PATCH 2/2] if-to-switch conversion pass -- infrastructure
On Tue, Jul 17, 2012 at 1:25 PM, Tom de Vries wrote: > On 17/07/12 13:21, Tom de Vries wrote: >> attached patch implements an if-to-switch conversion tree pass >> pass_if_to_switch. I will follow up this email with an infrastructure patch >> that >> provides double_int_popcount and popcount_hwi. > > Bootstrapped and reg-tested (Ada inclusive) on x86_64, with pass_if_to_switch > as > only client. > > OK for trunk? Ok. Thanks, Richard. > Thanks, > - Tom > > 2012-07-16 Tom de Vries > > * double-int.h (double_int_popcount): New inline function. > * hwint.c (popcount_hwi): New function. > * hwint.h (popcount_hwi): Declare function. New inline function.
[aarch64] Fix misplaced parenthesis
I've committed this patch to the aarch64 branch to fix a misplaced
parenthesis.
MarcusIndex: gcc/ChangeLog.aarch64
===
--- gcc/ChangeLog.aarch64 (revision 189571)
+++ gcc/ChangeLog.aarch64 (working copy)
@@ -1,5 +1,10 @@
2012-07-17 Marcus Shawcroft
+ * config/aarch64/aarch64.c (aarch64_rtx_costs):
+ Move misplaced parenthesis.
+
+2012-07-17 Marcus Shawcroft
+
* config/aarch64/aarch64-simd.md (*aarch64_simd_mov):
Do not emit lsl for a shift of 0.
(*aarch64_simd_mov): Likwise.
Index: gcc/config/aarch64/aarch64.c
===
--- gcc/config/aarch64/aarch64.c (revision 189570)
+++ gcc/config/aarch64/aarch64.c (working copy)
@@ -4191,7 +4191,7 @@
op1 = XEXP (x, 1);
*cost = COSTS_N_INSNS (1);
- if (GET_MODE_CLASS (GET_MODE (x) == MODE_INT))
+ if (GET_MODE_CLASS (GET_MODE (x)) == MODE_INT)
{
if (CONST_INT_P (op1)
&& exact_log2 (INTVAL (op1)) > 0)
Re: [C++ Patch] for c++/51214
On Wed, Jun 27, 2012 at 7:38 PM, Fabien Chêne wrote: > 2012/6/7 Fabien Chêne : > [...] >> ... committed as rev 188294. >> I will backport it to 4.7 when it unfreezes. > > ... Eventually backported as rev 189021. This causes PR53995. Richard. > -- > Fabien
Re: [Ada] Fix to 64-bit atomic operation failures on ppc-linux
On 07/17/2012 06:15 AM, Arnaud Charlet wrote: This patch fixes failures due to the use of 64-bit atomic operations on ppc-linux. Undo of the previous patch for 64-bit atomic operations only. Note: this does NOT address the failure on ppc-darwin, which will be addressed by another patch soon. Tested on x86_64-pc-linux-gnu, committed on trunk 2012-07-17 Vincent Pucci * s-atopri.adb (Lock_Free_Try_Write_X): Atomic_Compare_Exchange_X replaced by Sync_Compare_And_Swap_X. (Lock_Free_Try_Write_64): Removed. * s-atopri.ads (Sync_Compare_And_Swap_X): Replaces previous routine Atomic_Compare_Exchange_X. (Lock_Free_Read_64): Renaming of Atomic_Load_64. (Lock_Free_Try_Write_64): Renaming of Sync_Compare_And_Swap_64. What is the nature of the atomic failures using the __atomic_compare_exchange built-in? Does it have anything to do with the expected value being returned by pointer? Andrew
Re: CRIS atomics revisited 4/4: give up on alignment of atomic data, RFC for is_lock_free hook
On 07/15/2012 11:49 PM, Hans-Peter Nilsson wrote:
Well, give up by default that is, and fix it up in a helper
function in glibc to hold a global byte-sized atomic lock for
the duration. (Sorry!) Yes, this means that
fold_builtin_atomic_always_lock_free is wrong. It knows about
alignment in general but doesn't handle the case where the
default alignment of the underlying type is too small for atomic
accesses, and should probably be augmented by a target hook,
alternatively, change the allow_libcall argument in the call to
can_compare_and_swap_p to false. I guess I should open a PR for
this and add a test-case. Later.
I set it up to eventually handle alignment issues, but didn't really
know any details of what to do when, or how. Input was rather lacking
at the time and there was a time crunch, so I just punted on it in 4.7
at the tree level and targets did their own thing. The library idea was
new enough that the standards guys couldnt/wouldn't give me a straight
answer since it hadn't really been thought through I don't think. My
apologies if I misrepresent anyone there :-)
The basic problem you are dealing with is a 4 byte object that is not
aligned properly, so the lock-free instructions don't work on it., but
'always_lock_free' says "yes, that type is lock free". Then in the
library, its implemented via a lock? Is that approximately it? or is
there an additional issue?
The original intention was that __atomic{is,always}_lock_free takes the
size and a pointer to the object, and the alignment of the pointer
object would be checked at compile time to see if it is always
compatible with size. (so a char pointer to a 4 byte object would fail
that test). which would means 'always_lock_free' should return false,
and in turn a call to 'is_lock_free' would generate a library call and
check the alignment at runtime of the object to determine what to do.
The library implementation of all the other __atomic operations would
check 'is_lock_free' to see whether they need to use a lock, or whether
they can use available lock-free sequences/syscalls.
Some confusion around the standard surfaced and the intention from the
standard point of view appeared to be that 'is_lock_free' should be true
or false ALL the time for a given type.This possibly is related to
the separation of gcc's built-ins from the implementation details of the
standard (ie the standard uses the built-ins but only with aligned
objects, but those built-ins can also still be used outside the standard
in more chaotic ways)
So in the end, i wasn't sure what to do and ran out of time. Making it
better for 4.8 would be goodness. Is there a fatal flaw in the original
(unimplemented) intention? if so, can it be fixed without changing the API?
Any PR's you open related this this, copy me on them and I'll try to get
them addressed.
Andrew
Re: [PATCH 0/7] Clean up widen mult even/odd
On 07/10/2012 02:09 AM, Jakub Jelinek wrote:
> On Tue, Jul 10, 2012 at 10:22:44AM +0200, Richard Henderson wrote:
>> I've not touched the interface to supportable_widening_operation,
>> which is still prepared to return a CALL_EXPR and some decls. After
>> this patch set it will never do so. I'm undecided as to whether we
>> ought to be prepared for such in the future, or whether this should
>> simply go in as a completely separate patch that could in the future
>> be easily reverted.
>
> I think it would be nice to remove the support for widening operation
> calls as a follow-up, if we ever need it in the future, we can restore
> it from svn and it will simplify the callers that already handle way too
> many different cases.
The cleanup is much smaller than I hoped, since we may still generate calls via
the supportable_convert_operation and supportable_narrowing_operation paths.
Nevertheless... tested on x86_64 and committed.
r~
* tree-vect-stmts.c (supportable_widening_operation): Remove decl
parameters.
(vectorizable_conversion): Update supportable_widening_operation call.
* tree-vect-patterns.c (vect_recog_widen_mult_pattern): Likewise.
(vect_recog_widen_shift_pattern): Likewise.
* tree-vectorizer.h: Update decl.
diff --git a/gcc/tree-vect-patterns.c b/gcc/tree-vect-patterns.c
index e8ac42a..595b9b6 100644
--- a/gcc/tree-vect-patterns.c
+++ b/gcc/tree-vect-patterns.c
@@ -599,7 +599,6 @@ vect_recog_widen_mult_pattern (VEC (gimple, heap) **stmts,
tree type, half_type0, half_type1;
gimple pattern_stmt;
tree vectype, vectype_out = NULL_TREE;
- tree dummy;
tree var;
enum tree_code dummy_code;
int dummy_int;
@@ -692,8 +691,8 @@ vect_recog_widen_mult_pattern (VEC (gimple, heap) **stmts,
|| !vectype_out
|| !supportable_widening_operation (WIDEN_MULT_EXPR, last_stmt,
vectype_out, vectype,
- &dummy, &dummy, &dummy_code,
- &dummy_code, &dummy_int, &dummy_vec))
+ &dummy_code, &dummy_code,
+ &dummy_int, &dummy_vec))
return NULL;
*type_in = vectype;
@@ -1370,7 +1369,6 @@ vect_recog_widen_shift_pattern (VEC (gimple, heap)
**stmts,
tree type, half_type0;
gimple pattern_stmt;
tree vectype, vectype_out = NULL_TREE;
- tree dummy;
tree var;
enum tree_code dummy_code;
int dummy_int;
@@ -1441,9 +1439,8 @@ vect_recog_widen_shift_pattern (VEC (gimple, heap)
**stmts,
|| !vectype_out
|| !supportable_widening_operation (WIDEN_LSHIFT_EXPR, last_stmt,
vectype_out, vectype,
- &dummy, &dummy, &dummy_code,
- &dummy_code, &dummy_int,
- &dummy_vec))
+ &dummy_code, &dummy_code,
+ &dummy_int, &dummy_vec))
return NULL;
*type_in = vectype;
diff --git a/gcc/tree-vect-stmts.c b/gcc/tree-vect-stmts.c
index 2f372df..358c2d5 100644
--- a/gcc/tree-vect-stmts.c
+++ b/gcc/tree-vect-stmts.c
@@ -2410,8 +2410,8 @@ vectorizable_conversion (gimple stmt,
gimple_stmt_iterator *gsi,
case WIDEN:
if (supportable_widening_operation (code, stmt, vectype_out, vectype_in,
- &decl1, &decl2, &code1, &code2,
- &multi_step_cvt, &interm_types))
+ &code1, &code2, &multi_step_cvt,
+ &interm_types))
{
/* Binary widening operation can only be supported directly by the
architecture. */
@@ -2443,18 +2443,16 @@ vectorizable_conversion (gimple stmt,
gimple_stmt_iterator *gsi,
goto unsupported;
}
else if (!supportable_widening_operation (code, stmt, vectype_out,
- cvt_type, &decl1, &decl2,
- &codecvt1, &codecvt2,
- &multi_step_cvt,
+ cvt_type, &codecvt1,
+ &codecvt2, &multi_step_cvt,
&interm_types))
continue;
else
gcc_assert (multi_step_cvt == 0);
if (supportable_widening_operation (NOP_EXPR, stmt, cvt_type,
- vectype_in, NULL, NULL, &code1,
- &code2, &multi_step_cvt,
- &interm_types))
+ vectype_in, &code1, &code2,
+
Re: [Patch/RFC] SEH exceptions for Win64
On 07/17/2012 12:35 AM, Tristan Gingold wrote: > So, the first element of ExceptionInformation will be exc. > > Should I add a comment ? Ah right. Definitely. Otherwise I don't see anything else in the way. Kai? r~
Re: [C++ RFC / Patch] PR 51213 ("access control under SFINAE")
Hi,
On 07/16/2012 07:39 PM, Jason Merrill wrote:
On 07/14/2012 05:54 AM, Paolo Carlini wrote:
The above change of yours appear to imply that, at variance with what I
had in my first draft, perform_typedefs_access_check shouldn't really
gain a tsubst_flags_t argument, because now it's called by
instantiate_decl and instantiate_class_template_1 (from which I was
passing a true / tf_error). Makes sense?
That makes sense to me.
Excellent. Then the below (which incorporates your access7 patch)
bootstraps and regtests fine on x86_64-linux. As you can see, I'm
consistently using tsubst_flags_t parameters and, in enforce_access, I
make sure that in C++98 mode we emit hard errors even in SFINAE contexts.
Let me know how you want proceed, if you want now a ChangeLog entry for
my bits or whatelse...
Thanks!
Paolo.
///
Index: libstdc++-v3/testsuite/20_util/pair/noncopyable.cc
===
--- libstdc++-v3/testsuite/20_util/pair/noncopyable.cc (revision 0)
+++ libstdc++-v3/testsuite/20_util/pair/noncopyable.cc (revision 0)
@@ -0,0 +1,39 @@
+// { dg-do compile }
+// { dg-options "-std=gnu++11" }
+
+// Copyright (C) 2012 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library. This library 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.
+//
+// This library 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 this library; see the file COPYING3. If not see
+//
Re: [gimplefe] Construction of individual gimple statements for gimple_cond and gimple_label
On Tue, Jul 17, 2012 at 11:01 AM, Sandeep Soni wrote: > On Tue, Jul 17, 2012 at 1:22 PM, Bernhard Reutner-Fischer > wrote: >> >> I'm curious if the coding conventions were relaxed to allow for variable >> declarations that are not at the beginning of a function or scope? >> >> You seem to do this pretty often in the gimplefe.. >> >> cheers, > > Not really. I guess, I am the one at fault for this. I will ensure the > existing code is fixed so that the conventions are followed. Thanks > for pointing it out. Not so much, anymore (http://gcc.gnu.org/codingconventions.html#Variable). When gimplefe is merged into trunk, we will be using the C++ conventions which now allow this. No need to change anything, Sandy. Diego.
Re: [Patch/RFC] SEH exceptions for Win64
2012/7/17 Richard Henderson : > On 07/17/2012 12:35 AM, Tristan Gingold wrote: >> So, the first element of ExceptionInformation will be exc. >> >> Should I add a comment ? > > Ah right. Definitely. > > Otherwise I don't see anything else in the way. Kai? > > > r~ No, I don't have any objections. I just tested the patch myself with full regression-test. So patch is ok. Thanks, Kai
Re: [PATCH 1/2] if-to-switch conversion pass
On Tue, Jul 17, 2012 at 1:21 PM, Tom de Vries wrote: > Richard, > > attached patch implements an if-to-switch conversion tree pass > pass_if_to_switch. Nice. I've been working on something similar, using the paper "Efficient and Effective Branch Reordering Using Profile Data" (Mingui Yang et. al., see www.cs.fsu.edu/~whalley/papers/acmtoplas02.ps and also mentioned in tree-switch-conversion.c). The if-to-switch conversion falls out naturally from the algorithm proposed in that paper. It also proposes basic block duplication to form longer chains of if-chains to convert. I think you should compare your method to the one described in the paper, and at least reference the paper if it's somehow similar -- once upon a time it was a stated goal of tree-ssa to use algorithms close to "literature algorithms". Your approach looks very similar: smarter in some respects (the bit ranges stuff) and less sophisticated in others (no block duplication). This transformation should *not* be enabled by default at -O2. Users may have sorted the branches deliberately in a certain order, and if switch expansion results in a different order, your transformation is not an optimization. If the transformation is enabled with -fprofile-use, profile information gets lost with this transformation, because you don't have unique edges per condition anymore. This always hurts for the default case, and may also hurt "normal" cases. The Yang paper describes a value profiling method to record per-condition profile data, and I was planning to implement that as well (and also the PGO switch lowering that Freescale proposed at the GCC Summit 2006, see http://gcc.gnu.org/ml/gcc-patches/2008-04/msg02120.html). Perhaps you can have a look and see if there are some handles in the above that you can work with :-) Ciao! Steven
[PATCH] Re-work get_object_alignment (again)
I've arrived at get_object_{or_type,}alignment again looking at
PR53970. And I finally concluded we should unconditionally relying
on type-alignment on INDIRECT/MEM/TARGET_MEM_REF when we ask for
the alignment of an access (as opposed to when asking for the
alignment of an address). So the following patch removes
get_object_or_type_alignment again and folds its doings into
get_object_alignment_2 which now takes an argument to indicate
whether we compute address or object alignment.
I changed the meaning of the return value of the functions to
indicate whether the information returned is "correct". That's
used to disable the use of type-alignment knowledge when we
know for example the underlying decl and see it is not appropriately
aligned. This should mask some of the bugs in user code and
in the C frontend (at least) with regarding to packed structs.
I have bootstrapped and tested this patch on x86_64-unknown-linux-gnu
and also a variant that asserts that the alignment returned by
get_object_alignment is at least as large as that computed by
get_object_or_type_alignment (so we should not regress).
Now, back to PR53970, where #pragma pack() is used to pack a
struct. With #pragma pack() no part of the type or field-decls
have a hint that packing took place (well, their align information
tell you), which means the vectorizers use of contains_packed_reference
is not conservative enough, nor is expand_exprs use:
case BIT_FIELD_REF:
case ARRAY_RANGE_REF:
normal_inner_ref:
{
...
if (TYPE_PACKED (TREE_TYPE (TREE_OPERAND (exp, 0)))
|| (TREE_CODE (TREE_OPERAND (exp, 1)) == FIELD_DECL
&& DECL_PACKED (TREE_OPERAND (exp, 1
packedp = true;
I'm not sure if this flag is required for correctness - it's only
passed to extract_bit_field - but if it is the above code does
not work for #pragma packed structs. I suppose what should be
checked is (a few lines below the above test, after we expanded tem)
if (MEM_P (op0)
&& GET_MODE (op0) != BLKmode
&& MEM_ALIGN (op0) < GET_MODE_ALIGNMENT (GET_MODE (op0)))
packedp = true;
? I suppose packedp was computed for STRICT_ALIGNMENT targets only.
I'm not changing the above, but Eric, you should be able to produce a
#pragma packed testcase that fails on a STRICT_ALIGNMENT target?
Comments welcome, of course.
Oh, and this does not yet fix PR53970 - but I hope that I can
remove contains_packed_reference ;)
Thanks,
Richard.
2012-07-17 Richard Guenther
* tree.h (get_object_or_type_alignment): Remove.
* builtins.c (get_object_alignment_2): New function copied from
get_object_alignment_1. Take extra argument to indicate whether
we take the address of EXP. Rework to use type alignment information
if not, and return whether the result is an approximation or not.
(get_object_alignment_1): Wrap around get_object_alignment_2.
(get_pointer_alignment_1): Call get_object_alignment_2 indicating
we take the address.
(get_object_or_type_alignment): Remove.
* expr.c (expand_assignment): Call get_object_alignment.
(expand_expr_real_1): Likewise.
Index: gcc/builtins.c
===
*** gcc/builtins.c.orig 2012-07-17 12:26:37.0 +0200
--- gcc/builtins.c 2012-07-17 13:15:19.018757760 +0200
*** called_as_built_in (tree node)
*** 273,283
on the address at which an object is actually located. These two
addresses are not always the same. For example, on ARM targets,
the address &foo of a Thumb function foo() has the lowest bit set,
!whereas foo() itself starts on an even address. */
! bool
! get_object_alignment_1 (tree exp, unsigned int *alignp,
! unsigned HOST_WIDE_INT *bitposp)
{
HOST_WIDE_INT bitsize, bitpos;
tree offset;
--- 273,286
on the address at which an object is actually located. These two
addresses are not always the same. For example, on ARM targets,
the address &foo of a Thumb function foo() has the lowest bit set,
!whereas foo() itself starts on an even address.
!If ADDR_P is true we are taking the address of the memory reference EXP
!and thus cannot rely on the access taking place. */
!
! static bool
! get_object_alignment_2 (tree exp, unsigned int *alignp,
! unsigned HOST_WIDE_INT *bitposp, bool addr_p)
{
HOST_WIDE_INT bitsize, bitpos;
tree offset;
*** get_object_alignment_1 (tree exp, unsign
*** 293,340
/* Extract alignment information from the innermost object and
possibly adjust bitpos and offset. */
! if (TREE_CODE (exp) == CONST_DECL)
! exp = DECL_INITIAL (exp);
! if (DECL_P (exp)
! && TREE_CODE (exp) != LABEL_DECL)
{
! if (TREE_CODE (exp) == FUNCTION_DECL)
! {
! /* Function addresses can encod
Re: [Patch, Fortran] gfc_notify_std cleanup
I am far from being a gettext expert, but I think the new version
doesn't work. My understanding is that one can either mark strings for
translation - or one inserts a translation function call, which also
marks them for translation. In either case, the string passed to gettext
will be used as key for the translation.
On 07/17/2012 02:49 PM, Janus Weil wrote:
+ char buffer[50];
-error_print (_("Warning:"), _(gmsgid), argp);
Namely, that version passed "Warning" to the gettext library, which
returns a string with the translated version.
+strcpy (buffer, _("Warning:"));
Ditto here. Though, I think you are in danger of exceeding the buffer -
if not here, then further down. I admit that having 49 characters should
be enough, but with UTF8 one might quickly have only 24 characters - and
then it gets tight ... especially as you will strcat more output.
+ strcat (buffer, _(" Fortran 2008 obsolescent feature:"));
That would be a candidate for overflow. The current wording has 43
characters in English. Assume, e.g., the same length but in Cyrillic; I
think that's then 2*43 = 84 plus '\0' = 85 bytes!
+ error_print (buffer, _(gmsgid), argp);
Wouldn't it be simplyer to keep the error print for Warning/Error,
assign the messages to a "const char * msg" and then pass the msg to
error_print? That would be two calls to error_print, but would avoid
buffer issues, calls to strcpy/strcat, and would work with i18n.
Namely:
error_print (_("Warning:"), _(gmsgid), argp);
...
case GFC_STD_F2008_OBS:
msg = N_(" Fortran 2008 obsolescent feature:");
break;
...
error_print (_(msg), _(gmsgid), argp);
Note the N_() which marks the string as translatable without actually calling gettext. (I
think one of the header files contains "#define _ gettext".)
Okay, that won't work as one has to call error_print only once. Maybe something
like the following will work:
const char *msg, *msg2;
char *buffer;
msg = _("Warning: ");
msg2 = _("Deleted feature:");
buffer = (char *) alloca (strlen (msg) + strlen (msg2)+1);
strcpy(buffer, msg);
strcat (buffer, msg2);
error_print (buffer, _(gmsgid), argp);
where the buffer itself is not send through _().
Tobias
Re: [ARM Patch 1/3]PR53189: optimizations of 64bit logic operation with constant
Carrot, Sorry about the delayed response. On 3 July 2012 12:28, Carrot Wei wrote: > On Thu, Jun 28, 2012 at 12:14 AM, Ramana Radhakrishnan > wrote: >> On 28 May 2012 11:08, Carrot Wei wrote: >>> Hi >>> >>> This is the second part of the patches that deals with 64bit and. It >>> directly >>> extends the patterns anddi3, anddi3_insn and anddi3_neon to handle 64bit >>> constant operands. >>> >> >> Comments about const_di_ok_for_op still apply from my review of your add >> patch. >> >> However I don't see why and /ior / xor with constants that have either >> the low or high parts set can't be expanded directly into ands of >> subregs with moves of zero's or the original value especially if you >> aren't looking at doing 64 bit operations in neon .With Neon being >> used for 64 bit arithmetic it gets more interesting. >> >> Finally this should target PR target/53189. >> > > Hi Ramana > > Thanks for the review. Following is the updated patch according to > your comments. You've missed answering this part of my review :) >> However I don't see why and /ior / xor with constants that have either >> the low or high parts set can't be expanded directly into ands of >> subregs with moves of zero's or the original value especially if you >> aren't looking at doing 64 bit operations in neon .With Neon being >> used for 64 bit arithmetic it gets more interesting. Is there any reason why we don't split such cases earlier into the constituent moves and the associated ands earlier than reload in the non-Neon case? In addition, it would be good to have some tests for Thumb2 that deal with the replicated constants for Thumb2 . Can you have a look at creating some tests similar to the thumb2*replicated*.c tests in gcc.target/arm but for 64 bit constants ? regards, Ramana
Re: [PATCH 2/2] if-to-switch conversion pass -- infrastructure
On 17/07/12 13:29, Richard Guenther wrote:
> On Tue, Jul 17, 2012 at 1:25 PM, Tom de Vries wrote:
>> On 17/07/12 13:21, Tom de Vries wrote:
>>> attached patch implements an if-to-switch conversion tree pass
>>> pass_if_to_switch. I will follow up this email with an infrastructure patch
>>> that
>>> provides double_int_popcount and popcount_hwi.
>>
>> Bootstrapped and reg-tested (Ada inclusive) on x86_64, with
>> pass_if_to_switch as
>> only client.
>>
Mark pointed out that the popcount_hwi function had a bug: The loop should visit
all bits of the type but uses sizeof (type) as loop counter which returns the
number of bytes of the type.
Unit-tested and committed.
Thanks,
- Tom
2012-07-17 Tom de Vries
* hwint.c: Fix loop range.
Index: gcc/hwint.c
===
--- gcc/hwint.c (revision 189575)
+++ gcc/hwint.c (working copy)
@@ -113,8 +113,9 @@ int
popcount_hwi (unsigned HOST_WIDE_INT x)
{
int i, ret = 0;
+ size_t bits = sizeof (x) * CHAR_BIT;
- for (i = 0; i < sizeof (x); i += 1)
+ for (i = 0; i < bits; i += 1)
{
ret += x & 1;
x >>= 1;
Re: [C++ RFC / Patch] PR 51213 ("access control under SFINAE")
On 07/17/2012 08:45 AM, Paolo Carlini wrote:
-check_default_argument (tree decl, tree arg)
+check_default_argument (tree decl, tree arg, tsubst_flags_t complain)
Hmm, I don't think substitution of default arguments can cause deduction
failure; it happens after we've chosen which function to call. What was
the motivation for the default argument changes?
+tmp = error_mark_node;
Let's use a more informative name than "tmp" for these flags.
-void
-perform_deferred_access_checks (void)
+bool
+perform_deferred_access_checks (tsubst_flags_t complain)
Need to document what the return value means.
- if (complain & tf_error)
-perform_or_defer_access_check (TYPE_BINFO (context), t, t);
+ if (!perform_or_defer_access_check (TYPE_BINFO (context), t, t, complain))
+return error_mark_node;
These changes along with the enforce_access handling of cxx_dialect
break C++03 code that currently works, such as
template
class A
{
typedef T I;
};
template
void f(typename T::I);
template
void f(int);
int main()
{
f > (1);
}
Under the C++03 rules, we don't get access errors when generating
overload candidates, we get them when the function is instantiated (i.e.
in instantiate_decl).
Hmm, now that I look at the code in instantiate_decl for re-substituting
to get additional errors, I guess I should have factored that code out
into a separate function and used it in the access7 patch rather than
add handling of FNDECL_RECHECK_ACCESS_P in tsubst_decl.
Jason
[ARM] Scheduling VFP/NEON to core transfers (ping, RFC)
Hi, Whilst looking at upstreaming some of CodeSourcery/Mentor's old patches, I came across the following again, originally by Mark Shinwell but last sent upstream by Andrew Stubbs: http://gcc.gnu.org/ml/gcc-patches/2011-02/msg01431.html I've attached a new version, re-tested but not re-benchmarked (I'm not set up to do the latter just at the moment). I spent a while being quite unconvinced that this patch was a reasonable solution for the problem (of scheduling transfers between the NEON or VFP and the core unit) -- either on Cortex-A8, which the patch was originally supposed to target, or any other core version. So, this is what I came up with to try to convince myself. Handling of these transfers is unfortunately dealt with rather haphazardly on various cores. I only looked in any detail at Cortex-A8 and Cortex-A9. FAOD, I think we're principally concerned here with instructions like "movdi_vfp", which may be used to transfer either "VFP" or "NEON" register values to and from core registers, but also with movsf and friends for the "runfast"-mode case. * On Cortex-A8, instructions with "f_2_r" (nor "r_2_f") type do not participate in scheduling at all. This was probably the root of the problem the patch was trying to fix originally: this means that there is nothing to stop instructions which use the vfp/neon-to-core result from being placed directly after the transfer. (A scheduler dump shows "nothing" for the unit utilisation for these types of instruction at present.) * On Cortex-A9, the "f_2_r" and "r_2_f" types both use the (core) insn reservation "cortex_a9_fps", which produces its result after 2 cycles. The A9 TRM on infocentre.arm.com says that VFP-to-core transfers take 3 cycles, and NEON-to-core transfers take 11 cycles. * The cortex-r4f.md and cortex-m4-fpu.md scheduler descriptions seem to handle f_2_r and r_2_f sanely. So, there are generally multiple DFA descriptions in play at any given time, relating to different core units with different sets of registers, and transferring values between those cores isn't really being described properly to GCC's scheduler in a consistent way at present. Fixing this "properly", e.g. fully describing the way the NEON unit is decoupled from the core unit on the Cortex-A8, is probably impractical. But, the only cases we're concerned with at present are transfers of values from one unit to another. I think setting both "type" and "neon_type" for transfer instructions is therefore the right thing to do -- although given the above, and other restrictions (i.e. the mutual exclusion between VFP and NEON units on Cortex-A9), it's probably not a complete solution to the problem. To expand: * "type" should be set to f_2_r for MRC-type instructions because of the dependency on an earlier instruction setting the input register. * "neon_type" should be set appropriately for MRC-type instructions because following NEON instructions will have dependencies on the transferred value. * ...and vice-versa for MCR-type instructions. Incidentally other patches, probably merged from our source base, have introduced "neon_type" alongside "type" for a couple of instructions in vfp.md already: namely, *movdi_vfp and *movhf_vfp_neon: whatever we choose to do, we should be consistent. So: OK to apply? Thanks, Julian 2011-02-22 Andrew Stubbs Mark Shinwell Julian Brown gcc/ * config/arm/vfp.md (*arm_movsi_vfp, *thumb2_movsi_vfp) (*movdi_vfp_cortexa8, *movsf_vfp, *thumb2_movsf_vfp) (*movdf_vfp, *thumb2_movdf_vfp, *movsfcc_vfp) (*thumb2_movsfcc_vfp, *movdfcc_vfp, *thumb2_movdfcc_vfp): Add neon_type. * config/arm/arm.md (neon_type): Update comment. commit 44d6297b8e73eae42b3d6a0da7ca857f549049c1 Author: Julian Brown Date: Fri Jul 13 10:32:46 2012 -0700 Set neon_type for vfp-to-core transfers. diff --git a/gcc/config/arm/arm.md b/gcc/config/arm/arm.md index 382..e9da56d 100644 --- a/gcc/config/arm/arm.md +++ b/gcc/config/arm/arm.md @@ -397,8 +397,6 @@ (define_attr "ldsched" "no,yes" (const (symbol_ref "arm_ld_sched"))) ;; Classification of NEON instructions for scheduling purposes. -;; Do not set this attribute and the "type" attribute together in -;; any one instruction pattern. (define_attr "neon_type" "neon_int_1,\ neon_int_2,\ diff --git a/gcc/config/arm/vfp.md b/gcc/config/arm/vfp.md index 8369949..4a56d57 100644 --- a/gcc/config/arm/vfp.md +++ b/gcc/config/arm/vfp.md @@ -78,6 +78,7 @@ " [(set_attr "predicable" "yes") (set_attr "type" "*,*,*,*,load1,store1,r_2_f,f_2_r,fcpys,f_loads,f_stores") + (set_attr "neon_type" "*,*,*,*,*,*,neon_mcr,neon_mrc,neon_vmov,*,*") (set_attr "insn" "mov,mov,mvn,mov,*,*,*,*,*,*,*") (set_attr "pool_range" "*,*,*,*,4096,*,*,*,*,1020,*") (set_attr "neg_pool_range" "*,*,*,*,4084,*,*,*,*,1008,*")] @@ -120,6 +121,7 @@ " [(set_attr "predicable" "yes") (set_attr "type" "*,*,*,*,load1,load1,store1,st
[PATCH, ARM] Optimize vdup-constant builtins
Hi,
This patch (originally by Jie Zhang) optimizes vdup builtins which use
a constant argument into the immediate variants of the vdup
instructions, rather than generating separate immediate-loads and
register vdups, as is presently done. It also adds support for loading
floating-point constant 0.0 to such instructions, by using integer
zero-load instructions (the bit pattern is the same).
Tested with no regressions, and the new tests pass. One test needed
tweaking, since with the patch the (constant) calculations performed
now get entirely optimised away.
OK to apply?
Thanks,
Julian
ChangeLog
Jie Zhang
Julian Brown
gcc/
* config/arm/arm.c (arm_rtx_costs_1): Adjust cost for
CONST_VECTOR.
(arm_size_rtx_costs): Likewise.
(neon_valid_immediate): Add a case for double 0.0.
gcc/testsuite/
* gcc.target/arm/neon-vdup-1.c: New test case.
* gcc.target/arm/neon-vdup-2.c: New test case.
* gcc.target/arm/neon-vdup-3.c: New test case.
* gcc.target/arm/neon-vdup-4.c: New test case.
* gcc.target/arm/neon-vdup-5.c: New test case.
* gcc.target/arm/neon-vdup-6.c: New test case.
* gcc.target/arm/neon-vdup-7.c: New test case.
* gcc.target/arm/neon-vdup-8.c: New test case.
* gcc.target/arm/neon-vdup-9.c: New test case.
* gcc.target/arm/neon-vdup-10.c: New test case.
* gcc.target/arm/neon-vdup-11.c: New test case.
* gcc.target/arm/neon-vdup-12.c: New test case.
* gcc.target/arm/neon-vdup-13.c: New test case.
* gcc.target/arm/neon-vdup-14.c: New test case.
* gcc.target/arm/neon-vdup-15.c: New test case.
* gcc.target/arm/neon-vdup-16.c: New test case.
* gcc.target/arm/neon-vdup-17.c: New test case.
* gcc.target/arm/neon-vdup-18.c: New test case.
* gcc.target/arm/neon-vdup-19.c: New test case.
* gcc.target/arm/neon-combine-sub-abs-into-vabd.c: Make intrinsic
arguments non-constant.
commit 1e3a8ea7fbaed4cd6638b08fb18b951a9c02f889
Author: Julian Brown
Date: Fri Jul 13 07:13:09 2012 -0700
Optimize NEON vdup builtins.
diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index 9748dda..7eedb18 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -7608,6 +7608,17 @@ arm_rtx_costs_1 (rtx x, enum rtx_code outer, int* total, bool speed)
}
return true;
+case CONST_VECTOR:
+ if (TARGET_NEON
+ && TARGET_HARD_FLOAT
+ && outer == SET
+ && (VALID_NEON_DREG_MODE (mode) || VALID_NEON_QREG_MODE (mode))
+ && neon_immediate_valid_for_move (x, mode, NULL, NULL))
+ *total = COSTS_N_INSNS (1);
+ else
+ *total = COSTS_N_INSNS (4);
+ return true;
+
default:
*total = COSTS_N_INSNS (4);
return false;
@@ -7948,6 +7959,17 @@ arm_size_rtx_costs (rtx x, enum rtx_code code, enum rtx_code outer_code,
*total = COSTS_N_INSNS (4);
return true;
+case CONST_VECTOR:
+ if (TARGET_NEON
+ && TARGET_HARD_FLOAT
+ && outer_code == SET
+ && (VALID_NEON_DREG_MODE (mode) || VALID_NEON_QREG_MODE (mode))
+ && neon_immediate_valid_for_move (x, mode, NULL, NULL))
+ *total = COSTS_N_INSNS (1);
+ else
+ *total = COSTS_N_INSNS (4);
+ return true;
+
case HIGH:
case LO_SUM:
/* We prefer constant pool entries to MOVW/MOVT pairs, so bump the
@@ -8768,11 +8790,14 @@ vfp3_const_double_rtx (rtx x)
vmov i6417
vmov f3218aBbc defgh000
+ vmov f3219
For case 18, B = !b. Representable values are exactly those accepted by
vfp3_const_double_index, but are output as floating-point numbers rather
than indices.
+ For case 19, we will change it to vmov.i32 when assembling.
+
Variants 0-5 (inclusive) may also be used as immediates for the second
operand of VORR/VBIC instructions.
@@ -8829,7 +8854,7 @@ neon_valid_immediate (rtx op, enum machine_mode mode, int inverse,
rtx el0 = CONST_VECTOR_ELT (op, 0);
REAL_VALUE_TYPE r0;
- if (!vfp3_const_double_rtx (el0))
+ if (!vfp3_const_double_rtx (el0) && el0 != CONST0_RTX (GET_MODE (el0)))
return -1;
REAL_VALUE_FROM_CONST_DOUBLE (r0, el0);
@@ -8851,7 +8876,10 @@ neon_valid_immediate (rtx op, enum machine_mode mode, int inverse,
if (elementwidth)
*elementwidth = 0;
- return 18;
+ if (el0 == CONST0_RTX (GET_MODE (el0)))
+ return 19;
+ else
+ return 18;
}
/* Splat vector constant out into a byte vector. */
diff --git a/gcc/testsuite/gcc.target/arm/neon-combine-sub-abs-into-vabd.c b/gcc/testsuite/gcc.target/arm/neon-combine-sub-abs-into-vabd.c
index ad6ba75..fe3d78b 100644
--- a/gcc/testsuite/gcc.target/arm/neon-combine-sub-abs-into-vabd.c
+++ b/gcc/testsuite/gcc.target/arm/neon-combine-sub-abs-into-vabd.c
@@ -4,10 +4,8 @@
/* { dg-add-options arm_neon } */
#include
-float32x2_t f_sub_abs_to_vabd_32()
Re: [Patch, Fortran] gfc_notify_std cleanup
Hi,
> Ditto here. Though, I think you are in danger of exceeding the buffer - if
> not here, then further down.
admitted - the buffer length could clearly be a problem (in connection
with translation).
> Wouldn't it be simplyer to keep the error print for Warning/Error, assign
> the messages to a "const char * msg" and then pass the msg to error_print?
> That would be two calls to error_print, but would avoid buffer issues, calls
> to strcpy/strcat, and would work with i18n.
Actually I also tried something like this, but couldn't get it to work
(the biggest problem being that stuff will not show up in one line
after the locus printout).
> Okay, that won't work as one has to call error_print only once. Maybe
> something like the following will work:
>
> const char *msg, *msg2;
> char *buffer;
> msg = _("Warning: ");
> msg2 = _("Deleted feature:");
> buffer = (char *) alloca (strlen (msg) + strlen (msg2)+1);
> strcpy(buffer, msg);
> strcat (buffer, msg2);
> error_print (buffer, _(gmsgid), argp);
>
> where the buffer itself is not send through _().
With this you are almost back to my last version, except that you
allocate the buffer dynamically.
Cheers,
Janus
Re: [PATCH, ARM] Fix length attributes for sync.md patterns
On 16/07/12 14:45, Ulrich Weigand wrote:
> Hello,
>
> when testing an out-of-tree patch I ran into a latent bug.
> The symptom is error messages along the lines of
> /tmp/cc6q0E3x.s:38: Error: co-processor offset out of range
> caused by an out-of-range reference to a literal pool constant.
> This happens only with -O0.
>
> This turns out to caused by insn_and_split patterns in sync.md
> used to represent atomic instructions. Those will (must) always
> be split (usually into some form of compare-and-swap loop). If
> optimization is on, this split happens shortly after reload,
> before literal pool placement is finalized.
>
> However, when building with -O0, this split is done very late;
> in fact it happens *after* the machine-dependent reorg pass
> where literal pools are handled. This means that this pass
> sees the atomic patterns as single insns, and unfortunately,
> since they have no length attribute, they are handled as if
> they had a default length of 4 bytes.
>
> But since those patterns in the end will expand to at least
> 5-9 actual machine instructions, this default drastically
> underestimates the code size, causing the out of range
> references.
>
> The patch below adds length attributes giving conservative
> estimates of the final resulting code sizes. (They could
> probably be made more specific, but since this is relevant
> only for -O0, that's probably not worth the effort.)
>
> This fixes the problems I was seeing.
>
> Tested on arm-linux-gnueabi with no regressions.
>
> OK for mainline?
>
Hmm, I wonder if we should just unconditionally call split_all_insns()
at the start of md_reorg when -O0. This would address your problem, but
have the added benefit that the length calculations would be more
accurate. We're going to have to split the insns anyway during output,
so why not get it over and done with...
R.
> Bye,
> Ulrich
>
>
> ChangeLog:
>
> * config/arm/sync.md (cas_length): New mode attribute.
> (atomic_op_length, atomic_nand_length): Likewise.
> ("atomic_compare_and_swap_1"): Add length attribute.
> ("atomic_exchange"): Likewise.
> ("atomic_"): Likewise.
> ("atomic_nand"): Likewise.
> ("atomic_fetch_"): Likewise.
> ("atomic_fetch_nand"): Likewise.
> ("atomic__fetch"): Likewise.
> ("atomic_nand_fetch"): Likewise.
>
> Index: gcc/config/arm/sync.md
> ===
> *** gcc/config/arm/sync.md(revision 189459)
> --- gcc/config/arm/sync.md(working copy)
> ***
> *** 127,138
> {
> arm_split_compare_and_swap (operands);
> DONE;
> ! })
>
> (define_mode_attr cas_cmp_operand
> [(SI "arm_add_operand") (DI "cmpdi_operand")])
> (define_mode_attr cas_cmp_str
> [(SI "rIL") (DI "rDi")])
>
> (define_insn_and_split "atomic_compare_and_swap_1"
> [(set (reg:CC_Z CC_REGNUM);; bool
> out
> --- 127,141
> {
> arm_split_compare_and_swap (operands);
> DONE;
> ! }
> ! [(set_attr "length" "32")])
>
> (define_mode_attr cas_cmp_operand
> [(SI "arm_add_operand") (DI "cmpdi_operand")])
> (define_mode_attr cas_cmp_str
> [(SI "rIL") (DI "rDi")])
> + (define_mode_attr cas_length
> + [(SI "32") (DI "44")])
>
> (define_insn_and_split "atomic_compare_and_swap_1"
> [(set (reg:CC_Z CC_REGNUM);; bool
> out
> ***
> *** 155,161
> {
> arm_split_compare_and_swap (operands);
> DONE;
> ! })
>
> (define_insn_and_split "atomic_exchange"
> [(set (match_operand:QHSD 0 "s_register_operand" "=&r") ;; output
> --- 158,165
> {
> arm_split_compare_and_swap (operands);
> DONE;
> ! }
> ! [(set_attr "length" "")])
>
> (define_insn_and_split "atomic_exchange"
> [(set (match_operand:QHSD 0 "s_register_operand" "=&r") ;; output
> ***
> *** 175,181
> arm_split_atomic_op (SET, operands[0], NULL, operands[1],
>operands[2], operands[3], operands[4]);
> DONE;
> ! })
>
> (define_mode_attr atomic_op_operand
> [(QI "reg_or_int_operand")
> --- 179,186
> arm_split_atomic_op (SET, operands[0], NULL, operands[1],
>operands[2], operands[3], operands[4]);
> DONE;
> ! }
> ! [(set_attr "length" "20")])
>
> (define_mode_attr atomic_op_operand
> [(QI "reg_or_int_operand")
> ***
> *** 186,191
> --- 191,199
> (define_mode_attr atomic_op_str
> [(QI "rn") (HI "rn") (SI "rn") (DI "r")])
>
> + (define_mode_attr atomic_op_length
> + [(QI "24") (HI "24") (SI "24") (DI "28")])
> +
> (define_insn_and_split "atomic_"
> [(set (match_operand:QHSD 0 "mem_noofs_operand" "+Ua")
> (unspec_volatile:QHSD
> ***
> *** 204,210
> arm_split_atomic_op (, NULL, operands[3], operands[0],
>
[PATCH] Vectorizer referenced-vars cleanup
This was around in my tree for some time, consolidates calling
add_referenced_vars into vect_get_new_vect_var. Also uses
create_tmp_reg consistently.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2012-07-17 Richard Guenther
* tree-vect-data-refs.c (vect_get_new_vect_var): Add referenced
vars here, use create_tmp_reg where appropriate.
(vect_create_addr_base_for_vector_ref): Do not add referenced
vars here, use create_tmp_reg where appropriate.
(vect_create_data_ref_ptr): Likewise.
(vect_create_destination_var): Likewise.
(vect_permute_store_chain): Likewise.
(vect_permute_load_chain): Likewise.
* tree-vect-loop-manip.c (vect_create_cond_for_align_checks):
Likewise.
* tree-vect-loop.c (get_initial_def_for_induction): Likewise.
* tree-vect-patterns.c (vect_recog_temp_ssa_var): Likewise.
(vect_handle_widen_op_by_const): Likewise.
* tree-vect-stmts.c (vect_init_vector): Likewise.
(vectorizable_load): Likewise.
Index: gcc/tree-vect-data-refs.c
===
--- gcc/tree-vect-data-refs.c (revision 189564)
+++ gcc/tree-vect-data-refs.c (working copy)
@@ -3397,15 +3397,12 @@ vect_get_new_vect_var (tree type, enum v
if (name)
{
char* tmp = concat (prefix, name, NULL);
- new_vect_var = create_tmp_var (type, tmp);
+ new_vect_var = create_tmp_reg (type, tmp);
free (tmp);
}
else
-new_vect_var = create_tmp_var (type, prefix);
-
- /* Mark vector typed variable as a gimple register variable. */
- if (TREE_CODE (type) == VECTOR_TYPE)
-DECL_GIMPLE_REG_P (new_vect_var) = true;
+new_vect_var = create_tmp_reg (type, prefix);
+ add_referenced_var (new_vect_var);
return new_vect_var;
}
@@ -3533,7 +3530,6 @@ vect_create_addr_base_for_vector_ref (gi
vec_stmt = fold_convert (vect_ptr_type, addr_base);
addr_expr = vect_get_new_vect_var (vect_ptr_type, vect_pointer_var,
get_name (base_name));
- add_referenced_var (addr_expr);
vec_stmt = force_gimple_operand (vec_stmt, &seq, false, addr_expr);
gimple_seq_add_seq (new_stmt_list, seq);
@@ -3732,8 +3728,6 @@ vect_create_data_ref_ptr (gimple stmt, t
while (orig_stmt);
}
- add_referenced_var (aggr_ptr);
-
/* Note: If the dataref is in an inner-loop nested in LOOP, and we are
vectorizing LOOP (i.e., outer-loop vectorization), we need to create two
def-use update cycles for the pointer: one relative to the outer-loop
@@ -3983,7 +3977,6 @@ vect_create_destination_var (tree scalar
if (!new_name)
new_name = "var_";
vec_dest = vect_get_new_vect_var (type, kind, new_name);
- add_referenced_var (vec_dest);
return vec_dest;
}
@@ -4144,8 +4137,7 @@ vect_permute_store_chain (VEC(tree,heap)
/* Create interleaving stmt:
high = VEC_PERM_EXPR */
- perm_dest = create_tmp_var (vectype, "vect_inter_high");
- DECL_GIMPLE_REG_P (perm_dest) = 1;
+ perm_dest = create_tmp_reg (vectype, "vect_inter_high");
add_referenced_var (perm_dest);
high = make_ssa_name (perm_dest, NULL);
perm_stmt
@@ -4157,8 +4149,7 @@ vect_permute_store_chain (VEC(tree,heap)
/* Create interleaving stmt:
low = VEC_PERM_EXPR */
- perm_dest = create_tmp_var (vectype, "vect_inter_low");
- DECL_GIMPLE_REG_P (perm_dest) = 1;
+ perm_dest = create_tmp_reg (vectype, "vect_inter_low");
add_referenced_var (perm_dest);
low = make_ssa_name (perm_dest, NULL);
perm_stmt
@@ -4601,8 +4592,7 @@ vect_permute_load_chain (VEC(tree,heap)
second_vect = VEC_index (tree, dr_chain, j+1);
/* data_ref = permute_even (first_data_ref, second_data_ref); */
- perm_dest = create_tmp_var (vectype, "vect_perm_even");
- DECL_GIMPLE_REG_P (perm_dest) = 1;
+ perm_dest = create_tmp_reg (vectype, "vect_perm_even");
add_referenced_var (perm_dest);
perm_stmt = gimple_build_assign_with_ops3 (VEC_PERM_EXPR, perm_dest,
@@ -4616,8 +4606,7 @@ vect_permute_load_chain (VEC(tree,heap)
VEC_replace (tree, *result_chain, j/2, data_ref);
/* data_ref = permute_odd (first_data_ref, second_data_ref); */
- perm_dest = create_tmp_var (vectype, "vect_perm_odd");
- DECL_GIMPLE_REG_P (perm_dest) = 1;
+ perm_dest = create_tmp_reg (vectype, "vect_perm_odd");
add_referenced_var (perm_dest);
perm_stmt = gimple_build_assign_with_ops3 (VEC_PERM_EXPR, perm_dest,
Index: gcc/tree-vect-loop-manip.c
===
--- gcc/tree-vect-loop-manip.c (revision 189564)
+++ gcc/tree-vect-loop-manip.c (working copy)
@@ -2249,7 +2255,7 @@ vect_create_cond_for_align_checks (loop_
gimple_seq_add_seq
Re: new sign/zero extension elimination pass
the pass does not handle induction variables, i.e. variables that feed into themselves. kenny On 07/13/2012 03:53 AM, Tom de Vries wrote: On 12/07/12 14:04, Kenneth Zadeck wrote: you are on the right track with the example but combine will not get this unless everything is in the same bb. the whole point of having a separate pass for doing extension elimination is that it needs to be done over the entire function. There is a pass_ree, which does inter-bb combine targeted at extensions. However, that pass is currently limited to combining extensions with the definitions of the register it extends. The way your example sounds, you want the reverse, where extensions are combined with all their uses. I would say pass_ree is the natural place to add this and handle the example you describe. Thanks, - Tom my example is also a little more complex because, since we are talking about induction vars, you have an initial assignment outside of a loop, and increment inside the loop and the test you describe at the bottom of the loop. I would point out that with respect to speed optimizations, the case i am describing is in fact very important because getting code out of loops is were the important gains are. I believe that the ppc has a some significant performance issues because of this kind of thing. kenny On 07/12/2012 05:20 AM, Tom de Vries wrote: On 12/07/12 11:05, Tom de Vries wrote: On 12/07/12 03:39, Kenneth Zadeck wrote: Tom, I have a problem with the approach that you have taken here. I believe that this could be a very useful addition to gcc so I am in general very supportive, but i think you are missing an important case. My problem is that it the pass does not actually look at the target and make any decisions based on that target. for instance, we have a llp64 target. As with many targets, the target has a rich set of compare and branch instructions. In particular, it can do both 32 and 64 bit comparisons.We see that many of the upstream optimizations that take int (SI mode) index variables generate extension operations before doing 64 bit compare and branch instructions, even though there are 32 bit comparison and branches on the machine. There are a lot of machines that can do more than one size of comparison. This optimization pass, as it is currently written will not remove those extensions because it believes that the length of the destination is the "final answer" unless it is wrapped in an explicit truncation. Instead it needs to ask the port if there is a shorted compare and branch instruction that does not cost more. in that case, those instructions should be rewritten to use the shorted compare and branch. There are many operations other than compare and branch where the pass should be asking "can i shorten the target for free and therefore get rid of the extension?" Kenneth, I'm not sure I understand the optimization you're talking about, in particular I'm confused about whether the branch range of the 32-bit and 64-bit comparison is the same. Assuming it's the same, my understanding is that you're talking about an example like this: ... (insn (set (reg:DI 5) (zero_extend:DI (reg:SI 4 (jump_insn (set (pc) (if_then_else (eq (reg:DI 5) (const_int 0)) (label_ref:DI 62) (pc -> (jump_insn (set (pc) (if_then_else (eq (reg:SI 4) (const_int 0)) (label_ref:DI 62) (pc ... I would expect combine to optimize this. In case I got the example all backwards or it is a too simple one, please provide an rtl example that illustrates the optimization. Thanks, - Tom right shifts, rotates, and stores are not in this class, but left shifts are as are all comparisons, compare and branches, conditional moves. There may even be machines that have this for divide, but i do not know of any off the top of my head. What i am suggesting moves this pass into the target specific set of optimizations rather than target independent set, but at where this pass is to be put this is completely appropriate.Any dest instruction where all of the operands have been extended should be checked to see if it was really necessary to use the longer form before doing the propagation pass. kenny On 07/11/2012 06:30 AM, Tom de Vries wrote: On 13/11/10 10:50, Eric Botcazou wrote: I profiled the pass on spec2000: -mabi=32 -mabi=64 ee-pass (usr time): 0.70 1.16 total (usr time): 919.30 879.26 ee-pass(%): 0.08 0.13 The pass takes 0.13% or less of the total usr runtime. For how many hits? What are the numbers with --param ee-max-propagate=0? Is it necessary to improve the runtime of this pass? I've already given
Re: [PATCH, ARM] Fix length attributes for sync.md patterns
Richard Earnshaw wrote: > Hmm, I wonder if we should just unconditionally call split_all_insns() > at the start of md_reorg when -O0. This would address your problem, but > have the added benefit that the length calculations would be more > accurate. We're going to have to split the insns anyway during output, > so why not get it over and done with... Yes, that's already done on various other targets (including s390). [ Note that you need split_all_insns_noflow at this stage. ] I've noticed many other forced-split insn patterns that also carry a length attribute -- if we do the change you suggest, I guess we should then also remove those attributes? Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE ulrich.weig...@de.ibm.com
[PATCH] Add flag to control straight-line strength reduction
I overlooked adding a pass-control flag for strength reduction, added
here. I named it -ftree-slsr for consistency with other -ftree- flags,
but could change it to -fgimple-slsr if you prefer that for a pass named
gimple-ssa-...
Bootstrapped and tested on powerpc-unknown-linux-gnu with no new
regressions. Ok for trunk?
Thanks,
Bill
2012-07-17 Bill Schmidt
* opts.c (default_option): Make -ftree-slsr default at -O1 and above.
* gimple-ssa-strength-reduction.c (gate_strength_reduction): Use
flag_tree_slsr.
* common.opt: Add -ftree-slsr with flag_tree_slsr.
Index: gcc/opts.c
===
--- gcc/opts.c (revision 189574)
+++ gcc/opts.c (working copy)
@@ -452,6 +452,7 @@ static const struct default_options default_option
{ OPT_LEVELS_1_PLUS, OPT_ftree_ch, NULL, 1 },
{ OPT_LEVELS_1_PLUS, OPT_fcombine_stack_adjustments, NULL, 1 },
{ OPT_LEVELS_1_PLUS, OPT_fcompare_elim, NULL, 1 },
+{ OPT_LEVELS_1_PLUS, OPT_ftree_slsr, NULL, 1 },
/* -O2 optimizations. */
{ OPT_LEVELS_2_PLUS, OPT_finline_small_functions, NULL, 1 },
Index: gcc/gimple-ssa-strength-reduction.c
===
--- gcc/gimple-ssa-strength-reduction.c (revision 189574)
+++ gcc/gimple-ssa-strength-reduction.c (working copy)
@@ -1501,7 +1501,7 @@ execute_strength_reduction (void)
static bool
gate_strength_reduction (void)
{
- return optimize > 0;
+ return flag_tree_slsr;
}
struct gimple_opt_pass pass_strength_reduction =
Index: gcc/common.opt
===
--- gcc/common.opt (revision 189574)
+++ gcc/common.opt (working copy)
@@ -2080,6 +2080,10 @@ ftree-sink
Common Report Var(flag_tree_sink) Optimization
Enable SSA code sinking on trees
+ftree-slsr
+Common Report Var(flag_tree_slsr) Optimization
+Perform straight-line strength reduction
+
ftree-sra
Common Report Var(flag_tree_sra) Optimization
Perform scalar replacement of aggregates
Re: [Ada] Fix to 64-bit atomic operation failures on ppc-linux
On 07/17/2012 03:15 AM, Arnaud Charlet wrote: > + function Sync_Compare_And_Swap_32 > (Ptr : Address; >Expected : uint32; >Desired : uint32) return uint32; > pragma Import (Intrinsic, > + Sync_Compare_And_Swap_32, >"__sync_val_compare_and_swap_4"); > > + function Sync_Compare_And_Swap_64 > (Ptr : Address; >Expected : uint64; > - Desired : uint64) return uint64; > + Desired : uint64) return Boolean; > pragma Import (Intrinsic, > + Sync_Compare_And_Swap_64, > - "__sync_val_compare_and_swap_8"); > + "__sync_bool_compare_and_swap_8"); Ignoring the name change, why return bool only for the 64-bit function? This is surely papering over some sort of bug elsewhere... r~
Re: [Ada] Fix to 64-bit atomic operation failures on ppc-linux
On 07/17/2012 04:57 AM, Andrew MacLeod wrote: > What is the nature of the atomic failures using the > __atomic_compare_exchange built-in? Does it have anything to do > with the expected value being returned by pointer? It's a rue. He never was using __atomic_compare_exchange; the "Atomic_*" was simply the Ada symbol name. r~
Re: [Ada] Fix to 64-bit atomic operation failures on ppc-linux
On 07/17/2012 11:56 AM, Richard Henderson wrote: On 07/17/2012 04:57 AM, Andrew MacLeod wrote: What is the nature of the atomic failures using the __atomic_compare_exchange built-in? Does it have anything to do with the expected value being returned by pointer? It's a rue. He never was using __atomic_compare_exchange; the "Atomic_*" was simply the Ada symbol name. Ah, I was just disturbed by the apparent switch from 'atomic' to 'sync'... which is the wrong direction :-) Andrew
Re: [PATCH, ARM] Fix length attributes for sync.md patterns
On 17/07/12 16:17, Ulrich Weigand wrote: > Richard Earnshaw wrote: > >> Hmm, I wonder if we should just unconditionally call split_all_insns() >> at the start of md_reorg when -O0. This would address your problem, but >> have the added benefit that the length calculations would be more >> accurate. We're going to have to split the insns anyway during output, >> so why not get it over and done with... > > Yes, that's already done on various other targets (including s390). > [ Note that you need split_all_insns_noflow at this stage. ] > > I've noticed many other forced-split insn patterns that also carry > a length attribute -- if we do the change you suggest, I guess we > should then also remove those attributes? > > Bye, > Ulrich > There's certainly no harm in that, but it's not a priority. R.
Re: [C++ RFC / Patch] PR 51213 ("access control under SFINAE")
Hi,
On 07/17/2012 04:10 PM, Jason Merrill wrote:
On 07/17/2012 08:45 AM, Paolo Carlini wrote:
-check_default_argument (tree decl, tree arg)
+check_default_argument (tree decl, tree arg, tsubst_flags_t complain)
Hmm, I don't think substitution of default arguments can cause
deduction failure; it happens after we've chosen which function to
call. What was the motivation for the default argument changes?
Eh, thanks for noticing. Honestly, I have no idea where that cruft was
coming from, I removed it and everything seems fine.
+tmp = error_mark_node;
Let's use a more informative name than "tmp" for these flags.
Ok.
-void
-perform_deferred_access_checks (void)
+bool
+perform_deferred_access_checks (tsubst_flags_t complain)
Need to document what the return value means.
Indeed.
- if (complain & tf_error)
-perform_or_defer_access_check (TYPE_BINFO (context), t, t);
+ if (!perform_or_defer_access_check (TYPE_BINFO (context), t, t,
complain))
+return error_mark_node;
These changes along with the enforce_access handling of cxx_dialect
break C++03 code that currently works, such as
template
class A
{
typedef T I;
};
template
void f(typename T::I);
template
void f(int);
int main()
{
f > (1);
}
Under the C++03 rules, we don't get access errors when generating
overload candidates, we get them when the function is instantiated
(i.e. in instantiate_decl).
Ok, thanks. In fact today I added the enforce_access change very late,
without really checking that it was consistent with the callers etc. The
below variant makes more sense to me, afaics reduces correctly in the
various C++ modes either to what we used to have before this work or to
what I had in my first draft.
Hmm, now that I look at the code in instantiate_decl for
re-substituting to get additional errors, I guess I should have
factored that code out into a separate function and used it in the
access7 patch rather than add handling of FNDECL_RECHECK_ACCESS_P in
tsubst_decl.
I see. Could you take care of this improvement? Otherwise the below
passes testing, tries to implement all the changes you indicated.
Thanks!
Paolo.
Index: libstdc++-v3/testsuite/20_util/pair/noncopyable.cc
===
--- libstdc++-v3/testsuite/20_util/pair/noncopyable.cc (revision 0)
+++ libstdc++-v3/testsuite/20_util/pair/noncopyable.cc (revision 0)
@@ -0,0 +1,39 @@
+// { dg-do compile }
+// { dg-options "-std=gnu++11" }
+
+// Copyright (C) 2012 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library. This library 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.
+//
+// This library 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 this library; see the file COPYING3. If not see
+//
Re: [ARM] Scheduling VFP/NEON to core transfers (ping, RFC)
On 17/07/12 15:14, Julian Brown wrote: > Hi, > > Whilst looking at upstreaming some of CodeSourcery/Mentor's old > patches, I came across the following again, originally by Mark Shinwell > but last sent upstream by Andrew Stubbs: > > http://gcc.gnu.org/ml/gcc-patches/2011-02/msg01431.html > > I've attached a new version, re-tested but not re-benchmarked (I'm not > set up to do the latter just at the moment). > > I spent a while being quite unconvinced that this patch was a > reasonable solution for the problem (of scheduling transfers between the > NEON or VFP and the core unit) -- either on Cortex-A8, which the patch > was originally supposed to target, or any other core version. So, this > is what I came up with to try to convince myself. > > Handling of these transfers is unfortunately dealt with rather > haphazardly on various cores. I only looked in any detail at Cortex-A8 > and Cortex-A9. FAOD, I think we're principally concerned here with > instructions like "movdi_vfp", which may be used to transfer either > "VFP" or "NEON" register values to and from core registers, but also > with movsf and friends for the "runfast"-mode case. > > * On Cortex-A8, instructions with "f_2_r" (nor "r_2_f") type do not > participate in scheduling at all. This was probably the root of the > problem the patch was trying to fix originally: this means that > there is nothing to stop instructions which use the vfp/neon-to-core > result from being placed directly after the transfer. (A scheduler > dump shows "nothing" for the unit utilisation for these types of > instruction at present.) > > * On Cortex-A9, the "f_2_r" and "r_2_f" types both use the (core) insn > reservation "cortex_a9_fps", which produces its result after 2 > cycles. The A9 TRM on infocentre.arm.com says that VFP-to-core > transfers take 3 cycles, and NEON-to-core transfers take 11 cycles. > > * The cortex-r4f.md and cortex-m4-fpu.md scheduler descriptions seem to > handle f_2_r and r_2_f sanely. > > So, there are generally multiple DFA descriptions in play at any given > time, relating to different core units with different sets of registers, > and transferring values between those cores isn't really being > described properly to GCC's scheduler in a consistent way at present. > > Fixing this "properly", e.g. fully describing the way the NEON > unit is decoupled from the core unit on the Cortex-A8, is probably > impractical. But, the only cases we're concerned with at present are > transfers of values from one unit to another. I think setting both > "type" and "neon_type" for transfer instructions is therefore the > right thing to do -- although given the above, and other restrictions > (i.e. the mutual exclusion between VFP and NEON units on Cortex-A9), > it's probably not a complete solution to the problem. > > To expand: > > * "type" should be set to f_2_r for MRC-type instructions because of > the dependency on an earlier instruction setting the input register. > > * "neon_type" should be set appropriately for MRC-type instructions > because following NEON instructions will have dependencies on the > transferred value. > > * ...and vice-versa for MCR-type instructions. > > Incidentally other patches, probably merged from our source base, have > introduced "neon_type" alongside "type" for a couple of instructions in > vfp.md already: namely, *movdi_vfp and *movhf_vfp_neon: whatever we > choose to do, we should be consistent. > > So: OK to apply? > This is OK. I'll note for the record here, that I think having type, insn and neon_type attributes all trying to do the same thing (that is, classify the insn for scheduling purposes) is broken. The correct fix, long term, is to simplify these into one 'type' attribute that is then rich enough to handle all the different classifications. Subdividing a classification should be done by splitting an existing class into two entries in the same attribute, not adding some parallel alternative attribute for the sub-division -- that way lies chaos. However, that's rather a lot of work and this patch won't make that problem any harder. R. > Thanks, > > Julian > > 2011-02-22 Andrew Stubbs > Mark Shinwell > Julian Brown > > gcc/ > * config/arm/vfp.md (*arm_movsi_vfp, *thumb2_movsi_vfp) > (*movdi_vfp_cortexa8, *movsf_vfp, *thumb2_movsf_vfp) > (*movdf_vfp, *thumb2_movdf_vfp, *movsfcc_vfp) > (*thumb2_movsfcc_vfp, *movdfcc_vfp, *thumb2_movdfcc_vfp): Add > neon_type. > * config/arm/arm.md (neon_type): Update comment. > > > neon-type-vfplite-to-core-1.diff > > > commit 44d6297b8e73eae42b3d6a0da7ca857f549049c1 > Author: Julian Brown > Date: Fri Jul 13 10:32:46 2012 -0700 > > Set neon_type for vfp-to-core transfers. > > diff --git a/gcc/config/arm/arm.md b/gcc/config/arm/arm.md > index 382..e9da56d 100644 > --- a/gcc/config/arm/arm.md > +++ b/gcc/config/arm/arm.md > @@ -397,8 +397,6 @@ > (define_attr "
Re: CRIS atomics revisited 4/4: give up on alignment of atomic data, RFC for is_lock_free hook
> From: Andrew MacLeod
> Date: Tue, 17 Jul 2012 14:24:48 +0200
> On 07/15/2012 11:49 PM, Hans-Peter Nilsson wrote:
> > Well, give up by default that is, and fix it up in a helper
> > function in glibc to hold a global byte-sized atomic lock for
> > the duration. (Sorry!) Yes, this means that
> > fold_builtin_atomic_always_lock_free is wrong. It knows about
> > alignment in general but doesn't handle the case where the
> > default alignment of the underlying type is too small for atomic
> > accesses, and should probably be augmented by a target hook,
> > alternatively, change the allow_libcall argument in the call to
> > can_compare_and_swap_p to false. I guess I should open a PR for
> > this and add a test-case. Later.
>
> I set it up to eventually handle alignment issues, but didn't really
> know any details of what to do when, or how. Input was rather lacking
> at the time and there was a time crunch, so I just punted on it in 4.7
> at the tree level and targets did their own thing.
Most (all but mine :) seem happy to provide naturally-aligned
types and promising to never access non-naturally-aligned data
so not much they need to do... Not sure if the i386 ABI (or
e.g. xchg and similar insns in the CPU) promises or requires
that all data (ints) are aligned or if something is nominally
required.
> The library idea was
> new enough that the standards guys couldnt/wouldn't give me a straight
> answer since it hadn't really been thought through I don't think. My
> apologies if I misrepresent anyone there :-)
>
> The basic problem you are dealing with is a 4 byte object that is not
> aligned properly, so the lock-free instructions don't work on it., but
> 'always_lock_free' says "yes, that type is lock free". Then in the
> library,
(The library here meaning the atomicity implementation, not
e.g. libstdc++. I assume you don't mean libatomic, which seems
to be intended just as a fallback for targets and sizes
unsupported by core gcc, so they're guaranteed to not be
lock-free.)
> its implemented via a lock? Is that approximately it? or is
> there an additional issue?
That's pretty much it... except it'd be better letting the
target decorate the intended atomic type, e.g. with alignment
attributes. See suggestion last. Decoration is in place for
_Atomic_word but I can't tell how _Atomic_word relates to the
issues here. Is _Atomic_word just obsolete?
> The original intention was that __atomic{is,always}_lock_free takes the
> size and a pointer to the object, and the alignment of the pointer
> object would be checked at compile time to see if it is always
> compatible with size.
The alignment of the pointed-to *object* can't be checked at
compile-time. As GCC is pretty bad at alignment, taking on the
task of trying to make a difference for different *types* seems
non-trivial. All you can hope for is telling apart the size of
the objects.
Alignment of objects *can* be checked at run-time from within
the current __atomic_is_lock_free API, and apparently that's the
intention in the core gcc implementation, but the last few
details aren't there or are wrong.
> (so a char pointer to a 4 byte object would fail
> that test). which would means 'always_lock_free' should return false,
> and in turn a call to 'is_lock_free' would generate a library call and
> check the alignment at runtime of the object to determine what to do.
For the record, is_lock_free in libstdc++ calls
__atomic_is_lock_free, which is per-instance at the API level.
I don't see usage of __atomic_always_lock_free in libstdc++.
(I see it in libatomic/glfree.c:libat_is_free, but dominated by
a check for natural alignment of the pointer instance with
failure yielding false, bravo.)
Not using __atomic_always_lock_free is probably wrong, it seems
it should call __atomic_always_lock_free if I understand
/path/to/trunk/libstdc++-v3/doc/html/ext/lwg-closed.html#1146
correctly (the link to www.open-std.org there is dead). Can
this be confirmed? Still wouldn't work of course - the target
can't doesn't have a say in the __atomic_always_lock_free
implementation.
> The library implementation of all the other __atomic operations would
> check 'is_lock_free' to see whether they need to use a lock, or whether
> they can use available lock-free sequences/syscalls.
(You must mean libstdc++ here which is slightly confusing with
the use of "__atomic_" which for me implies the gcc
implementation.)
> Some confusion around the standard surfaced and the intention from the
> standard point of view appeared to be that 'is_lock_free' should be true
> or false ALL the time for a given type.
And there's confusion all around telling apart atomic access
from *lock-free* atomic access. :-) Witness
__GCC_ATOMIC_INT_LOCK_FREE and the md.texi note: "For the
purposes of C++11 @code{std::atomic::is_lock_free}, it is
assumed that these library calls do @emph{not} use any kind of
interruptable locking".
Come to think of it, what
Re: [PATCH, ARM] Fix length attributes for sync.md patterns
Richard Earnshaw wrote: > On 17/07/12 16:17, Ulrich Weigand wrote: > > Richard Earnshaw wrote: > > > >> Hmm, I wonder if we should just unconditionally call split_all_insns() > >> at the start of md_reorg when -O0. This would address your problem, but > >> have the added benefit that the length calculations would be more > >> accurate. We're going to have to split the insns anyway during output, > >> so why not get it over and done with... > > > > Yes, that's already done on various other targets (including s390). > > [ Note that you need split_all_insns_noflow at this stage. ] > > > > I've noticed many other forced-split insn patterns that also carry > > a length attribute -- if we do the change you suggest, I guess we > > should then also remove those attributes? > > There's certainly no harm in that, but it's not a priority. OK, I'll prepare a patch doing just the split_all_insns then ... Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE ulrich.weig...@de.ibm.com
Re: [patch] fixes for power4 scheduler description
On Tue, Jul 10, 2012 at 8:20 AM, Steven Bosscher wrote: > Hello, > > These look like typos: > > * "power4-store-update" wants "iuX,iuY" for X=1|2 and Y=1|2. The > "iu2,iu1" case appeared twice. > * "power4-three" wants "iuX,iuX,iuY|iuX,iuY,iuY" for X=1|2 and Y=1|2. > The "iu1,iu1,iu2" case appeared twice. > > Bootstrapped&tested on powerpc64-unknown-linux-gnu. > OK for trunk? > > Note, it'd be nice if the size of the power4iu automaton could be > reduced somehow. It is by far the largest automaton in the rs6000 back > end, accounting for ~40% of the total. Steven, The change to the power3-three reservation is okay. The change to power4-store-update looks incorrect or at least incomplete. These reservations and others were changed by Vlad in March/April 2004 to fix a consistency check that he introduced at the time. Note that the dispatch units for the final choice also is wrong and duplicated from the previous line for power4-store-update: |(du3_power4+du4_power4,lsu2_power4)\ |(du3_power4+du4_power4,lsu2_power4))+\ It looks like the final line should be du4_power4+du1_power4,lsu1_power4 On POWER4, the dispatch slot forces specific function units. I don't remember and don't have the documents handy to know if the function units for store-update should be 2-1 2-2 1-1 1-2 or 2-1 2-2 1-2 1-1 I think it is the latter. If you look at the thread from 2009, we discuss that the POWER4 scheduler description already is an approximation because an accurate description creates an unreasonably large automata. A lot of the problem is the 1 cycle delay for dependent integer ops. Thanks, David
C++ PATCH for c++/53549 (ICE with using-declaration in nested class derived from enclosing class template)
For C2 to be considered the "current instantiation", we need to call
xref_basetypes while we're still pushed into its scope. So we can
actually simplify the code by moving the call into cp_parser_class_head.
Once we've fixed that, we need to fix tsubst_decl to handle USING_DECLs
for members of the current instantiation, since the scope can be a
dependent type even though we can do name lookup in it.
The discussion of the PR also pointed out that EDG rejects code like
template struct A
{
struct B : A { };
};
because A is not complete yet. This makes sense to me, so I've added
this diagnostic as a pedwarn (so code that uses this pattern will
continue to compile for now).
Tested x86_64-pc-linux-gnu, applying the first patch to trunk and 4.7,
the second to trunk only.
commit 5d594c4a4616821068b111489b26a88183d6eb22
Author: Jason Merrill
Date: Tue Jul 17 00:45:54 2012 -0400
PR c++/53549
* parser.c (cp_parser_class_head): Call xref_basetypes here.
(cp_parser_class_specifier_1): Not here.
* pt.c (tsubst_decl) [USING_DECL]: Check uses_template_parms
as well as DECL_DEPENDENT_P.
diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index 1428a26..df23299 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -2008,7 +2008,7 @@ static tree cp_parser_class_name
static tree cp_parser_class_specifier
(cp_parser *);
static tree cp_parser_class_head
- (cp_parser *, bool *, tree *);
+ (cp_parser *, bool *);
static enum tag_types cp_parser_class_key
(cp_parser *);
static void cp_parser_member_specification_opt
@@ -17961,15 +17961,13 @@ cp_parser_class_specifier_1 (cp_parser* parser)
bool saved_in_unbraced_linkage_specification_p;
tree old_scope = NULL_TREE;
tree scope = NULL_TREE;
- tree bases;
cp_token *closing_brace;
push_deferring_access_checks (dk_no_deferred);
/* Parse the class-head. */
type = cp_parser_class_head (parser,
- &nested_name_specifier_p,
- &bases);
+ &nested_name_specifier_p);
/* If the class-head was a semantic disaster, skip the entire body
of the class. */
if (!type)
@@ -17986,18 +17984,6 @@ cp_parser_class_specifier_1 (cp_parser* parser)
return error_mark_node;
}
- /* Process the base classes. If they're invalid, skip the
- entire class body. */
- if (!xref_basetypes (type, bases))
-{
- /* Consuming the closing brace yields better error messages
- later on. */
- if (cp_parser_skip_to_closing_brace (parser))
- cp_lexer_consume_token (parser->lexer);
- pop_deferring_access_checks ();
- return error_mark_node;
-}
-
/* Issue an error message if type-definitions are forbidden here. */
cp_parser_check_type_definition (parser);
/* Remember that we are defining one more class. */
@@ -18283,14 +18269,14 @@ cp_parser_class_specifier (cp_parser* parser)
static tree
cp_parser_class_head (cp_parser* parser,
- bool* nested_name_specifier_p,
- tree *bases)
+ bool* nested_name_specifier_p)
{
tree nested_name_specifier;
enum tag_types class_key;
tree id = NULL_TREE;
tree type = NULL_TREE;
tree attributes;
+ tree bases;
cp_virt_specifiers virt_specifiers = VIRT_SPEC_UNSPECIFIED;
bool template_id_p = false;
bool qualified_p = false;
@@ -18307,8 +18293,6 @@ cp_parser_class_head (cp_parser* parser,
num_templates = 0;
parser->colon_corrects_to_scope_p = false;
- *bases = NULL_TREE;
-
/* Look for the class-key. */
class_key = cp_parser_class_key (parser);
if (class_key == none_type)
@@ -18671,7 +18655,15 @@ cp_parser_class_head (cp_parser* parser,
/* Get the list of base-classes, if there is one. */
if (cp_lexer_next_token_is (parser->lexer, CPP_COLON))
-*bases = cp_parser_base_clause (parser);
+bases = cp_parser_base_clause (parser);
+ else
+bases = NULL_TREE;
+
+ /* If we're really defining a class, process the base classes.
+ If they're invalid, fail. */
+ if (type && cp_lexer_next_token_is (parser->lexer, CPP_OPEN_BRACE)
+ && !xref_basetypes (type, bases))
+type = NULL_TREE;
done:
/* Leave the scope given by the nested-name-specifier. We will
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 95c6464..542f57a 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -10235,8 +10235,12 @@ tsubst_decl (tree t, tree args, tsubst_flags_t complain)
break;
case USING_DECL:
- /* We reach here only for member using decls. */
- if (DECL_DEPENDENT_P (t))
+ /* We reach here only for member using decls. We also need to check
+ uses_template_parms because DECL_DEPENDENT_P is not set for a
+ using-declaration that designates a member of the current
+ instantiation (c++/53549). */
+ if (DECL_DEPENDENT_P (t)
+ || uses_template_parms (USING_DECL_SCOPE (t)))
{
r = do_class_using_decl
(tsubst_copy (USING_DECL_SCOPE (t), args, complain, in_decl),
diff --git a/gcc/testsuite/g++.dg/parse/crash35.C b/gcc/
[Fortran, Patch] Fix #line parsing
gfortran properly handles the "#line" which come from #include
statements and look as
# 1234 "include_file_name.f90" 1
Here, the syntax is "# linenumber filename flags", where flags is a
space-delimited list of the flags 1,2,3, or 4. The problem is that the
gfortran didn't handle the case of having no flag.
Additionally, I now also go through the new-file handling for system
headers.
Build and regtested on x86-64-gnu-linux.
OK for the trunk?
Tobias
PS: I didn't include a test case; one could create one using
-fdump-tree-original-lineno, if you think that it makes sense.
2012-07-17 Tobias Burnus
PR fortran/53993
* scanner.c (preprocessor_line): Fix parsing of a "#line"
which has no flags.
diff --git a/gcc/fortran/scanner.c b/gcc/fortran/scanner.c
index 4fad58b..df9f01d 100644
--- a/gcc/fortran/scanner.c
+++ b/gcc/fortran/scanner.c
@@ -1654,6 +1654,9 @@ preprocessor_line (gfc_char_t *c)
gfc_file *f;
int escaped, unescape;
char *filename;
+ enum {FLAG_NEW_FILE = 1, FLAG_PREV_FILE, FLAG_SYSHEADER, FLAG_EXTERN_C};
+
+ /* The expected syntax is "# linenumber filename flags". */
c++;
while (*c == ' ' || *c == '\t')
@@ -1739,20 +1742,24 @@ preprocessor_line (gfc_char_t *c)
flag[i] = true;
}
+ /* No flag implies that one might have a new file. */
+ if (!flag[FLAG_NEW_FILE] && !flag[FLAG_PREV_FILE] && !flag[FLAG_SYSHEADER])
+flag[FLAG_NEW_FILE] = true;
+
/* Convert the filename in wide characters into a filename in narrow
characters. */
filename = gfc_widechar_to_char (wide_filename, -1);
/* Interpret flags. */
- if (flag[1]) /* Starting new file. */
+ if (flag[FLAG_NEW_FILE] || flag[FLAG_SYSHEADER]) /* Starting new file. */
{
f = get_file (filename, LC_RENAME);
add_file_change (f->filename, f->inclusion_line);
current_file = f;
}
- if (flag[2]) /* Ending current file. */
+ if (flag[FLAG_PREV_FILE]) /* Ending current file. */
{
if (!current_file->up
|| filename_cmp (current_file->up->filename, filename) != 0)
Re: [Patch, Fortran] gfc_notify_std cleanup
Hello,
On 17/07/2012 16:44, Janus Weil wrote:
> Hi,
>
>> Ditto here. Though, I think you are in danger of exceeding the buffer - if
>> not here, then further down.
>
> admitted - the buffer length could clearly be a problem (in connection
> with translation).
>
>
>> Wouldn't it be simplyer to keep the error print for Warning/Error, assign
>> the messages to a "const char * msg" and then pass the msg to error_print?
>> That would be two calls to error_print, but would avoid buffer issues, calls
>> to strcpy/strcat, and would work with i18n.
>
> Actually I also tried something like this, but couldn't get it to work
> (the biggest problem being that stuff will not show up in one line
> after the locus printout).
>
Another possibility is adding an argument to error_print containing the
standard version information either as a string or as an enum; an
argument that is ignored if it has an invalid value (NULL string, ...),
typically for errors irrelevant to the standard version.
I'm fine with Tobias' suggestion too.
>
>> Okay, that won't work as one has to call error_print only once. Maybe
>> something like the following will work:
>>
>> const char *msg, *msg2;
>> char *buffer;
>> msg = _("Warning: ");
>> msg2 = _("Deleted feature:");
>> buffer = (char *) alloca (strlen (msg) + strlen (msg2)+1);
>> strcpy(buffer, msg);
>> strcat (buffer, msg2);
>> error_print (buffer, _(gmsgid), argp);
>>
>> where the buffer itself is not send through _().
>
> With this you are almost back to my last version, except that you
> allocate the buffer dynamically.
... which is better ;-).
Nice patch anyway.
Mikael
Re: [Fortran, Patch] Fix #line parsing
On 17/07/2012 20:52, Tobias Burnus wrote: > gfortran properly handles the "#line" which come from #include > statements and look as > > # 1234 "include_file_name.f90" 1 > > Here, the syntax is "# linenumber filename flags", where flags is a > space-delimited list of the flags 1,2,3, or 4. The problem is that the > gfortran didn't handle the case of having no flag. > > Additionally, I now also go through the new-file handling for system > headers. > > Build and regtested on x86-64-gnu-linux. > OK for the trunk? > > Tobias > > PS: I didn't include a test case; one could create one using > -fdump-tree-original-lineno, if you think that it makes sense. OK; I prefer with a testcase. Thanks. Mikael
Re: [PATCH, ARM] Optimize vdup-constant builtins
Nice. On 17 July 2012 15:26, Julian Brown wrote: > Hi, > > This patch (originally by Jie Zhang) optimizes vdup builtins which use > a constant argument into the immediate variants of the vdup > instructions, rather than generating separate immediate-loads and > register vdups, as is presently done. It also adds support for loading > floating-point constant 0.0 to such instructions, by using integer > zero-load instructions (the bit pattern is the same). > > Tested with no regressions, and the new tests pass. One test needed > tweaking, since with the patch the (constant) calculations performed > now get entirely optimised away. Yes, I know that one. I've been looking at fixing these with my other patch from earlier this month. Coincidentally the costs was something that I'd been looking at tweaking, so thanks. > > OK to apply? Ok. regards, Ramana > > Thanks, > > Julian > > ChangeLog > > Jie Zhang > Julian Brown > > gcc/ > * config/arm/arm.c (arm_rtx_costs_1): Adjust cost for > CONST_VECTOR. > (arm_size_rtx_costs): Likewise. > (neon_valid_immediate): Add a case for double 0.0. > > gcc/testsuite/ > * gcc.target/arm/neon-vdup-1.c: New test case. > * gcc.target/arm/neon-vdup-2.c: New test case. > * gcc.target/arm/neon-vdup-3.c: New test case. > * gcc.target/arm/neon-vdup-4.c: New test case. > * gcc.target/arm/neon-vdup-5.c: New test case. > * gcc.target/arm/neon-vdup-6.c: New test case. > * gcc.target/arm/neon-vdup-7.c: New test case. > * gcc.target/arm/neon-vdup-8.c: New test case. > * gcc.target/arm/neon-vdup-9.c: New test case. > * gcc.target/arm/neon-vdup-10.c: New test case. > * gcc.target/arm/neon-vdup-11.c: New test case. > * gcc.target/arm/neon-vdup-12.c: New test case. > * gcc.target/arm/neon-vdup-13.c: New test case. > * gcc.target/arm/neon-vdup-14.c: New test case. > * gcc.target/arm/neon-vdup-15.c: New test case. > * gcc.target/arm/neon-vdup-16.c: New test case. > * gcc.target/arm/neon-vdup-17.c: New test case. > * gcc.target/arm/neon-vdup-18.c: New test case. > * gcc.target/arm/neon-vdup-19.c: New test case. > * gcc.target/arm/neon-combine-sub-abs-into-vabd.c: Make intrinsic > arguments non-constant.
Re: [Patch, Fortran] PR53985 add missing case to -Wc-binding-type
On 17/07/2012 10:13, Tobias Burnus wrote: > gfortran always warned for BIND(C) procedures if one used "integer", > "integer(4)" etc. instead of "integer(c_int)". While the latter is > surely more portable than the former, all of them are identical on > nearly all systems. Hence, the other versions are rahter widely used. > > In order to reduce the clutter due to default warnings, since GCC 4.8 > there is a new warning -Wc-binding-type, which is turned off by default. > However, for some reason, it misses the most common case. That's now > fixed in the attachment. I also corrected the wording. > > Build and regtested on x86-64-gnu-linux. > OK for the trunk? > > Tobias OK, thanks. Mikael
Re: [Patch, Fortran] gfc_notify_std cleanup
On 17/07/2012 12:03, Tobias Burnus wrote: > On 07/17/2012 11:42 AM, Janus Weil wrote: >> +case GFC_STD_F2008_TS: >> + strcat (buffer, " TS 29113:"); >> + break; > > That's currently correct. However, there is another post-Fortran 2008 > Technical Specification in preparation. (Coarray extensions.)* How > should be handled? "TS 29113 or TS 12345:"? > Future extension:? To be standardized feature:? Bleeding edge stuff:? Fortran 2015:? If they are both in the next standard revision, they have to be under the same flag anyway. Mikael
[SH] PR 33135
Hello,
The attached patch fixes PR 33135 as discussed in the PR.
Tested with
make info dvi pdf
and
make check-gcc RUNTESTFLAGS="sh.exp=pr33135* --target_board=sh-sim
\{-m2/-ml,-m2/-mb,-m2e,-m3,-m3e,-m2a/-mb,-m2a-single/-mb,-m4/-ml,
-m4/-mb,-m4-single/-ml,-m4-single/-mb,-m4a-single/-ml,-m4a-single/-mb}"
OK?
Cheers,
Oleg
ChangeLog:
PR target/33135
* config/sh/sh.opt (mieee): Use Var instead of Mask. Correct
description.
* config/sh/sh.c (sh_option_override): Do not change
flag_finite_math_only. Set TARGET_IEEE to complement of
flag_finite_math_only.
* doc/invoke.texi (SH options): Add mno-ieee. Correct
description of mieee and mno-ieee behavior.
testsuite/ChangeLog:
PR target/33135
* gcc.target/sh/pr33135-1.c: New.
* gcc.target/sh/pr33135-2.c: New.
* gcc.target/sh/pr33135-3.c: New.
* gcc.target/sh/pr33135-4.c: New.
Index: gcc/doc/invoke.texi
===
--- gcc/doc/invoke.texi (revision 189549)
+++ gcc/doc/invoke.texi (working copy)
@@ -881,8 +881,8 @@
-m5-compact -m5-compact-nofpu @gol
-mb -ml -mdalign -mrelax @gol
-mbigtable -mfmovd -mhitachi -mrenesas -mno-renesas -mnomacsave @gol
--mieee -mbitops -misize -minline-ic_invalidate -mpadstruct -mspace @gol
--mprefergot -musermode -multcost=@var{number} -mdiv=@var{strategy} @gol
+-mieee -mno-ieee -mbitops -misize -minline-ic_invalidate -mpadstruct @gol
+-mspace -mprefergot -musermode -multcost=@var{number} -mdiv=@var{strategy} @gol
-mdivsi3_libfunc=@var{name} -mfixed-range=@var{register-range} @gol
-mindexed-addressing -mgettrcost=@var{number} -mpt-fixed @gol
-maccumulate-outgoing-args -minvalid-symbols -msoft-atomic -mhard-atomic @gol
@@ -18099,13 +18099,15 @@
@option{-mhitachi} is given.
@item -mieee
+@item -mno-ieee
@opindex mieee
-Increase IEEE compliance of floating-point code.
-At the moment, this is equivalent to @option{-fno-finite-math-only}.
-When generating 16-bit SH opcodes, getting IEEE-conforming results for
-comparisons of NANs / infinities incurs extra overhead in every
-floating-point comparison, therefore the default is set to
-@option{-ffinite-math-only}.
+@opindex mnoieee
+Control the IEEE compliance of floating-point comparisons, which affects the
+handling of cases where the result of a comparison is unordered. By default
+@option{-mieee} is implicitly enabled. If @option{-ffinite-math-only} is
+enabled @option{-mno-ieee} is implicitly set, which results in faster
+floating-point greater-equal and less-equal comparisons. The implcit settings
+can be overridden by specifying either @option{-mieee} or @option{-mno-ieee}.
@item -minline-ic_invalidate
@opindex minline-ic_invalidate
Index: gcc/testsuite/gcc.target/sh/pr33135-2.c
===
--- gcc/testsuite/gcc.target/sh/pr33135-2.c (revision 0)
+++ gcc/testsuite/gcc.target/sh/pr33135-2.c (revision 0)
@@ -0,0 +1,32 @@
+/* Check that only the fcmp/gt instruction is generated when specifying
+ -ffinite-math-only (implicit -mno-ieee). */
+/* { dg-do compile { target "sh*-*-*" } } */
+/* { dg-options "-O1 -ffinite-math-only" } */
+/* { dg-skip-if "" { "sh*-*-*" } { "-m1" "-m2" "-m3" "-m4al" "*nofpu" "-m4-340*" "-m4-400*" "-m4-500*" "-m5*" } { "" } } */
+/* { dg-final { scan-assembler-not "fcmp/eq" } } */
+/* { dg-final { scan-assembler-times "fcmp/gt" 4 } } */
+
+int
+test_00 (float a, float b)
+{
+ return a <= b;
+}
+
+int
+test_01 (float a, float b)
+{
+ return a >= b;
+}
+
+int
+test_02 (double a, double b)
+{
+ return a <= b;
+}
+
+int
+test_03 (double a, double b)
+{
+ return a >= b;
+}
+
Index: gcc/testsuite/gcc.target/sh/pr33135-4.c
===
--- gcc/testsuite/gcc.target/sh/pr33135-4.c (revision 0)
+++ gcc/testsuite/gcc.target/sh/pr33135-4.c (revision 0)
@@ -0,0 +1,32 @@
+/* Check that only the fcmp/gt instruction is generated when specifying
+ -fno-finite-math-only and -mno-ieee. */
+/* { dg-do compile { target "sh*-*-*" } } */
+/* { dg-options "-O1 -fno-finite-math-only -mno-ieee" } */
+/* { dg-skip-if "" { "sh*-*-*" } { "-m1" "-m2" "-m3" "-m4al" "*nofpu" "-m4-340*" "-m4-400*" "-m4-500*" "-m5*" } { "" } } */
+/* { dg-final { scan-assembler-not "fcmp/eq" } } */
+/* { dg-final { scan-assembler-times "fcmp/gt" 4 } } */
+
+int
+test_00 (float a, float b)
+{
+ return a <= b;
+}
+
+int
+test_01 (float a, float b)
+{
+ return a >= b;
+}
+
+int
+test_02 (double a, double b)
+{
+ return a <= b;
+}
+
+int
+test_03 (double a, double b)
+{
+ return a >= b;
+}
+
Index: gcc/testsuite/gcc.target/sh/pr33135-1.c
===
--- gcc/testsuite/gcc.target/sh/pr33135-1.c (revision 0)
+++ gcc/testsuite/gcc.target/sh/pr33135-1.c (revision 0)
@@ -0,0 +1,32 @@
+/* Check that fcmp/eq and fcmp/gt instructions are generated by de
Re: [Patch, Fortran] gfc_notify_std cleanup
Mikael Morin wrote: On 17/07/2012 12:03, Tobias Burnus wrote: On 07/17/2012 11:42 AM, Janus Weil wrote: +case GFC_STD_F2008_TS: + strcat (buffer, " TS 29113:"); + break; That's currently correct. However, there is another post-Fortran 2008 Technical Specification in preparation. (Coarray extensions.)* How should be handled? "TS 29113 or TS 12345:"? Future extension:? To be standardized feature:? Bleeding edge stuff:? Well, those names are nice – until we have Fortran 2015 and Fortran 2020. Fortran 2015:? If they are both in the next standard revision, they have to be under the same flag anyway. Well, they will be in the next standard, however, the goal is to be able to compile with a -std= flag, which does not include compiler extensions but those features. I have met a couple of users, who just wanted to have Fortran 95 + allocatable components/dummy arguments (TR 15581:2001) and not any Fortran 2003 feature. However, as gfortran doesn't have a suitable -std=, they had to use -std=f2003. Okay, for Fortran 2015, that is probably not a problem as it seems as if only few features will be added. There is not much time according to the schedule [1], only until mid-2015 – and a lot of time will be spend on the coarray TS (due: mid-2013). Additionally, there seems to be the feeling in the committee that one shouldn't move forward too quickly, given that finding a Fortran 2003 compiler is difficult and having no compiler with full Fortran 2008. [2] In that sense, one could rename -std=f2008ts into -std=f2015 and have the "f2015ts" as alias. But otherwise, Fortran 2008 plus TS and Fortran 2015 are different beasts. Tobias [1] ftp://ftp.nag.co.uk/sc22wg5/N1901-N1950/N1925.txt [2] Especially the UK's position is along those lines ftp://ftp.nag.co.uk/sc22wg5/N1901-N1950/N1923.pdf
Re: G++ namespace association extension
On 16 July 2012 00:34, Gerald Pfeifer wrote: > On Sun, 15 Jul 2012, Jonathan Wakely wrote: >>> I think this also should go into the GCC 4.8 release notes >>> (gcc-4.8/changes.html)? >> I can do that too. There's no gcc-4.8 dir yet, do I need to copy over >> the various other files from the gcc-4.7 dir or can I just create >> changes.html and leave the RM to do the rest at the appropriate time? > > If you run `cvs up -PAd` it should magically appear. :-) Ah yes, I'd (quite happily) forgotten how to use CVS, but have now reinstated the ~/.cvsrc I used to have on my previous machine. Here's what I committed. Index: changes.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.8/changes.html,v retrieving revision 1.5 diff -u -r1.5 changes.html --- changes.html15 Jul 2012 21:24:31 - 1.5 +++ changes.html17 Jul 2012 19:46:32 - @@ -21,6 +21,9 @@ directory. The installation manual contains more information about requirements to build GCC. +The G++ namespace association extension, __attribute ((strong)), +has been deprecated. Inline namespaces should be used instead. + General Optimizer Improvements
[SH] Use some more insn_and_split in MD
Hello,
The attached patch folds some define_insn and define_split with
define_insn_and_split and removes constraints in some expander
definitions.
Tested on rev 189549 with
make -k check RUNTESTFLAGS="--target_board=sh-sim
\{-m2/-ml,-m2/-mb,-m2a/-mb,-m2a-single/-mb,-m4/-ml,-m4/-mb,
-m4-single/-ml,-m4-single/-mb,-m4a-single/-ml,-m4a-single/-mb}"
and no new failures.
CSiBE result-size (-m4-single -ml -O2 -mpretend-cmove) also shows no
changes.
OK?
Cheers,
Oleg
ChangeLog:
* config/sh/sh.md (mulsidi3, umulsidi3): Remove constraints in
expander. Use arith_reg_dest predicate.
(rotldi3, rotrdi3): Remove constraints in expander.
(adddi3_compact, subdi3_compact, mulsidi3_compact,
umulsidi3_compact, ashlsi3_n, *ashlhi3_n, ashrsi2_16,
ashrsi2_31, lshrsi3_n): Convert to insn_and_split.
Index: gcc/config/sh/sh.md
===
--- gcc/config/sh/sh.md (revision 189427)
+++ gcc/config/sh/sh.md (working copy)
@@ -1431,21 +1431,14 @@
[(set_attr "type" "arith_media")
(set_attr "highpart" "ignore")])
-(define_insn "adddi3_compact"
+(define_insn_and_split "adddi3_compact"
[(set (match_operand:DI 0 "arith_reg_dest" "=&r")
(plus:DI (match_operand:DI 1 "arith_reg_operand" "%0")
(match_operand:DI 2 "arith_reg_operand" "r")))
(clobber (reg:SI T_REG))]
"TARGET_SH1"
"#"
- [(set_attr "length" "6")])
-
-(define_split
- [(set (match_operand:DI 0 "arith_reg_dest" "")
- (plus:DI (match_operand:DI 1 "arith_reg_operand" "")
- (match_operand:DI 2 "arith_reg_operand" "")))
- (clobber (reg:SI T_REG))]
- "TARGET_SH1 && reload_completed"
+ "&& reload_completed"
[(const_int 0)]
{
rtx high0 = gen_highpart (SImode, operands[0]);
@@ -1556,21 +1549,14 @@
[(set_attr "type" "arith_media")
(set_attr "highpart" "ignore")])
-(define_insn "subdi3_compact"
+(define_insn_and_split "subdi3_compact"
[(set (match_operand:DI 0 "arith_reg_dest" "=&r")
(minus:DI (match_operand:DI 1 "arith_reg_operand" "0")
(match_operand:DI 2 "arith_reg_operand" "r")))
(clobber (reg:SI T_REG))]
"TARGET_SH1"
"#"
- [(set_attr "length" "6")])
-
-(define_split
- [(set (match_operand:DI 0 "arith_reg_dest" "")
- (minus:DI (match_operand:DI 1 "arith_reg_operand" "")
- (match_operand:DI 2 "arith_reg_operand" "")))
- (clobber (reg:SI T_REG))]
- "TARGET_SH1 && reload_completed"
+ "&& reload_completed"
[(const_int 0)]
{
rtx high0 = gen_highpart (SImode, operands[0]);
@@ -2861,9 +2847,9 @@
[(set_attr "type" "dmpy")])
(define_expand "mulsidi3"
- [(set (match_operand:DI 0 "arith_reg_operand" "=r")
- (mult:DI (sign_extend:DI (match_operand:SI 1 "arith_reg_operand" "r"))
- (sign_extend:DI (match_operand:SI 2 "arith_reg_operand" "r"]
+ [(set (match_operand:DI 0 "arith_reg_dest" "")
+ (mult:DI (sign_extend:DI (match_operand:SI 1 "arith_reg_operand" ""))
+ (sign_extend:DI (match_operand:SI 2 "arith_reg_operand" ""]
"TARGET_SH2 || TARGET_SHMEDIA"
{
if (TARGET_SH2)
@@ -2882,7 +2868,7 @@
[(set_attr "type" "dmpy_media")
(set_attr "highpart" "ignore")])
-(define_insn "mulsidi3_compact"
+(define_insn_and_split "mulsidi3_compact"
[(set (match_operand:DI 0 "arith_reg_dest" "=r")
(mult:DI
(sign_extend:DI (match_operand:SI 1 "arith_reg_operand" "r"))
@@ -2890,16 +2876,8 @@
(clobber (reg:SI MACH_REG))
(clobber (reg:SI MACL_REG))]
"TARGET_SH2"
- "#")
-
-(define_split
- [(set (match_operand:DI 0 "arith_reg_dest" "")
- (mult:DI
- (sign_extend:DI (match_operand:SI 1 "arith_reg_operand" ""))
- (sign_extend:DI (match_operand:SI 2 "arith_reg_operand" ""
- (clobber (reg:SI MACH_REG))
- (clobber (reg:SI MACL_REG))]
- "TARGET_SH2"
+ "#"
+ "&& 1"
[(const_int 0)]
{
rtx low_dst = gen_lowpart (SImode, operands[0]);
@@ -2930,9 +2908,9 @@
[(set_attr "type" "dmpy")])
(define_expand "umulsidi3"
- [(set (match_operand:DI 0 "arith_reg_operand" "=r")
- (mult:DI (zero_extend:DI (match_operand:SI 1 "arith_reg_operand" "r"))
- (zero_extend:DI (match_operand:SI 2 "arith_reg_operand" "r"]
+ [(set (match_operand:DI 0 "arith_reg_dest" "")
+ (mult:DI (zero_extend:DI (match_operand:SI 1 "arith_reg_operand" ""))
+ (zero_extend:DI (match_operand:SI 2 "arith_reg_operand" ""]
"TARGET_SH2 || TARGET_SHMEDIA"
{
if (TARGET_SH2)
@@ -2951,7 +2929,7 @@
[(set_attr "type" "dmpy_media")
(set_attr "highpart" "ignore")])
-(define_insn "umulsidi3_compact"
+(define_insn_and_split "umulsidi3_compact"
[(set (match_operand:DI 0 "arith_reg_dest" "=r")
(mult:DI
(zero_extend:DI (match_operand:SI 1 "arith_reg_operand" "r"))
@@ -2959,15 +2937,8 @@
(clobber (reg:SI MACH_REG))
(clobber (reg:SI MACL_REG))]
"TARGET_SH2"
- "#")
-
-(define_split
- [(set (match_operand:DI 0 "arith_reg_dest" "")
- (mult:DI (zero_extend:DI (match_operand:SI 1 "arith_reg_operand" ""))
- (zero_extend:DI (match_operand:SI 2 "arith_reg_operand" ""
-
[SH] Add test case for PR 38621
Hello,
The attached patch adds the test case from comment #3 of PR 38621 to the
test suite.
Tested with
make check-gcc RUNTESTFLAGS="compile.exp=pr38621.c --target_board=sh-sim
\{-m2/-ml,-m2/-mb,-m2a/-mb,-m2a-single/-mb,-m4/-ml,-m4/-mb,-m4-single/-ml,
-m4-single/-mb,-m4a-single/-ml,-m4a-single/-mb}"
OK?
Cheers,
Oleg
testsuite/ChangeLog:
target PR/38621
* gcc.c-torture/compile/pr38621.c: New.
Index: gcc/testsuite/gcc.c-torture/compile/pr38621.c
===
--- gcc/testsuite/gcc.c-torture/compile/pr38621.c (revision 0)
+++ gcc/testsuite/gcc.c-torture/compile/pr38621.c (revision 0)
@@ -0,0 +1,17 @@
+/* PR target/38621 */
+struct s
+{
+ char a[512];
+ int b;
+ int c;
+};
+
+long long
+foo (struct s *p, int m, int r)
+{
+ if (r == m)
+p->b = 3;
+ p->c = 1;
+ return m;
+}
+
Re: [PATCH] ARM: exclude fixed_regs for stack-alignment save/restore
Richard, here is the patch against the current trunk, as I promised
last week in Prague. Please apply.
Thanks,
Roland
gcc/
2012-07-17 Roland McGrath
* config/arm/arm.c (arm_get_frame_offsets): Never use a fixed register
as the extra register to save/restore for stack-alignment padding.
diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index e2f625c..189f71e 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -16121,7 +16121,12 @@ arm_get_frame_offsets (void)
else
for (i = 4; i <= (TARGET_THUMB1 ? LAST_LO_REGNUM : 11); i++)
{
- if ((offsets->saved_regs_mask & (1 << i)) == 0)
+ /* While the gratuitous register save/restore is ordinarily
+ harmless, if a register is marked as fixed or global it
+ may be entirely forbidden by the system ABI to touch it,
+ so we should avoid those registers. */
+ if (!fixed_regs[i]
+ && (offsets->saved_regs_mask & (1 << i)) == 0)
{
reg = i;
break;
[Patch, mips] Fix compiler abort with -mips32r2 -mips16 -msynci
While working on my favorite mips option (-msynci) I noticed an odd thing.
If I compile with '-mips32 -mips16 -msynci' I got a warning about synci not
being supported but if I compiled with '-mips32r2 -mips16 -msynci' I did not
get a warning, even though -mips16 mode does not support synci. Furthermore
if I compiled a program that called __builtin___clear_cache with '-mips32r2
-mips16 -msynci', the compiler would abort.
In mips.h we have:
/* ISA includes synci, jr.hb and jalr.hb. */
#define ISA_HAS_SYNCI ((ISA_MIPS32R2\
|| ISA_MIPS64R2)\
&& !TARGET_MIPS16)
What I found was that in mips_option_override, where we check this macro
to generate the warning we have this code at the front of the function:
/* Process flags as though we were generating non-MIPS16 code. */
mips_base_mips16 = TARGET_MIPS16;
target_flags &= ~MASK_MIPS16;
Then later, we check ISA_HAS_SYNCI, but at that point TARGET_MIPS16 is
always false because of the above lines.
I looked at changing ISA_HAS_SYNCI to use target_flag_explicit but that
seems like the wrong thing to do for the use of ISA_HAS_SYNCI in mips.md.
Then I modified the if statement in mips_option_override but that resulted
in the use of 'mips32r2 -mips16 -msynci' giving an odd warning message:
warning: the ‘mips32r2’ architecture does not support the synci instruction
But of course mips32r2 does support synci, it is -mips16 that does not. So I
added a new if statement with an explicit check against mips_base_mips16 to
give a better warning.
OK to checkin?
Steve Ellcey
sell...@mips.com
2012-07-17 Steve Ellcey
* config/mips/mips.c (mips_option_override): Fix check for -mips16
-msynci combination of flags.
diff --git a/gcc/config/mips/mips.c b/gcc/config/mips/mips.c
index 7356ce5..889cfb5 100644
--- a/gcc/config/mips/mips.c
+++ b/gcc/config/mips/mips.c
@@ -16212,6 +16212,14 @@ mips_option_override (void)
target_flags &= ~MASK_SYNCI;
}
+ /* ISA_HAS_SYNCI checks TARGET_MIPS16 but that was turned off at the
+ beginning of this function so we need to check mips_base_mips16. */
+ if (TARGET_SYNCI && mips_base_mips16)
+{
+ warning (0, "the \'mips16\' ASE does not support the synci instruction");
+ target_flags &= ~MASK_SYNCI;
+}
+
/* Only optimize PIC indirect calls if they are actually required. */
if (!TARGET_USE_GOT || !TARGET_EXPLICIT_RELOCS)
target_flags &= ~MASK_RELAX_PIC_CALLS;
Re: [Fortran, Patch] Fix #line parsing
Mikael Morin wrote:
On 17/07/2012 20:52, Tobias Burnus wrote:
Build and regtested on x86-64-gnu-linux.
OK for the trunk?
Sorry, I hit "Sent" a tad too early. The patch failed because it was
also parsing the first few lines of a cpped file, which are, e.g.,
# 1 "gfortran.dg/g77/cpp4.F"
# 1 ""
# 1 "gfortran.dg/g77/cpp4.F"
That lead to the warning:
-
gfortran.dg/g77/cpp4.F:6.16:
Included at :1:
Included at gfortran.dg/g77/cpp4.F:1:
Included at gfortran.dg/g77/cpp4.F:1:
data i /4hbla'/
1
Warning: Extension: Hollerith constant at (1)
-
At the same time, it had also to work with gfortran.dg/g77/20010321-1.f,
which is not preprocessed but contains the following lines:
# 1 "20010321-1.f"
# 1 "include/implicit.h" 1 3
# 3 "20010321-1.f" 2 3
The current patch is slightly uglier than the original version, but it
seems to work.
PS: I didn't include a test case; one could create one using
-fdump-tree-original-lineno, if you think that it makes sense.
OK; I prefer with a testcase.
I have now also included a test case.
Thanks for the review – and sorry for asking for another review.
Tobias
PS: I wouldn't mind if you could review the assumed-rank patch. I know
that it is rather big, but it kind of blocks me from writing other
patches. I think the first external user will be Open MPI,* as MPIv3
will support assumed-rank arrays.
* Draft MPIv3 http://www.unixer.de/sec/mpi-report-r1300.pdf ; draft Open
MPI implementation https://bitbucket.org/jsquyres/mpi3-fortran/
2012-07-17 Tobias Burnus
PR fortran/53993
* scanner.c (preprocessor_line): Fix parsing of a "#line"
which has no flags, add new parameter.
(load_file): Update the call.
2012-07-17 Tobias Burnus
PR fortran/53993
* gfortran.dg/debug_3.F90: New.
diff --git a/gcc/fortran/scanner.c b/gcc/fortran/scanner.c
index 4fad58b..56eaa48 100644
--- a/gcc/fortran/scanner.c
+++ b/gcc/fortran/scanner.c
@@ -1646,7 +1646,7 @@ get_file (const char *name, enum lc_reason reason ATTRIBUTE_UNUSED)
initial octothorp has already been seen. */
static void
-preprocessor_line (gfc_char_t *c)
+preprocessor_line (gfc_char_t *c, bool ignore_line)
{
bool flag[5];
int i, line;
@@ -1654,6 +1654,9 @@ preprocessor_line (gfc_char_t *c)
gfc_file *f;
int escaped, unescape;
char *filename;
+ enum {FLAG_NEW_FILE = 1, FLAG_PREV_FILE, FLAG_SYSHEADER, FLAG_EXTERN_C};
+
+ /* The expected syntax is "# linenumber filename flags". */
c++;
while (*c == ' ' || *c == '\t')
@@ -1739,20 +1742,25 @@ preprocessor_line (gfc_char_t *c)
flag[i] = true;
}
+ /* No flag implies that one might have a new file. However, we have to skip
+ over the first three lines of a cpp'ed file. */
+ if (!flag[FLAG_NEW_FILE] && !flag[FLAG_PREV_FILE] && !ignore_line)
+flag[FLAG_NEW_FILE] = true;
+
/* Convert the filename in wide characters into a filename in narrow
characters. */
filename = gfc_widechar_to_char (wide_filename, -1);
/* Interpret flags. */
- if (flag[1]) /* Starting new file. */
+ if (flag[FLAG_NEW_FILE]) /* Starting new file. */
{
f = get_file (filename, LC_RENAME);
add_file_change (f->filename, f->inclusion_line);
current_file = f;
}
- if (flag[2]) /* Ending current file. */
+ if (flag[FLAG_PREV_FILE]) /* Ending current file. */
{
if (!current_file->up
|| filename_cmp (current_file->up->filename, filename) != 0)
@@ -1959,12 +1967,12 @@ load_file (const char *realfilename, const char *displayedname, bool initial)
if (initial && gfc_src_preprocessor_lines[0])
{
- preprocessor_line (gfc_src_preprocessor_lines[0]);
+ preprocessor_line (gfc_src_preprocessor_lines[0], initial);
free (gfc_src_preprocessor_lines[0]);
gfc_src_preprocessor_lines[0] = NULL;
if (gfc_src_preprocessor_lines[1])
{
- preprocessor_line (gfc_src_preprocessor_lines[1]);
+ preprocessor_line (gfc_src_preprocessor_lines[1], initial);
free (gfc_src_preprocessor_lines[1]);
gfc_src_preprocessor_lines[1] = NULL;
}
@@ -2015,7 +2023,7 @@ load_file (const char *realfilename, const char *displayedname, bool initial)
;
else
{
- preprocessor_line (line);
+ preprocessor_line (line, first_line);
continue;
}
}
--- /dev/null 2012-07-17 07:28:04.995717470 +0200
+++ gcc/gcc/testsuite/gfortran.dg/debug_3.F90 2012-07-17 21:19:34.0 +0200
@@ -0,0 +1,25 @@
+! { dg-do compile }
+! { dg-options "-fdump-tree-original-lineno" }
+!
+! PR fortran/53993
+!
+! Contributed by Markus Geimer
+!
+program dummy
+write(*,*) "Starting dummy"
+#line 444 "newFile.f90"
+call foo
+write(*,*) "Stopping dummy"
+#line 455 "newFile.f90"
+end program dummy
+#line 16 "debug_3.F90"
+
+subroutine foo
+write(*,*) "Hello world!"
+end subroutine foo
+
+! { dg-final { scan-tree-dump "newFile.f90 : 444" "original" } }
+! { dg-final { scan-tree-dump "newFile.f90 : 445" "original
C++ PATCH for c++/53989 (ICE with array of typedef)
As it turns out, the problem in this case was that we were building up a
canonical array as part of building up an array of the typedef, but we
didn't add it to the list of array variants, so
complete_vars/finalize_type_size couldn't find it to fix it up. Fixed
by adding it to the variant list appropriately.
Tested x86_64-pc-linux-gnu, applying to trunk and 4.7.
commit 465cefa1e575ccedfa6655018a31241ba2a669c6
Author: Jason Merrill
Date: Tue Jul 17 16:56:04 2012 -0400
PR c++/53989
* tree.c (build_cplus_array_type): Also add TYPE_CANONICAL
to the list of variants.
diff --git a/gcc/cp/tree.c b/gcc/cp/tree.c
index 01bc483..3c7bbb132 100644
--- a/gcc/cp/tree.c
+++ b/gcc/cp/tree.c
@@ -803,12 +803,23 @@ build_cplus_array_type (tree elt_type, tree index_type)
{
tree m = build_cplus_array_type (TYPE_MAIN_VARIANT (elt_type),
index_type);
+ tree c = TYPE_CANONICAL (t);
+
if (TYPE_MAIN_VARIANT (t) != m)
{
TYPE_MAIN_VARIANT (t) = m;
TYPE_NEXT_VARIANT (t) = TYPE_NEXT_VARIANT (m);
TYPE_NEXT_VARIANT (m) = t;
}
+
+ /* If we built a new array type for TYPE_CANONICAL, add
+ that to the list of variants as well. */
+ if (c && c != t && TYPE_MAIN_VARIANT (c) != m)
+ {
+ TYPE_MAIN_VARIANT (c) = m;
+ TYPE_NEXT_VARIANT (c) = t;
+ TYPE_NEXT_VARIANT (m) = c;
+ }
}
/* Push these needs up so that initialization takes place
diff --git a/gcc/testsuite/g++.dg/template/array23.C b/gcc/testsuite/g++.dg/template/array23.C
new file mode 100644
index 000..6ede8b0
--- /dev/null
+++ b/gcc/testsuite/g++.dg/template/array23.C
@@ -0,0 +1,12 @@
+// PR c++/53989
+
+struct Foo {
+ int value;
+ typedef Foo Foo2;
+ static Foo2 const foos[2];
+};
+
+template void g (T);
+void bar() {
+ g(&Foo::foos);
+}
Re: [PR52983] eliminate autoinc from debug_insn locs
On 07/17/2012 02:36 PM, Alexandre Oliva wrote: > http://gcc.gnu.org/ml/gcc-patches/2012-05/msg00300.html ... except that post has patch 1 repeated as patch 3. The actual patch 3 is missing. That said, the first two patches are ok. Please repost #3. r~
Re: [Patch, Fortran] gfc_notify_std cleanup
Okay, that won't work as one has to call error_print only once. Maybe
something like the following will work:
const char *msg, *msg2;
char *buffer;
msg = _("Warning: ");
msg2 = _("Deleted feature:");
buffer = (char *) alloca (strlen (msg) + strlen (msg2)+1);
strcpy(buffer, msg);
strcat (buffer, msg2);
error_print (buffer, _(gmsgid), argp);
where the buffer itself is not send through _().
>>>
>>> With this you are almost back to my last version, except that you
>>> allocate the buffer dynamically.
>> ... which is better ;-).
>
> Yes, of course it's better :)
>
> Attached is a new version, which uses the dynamic allocation as
> proposed by Tobias.
>
>
>> Nice patch anyway.
>
> Thanks. In case there are more comments on the patch, just keep it
> coming. Otherwise I'll commit the attached version soon (once I'm done
> with the tedious task of writing a ChangeLog for this baby).
Committed as r189589.
Cheers,
Janus
Re: [SH] Add test case for PR 38621
On Jul 17, 2012, at 1:06 PM, Oleg Endo wrote:
> The attached patch adds the test case from comment #3 of PR 38621 to the
> test suite.
>
> Tested with
> make check-gcc RUNTESTFLAGS="compile.exp=pr38621.c --target_board=sh-sim
> \{-m2/-ml,-m2/-mb,-m2a/-mb,-m2a-single/-mb,-m4/-ml,-m4/-mb,-m4-single/-ml,
> -m4-single/-mb,-m4a-single/-ml,-m4a-single/-mb}"
>
> OK?
Gosh, the code looks so, portable. :-)
Ok. I'd say nix the blank line at the end of the file.
Re: CRIS atomics revisited 4/4: give up on alignment of atomic data, RFC for is_lock_free hook
> From: Andrew MacLeod
> Date: Tue, 17 Jul 2012 14:24:48 +0200
> Any PR's you open related this this, copy me on them and I'll try to get
> them addressed.
I could separate the issues I saw into PRs 54003-6. That's all,
hopefully ...at least for now. :)
BTW, your @gcc.gnu.org account doesn't have a bugzilla account
("did not match anything" says bugzilla), contrary to most/all
other accounts. Maybe deliberate or known, maybe something to
look into.
brgds, H-P
Re: CRIS atomics revisited 4/4: give up on alignment of atomic data, RFC for is_lock_free hook
On 07/17/2012 06:55 PM, Hans-Peter Nilsson wrote:
From: Andrew MacLeod
Date: Tue, 17 Jul 2012 14:24:48 +0200
Any PR's you open related this this, copy me on them and I'll try to get
them addressed.
I could separate the issues I saw into PRs 54003-6. That's all,
hopefully ...at least for now. :)
Thanks, I'll have a look at them shortly.
BTW, your @gcc.gnu.org account doesn't have a bugzilla account
("did not match anything" says bugzilla), contrary to most/all
other accounts. Maybe deliberate or known, maybe something to
look into.
known, but never got around to investigating since it hasn't had a
determinable effect :-)
Andrew
Re: [patch][rfc] Clean up CFG dumping
On Tue, Jul 17, 2012 at 9:40 AM, Bernhard Reutner-Fischer
wrote:
> s/anem/name/g
Good catch.
>>> * tree-cfg.c (gimple_can_merge_blocks_p): Use EDGE_COMPLEX.
>
> I take it you added EDGE_ABNORMAL_CALL on purpose?
Yes. I don't think it matters in practice because such edges will
have EDGE_EH or EDGE_ABNORMAL set also, but this flag does belong to
the set.
>>> (dump_bb_info): Removed and re-incarnated in cfg.c.
>
> + if (flags & TDF_COMMENT)
> + fputs (";; ", outf);
>
> This emits an ugly trailing space, perhaps we can remove this now?
The old code had this too:
- fprintf (outf, ";;%s basic block %d, loop depth %d, count ",
It's necessary to guarantee there's always a space between ";;" and
whatever follows next, also with ident==0.
So I've not change this.
> + fprintf (outf, "%s prev block ", s_indent);
> + if (bb->prev_bb)
> + fprintf (outf, "%d, ", bb->prev_bb->index);
> + else
> + fprintf (outf, "(nil), ");
> + fprintf (outf, "next block ");
> + if (bb->next_bb)
> + fprintf (outf, "%d", bb->next_bb->index);
> +
> + fputs (", flags:", outf);
>
> This looks like it could emit oddly spaced output, think
> "next block , flags:\n".
This was missing for the next_bb case:
> + else
> + fprintf (outf, "(nil), ");
Fixed that before commit.
> It would be nice to alway have the required spaces _before_ the
> actual string in this function, imho.
Most of the function comes from old cfgrtl.c:dump_bb_info, and bits
from old gimple-pretty-print.c:dump_bb_header. I'm not really
interested in making the dumps pretty. Just complete and correct is a
good start. Aesthetically, all dumps are ugly, but I admit that some
dumps are more ugly than others. Patches welcome ;-)
Thanks for your review!
Ciao!
Steven
[patch] Add v850-*-rtems*
Hi,
The patch below adds an v850-*-rtems* target configuration to GCC.
It's a sightly modified copy of the v850*-*-* target, with some RTEMS
specific changes added.
I would like to apply this patch to trunk and gcc-4_7-branch.
OK to commit?
Ralf
2012-06-27 Ralf Corsépius
* config.gcc (v850-*-rtems*): New target.
* config/v850/rtems.h: New.
* config/v850/t-rtems: New.
diff --git a/gcc/config.gcc b/gcc/config.gcc
index 7768917..39ea7c8 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -2448,6 +2448,16 @@ tilepro-*-linux*)
c_target_objs="tilepro-c.o"
cxx_target_objs="tilepro-c.o"
;;
+v850-*-rtems*)
+ target_cpu_default="TARGET_CPU_generic"
+ tm_file="dbxelf.h elfos.h v850/v850.h"
+ tm_file="${tm_file} rtems.h v850/rtems.h newlib-stdint.h"
+ tmake_file="${tmake_file} v850/t-v850"
+ tmake_file="${tmake_file} t-rtems v850/t-rtems"
+ use_collect2=no
+ c_target_objs="v850-c.o"
+ cxx_target_objs="v850-c.o"
+ ;;
v850*-*-*)
case ${target} in
v850e2v3-*-*)
diff --git a/gcc/config/v850/rtems.h b/gcc/config/v850/rtems.h
new file mode 100644
index 000..397d2e0
--- /dev/null
+++ b/gcc/config/v850/rtems.h
@@ -0,0 +1,29 @@
+/* Definitions for rtems targeting a v850 using ELF.
+ 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
+
Re: [patch][rfc] Clean up CFG dumping
On Mon, Jul 16, 2012 at 8:57 AM, Steven Bosscher wrote: > Hello, > > There are comments in basic-block.h that advise to update certain > parts of the compiler if a new edge flag or basic block flag is added: > > -/* Always update the table in cfg.c dump_edge_info. */ > > and > > - Always update the table in cfg.c dump_bb_info. */ > > Apparently this is not enough, because there are more places where the > BB flags are dumped. For instance, cfg.c:dump_cfg_bb_info does not > handle BB_MODIFIED, BB_VISITED, and BB_IN_TRANSACTION, and > dump_bb_info doesn't even exist in cfg.c (it's in cfgrtl.c). The flags > also aren't documented very well in the code. > > Furthermore, there are multiple places where "common" (i.e. IR > agnostic) basic block information is dumped, with some functions > taking TDF_* flags and others not, some functions taking a FILE as the > first argument and others as the second argument, etc. In short: > Unnecessarily messy. > > The attached patch cleans up the worst of it: > > * A new file cfg-flags.def is used to define the BB_* and EDGE_* > flags. The names are the full string of the name of the flag in > uppercase, that's a change from before. I can add a separate name > field to DEF_EDGE_FLAG and DEF_BB_FLAG if necessary. > > * Now that there is dumpfile.h for the TDF_* masks, it's easier to use > them everywhere. I have added one new flag to dump with the ";;" > prefix (I think it should be used in more places, but that's something > for later, perhaps). > > * All basic block header/footer and edge dumping is consolidated in > dump_edge_info and dump_bb_info. This affects GIMPLE dump the most, > because it uses a different form of dumping for basic block > predecessors and successors. I expect some fall-out in the test suite > (patterns that no longer match) that I'll have to address before the > patch is ready for mainline. > > * Slim RTL printing is better integrated: print_rtl_with_bb takes > flags and uses dump_rtl_slim if TDF_SLIM is passed. The same happens > in rtl_dump_bb, which always dumps non-slim RTL without this patch. > > Bootstrapped on powerpc64-unknown-linux-gnu. Testing will probably > reveal some test suite pattern mismatches, and I also still want to > bootstrap&test this on x86_64. > I'd like to hear what people think of the cfg-flags.def change. > > Ciao! > Steven > > * dumpfile.h (TDF_COMMENT): New define. > * basic-block.h (EDGE_FALLTHRU, EDGE_ABNORMAL, EDGE_ABNORMAL_CALL, > EDGE_EH, EDGE_FAKE, EDGE_DFS_BACK, EDGE_CAN_FALLTHRU, > EDGE_IRREDUCIBLE_LOOP, EDGE_SIBCALL, EDGE_LOOP_EXIT, EDGE_TRUE_VALUE, > EDGE_FALSE_VALUE, EDGE_EXECUTABLE, EDGE_CROSSING, EDGE_PRESERVE): > Move to new file cfg-flags.h. > (enum cfg_edge_flags): New enum, using cfg-flags.h. > (EDGE_ALL_FLAGS): Compute value automatically. > (BB_NEW, BB_REACHABLE, BB_IRREDUCIBLE_LOOP, BB_SUPERBLOCK, > BB_DISABLE_SCHEDULE, BB_HOT_PARTITION, BB_COLD_PARTITION, > BB_DUPLICATED, BB_NON_LOCAL_GOTO_TARGET, BB_RTL, > BB_FORWARDER_BLOCK, BB_NONTHREADABLE_BLOCK, BB_MODIFIED, BB_VISITED, > BB_IN_TRANSACTION): Move to new file cfg-flags.h. > (enum bb_flags): Rename to cfg_bb_flags. Use cfg-flags.h. > (BB_ALL_FLAGS): New, compute value automatically. > (dump_bb_info): Update prototype. > (dump_edge_info): Update prototype. > * cfg-flags.h: New file. > * cfg.c (dump_edge_info): Take flags argument. Be verbose only if > TDF_DETAILS and not TDF_SLIM. Include cfg-flags.h for bitnames. > Check that the edge flags are within the range of EDGE_ALL_FLAGS. > (debug_bb): Update dump_bb call. > (dump_cfg_bb_info): Remove. > (dump_bb_info): New function. Use cfg-flags.h for bitnames. > Adjust verbosity using TDF_* flags. Check that the basic block flags > are within the range of BB_ALL_FLAGS. > (brief_dump_cfg): Use dump_bb_info instead of dump_cfg_bb_info. > * cfghooks.h (struct cfghooks): Update dump_bb hook, take a FILE > first for consistency with other dump functions. > (dump_bb): Update prototype accordingly. > * cfghooks.c: Include dumpfile.h. > (verify_flow_info): Update dump_edge_info calls. > (dump_bb): Take a flags argument and pass it around. > Use dump_bb_info to dump common information about a basic block. > (dump_flow_info): Moved here from cfgrtl.c. Make IL agnostic. > (debug_flow_info): Moved here from cfgrtl.c. > * profile.c (is_edge_inconsistent): Update dump_bb calls. > * loop-invariant.c (find_defs): Update print_rtl_with_bb call. > * rtl.h (debug_bb_n_slim, debug_bb_slim, print_rtl_slim, > print_rtl_slim_with_bb): Remove prototypes. > (dump_insn_slim): Adjust prototype to take a const_rtx. > (print_rtl_with_bb): Adjust prototype. > * sched-rgn.c (debug_
Re: [SH] PR 33135
Oleg Endo wrote:
> The attached patch fixes PR 33135 as discussed in the PR.
> Tested with
>
> make info dvi pdf
>
> and
>
> make check-gcc RUNTESTFLAGS="sh.exp=pr33135* --target_board=sh-sim
> \{-m2/-ml,-m2/-mb,-m2e,-m3,-m3e,-m2a/-mb,-m2a-single/-mb,-m4/-ml,
> -m4/-mb,-m4-single/-ml,-m4-single/-mb,-m4a-single/-ml,-m4a-single/-mb}"
>
> OK?
OK.
Regards,
kaz
Re: [SH] Use some more insn_and_split in MD
Oleg Endo wrote:
> The attached patch folds some define_insn and define_split with
> define_insn_and_split and removes constraints in some expander
> definitions.
>
> Tested on rev 189549 with
> make -k check RUNTESTFLAGS="--target_board=sh-sim
> \{-m2/-ml,-m2/-mb,-m2a/-mb,-m2a-single/-mb,-m4/-ml,-m4/-mb,
> -m4-single/-ml,-m4-single/-mb,-m4a-single/-ml,-m4a-single/-mb}"
>
> and no new failures.
> CSiBE result-size (-m4-single -ml -O2 -mpretend-cmove) also shows no
> changes.
>
> OK?
OK.
Regards,
kaz
RE: [wwwdocs] Document ARM/embedded-x_y-branch family
On Tue, 17 Jul 2012, Terry Guo wrote: > Thanks for your comments. I updated the description to address this > concern. Is it OK? Looks good to me! And I meant to imply that you should feel free to go ahead. :-) Thanks, Gerald
[committed] restrict gcc.target/m68k/pr36134.c to ColdFire
I've checked in this patch, which was conditionally approved 3+ years ago: http://gcc.gnu.org/ml/gcc-patches/2009-05/msg00688.html I did look at general usage for m68k and adding -mcpu is consistent with other existing tests; there aren't enough of them that are conditionalized in this way to justify adding a more complicated test framework. -Sandra
Re: [C++ RFC / Patch] PR 51213 ("access control under SFINAE")
Hi again,
Hmm, now that I look at the code in instantiate_decl for
re-substituting to get additional errors, I guess I should have
factored that code out into a separate function and used it in the
access7 patch rather than add handling of FNDECL_RECHECK_ACCESS_P in
tsubst_decl.
I see. Could you take care of this improvement? Otherwise the below
passes testing, tries to implement all the changes you indicated.
The below variant adds a fndecl_recheck_access_p and uses it in two
places, in tsubst_decl and instantiate_template_1. Did I understand
correctly?
Tested x86_64-linux.
Thanks,
Paolo.
Index: libstdc++-v3/testsuite/20_util/pair/noncopyable.cc
===
--- libstdc++-v3/testsuite/20_util/pair/noncopyable.cc (revision 0)
+++ libstdc++-v3/testsuite/20_util/pair/noncopyable.cc (revision 0)
@@ -0,0 +1,39 @@
+// { dg-do compile }
+// { dg-options "-std=gnu++11" }
+
+// Copyright (C) 2012 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library. This library 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.
+//
+// This library 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 this library; see the file COPYING3. If not see
+//
[PATCH, testsuite] Skip 20101011-1.c for bare-metal m68k
Like the subject line says; this is consistent with the existing test to bail out for MIPS bare-metal. OK for mainline? -Sandra 2012-07-17 Julian Brown Sandra Loosemore gcc/testsuite/ * gcc.c-torture/execute/20101011-1.c: Skip on bare-metal m68k. Index: gcc/testsuite/gcc.c-torture/execute/20101011-1.c === --- gcc/testsuite/gcc.c-torture/execute/20101011-1.c (revision 189595) +++ gcc/testsuite/gcc.c-torture/execute/20101011-1.c (working copy) @@ -32,6 +32,10 @@ /* Epiphany does not have hardware division, and the software implementation has truly undefined behaviour for division by 0. */ # define DO_TEST 0 +#elif defined (__m68k__) && !defined(__linux__) + /* Attempting to trap division-by-zero in this way isn't likely to work on + bare-metal m68k systems. */ +# define DO_TEST 0 #else # define DO_TEST 1 #endif
Re: [PATCH 1/2] gcc symbol database
> It took me a couple of minutes to understand what you meant here, so > please let me re-phrase to make sure I got it. > > You are saying that the callback function of the cb_lex_token event is > set by the callback function of the macro_start_expand event. > > Is that correct? Yes. > And this makes me wonder why you'd need the second parameter of > macro_start_expand (the token). I believe you should have all the > information you need with the first, second, and last parameter. As I > said in my previous email, you can get the file offset of the token in > your client code by doing 'file_offset = line + column'. So that token > should not be needed. Thus, calling macro_start_expand from inside > funlike_invocation_p once you are sure the expansion of the macro is > going to take place, is possible. The only thing is the file-offset or source_location of the macro leader token. I don't know how to get it when macro_start_expand is called in funlike_invocation_p intern. The parameter `result' of enter_macro_context doesn't be delivered down. And file_offset = sum(`all former column_total_count' + current column_number'), so it can't be deduced from current line_map + source_location desgin. BTW, I can change my plugin to use line/column instead of fileoffset, there ins't design limitation, only time. Yunfeng
Re: [C++ RFC / Patch] PR 51213 ("access control under SFINAE")
On 07/17/2012 09:20 PM, Paolo Carlini wrote: The below variant adds a fndecl_recheck_access_p and uses it in two places, in tsubst_decl and instantiate_template_1. Did I understand correctly? I had something else in mind, but I'll take care of it. Jason
C++ PATCH for c++/53995 (wrong name lookup with enum in member function)
Checking current_class_type isn't enough to determine whether we're at
class scope; in this testcase it's set, but current_scope() is the
member function, so we don't want to mess with the type.
Tested x86_64-pc-linux-gnu, applying to trunk and 4.7.
commit ab4e9d79eae7c11c4dc2e58437f45901c439dca1
Author: Jason Merrill
Date: Tue Jul 17 21:01:41 2012 -0400
PR c++/53995
* decl.c (finish_enum_value_list): Only call
insert_late_enum_def_into_classtype_sorted_fields in class scope.
diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index 84b78f6..8a3163a 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -12392,7 +12392,7 @@ finish_enum_value_list (tree enumtype)
for (t = TYPE_MAIN_VARIANT (enumtype); t; t = TYPE_NEXT_VARIANT (t))
TYPE_VALUES (t) = TYPE_VALUES (enumtype);
- if (current_class_type
+ if (at_class_scope_p ()
&& COMPLETE_TYPE_P (current_class_type)
&& UNSCOPED_ENUM_P (enumtype))
insert_late_enum_def_into_classtype_sorted_fields (enumtype,
diff --git a/gcc/testsuite/g++.dg/parse/enum9.C b/gcc/testsuite/g++.dg/parse/enum9.C
new file mode 100644
index 000..559db31
--- /dev/null
+++ b/gcc/testsuite/g++.dg/parse/enum9.C
@@ -0,0 +1,13 @@
+// PR c++/53995
+
+enum E1 { e };
+void f(E1);
+
+struct A {
+ int i1,i2,i3,i4,i5,i6,i7,i8,i9,i10;
+ void g();
+ void h();
+};
+
+void A::g() { enum E2 { e }; }
+void A::h() { f(e); }
Re: [gimplefe] Construction of individual gimple statements for gimple_cond and gimple_label
On Tue, Jul 17, 2012 at 6:16 PM, Diego Novillo wrote: > > Not so much, anymore > (http://gcc.gnu.org/codingconventions.html#Variable). When gimplefe > is merged into trunk, we will be using the C++ conventions which now > allow this. > > No need to change anything, Sandy. Ah..Saved by the skin of my teeth. Thanks! -- Cheers Sandy
