Re: [PATCH v2] ARM: Use different linker path for hardfloat ABI
On 05/01/2012 10:52 AM, Richard Earnshaw wrote:
On 30/04/12 22:47, Michael Hope wrote:
On 1 May 2012 03:24, Richard Earnshawrearn...@arm.com wrote:
On 27/04/12 00:27, Michael Hope wrote:
On 27 April 2012 08:20, Carlos O'Donellcar...@systemhalted.org wrote:
On Mon, Apr 23, 2012 at 5:36 PM, Michael Hopemichael.h...@linaro.org wrote:
2012-04-24 Michael Hopemichael.h...@linaro.org
Richard Earnshawrearn...@arm.com
* config/arm/linux-eabi.h (GLIBC_DYNAMIC_LINKER_SOFT_FLOAT): Define.
(GLIBC_DYNAMIC_LINKER_HARD_FLOAT): Define.
(GLIBC_DYNAMIC_LINKER_DEFAULT): Define.
(GLIBC_DYNAMIC_LINKER): Redefine to use the hard float path.
diff --git a/gcc/config/arm/linux-eabi.h b/gcc/config/arm/linux-eabi.h
index 80bd825..2ace6f0 100644
--- a/gcc/config/arm/linux-eabi.h
+++ b/gcc/config/arm/linux-eabi.h
@@ -62,7 +62,17 @@
/* Use ld-linux.so.3 so that it will be possible to run classic
GNU/Linux binaries on an EABI system. */
#undef GLIBC_DYNAMIC_LINKER
-#define GLIBC_DYNAMIC_LINKER /lib/ld-linux.so.3
+#define GLIBC_DYNAMIC_LINKER_SOFT_FLOAT /lib/ld-linux.so.3
+#define GLIBC_DYNAMIC_LINKER_HARD_FLOAT /lib/ld-linux-armhf.so.3
+#if TARGET_DEFAULT_FLOAT_ABI == ARM_FLOAT_ABI_HARD
+#define GLIBC_DYNAMIC_LINKER_DEFAULT GLIBC_DYNAMIC_LINKER_HARD_FLOAT
+#else
+#define GLIBC_DYNAMIC_LINKER_DEFAULT GLIBC_DYNAMIC_LINKER_SOFT_FLOAT
+#endif
+#define GLIBC_DYNAMIC_LINKER \
+ %{mfloat-abi=hard: GLIBC_DYNAMIC_LINKER_HARD_FLOAT } \
+%{mfloat-abi=soft*: GLIBC_DYNAMIC_LINKER_SOFT_FLOAT } \
+%{!mfloat-abi=*: GLIBC_DYNAMIC_LINKER_DEFAULT }
/* At this point, bpabi.h will have clobbered LINK_SPEC. We want to
use the GNU/Linux version, not the generic BPABI version. */
This patch is broken. Please fix this.
You can't use a named enumeration in cpp equality.
The type ARM_FLOAT_ABI_HARD is a named enumeration and evaluates to 0
as an unknown identifier.
Therefore #if TARGET_DEFAULT_FLOAT_ABI == ARM_FLOAT_ABI_HARD
evaluates to #if 0 == 0 and is always true.
Watch out that #define ARM_FLOAT_ABI_HARD ARM_FLOAT_ABI_HARD for
such enums is not conforming C99/C11.
I suggest you define the types as macros and then set the named enum
to those values, then use the macros in the header equality checks.
e.g.
#define VAL1 0 then enum FOO { RVAL1 = VAL1, ... }
Look at arm.h for the enum definition.
I've looked further into this and I think the original pre-#if version
is correct.
The float ABI comes from these places:
* The -mfloat-abi= command line argument, else
* The --with-float= configure time argument, else
* TARGET_DEFAULT_FLOAT_ABI from linux-eabi.h
In the first case the ABI is explicit. In the second
OPTION_DEFAULT_SPECS turns the configure time argument into an explict
-mfloat-abi=.
The patch below covers all cases, keeps the logic in the spec file,
and adds a comment linking the two #defines.
Tested by building with no configure flags, --wtih-float=softfp,
--with-float=hard, and then running with all combinations of
{,-mfloat-abi=softfp,-mfloat-abi=hard} {,-mglibc,-muclibc,-mbionic}.
OK?
-- Michael
2012-04-27 Michael Hopemichael.h...@linaro.org
* config/arm/linux-eabi.h (GLIBC_DYNAMIC_LINKER): Pick the loader
using a spec rule.
Michael,
can you try this patch please. It should make it possible to then
create linux-eabihf.h containing just
#undef TARGET_DEFAULT_FLOAT_ABI
#define TARGET_DEFAULT_FLOAT_ABI ARM_FLOAT_ABI_HARD
#undef GLIBC_DYNAMIC_LINKER_DEFAULT
#define GLIBC_DYNAMIC_LINKER_DEFAULT GLIBC_DYNAMIC_LINKER_HARD_FLOAT
Which is not quite as simple as leaving out the second re-define, but
pretty close.
Hi Richard. Your patch tests just fine. I like it. You could change
the spec rule to the newer if-elseif-else form but that's a nit.
-- Michael
Great, thanks! I've committed it as is.
I suggest to add this also to the gcc 4.7 branch. Richard (Earnshaw),
could you do take care of this, please?
Thanks,
Andreas
--
Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
Re: [PATCH v2] ARM: Use different linker path for hardfloat ABI
On 23/05/12 08:12, Andreas Jaeger wrote:
On 05/01/2012 10:52 AM, Richard Earnshaw wrote:
On 30/04/12 22:47, Michael Hope wrote:
On 1 May 2012 03:24, Richard Earnshawrearn...@arm.com wrote:
On 27/04/12 00:27, Michael Hope wrote:
On 27 April 2012 08:20, Carlos O'Donellcar...@systemhalted.org wrote:
On Mon, Apr 23, 2012 at 5:36 PM, Michael Hopemichael.h...@linaro.org
wrote:
2012-04-24 Michael Hopemichael.h...@linaro.org
Richard Earnshawrearn...@arm.com
* config/arm/linux-eabi.h (GLIBC_DYNAMIC_LINKER_SOFT_FLOAT):
Define.
(GLIBC_DYNAMIC_LINKER_HARD_FLOAT): Define.
(GLIBC_DYNAMIC_LINKER_DEFAULT): Define.
(GLIBC_DYNAMIC_LINKER): Redefine to use the hard float path.
diff --git a/gcc/config/arm/linux-eabi.h b/gcc/config/arm/linux-eabi.h
index 80bd825..2ace6f0 100644
--- a/gcc/config/arm/linux-eabi.h
+++ b/gcc/config/arm/linux-eabi.h
@@ -62,7 +62,17 @@
/* Use ld-linux.so.3 so that it will be possible to run classic
GNU/Linux binaries on an EABI system. */
#undef GLIBC_DYNAMIC_LINKER
-#define GLIBC_DYNAMIC_LINKER /lib/ld-linux.so.3
+#define GLIBC_DYNAMIC_LINKER_SOFT_FLOAT /lib/ld-linux.so.3
+#define GLIBC_DYNAMIC_LINKER_HARD_FLOAT /lib/ld-linux-armhf.so.3
+#if TARGET_DEFAULT_FLOAT_ABI == ARM_FLOAT_ABI_HARD
+#define GLIBC_DYNAMIC_LINKER_DEFAULT GLIBC_DYNAMIC_LINKER_HARD_FLOAT
+#else
+#define GLIBC_DYNAMIC_LINKER_DEFAULT GLIBC_DYNAMIC_LINKER_SOFT_FLOAT
+#endif
+#define GLIBC_DYNAMIC_LINKER \
+ %{mfloat-abi=hard: GLIBC_DYNAMIC_LINKER_HARD_FLOAT } \
+%{mfloat-abi=soft*: GLIBC_DYNAMIC_LINKER_SOFT_FLOAT } \
+%{!mfloat-abi=*: GLIBC_DYNAMIC_LINKER_DEFAULT }
/* At this point, bpabi.h will have clobbered LINK_SPEC. We want to
use the GNU/Linux version, not the generic BPABI version. */
This patch is broken. Please fix this.
You can't use a named enumeration in cpp equality.
The type ARM_FLOAT_ABI_HARD is a named enumeration and evaluates to 0
as an unknown identifier.
Therefore #if TARGET_DEFAULT_FLOAT_ABI == ARM_FLOAT_ABI_HARD
evaluates to #if 0 == 0 and is always true.
Watch out that #define ARM_FLOAT_ABI_HARD ARM_FLOAT_ABI_HARD for
such enums is not conforming C99/C11.
I suggest you define the types as macros and then set the named enum
to those values, then use the macros in the header equality checks.
e.g.
#define VAL1 0 then enum FOO { RVAL1 = VAL1, ... }
Look at arm.h for the enum definition.
I've looked further into this and I think the original pre-#if version
is correct.
The float ABI comes from these places:
* The -mfloat-abi= command line argument, else
* The --with-float= configure time argument, else
* TARGET_DEFAULT_FLOAT_ABI from linux-eabi.h
In the first case the ABI is explicit. In the second
OPTION_DEFAULT_SPECS turns the configure time argument into an explict
-mfloat-abi=.
The patch below covers all cases, keeps the logic in the spec file,
and adds a comment linking the two #defines.
Tested by building with no configure flags, --wtih-float=softfp,
--with-float=hard, and then running with all combinations of
{,-mfloat-abi=softfp,-mfloat-abi=hard} {,-mglibc,-muclibc,-mbionic}.
OK?
-- Michael
2012-04-27 Michael Hopemichael.h...@linaro.org
* config/arm/linux-eabi.h (GLIBC_DYNAMIC_LINKER): Pick the loader
using a spec rule.
Michael,
can you try this patch please. It should make it possible to then
create linux-eabihf.h containing just
#undef TARGET_DEFAULT_FLOAT_ABI
#define TARGET_DEFAULT_FLOAT_ABI ARM_FLOAT_ABI_HARD
#undef GLIBC_DYNAMIC_LINKER_DEFAULT
#define GLIBC_DYNAMIC_LINKER_DEFAULT GLIBC_DYNAMIC_LINKER_HARD_FLOAT
Which is not quite as simple as leaving out the second re-define, but
pretty close.
Hi Richard. Your patch tests just fine. I like it. You could change
the spec rule to the newer if-elseif-else form but that's a nit.
-- Michael
Great, thanks! I've committed it as is.
I suggest to add this also to the gcc 4.7 branch. Richard (Earnshaw),
could you do take care of this, please?
This is a behaviour change. It would need RM approval for a release branch.
R.
Re: [PATCH v2] ARM: Use different linker path for hardfloat ABI
On Wednesday, May 23, 2012 09:56:31 Richard Earnshaw wrote:
[...]
This is a behaviour change. It would need RM approval for a release
branch.
R.
There was agreement by all pushing for the change to use it. So, let's ask
the release managers about their opinion,
Andreas
--
Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
Re: [PATCH v2] ARM: Use different linker path for hardfloat ABI
On Wed, 23 May 2012, Andreas Jaeger wrote: On Wednesday, May 23, 2012 09:56:31 Richard Earnshaw wrote: [...] This is a behaviour change. It would need RM approval for a release branch. R. There was agreement by all pushing for the change to use it. So, let's ask the release managers about their opinion, I'm ok with the change - but of course only to carry one less patch in our local tree. What do others think? It would definitely (anyway) need documenting in changes.html (for both 4.7.1 and 4.8). Richard.
Re: [PATCH 2/2] Better system header location detection for built-in macro tokens
Jason Merrill ja...@redhat.com writes:
What if the built-in macro appears in a macro defined in a system
header but used in user code? This would resolve the location all the
way to the user code, and warn. I think we only want to step out
until we reach a non-built-in macro, not all the way to the outermost
expansion point.
I think it's not that simple. If we simply do what you propose, then we
regress on a test like the below, distilled from
testsuite/c-c++-common/dfp/convert-int-saturate.c:
volatile unsigned int usi;
int
main ()
{
usi = DEC32_MAX; /* { dg-warning overflow in implicit constant
conversion } */
...
}
We fail to warn here because DEC32_MAX is defined in the system header
float.h to a built-in macro:
#define DEC32_MAX __DEC32_MAX__
I tried to do what the C FE seems to do, which is to consider that the
default location (the global input_location variable) is on the LHS of
the assignment (on the usi variable), rather than on the token that
comes from DEC32_MAX. But then it regresses notably on tests like
testsuite/g++.dg/warn/pr35635.C:
void func3()
{
unsigned char uchar_x;
...
uchar_x = bar != 0
? (unsigned char) 1024
: -1; /* { dg-warning negative integer implicitly converted to
unsigned type } */
}
It seems to me that ultimately, things like conversion routines that
emit diagnostics should know about the expression that represents the
context in which they are emitting the said diagnostic. In this
particular case, warnings_for_convert_and_check should know about the
assignment expression usi = DEC32_MAX, so that it can determine that
the whole expression is spelled in user code, and thus, the diagnostic
should be emitted. IOW, just knowing about the single token on which
the error occurs is not enough to decide.
But handling that seems like a huge task. So maybe we could, for now,
going for the solution that makes us regress the less, while improving
things nonetheless?
--
Dodji
Fix ipa-ref memory corruption
Hi,
the testcase bellow manages to corrupt IPA-REF reference lists.
The problem is that C++ FE creates new symtab node while another is in
construction
via DECL_ASSEMBLER_NAME hook.
Bootstrapped/regtested/comitted x86_64-linux.
Honza
Index: ChangeLog
===
--- ChangeLog (revision 187797)
+++ ChangeLog (working copy)
@@ -1,3 +1,8 @@
+2012-05-22 Jan Hubicka j...@suse.cz
+
+ PR middle-end/53161
+ * symtab.c (symtab_register_node): Fix ordering issue.
+
2012-05-22 Steven Drake s...@netbsd.org
* gcc.c (do_spec_1): Add %M spec token to output multilib_os_dir.
Index: testsuite/ChangeLog
===
--- testsuite/ChangeLog (revision 187797)
+++ testsuite/ChangeLog (working copy)
@@ -1,3 +1,8 @@
+2012-05-22 Jan Hubicka j...@suse.cz
+
+ PR middle-end/53161
+ * g++.dg/torture/pr53161.C: New testcase.
+
2012-05-22 Tobias Burnus bur...@net-b.de
PR fortran/53389
Index: testsuite/g++.dg/torture/pr53161.C
===
--- testsuite/g++.dg/torture/pr53161.C (revision 0)
+++ testsuite/g++.dg/torture/pr53161.C (revision 0)
@@ -0,0 +1,22 @@
+/* { dg-options -std=c++11 } */
+void gg();
+static __typeof(gg) __gthrw_gg __attribute__((__weakref__(gg)));
+
+templatetypename R,typename... A
+struct data {
+ templatetypename Y,typename X
+ data(Y y,R(X::*f)(A...));
+};
+
+templatetypename Y,typename X,typename R,typename... A
+dataR,A... make_data(Y y,R(X::*f)(A...)) {
+ return dataR,A...(y,f);
+}
+
+void global(datavoid);
+
+struct test {
+ void bar() {}
+ void doit() { global(make_data(*this,test::bar)); }
+};
+
Index: symtab.c
===
--- symtab.c(revision 187695)
+++ symtab.c(working copy)
@@ -177,11 +177,13 @@ symtab_register_node (symtab_node node)
if (*slot == NULL)
*slot = node;
- insert_to_assembler_name_hash (node);
+ ipa_empty_ref_list (node-symbol.ref_list);
node-symbol.order = symtab_order++;
- ipa_empty_ref_list (node-symbol.ref_list);
+ /* Be sure to do this last; C++ FE might create new nodes via
+ DECL_ASSEMBLER_NAME langhook! */
+ insert_to_assembler_name_hash (node);
}
/* Make NODE to be the one symtab hash is pointing to. Used when reshaping
tree
[PR49888, VTA] don't keep VALUEs bound to modified MEMs
Nothing in var-tracking was prepared to drop MEMs from bindings upon
writes that might modify the MEM contents. That was correct, back when
it was variables (rather than values) that were bound to MEMs, and we
wanted the binding to remain even if the value stored in the variables
changed.
VTA changed that for gimple regs: we now bind variables to values, and
values to locations that hold that value, so we must unbind them when
the value stored in the MEM location changes, just like we already did
for REGs.
cselib might offer us some help to that end, but only within individual
basic blocks. That's not quite enough: even a trivial testcase, as
provided in the bug report, was enough to defeat the first approach I
tried, of emitting MOps to unbind values from MEMs when cselib noticed
the MEM was modified. Even in that trivial testcase, we wouldn't always
unbind the incoming argument from the MEM, because it would be recorded
using a different expression which we could only globally recognize as
equivalent. And that didn't even take potential aliasing into account!
In order to fix this debug info correctness bug, I ended up going with
the following approach: after every MEM write, we go through all MEMs in
the dataflow set binding table and unbind VALUEs bound to
possibly-aliased MEMs. I'm sure there are cases in which this may
remove perfectly valid location information, but getting the compiler to
figure out they are indeed valid is impossible in some cases (eg
incoming pointers known by the caller to not alias), and very, very
expensive in others (eg inferring the lack of overlap by following
equivalence chains).
In the end, this patch didn't cause much loss of debug information on
x86_64, but it does significantly reduce total coverage on i686 for
libstdc++, libgcc and cc1plus. There was a also a significant drop in
call_site_value and entry_value expressions, on both x86_64 and i686,
slightly more pronounced on the latter. Unfortunately, I couldn't
quantify how much of this reduction was because we of incorrect location
information we generated before, and how much is because of
overconservative decisions about potential aliasing.
This was all kind of expected. What did surprise me was that this
didn't have any measurable impact on bootstrap time. What surprised me
further was that testing this patch confirmed the boostrap speedup of
1.08 I had observed with the proposed patch for PR47624, that this patch
depends on.
This patch was regstrapped along with the patch for PR47624 (ping
http://gcc.gnu.org/ml/gcc-patches/2012-04/msg01320.html) on
x86_64-linux-gnu and i686-linux-gnu. Ok to install?
for gcc/ChangeLog
from Alexandre Oliva aol...@redhat.com
PR debug/49888
* var-tracking.c: Include alias.h.
(overlapping_mems): New struct.
(drop_overlapping_mem_locs): New.
(clobber_overlapping_mems): New.
(var_mem_delete_and_set, var_mem_delete): Call it.
(val_bind): Likewise, but only if modified.
(compute_bb_dataflow, emit_notes_in_bb): Call it on MEMs.
* Makefile.in (var-tracking.o): Depend in $(ALIAS_H).
for gcc/testsuite/ChangeLog
from Alexandre Oliva aol...@redhat.com
PR debug/49888
* gcc.dg/guality/pr49888.c: New.
Index: gcc/var-tracking.c
===
--- gcc/var-tracking.c.orig 2012-05-16 14:58:11.0 -0300
+++ gcc/var-tracking.c 2012-05-21 02:24:57.0 -0300
@@ -116,6 +116,7 @@
#include pointer-set.h
#include recog.h
#include tm_p.h
+#include alias.h
/* var-tracking.c assumes that tree code with the same value as VALUE rtx code
has no chance to appear in REG_EXPR/MEM_EXPRs and isn't a decl.
@@ -1955,6 +1956,106 @@ var_regno_delete (dataflow_set *set, int
*reg = NULL;
}
+/* Hold parameters for the hashtab traversal function
+ drop_overlapping_mem_locs, see below. */
+
+struct overlapping_mems
+{
+ dataflow_set *set;
+ rtx loc;
+};
+
+/* Remove all MEMs that overlap with COMS-LOC from the location list
+ of a hash table entry for a value. */
+
+static int
+drop_overlapping_mem_locs (void **slot, void *data)
+{
+ struct overlapping_mems *coms = (struct overlapping_mems *)data;
+ dataflow_set *set = coms-set;
+ rtx mloc = coms-loc;
+ variable var = (variable) *slot;
+
+ if (var-onepart == ONEPART_VALUE)
+{
+ location_chain loc, *locp;
+ bool changed = false;
+ rtx cur_loc;
+
+ gcc_assert (var-n_var_parts == 1);
+
+ if (shared_var_p (var, set-vars))
+ {
+ for (loc = var-var_part[0].loc_chain; loc; loc = loc-next)
+ if (GET_CODE (loc-loc) == MEM
+ !nonoverlapping_memrefs_p (loc-loc, mloc, false))
+ break;
+
+ if (!loc)
+ return 1;
+
+ slot = unshare_variable (set, slot, var, VAR_INIT_STATUS_UNKNOWN);
+ var = (variable)*slot;
+ gcc_assert (var-n_var_parts == 1);
+ }
+
+ if (VAR_LOC_1PAUX (var))
+ cur_loc = VAR_LOC_FROM (var);
+ else
+ cur_loc = var-var_part[0].cur_loc;
+
+ for (locp = var-var_part[0].loc_chain,
[libgo] Fix IRIX bootstrap failure
The current 4.7 branch fails to build on IRIX 6.5:
/vol/gcc/src/hg/gcc-4.7-branch/local/libgo/runtime/go-caller.c:51:1: error:
conflicting types for '__go_file_line'
In file included from
/vol/gcc/src/hg/gcc-4.7-branch/local/libgo/runtime/go-caller.c:11:0:
/vol/gcc/src/hg/gcc-4.7-branch/local/libgo/runtime/runtime.h:481:14: note:
previous declaration of '__go_file_line' was here
The following patch fixes the inconsistency between runtime.h and
go-caller.c and lets the bootstrap finish. Testsuite results are still
terrible since many tests timeout (with timeout doubled to 600s to
account for the slow 250 MHz MIPS R10k CPUs on my test machine), and
others not even hitting the timeout at all:
PID USERNAME PRI NICE SIZE RES STATE TIME WCPUCPU COMMAND
35782082 ro 200 784M 3696K ready 357:50 29.59% 59.18% goprint.ex
33666480 ro 200 784M 5568K ready 437:14 29.56% 59.11% select5.ex
35957493 ro 200 784M 5264K run/2 206:40 29.43% 58.86% 64bit.exe
35654428 ro 200 784M 5072K ready 432:59 29.41% 58.82% index.exe
They all seem to loop in a SIGSEGV handling loop.
Rainer
diff --git a/libgo/runtime/go-caller.c b/libgo/runtime/go-caller.c
--- a/libgo/runtime/go-caller.c
+++ b/libgo/runtime/go-caller.c
@@ -48,7 +48,7 @@ RegisterDebugLookup (infofn_type pi, sym
/* Return function/file/line information for PC. */
_Bool
-__go_file_line (uintptr_t pc, struct __go_string *fn, struct __go_string *file,
+__go_file_line (uintptr pc, struct __go_string *fn, struct __go_string *file,
int *line)
{
if (infofn == NULL)
--
-
Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [PR49888, VTA] don't keep VALUEs bound to modified MEMs
On Wed, May 23, 2012 at 12:13 PM, Jakub Jelinek ja...@redhat.com wrote:
On Wed, May 23, 2012 at 06:27:21AM -0300, Alexandre Oliva wrote:
+static int
+drop_overlapping_mem_locs (void **slot, void *data)
+{
+ struct overlapping_mems *coms = (struct overlapping_mems *)data;
+ dataflow_set *set = coms-set;
+ rtx mloc = coms-loc;
+ variable var = (variable) *slot;
+
+ if (var-onepart == ONEPART_VALUE)
+ {
+ location_chain loc, *locp;
+ bool changed = false;
+ rtx cur_loc;
+
+ gcc_assert (var-n_var_parts == 1);
+
+ if (shared_var_p (var, set-vars))
+ {
+ for (loc = var-var_part[0].loc_chain; loc; loc = loc-next)
+ if (GET_CODE (loc-loc) == MEM
+ !nonoverlapping_memrefs_p (loc-loc, mloc, false))
Isn't nonoverlapping_memrefs_p predicate too conservative?
cselib.c uses canon_true_dependence to decide what should be invalidated.
Yeah, I think nonoverlapping_memrefs_p should become private to alias.c
Richard.
Jakub
Re: [C++ Patch] PR 29185
On 05/23/2012 04:54 AM, Gabriel Dos Reis wrote: On Tue, May 22, 2012 at 8:25 PM, Paolo Carlinipaolo.carl...@oracle.com wrote: Hi, some years ago Martin lamented that we weren't consistently warning about deleting member arrays vs arrays. A fix seems simple and passes bootstrap and testing on x86_64-linux. Note I have to change D to E because dump_decl cannot cope with COMPONENT_REFs. dump_decl can't handle COMPONENT_REF because it is an expression. I suspect you want to look at the operand 1 instead of changing D to E. Gaby, at some point I did that, but then it didn't work with the third case. In general, I understand that this is an expression and I would rather rely on dump_expr, which has logic to unwrap all the various possibilities. This, indeed, as long as we print expressions at all. For the time being, If you like I can test DECL_P and use either D or E. Just let me know. Thanks, Paolo.
Re: [C++ Patch] PR 44516
On 05/23/2012 06:30 AM, Jason Merrill wrote: On 05/22/2012 05:18 PM, Paolo Carlini wrote: Uhhm, I have an out of the blue idea, so please excuse me if for some obvious reason doesn't make sense: don't we have a global variable saying where we are in the compiler pipeline? I'm not sure, but the question led me to thinking about only asserting if input_location != UNKNOWN_LOCATION. Would that work? Ah, that would be a nice implementation of my vague idea! Thus, what I'm going to test, in warning_at co is something like: gcc_assert (input_location == UNKNOWN_LOCATION || location != UNKNOWN_LOCATION); Paolo.
Re: [C++ Patch] PR 29185
On 05/23/2012 06:34 AM, Jason Merrill wrote:
On 05/22/2012 09:25 PM, Paolo Carlini wrote:
some years ago Martin lamented that we weren't consistently warning
about deleting member arrays vs arrays.
I wonder why we look at the code of exp at all. Surely deleting any
expression with array type is questionable.
Indeed. The below, as-is, bootstraps and tests fine.
I wondered whether adding a check that TREE_TYPE is non null could
provide a tad of additional robustness, but noticed that the next
build_expr_type_conversion just uses MAYBE_CLASS_TYPE_P on it.
Thanks!
Paolo.
/
Index: testsuite/g++.dg/warn/delete-array-1.C
===
--- testsuite/g++.dg/warn/delete-array-1.C (revision 0)
+++ testsuite/g++.dg/warn/delete-array-1.C (revision 0)
@@ -0,0 +1,11 @@
+// PR c++/29185
+
+int a [1];
+struct S { int a [1]; } s;
+
+void foo (S *p)
+{
+ delete a;// { dg-warning deleting array }
+ delete s.a; // { dg-warning deleting array }
+ delete p-a; // { dg-warning deleting array }
+}
Index: cp/decl2.c
===
--- cp/decl2.c (revision 187799)
+++ cp/decl2.c (working copy)
@@ -438,9 +438,8 @@ delete_sanity (tree exp, tree size, bool doing_vec
}
/* An array can't have been allocated by new, so complain. */
- if (TREE_CODE (exp) == VAR_DECL
- TREE_CODE (TREE_TYPE (exp)) == ARRAY_TYPE)
-warning (0, deleting array %q#D, exp);
+ if (TREE_CODE (TREE_TYPE (exp)) == ARRAY_TYPE)
+warning (0, deleting array %q#E, exp);
t = build_expr_type_conversion (WANT_POINTER, exp, true);
[PATCH] Fix memory leak in inline_merge_summary
Hi, the vector operand_map is not freed in inline_merge_summary, this patch fixes it. It looks fairly obvious and I also have talked about the problem on IRC with Honza yesterday so I will commit it after bootstrap and testing on x86_64-linux. I suppose I should then test and commit it to the 4.7 branch...? Thanks, Martin 2012-05-23 Martin Jambor mjam...@suse.cz * ipa-inline-analysis.c (inline_merge_summary): Free operand_map. Index: src/gcc/ipa-inline-analysis.c === --- src.orig/gcc/ipa-inline-analysis.c +++ src/gcc/ipa-inline-analysis.c @@ -2696,6 +2696,7 @@ inline_merge_summary (struct cgraph_edge edge_set_predicate (edge, true_p); /* Similarly remove param summaries. */ VEC_free (inline_param_summary_t, heap, es-param); + VEC_free (int, heap, operand_map); info-time = (info-time + INLINE_TIME_SCALE / 2) / INLINE_TIME_SCALE; info-size = (info-size + INLINE_SIZE_SCALE / 2) / INLINE_SIZE_SCALE;
Re: [PATCH] Fix memory leak in inline_merge_summary
On Wed, May 23, 2012 at 1:02 PM, Martin Jambor mjam...@suse.cz wrote: Hi, the vector operand_map is not freed in inline_merge_summary, this patch fixes it. It looks fairly obvious and I also have talked about the problem on IRC with Honza yesterday so I will commit it after bootstrap and testing on x86_64-linux. I suppose I should then test and commit it to the 4.7 branch...? Yes. Thanks, Richard. Thanks, Martin 2012-05-23 Martin Jambor mjam...@suse.cz * ipa-inline-analysis.c (inline_merge_summary): Free operand_map. Index: src/gcc/ipa-inline-analysis.c === --- src.orig/gcc/ipa-inline-analysis.c +++ src/gcc/ipa-inline-analysis.c @@ -2696,6 +2696,7 @@ inline_merge_summary (struct cgraph_edge edge_set_predicate (edge, true_p); /* Similarly remove param summaries. */ VEC_free (inline_param_summary_t, heap, es-param); + VEC_free (int, heap, operand_map); info-time = (info-time + INLINE_TIME_SCALE / 2) / INLINE_TIME_SCALE; info-size = (info-size + INLINE_SIZE_SCALE / 2) / INLINE_SIZE_SCALE;
Re: [PATCH] Hoist adjacent pointer loads
On Tue, 22 May 2012, William J. Schmidt wrote:
Here's a revision of the hoist-adjacent-loads patch. Besides hopefully
addressing all your comments, I added a gate of at least -O2 for this
transformation. Let me know if you prefer a different minimum opt
level.
I'm still running SPEC tests to make sure there are no regressions when
opening this up to non-pointer arguments. The code bootstraps on
powerpc64-unknown-linux-gnu with no regressions. Assuming the SPEC
numbers come out as expected, is this ok?
Thanks,
Bill
2012-05-22 Bill Schmidt wschm...@linux.vnet.ibm.com
* tree-ssa-phiopt.c (tree_ssa_phiopt_worker): Add argument to forward
declaration.
(hoist_adjacent_loads, gate_hoist_loads): New forward declarations.
(tree_ssa_phiopt): Call gate_hoist_loads.
(tree_ssa_cs_elim): Add parm to tree_ssa_phiopt_worker call.
(tree_ssa_phiopt_worker): Add do_hoist_loads to formal arg list; call
hoist_adjacent_loads.
(local_mem_dependence): New function.
(hoist_adjacent_loads): Likewise.
(gate_hoist_loads): Likewise.
* common.opt (fhoist-adjacent-loads): New switch.
* Makefile.in (tree-ssa-phiopt.o): Added dependencies.
* params.def (PARAM_MIN_CMOVE_STRUCT_ALIGN): New param.
Index: gcc/tree-ssa-phiopt.c
===
--- gcc/tree-ssa-phiopt.c (revision 187728)
+++ gcc/tree-ssa-phiopt.c (working copy)
@@ -37,9 +37,17 @@ along with GCC; see the file COPYING3. If not see
#include cfgloop.h
#include tree-data-ref.h
#include tree-pretty-print.h
+#include gimple-pretty-print.h
+#include insn-config.h
+#include expr.h
+#include optabs.h
+#ifndef HAVE_conditional_move
+#define HAVE_conditional_move (0)
+#endif
+
static unsigned int tree_ssa_phiopt (void);
-static unsigned int tree_ssa_phiopt_worker (bool);
+static unsigned int tree_ssa_phiopt_worker (bool, bool);
static bool conditional_replacement (basic_block, basic_block,
edge, edge, gimple, tree, tree);
static int value_replacement (basic_block, basic_block,
@@ -53,6 +61,9 @@ static bool cond_store_replacement (basic_block, b
static bool cond_if_else_store_replacement (basic_block, basic_block,
basic_block);
static struct pointer_set_t * get_non_trapping (void);
static void replace_phi_edge_with_variable (basic_block, edge, gimple, tree);
+static void hoist_adjacent_loads (basic_block, basic_block,
+ basic_block, basic_block);
+static bool gate_hoist_loads (void);
/* This pass tries to replaces an if-then-else block with an
assignment. We have four kinds of transformations. Some of these
@@ -138,12 +149,56 @@ static void replace_phi_edge_with_variable (basic_
bb2:
x = PHI x' (bb0), ...;
- A similar transformation is done for MAX_EXPR. */
+ A similar transformation is done for MAX_EXPR.
+
+ This pass also performs a fifth transformation of a slightly different
+ flavor.
+
+ Adjacent Load Hoisting
+ --
+
+ This transformation replaces
+
+ bb0:
+ if (...) goto bb2; else goto bb1;
+ bb1:
+ x1 = (expr).field1;
+ goto bb3;
+ bb2:
+ x2 = (expr).field2;
+ bb3:
+ # x = PHI x1, x2;
+
+ with
+
+ bb0:
+ x1 = (expr).field1;
+ x2 = (expr).field2;
+ if (...) goto bb2; else goto bb1;
+ bb1:
+ goto bb3;
+ bb2:
+ bb3:
+ # x = PHI x1, x2;
+
+ The purpose of this transformation is to enable generation of conditional
+ move instructions such as Intel CMOVE or PowerPC ISEL. Because one of
+ the loads is speculative, the transformation is restricted to very
+ specific cases to avoid introducing a page fault. We are looking for
+ the common idiom:
+
+ if (...)
+ x = y-left;
+ else
+ x = y-right;
+
+ where left and right are typically adjacent pointers in a tree structure.
*/
+
static unsigned int
tree_ssa_phiopt (void)
{
- return tree_ssa_phiopt_worker (false);
+ return tree_ssa_phiopt_worker (false, gate_hoist_loads ());
}
/* This pass tries to transform conditional stores into unconditional
@@ -190,7 +245,7 @@ tree_ssa_phiopt (void)
static unsigned int
tree_ssa_cs_elim (void)
{
- return tree_ssa_phiopt_worker (true);
+ return tree_ssa_phiopt_worker (true, false);
}
/* Return the singleton PHI in the SEQ of PHIs for edges E0 and E1. */
@@ -227,9 +282,11 @@ static tree condstoretemp;
/* The core routine of conditional store replacement and normal
phi optimizations. Both share much of the infrastructure in how
to match applicable basic block patterns. DO_STORE_ELIM is true
- when we want to do conditional store replacement, false otherwise. */
+ when we want to do conditional store replacement, false
Re: [C++ Patch] PR 44516
On 05/23/2012 12:30 PM, Paolo Carlini wrote: On 05/23/2012 06:30 AM, Jason Merrill wrote: On 05/22/2012 05:18 PM, Paolo Carlini wrote: Uhhm, I have an out of the blue idea, so please excuse me if for some obvious reason doesn't make sense: don't we have a global variable saying where we are in the compiler pipeline? I'm not sure, but the question led me to thinking about only asserting if input_location != UNKNOWN_LOCATION. Would that work? Ah, that would be a nice implementation of my vague idea! Thus, what I'm going to test, in warning_at co is something like: gcc_assert (input_location == UNKNOWN_LOCATION || location != UNKNOWN_LOCATION); Not precise enough :( Tests like gcc.dg/pr28322-2.c show that we may emit such line #0 warnings when input_location is already != UNKNOWN_LOCATION. I'm afraid that for the next location changes in the C++ front-end I will resort to apply the temporarily apply the checks when regression testing the front-end. Paolo.
[PATCH][4/n] referenced-vars TLC
This finally switches us to not record global vars in referenced-vars.
For this to work I had to re-engineer how we handle global var removal
from local-decls in remove_unused_locals. Incidentially that code
already had some sort of a bitmap (for some weird reason even), thus
I borrowed that and simplified the handling. You may notice that
it would be easy to handle all vars that way ...
So eventually 5/n will make referenced-vars go away completely
(the only serious user seems to be the SSA renamer for its
SYMS_TO_RENAME bitmap).
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
Richard.
2012-05-23 Richard Guenther rguent...@suse.de
* tree-dfa.c (add_referenced_var_1): Do not add global vars.
* tree-ssa-live.c (mark_all_vars_used_1): Handle global vars
via the global_unused_vars bitmap.
(remove_unused_locals): Handle global vars in local-decls via
a global_unused_vars bitmap instead of the used flag in the
var annotation. Simplify global variable handling and removal.
* gcc.dg/torture/pr39074-2.c: Adjust.
* gcc.dg/torture/pr39074.c: Likewise.
* gcc.dg/torture/pta-structcopy-1.c: Likewise.
* gcc.dg/tree-ssa/alias-19.c: Likewise.
Index: gcc/tree-dfa.c
===
*** gcc/tree-dfa.c.orig 2012-05-22 14:50:50.0 +0200
--- gcc/tree-dfa.c 2012-05-22 15:26:37.868506459 +0200
*** add_referenced_var_1 (tree var, struct f
*** 581,586
--- 581,591
|| TREE_CODE (var) == PARM_DECL
|| TREE_CODE (var) == RESULT_DECL);
+ if (!(TREE_CODE (var) == VAR_DECL
+VAR_DECL_IS_VIRTUAL_OPERAND (var))
+is_global_var (var))
+ return false;
+
if (!*DECL_VAR_ANN_PTR (var))
create_var_ann (var);
Index: gcc/testsuite/gcc.dg/torture/pr39074-2.c
===
*** gcc/testsuite/gcc.dg/torture/pr39074-2.c.orig 2011-12-06
10:39:54.0 +0100
--- gcc/testsuite/gcc.dg/torture/pr39074-2.c2012-05-22 15:42:43.068473038
+0200
*** int main()
*** 30,34
return 0;
}
! /* { dg-final { scan-tree-dump y.._., points-to vars: { i } alias } } */
/* { dg-final { cleanup-tree-dump alias } } */
--- 30,35
return 0;
}
! /* { dg-final { scan-tree-dump y.._. = { i } alias } } */
! /* { dg-final { scan-tree-dump y.._., points-to vars: { D. } alias }
} */
/* { dg-final { cleanup-tree-dump alias } } */
Index: gcc/testsuite/gcc.dg/torture/pr39074.c
===
*** gcc/testsuite/gcc.dg/torture/pr39074.c.orig 2012-04-12 11:32:07.0
+0200
--- gcc/testsuite/gcc.dg/torture/pr39074.c 2012-05-22 15:43:07.770472209
+0200
*** int main()
*** 29,33
return 0;
}
! /* { dg-final { scan-tree-dump y.._., points-to vars: { i } alias } } */
/* { dg-final { cleanup-tree-dump alias } } */
--- 29,34
return 0;
}
! /* { dg-final { scan-tree-dump y.._. = { i } alias } } */
! /* { dg-final { scan-tree-dump y.._., points-to vars: { D. } alias }
} */
/* { dg-final { cleanup-tree-dump alias } } */
Index: gcc/testsuite/gcc.dg/torture/pta-structcopy-1.c
===
*** gcc/testsuite/gcc.dg/torture/pta-structcopy-1.c.orig2011-06-21
13:06:08.0 +0200
--- gcc/testsuite/gcc.dg/torture/pta-structcopy-1.c 2012-05-22
15:42:19.922473852 +0200
*** int main()
*** 31,35
return 0;
}
! /* { dg-final { scan-tree-dump points-to vars: { i } ealias } } */
/* { dg-final { cleanup-tree-dump ealias } } */
--- 31,36
return 0;
}
! /* { dg-final { scan-tree-dump y.* = { i } ealias } } */
! /* { dg-final { scan-tree-dump y.*, points-to vars: { D. } ealias } }
*/
/* { dg-final { cleanup-tree-dump ealias } } */
Index: gcc/testsuite/gcc.dg/tree-ssa/alias-19.c
===
*** gcc/testsuite/gcc.dg/tree-ssa/alias-19.c.orig 2009-04-03
12:56:17.0 +0200
--- gcc/testsuite/gcc.dg/tree-ssa/alias-19.c2012-05-22 15:39:53.318478953
+0200
*** int main()
*** 26,30
}
/* { dg-final { scan-tree-dump q_. = { a b } alias } } */
! /* { dg-final { scan-tree-dump q_., points-to vars: { a b } alias } } */
/* { dg-final { cleanup-tree-dump alias } } */
--- 26,30
}
/* { dg-final { scan-tree-dump q_. = { a b } alias } } */
! /* { dg-final { scan-tree-dump q_., points-to vars: { D. b } alias }
} */
/* { dg-final { cleanup-tree-dump alias } } */
Index: gcc/tree-ssa-live.c
===
*** gcc/tree-ssa-live.c (revision 187771)
--- gcc/tree-ssa-live.c (working copy)
*** static inline void mark_all_vars_used (t
*** 348,353
---
Re: [PATCH, 4.6] Fix PR53170: missing target c++11 selector
On 05/23/2012 05:39 AM, Michael Hope wrote:
On 21/05/12 21:14, Paolo Carlini wrote:
On 05/21/2012 01:45 AM, Michael Hope wrote:
The testsuite for PR52796 uses the 'target c++11' selector which
doesn't exist in 4.6.
This patch backports the selector, clearing the 'ERROR:
g++.dg/cpp0x/variadic-value1.C:
syntax error in target selector target c++11 for dg-do 2 run {
target c++11 } '
errors which have appeared in recent 4.6 builds.
Tested on x86_64-linux-gnu with no regressions. Changes the ERROR to
UNSUPPORTED.
OK for 4.6?
To be honest, when I saw the issue I thought we wanted simply to not
use the target selector at all in the branch and simply add a // {
dg-options -std=c++11 } I thought somebody would commit the change
as obvious ;)
Sure. The version below changes the selector for explicit flags that
match those passed by trunk.
OK for 4.6?
-- Michael (who's not keen enough to commit as obvious)
I would say let's go ahead ;) But in the ChangeLog entry please use PR
c++/52796.
Paolo.
Paolo.
Re: [C++ Patch] PR 29185
OK. We shouldn't need to worry about null type, since templates are handled at the top of the function. Jason
Re: [C++ Patch] PR 29185
On Wed, May 23, 2012 at 5:24 AM, Paolo Carlini paolo.carl...@oracle.com wrote: On 05/23/2012 04:54 AM, Gabriel Dos Reis wrote: On Tue, May 22, 2012 at 8:25 PM, Paolo Carlinipaolo.carl...@oracle.com wrote: Hi, some years ago Martin lamented that we weren't consistently warning about deleting member arrays vs arrays. A fix seems simple and passes bootstrap and testing on x86_64-linux. Note I have to change D to E because dump_decl cannot cope with COMPONENT_REFs. dump_decl can't handle COMPONENT_REF because it is an expression. I suspect you want to look at the operand 1 instead of changing D to E. Gaby, at some point I did that, but then it didn't work with the third case. In general, I understand that this is an expression and I would rather rely on dump_expr, which has logic to unwrap all the various possibilities. This, indeed, as long as we print expressions at all. For the time being, If you like I can test DECL_P and use either D or E. Just let me know. With Jason's suggestion of testing for just any expression of array type, it makes sense to change D to E. -- Gaby
Re: [PATCH v2] ARM: Use different linker path for hardfloat ABI
On Wednesday 23 May 2012 04:17:51 Richard Guenther wrote: On Wed, 23 May 2012, Andreas Jaeger wrote: On Wednesday, May 23, 2012 09:56:31 Richard Earnshaw wrote: [...] This is a behaviour change. It would need RM approval for a release branch. R. There was agreement by all pushing for the change to use it. So, let's ask the release managers about their opinion, I'm ok with the change - but of course only to carry one less patch in our local tree. What do others think? It would definitely (anyway) need documenting in changes.html (for both 4.7.1 and 4.8). i've done this for Gentoo and 4.5.0+, so if all the distros are going to be doing this in 4.7.x anyways, makes sense to me to do it in the official branch. -mike signature.asc Description: This is a digitally signed message part.
Re: [PATCH][4/n] referenced-vars TLC
On Wed, May 23, 2012 at 5:00 AM, Richard Guenther rguent...@suse.de wrote: This finally switches us to not record global vars in referenced-vars. For this to work I had to re-engineer how we handle global var removal from local-decls in remove_unused_locals. Incidentially that code already had some sort of a bitmap (for some weird reason even), thus I borrowed that and simplified the handling. You may notice that it would be easy to handle all vars that way ... So eventually 5/n will make referenced-vars go away completely (the only serious user seems to be the SSA renamer for its SYMS_TO_RENAME bitmap). Bootstrapped on x86_64-unknown-linux-gnu, testing in progress. Richard. 2012-05-23 Richard Guenther rguent...@suse.de * tree-dfa.c (add_referenced_var_1): Do not add global vars. * tree-ssa-live.c (mark_all_vars_used_1): Handle global vars via the global_unused_vars bitmap. (remove_unused_locals): Handle global vars in local-decls via a global_unused_vars bitmap instead of the used flag in the var annotation. Simplify global variable handling and removal. This breaks bootstrap on Linux/x86-64: http://gcc.gnu.org/ml/gcc-regression/2012-05/msg00468.html Comparing stages 2 and 3 warning: gcc/cc1plus-checksum.o differs warning: gcc/cc1obj-checksum.o differs warning: gcc/cc1-checksum.o differs Bootstrap comparison failure! gcc/trans-mem.o differs gcc/gimple-low.o differs gcc/sese.o differs make[5]: *** [compare] Error 1 Please make sure that your compiler used for bootstrap doesn't add anything to .comment section, which will disable debug compare. Thanks. -- H.J.
[Patch, fortran] PR 53456 Improve time resolution on targets without gettimeofday
Hi, some targets such as VXWorks don't provide gettimeofday but do provide clock_gettime. The attached patch allows such targets to get better resolution for the DATE_AND_TIME (up to the 1 millisecond limit of the API) intrinsic than the 1 second resolution provided by the current fallback of using the C standard time(). (SYSTEM_CLOCK already uses clock_gettime if available and thus nanosecond resultion has been available to vxworks also before this patch.) Ok for trunk? (Patch both inline below and as an attachment) 2012-05-23 Janne Blomqvist j...@gcc.gnu.org PR fortran/53456 * intrinsics/time_1.h (gf_gettime): Fallback for clock_gettime. diff --git a/libgfortran/intrinsics/time_1.h b/libgfortran/intrinsics/time_1.h index aaca56a..ca5b26b 100644 --- a/libgfortran/intrinsics/time_1.h +++ b/libgfortran/intrinsics/time_1.h @@ -181,8 +181,8 @@ gf_cputime (long *user_sec, long *user_usec, long *system_sec, long *system_usec #endif -/* Realtime clock with microsecond resolution, falling back to less - precise functions if the target does not support gettimeofday(). +/* Realtime clock with microsecond resolution, falling back to other + functions if the target does not support gettimeofday(). Arguments: secs - OUTPUT, seconds @@ -204,6 +204,12 @@ gf_gettime (time_t * secs, long * usecs) *secs = tv.tv_sec; *usecs = tv.tv_usec; return err; +#elif defined(HAVE_CLOCK_GETTIME) + struct timespec ts; + int err = clock_gettime (CLOCK_REALTIME, ts); + *secs = ts.tv_sec; + *usecs = ts.tv_nsec / 1000; + return err; #else time_t t = time (NULL); *secs = t; -- Janne Blomqvist vxtime.diff Description: Binary data
[Patch,AVR]: Fix PR53448: ignored aligned(2)
Sometimes, even on AVR there is the need to align data.
However, alignments of 2 are ignored at the moment because of
#define ASM_OUTPUT_ALIGN(STREAM, POWER) \
do { \
if ((POWER) 1)\
fprintf (STREAM, \t.p2align\t%d\n, POWER); \
} while (0)
The fix is to use POWER 0 instead.
Maybe someone knows why the restriction to POWER = 2 is
there at all?
Ok to install?
Johann
PR target/53448
* config/avr/avr.h (ASM_OUTPUT_ALIGN): Don't inhibit .p2align 1.
* config/avr/elf.h (ASM_OUTPUT_BEFORE_CASE_LABEL): Use
ASM_OUTPUT_ALIGN.
Index: config/avr/elf.h
===
--- config/avr/elf.h (revision 187704)
+++ config/avr/elf.h (working copy)
@@ -35,7 +35,7 @@
/* Output alignment 2**1 for jump tables. */
#undef ASM_OUTPUT_BEFORE_CASE_LABEL
#define ASM_OUTPUT_BEFORE_CASE_LABEL(FILE, PREFIX, NUM, TABLE) \
- fprintf (FILE, \t.p2align\t1\n);
+ ASM_OUTPUT_ALIGN (FILE, 1);
/* Be conservative in crtstuff.c. */
#undef INIT_SECTION_ASM_OP
Index: config/avr/avr.h
===
--- config/avr/avr.h (revision 187704)
+++ config/avr/avr.h (working copy)
@@ -557,10 +557,10 @@ typedef struct avr_args {
#define ASM_OUTPUT_ADDR_VEC_ELT(STREAM, VALUE) \
avr_output_addr_vec_elt(STREAM, VALUE)
-#define ASM_OUTPUT_ALIGN(STREAM, POWER) \
- do { \
- if ((POWER) 1) \
- fprintf (STREAM, \t.p2align\t%d\n, POWER); \
+#define ASM_OUTPUT_ALIGN(STREAM, POWER) \
+ do { \
+if ((POWER) 0)\
+ fprintf (STREAM, \t.p2align\t%d\n, POWER); \
} while (0)
#define CASE_VECTOR_MODE HImode
Re: [Patch,AVR]: Fix PR53448: ignored aligned(2)
2012/5/23 Georg-Johann Lay a...@gjlay.de:
Sometimes, even on AVR there is the need to align data.
However, alignments of 2 are ignored at the moment because of
#define ASM_OUTPUT_ALIGN(STREAM, POWER) \
do { \
if ((POWER) 1) \
fprintf (STREAM, \t.p2align\t%d\n, POWER); \
} while (0)
The fix is to use POWER 0 instead.
Maybe someone knows why the restriction to POWER = 2 is
there at all?
Ok to install?
Johann
PR target/53448
* config/avr/avr.h (ASM_OUTPUT_ALIGN): Don't inhibit .p2align 1.
* config/avr/elf.h (ASM_OUTPUT_BEFORE_CASE_LABEL): Use
ASM_OUTPUT_ALIGN.
Approved.
Denis.
Re: [RFA] PowerPC e5500 and e6500 cores support
David, Michael, Thanks for the feedback. If you don't object, I will relay the message to the designers. Meanwhile I have to work with the cards I have, so... I will break the patch in three parts: - One that includes the very basic, scheduling etc. - One for the Altivec builtins, which I will hold until we have a formal ISA-2.07 document, and we are sure there is no conflict with the patch. - The rest that will be kept by Freescale. Thanks, Edmar On 05/21/2012 02:51 PM, David Edelsohn wrote: Regarding the implementation of popcntb, popcntd, and cmpb. Gcc has dedicated masks on target_flags for them, but due to shortage of bits, those masks controls more than the name implies. The target flag bits control more than the name implies, but the bits correspond to published ISA levels. The Freescale localized parts of the patch (new scheduling descriptions) are okay, modulo Mike's comments. We also need to coordinate on which instructions really are part of Altivec2 and what name will be used for that feature. However, what concerns me, as Mike commented as well, is this patch adds support for a processor that does not conform to any particular ISA -- it does not implement some instructions and adds other unique instructions. Unlike the SPE instructions, these are not completely orthogonal from the rest of the PowerPC architecture. SPE added a separate set of SIMD instructions and merged the GPR and FPR register sets, but left most other things alone. The earlier addition of E500 support was a mess because the concept of architecture and processor were not clearly defined and delineated. This has been a maintenance nightmare for all other PowerPC maintainers dealing with the irregularities introduced for Freescale's non-conforming processor, especially when additional features were added in the next processor. At least the previous irregularities were local to Freescale's ISA extensions. This latest processor modifies the meaning of the ISA definitions. Changing macros that designate architectures to test for specific processors is reverting to an approach of bad software design. If the Freescale parts only has complete support for an earlier ISA, that is the one it needs to use. If it implements more Altivec2 instructions than defined, users can access those with inlined assembly. Freescale can distribute compilers with whatever additional patches it wants to include, but the cost-benefit ratio to the rest of the PowerPC community and the rest of the GCC community is past unreasonable. In other words, this new processor and the latest patches mean that a Linux distributor cannot build an application for a particular revision of the ISA and have it work across both IBM and Freescale processors. That is not the meaning of ISA and is going to confuse users, developers and distros. The Freescale parts need to present themselves as the lowest-common denominator of the processor ISA they supports. Thanks, David On Fri, May 18, 2012 at 3:16 PM, Edmared...@freescale.com wrote: Michael, Thanks for reviewing the patch and all the suggestions. I have some questions / comments bellow. Regards, Edmar On 05/17/2012 06:16 PM, Michael Meissner wrote: In the patch I minimized the number of changes, while not adding any new mask to target_flags. While we may get some bits back when the original Power flags are removed, it may be time to bite the bullet and have two separate target flags like x86 did, because we keep running out of bits. I agree. But, wouldn't be better to have the e6500 patch separated from this ? Either way, I would like to collaborate towards having 2 target flags. Some comments from looking at the patches: A meta-issue is the name of the Freescale extensions. The problem of calling it Altivec2 is we get into a situation like AMD and Intel have had over what the next SSE revision is. Perhaps using a different name than Altivec2. David probably needs to weigh in on this. That name is my fault. Internally Freescale is not giving this feature any new name. Our design manual has a table that lists the differences between the original Altivec and the current Altivec, and that is it. I thought it would be better to have independent control of the instructions, instead of just throwing everything under __ALTIVEC__ Perhaps we should keep the control that the -m... option does and get rid of the __ALTIVEC2__ definition ? Regarding the spelling (-maltivec2 or other name), we do not have any position on it. What is the rationale for changing modes for stv* from V4SI to V16QI, and is it safe? I'm just worried about existing code, that suddenly stops working. Understandable. Right now there is a type mismatch. The RTL is V4SI and the builtins are emitted with V16QI, causing an ICE. I traced that ICE all the way back to 4.4. BTW, the only locations that uses V4SI are the ones I changed... In rs6000.c, I think gpopt/mfocrf should only be cleared if the user did not
Re: [Patch, fortran] PR 53456 Improve time resolution on targets without gettimeofday
Hi Janne, On 05/23/2012 04:44 PM, Janne Blomqvist wrote: some targets such as VXWorks don't provide gettimeofday but do provide clock_gettime. The attached patch allows such targets to get better resolution for the DATE_AND_TIME (up to the 1 millisecond limit of the API) intrinsic than the 1 second resolution provided by the current fallback of using the C standard time(). Ok for trunk? (Patch both inline below and as an attachment) I concur and wrote essentially the same patch - except that I used a different condition (and forgot to change the comment): +#elif defined(HAVE_CLOCK_GETTIME) defined(CLOCK_REALTIME) !defined(HAVE_CLOCK_GETTIME_LIBRT) I think in practice it shouldn't matter as librt* mostly affects GLIBC which has gettimeofday. Plus I believe CLOCK_REALTIME should be always available and only CLOCK_MONOTONIC is unimplemented on some systems (e.g. on VxWorks 5.5 but not on 6.x according to the documentation). (* = In intrinsics/system_clock.c, weak refs are used for librt; for gf_gettime that's an overkill and a simple time() as fall back is sufficient.) Okay with considering my preprocessor condition. Tobias PS: In Thunderbird, the attachment is shown as inline. Thus, from my side, it is sufficient to just keep the attachment.
[PATCH, rs6000] Fix insertion of nop[s] to force dependent load into new dispatch group.
The following patch fixes existing code that tried to prevent load-hit-store
(LHS) from being in the same dispatch group. The main problem was use of the
wrong dependency list in is_costly_group(), but I also added code to verify the
memory refs overlap and to emit group ending nops for those ISAs that have them.
Bootstrap/regtest on powerpc64-linux with no new regressions. Ok for trunk?
-Pat
2012-05-23 Pat Haugen pthau...@us.ibm.com
* config/rs6000/rs6000.c (rs6000_option_override_internal): Change
rs6000_sched_costly_dep default to true_store_to_load_dep_costly.
(adjacent_mem_locations): Move some code to and call...
(get_memref_parts): ...new function.
(mem_locations_overlap): New function.
(rs6000_adjust_priority): Adjust calls to is_load_insn/is_store_insn.
(is_mem_ref): Rename to...
(find_mem_ref): ...this. Return MEM rtx.
(get_store_dest): Remove function.
(is_load_insn1, is_load_insn, is_store_insn1, is_store_insn): Add
new parameter and adjust calls.
(rs6000_is_costly_dependence): Update calls for extra arg. Make sure
mem refs overlap for true_store_to_load_dep_costly.
(rs6000_sched_reorder2): Update calls for extra arg. Adjust args
passed to adjacent_mem_locations.
(is_costly_group): Walk resolved dependency list.
(force_new_group): Emit group ending nop for Power6/Power7.
* config/rs6000/rs6000.md (UNSPEC_GRP_END_NOP): New enum value.
(group_ending_nop): New define_insn.
gcc/testsuite:
* gcc.target/powerpc/lhs-1.c: New.
* gcc.target/powerpc/lhs-2.c: New.
* gcc.target/powerpc/lhs-3.c: New.
Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c (revision 187663)
+++ gcc/config/rs6000/rs6000.c (working copy)
@@ -1005,9 +1005,8 @@ static bool is_microcoded_insn (rtx);
static bool is_nonpipeline_insn (rtx);
static bool is_cracked_insn (rtx);
static bool is_branch_slot_insn (rtx);
-static bool is_load_insn (rtx);
-static rtx get_store_dest (rtx pat);
-static bool is_store_insn (rtx);
+static bool is_load_insn (rtx, rtx *);
+static bool is_store_insn (rtx, rtx *);
static bool set_to_load_agen (rtx,rtx);
static bool adjacent_mem_locations (rtx,rtx);
static int rs6000_adjust_priority (rtx, int);
@@ -3046,7 +3045,7 @@ rs6000_option_override_internal (bool gl
/* Handle -msched-costly-dep option. */
rs6000_sched_costly_dep
-= (rs6000_sched_groups ? store_to_load_dep_costly : no_dep_costly);
+= (rs6000_sched_groups ? true_store_to_load_dep_costly : no_dep_costly);
if (rs6000_sched_costly_dep_str)
{
@@ -22965,49 +22964,78 @@ set_to_load_agen (rtx out_insn, rtx in_i
return false;
}
-/* The function returns true if the target storage location of
- out_insn is adjacent to the target storage location of in_insn */
-/* Return 1 if memory locations are adjacent. */
+/* Try to determine base/offset/size parts of the given MEM.
+ Return true if successful, false if all the values couldn't
+ be determined.
+
+ This function only looks for REG or REG+CONST address forms.
+ REG+REG address form will return false. */
static bool
-adjacent_mem_locations (rtx insn1, rtx insn2)
+get_memref_parts (rtx mem, rtx *base, HOST_WIDE_INT *offset,
+ HOST_WIDE_INT *size)
{
+ rtx addr_rtx;
+ if MEM_SIZE_KNOWN_P (mem)
+*size = MEM_SIZE (mem);
+ else
+return false;
- rtx a = get_store_dest (PATTERN (insn1));
- rtx b = get_store_dest (PATTERN (insn2));
+ if (GET_CODE (XEXP (mem, 0)) == PRE_MODIFY)
+addr_rtx = XEXP (XEXP (mem, 0), 1);
+ else
+addr_rtx = (XEXP (mem, 0));
- if ((GET_CODE (XEXP (a, 0)) == REG
- || (GET_CODE (XEXP (a, 0)) == PLUS
- GET_CODE (XEXP (XEXP (a, 0), 1)) == CONST_INT))
- (GET_CODE (XEXP (b, 0)) == REG
- || (GET_CODE (XEXP (b, 0)) == PLUS
- GET_CODE (XEXP (XEXP (b, 0), 1)) == CONST_INT)))
+ if (GET_CODE (addr_rtx) == REG)
+{
+ *base = addr_rtx;
+ *offset = 0;
+}
+ else if (GET_CODE (addr_rtx) == PLUS
+ CONST_INT_P (XEXP (addr_rtx, 1)))
{
- HOST_WIDE_INT val0 = 0, val1 = 0, val_diff;
- rtx reg0, reg1;
+ *base = XEXP (addr_rtx, 0);
+ *offset = INTVAL (XEXP (addr_rtx, 1));
+}
+ else
+return false;
- if (GET_CODE (XEXP (a, 0)) == PLUS)
-{
- reg0 = XEXP (XEXP (a, 0), 0);
- val0 = INTVAL (XEXP (XEXP (a, 0), 1));
-}
- else
- reg0 = XEXP (a, 0);
+ return true;
+}
- if (GET_CODE (XEXP (b, 0)) == PLUS)
-{
- reg1 = XEXP (XEXP (b, 0), 0);
- val1 = INTVAL (XEXP (XEXP (b, 0), 1));
-}
- else
- reg1 = XEXP (b, 0);
+/* The function returns true if the target storage location of
+ mem1 is adjacent to the target storage location of mem2 */
+/* Return 1 if memory locations are adjacent. */
- val_diff = val1 - val0;
+static bool
Re: [Patch, fortran] PR 53456 Improve time resolution on targets without gettimeofday
On Wed, May 23, 2012 at 6:36 PM, Tobias Burnus bur...@net-b.de wrote: Hi Janne, On 05/23/2012 04:44 PM, Janne Blomqvist wrote: some targets such as VXWorks don't provide gettimeofday but do provide clock_gettime. The attached patch allows such targets to get better resolution for the DATE_AND_TIME (up to the 1 millisecond limit of the API) intrinsic than the 1 second resolution provided by the current fallback of using the C standard time(). Ok for trunk? (Patch both inline below and as an attachment) I concur and wrote essentially the same patch - except that I used a different condition (and forgot to change the comment): +#elif defined(HAVE_CLOCK_GETTIME) defined(CLOCK_REALTIME) !defined(HAVE_CLOCK_GETTIME_LIBRT) I think in practice it shouldn't matter as librt* mostly affects GLIBC which has gettimeofday. Plus I believe CLOCK_REALTIME should be always available and only CLOCK_MONOTONIC is unimplemented on some systems (e.g. on VxWorks 5.5 but not on 6.x according to the documentation). (* = In intrinsics/system_clock.c, weak refs are used for librt; for gf_gettime that's an overkill and a simple time() as fall back is sufficient.) Okay with considering my preprocessor condition. AFAICS it's not necessary. HAVE_CLOCK_GETTIME and HAVE_CLOCK_GETTIME_LIBRT are mutually exclusive, see the test for the latter in configure.ac. Also, POSIX states that CLOCK_REALTIME is mandatory, and in intrinsics/system_clock.c we assume its presense if clock_gettime is available. Thanks for the review. -- Janne Blomqvist
Re: [Ada] Remove call to expand_decl
2005-11-14 Thomas Quinot qui...@adacore.com Olivier Hainque hain...@adacore.com Eric Botcazou ebotca...@adacore.com ... (create_var_decl): call expand_decl for CONST_DECLs, to set MODE, ALIGN SIZE and SIZE_UNIT which we need for later back-annotations. I don't understand the reference to back-annotations so I don't really know if this need was meanwhile solved differently, or if it's still necessary. As said, there are no testcases in GCC (or in the Ada compiler itself) that would exhibit any problem with that setup removed. Gigi back-annotates the nodes of the Ada part of the front-end with information about the layout of objects. This is used by the -gnatR? options for example. I think this line is now obsolete because of: /* Back-annotate Esize and Alignment of the object if not already known. Note that we pick the values of the type, not those of the object, to shield ourselves from low-level platform-dependent adjustments like alignment promotion. This is both consistent with all the treatment above, where alignment and size are set on the type of the object and not on the object directly, and makes it possible to support all confirming representation clauses. */ annotate_object (gnat_entity, TREE_TYPE (gnu_decl), gnu_object_size, used_by_ref, false); * gcc-interface/utils.c (create_var_decl_1): Remove call to expand_decl. OK, thanks. -- Eric Botcazou
Re: fix cross build
On 05/22/12 15:12, Richard Guenther wrote:
But I wonder why CONSTRUCTORs do not inherit TREE_SIDE_EFFECTS
properly ...
the attached patch fixes the ICE and causes no regressions on i686-pc-linux-gnu.
ok?
nathan
2012-05-23 Nathan Sidwell nat...@acm.org
* tree.c (build_constructor): Propagate TREE_SIDE_EFFECTS.
* gcc.dg/stmt-expr-4.c: New.
Index: tree.c
===
--- tree.c (revision 187628)
+++ tree.c (working copy)
@@ -1416,17 +1416,24 @@ build_constructor (tree type, VEC(constr
unsigned int i;
constructor_elt *elt;
bool constant_p = true;
+ bool side_effects_p = false;
TREE_TYPE (c) = type;
CONSTRUCTOR_ELTS (c) = vals;
FOR_EACH_VEC_ELT (constructor_elt, vals, i, elt)
-if (!TREE_CONSTANT (elt-value))
- {
+{
+ /* Mostly ctors will have elts that don't have side-effects, so
+ the usual case is to scan all the elements. Hence a single
+ loop for both const and side effects, rather than one loop
+ each (with early outs). */
+ if (!TREE_CONSTANT (elt-value))
constant_p = false;
- break;
- }
+ if (TREE_SIDE_EFFECTS (elt-value))
+ side_effects_p = true;
+}
+ TREE_SIDE_EFFECTS (c) = side_effects_p;
TREE_CONSTANT (c) = constant_p;
return c;
Index: testsuite/gcc.dg/stmt-expr-4.c
===
--- testsuite/gcc.dg/stmt-expr-4.c (revision 0)
+++ testsuite/gcc.dg/stmt-expr-4.c (revision 0)
@@ -0,0 +1,22 @@
+
+/* { dg-options -O2 -std=gnu99 } */
+/* Internal compiler error in iterative_hash_expr */
+
+struct tree_string
+{
+ char str[1];
+};
+
+union tree_node
+{
+ struct tree_string string;
+};
+
+char *Foo (union tree_node * num_string)
+{
+ char *str = ((union {const char * _q; char * _nq;})
+ ((const char *)(({ __typeof (num_string) const __t
+ = num_string; __t; })
+ -string.str)))._nq;
+ return str;
+}
Re: [RFA] PowerPC e5500 and e6500 cores support
On Wed, May 23, 2012 at 10:18 AM, Edmar ed...@freescale.com wrote: David, Michael, Thanks for the feedback. If you don't object, I will relay the message to the designers. Meanwhile I have to work with the cards I have, so... I will break the patch in three parts: - One that includes the very basic, scheduling etc. - One for the Altivec builtins, which I will hold until we have a formal ISA-2.07 document, and we are sure there is no conflict with the patch. - The rest that will be kept by Freescale. Sounds like a reasonable plan. I look forward to your revised patches. Thanks, David
[cxx-conversion] Convert vec.[ch] to C++ [2/3] (issue6236043)
Part 2 of the VEC C++ conversion. This patch implements the gengtype
changes.
I extended gengtype to understand templated types. These changes are
not as ugly as I thought they would be. Gengtype has some hardwired
knowledge of VEC_*, which I renamed to vec_t. I'm not even sure why
gengtype needs to care about vec_t in this way, but I was looking for
minimal changes, so I just did it.
The other change is more generic. It allows gengtype to deal with
templated types. There is a new function (filter_type_name) that
recognizes C++ special characters '', '' and ':'. It turns them
into '_'. This way, gengtype can generate a valid identifier for the
pre-processor. It only does this in contexts where it needs a
pre-processor identifier. For everything else, it emits the type
directly. So, the functions emitted in gt-*.h files have proper
template type references.
2012-05-23 Diego Novillo dnovi...@google.com
* gengtype-lex.l (DEF_VEC_ALLOC_[IOP]/{EOID}): Remove.
* gengtype-parse.c (token_names): Remove DEF_VEC_ALLOC_[IOP].
(typedef_name): Emit vec_tC1 instead of VEC_C1_C2.
(def_vec_alloc): Remove. Update all callers.
* gengtype.c (filter_type_name): New.
(output_mangled_typename): Call it.
(write_func_for_structure): Likewise.
(write_types): Likewise.
(write_root): Likewise.
(write_typed_alloc_def): Likewise.
(note_def_vec): Emit vec_tTYPE_NAME instead of VEC_TYPE_NAME_base.
(note_def_vec_alloc): Remove.
* gengtype.h (note_def_vec_alloc): Remove.
(DEFVEC_ALLOC): Remove token code.
diff --git a/gcc/gengtype-lex.l b/gcc/gengtype-lex.l
index a71cce0..edfd4a1 100644
--- a/gcc/gengtype-lex.l
+++ b/gcc/gengtype-lex.l
@@ -100,10 +100,6 @@ EOID [^[:alnum:]_]
BEGIN(in_struct);
return DEFVEC_I;
}
-^{HWS}DEF_VEC_ALLOC_[IOP]/{EOID} {
- BEGIN(in_struct);
- return DEFVEC_ALLOC;
-}
}
in_struct{
diff --git a/gcc/gengtype-parse.c b/gcc/gengtype-parse.c
index 89f14e8..4fc2b07 100644
--- a/gcc/gengtype-parse.c
+++ b/gcc/gengtype-parse.c
@@ -79,7 +79,6 @@ static const char *const token_names[] = {
VEC,
DEF_VEC_[OP],
DEF_VEC_I,
- DEF_VEC_ALLOC_[IOP],
...,
ptr_alias,
nested_ptr,
@@ -227,7 +226,7 @@ typedef_name (void)
require (',');
c2 = require (ID);
require (')');
- r = concat (VEC_, c1, _, c2, (char *) 0);
+ r = concat (vec_t, c1, , (char *) 0);
free (CONST_CAST (char *, c1));
free (CONST_CAST (char *, c2));
return r;
@@ -916,31 +915,6 @@ def_vec (void)
return;
note_def_vec (type, is_scalar, lexer_line);
- note_def_vec_alloc (type, none, lexer_line);
-}
-
-/* Definition of an allocation strategy for a VEC structure:
-
- 'DEF_VEC_ALLOC_[IPO]' '(' id ',' id ')' ';'
-
- For purposes of gengtype, this just declares a wrapper structure. */
-static void
-def_vec_alloc (void)
-{
- const char *type, *astrat;
-
- require (DEFVEC_ALLOC);
- require ('(');
- type = require2 (ID, SCALAR);
- require (',');
- astrat = require (ID);
- require (')');
- require (';');
-
- if (!type || !astrat)
-return;
-
- note_def_vec_alloc (type, astrat, lexer_line);
}
/* Parse the file FNAME for GC-relevant declarations and definitions.
@@ -972,10 +946,6 @@ parse_file (const char *fname)
def_vec ();
break;
- case DEFVEC_ALLOC:
- def_vec_alloc ();
- break;
-
case EOF_TOKEN:
goto eof;
diff --git a/gcc/gengtype.c b/gcc/gengtype.c
index 814d9e0..82dca36 100644
--- a/gcc/gengtype.c
+++ b/gcc/gengtype.c
@@ -2295,6 +2295,34 @@ struct walk_type_data
int loopcounter;
};
+
+/* Given a string TYPE_NAME, representing a C++ typename, return a valid
+ pre-processor identifier to use in a #define directive. This replaces
+ special characters used in C++ identifiers like '', '' and ':' with
+ '_'.
+
+ If no C++ special characters are found in TYPE_NAME, return
+ TYPE_NAME. Otherwise, return a copy of TYPE_NAME with the special
+ characters replaced with '_'. In this case, the caller is
+ responsible for freeing the allocated string. */
+
+static const char *
+filter_type_name (const char *type_name)
+{
+ if (strchr (type_name, '') || strchr (type_name, ':'))
+{
+ size_t i;
+ char *s = xstrdup (type_name);
+ for (i = 0; i strlen (s); i++)
+ if (s[i] == '' || s[i] == '' || s[i] == ':')
+ s[i] = '_';
+ return s;
+}
+ else
+return type_name;
+}
+
+
/* Print a mangled name representing T to OF. */
static void
@@ -2321,8 +2349,13 @@ output_mangled_typename (outf_p of, const_type_p t)
case TYPE_STRUCT:
case TYPE_UNION:
case TYPE_LANG_STRUCT:
- oprintf (of, %lu%s, (unsigned long) strlen (t-u.s.tag),
-t-u.s.tag);
+ {
+ const char *id_for_tag = filter_type_name (t-u.s.tag);
+ oprintf (of, %lu%s, (unsigned long) strlen (id_for_tag),
+
Re: [Patch, Fortran] PR51055 - accept non-spec-expr i in allocate(character(len=i)::s)
*ping* On 20 May 2012 10:34, Tobias Burnus wrote: *ping* On Tue, 15 May 2012 12:26, Tobias Burnus wrote: A rather simple patch. Build and regtested on x86-64-linux. OK for the trunk? I think that is the last patch required for commonly used code. Remaining are issues with array constructors and concatenations - and, of course, deferred-length components. Tobias
Re: [Patch, Fortran] PR51055 - accept non-spec-expr i in allocate(character(len=i)::s)
On Wed, May 23, 2012 at 9:49 PM, Tobias Burnus bur...@net-b.de wrote: *ping* On 20 May 2012 10:34, Tobias Burnus wrote: *ping* On Tue, 15 May 2012 12:26, Tobias Burnus wrote: A rather simple patch. Build and regtested on x86-64-linux. OK for the trunk? Looks obvious to me :-) Ciao! Steven
Re: [C++ Patch] for c++/51214
2012/5/7 Jason Merrill ja...@redhat.com: On 05/06/2012 04:06 PM, Fabien Chêne wrote: + if (late_enum_values) + VEC_safe_push (tree, gc, late_enum_values, decl); I would think you could walk the TYPE_VALUES list directly, rather than copy it into a temporary VEC. Indeed, let's use good old tree lists. Tested x86_64-unknown-linux-gnu, OK for trunk and 4.7 ? gcc/testsuite/ChangeLog 2012-05-23 Fabien Chêne fab...@gcc.gnu.org PR c++/51214 * g++.dg/cpp0x/forw_enum11.C: New. gcc/cp/ChangeLog 2012-05-23 Fabien Chêne fab...@gcc.gnu.org PR c++/51214 * cp-tree.h (insert_late_enum_def_into_classtype_sorted_fields): Declare. * class.c (insert_into_classtype_sorted_fields): New. (add_enum_fields_to_record_type): New. (count_fields): Adjust the comment. (add_fields_to_record_type): Likewise. (finish_struct_1): Move the code that inserts the fields for the sorted case, into insert_into_classtype_sorted_fields, and call it. (insert_late_enum_def_into_classtype_sorted_fields): Define. * decl.c (finish_enum_value_list): Call insert_late_enum_def_into_classtype_sorted_fields if a late enum definition is encountered. -- Fabien 51214.patch Description: Binary data
[Patch, fortran] PR 53456 More CPU timing fallbacks
Hi, the attached patch allows the use of clock_gettime() with CLOCK_PROCESS_CPUTIME_ID or CLOCK_THREAD_CPUTIME_ID if the target doesn't have getrusage() or times(). Such a target is apparently VxWorks 6.something, see http://www-ad.fnal.gov/controls/micro_p/manuals/vxworks_application_programmers_guide_6.7.pdf Ok for trunk? 2012-05-23 Janne Blomqvist j...@gcc.gnu.org PR fortran/53456 * intrinsics/time_1.h (gf_cputime): Fallback for clock_gettime. -- Janne Blomqvist vxtime2.diff Description: Binary data
Re: [PATCH v2] ARM: Use different linker path for hardfloat ABI
On 24 May 2012 02:16, Mike Frysinger vap...@gentoo.org wrote: On Wednesday 23 May 2012 04:17:51 Richard Guenther wrote: On Wed, 23 May 2012, Andreas Jaeger wrote: On Wednesday, May 23, 2012 09:56:31 Richard Earnshaw wrote: [...] This is a behaviour change. It would need RM approval for a release branch. R. There was agreement by all pushing for the change to use it. So, let's ask the release managers about their opinion, I'm ok with the change - but of course only to carry one less patch in our local tree. What do others think? It would definitely (anyway) need documenting in changes.html (for both 4.7.1 and 4.8). i've done this for Gentoo and 4.5.0+, so if all the distros are going to be doing this in 4.7.x anyways, makes sense to me to do it in the official branch. Agreed. Google have done it for their 4.6, Fedora have done it for 4.7 (?), and we've done it for Linaro GCC 4.6 and 4.7. My concern is that a point release of GCC would stop working against the latest release of GLIBC. I'm happy to prepare a backport to GCC 4.6, GCC 4.7, and GLIBC 2.15 so the next set of point releases will all work with each other. This would match what the distros are doing. -- Michael
Re: [PATCH, 4.6] Fix PR53170: missing target c++11 selector
On 24 May 2012 00:27, Paolo Carlini paolo.carl...@oracle.com wrote:
On 05/23/2012 05:39 AM, Michael Hope wrote:
On 21/05/12 21:14, Paolo Carlini wrote:
On 05/21/2012 01:45 AM, Michael Hope wrote:
The testsuite for PR52796 uses the 'target c++11' selector which doesn't
exist in 4.6.
This patch backports the selector, clearing the 'ERROR:
g++.dg/cpp0x/variadic-value1.C:
syntax error in target selector target c++11 for dg-do 2 run {
target c++11 } '
errors which have appeared in recent 4.6 builds.
Tested on x86_64-linux-gnu with no regressions. Changes the ERROR to
UNSUPPORTED.
OK for 4.6?
To be honest, when I saw the issue I thought we wanted simply to not use
the target selector at all in the branch and simply add a // { dg-options
-std=c++11 } I thought somebody would commit the change as obvious ;)
Sure. The version below changes the selector for explicit flags that
match those passed by trunk.
OK for 4.6?
-- Michael (who's not keen enough to commit as obvious)
I would say let's go ahead ;) But in the ChangeLog entry please use PR
c++/52796.
Done as per http://gcc.gnu.org/ml/gcc-cvs/2012-05/msg00810.html and
the typo fix in http://gcc.gnu.org/ml/gcc-cvs/2012-05/msg00813.html.
-- Michael
Re: [cxx-conversion] Convert vec.[ch] to C++ [1/3] (issue6233044)
On 5/23/12, Diego Novillo dnovi...@google.com wrote: OK for cxx-conversion branch? LGTM. -- Lawrence Crowl
Re: [cxx-conversion] Convert vec.[ch] to C++ [2/3] (issue6236043)
On 5/23/12, Diego Novillo dnovi...@google.com wrote: Part 2 of the VEC C++ conversion. This patch implements the gengtype changes. LGTM. -- Lawrence Crowl
Re: [cxx-conversion] Convert vec.[ch] to C++ [3/3] (issue6236044)
On 5/23/12, Diego Novillo dnovi...@google.com wrote: Part 3 of the VEC C++ conversion. This patch implements all the client code changes needed by the API changes made by the first patch. LGTM. -- Lawrence Crowl
Re: Turn check macros into functions. (issue6188088)
On 5/21/12, Mike Stump mikest...@comcast.net wrote:
On May 18, 2012, at 7:48 PM, Lawrence Crowl wrote:
On 5/17/12, Mike Stump mikest...@comcast.net wrote:
On May 17, 2012, at 2:41 PM, Lawrence Crowl wrote:
Reusing the compiler for this seems like the only way to go.
But, we did look at using g++ to parse C++ expressions from gdb,
and it was too slow :-(. We're going to look again, at least to
generate some bug reports if we can.
It's a tough problem, particularly as C/C++ and their compilers
were not designed for a read-eval-print-loop environment.
This of course is trivial to do,
I do not think that word means what you think it means. :-)
Excellent reference... Yeah, well, just a little more work to do:
$ ./eval
extern C int printf(const char *...); int k2 = *(int*)4294971592;
void eval() { printf(k is %d\n, k2); }
about to run
k is 42
done running, took 32540 usecs
Notice, this sucked a int k2 = 42; that was a variable inside
the context in which I wanted a k2. The nature of the variable
is irrelevant, could be a stack variable, could be a global,
a static top-level, all I need to know, is where it is (the
address) and the type and I generate a binding stub for it into
the context, and presto, complete access to most all variables.
This does make use of C++ to manage the variables in a slightly
nicer way. One either has to inject all variables and functions
into the context into which the program fragment is compiled,
or notice which variables and function are or might be used and
inject just those.
I've seen ptype foo print the types of variables, so, it isn't
far off, and certainly gdb knows about the symbol table and can
figure out the addresses of those variables, right?!
For variables that are not optimized out of memory, I think this
can work. But if you need to go for registers, or undo a variable
elimination, the effort gets harder.
Now, certainly one can find additional issues, and yes, there
is a bit of work to get 100% reliability that we'd like from
the scheme. For example, packed structures would need work, as
ptype isn't going to get that right from that start. I think the
functionality one would get would be good enough to start with,
and in time, better support for things ptype doesn't get right
would fix a certain class of problems.
Agreed.
So, what another 1000 lines to generate the context for the
fragment... I guess finding references could be annoying, and the
time required to generate and compile the entire context could
be annoying...
Doing C++ would be harder, though, not quite for the reason
you gave.
I like the example, but it sidesteps the main problem, which is
putting the expression in the context from which it was called.
For instance if I stop in the middle of a function and type
print foo-bar( a + b )
I need to find the find the variable names, lookup their types,
ptype a does the lookup for a, and finds the type, so that isn't
hard, same with b and foo. Harder would be to synthesize the
context for the fragment to live in. To do this and work with
templates, you'd need the entire template bodies to be in the
debug information and to output them when generating the context
that might use them.
Yes, you essentially need to come close to sending the compiler's
symbol tables through the debug information. I don't know of any
compiler/debugger pair that is close to that capability. That said,
I don't know all such pairs either.
class A {
foo() { }
}
when stopped in foo, one needs to generate:
class A {
foo();
__eval() { fragment }
}
and then call __eval(lookup(this))... The compiler does
the overload resolution, the template instantiation and so on.
To ensure the compiler does name loookup right, one just needs
to generate the context for that fragment carefully.
Agreed.
do overload resolution, possibly do template instantiation, etc,
all as if the compiler was in the scope defined for the line that
the debugger is stopped at. That's the hard part.
I'm not saying that the task is impossible, only that there is a
lot of work to do before we get there.
--
Lawrence Crowl
Re: Turn check macros into functions. (issue6188088)
On 5/21/12, Tom Tromey tro...@redhat.com wrote: Alexander == Alexander Monakov amona...@ispras.ru writes: Alexander Hm, isn't GDB's 'set unwindonsignal on' enough to fix it? Alexander It's useful to have that in your .gdbinit anyway, because the Alexander same issue arises when calling debug_* functions in cc1 from Alexander the debugger. Yeah, why didn't I remember that? I think it should suffice. Thanks for the reminder. Should I add that to my patch to gdbinit.in? -- Lawrence Crowl
[PATCH] Add powerpc64-linux configuration options
On powerpc64-linux systems that run on IBM servers, the 32-bit software
emulation library is not built with the Red Hat and SUSE distributions, but the
FSF sources still list it as a multilib. This patch adds a configuration
option (--disable-ppc64-swfloat) to disable building this library.
We've also seen some performance issues where building the multilibs with the
-mstrict-align option causes slow downs. I vaguelly recall adding this option
in the 1995 time frame, because the 603, 604 systems of the day did not handle
unaligned accesses in little endian mode, and maybe some of the other embedded
chips did not handle unaligned accesses at all. This patch also adds an option
(--disable-ppc64-strict-align) to disable building the multilibs with
-mstrict-align.
I have bootstrapped the compiler with and without the changes, and there are no
differences. Is it ok to apply?
An alternative would be for the powerpc64-linux case, should we just delete the
software floating emulation multilib and stop using the -mstrict-align, since
Linux only runs in big endian mode. The software emulation multilib would be
built for other powerpc varients and -mstrict-align would be used there as
well.
2012-05-23 Michael Meissner meiss...@linux.vnet.ibm.com
* configure.ac (--disable-ppc64-swfloat): New configure switches
for powerpc64-linux to disable building multlibs for 32-bit
software floating point emulation, and to remove the
-mstrict-align option from the multilib options.
(--disable-ppc64-strict-align): Likewise.
* config.gcc (powerpc64-linux): Likewise.
* configure: Regenerate.
* config/rs6000/t-linux64-noalign: New configuration files for
enabling and disabling building the libraries with
-mstrict-align.
* config/rs6000/t-linux64-align: Likewise.
* config/rs6000/t-linux64-noswflt: New configuration file to
disable building the 32-bit software floating point emulation
library.
* config/rs6000/t-linux64 (MULTILIB_EXTRA_OPTS): Move to
t-linux64-align and t-linux64-noalign.
* doc/install.texi (--disable-ppc64-swfloat): Document.
(--dsiable-ppc64-strict-align): Likewise.
--
Michael Meissner, IBM
5 Technology Place Drive, M/S 2757, Westford, MA 01886-3141, USA
meiss...@linux.vnet.ibm.com fax +1 (978) 399-6899
Index: gcc/doc/install.texi
===
--- gcc/doc/install.texi(revision 187805)
+++ gcc/doc/install.texi(working copy)
@@ -1423,6 +1423,21 @@ defaulted to o32.
Currently, this option only affects sparc-linux, powerpc-linux, x86-linux,
mips-linux and s390-linux.
+@item --disable-ppc64-swfloat
+This option disables building the 32-bit software floating point
+libraries for powerpc64-linux.
+
+@item --disable-ppc64-strict-align
+This option disables building the libraries with the
+@option{-mstrict-align} option on powerpc64-linux.
+@ifnothtml
+@xref{RS/6000 and PowerPC Options,, RS/6000 and PowerPC Options, gcc,
+Using the GNU Compiler Collection (GCC)},
+@end ifnothtml
+@ifhtml
+See ``RS/6000 and PowerPC Options'' in the main manual
+@end ifhtml
+
@item --enable-secureplt
This option enables @option{-msecure-plt} by default for powerpc-linux.
@ifnothtml
Index: gcc/configure
===
--- gcc/configure (revision 187805)
+++ gcc/configure (working copy)
@@ -893,6 +893,8 @@ with_multilib_list
enable_rpath
with_libiconv_prefix
enable_sjlj_exceptions
+enable_ppc64_swfloat
+enable_ppc64_strict_align
enable_secureplt
enable_leading_mingw64_underscores
enable_cld
@@ -1592,6 +1594,11 @@ Optional Features:
--disable-rpath do not hardcode runtime library paths
--enable-sjlj-exceptions
arrange to use setjmp/longjmp exception handling
+ --disable-ppc64-swfloat disable building 32-bit software floating point
+ libraries on 64-bit PowerPC Linux systems
+ --disable-ppc64-strict-align
+ disable building multilibs with -mstrict-align on
+ 64-bit PowerPC Linux systems
--enable-secureplt enable -msecure-plt by default for PowerPC
--enable-leading-mingw64-underscores
enable leading underscores on 64 bit mingw targets
@@ -11507,6 +11514,18 @@ case $LIBINTL in *$LIBICONV*)
LIBICONV= ;;
esac
+# Check whether --enable-ppc64-swfloat was given.
+if test ${enable_ppc64_swfloat+set} = set; then :
+ enableval=$enable_ppc64_swfloat;
+fi
+
+
+# Check whether --enable-ppc64-strict-align was given.
+if test ${enable_ppc64_strict_align+set} = set; then :
+ enableval=$enable_ppc64_strict_align;
+fi
+
+
# Check whether --enable-secureplt was given.
if test ${enable_secureplt+set} = set; then :
enableval=$enable_secureplt;
@@ -17967,7 +17986,7 @@ else
lt_dlunknown=0;
Re: [PATCH] Add powerpc64-linux configuration options
On Wed, 23 May 2012, Michael Meissner wrote: An alternative would be for the powerpc64-linux case, should we just delete the software floating emulation multilib and stop using the -mstrict-align, since Linux only runs in big endian mode. The software emulation multilib would be built for other powerpc varients and -mstrict-align would be used there as well. I support deleting the soft-float multilib; it can't be used as-is because it requires its own libc, in its own sysroot, and the configuration doesn't use a separate sysroot for it. As for -mstrict-align, again if someone wants -mstrict-align libraries I think they should set up a multilib using that option (or a CPU option that implies it) rather than trying to make the libraries from a compiler configured for some CPU compatible with another CPU they wouldn't normally be compatible with. -- Joseph S. Myers jos...@codesourcery.com
Re: Turn check macros into functions. (issue6188088)
On May 23, 2012, at 3:36 PM, Lawrence Crowl wrote:
For variables that are not optimized out of memory, I think this
can work. But if you need to go for registers,
Also trivial... Just one has to generate the context correctly. One has to
save off the registers and then in the context generator, synthesize them back
up. So, take a context in which a is in register 5, one can generate something
like:
void eval() {
register int a = __gdb_registers[5];
snippet
__gdb_registers[5] = a;
}
This preserves the value in register 5 from the gdb context at that point, and
even allows the user to write to such variables, and have that reflected in the
register file.
or undo a variable elimination, the effort gets harder.
Yes, setting the value of a variable that has, for example, been removed due to
dce, is annoying. But I'll note it is annoying in gdb currently. I'd be happy
to introduce declarations that if used, lead to compile time errors. Darwin
for example has an unavailable attribute one can attach to a decl to ensure an
error is produced. gcc has deprecated, though, it is just a warning.
Now, for variables that can be computed from variables that are present, I'd
rather the optimizer explain how to produce the value given the state and for
gdb to producea context with that value into a read only variable. This
preserves for read access such variables that are gone. This is something that
gcc and gdb should be doing anyway... but don't.
Yes, you essentially need to come close to sending the compiler's
symbol tables through the debug information. I don't know of any
compiler/debugger pair that is close to that capability.
:-) Not yet... Maybe never.
I'm not saying that the task is impossible, only that there is a
lot of work to do before we get there.
Yeah, I kinda think the gdb people are wimping out by not just implementing
__extension__ and ({}), which, I think get us most of the way there. Shh,
don't tell them I said that.
Re: [PATCH 2/2] Better system header location detection for built-in macro tokens
On 05/23/2012 04:52 AM, Dodji Seketeli wrote:
I tried to do what the C FE seems to do, which is to consider that the
default location (the global input_location variable) is on the LHS of
the assignment (on the usi variable), rather than on the token that
comes from DEC32_MAX.
That makes sense. Though really the relevant location would be the '='.
But then it regresses notably on tests like
testsuite/g++.dg/warn/pr35635.C:
void func3()
{
unsigned char uchar_x;
...
uchar_x = bar != 0
? (unsigned char) 1024
: -1; /* { dg-warning negative integer implicitly converted to unsigned
type } */
}
Regresses how? In this case the locus of the conversion is again the
'='. So the line number of the warning might change, but that doesn't
seem like a significant regression.
It seems to me that ultimately, things like conversion routines that
emit diagnostics should know about the expression that represents the
context in which they are emitting the said diagnostic. In this
particular case, warnings_for_convert_and_check should know about the
assignment expression usi = DEC32_MAX, so that it can determine that
the whole expression is spelled in user code, and thus, the diagnostic
should be emitted. IOW, just knowing about the single token on which
the error occurs is not enough to decide.
I'm not sure I agree. We don't want to warn about a conversion that's
all within a macro from a system header, even if it is expanded within
an expression in user code. We just need to get the location right for
our diagnostics, which is an ongoing process, but we've been making a
lot of progress just recently.
Jason
Re: [PATCH][4/n] referenced-vars TLC
On Wed, May 23, 2012 at 7:25 AM, H.J. Lu hjl.to...@gmail.com wrote: On Wed, May 23, 2012 at 5:00 AM, Richard Guenther rguent...@suse.de wrote: This finally switches us to not record global vars in referenced-vars. For this to work I had to re-engineer how we handle global var removal from local-decls in remove_unused_locals. Incidentially that code already had some sort of a bitmap (for some weird reason even), thus I borrowed that and simplified the handling. You may notice that it would be easy to handle all vars that way ... So eventually 5/n will make referenced-vars go away completely (the only serious user seems to be the SSA renamer for its SYMS_TO_RENAME bitmap). Bootstrapped on x86_64-unknown-linux-gnu, testing in progress. Richard. 2012-05-23 Richard Guenther rguent...@suse.de * tree-dfa.c (add_referenced_var_1): Do not add global vars. * tree-ssa-live.c (mark_all_vars_used_1): Handle global vars via the global_unused_vars bitmap. (remove_unused_locals): Handle global vars in local-decls via a global_unused_vars bitmap instead of the used flag in the var annotation. Simplify global variable handling and removal. This breaks bootstrap on Linux/x86-64: http://gcc.gnu.org/ml/gcc-regression/2012-05/msg00468.html Comparing stages 2 and 3 warning: gcc/cc1plus-checksum.o differs warning: gcc/cc1obj-checksum.o differs warning: gcc/cc1-checksum.o differs Bootstrap comparison failure! gcc/trans-mem.o differs gcc/gimple-low.o differs gcc/sese.o differs make[5]: *** [compare] Error 1 Please make sure that your compiler used for bootstrap doesn't add anything to .comment section, which will disable debug compare. I opened: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53466 -- H.J.
Re: [PATCH] Fix VRP handling of undefined state
On Fri, Jul 29, 2011 at 1:46 AM, Richard Guenther rguent...@suse.de wrote: I noticed that for binary expressions VRP contains the same bugs that CCP once did (it treats UNDEFINED * 0 as UNDEFINED). Then I noticed we never hit this bug because we never end up with any range being UNDEFINED - which is bad, because this way we miss value-ranges for all conditionally initialized variables. Thus, the following patch fixes this and conservatively handles the binary expression case (which is only of academic interest anyway - the important part is to handle UNDEFINED in PHIs). Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk. Richard. 2011-07-29 Richard Guenther rguent...@suse.de * tree-vrp.c (get_value_range): Only set parameter default definitions to varying, leave others at undefined. (extract_range_from_binary_expr): Fix undefined handling. (vrp_visit_phi_node): Handle merged undefined state. This caused: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53465 -- H.J.
Re: [PATCH v2] ARM: Use different linker path for hardfloat ABI
On Wednesday 23 May 2012 17:11:53 Michael Hope wrote: On 24 May 2012 02:16, Mike Frysinger wrote: On Wednesday 23 May 2012 04:17:51 Richard Guenther wrote: On Wed, 23 May 2012, Andreas Jaeger wrote: On Wednesday, May 23, 2012 09:56:31 Richard Earnshaw wrote: [...] This is a behaviour change. It would need RM approval for a release branch. R. There was agreement by all pushing for the change to use it. So, let's ask the release managers about their opinion, I'm ok with the change - but of course only to carry one less patch in our local tree. What do others think? It would definitely (anyway) need documenting in changes.html (for both 4.7.1 and 4.8). i've done this for Gentoo and 4.5.0+, so if all the distros are going to be doing this in 4.7.x anyways, makes sense to me to do it in the official branch. Agreed. Google have done it for their 4.6, Fedora have done it for 4.7 (?), and we've done it for Linaro GCC 4.6 and 4.7. My concern is that a point release of GCC would stop working against the latest release of GLIBC. I'm happy to prepare a backport to GCC 4.6, GCC 4.7, and GLIBC 2.15 so the next set of point releases will all work with each other. This would match what the distros are doing. http://sources.gentoo.org/gentoo/src/patchsets/gcc/4.6.3/gentoo/33_all_armhf.patch http://sources.gentoo.org/gentoo/src/patchsets/gcc/4.7.0/gentoo/33_all_armhf.patch http://sources.gentoo.org/gentoo/src/patchsets/glibc/2.15/6226_all_arm-glibc-2.15-hardfp.patch -mike signature.asc Description: This is a digitally signed message part.
Re: [PATCH] Hoist adjacent pointer loads
On Wed, 2012-05-23 at 13:25 +0200, Richard Guenther wrote:
On Tue, 22 May 2012, William J. Schmidt wrote:
Here's a revision of the hoist-adjacent-loads patch. Besides hopefully
addressing all your comments, I added a gate of at least -O2 for this
transformation. Let me know if you prefer a different minimum opt
level.
I'm still running SPEC tests to make sure there are no regressions when
opening this up to non-pointer arguments. The code bootstraps on
powerpc64-unknown-linux-gnu with no regressions. Assuming the SPEC
numbers come out as expected, is this ok?
Thanks,
Bill
2012-05-22 Bill Schmidt wschm...@linux.vnet.ibm.com
* tree-ssa-phiopt.c (tree_ssa_phiopt_worker): Add argument to forward
declaration.
(hoist_adjacent_loads, gate_hoist_loads): New forward declarations.
(tree_ssa_phiopt): Call gate_hoist_loads.
(tree_ssa_cs_elim): Add parm to tree_ssa_phiopt_worker call.
(tree_ssa_phiopt_worker): Add do_hoist_loads to formal arg list; call
hoist_adjacent_loads.
(local_mem_dependence): New function.
(hoist_adjacent_loads): Likewise.
(gate_hoist_loads): Likewise.
* common.opt (fhoist-adjacent-loads): New switch.
* Makefile.in (tree-ssa-phiopt.o): Added dependencies.
* params.def (PARAM_MIN_CMOVE_STRUCT_ALIGN): New param.
Index: gcc/tree-ssa-phiopt.c
===
--- gcc/tree-ssa-phiopt.c (revision 187728)
+++ gcc/tree-ssa-phiopt.c (working copy)
@@ -37,9 +37,17 @@ along with GCC; see the file COPYING3. If not see
#include cfgloop.h
#include tree-data-ref.h
#include tree-pretty-print.h
+#include gimple-pretty-print.h
+#include insn-config.h
+#include expr.h
+#include optabs.h
+#ifndef HAVE_conditional_move
+#define HAVE_conditional_move (0)
+#endif
+
static unsigned int tree_ssa_phiopt (void);
-static unsigned int tree_ssa_phiopt_worker (bool);
+static unsigned int tree_ssa_phiopt_worker (bool, bool);
static bool conditional_replacement (basic_block, basic_block,
edge, edge, gimple, tree, tree);
static int value_replacement (basic_block, basic_block,
@@ -53,6 +61,9 @@ static bool cond_store_replacement (basic_block, b
static bool cond_if_else_store_replacement (basic_block, basic_block,
basic_block);
static struct pointer_set_t * get_non_trapping (void);
static void replace_phi_edge_with_variable (basic_block, edge, gimple,
tree);
+static void hoist_adjacent_loads (basic_block, basic_block,
+ basic_block, basic_block);
+static bool gate_hoist_loads (void);
/* This pass tries to replaces an if-then-else block with an
assignment. We have four kinds of transformations. Some of these
@@ -138,12 +149,56 @@ static void replace_phi_edge_with_variable (basic_
bb2:
x = PHI x' (bb0), ...;
- A similar transformation is done for MAX_EXPR. */
+ A similar transformation is done for MAX_EXPR.
+
+ This pass also performs a fifth transformation of a slightly different
+ flavor.
+
+ Adjacent Load Hoisting
+ --
+
+ This transformation replaces
+
+ bb0:
+ if (...) goto bb2; else goto bb1;
+ bb1:
+ x1 = (expr).field1;
+ goto bb3;
+ bb2:
+ x2 = (expr).field2;
+ bb3:
+ # x = PHI x1, x2;
+
+ with
+
+ bb0:
+ x1 = (expr).field1;
+ x2 = (expr).field2;
+ if (...) goto bb2; else goto bb1;
+ bb1:
+ goto bb3;
+ bb2:
+ bb3:
+ # x = PHI x1, x2;
+
+ The purpose of this transformation is to enable generation of
conditional
+ move instructions such as Intel CMOVE or PowerPC ISEL. Because one of
+ the loads is speculative, the transformation is restricted to very
+ specific cases to avoid introducing a page fault. We are looking for
+ the common idiom:
+
+ if (...)
+ x = y-left;
+ else
+ x = y-right;
+
+ where left and right are typically adjacent pointers in a tree
structure. */
+
static unsigned int
tree_ssa_phiopt (void)
{
- return tree_ssa_phiopt_worker (false);
+ return tree_ssa_phiopt_worker (false, gate_hoist_loads ());
}
/* This pass tries to transform conditional stores into unconditional
@@ -190,7 +245,7 @@ tree_ssa_phiopt (void)
static unsigned int
tree_ssa_cs_elim (void)
{
- return tree_ssa_phiopt_worker (true);
+ return tree_ssa_phiopt_worker (true, false);
}
/* Return the singleton PHI in the SEQ of PHIs for edges E0 and E1. */
@@ -227,9 +282,11 @@ static tree condstoretemp;
/* The core routine of conditional store replacement and normal
phi optimizations. Both share much of the infrastructure in how
to match applicable basic block
Re: fix install-no-fixedincludes mishaps
On Wed, May 16, 2012 at 7:46 AM, Olivier Hainque hain...@adacore.com wrote: 2012-05-16 Olivier Hainque hain...@adacore.com libgcc/ * Makefile.in (install-unwind_h): Rename into ... (install-unwind_h-forbuild): New target. (all): Use it instead of the former install-unwind_h. (install-unwind_h): Reinstate, copy to user install destination for include files, not to the internal gcc object directory one. (install-leaf): Depend on it. This has a fairly annoying side effect. The all rule in libgcc runs a make install installing everything back in the gcc directory. This now installs unwind.h. The effect is that every time libgcc is built, unwind.h changes. And the effect of that is that every library file that depends on unwind.h gets rebuilt every time. This affects libgo and libitm. Please fix this one way or another so that the copy of unwind.h installed in the gcc object directory does not have its timestamp change if the file contents are unchanged, as it used to be. Thanks. Ian
