[wide-int] tree-ssa-ccp fix
The asm comparison showed a problem with my r204593 change, which dropped
a "val.mask &" in the second hunk below.
Seeing that the problem was in ccp made me look at the whole file again.
I noticed that we'd changed the VARYING mask value from -1 to 1, which
didn't look intentional.
Tested on x86_64-linux-gnu. OK to install?
Thanks,
Richard
Index: gcc/tree-ssa-ccp.c
===
--- gcc/tree-ssa-ccp.c 2014-04-23 19:13:20.488547331 +0100
+++ gcc/tree-ssa-ccp.c 2014-04-23 19:30:07.025416946 +0100
@@ -607,7 +607,7 @@ get_value_for_expr (tree expr, bool for_
else
{
val.lattice_val = VARYING;
- val.mask = 1;
+ val.mask = -1;
val.value = NULL_TREE;
}
return val;
@@ -1848,7 +1848,7 @@ evaluate_stmt (gimple stmt)
if (nonzero_bits == 0)
val.mask = 0;
else
- val.mask = extend_mask (nonzero_bits);
+ val.mask = val.mask & extend_mask (nonzero_bits);
}
}
}
Re: [RFC] Add aarch64 support for ada
On 04/23/2014 01:37 PM, Eric Botcazou wrote: >> But it breaks on IA-64 for the same reason as on Aarch64 so we'll need to >> > find something else. > Tentative revised patch attached. Can you give it a try when you have some > time? There is a rationale based on my understanding in types.h. TIA. Bootstrap and test succeeded, thanks. r~
Re: Skip gcc.dg/tree-ssa/isolate-*.c for AVR Target
On 04/07/14 01:10, K_s, Vishnu wrote: Added comment to avr.c on why disabling -fdelete-null-pointer-checks. Patch Attached in the mail. Previously approved patch can be found here - http://gcc.gnu.org/ml/gcc-patches/2014-03/msg01697.html. I don't have commit access to the source, please commit both the patches If they are OK. Regards Vishnu KS 2014-03-31 Vishnu K S * gcc/config/avr/avr.c: Add comment on why disabling -fdelete-null-pointer-checks Thanks. Installed. jeff
Re: Skip gcc.dg/tree-ssa/isolate-*.c for AVR Target
On 03/31/14 02:20, K_s, Vishnu wrote: Changed the comment in log as the tests are not skipping for AVR only, but for all The targets keeps_null_pointer_checks is true. Corrected the log as per the comments. Please review it and commit it if it's OK. Regards Vishnu KS 2014-03-31 Vishnu K S * gcc/testsuite/gcc.dg/tree-ssa/isolate-1.c: Skip test if keeps_null_pointer_checks is true for target. * gcc/testsuite/gcc.dg/tree-ssa/isolate-2.c: Ditto * gcc/testsuite/gcc.dg/tree-ssa/isolate-3.c: Ditto * gcc/testsuite/gcc.dg/tree-ssa/isolate-4.c: Ditto * gcc/testsuite/gcc.dg/tree-ssa/isolate-5.c: Ditto Thanks. Installed. jeff
[wide-int] Stricter type checking in wide_int constructor
At the moment we prohibit "widest_int = wide_int" and "offset_int = wide_int".
These would be correct only if the wide_int had the same precision as
widest_int and offset_int respectively, but since those precisions
don't really correspond to a particular language-level precision,
such cases should never occur in practice.
We also prohibit "wide_int = HOST_WIDE_INT" on the basis that the wide_int
would naturally get the precision of HOST_WIDE_INT, which is a host property.
However, we allowed "wide_int = widest_int" and "wide_int = offset_int".
This is always safe in the sense that, unlike "widest_int = wide_int"
and "offset_int = wide_int", they would never trigger an assertion
failure in themselves. But I think in practice they're always going to
be a mistake. The only arithmetic you can do on the resulting wide_int
is with wide_ints that have been assigned in the same way, in which case
you should be doing the arithmetic on widest_int or offset_int instead.
And if you don't want to do arithmetic, but simply want to access the value,
you should use wide_int_ref instead. This avoids unnecessary copying.
This patch adds an extra STATIC_ASSERT to trap that case and fixes
the minor fallout. The to_mpz change contains another fix: we applied
small_prec without checking whether len was the maximum value.
Also, it seems safer to use alloca now that we have the extra-wide
integer in vrp.
Putting the STATIC_ASSERTs in their own scope is a bit clunky, but a lot
of this code would be much cleaner with C++11...
Tested on x86_64-linux-gnu and included in the asm comparison. OK to install?
Thanks,
Richard
Index: gcc/emit-rtl.c
===
--- gcc/emit-rtl.c 2014-04-24 08:30:16.191670326 +0100
+++ gcc/emit-rtl.c 2014-04-24 08:30:19.117694968 +0100
@@ -535,7 +535,7 @@ lookup_const_wide_int (rtx wint)
(if TARGET_SUPPORTS_WIDE_INT). */
rtx
-immed_wide_int_const (const wide_int &v, enum machine_mode mode)
+immed_wide_int_const (const wide_int_ref &v, enum machine_mode mode)
{
unsigned int len = v.get_len ();
unsigned int prec = GET_MODE_PRECISION (mode);
Index: gcc/rtl.h
===
--- gcc/rtl.h 2014-04-24 08:30:16.191670326 +0100
+++ gcc/rtl.h 2014-04-24 08:30:19.117694968 +0100
@@ -2008,7 +2008,7 @@ extern double_int rtx_to_double_int (con
#endif
extern void cwi_output_hex (FILE *, const_rtx);
#ifndef GENERATOR_FILE
-extern rtx immed_wide_int_const (const wide_int &cst, enum machine_mode mode);
+extern rtx immed_wide_int_const (const wide_int_ref &, enum machine_mode);
#endif
#if TARGET_SUPPORTS_WIDE_INT == 0
extern rtx immed_double_const (HOST_WIDE_INT, HOST_WIDE_INT,
Index: gcc/tree-ssa-ccp.c
===
--- gcc/tree-ssa-ccp.c 2014-04-24 08:30:16.191670326 +0100
+++ gcc/tree-ssa-ccp.c 2014-04-24 08:30:19.118694976 +0100
@@ -218,7 +218,8 @@ dump_lattice_value (FILE *outf, const ch
}
else
{
- wide_int cval = wi::bit_and_not (wi::to_widest (val.value), val.mask);
+ widest_int cval = wi::bit_and_not (wi::to_widest (val.value),
+val.mask);
fprintf (outf, "%sCONSTANT ", prefix);
print_hex (cval, outf);
fprintf (outf, " (");
@@ -1249,7 +1250,7 @@ bit_value_binop_1 (enum tree_code code,
case RROTATE_EXPR:
if (r2mask == 0)
{
- wide_int shift = r2val;
+ widest_int shift = r2val;
if (shift == 0)
{
*mask = r1mask;
@@ -1286,7 +1287,7 @@ bit_value_binop_1 (enum tree_code code,
is zero. */
if (r2mask == 0)
{
- wide_int shift = r2val;
+ widest_int shift = r2val;
if (shift == 0)
{
*mask = r1mask;
Index: gcc/tree-vrp.c
===
--- gcc/tree-vrp.c 2014-04-24 08:30:16.191670326 +0100
+++ gcc/tree-vrp.c 2014-04-24 08:30:19.119694985 +0100
@@ -3860,7 +3860,8 @@ adjust_range_with_scev (value_range_t *v
signop sgn = TYPE_SIGN (TREE_TYPE (step));
bool overflow;
- wide_int wtmp = wi::mul (wi::to_widest (step), nit, sgn, &overflow);
+ widest_int wtmp = wi::mul (wi::to_widest (step), nit, sgn,
+&overflow);
/* If the multiplication overflowed we can't do a meaningful
adjustment. Likewise if the result doesn't fit in the type
of the induction variable. For a signed type we have to
Index: gcc/wide-int-print.cc
===
--- gcc/wide-int-print.cc 2014-04-24 08:30:16.191670326 +0100
+++ gcc/wide-int-print.cc 2014-04-24 08:30:19.120694993 +0100
@@ -34,7 +34,7 @@ along with GCC; see the file COPYING3.
(((PREC) + HOST_BITS_PER_WIDE_I
Re: [PATCH] Adjust hoist-register-pressure* testcases to work for S/390
On 04/10/14 02:00, Andreas Krebbel wrote: Hi, the hoist-register-pressure testcases currently fail on S/390 since the rtl hoist pass requires that the expression to be hoisted can be assigned without clobbering cc. We do not have a 32 bit add which does not clobber cc. On 64 bit we might use load address if the operands are DImode. On 31 bit we are out of luck. The attached patch turns the int types into long for these testcases and disables them for s390 31bit. I've verified that they still succeed on power and x86_64. Ok? Bye, -Andreas- 2014-04-10 Andreas Krebbel * gcc.dg/hoist-register-pressure-1.c: Replace int with long. Disable asm scan for s390. * gcc.dg/hoist-register-pressure-2.c: Likewise. * gcc.dg/hoist-register-pressure-3.c: Likewise. OK for the trunk. Thanks, Jeff
Re: [wide-int, committed] Obvious s390 build fix
On Apr 24, 2014, at 2:45 PM, Richard Sandiford wrote: > I committed this patch as obvious to fix the s390 build. Looks good, thanks.
Re: [PATCH] Add a couple of dialect and warning options regarding Objective-C instance variable scope
On 04/24/2014 07:00 PM, Mike Stump wrote: On Feb 6, 2014, at 1:25 AM, Dimitris Papavasiliou wrote: This is a patch regarding a couple of Objective-C related dialect options and warning switches. Ok. Committed revision 209753. If you could, please add documentation and a test case. Thanks for taking the time to look at this, although to be honest I didn't expect a straight merge into the trunk. This patch was made quite a few months ago but since your were able to apply it without problems I suppose it was still up-to-date. I took a look at the applied changes and everything seems to be ok. I'll add documentation and test cases as soon as I figure out how. Dimitris
Re: [PING^8][PATCH] Add a couple of dialect and warning options regarding Objective-C instance variable scope
On 04/24/2014 11:17 PM, Jakub Jelinek wrote: How has this been tested? I'm seeing: +FAIL: obj-c++.dg/local-decl-1.mm -fgnu-runtime (test for warnings, line 39) +FAIL: obj-c++.dg/local-decl-1.mm -fgnu-runtime (test for warnings, line 41) +FAIL: obj-c++.dg/private-2.mm -fgnu-runtime (test for warnings, line 32) +FAIL: obj-c++.dg/private-2.mm -fgnu-runtime (test for warnings, line 33) +FAIL: obj-c++.dg/private-2.mm -fgnu-runtime (test for warnings, line 34) +FAIL: obj-c++.dg/private-2.mm -fgnu-runtime (test for warnings, line 53) +FAIL: obj-c++.dg/private-2.mm -fgnu-runtime (test for warnings, line 54) +FAIL: objc.dg/local-decl-1.m -fgnu-runtime (test for warnings, line 23) +FAIL: objc.dg/local-decl-2.m -fgnu-runtime (test for warnings, line 37) +FAIL: objc.dg/local-decl-2.m -fgnu-runtime (test for warnings, line 39) +FAIL: objc.dg/private-2.m -fgnu-runtime (test for warnings, line 30) +FAIL: objc.dg/private-2.m -fgnu-runtime (test for warnings, line 31) +FAIL: objc.dg/private-2.m -fgnu-runtime (test for warnings, line 32) +FAIL: objc.dg/private-2.m -fgnu-runtime (test for warnings, line 51) +FAIL: objc.dg/private-2.m -fgnu-runtime (test for warnings, line 52) regressions compared to a bootstrap/regtest from a few hours ago on i686-linux (x86_64-linux still regtesting, but the objc.dg/ failures can be seen in the logs already). Jakub These failures are due to the fact that the patch made -Wshadow control the warnings related to instance variable hiding. These were before "enabled by default" although they were clearly cases of variable shadowing. If the old behavior is considered preferable I can easily make a patch to revert to it. Otherwise I can try to update these tests by getting them to run with -Wshadow. Dimitris
Re: version typeinfo for 128bit types
On 24/04/14 20:03 +0200, Marc Glisse wrote: Grep seems to indicate that the manual is the only other place that needs updating, but that can wait. Is this patch ok, assuming the tests pass? OK, and sorry for forgetting about that file in the testsuite!
[PATCH] A new reload-rewrite pattern recognizer for GCC vectorizer.
In this patch a new reload-rewrite pattern detector is composed to
handle the following pattern in the loop being vectorized:
x = *p;
...
y = *p;
or
*p = x;
...
y = *p;
In both cases, *p is reloaded because there may exist other defs to
another memref that may alias with p. However, aliasing is eliminated
with alias checks. Then we can safely replace the last statement in
above cases by y = x.
The following rewrite pattern is also detected:
*p = x;
...
*p = y;
The first write is redundant due to the fact that there is no aliasing
between p and other pointers. In this case we don't need to vectorize
this write. Here we replace it with a dummy statement z = x.
Bootstrapped and tested on x86-64.
OK for trunk?
thanks,
Cong
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 117cdd0..59a4388 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,10 @@
+2014-04-23 Cong Hou
+
+ * tree-vect-patterns.c (vect_recog_reload_rewrite_pattern):
+ New function.
+ (vect_vect_recog_func_ptrs): Add new pattern.
+ * tree-vectorizer.h (NUM_PATTERNS): Update the pattern count.
+
2014-04-23 David Malcolm
* is-a.h: Update comments to reflect the following changes to the
diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
index 62b07f4..2116cd3 100644
--- a/gcc/testsuite/ChangeLog
+++ b/gcc/testsuite/ChangeLog
@@ -1,3 +1,7 @@
+2014-04-23 Cong Hou
+
+ * gcc.dg/vect/vect-reload-rewrite-pattern.c: New test.
+
2014-04-23 Jeff Law
PR tree-optimization/60902
diff --git a/gcc/testsuite/gcc.dg/vect/vect-reload-rewrite-pattern.c
b/gcc/testsuite/gcc.dg/vect/vect-reload-rewrite-pattern.c
new file mode 100644
index 000..e75f969
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/vect/vect-reload-rewrite-pattern.c
@@ -0,0 +1,61 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target vect_int } */
+
+#define N 1000
+int a[N];
+
+void test1 (int *b, int *c)
+{
+ int i;
+ for (i = 0; i < N; ++i)
+{
+ a[i] = c[i];
+ /* Reload of c[i]. */
+ b[i] = c[i];
+}
+}
+
+void test2 (int *b, int *c)
+{
+ int i;
+ for (i = 0; i < N; ++i)
+{
+ c[i] = a[i] + 10;
+ /* Reload of a[i]. */
+ a[i]++;
+ /* Reload of c[i]. */
+ b[i] = c[i];
+}
+}
+
+void test3 (int *b, int *c)
+{
+ int i;
+ for (i = 0; i < N; ++i)
+{
+ c[i] = a[i] & 63;
+ /* Reload of a[i]. */
+ a[i]++;
+ /* Reload of c[i]. */
+ /* Rewrite to c[i]. */
+ c[i]--;
+}
+}
+
+void test4 (_Complex int *b, _Complex int *c, _Complex int *d)
+{
+ int i;
+ for (i = 0; i < N; ++i)
+{
+ b[i] = c[i] + d[i];
+ /* Reload of REALPART_EXPR (c[i]). */
+ /* Reload of IMAGPART_EXPR (c[i]). */
+ /* Reload of REALPART_EXPR (d[i]). */
+ /* Reload of IMAGPART_EXPR (d[i]). */
+ c[i] = c[i] - d[i];
+}
+}
+
+/* { dg-final { scan-tree-dump-times "vectorized 1 loops" 4 "vect"} } */
+/* { dg-final { scan-tree-dump-times "vect_recog_reload_rewrite_pattern:
detected" 10 "vect" } } */
+/* { dg-final { cleanup-tree-dump "vect" } } */
diff --git a/gcc/tree-vect-patterns.c b/gcc/tree-vect-patterns.c
index 5daaf24..38a0fec 100644
--- a/gcc/tree-vect-patterns.c
+++ b/gcc/tree-vect-patterns.c
@@ -40,6 +40,7 @@ along with GCC; see the file COPYING3. If not see
#include "ssa-iterators.h"
#include "stringpool.h"
#include "tree-ssanames.h"
+#include "tree-ssa-sccvn.h"
#include "cfgloop.h"
#include "expr.h"
#include "optabs.h"
@@ -70,6 +71,7 @@ static gimple vect_recog_divmod_pattern (vec *,
static gimple vect_recog_mixed_size_cond_pattern (vec *,
tree *, tree *);
static gimple vect_recog_bool_pattern (vec *, tree *, tree *);
+static gimple vect_recog_reload_rewrite_pattern (vec *, tree *, tree
*);
static vect_recog_func_ptr vect_vect_recog_func_ptrs[NUM_PATTERNS] = {
vect_recog_widen_mult_pattern,
vect_recog_widen_sum_pattern,
@@ -81,6 +83,7 @@ static vect_recog_func_ptr
vect_vect_recog_func_ptrs[NUM_PATTERNS] = {
vect_recog_vector_vector_shift_pattern,
vect_recog_divmod_pattern,
vect_recog_mixed_size_cond_pattern,
+ vect_recog_reload_rewrite_pattern,
vect_recog_bool_pattern};
static inline void
@@ -3019,6 +3022,160 @@ vect_recog_bool_pattern (vec *stmts, tree
*type_in,
return NULL;
}
+/* Function vect_recog_reload_rewrite_pattern
+
+ Try to find the following reload pattern:
+
+ x = *p;
+ ...
+ y = *p;
+
+ or
+
+ *p = x;
+ ...
+ y = *p;
+
+ In both cases, *p is reloaded because there may exist other defs to another
+ memref that may alias with p. However, aliasing is eliminated with alias
+ checks. Then we can safely replace the last statement in above cases by
+ y = x.
+
+ Also try to detect rewrite pattern:
+
+ *p = x;
+ ...
+ *p = y;
+
+ The first write is redundant due to the fact that there is no aliasing
+ b
Re: [PING^8][PATCH] Add a couple of dialect and warning options regarding Objective-C instance variable scope
On Apr 24, 2014, at 4:16 PM, Dimitris Papavasiliou wrote: > On 04/24/2014 11:17 PM, Jakub Jelinek wrote: >> How has this been tested? >> >> I'm seeing: >> >> +FAIL: obj-c++.dg/local-decl-1.mm -fgnu-runtime (test for warnings, line 39) >> +FAIL: obj-c++.dg/local-decl-1.mm -fgnu-runtime (test for warnings, line 41) >> +FAIL: obj-c++.dg/private-2.mm -fgnu-runtime (test for warnings, line 32) >> +FAIL: obj-c++.dg/private-2.mm -fgnu-runtime (test for warnings, line 33) >> +FAIL: obj-c++.dg/private-2.mm -fgnu-runtime (test for warnings, line 34) >> +FAIL: obj-c++.dg/private-2.mm -fgnu-runtime (test for warnings, line 53) >> +FAIL: obj-c++.dg/private-2.mm -fgnu-runtime (test for warnings, line 54) >> +FAIL: objc.dg/local-decl-1.m -fgnu-runtime (test for warnings, line 23) >> +FAIL: objc.dg/local-decl-2.m -fgnu-runtime (test for warnings, line 37) >> +FAIL: objc.dg/local-decl-2.m -fgnu-runtime (test for warnings, line 39) >> +FAIL: objc.dg/private-2.m -fgnu-runtime (test for warnings, line 30) >> +FAIL: objc.dg/private-2.m -fgnu-runtime (test for warnings, line 31) >> +FAIL: objc.dg/private-2.m -fgnu-runtime (test for warnings, line 32) >> +FAIL: objc.dg/private-2.m -fgnu-runtime (test for warnings, line 51) >> +FAIL: objc.dg/private-2.m -fgnu-runtime (test for warnings, line 52) >> >> regressions compared to a bootstrap/regtest from a few hours ago on >> i686-linux (x86_64-linux still regtesting, but the objc.dg/ failures >> can be seen in the logs already). >> >> Jakub >> > > These failures are due to the fact that the patch made -Wshadow control the > warnings related to instance variable hiding. These were before "enabled by > default" although they were clearly cases of variable shadowing. So, in general, to contribute patches, you will want to run the test suite to ensure quality. We don’t want to remove warnings without good reason… so I’m defaulting them back to on. In your text, you didn’t seem to cover this, other than to note what we do and to say some might want to turn them off. Now, if clang turned them off by default, we can go that way, but I’d like to maintain users expectations of those on. I’m anticipating they have them on by default still. Index: gcc/c-family/c.opt === --- gcc/c-family/c.opt (revision 209755) +++ gcc/c-family/c.opt (working copy) @@ -685,7 +685,7 @@ ObjC ObjC++ Var(warn_selector) Warning Warn if a selector has multiple methods Wshadow-ivar -ObjC ObjC++ Var(warn_shadow_ivar) Init(-1) Warning +ObjC ObjC++ Var(warn_shadow_ivar) Init(1) Warning Warn if a local declaration hides an instance variable Wsequence-point Committed revision 209774. Thanks Jakub for pointing it out.
Re: [PATCH] Add a couple of dialect and warning options regarding Objective-C instance variable scope
On Apr 24, 2014, at 4:09 PM, Dimitris Papavasiliou wrote:
> On 04/24/2014 07:00 PM, Mike Stump wrote:
>> On Feb 6, 2014, at 1:25 AM, Dimitris Papavasiliou wrote:
>>> This is a patch regarding a couple of Objective-C related dialect options
>>> and warning switches.
>>
>> Ok.
>>
>> Committed revision 209753.
>>
>> If you could, please add documentation and a test case.
>
> Thanks for taking the time to look at this, although to be honest I didn't
> expect a straight merge into the trunk.
Don’t submit changes you don’t want! :-)
> I'll add documentation and test cases as soon as I figure out how.
Just copy testsuite/objc.dg/private-2.m into shadow-1.m and then `fix’ it to
test what you want. If you need one with and one without a flag, copy it twice
and use something like:
// { dg-options "-Wshadow" }
on it. Type make RUNTESTFLAGS=dg.exp=shadow-1.m check-objc to test it.
For the doc, just find a simple option in the part of the manual you want to
put it in, and copy it. We document the non-default, (Wno-shadow-ivar for
example) options.
Re: [PATCH] Fix PR60930
On 04/24/14 10:20, Bill Schmidt wrote: Hi, PR60930 exposes an SLSR problem with a fold. When multiplying two constants to create a new stride, the result must fit in the stride type for the computation or the fold is invalid. Bootstrapped and tested on powerpc64le-unknown-linux-gnu with no regressions. The same patch applies equally to 4.8, 4.9, and trunk. Is this ok for trunk (and for 4.8/4.9 after a suitable burn-in period)? Thanks, Bill [gcc] 2014-04-24 Bill Schmidt PR tree-optimization/60930 * gimple-ssa-strength-reduction.c (create_mul_imm_cand): Reject creating a multiply candidate by folding two constant multiplicands when the result overflows. [gcc/testsuite] 2014-04-24 Bill Schmidt PR tree-optimization/60930 * gcc.dg/torture/pr60930.c: New test. Doesn't the test depend on long long being at least 64 bits? What we've done for these kinds of tests in the past is: if (sizeof (whatever) < needed size) exit (0); Another approach would be to use an effective target test and skip the test if the target doesn't have a suitable long long. Look in testsuite/lib/target-supports.exp for the various target characteristics you can test for. If you go this route you'd create pr60930.x which skips the test. There's several examples you can use to guide you. With the testcase fixed, this is OK. jeff
[patch, toplevel] configure nios2-elf libraries to build with -mno-gpopt
People are now starting to build quite large programs for nios2-elf and
are running into problems with the small data section getting too large
to be entirely within range for GP-relative addressing with a 16-bit
offset. This architecture doesn't have an indirect addressing mode with
32-bit offsets and doing halfword loads to construct a 32-bit constant
offset with an explicit GP add would be less efficient than a direct
reference to the object residing in the small data section, which is
what -mno-gpopt does.
The range overflow problem is more likely to affect libraries than user
code because of the normal linker allocation strategy, so telling users
to build their code with -mno-gpopt is not terribly helpful in many
cases -- the libraries have to be built with -mno-gpopt, too. That's
what this patch does. It's similar to what is already being done for
mips-sde-elf (see config/mt-sde, in particular).
Altera has identified this as an important fix for their users. After
discussion, we decided a a similar hack for nios2-linux-gnu targets
isn't necessary because most people link against shared libraries instead.
I understand that this patch, although target-specific, needs to be
approved by a global reviewer and then propagated to the sourceware.org
binutils-gdb and newlib repositories as well. So, OK to commit?
-Sandra
2014-04-24 Sandra Loosemore
* configure.ac (target_makefile_frag): Set for nios2-*-elf*.
* configure: Regenerated.
config/
* mt-nios2-elf: New file.
Index: configure.ac
===
--- configure.ac (revision 209669)
+++ configure.ac (working copy)
@@ -2370,6 +2370,9 @@ case "${target}" in
mips*-*-*linux* | mips*-*-gnu*)
target_makefile_frag="config/mt-mips-gnu"
;;
+ nios2-*-elf*)
+target_makefile_frag="config/mt-nios2-elf"
+;;
*-*-linux* | *-*-gnu* | *-*-k*bsd*-gnu | *-*-kopensolaris*-gnu)
target_makefile_frag="config/mt-gnu"
;;
Index: config/mt-nios2-elf
===
--- config/mt-nios2-elf (revision 0)
+++ config/mt-nios2-elf (revision 0)
@@ -0,0 +1,5 @@
+# We build library code with -mno-gpopt so that it can be linked with
+# larger executables with small-data sections that exceed the 16-bit
+# offset range for GP-relative addressing.
+CFLAGS_FOR_TARGET += -mno-gpopt
+CXXFLAGS_FOR_TARGET += -mno-gpopt
Index: configure
===
--- configure (revision 209669)
+++ configure (working copy)
@@ -6992,6 +6992,9 @@ case "${target}" in
mips*-*-*linux* | mips*-*-gnu*)
target_makefile_frag="config/mt-mips-gnu"
;;
+ nios2-*-elf*)
+target_makefile_frag="config/mt-nios2-elf"
+;;
*-*-linux* | *-*-gnu* | *-*-k*bsd*-gnu | *-*-kopensolaris*-gnu)
target_makefile_frag="config/mt-gnu"
;;
libgo patch committed: Fix madvise on systems with page size != 4096
This patch from Anton Blanchard fixes libgo to adjust to the system page
size when calling madvise. Bootstrapped and ran Go testsuite on
x86_64-unknown-linux-gnu. Committed to mainline and 4.9 branch.
Ian
diff -r 3a53301d24d7 libgo/runtime/mheap.c
--- a/libgo/runtime/mheap.c Tue Apr 22 16:43:35 2014 -0700
+++ b/libgo/runtime/mheap.c Thu Apr 24 21:18:35 2014 -0700
@@ -387,7 +387,7 @@
static uintptr
scavengelist(MSpan *list, uint64 now, uint64 limit)
{
- uintptr released, sumreleased;
+ uintptr released, sumreleased, start, end, pagesize;
MSpan *s;
if(runtime_MSpanList_IsEmpty(list))
@@ -400,7 +400,17 @@
mstats.heap_released += released;
sumreleased += released;
s->npreleased = s->npages;
- runtime_SysUnused((void*)(s->start << PageShift), s->npages << PageShift);
+
+ start = s->start << PageShift;
+ end = start + (s->npages << PageShift);
+
+ // Round start up and end down to ensure we
+ // are acting on entire pages.
+ pagesize = getpagesize();
+ start = ROUND(start, pagesize);
+ end &= ~(pagesize - 1);
+ if(end > start)
+runtime_SysUnused((void*)start, end - start);
}
}
return sumreleased;
Re: [PATCH] Fix PR60930
On Thu, Apr 24, 2014 at 09:20:50PM -0600, Jeff Law wrote: > > PR tree-optimization/60930 > > * gcc.dg/torture/pr60930.c: New test. > Doesn't the test depend on long long being at least 64 bits? But that is guaranteed by C99, isn't it? 5.2.4.2.1 says: ... Their implementation-defined values shall be equal or greater in magnitude (absolute value) to those shown, with the same sign. ... - maximum value for an object of type unsigned long long int ULLONG_MAX 18446744073709551615 // 2 64 − 1 > > What we've done for these kinds of tests in the past is: > > if (sizeof (whatever) < needed size) > exit (0); > > Another approach would be to use an effective target test and skip > the test if the target doesn't have a suitable long long. Look in > testsuite/lib/target-supports.exp for the various target If it was some other type, sure, one could use int32plus, lp64, etc. target, or #if __SIZEOF_type__ == ... Jakub
[libcpp] use CPP_PEDANTIC
Use macro CPP_PEDANTIC (PF) instead of directly using
it's definition: CPP_OPTION (PF, cpp_pedantic).
[libcpp]
* directives.c (_cpp_handle_directive): Use CPP_PEDANTIC macro.
* macro.c (parse_params): Likewise.
Bootstrapped on x86_64-unknown-linux-gnu.
OK for trunk ?
Thanks and Regards,
Prathamesh
Index: libcpp/directives.c
===
--- libcpp/directives.c (revision 209778)
+++ libcpp/directives.c (working copy)
@@ -403,7 +403,7 @@ _cpp_handle_directive (cpp_reader *pfile
if (was_parsing_args)
{
- if (CPP_OPTION (pfile, cpp_pedantic))
+ if (CPP_PEDANTIC (pfile))
cpp_error (pfile, CPP_DL_PEDWARN,
"embedding a directive within macro arguments is not portable");
pfile->state.parsing_args = 0;
Index: libcpp/macro.c
===
--- libcpp/macro.c (revision 209778)
+++ libcpp/macro.c (working copy)
@@ -2794,13 +2794,13 @@ parse_params (cpp_reader *pfile, cpp_mac
pfile->spec_nodes.n__VA_ARGS__);
pfile->state.va_args_ok = 1;
if (! CPP_OPTION (pfile, c99)
- && CPP_OPTION (pfile, cpp_pedantic)
+ && CPP_PEDANTIC (pfile)
&& CPP_OPTION (pfile, warn_variadic_macros))
cpp_pedwarning
(pfile, CPP_W_VARIADIC_MACROS,
"anonymous variadic macros were introduced in C99");
}
- else if (CPP_OPTION (pfile, cpp_pedantic)
+ else if (CPP_PEDANTIC (pfile)
&& CPP_OPTION (pfile, warn_variadic_macros))
cpp_pedwarning (pfile, CPP_W_VARIADIC_MACROS,
"ISO C does not permit named variadic macros");
[Ping][Patch, GCC/Thumb1] Improve 64bit constant load for Thumb1
Ping ... BR, Terry > -Original Message- > From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches- > ow...@gcc.gnu.org] On Behalf Of Terry Guo > Sent: Friday, April 11, 2014 3:36 PM > To: gcc-patches@gcc.gnu.org > Cc: Richard Earnshaw; Ramana Radhakrishnan > Subject: [Patch, GCC/Thumb1] Improve 64bit constant load for Thumb1 > > Hi there, > > Current gcc prefers to using two LDR instructions to load 64bit constants. > This could miss some chances that 64bit load can be done in fewer > instructions or fewer cycles. For example, below code to load 0x10001 > > mov r0, #1 > mov r1, #1 > > is better than current solution: > > ldr r1, .L2+4 > ldr r0, .L2 > .L2: > .word 1 > .word 1 > > The attached patch intends to split 64bit load to take advantage of such > chances. Tested with gcc regression test on cortex-m0. No new regressions. > > Is it ok to stage 1? > > BR, > Terry > > gcc/ > 2014-04-11 Terry Guo > > * config/arm/arm.md (split 64-bit constant for Thumb1): New split > pattern. > > gcc/testsuite/ > 2014-04-11 Terry Guo > > * gcc.target/arm/thumb1-load-64bit-constant-1.c: New test. > * gcc.target/arm/thumb1-load-64bit-constant-2.c: Ditto. > * gcc.target/arm/thumb1-load-64bit-constant-3.c: Ditto.
Re: Add call_fusage_contains_non_callee_clobbers hook
On 23-04-14 17:10, Richard Sandiford wrote:
FWIW I think this should be a plain bool rather than a function,
like delay_sched2 etc.
Vladimir,
I've reimplemented the hook using DEFHOOKPOD instead of DEFHOOK, to make it a
plain bool.
OK for trunk?
Thanks,
- Tom
2013-04-29 Radovan Obradovic
Tom de Vries
* target.def (call_fusage_contains_non_callee_clobbers): New DEFHOOKPOD.
* doc/tm.texi.in (@node Stack and Calling): Add Miscellaneous Register
Hooks to @menu.
(@node Miscellaneous Register Hooks): New node.
(@hook TARGET_CALL_FUSAGE_CONTAINS_NON_CALLEE_CLOBBERS): New hook.
* doc/tm.texi: Regenerate.
diff --git a/gcc/doc/tm.texi b/gcc/doc/tm.texi
index b8ca17e..f06113d 100644
--- a/gcc/doc/tm.texi
+++ b/gcc/doc/tm.texi
@@ -3091,6 +3091,7 @@ This describes the stack layout and calling conventions.
* Profiling::
* Tail Calls::
* Stack Smashing Protection::
+* Miscellaneous Register Hooks::
@end menu
@node Frame Layout
@@ -5016,6 +5017,21 @@ normally defined in @file{libgcc2.c}.
Whether this target supports splitting the stack when the options described in @var{opts} have been passed. This is called after options have been parsed, so the target may reject splitting the stack in some configurations. The default version of this hook returns false. If @var{report} is true, this function may issue a warning or error; if @var{report} is false, it must simply return a value
@end deftypefn
+@node Miscellaneous Register Hooks
+@subsection Miscellaneous register hooks
+@cindex miscellaneous register hooks
+
+@deftypevr {Target Hook} bool TARGET_CALL_FUSAGE_CONTAINS_NON_CALLEE_CLOBBERS
+set to true if all the calls in the current function contain clobbers in
+CALL_INSN_FUNCTION_USAGE for the registers that are clobbered by the call
+rather than by the callee, and are not already set or clobbered in the call
+pattern. Examples of such registers are registers used in PLTs and stubs,
+and temporary registers used in the call instruction but not present in the
+rtl pattern. Another way to formulate it is the registers not present in the
+rtl pattern that are clobbered by the call assuming the callee does not
+clobber any register. The default version of this hook is set to false.
+@end deftypevr
+
@node Varargs
@section Implementing the Varargs Macros
@cindex varargs implementation
diff --git a/gcc/doc/tm.texi.in b/gcc/doc/tm.texi.in
index d793d26..8991c3c 100644
--- a/gcc/doc/tm.texi.in
+++ b/gcc/doc/tm.texi.in
@@ -2720,6 +2720,7 @@ This describes the stack layout and calling conventions.
* Profiling::
* Tail Calls::
* Stack Smashing Protection::
+* Miscellaneous Register Hooks::
@end menu
@node Frame Layout
@@ -3985,6 +3986,12 @@ the function prologue. Normally, the profiling code comes after.
@hook TARGET_SUPPORTS_SPLIT_STACK
+@node Miscellaneous Register Hooks
+@subsection Miscellaneous register hooks
+@cindex miscellaneous register hooks
+
+@hook TARGET_CALL_FUSAGE_CONTAINS_NON_CALLEE_CLOBBERS
+
@node Varargs
@section Implementing the Varargs Macros
@cindex varargs implementation
diff --git a/gcc/target.def b/gcc/target.def
index 3a64cd1..5787e13 100644
--- a/gcc/target.def
+++ b/gcc/target.def
@@ -5130,6 +5130,22 @@ FRAME_POINTER_REGNUM, ARG_POINTER_REGNUM, and the PIC_OFFSET_TABLE_REGNUM.",
void, (bitmap regs),
hook_void_bitmap)
+/* Targets should define this target hook to mark that non-callee clobbers are
+ present in CALL_INSN_FUNCTION_USAGE for all the calls in the current
+ function. */
+DEFHOOKPOD
+(call_fusage_contains_non_callee_clobbers,
+ "set to true if all the calls in the current function contain clobbers in\n\
+CALL_INSN_FUNCTION_USAGE for the registers that are clobbered by the call\n\
+rather than by the callee, and are not already set or clobbered in the call\n\
+pattern. Examples of such registers are registers used in PLTs and stubs,\n\
+and temporary registers used in the call instruction but not present in the\n\
+rtl pattern. Another way to formulate it is the registers not present in the\n\
+rtl pattern that are clobbered by the call assuming the callee does not\n\
+clobber any register. The default version of this hook is set to false.",
+ bool,
+ false)
+
/* Fill in additional registers set up by prologue into a regset. */
DEFHOOK
(set_up_by_prologue,
[Patch] Fix a typo in Chinese msg
There is a minor typo in zh_CN.po, should change '-pic' to '-fpic'. Best wishes, Jincheng Miao Index: gcc/po/zh_CN.po === --- gcc/po/zh_CN.po (revision 209734) +++ gcc/po/zh_CN.po (working copy) @@ -24308,7 +24308,7 @@ msgstr "堆栈探针目前需要框架æ #: config/i386/i386.c:4108 #, gcc-internal-format msgid "-mfentry isn%'t supported for 32-bit in combination with -fpic" -msgstr "-mfentry 在 32 位下不能和 -pic 同时使用" +msgstr "-mfentry 在 32 位下不能和 -fpic 同时使用" #: config/i386/i386.c:4115 #, gcc-internal-format
Re: [Patch]Simplify SUBREG with operand whose target bits are cleared by AND operation
On Mon, Apr 14, 2014 at 6:13 PM, Terry Guo wrote:
> On Thu, Apr 3, 2014 at 10:11 PM, Eric Botcazou wrote:
>>> I find the GCC function simplify_subreg fails to simplify rtx (subreg:SI
>>> (and:DI (reg/v:DI 115 [ a ]) (const_int 4294967295 [0x])) 4) to zero
>>> during the fwprop1 pass, considering the fact that the high 32-bit part of
>>> (a & 0x) is zero. This leads to some unnecessary multiplications
>>> for high 32-bit part of the result of AND operation. The attached patch is
>>> trying to improve simplify_rtx to handle such case. Other target like x86
>>> seems hasn't such issue because it generates different RTX to handle 64bit
>>> multiplication on a 32bit machine.
>>
>> See http://gcc.gnu.org/ml/gcc-patches/2013-05/msg00073.html for another try,
>> which led to the simplification in combine.c:combine_simplify_rtx line 5448.
>>
>> Your variant is both more general, because it isn't restricted to the
>> lowpart,
>> and less general, because it is artificially restricted to AND.
>>
>> Some remarks:
>> - this needs to be restricted to non-paradoxical subregs,
>> - you need to test HWI_COMPUTABLE_MODE_P (innermode),
>> - you need to test !side_effects_p (op).
>>
>> I think we need to find a common ground between Jakub's patch and yours and
>> put a single transformation in simplify_subreg.
>>
>> --
>> Eric Botcazou
>
> Thanks for your review. Even without Jakub's patch, the combine pass
> can simplify such subreg to zero. But the live range of destination
> register causes combine pass to undo all attempts. Here is detailed
> explanation, please note that the AND operation (and:DI (reg/v:DI 115
> [ a ]) (const_int 4294967295 [0x])) from fwprop1 pass is
> turned into ZERO_EXTEND operation (zero_extend:DI (reg:SI 0 r0 [ a ]))
> in combine pass. The variable a is function arguments and occupies
> register r0 and r1. Right before try_combine function we have below
> three instructions:
>
> (insn 8 4 10 2 (set (reg:DI 118 [ D.4091 ])
> (zero_extend:DI (reg:SI 0 r0 [ a ]))) 000.c:4 170 {zero_extendsidi2}
> (expr_list:REG_DEAD (reg:SI 0 r0)
> (nil)))
>
> (insn 10 8 13 2 (set (reg:SI 121)
> (mult:SI (reg/v:SI 116 [ b ])
> (subreg:SI (reg:DI 118 [ D.4091 ]) 4))) 000.c:4 41
> {*arm_mulsi3_v6}
> (nil))
>
> (insn 13 10 14 2 (set (reg:DI 117 [ D.4091 ])
> (mult:DI (zero_extend:DI (subreg:SI (reg:DI 118 [ D.4091 ]) 0))
> (zero_extend:DI (reg/v:SI 116 [ b ] 000.c:4 60 {*umulsidi3_v6}
> (expr_list:REG_DEAD (reg:DI 118 [ D.4091 ])
> (expr_list:REG_DEAD (reg/v:SI 116 [ b ])
> (nil
>
> Without any changes, current gcc can simplify the insn 10 to
>
> (insn 10 8 13 2 (set (reg:SI 121)
> (const_int 0 [0])) 000.c:4 41 {*arm_mulsi3_v6}
> (nil))
>
> This is what we wanted. Unfortunately the live range of register
> (reg:DI 118) is extended to insn 13. Thus unable to remove insn 8. The
> combine pass has to generate PARALLEL rtx to handle such case:
>
> (parallel [
> (set (reg:SI 121)
> (const_int 0 [0]))
> (set (reg:DI 118 [ D.4091 ])
> (zero_extend:DI (reg:SI 0 r0 [ a ])))
> ])
>
> There is no instruction patter to match this parallel rtx. This causes
> combine pass to undo all attempts and roll back simplification to
> subreg operand. Without such live range extension, everything works
> fine. That's why such optimization can only happen in fwprop1 pass.
>
> I made a typo in my previous changelog. My code are indeed for
> simplify_subreg function. I updated my patch per your suggestions to
> handle more general cases. Please review again. Thanks.
>
> BR,
> Terry
Hi Eric,
How do you think my above investigation? To put it simple, the combine
can optimize it to zero, but lately has to undo it because some
restrictions. Now I generalize my optimization to focus on things like
(subreg:mode (OP) index), then use function nonzero_bits to get bits
status of the result of OP. Once the bits expected by subreg are all
zero, we can optimize this whole subreg to zero. Does this make sense?
Please advise. Thanks.
BR,
Terry
Re: [PATCH][AArch64] Vectorise bswap[16,32,64]
On 16 April 2014 09:12, Kyrill Tkachov wrote:
> On 15/04/14 18:45, Eric Christopher wrote:
>>
>> Testcase weirdness?
>>
>>for (i < 0; i < N; ++i)
>> {
>>arr[i] = i;
>>expect[i] = __builtin_bswap64 (i);
>>if (y) /* Avoid vectorisation. */
>> abort ();
>> }
>>
>> i < 0 :)
>>
>> duplicated in all 3 testcases btw.
>
> Oops, here it is fixed.
>
> Thanks for catching this.
> Kyrill
Fixed version OK /Marcus
[PING][AArch64][4.8,4.9] Wire up TARGET_SIMD and TARGET_FLOAT properly
Hi all, I'd like to ping the two patches at: http://gcc.gnu.org/ml/gcc-patches/2014-04/msg00490.html and http://gcc.gnu.org/ml/gcc-patches/2014-04/msg00315.html They fix a bug in aarch64 and I think they should go into the release branches. Thanks, Kyrill
Re: [AArch64/ARM 1/3] Add execution + assembler tests of AArch64 TRN Intrinsics
On 28 March 2014 15:31, Alan Lawrence wrote: > This adds DejaGNU tests of the existing AArch64 vuzp_* intrinsics, both > checking > the assembler output and the runtime results. Test bodies are in separate > files > ready to reuse for ARM in the third patch. > > Putting these in a new subdirectory with the ZIP Intrinsics tests, using > simd.exp added there (will commit ZIP tests first). > > All tests passing on aarch64-none-elf and aarch64_be-none-elf. > > testsuite/ChangeLog: > 2012-03-28 Alan Lawrence > > * gcc.target/aarch64/simd/vtrnf32_1.c: New file. > * gcc.target/aarch64/simd/vtrnf32.x: New file. > * gcc.target/aarch64/simd/vtrnp16_1.c: New file. > * gcc.target/aarch64/simd/vtrnp16.x: New file. > * gcc.target/aarch64/simd/vtrnp8_1.c: New file. > * gcc.target/aarch64/simd/vtrnp8.x: New file. > * gcc.target/aarch64/simd/vtrnqf32_1.c: New file. > * gcc.target/aarch64/simd/vtrnqf32.x: New file. > * gcc.target/aarch64/simd/vtrnqp16_1.c: New file. > * gcc.target/aarch64/simd/vtrnqp16.x: New file. > * gcc.target/aarch64/simd/vtrnqp8_1.c: New file. > * gcc.target/aarch64/simd/vtrnqp8.x: New file. > * gcc.target/aarch64/simd/vtrnqs16_1.c: New file. > * gcc.target/aarch64/simd/vtrnqs16.x: New file. > * gcc.target/aarch64/simd/vtrnqs32_1.c: New file. > * gcc.target/aarch64/simd/vtrnqs32.x: New file. > * gcc.target/aarch64/simd/vtrnqs8_1.c: New file. > * gcc.target/aarch64/simd/vtrnqs8.x: New file. > * gcc.target/aarch64/simd/vtrnqu16_1.c: New file. > * gcc.target/aarch64/simd/vtrnqu16.x: New file. > * gcc.target/aarch64/simd/vtrnqu32_1.c: New file. > * gcc.target/aarch64/simd/vtrnqu32.x: New file. > * gcc.target/aarch64/simd/vtrnqu8_1.c: New file. > * gcc.target/aarch64/simd/vtrnqu8.x: New file. > * gcc.target/aarch64/simd/vtrns16_1.c: New file. > * gcc.target/aarch64/simd/vtrns16.x: New file. > * gcc.target/aarch64/simd/vtrns32_1.c: New file. > * gcc.target/aarch64/simd/vtrns32.x: New file. > * gcc.target/aarch64/simd/vtrns8_1.c: New file. > * gcc.target/aarch64/simd/vtrns8.x: New file. > * gcc.target/aarch64/simd/vtrnu16_1.c: New file. > * gcc.target/aarch64/simd/vtrnu16.x: New file. > * gcc.target/aarch64/simd/vtrnu32_1.c: New file. > * gcc.target/aarch64/simd/vtrnu32.x: New file. > * gcc.target/aarch64/simd/vtrnu8_1.c: New file. > * gcc.target/aarch64/simd/vtrnu8.x: New file. OK /Marcus
Re: [AArch64/ARM 2/3] Reimplement AArch64 TRN intrinsics with __builtin_shuffle
On 28 March 2014 15:36, Alan Lawrence wrote: > This patch replaces the temporary inline assembler for vtrn[q]_* in > arm_neon.h with equivalent calls to __builtin_shuffle. These are matched by > existing patterns in aarch64.c (aarch64_expand_vec_perm_const_1), outputting > the same assembler instructions. For two-element vectors, ZIP, UZP and TRN > instructions all have the same effect, and the backend chooses to output > ZIP, so this patch also updates the 3 affected tests. > > Regressed, and tests from first patch still passing modulo updates herein, > on > aarch64-none-elf and aarch64_be-none-elf. > > gcc/testsuite/ChangeLog: > 2014-03-28 Alan Lawrence > > * gcc.target/aarch64/vtrns32.c: Expect zip[12] insn rather than > trn[12]. > * gcc.target/aarch64/vtrnu32.c: Likewise. > * gcc.target/aarch64/vtrnf32.c: Likewise. > > gcc/ChangeLog: > 2014-03-28 Alan Lawrence > > * config/aarch64/arm_neon.h (vtrn1_f32, vtrn1_p8, vtrn1_p16, > vtrn1_s8, > vtrn1_s16, vtrn1_s32, vtrn1_u8, vtrn1_u16, vtrn1_u32, vtrn1q_f32, > vtrn1q_f64, vtrn1q_p8, vtrn1q_p16, vtrn1q_s8, vtrn1q_s16, > vtrn1q_s32, > vtrn1q_s64, vtrn1q_u8, vtrn1q_u16, vtrn1q_u32, vtrn1q_u64, > vtrn2_f32, > vtrn2_p8, vtrn2_p16, vtrn2_s8, vtrn2_s16, vtrn2_s32, vtrn2_u8, > vtrn2_u16, vtrn2_u32, vtrn2q_f32, vtrn2q_f64, vtrn2q_p8, vtrn2q_p16, > vtrn2q_s8, vtrn2q_s16, vtrn2q_s32, vtrn2q_s64, vtrn2q_u8, > vtrn2q_u16, > vtrn2q_u32, vtrn2q_u64): Replace temporary asm with > __builtin_shuffle. OK /Marcus
Re: [PATCH][AArch64] Wire up TARGET_SIMD and TARGET_FLOAT properly
On 7 April 2014 14:46, Kyrill Tkachov wrote: > 2014-04-04 Kyrylo Tkachov > > * config/aarch64/aarch64.h (TARGET_CPU_CPP_BUILTINS): Check > TARGET_SIMD rather than TARGET_GENERAL_REGS_ONLY. > (TARGET_SIMD): Take AARCH64_ISA_SIMD into account. > (TARGET_FLOAT): Take AARCH64_ISA_FP into account. > (TARGET_CRYPTO): Take TARGET_SIMD into account. OK for trunk. This will need to go on 4.9, please wait a week before applying the back port. /Marcus
[PATCH] Fix web/60933
The GMP people complained that we "advertise" outdated versions
in our install instructions. I tried to address that by not
explicitely listing a "good" version but only mention the version
that is the minimum requirement. I also added a reference to
contrib/download_prerequesites as the recommended way to do
in-tree builds (so we don't get random bugreports for that
with untested combinations of gmp/mpfr/mpc versions).
We probably should try to bump the versions used by that script
to something more recent though (should we do that for the 4.9
branch even?). Any idea what to choose here? I'd say mpc
1.0.2 is fine, so is mpfr 3.1.2, but should we avoid the 6.0.0 version
of gmp? We shouldn't change those versions too often, otherwise
we end up with a lot of garbage in gcc/infrastructure (we don't
want to break old versions of the script).
Meanwhile is does the patch look ok?
Thanks,
Richard.
2014-04-24 Richard Biener
PR web/60933
* doc/install.texi: Mention download_prerequesites as the
recommended way to setup in-tree builds of gmp, mpfr, mpc,
cloog and isl. Do not advertise outdated versions of gmp,
mpfr and mpc.
Index: gcc/doc/install.texi
===
--- gcc/doc/install.texi(revision 209677)
+++ gcc/doc/install.texi(working copy)
@@ -351,32 +351,41 @@ versions may work in some cases, but it'
versions documented. We appreciate bug reports about problems with
newer versions, though. If your OS vendor provides packages for the
support libraries then using those packages may be the simplest way to
-install the libraries.
+install the libraries. If you choose to build the library dependencies
+together with GCC you are encouraged to use the
+@command{download_prerequesites} script that comes with the GCC
+source tarball in the @file{contrib} directory.
+This downloads versions that were tested to build and
+work ok and prepares the source tree appropriately.
@table @asis
-@item GNU Multiple Precision Library (GMP) version 4.3.2 (or later)
+@item GNU Multiple Precision Library (GMP)
-Necessary to build GCC@. If a GMP source distribution is found in a
+Necessary to build GCC@. It can be downloaded from @uref{https://gmplib.org/}.
+Older versions than 4.2.3 will not work.
+If a GMP source distribution is found in a
subdirectory of your GCC sources named @file{gmp}, it will be built
together with GCC. Alternatively, if GMP is already installed but it
is not in your library search path, you will have to configure with the
@option{--with-gmp} configure option. See also @option{--with-gmp-lib}
and @option{--with-gmp-include}.
-@item MPFR Library version 2.4.2 (or later)
+@item MPFR Library
Necessary to build GCC@. It can be downloaded from
-@uref{http://www.mpfr.org/}. If an MPFR source distribution is found
+@uref{http://www.mpfr.org/}. Older versions than 2.4.0 will not work.
+If an MPFR source distribution is found
in a subdirectory of your GCC sources named @file{mpfr}, it will be
built together with GCC. Alternatively, if MPFR is already installed
but it is not in your default library search path, the
@option{--with-mpfr} configure option should be used. See also
@option{--with-mpfr-lib} and @option{--with-mpfr-include}.
-@item MPC Library version 0.8.1 (or later)
+@item MPC Library
Necessary to build GCC@. It can be downloaded from
-@uref{http://www.multiprecision.org/}. If an MPC source distribution
+@uref{http://www.multiprecision.org/}. Older versions than
+0.8.0 will not work. If an MPC source distribution
is found in a subdirectory of your GCC sources named @file{mpc}, it
will be built together with GCC. Alternatively, if MPC is already
installed but it is not in your default library search path, the
Re: [PATCH][AArch64][4.8] Wire up TARGET_SIMD and TARGET_FLOAT properly
On 10 April 2014 12:05, Kyrill Tkachov wrote: > Hi all, > > This is the 4.8 version of the patch posted at: > http://gcc.gnu.org/ml/gcc-patches/2014-04/msg00315.html > > TARGET_CRYPTO was not defined in 4.8 therefore that hunk is removed. > Ok for the 4.8 branch? > > Thanks, > Kyrill > > 2014-04-10 Kyrylo Tkachov > > * config/aarch64/aarch64.h (TARGET_SIMD): Take AARCH64_ISA_SIMD > > into account. > (TARGET_FLOAT): Take AARCH64_ISA_FP into account. This looks fine but wait until the 4.9 back port is committed before applying this one. /Marcus
[PING][ARM] Handle simple SImode PLUS and MINUS operations in rtx costs
Hi all, Pinging this: http://gcc.gnu.org/ml/gcc-patches/2014-03/msg01276.html Thanks, Kyrill
Re: [PATCH] Fix web/60933
On Thu, Apr 24, 2014 at 10:15:31AM +0200, Richard Biener wrote:
> We probably should try to bump the versions used by that script
> to something more recent though (should we do that for the 4.9
> branch even?). Any idea what to choose here? I'd say mpc
> 1.0.2 is fine, so is mpfr 3.1.2, but should we avoid the 6.0.0 version
> of gmp? We shouldn't change those versions too often, otherwise
For gmp 6.0.0, there were some issues with miscompilation of that on
Solaris, right? Does it work elsewhere fine? Just fuzzy memories.
> -@item GNU Multiple Precision Library (GMP) version 4.3.2 (or later)
> +@item GNU Multiple Precision Library (GMP)
>
> -Necessary to build GCC@. If a GMP source distribution is found in a
> +Necessary to build GCC@. It can be downloaded from
> @uref{https://gmplib.org/}.
> +Older versions than 4.2.3 will not work.
> +If a GMP source distribution is found in a
Is there a reason why you have lowered the minimum versions (4.3.2 -> 4.2.3,
2.4.2 -> 2.4.0, 0.8.1 -> 0.8.0)?
Jakub
Re: [4.9.1 RFA] [tree-optimization/60902] Invalidate outputs of GIMPLE_ASMs when threading around loops
On Wed, Apr 23, 2014 at 8:01 PM, Jeff Law wrote:
>
> The more aggressive threading across loop backedges requires invalidating
> equivalences that do not hold across all iterations of a loop.
>
> At first glance, invaliding at PHI nodes should be sufficient as any
> statement which potentially generated a new equivalence would be reprocessed
> as we come across the backedge. However, there is one important case where
> that does not hold.
>
> Specifically we might have derived a value from a conditional and the
> conditional might have been fed by a statement that doesn't produce useful
> equivalences (such as a GIMPLE_ASM). Thus the equivalence from the
> conditional is still visible because no new equivalence will be recorded for
> the GIMPLE_ASM.
>
> So if the result of the GIMPLE_ASM that gets used in the conditional varies
> from one loop iteration to the next, we could use a stale value from a prior
> iteration to thread the current iteration. That's exactly what happens in
> the ffmpeg code.
>
> Bootstrapped and regression tested on x86_64-unknown-linux-gnu. Also
> verified that the sample audio in the referenced BZs no longer chops off
> after ~2 seconds.
>
> Installed on the trunk. OK for 4.9.1 after a suitable soak period on the
> trunk?
Ok, but ...
>
>
>
> commit 02269351ce3a81b5470b8137fb3c34bca27011da
> Author: Jeff Law
> Date: Wed Apr 23 00:25:47 2014 -0600
>
> PR tree-optimization/60902
> * tree-ssa-threadedge.c
> (record_temporary_equivalences_from_stmts_at_dest): Make sure to
> invalidate outputs from statements that do not produce useful
> outputs for threading.
>
> PR tree-optimization/60902
> * gcc.target/i386/pr60902.c: New test.
>
> diff --git a/gcc/ChangeLog b/gcc/ChangeLog
> index 638c0da..ddebba7 100644
> --- a/gcc/ChangeLog
> +++ b/gcc/ChangeLog
> @@ -1,3 +1,11 @@
> +2014-04-23 Jeff Law
> +
> + PR tree-optimization/60902
> + * tree-ssa-threadedge.c
> + (record_temporary_equivalences_from_stmts_at_dest): Make sure to
> + invalidate outputs from statements that do not produce useful
> + outputs for threading.
> +
> 2014-04-23 Venkataramanan Kumar
>
> * config/aarch64/aarch64.md (stack_protect_set, stack_protect_test)
> diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
> index 126ad08..62b07f4 100644
> --- a/gcc/testsuite/ChangeLog
> +++ b/gcc/testsuite/ChangeLog
> @@ -1,3 +1,8 @@
> +2014-04-23 Jeff Law
> +
> + PR tree-optimization/60902
> + * gcc.target/i386/pr60902.c: New test.
> +
> 2014-04-23 Alex Velenko
>
> * gcc.target/aarch64/vdup_lane_1.c: New testcase.
> diff --git a/gcc/testsuite/gcc.target/i386/pr60902.c
> b/gcc/testsuite/gcc.target/i386/pr60902.c
> new file mode 100644
> index 000..b81dcd7
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/i386/pr60902.c
> @@ -0,0 +1,32 @@
> +/* { dg-do run } */
> +/* { dg-options "-O2" } */
> +extern void abort ();
> +extern void exit (int);
> +
> +int x;
> +
> +foo()
> +{
> + static int count;
> + count++;
> + if (count > 1)
> +abort ();
> +}
> +
> +static inline int
> +frob ()
> +{
> + int a;
> + __asm__ ("mov %1, %0\n\t" : "=r" (a) : "m" (x));
> + x++;
> + return a;
> +}
> +
> +int
> +main ()
> +{
> + int i;
> + for (i = 0; i < 10 && frob () == 0; i++)
> +foo();
> + exit (0);
> +}
> diff --git a/gcc/tree-ssa-threadedge.c b/gcc/tree-ssa-threadedge.c
> index c447b72..8a0103b 100644
> --- a/gcc/tree-ssa-threadedge.c
> +++ b/gcc/tree-ssa-threadedge.c
> @@ -387,7 +387,34 @@ record_temporary_equivalences_from_stmts_at_dest (edge
> e,
>&& (gimple_code (stmt) != GIMPLE_CALL
>|| gimple_call_lhs (stmt) == NULL_TREE
>|| TREE_CODE (gimple_call_lhs (stmt)) != SSA_NAME))
> - continue;
> + {
> + /* STMT might still have DEFS and we need to invalidate any known
> +equivalences for them.
> +
> +Consider if STMT is a GIMPLE_ASM with one or more outputs that
> +feeds a conditional inside a loop. We might derive an
> equivalence
> +due to the conditional. */
> + tree op;
> + ssa_op_iter iter;
> +
> + if (backedge_seen)
> + FOR_EACH_SSA_TREE_OPERAND (op, stmt, iter, SSA_OP_ALL_DEFS)
You only need SSA_OP_DEF here, no need to process virtual
operands.
> + {
> + /* This call only invalidates equivalences created by
> + PHI nodes. This is by design to keep the cost of
> + of invalidation reasonable. */
> + invalidate_equivalences (op, stack, src_map, dst_map);
> +
> + /* However, conditionals can imply values for real
> + operands as well. And those won't be recorded in the
> + maps. In fact, those equivalences may be recorded
> totally
> + outside the threading code. We can just create a new
> +
Re: [Patch] Fix obsolete autoconf macros in configure.ac
On Wed, Apr 23, 2014 at 8:05 PM, Steve Ellcey wrote: > On Wed, 2014-04-23 at 18:40 +0200, Andreas Schwab wrote: >> "Steve Ellcey " writes: >> >> > diff --git a/gcc/configure.ac b/gcc/configure.ac >> > index d789557..98acb1b 100644 >> > --- a/gcc/configure.ac >> > +++ b/gcc/configure.ac >> > @@ -1083,8 +1083,8 @@ int main() >> >fi >> > fi >> > >> > -AC_CHECK_TYPE(ssize_t, int) >> > -AC_CHECK_TYPE(caddr_t, char *) >> > +AC_CHECK_TYPES([ssize_t]) >> > +AC_CHECK_TYPES([caddr_t]) >> >> You also need to handle the no longer supported default definition. >> Moreover, the two macro calls can be combined into one. >> >> Andreas. > > OK, if I keep these definitions, where would I put the default > definitions? I assume I want this in configure.ac: > > AC_CHECK_TYPES([ssize_t, caddr_t]) > > and then something like this in a header file: > > #ifndef HAVE_SSIZE_T > typedef int ssize_t; > #endif > #ifndef HAVE_CADDR_T > typedef char *caddr_t; > #endif > > But I am not sure what header file this code would go in. In system.h. > Steve Ellcey >
RE: [patch, testsuite] Fix fragile case nsdmi-union5
> -Original Message- > From: Mike Stump [mailto:mikest...@comcast.net] > Sent: Monday, April 21, 2014 11:39 PM > To: Joey Ye > Cc: gcc-patches@gcc.gnu.org > Subject: Re: [patch, testsuite] Fix fragile case nsdmi-union5 > > On Apr 17, 2014, at 10:28 PM, Joey Ye wrote: > > Resulting from discussion here: > > http://gcc.gnu.org/ml/gcc/2014-04/msg00125.html > > Not checked in, and no Ok? asked. You should do one or the other. :-) I'll > assume Ok? > > Ok. Just committed.
Re: [PATCH] Fix web/60933
Richard Biener writes: > The GMP people complained that we "advertise" outdated versions > in our install instructions. I tried to address that by not > explicitely listing a "good" version but only mention the version > that is the minimum requirement. I also added a reference to > contrib/download_prerequesites as the recommended way to do > in-tree builds (so we don't get random bugreports for that > with untested combinations of gmp/mpfr/mpc versions). > > We probably should try to bump the versions used by that script > to something more recent though (should we do that for the 4.9 > branch even?). Any idea what to choose here? I'd say mpc > 1.0.2 is fine, so is mpfr 3.1.2, but should we avoid the 6.0.0 version > of gmp? We shouldn't change those versions too often, otherwise > we end up with a lot of garbage in gcc/infrastructure (we don't > want to break old versions of the script). > > Meanwhile is does the patch look ok? I'd strongly advise against it: in the past we've had serious problems with versions newer than advertised in install.texi on some platforms. Until we have positive evidence that specific newer versions work on a wide range of platforms, we shouldn't suggest to our users that they might. Many users tried with the then-current versions in the past, and the failures are often quite hard to trace back to this. For the 4.9 branch, we should leave this as is: the benefit is almost certainly not worth the trouble. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [PATCH 03/89] Introduce gimple_bind and use it for accessors.
On Wed, Apr 23, 2014 at 11:23 PM, Jeff Law wrote: > On 04/23/14 15:13, David Malcolm wrote: >> >> On Wed, 2014-04-23 at 15:04 -0600, Jeff Law wrote: >>> >>> On 04/21/14 10:56, David Malcolm wrote: This updates all of the gimple_bind_* accessors in gimple.h from taking a plain gimple to taking a gimple_bind (or const_gimple_bind), with the checking happening at the point of cast. Various other types are strengthened from gimple to gimple_bind, and from plain vec to vec. >> >> >> [...] >> >>> This is fine, with the same requested changes as #2; specifically using >>> an explicit cast rather than hiding the conversion in a method. Once >>> those changes are in place, it's good for 4.9.1. >> >> Thanks - presumably you mean >>"good for *trunk* after 4.9.1 is released" > > Right. Sorry for the confusion. Note I still want that less-typedefs (esp. the const_*) variants to be explored. Changing this will touch all the code again, so I'd like to avoid that. That is, shouldn't we go back to 'gimple' being 'gimple_statement_base' and not 'gimple_statement_base *'? The main reason that we have so many typedefs is that in C you had to use 'struct foo' each time you refer to foo as a type - I suppose it was then convenient to do the typedef to the pointer type. With 'gimple' being not a pointer type we get const correctness in the way people would expect it to work. [no, I don't suggest you change 'tree' or 'const_tree' at this point, just gimple (and maybe gimple_seq) as you are working on the 'gimple' type anyway]. So I'd rather not say "ok for trunk after 4.9.1" for the current form with the cast changes. Not yet. Thanks, Richard. > jeff
[build] Fix gcc_cv_as_cfi_directive test for Solaris as
Recent versions of the Solaris/x86 assembler are gaining support for cfi directives. gcc/configure failed to detect this since it used a gas-only option for 64-bit code generation. This patch fixes it. Tested on a wide range of assembler/linker configurations on i386-pc-solaris2.1[01], installed on mainline. Rainer 2014-03-27 Rainer Orth * configure.ac (gcc_cv_as_cfi_directive): Support Solaris/x86 assembler 64-bit option. * configure: Regenerate. # HG changeset patch # Parent 5006bbed82c4b0ec2df907a42697ebd4d1e8b40a Fix gcc_cv_as_cfi_directive test for Solaris as diff --git a/gcc/configure.ac b/gcc/configure.ac --- a/gcc/configure.ac +++ b/gcc/configure.ac @@ -2570,9 +2570,14 @@ gcc_GAS_CHECK_FEATURE([cfi directives], else case "$target" in i?86-*-solaris2.1[[0-9]]* | x86_64-*-solaris2.1[[0-9]]*) - # On Solaris/x86, make sure that GCC and gas agree on using + # On Solaris/x86, make sure that GCC and assembler agree on using # read-only .eh_frame sections for 64-bit. - if $gcc_cv_as --64 -o conftest.o conftest.s > /dev/null 2>&1 && \ + if test x$gas = xyes; then + as_ix86_64_opt="--64" + else + as_ix86_64_opt="-xarch=amd64" + fi + if $gcc_cv_as $as_ix86_64_opt -o conftest.o conftest.s > /dev/null 2>&1 && \ $gcc_cv_objdump -h conftest.o 2>/dev/null | \ sed -e /.eh_frame/!d -e N | \ grep READONLY > /dev/null; then -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: GCC's -fsplit-stack disturbing Mach's vm_allocate
On Fri, 2014-04-18 at 10:03 +0200, Samuel Thibault wrote:
> Samuel Thibault, le Thu 17 Apr 2014 00:03:45 +0200, a écrit :
> > Thomas Schwinge, le Wed 09 Apr 2014 09:36:42 +0200, a écrit :
> > > Well, the first step is to verify that TARGET_THREAD_SPLIT_STACK_OFFSET
> > > and similar configury is correct for the Hurd,
> >
> > I have added the corresponding field, so we can just use the same offset
> > as on Linux.
>
> I have uploaded packages on http://people.debian.org/~sthibault/tmp/ so
> Svante can try setting TARGET_THREAD_SPLIT_STACK_OFFSET to 0x30 with
> them.
Status report:
- Without split stack enabled around 70 libgo tests pass and 50 fails,
most of them with a segfault.
- Enabling split stack and using the libc Samuel built all 122 libgo
tests fail with a segfault.
- In both cases simple go programs work, like hello+sqrt.go below.
- The segfault seems to be located at the same code piece according to
gdb (maybe due to exception handling)
cat hello+sqrt.go
package main
import (
"fmt"
)
func main() {
fmt.Printf("Hello, world. Sqrt(2) = %v\n", Sqrt(2))
}
I have not been able to use a local go library function, e.g. package
newmath, and the go frontend is not yet available for GNU/Hurd.
However, it seems that something triggers the segfaults when running
make -C build/i486-gnu/libgo check (both with and w/o split-stack)
while setting the keep parameter in ./src/libgo/testsuite/gotest
and running them manually some of them work?? As a first glance, about
the same number of tests succeeds with and w/o split stack :) Some of
the failing tests still seems random, sometimes they pass, sometimes
they fail.
RE: [PATCH][2/3] Fix PR54733 Optimize endian independent load/store
> > Bootstrapped on x86_64-linux-gnu with no testsuite regression. Also did a > arm-none-eabi cross build with no regression after running testsuite via > qemu Forgot to ask if it's ok for trunk. Same question for part 1 and 3. Best regards, Thomas
Re: [PATCH] Fix web/60933
On Thu, 24 Apr 2014, Rainer Orth wrote: > Richard Biener writes: > > > The GMP people complained that we "advertise" outdated versions > > in our install instructions. I tried to address that by not > > explicitely listing a "good" version but only mention the version > > that is the minimum requirement. I also added a reference to > > contrib/download_prerequesites as the recommended way to do > > in-tree builds (so we don't get random bugreports for that > > with untested combinations of gmp/mpfr/mpc versions). > > > > We probably should try to bump the versions used by that script > > to something more recent though (should we do that for the 4.9 > > branch even?). Any idea what to choose here? I'd say mpc > > 1.0.2 is fine, so is mpfr 3.1.2, but should we avoid the 6.0.0 version > > of gmp? We shouldn't change those versions too often, otherwise > > we end up with a lot of garbage in gcc/infrastructure (we don't > > want to break old versions of the script). > > > > Meanwhile is does the patch look ok? > > I'd strongly advise against it: in the past we've had serious problems > with versions newer than advertised in install.texi on some platforms. > Until we have positive evidence that specific newer versions work on a > wide range of platforms, we shouldn't suggest to our users that they > might. Many users tried with the then-current versions in the past, and > the failures are often quite hard to trace back to this. Note that I explicitely added the reference to download_prerequesites for the case the user wants/needs to build the libraries together with GCC. That should address this concern, no? > For the 4.9 branch, we should leave this as is: the benefit is almost > certainly not worth the trouble. Of course. Though the version referenced from http://gcc.gnu.org/install is the one from trunk. Richard. -- Richard Biener SUSE / SUSE Labs SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746 GF: Jeff Hawn, Jennifer Guild, Felix Imend"orffer
Re: [PATCH] Fix web/60933
On Thu, 24 Apr 2014, Jakub Jelinek wrote:
> On Thu, Apr 24, 2014 at 10:15:31AM +0200, Richard Biener wrote:
> > We probably should try to bump the versions used by that script
> > to something more recent though (should we do that for the 4.9
> > branch even?). Any idea what to choose here? I'd say mpc
> > 1.0.2 is fine, so is mpfr 3.1.2, but should we avoid the 6.0.0 version
> > of gmp? We shouldn't change those versions too often, otherwise
>
> For gmp 6.0.0, there were some issues with miscompilation of that on
> Solaris, right? Does it work elsewhere fine? Just fuzzy memories.
>
> > -@item GNU Multiple Precision Library (GMP) version 4.3.2 (or later)
> > +@item GNU Multiple Precision Library (GMP)
> >
> > -Necessary to build GCC@. If a GMP source distribution is found in a
> > +Necessary to build GCC@. It can be downloaded from
> > @uref{https://gmplib.org/}.
> > +Older versions than 4.2.3 will not work.
> > +If a GMP source distribution is found in a
>
> Is there a reason why you have lowered the minimum versions (4.3.2 -> 4.2.3,
> 2.4.2 -> 2.4.0, 0.8.1 -> 0.8.0)?
As I say "will not work" I checked what we reject at configure time
(for the oldest versions that work we'll complain "buggy but acceptable").
We can of course make configure more strict and at this time reject
the known buggy versions. Shall we do that?
Thanks,
Richard.
Re: [c++] typeinfo for target types
On 23/04/14 21:35, Richard Henderson wrote: On 04/23/2014 12:43 PM, Marc Glisse wrote: Any c++ compilation aborts at That's surprising, the code I touched is only ever supposed to run while compiling one file in libsupc++, if I understand correctly. Ah, well, perhaps it's one of the first built for stage1 libstdc++. I admit to not digging much deeper. ;-) Would mangling the aarch64 builtins be a lot of work? Did other platforms break as well? I've no idea on difficulty. I've not yet checked other platforms. This affects arm as well. The same ICE in mangle.c. The arm and aarch64 mangling code is very similar... Kyrill r~
Only redefine ASM_PREFERRED_EH_DATA_FORMAT if necessary on Solaris/x86
Currently, Solaris/x86 uses a private version of ASM_PREFERRED_EH_DATA_FORMAT since older versions of the Solaris assembler couldn't calculate the difference between labels in different sections. This restriction has been lifted in Solaris 10 patch 119961-07 from May 2010. Since the redefinition causes us to lose several cases in the i386 default (asm_preferred_eh_data_format) and the unwinder can easily deal with different encodings, it's best to avoid the redefinition if possible. The following patch does just that. I chose to only test for !HAVE_AS_IX86_DIFF_SECT_DELTA to enable the redef, not also HAVE_GAS_CFI_DIRECTIVE, to allow for the (admittedly unlikely) case the the assembler supports cfi directives, but not inter-section label diffs. In this scenario, -fno-dwarf2-cfi-asm would be broken. Tested on i386-pc-solaris2.1[10] with all different as/ld combos, installed on mainline. Rainer 2014-04-08 Rainer Orth * config/i386/sol2.h (ASM_PREFERRED_EH_DATA_FORMAT): Only redefine if not HAVE_AS_IX86_DIFF_SECT_DELTA. # HG changeset patch # Parent df024c74c75cec9fc9d7059928cfa014b5cd8559 Only redefine ASM_PREFERRED_EH_DATA_FORMAT if necessary on Solaris/x86 diff --git a/gcc/config/i386/sol2.h b/gcc/config/i386/sol2.h --- a/gcc/config/i386/sol2.h +++ b/gcc/config/i386/sol2.h @@ -26,13 +26,15 @@ along with GCC; see the file COPYING3. (MASK_80387 | MASK_IEEE_FP | MASK_FLOAT_RETURNS | MASK_VECT8_RETURNS) /* Old versions of the Solaris assembler can not handle the difference of - labels in different sections, so force DW_EH_PE_datarel. */ + labels in different sections, so force DW_EH_PE_datarel if so. */ +#ifndef HAVE_AS_IX86_DIFF_SECT_DELTA #undef ASM_PREFERRED_EH_DATA_FORMAT #define ASM_PREFERRED_EH_DATA_FORMAT(CODE,GLOBAL) \ (flag_pic ? ((GLOBAL ? DW_EH_PE_indirect : 0)\ | (TARGET_64BIT ? DW_EH_PE_pcrel | DW_EH_PE_sdata4 \ : DW_EH_PE_datarel)) \ : DW_EH_PE_absptr) +#endif /* The Solaris linker will not merge a read-only .eh_frame section with a read-write .eh_frame section. None of the encodings used -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [PATCH] Fix web/60933
On Thu, Apr 24, 2014 at 10:38:38AM +0200, Richard Biener wrote: > > Is there a reason why you have lowered the minimum versions (4.3.2 -> 4.2.3, > > 2.4.2 -> 2.4.0, 0.8.1 -> 0.8.0)? > > As I say "will not work" I checked what we reject at configure time > (for the oldest versions that work we'll complain "buggy but acceptable"). > We can of course make configure more strict and at this time reject > the known buggy versions. Shall we do that? Ah, ok, guess it is fine then. Dunno what the bugs in the "buggy but acceptable" were, and in any case that can be bumped independently (in both places, configure and web). Jakub
Re: [PATCH] Fix web/60933
Richard Biener writes: >> I'd strongly advise against it: in the past we've had serious problems >> with versions newer than advertised in install.texi on some platforms. >> Until we have positive evidence that specific newer versions work on a >> wide range of platforms, we shouldn't suggest to our users that they >> might. Many users tried with the then-current versions in the past, and >> the failures are often quite hard to trace back to this. > > Note that I explicitely added the reference to download_prerequesites > for the case the user wants/needs to build the libraries together > with GCC. That should address this concern, no? I fear it won't: some people will use it, others just download the latest versions from gmp.org etc. and build them out-of-tree themselves. If we want to recommend newer versions (and no complaint from me there), we should first make sure they work *ourselves* and then again require *those specific versions*, no weasle-wording for anything else, given lots of bad experience in the past. >> For the 4.9 branch, we should leave this as is: the benefit is almost >> certainly not worth the trouble. > > Of course. Though the version referenced from http://gcc.gnu.org/install > is the one from trunk. Unfortunately true. Perhaps we should change that? Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [PATCH] Fix web/60933
> Meanwhile is does the patch look ok? No, the current wording is just fine and yours doesn't bring anything (even the contrary, since you're listing known problematic versions). This will also break http://gcc.gnu.org/install/specific.html#sparc-x-x I don't see why we should special case GMP, MPFR and MPC here, look at all the other dependencies on http://gcc.gnu.org/install/prerequisites.html And IIUC the real issue is that ftp://gcc.gnu.org/pub/gcc/infrastructure/ contains obsolete versions. -- Eric Botcazou
Re: [PATCH] Fix web/60933
On Thu, 24 Apr 2014, Eric Botcazou wrote: > > Meanwhile is does the patch look ok? > > No, the current wording is just fine and yours doesn't bring anything (even > the contrary, since you're listing known problematic versions). This will > also break http://gcc.gnu.org/install/specific.html#sparc-x-x Ah, I didn't see that. So the issue here is that the host compiler miscompiles the in-tree copy? Maybe we should compile host libraries with -O0 during stage1 (and require recent host GCC for compiling cross compilers - which we probably do anyway). It's an issue anyway as soon as we bump the versions downloaded by contrib/download_prerequesites. What "newer" versions are affected, btw? Are "very newer" versions fixed maybe? > I don't see why we should special case GMP, MPFR and MPC here, look at all > the > other dependencies on http://gcc.gnu.org/install/prerequisites.html > > And IIUC the real issue is that ftp://gcc.gnu.org/pub/gcc/infrastructure/ > contains obsolete versions. Hmm, ok. Is the piece referencing contrib/download_prerequesites and documenting that as the recommended way to setup and do in-tree builds? Generally we have conflicting goals - we want to make sure GCC works with system supplied versions of the libraries (thus the configure version checks), and we want to specify versions that work for the in-tree builds (because of the somewhat awkward setup of the build because of their inter-dependencies and not doing intermediate installs). -- Richard Biener SUSE / SUSE Labs SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746 GF: Jeff Hawn, Jennifer Guild, Felix Imend"orffer
Re: [PATCH] Fix web/60933
On Thu, 24 Apr 2014, Richard Biener wrote:
> On Thu, 24 Apr 2014, Eric Botcazou wrote:
>
> > > Meanwhile is does the patch look ok?
> >
> > No, the current wording is just fine and yours doesn't bring anything (even
> > the contrary, since you're listing known problematic versions). This will
> > also break http://gcc.gnu.org/install/specific.html#sparc-x-x
>
> Ah, I didn't see that. So the issue here is that the host compiler
> miscompiles the in-tree copy? Maybe we should compile host libraries with
> -O0 during stage1 (and require recent host GCC for compiling
> cross compilers - which we probably do anyway).
>
> It's an issue anyway as soon as we bump the versions downloaded
> by contrib/download_prerequesites. What "newer" versions are
> affected, btw? Are "very newer" versions fixed maybe?
@@ -4321,8 +4330,8 @@ read all other sections that match your
Newer versions of the GNU Multiple Precision Library (GMP), the MPFR
library and the MPC library are known to be miscompiled by earlier
versions of GCC on these platforms. We therefore recommend the use
-of the exact versions of these libraries listed as minimal versions
-in @uref{prerequisites.html,,the prerequisites}.
+of the @command{download_prerequesites} script to download
+versions that are known to work.
@html
> > I don't see why we should special case GMP, MPFR and MPC here, look at all
> > the
> > other dependencies on http://gcc.gnu.org/install/prerequisites.html
> >
> > And IIUC the real issue is that ftp://gcc.gnu.org/pub/gcc/infrastructure/
> > contains obsolete versions.
>
> Hmm, ok. Is the piece referencing contrib/download_prerequesites
> and documenting that as the recommended way to setup and do
> in-tree builds?
>
> Generally we have conflicting goals - we want to make sure
> GCC works with system supplied versions of the libraries
> (thus the configure version checks), and we want to specify
> versions that work for the in-tree builds (because of the
> somewhat awkward setup of the build because of their inter-dependencies
> and not doing intermediate installs).
>
>
--
Richard Biener
SUSE / SUSE Labs
SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746
GF: Jeff Hawn, Jennifer Guild, Felix Imend"orffer
Re: [AArch64/ARM 1/3] Add execution + assembler tests of AArch64 REV Neon Intrinsics
On 23 April 2014 20:17, Alan Lawrence wrote: > This adds DejaGNU tests of the existing AArch64 vrev_* intrinsics, both > checking the assembler output and the runtime results. Test bodies are in > separate files ready to reuse for ARM in the third patch. > > All tests passing on aarch64-none-elf and aarch64_be-none-elf. > > gcc/testsuite/ChangeLog: > > 2014-04-23 Alan Lawrence There are supposed to be two spaces between the date and your name in these entries. > * gcc.target/aarch64/simd/vrev16p8_1.c: New file. > * gcc.target/aarch64/simd/vrev16p8.x: New file. > * gcc.target/aarch64/simd/vrev16qp8_1.c: New file. > * gcc.target/aarch64/simd/vrev16qp8.x: New file. > * gcc.target/aarch64/simd/vrev16qs8_1.c: New file. > * gcc.target/aarch64/simd/vrev16qs8.x: New file. > * gcc.target/aarch64/simd/vrev16qu8_1.c: New file. > * gcc.target/aarch64/simd/vrev16qu8.x: New file. > * gcc.target/aarch64/simd/vrev16s8_1.c: New file. > * gcc.target/aarch64/simd/vrev16s8.x: New file. > * gcc.target/aarch64/simd/vrev16u8_1.c: New file. > * gcc.target/aarch64/simd/vrev16u8.x: New file. > * gcc.target/aarch64/simd/vrev32p16_1.c: New file. > * gcc.target/aarch64/simd/vrev32p16.x: New file. > * gcc.target/aarch64/simd/vrev32p8_1.c: New file. > * gcc.target/aarch64/simd/vrev32p8.x: New file. > * gcc.target/aarch64/simd/vrev32qp16_1.c: New file. > * gcc.target/aarch64/simd/vrev32qp16.x: New file. > * gcc.target/aarch64/simd/vrev32qp8_1.c: New file. > * gcc.target/aarch64/simd/vrev32qp8.x: New file. > * gcc.target/aarch64/simd/vrev32qs16_1.c: New file. > * gcc.target/aarch64/simd/vrev32qs16.x: New file. > * gcc.target/aarch64/simd/vrev32qs8_1.c: New file. > * gcc.target/aarch64/simd/vrev32qs8.x: New file. > * gcc.target/aarch64/simd/vrev32qu16_1.c: New file. > * gcc.target/aarch64/simd/vrev32qu16.x: New file. > * gcc.target/aarch64/simd/vrev32qu8_1.c: New file. > * gcc.target/aarch64/simd/vrev32qu8.x: New file. > * gcc.target/aarch64/simd/vrev32s16_1.c: New file. > * gcc.target/aarch64/simd/vrev32s16.x: New file. > * gcc.target/aarch64/simd/vrev32s8_1.c: New file. > * gcc.target/aarch64/simd/vrev32s8.x: New file. > * gcc.target/aarch64/simd/vrev32u16_1.c: New file. > * gcc.target/aarch64/simd/vrev32u16.x: New file. > * gcc.target/aarch64/simd/vrev32u8_1.c: New file. > * gcc.target/aarch64/simd/vrev32u8.x: New file. > * gcc.target/aarch64/simd/vrev64f32_1.c: New file. > * gcc.target/aarch64/simd/vrev64f32.x: New file. > * gcc.target/aarch64/simd/vrev64p16_1.c: New file. > * gcc.target/aarch64/simd/vrev64p16.x: New file. > * gcc.target/aarch64/simd/vrev64p8_1.c: New file. > * gcc.target/aarch64/simd/vrev64p8.x: New file. > * gcc.target/aarch64/simd/vrev64qf32_1.c: New file. > * gcc.target/aarch64/simd/vrev64qf32.x: New file. > * gcc.target/aarch64/simd/vrev64qp16_1.c: New file. > * gcc.target/aarch64/simd/vrev64qp16.x: New file. > * gcc.target/aarch64/simd/vrev64qp8_1.c: New file. > * gcc.target/aarch64/simd/vrev64qp8.x: New file. > * gcc.target/aarch64/simd/vrev64qs16_1.c: New file. > * gcc.target/aarch64/simd/vrev64qs16.x: New file. > * gcc.target/aarch64/simd/vrev64qs32_1.c: New file. > * gcc.target/aarch64/simd/vrev64qs32.x: New file. > * gcc.target/aarch64/simd/vrev64qs8_1.c: New file. > * gcc.target/aarch64/simd/vrev64qs8.x: New file. > * gcc.target/aarch64/simd/vrev64qu16_1.c: New file. > * gcc.target/aarch64/simd/vrev64qu16.x: New file. > * gcc.target/aarch64/simd/vrev64qu32_1.c: New file. > * gcc.target/aarch64/simd/vrev64qu32.x: New file. > * gcc.target/aarch64/simd/vrev64qu8_1.c: New file. > * gcc.target/aarch64/simd/vrev64qu8.x: New file. > * gcc.target/aarch64/simd/vrev64s16_1.c: New file. > * gcc.target/aarch64/simd/vrev64s16.x: New file. > * gcc.target/aarch64/simd/vrev64s32_1.c: New file. > * gcc.target/aarch64/simd/vrev64s32.x: New file. > * gcc.target/aarch64/simd/vrev64s8_1.c: New file. > * gcc.target/aarch64/simd/vrev64s8.x: New file. > * gcc.target/aarch64/simd/vrev64u16_1.c: New file. > * gcc.target/aarch64/simd/vrev64u16.x: New file. > * gcc.target/aarch64/simd/vrev64u32_1.c: New file. > * gcc.target/aarch64/simd/vrev64u32.x: New file. > * gcc.target/aarch64/simd/vrev64u8_1.c: New file. > * gcc.target/aarch64/simd/vrev64u8.x: New file. OK /Marcus
Re: [AArch64/ARM 2/3] Recognize shuffle patterns for REV instructions on AARch64, rewrite intrinsics.
On 23 April 2014 20:44, Alan Lawrence wrote:
> This patch (borrowing heavily from the ARM backend) makes
> aarch64_expand_vec_perm_const output REV instructions when appropriate,
> and then implements the vrev_XXX intrinsics in terms of __builtin_shuffle
> (which
> now produces the same assembly instructions).
>
> No regressions (and tests in previous patch
> http://gcc.gnu.org/ml/gcc-patches/2014-04/msg01468.html still passing) on
> aarch64-none-elf; also on aarch64_be-none-elf, where there are
> no regressions following testsuite config changes in
> http://gcc.gnu.org/ml/gcc-patches/2014-04/msg00579.html, but some "noise"
> (due
> to unexpected success in vectorization) without that patch.
>
> gcc/ChangeLog:
> 2014-04-23 Alan Lawrence
Two spaces after the date.
> * config/aarch64/iterators.md: add a REVERSE iterator and rev_op
> attribute for REV64/32/16 insns.
ChangeLog entries are sentences, therefore they start with a capital letter.
Identify the new definitions in parentheses. The ChangeLog entry just
states what changed, not why, any explanation required should be in
code comments or in the submission email, therefore:
* config/aarch64/iterators.md (REVERSE, rev_op): Define.
> * config/aarch64/aarch64-simd.md: add corresponding define_insn
> parameterized by REVERSE iterator.
... and this one should read something like:
* config/aarch64/aarch64-simd.md
(aarch64_rev): Define.
The remaining entries should all be updated in a similar fashion...
> +
> +/* vrev */
> +
> +__extension__ static __inline poly8x8_t __attribute__ ((__always_inline__))
> +vrev16_p8 (poly8x8_t a)
> +{
> + return __builtin_shuffle (a, (uint8x8_t) { 1, 0, 3, 2, 5, 4, 7, 6 });
> +}
This has the effect of reserving the symbol 'a', use __a instead. We
have other breakage like this in arm_neon.h which needs fixing but
that aside we should not be compounding the problem.
Cheers
/Marcus
Re: [AArch64/ARM 1/3] Add execution + assembler tests of AArch64 EXT intrinsics
On 23 April 2014 21:01, Alan Lawrence wrote: > This adds DejaGNU tests of the existing AArch64 vext* intrinsics, both > checking the assembler output and the runtime results. Test bodies are in > separate files ready to reuse for ARM in the third patch. > > All passing on aarch64-none-elf and aarch64_be-none-elf. > > gcc/testsuite/ChangeLog: > 2014-04-23 Alan Lawrence Double space after the date, otherwise this is OK to commit. /Marcus
Re: [PING^8][PATCH] Add a couple of dialect and warning options regarding Objective-C instance variable scope
Ping! Does anybody know the current record of longest ping? I'd like to at least break it before giving up. On 04/03/2014 06:32 PM, Dimitris Papavasiliou wrote: Still pinging. On 03/28/2014 11:58 AM, Dimitris Papavasiliou wrote: Ping! On 03/23/2014 03:20 AM, Dimitris Papavasiliou wrote: Ping! On 03/13/2014 11:54 AM, Dimitris Papavasiliou wrote: Ping! On 03/06/2014 07:44 PM, Dimitris Papavasiliou wrote: Ping! On 02/27/2014 11:44 AM, Dimitris Papavasiliou wrote: Ping! On 02/20/2014 12:11 PM, Dimitris Papavasiliou wrote: Hello all, Pinging this patch review request again. See previous messages quoted below for details. Regards, Dimitris On 02/13/2014 04:22 PM, Dimitris Papavasiliou wrote: Hello, Pinging this patch review request. Can someone involved in the Objective-C language frontend have a quick look at the description of the proposed features and tell me if it'd be ok to have them in the trunk so I can go ahead and create proper patches? Thanks, Dimitris On 02/06/2014 11:25 AM, Dimitris Papavasiliou wrote: Hello, This is a patch regarding a couple of Objective-C related dialect options and warning switches. I have already submitted it a while ago but gave up after pinging a couple of times. I am now informed that should have kept pinging until I got someone's attention so I'm resending it. The patch is now against an old revision and as I stated originally it's probably not in a state that can be adopted as is. I'm sending it as is so that the implemented features can be assesed in terms of their usefulness and if they're welcome I'd be happy to make any necessary changes to bring it up-to-date, split it into smaller patches, add test-cases and anything else that is deemed necessary. Here's the relevant text from my initial message: Two of these switches are related to a feature request I submitted a while ago, Bug 56044 (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56044). I won't reproduce the entire argument here since it is available in the feature request. The relevant functionality in the patch comes in the form of two switches: -Wshadow-ivars which controls the "local declaration of ‘somevar’ hides instance variable" warning which curiously is enabled by default instead of being controlled at least by -Wshadow. The patch changes it so that this warning can be enabled and disabled specifically through -Wshadow-ivars as well as with all other shadowing-related warnings through -Wshadow. The reason for the extra switch is that, while searching through the Internet for a solution to this problem I have found out that other people are inconvenienced by this particular warning as well so it might be useful to be able to turn it off while keeping all the other shadowing-related warnings enabled. -flocal-ivars which when true, as it is by default, treats instance variables as having local scope. If false (-fno-local-ivars) instance variables must always be referred to as self->ivarname and references of ivarname resolve to the local or global scope as usual. I've also taken the opportunity of adding another switch unrelated to the above but related to instance variables: -fivar-visibility which can be set to either private, protected (the default), public and package. This sets the default instance variable visibility which normally is implicitly protected. My use-case for it is basically to be able to set it to public and thus effectively disable this visibility mechanism altogether which I find no use for and therefore have to circumvent. I'm not sure if anyone else feels the same way towards this but I figured it was worth a try. I'm attaching a preliminary patch against the current revision in case anyone wants to have a look. The changes are very small and any blatant mistakes should be immediately obvious. I have to admit to having virtually no knowledge of the internals of GCC but I have tried to keep in line with formatting guidelines and general style as well as looking up the particulars of the way options are handled in the available documentation to avoid blind copy-pasting. I have also tried to test the functionality both in my own (relatively large, or at least not too small) project and with small test programs and everything works as expected. Finallly, I tried running the tests too but these fail to complete both in the patched and unpatched version, possibly due to the way I've configured GCC. Dimitris
Re: [c++] typeinfo for target types
On Wed, Apr 23, 2014 at 8:43 PM, Marc Glisse wrote: > On Wed, 23 Apr 2014, Richard Henderson wrote: > >> On 04/13/2014 01:41 AM, Marc Glisse wrote: >>> >>> Hello, >>> >>> this patch generates typeinfo for target types. On x86_64, it adds these >>> 6 >>> lines to nm -C libsupc++.a. A follow-up patch will be needed to export >>> and >>> version those in the shared library. >>> >>> + V typeinfo for __float128 >>> + V typeinfo for __float128 const* >>> + V typeinfo for __float128* >>> + V typeinfo name for __float128 >>> + V typeinfo name for __float128 const* >>> + V typeinfo name for __float128* >>> >>> Bootstrap and testsuite on x86_64-linux-gnu (a bit of noise in >>> tsan/tls_race.c). >>> >>> 2014-04-13 Marc Glisse >>> >>> PR libstdc++/43622 >>> gcc/c-family/ >>> * c-common.c (registered_builtin_types): Make non-static. >>> * c-common.h (registered_builtin_types): Declare. >>> gcc/cp/ >>> * rtti.c (emit_support_tinfo_1): New function, extracted from >>> emit_support_tinfos. >>> (emit_support_tinfos): Call it and iterate on >>> registered_builtin_types. >>> >> >> This is causing aarch64 builds to break. > > > If it is causing too much trouble, we could ifdef out the last 2 lines of > emit_support_tinfos and revert the libstdc++ changes (or even revert the > whole thing). > > >> Any c++ compilation aborts at > > > That's surprising, the code I touched is only ever supposed to run while > compiling one file in libsupc++, if I understand correctly. > > >> #0 fancy_abort (file=0x14195c8 "../../git-rh/gcc/cp/mangle.c", line=2303, >>function=0x1419ff8 >>"write_builtin_type") at ../../git-rh/gcc/diagnostic.c:1190 >> #1 0x007ce2b4 in write_builtin_type ( >>type=) >>at ../../git-rh/gcc/cp/mangle.c:2303 >> #2 0x007cc85c in write_type ( >>type=) >>at ../../git-rh/gcc/cp/mangle.c:1969 >> #3 0x007d4d98 in mangle_special_for_type ( >>type=, >>code=0x1419a98 "TI") at ../../git-rh/gcc/cp/mangle.c:3569 >> #4 0x007d4dcc in mangle_typeinfo_for_type ( >>type=) >>at ../../git-rh/gcc/cp/mangle.c:3585 >> #5 0x0070618c in get_tinfo_decl ( >>type=) >>at ../../git-rh/gcc/cp/rtti.c:422 >> #6 0x00709ff0 in emit_support_tinfo_1 ( >>bltn=) >>at ../../git-rh/gcc/cp/rtti.c:1485 >> #7 0x0070a344 in emit_support_tinfos () >>at ../../git-rh/gcc/cp/rtti.c:1550 >> >> Presumably the backend needs to grow some mangling support for its >> builtins, > > > aarch64 has complicated builtins... __builtin_aarch64_simd_df uses > double_aarch64_type_node which is not the same as double_type_node. I mostly > looked at the x86 backend, so I didn't notice that aarch64 registers a lot > more builtins. > > >> but in the meantime can we do something less drastic than abort? > > > Sounds good, but I am not sure how exactly. We could use a separate hook > (register_builtin_type_for_typeinfo?) so back-ends have to explicitly say > they want typeinfo, but it is ugly having to register types multiple times. > We could add a parameter to the existing register_builtin_type saying > whether we want typeinfo, but that means updating all back-ends. Well some of these scalar types are not really user visible which is where I believe the problem is coming from and prima-facie I don't think we should be inventing mangling for some of these "internal" types. > We could > get the mangling functions to take a parameter that says whether errors > should be fatal and skip generating the typeinfo when we can't mangle, but > there is no convenient way to communicate this mangling failure (0 bytes > written?). > > Would mangling the aarch64 builtins be a lot of work? Did other platforms > break as well? > It's not a lot of work but I'd like to make sure we're doing the right thing on both AArch32 and AArch64. So, for now can we just revert this till the thing is sorted out. regards Ramana > >> Isn't this only really an issue if someone tries to access one of these >> types via typeinfo? > > > Yes. > > -- > Marc Glisse
[PATCH] Update libstdc++ baseline symbols for ia64
Tested on ia64-suse-linux and installed as obvious. Andreas. * config/abi/post/ia64-linux-gnu/baseline_symbols.txt: Update for new CXXABI_1.3.9 symbols. diff --git a/libstdc++-v3/config/abi/post/ia64-linux-gnu/baseline_symbols.txt b/libstdc++-v3/config/abi/post/ia64-linux-gnu/baseline_symbols.txt index 6ff97c7..f1a8cbd 100644 --- a/libstdc++-v3/config/abi/post/ia64-linux-gnu/baseline_symbols.txt +++ b/libstdc++-v3/config/abi/post/ia64-linux-gnu/baseline_symbols.txt @@ -2520,6 +2520,7 @@ OBJECT:0:CXXABI_1.3.5 OBJECT:0:CXXABI_1.3.6 OBJECT:0:CXXABI_1.3.7 OBJECT:0:CXXABI_1.3.8 +OBJECT:0:CXXABI_1.3.9 OBJECT:0:CXXABI_TM_1 OBJECT:0:GLIBCXX_3.4 OBJECT:0:GLIBCXX_3.4.1 @@ -2641,6 +2642,7 @@ OBJECT:16:_ZTIc@@CXXABI_1.3 OBJECT:16:_ZTId@@CXXABI_1.3 OBJECT:16:_ZTIe@@CXXABI_1.3 OBJECT:16:_ZTIf@@CXXABI_1.3 +OBJECT:16:_ZTIg@@CXXABI_1.3.9 OBJECT:16:_ZTIh@@CXXABI_1.3 OBJECT:16:_ZTIi@@CXXABI_1.3 OBJECT:16:_ZTIj@@CXXABI_1.3 @@ -3168,11 +3170,14 @@ OBJECT:2:_ZTSc@@CXXABI_1.3 OBJECT:2:_ZTSd@@CXXABI_1.3 OBJECT:2:_ZTSe@@CXXABI_1.3 OBJECT:2:_ZTSf@@CXXABI_1.3 +OBJECT:2:_ZTSg@@CXXABI_1.3.9 OBJECT:2:_ZTSh@@CXXABI_1.3 OBJECT:2:_ZTSi@@CXXABI_1.3 OBJECT:2:_ZTSj@@CXXABI_1.3 OBJECT:2:_ZTSl@@CXXABI_1.3 OBJECT:2:_ZTSm@@CXXABI_1.3 +OBJECT:2:_ZTSn@@CXXABI_1.3.9 +OBJECT:2:_ZTSo@@CXXABI_1.3.9 OBJECT:2:_ZTSs@@CXXABI_1.3 OBJECT:2:_ZTSt@@CXXABI_1.3 OBJECT:2:_ZTSv@@CXXABI_1.3 @@ -3199,6 +3204,7 @@ OBJECT:32:_ZTIPKc@@CXXABI_1.3 OBJECT:32:_ZTIPKd@@CXXABI_1.3 OBJECT:32:_ZTIPKe@@CXXABI_1.3 OBJECT:32:_ZTIPKf@@CXXABI_1.3 +OBJECT:32:_ZTIPKg@@CXXABI_1.3.9 OBJECT:32:_ZTIPKh@@CXXABI_1.3 OBJECT:32:_ZTIPKi@@CXXABI_1.3 OBJECT:32:_ZTIPKj@@CXXABI_1.3 @@ -3218,6 +3224,7 @@ OBJECT:32:_ZTIPc@@CXXABI_1.3 OBJECT:32:_ZTIPd@@CXXABI_1.3 OBJECT:32:_ZTIPe@@CXXABI_1.3 OBJECT:32:_ZTIPf@@CXXABI_1.3 +OBJECT:32:_ZTIPg@@CXXABI_1.3.9 OBJECT:32:_ZTIPh@@CXXABI_1.3 OBJECT:32:_ZTIPi@@CXXABI_1.3 OBJECT:32:_ZTIPj@@CXXABI_1.3 @@ -3265,11 +3272,14 @@ OBJECT:3:_ZTSPc@@CXXABI_1.3 OBJECT:3:_ZTSPd@@CXXABI_1.3 OBJECT:3:_ZTSPe@@CXXABI_1.3 OBJECT:3:_ZTSPf@@CXXABI_1.3 +OBJECT:3:_ZTSPg@@CXXABI_1.3.9 OBJECT:3:_ZTSPh@@CXXABI_1.3 OBJECT:3:_ZTSPi@@CXXABI_1.3 OBJECT:3:_ZTSPj@@CXXABI_1.3 OBJECT:3:_ZTSPl@@CXXABI_1.3 OBJECT:3:_ZTSPm@@CXXABI_1.3 +OBJECT:3:_ZTSPn@@CXXABI_1.3.9 +OBJECT:3:_ZTSPo@@CXXABI_1.3.9 OBJECT:3:_ZTSPs@@CXXABI_1.3 OBJECT:3:_ZTSPt@@CXXABI_1.3 OBJECT:3:_ZTSPv@@CXXABI_1.3 @@ -3565,11 +3575,14 @@ OBJECT:4:_ZTSPKc@@CXXABI_1.3 OBJECT:4:_ZTSPKd@@CXXABI_1.3 OBJECT:4:_ZTSPKe@@CXXABI_1.3 OBJECT:4:_ZTSPKf@@CXXABI_1.3 +OBJECT:4:_ZTSPKg@@CXXABI_1.3.9 OBJECT:4:_ZTSPKh@@CXXABI_1.3 OBJECT:4:_ZTSPKi@@CXXABI_1.3 OBJECT:4:_ZTSPKj@@CXXABI_1.3 OBJECT:4:_ZTSPKl@@CXXABI_1.3 OBJECT:4:_ZTSPKm@@CXXABI_1.3 +OBJECT:4:_ZTSPKn@@CXXABI_1.3.9 +OBJECT:4:_ZTSPKo@@CXXABI_1.3.9 OBJECT:4:_ZTSPKs@@CXXABI_1.3 OBJECT:4:_ZTSPKt@@CXXABI_1.3 OBJECT:4:_ZTSPKv@@CXXABI_1.3 -- 1.9.2 -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: [Patch] Fix a bug of consecutive range quantifiers in regex
On 24 April 2014 04:47, Tim Shen wrote: >> Booted and tested with -m32 and -m64. > > I should give an explanation: > > When traversing a graph in _M_clone(), it should stop at a node with > id _M_end. However, if _M_end has other outgoing edge (_M_alt), the > edge should be concerned too. So this patch move the _M_alt part > before the _M_end test, thus _M_alt must be traversed. Unless I'm doing something wrong the new tests you added already give the right results, do you have a testcase that fails with the current code?
[PATCH] Fix PR60912
The following fixes PR60912 - a bug with IPA PTA computing
the use/clobber sets for direct calls where it "optimized"
walking using the cgraph nodes caller list. But that can
be incomplete in the face of aliases. Luckily that
optimization is no longer necessary because we now cache
the outcome of find_what_var_points_to, thus removing it
fixes the issue.
Bootstrap and regtest ongoing on x86_64-unknown-linux-gnu,
will apply to trunk and 4.9 branch.
Thanks,
Richard.
2014-04-24 Richard Biener
PR ipa/60912
* tree-ssa-structalias.c (ipa_pta_execute): Compute direct
call stmt use/clobber sets during stmt walk instead of
walking the possibly incomplete set of caller edges.
* g++.dg/opt/pr60912.C: New testcase.
Index: gcc/tree-ssa-structalias.c
===
*** gcc/tree-ssa-structalias.c (revision 209744)
--- gcc/tree-ssa-structalias.c (working copy)
*** ipa_pta_execute (void)
*** 7244,7253
tree ptr;
struct function *fn;
unsigned i;
- varinfo_t fi;
basic_block bb;
- struct pt_solution uses, clobbers;
- struct cgraph_edge *e;
/* Nodes without a body are not interesting. */
if (!cgraph_function_with_gimple_body_p (node) || node->clone_of)
--- 7244,7250
*** ipa_pta_execute (void)
*** 7263,7283
find_what_p_points_to (ptr);
}
- /* Compute the call-use and call-clobber sets for all direct calls. */
- fi = lookup_vi_for_tree (node->decl);
- gcc_assert (fi->is_fn_info);
- clobbers
- = find_what_var_points_to (first_vi_for_offset (fi, fi_clobbers));
- uses = find_what_var_points_to (first_vi_for_offset (fi, fi_uses));
- for (e = node->callers; e; e = e->next_caller)
- {
- if (!e->call_stmt)
- continue;
-
- *gimple_call_clobber_set (e->call_stmt) = clobbers;
- *gimple_call_use_set (e->call_stmt) = uses;
- }
-
/* Compute the call-use and call-clobber sets for indirect calls
and calls to external functions. */
FOR_EACH_BB_FN (bb, fn)
--- 7260,7265
*** ipa_pta_execute (void)
*** 7288,7304
{
gimple stmt = gsi_stmt (gsi);
struct pt_solution *pt;
! varinfo_t vi;
tree decl;
if (!is_gimple_call (stmt))
continue;
! /* Handle direct calls to external functions. */
decl = gimple_call_fndecl (stmt);
if (decl
! && (!(fi = lookup_vi_for_tree (decl))
! || !fi->is_fn_info))
{
pt = gimple_call_use_set (stmt);
if (gimple_call_flags (stmt) & ECF_CONST)
--- 7270,7296
{
gimple stmt = gsi_stmt (gsi);
struct pt_solution *pt;
! varinfo_t vi, fi;
tree decl;
if (!is_gimple_call (stmt))
continue;
! /* Handle direct calls to functions with body. */
decl = gimple_call_fndecl (stmt);
if (decl
! && (fi = lookup_vi_for_tree (decl))
! && fi->is_fn_info)
! {
! *gimple_call_clobber_set (stmt)
!= find_what_var_points_to
!(first_vi_for_offset (fi, fi_clobbers));
! *gimple_call_use_set (stmt)
!= find_what_var_points_to
!(first_vi_for_offset (fi, fi_uses));
! }
! /* Handle direct calls to external functions. */
! else if (decl)
{
pt = gimple_call_use_set (stmt);
if (gimple_call_flags (stmt) & ECF_CONST)
*** ipa_pta_execute (void)
*** 7342,7351
pt->nonlocal = 1;
}
}
-
/* Handle indirect calls. */
! if (!decl
! && (fi = get_fi_for_callee (stmt)))
{
/* We need to accumulate all clobbers/uses of all possible
callees. */
--- 7334,7342
pt->nonlocal = 1;
}
}
/* Handle indirect calls. */
! else if (!decl
! && (fi = get_fi_for_callee (stmt)))
{
/* We need to accumulate all clobbers/uses of all possible
callees. */
Index: gcc/testsuite/g++.dg/opt/pr60912.C
===
*** gcc/testsuite/g++.dg/opt/pr60912.C (revision 0)
--- gcc/testsuite/g++.dg/opt/pr60912.C (working copy)
***
*** 0
--- 1,18
+ // { dg-do run }
+ // { dg-options "-O -fno-inline -fipa-pta" }
+
+ s
[PATCH] Fix PR60911
Simple IPA passes are supposed to see function bodies with IPA transforms
applied - this is what the code in execute_one_pass tries to ensure.
But that doesn't work anymore with on-demand function-body loading.
The following addresses this in the least intrusive way - inlining
do_per_function (apply_ipa_transforms) and adjusting it accordingly.
This IMHO is definitely the solution for the 4.9 branch (and for
the time being on trunk).
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
Ok for trunk and branch?
Thanks,
Richard.
2014-04-24 Richard Biener
PR ipa/60911
* passes.c (apply_ipa_transforms): Inline into only caller ...
(execute_one_pass): ... here. Properly bring in function
bodies for nodes we want to apply IPA transforms to.
* gcc.dg/lto/pr60911_0.c: New testcase.
Index: gcc/passes.c
===
--- gcc/passes.c(revision 209742)
+++ gcc/passes.c(working copy)
@@ -2109,20 +2109,6 @@ execute_all_ipa_transforms (void)
}
}
-/* Callback for do_per_function to apply all IPA transforms. */
-
-static void
-apply_ipa_transforms (void *data)
-{
- struct cgraph_node *node = cgraph_get_node (current_function_decl);
- if (!node->global.inlined_to && node->ipa_transforms_to_apply.exists ())
-{
- *(bool *)data = true;
- execute_all_ipa_transforms ();
- rebuild_cgraph_edges ();
-}
-}
-
/* Check if PASS is explicitly disabled or enabled and return
the gate status. FUNC is the function to be processed, and
GATE_STATUS is the gate status determined by pass manager by
@@ -2194,8 +2180,26 @@ execute_one_pass (opt_pass *pass)
Apply all trnasforms first. */
if (pass->type == SIMPLE_IPA_PASS)
{
+ struct cgraph_node *node;
bool applied = false;
- do_per_function (apply_ipa_transforms, (void *)&applied);
+ FOR_EACH_DEFINED_FUNCTION (node)
+ if (node->analyzed
+ && cgraph_function_with_gimple_body_p (node)
+ && (!node->clone_of || node->decl != node->clone_of->decl))
+ {
+ if (!node->global.inlined_to
+ && node->ipa_transforms_to_apply.exists ())
+ {
+ cgraph_get_body (node);
+ push_cfun (DECL_STRUCT_FUNCTION (node->decl));
+ execute_all_ipa_transforms ();
+ rebuild_cgraph_edges ();
+ free_dominance_info (CDI_DOMINATORS);
+ free_dominance_info (CDI_POST_DOMINATORS);
+ pop_cfun ();
+ applied = true;
+ }
+ }
if (applied)
symtab_remove_unreachable_nodes (true, dump_file);
/* Restore current_pass. */
Index: gcc/testsuite/gcc.dg/lto/pr60911_0.c
===
--- gcc/testsuite/gcc.dg/lto/pr60911_0.c(revision 0)
+++ gcc/testsuite/gcc.dg/lto/pr60911_0.c(working copy)
@@ -0,0 +1,21 @@
+// { dg-lto-do run }
+// { dg-lto-options { { -O2 -flto -fipa-pta } } }
+
+int __attribute__ ((__noinline__)) f (unsigned *p, int *x)
+{
+ int y = *p++ & 0xfff;
+ *x++ = y;
+ *x = *p;
+ return y;
+}
+
+int
+main ()
+{
+ unsigned u[2] = { 0x3aad, 0x5ad1 };
+ int x[2] = { 17689, 23456 };
+
+ if (f (u, x) != 0xaad || x[0] != 0xaad || x[1] != 0x5ad1)
+__builtin_abort ();
+ return 0;
+}
Re: [PATCH 00/89] Compile-time gimple-checking
Jeff Law writes: > On 04/22/14 02:03, Richard Sandiford wrote: >> First of all, thanks a lot for doing this. Maybe one day we'll have >> the same in rtl :-) > Funny you should mention that. I blocked off a hunk of time for David > to investigate doing some work on that this year. That'd be great. The fact that we had to turn rtl checking off by default for being too expensive suggests that we do far too many opaque accesses. Hopefully something like this will either eliminate the need for rtl checking (probably a bit optimistic) or at least make it cheap enough to be turned on by default. E.g. "instruction" rtxes should be mostly distinct from "pattern" rtxes. Having them as different types would also avoid cases of patterns being accidentally passed to functions that take insns, or vice versa. Thanks, Richard
Re: [PATCH] Fix PR60896
On Wed, 23 Apr 2014, Cong Hou wrote: > See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60896 for bug report. > > The cause of PR60896 is that those statements in PATTERN_DEF_SEQ in > pre-recognized widen-mult pattern are not forwarded to later > recognized dot-product pattern. > > Another issue is that the def types of statements in PATTERN_DEF_SEQ > are assigned with the def type of the pattern statement. This is > incorrect for reduction pattern statement, in which case all > statements in PATTERN_DEF_SEQ will all be vect_reduction_def, and none > of them will be vectorized later. The def type of statement in > PATTERN_DEF_SEQ should always be vect_internal_def. > > The patch is attached. Bootstrapped and tested on a x86_64 machine. > > OK for trunk? Ok. Thanks, Richard.
Re: [PATCH, AArch64] Enable shuffle on big-endian and turn on the testsuite
> gcc/ChangeLog: > 2014-04-11 Alan Lawrence > > * config/aarch64/aarch64.c (aarch64_evpc_tbl): enable for bigendian. > > gcc/testsuite/ChangeLog: > 2014-04-11 Alan Lawrence > > * lib/target-supports.exp (check_effective_target_vect_perm): return > true for aarch64_be. ChangeLog entries are sentences, start with a capital, otherwise. OK /Marcus
Re: [VRP][PATCH] Improve value range for loop index
On Wed, Apr 9, 2014 at 10:07 PM, Kugan
wrote:
> Value range propagation simplifies convergence in vrp_visit_phi_node by
> setting minimum to TYPE_MIN when the computed minimum is smaller than
> the previous minimum. This can however result in pessimistic value
> ranges in some cases.
>
> for example,
>
> unsigned int i;
> for (i = 0; i < 8; i++)
> {
>
> }
>
> # ivtmp_19 = PHI
> ...
> :
> ivtmp_17 = ivtmp_19 - 1;
> if (ivtmp_17 != 0)
>
> goto ;
>
> min value of ivtmp_19 is simplified to 0 (in tree-vrp.c:8465) where as
> it should have been 1. This prevents correct value ranges being
> calculated for ivtmp_17 in the example.
>
> We should be able to see the step (the difference from previous minimum
> to computed minimum) and if there is scope for more iterations (computed
> minimum is greater than step), and then we should be able set minimum to
> do one more iteration and converge to the right minimum value.
>
> Attached patch fixes this. Is this OK for stage-1?
In principle the code in adjust_range_with_scev is supposed to
fix this up by using number-of-iteration analysis. I can see this is not
working for the testcase but I'm curious exactly why.
Your patch basically makes us converge to the correct value by
iterating (but faster than by just iterating). That's an interesting
idea but the way you do it looks very special. If we really want to
go down this route (instead of fixing up adjust_range_with_scev for IVs)
then I'd like to see a more general solution - like by making the code
skip to TYPE_MIN/MAX_VALUE +-1. I'm also not sure the case
handling the supposed bouncing needs to bump to MIN/MAX at all,
it could simply retain the old values.
For example with the following which also lets the next iteration choose
whether there was overflow or not. That would be the main motivation
here - that we now handle a lower bound of -INF + 1 correctly is a
nice side-effect (but as we don't handle -INF + 2 the same it's only
a side-effect).
Like with the following.
@@ -8452,32 +8453,30 @@ vrp_visit_phi_node (gimple phi)
&& (cmp_min != 0 || cmp_max != 0))
goto varying;
- /* If the new minimum is smaller or larger than the previous
-one, go all the way to -INF. In the first case, to avoid
-iterating millions of times to reach -INF, and in the
-other case to avoid infinite bouncing between different
-minimums. */
- if (cmp_min > 0 || cmp_min < 0)
- {
- if (!needs_overflow_infinity (TREE_TYPE (vr_result.min))
- || !vrp_var_may_overflow (lhs, phi))
- vr_result.min = TYPE_MIN_VALUE (TREE_TYPE (vr_result.min));
- else if (supports_overflow_infinity (TREE_TYPE (vr_result.min)))
- vr_result.min =
- negative_overflow_infinity (TREE_TYPE (vr_result.min));
- }
-
- /* Similarly, if the new maximum is smaller or larger than
-the previous one, go all the way to +INF. */
- if (cmp_max < 0 || cmp_max > 0)
- {
- if (!needs_overflow_infinity (TREE_TYPE (vr_result.max))
- || !vrp_var_may_overflow (lhs, phi))
- vr_result.max = TYPE_MAX_VALUE (TREE_TYPE (vr_result.max));
- else if (supports_overflow_infinity (TREE_TYPE (vr_result.max)))
- vr_result.max =
- positive_overflow_infinity (TREE_TYPE (vr_result.max));
- }
+ /* If the new minimum is larger than than the previous one
+retain the old value. If the new minimum value is smaller
+than the previous one and not -INF go all the way to -INF + 1.
+In the first case, to avoid infinite bouncing between different
+minimums, and in the other case to avoid iterating millions of
+times to reach -INF. */
+ if (cmp_min < 0)
+ vr_result.min = lhs_vr->min;
+ else if (cmp_min > 0
+ && !vrp_val_is_min (vr_result.min))
+ vr_result.min
+ = int_const_binop (PLUS_EXPR,
+vrp_val_min (TREE_TYPE (vr_result.min)),
+build_int_cst (TREE_TYPE (vr_result.min), 1));
+
+ /* Similarly for the maximum value. */
+ if (cmp_max > 0)
+ vr_result.max = lhs_vr->max;
+ else if (cmp_max < 0
+ && !vrp_val_is_max (vr_result.max))
+ vr_result.max
+ = int_const_binop (MINUS_EXPR,
+vrp_val_max (TREE_TYPE (vr_result.min)),
+build_int_cst (TREE_TYPE (vr_result.min), 1));
/* If we dropped either bound to +-INF then if this is a loop
PHI node SCEV may known more about its value-range. */
I'm going to give this bootstrap and testing.
Richard.
> Bootstrapped and regression tested on X86_64-unknown-linux-gnu with no
> new regressions.
>
> Thanks,
> Kugan
>
> gcc/
>
> +2014-04-09 Kugan Vivekanandarajah
> +
> + * t
Re: [PATCH 03/89] Introduce gimple_bind and use it for accessors.
On 04/24/2014 04:33 AM, Richard Biener wrote: On Wed, Apr 23, 2014 at 11:23 PM, Jeff Law wrote: On 04/23/14 15:13, David Malcolm wrote: On Wed, 2014-04-23 at 15:04 -0600, Jeff Law wrote: On 04/21/14 10:56, David Malcolm wrote: This updates all of the gimple_bind_* accessors in gimple.h from taking a plain gimple to taking a gimple_bind (or const_gimple_bind), with the checking happening at the point of cast. Various other types are strengthened from gimple to gimple_bind, and from plain vec to vec. [...] This is fine, with the same requested changes as #2; specifically using an explicit cast rather than hiding the conversion in a method. Once those changes are in place, it's good for 4.9.1. Thanks - presumably you mean "good for *trunk* after 4.9.1 is released" Right. Sorry for the confusion. Note I still want that less-typedefs (esp. the const_*) variants to be explored. Changing this will touch all the code again, so I'd like to avoid that. That is, shouldn't we go back to 'gimple' being 'gimple_statement_base' and not 'gimple_statement_base *'? The main reason that we have so many typedefs is that in C you had to use 'struct foo' each time you refer to foo as a type - I suppose it was then convenient to do the typedef to the pointer type. With 'gimple' being not a pointer type we get const correctness in the way people would expect it to work. [no, I don't suggest you change 'tree' or 'const_tree' at this point, just gimple (and maybe gimple_seq) as you are working on the 'gimple' type anyway]. So if we change 'gimple' everywhere to be 'gimple *', can we just abandon the 'gimple' typedef completely and go directly to using something like gimple_stmt, or some other agreeable name instead? I think its more descriptive and then frees up the generic 'gimple' name should we decide to do something more with namespaces in the future... Andrew
Re: [PATCH 00/89] Compile-time gimple-checking
On 04/23/2014 10:42 AM, Michael Matz wrote: Hi, On Mon, 21 Apr 2014, David Malcolm wrote: case GIMPLE_SWITCH: dump_gimple_switch (buffer, gs->as_a_gimple_switch (), spc, flags); break; where the ->as_a_gimple_switch is a no-op cast from "gimple" to the more concrete "gimple_switch" in a release build, with runtime checking for code == GIMPLE_SWITCH added in a checked build (it uses as_a <> internally). Unlike others here I do like the cast-as-method (if we absolutely _must_ have a complicated type hierarchy for gimple), but would suggest different a name: the "gimple_" is tautological, and the "a_" just noise, just name it "gs->as_switch()" (incidentally then it's _really_ shorter than the ugly is_a/as_a syntax). Well, we ought to settle on one... either use the is_a, as_a, and dyn_cast paradigm as they exist today, or we use the cast_as_method approach everywhere. I'm not fond of each potential project having a different approach... I'd like to see a consistent look throughout. I suspect the cast_as_method has compile time advantages, as well as error reporting ones (have you seen the kind of message you get when the template instantiation doesn't work right? ick!) , but it suffers from having to modify the base class whenever a new derived class is added... (which seems a little "dirty" and could impact possible future enhancements). Andrew
Re: [c++] typeinfo for target types
On Thu, 24 Apr 2014, Ramana Radhakrishnan wrote: On Wed, Apr 23, 2014 at 8:43 PM, Marc Glisse wrote: On Wed, 23 Apr 2014, Richard Henderson wrote: On 04/13/2014 01:41 AM, Marc Glisse wrote: Hello, this patch generates typeinfo for target types. On x86_64, it adds these 6 lines to nm -C libsupc++.a. A follow-up patch will be needed to export and version those in the shared library. + V typeinfo for __float128 + V typeinfo for __float128 const* + V typeinfo for __float128* + V typeinfo name for __float128 + V typeinfo name for __float128 const* + V typeinfo name for __float128* Bootstrap and testsuite on x86_64-linux-gnu (a bit of noise in tsan/tls_race.c). 2014-04-13 Marc Glisse PR libstdc++/43622 gcc/c-family/ * c-common.c (registered_builtin_types): Make non-static. * c-common.h (registered_builtin_types): Declare. gcc/cp/ * rtti.c (emit_support_tinfo_1): New function, extracted from emit_support_tinfos. (emit_support_tinfos): Call it and iterate on registered_builtin_types. This is causing aarch64 builds to break. If it is causing too much trouble, we could ifdef out the last 2 lines of emit_support_tinfos and revert the libstdc++ changes (or even revert the whole thing). Any c++ compilation aborts at That's surprising, the code I touched is only ever supposed to run while compiling one file in libsupc++, if I understand correctly. #0 fancy_abort (file=0x14195c8 "../../git-rh/gcc/cp/mangle.c", line=2303, function=0x1419ff8 "write_builtin_type") at ../../git-rh/gcc/diagnostic.c:1190 #1 0x007ce2b4 in write_builtin_type ( type=) at ../../git-rh/gcc/cp/mangle.c:2303 #2 0x007cc85c in write_type ( type=) at ../../git-rh/gcc/cp/mangle.c:1969 #3 0x007d4d98 in mangle_special_for_type ( type=, code=0x1419a98 "TI") at ../../git-rh/gcc/cp/mangle.c:3569 #4 0x007d4dcc in mangle_typeinfo_for_type ( type=) at ../../git-rh/gcc/cp/mangle.c:3585 #5 0x0070618c in get_tinfo_decl ( type=) at ../../git-rh/gcc/cp/rtti.c:422 #6 0x00709ff0 in emit_support_tinfo_1 ( bltn=) at ../../git-rh/gcc/cp/rtti.c:1485 #7 0x0070a344 in emit_support_tinfos () at ../../git-rh/gcc/cp/rtti.c:1550 Presumably the backend needs to grow some mangling support for its builtins, aarch64 has complicated builtins... __builtin_aarch64_simd_df uses double_aarch64_type_node which is not the same as double_type_node. I mostly looked at the x86 backend, so I didn't notice that aarch64 registers a lot more builtins. but in the meantime can we do something less drastic than abort? Sounds good, but I am not sure how exactly. We could use a separate hook (register_builtin_type_for_typeinfo?) so back-ends have to explicitly say they want typeinfo, but it is ugly having to register types multiple times. We could add a parameter to the existing register_builtin_type saying whether we want typeinfo, but that means updating all back-ends. We could also make typeinfo_in_lib_p more strict so for REAL_TYPE it only returns true for the types listed in fundamentals. Well some of these scalar types are not really user visible which is where I believe the problem is coming from and prima-facie I don't think we should be inventing mangling for some of these "internal" types. If the types are not user-visible, it is not clear to me why they need to be registered with the front-end... We could get the mangling functions to take a parameter that says whether errors should be fatal and skip generating the typeinfo when we can't mangle, but there is no convenient way to communicate this mangling failure (0 bytes written?). Would mangling the aarch64 builtins be a lot of work? Did other platforms break as well? It's not a lot of work but I'd like to make sure we're doing the right thing on both AArch32 and AArch64. So, for now can we just revert this till the thing is sorted out. Ok, I'll commit the attached as soon as I've checked it isn't too broken. It is not a complete revert: splitting the rtti function is still cleaner, and the int128 symbols are still there. 2014-04-24 Marc Glisse PR libstdc++/43622 gcc/cp/ * rtti.c (emit_support_tinfos): Do not iterate on registered_builtin_types (partial revert). libstdc++/ * config/abi/pre/gnu.ver (CXXABI_1.3.9): Remove __float128 symbols. * config/abi/pre/gnu-versioned-namespace.ver: Likewise. * config/abi/post/x86_64-linux-gnu/baseline_symbols.txt: Update. -- Marc GlisseIndex: gcc/cp/rtti.c === --- gcc/cp/rtti.c (revision 209747) +++ gcc/cp/rtti.c (working copy) @@ -1539,22 +1539,20 @@ emit_support_tinfos (void) /*tag_scope=*/ts_current, false); pop_abi_namespace (); if (!COMPLETE_TYPE_P (bltn
Re: [PATCH 02/89] Introduce gimple_switch and use it in various places
On Wed, 2014-04-23 at 13:58 -0600, Jeff Law wrote: > On 04/21/14 10:56, David Malcolm wrote: [...] > So, generally I like it. It looks pretty much like what I'd expect from > this kind of work. > > So it sounds like Richi really prefers the explicit casting rather than > member functions. It seems like a minor issue to me, so let's go with > explicit casting. > > OK for the trunk with that change. Per Richi's request, please hold off > until 4.9.1 goes out the door (~2 months?) Thanks. I see that Richi wants me to investigate ways of doing this without introducing all the typedefs: http://gcc.gnu.org/ml/gcc-patches/2014-04/msg01520.html so I'm not going to commit this without further discussion, but for reference, I'm attaching the port I did of patch 2 to directly use the is-a.h API (i.e. without the casting methods in the base class) [1]. This version of the patch also fixes up the decls in doc/gimple.texi to match the changes in gimple.h [2], and I tweaked some of the hunks to favor dyn_cast over "check the of code, then do an as_a", for example: - else if (gimple_code (stmt) == GIMPLE_SWITCH) -return simplify_switch_using_ranges (stmt); + else if (gimple_switch switch_stmt = dyn_cast (stmt)) +return simplify_switch_using_ranges (switch_stmt); It bootstrapped®rtested on x86_64-unknown-linux-gnu, but as I said above, I'm merely posting this for reference. > Jeff > ps. If/when your work exposes a problem with the existing code base, > please point it out. This is just for my own curiosity than anything. Definitely. Dave [1] specifically, using the revised is-a.h API from r209719. [2] though I wish we were using Doxygen instead, to avoid having to repeat the decls and manually keep them in sync. commit bf955db0ef4f7e86860c1c3d30e435c79abf6c69 Author: David Malcolm Date: Tue Apr 22 16:47:11 2014 -0400 Introduce gimple_switch and use it in various places gcc/ * gimple.h (gimple_statement_switch): New subclass of gimple_statement_with_ops, adding the invariant that stmt->code == GIMPLE_SWITCH. (is_a_helper ::test (gimple)): New. * coretypes.h (gimple_switch): New typedef (const_gimple_switch): Likewise. * gdbhooks.py (build_pretty_printer): Add gimple_switch and its variants, using the gimple printer. * gimple.c (gimple_build_switch_nlabels): Return a gimple_switch rather than just a gimple. (gimple_build_switch): Likewise. * gimple.h (gimple_build_switch_nlabels): Likewise. (gimple_build_switch): Likewise. * gimple.h (gimple_switch_num_labels): Update type-signature to require a gimple_switch rather than just a gimple. (gimple_switch_set_num_labels): Likewise. (gimple_switch_set_index): Likewise. (gimple_switch_label): Likewise. (gimple_switch_set_label): Likewise. (gimple_switch_default_label): Likewise. (gimple_switch_set_default_label): Likewise. * expr.h (expand_case): Likewise. * gimple-pretty-print.c (dump_gimple_call): Likewise. * stmt.c (compute_cases_per_edge): Likewise. (expand_case): Likewise. * tree-cfg.h (group_case_labels_stmt): Likewise. * tree-cfg.c (make_gimple_switch_edges): Likewise. (find_taken_edge_switch_expr) Likewise. (find_case_label_for_value) Likewise. (get_cases_for_edge): Likewise. (group_case_labels_stmt): Likewise. (verify_gimple_switch): Likewise. * tree-eh.c (verify_norecord_switch_expr): Likewise. * tree-eh.c (lower_eh_constructs_2): Likewise. * tree-ssa-forwprop.c (simplify_gimple_switch_label_vec): Likewise. (simplify_gimple_switch): Likewise. * tree-switch-conversion.c (emit_case_bit_tests): Likewise. (collect_switch_conv_info): Likewise. (build_constructors): Likewise. (array_value_type): Likewise. (build_one_array): Likewise. (build_arrays): Likewise. (gen_inbound_check): Likewise. (pass_convert_switch::execute): Likewise. * tree-vrp.c (find_switch_asserts): Likewise. (find_case_label_range): Likewise. (find_case_label_ranges): Likewise. (vrp_visit_switch_stmt): Likewise. (simplify_switch_using_ranges): Likewise. * tree-vrp.c (switch_update): Strengthen field "stmt" from being merely a gimple to being a gimple_switch. * cfgexpand.c (expand_gimple_stmt_1): Add checked cast to gimple_switch in regions where the stmt code has been tested as GIMPLE_SWITCH. * gimple-pretty-print.c (pp_gimple_stmt_1): Likewise. * tree-cfg.c (make_edges): Likewise. (end_recording_case_labels): Likewise. (cleanup_dead_labels): Likewise. (cleanup_dead_labels): Likewise. (group_case_labels): Likewise. (find_case_label_for_value): Likewise. (verify_gimple_stmt): Likewise. (gimple_verify_flow_info): Likewise. (gimple_redirect_edge_and_branch): Likewise. * tree-inline.c (estimate_num_insns): Likewise
Re: [c++] typeinfo for target types
>> Well some of these scalar types are not really user visible which is
>> where I believe the problem is coming from and prima-facie I don't
>> think we should be inventing mangling for some of these "internal"
>> types.
>
>
> If the types are not user-visible, it is not clear to me why they need to be
> registered with the front-end...
The vector types that are built on this are user visible, so I suspect
that's why the scalar types need to be registered with the front-end.
A lot of this comes from the original support for the intrinsics way
that goes quite some time back so there is some digging needed here.
regards
Ramana
>
>
>>> We could
>>> get the mangling functions to take a parameter that says whether errors
>>> should be fatal and skip generating the typeinfo when we can't mangle,
>>> but
>>> there is no convenient way to communicate this mangling failure (0 bytes
>>> written?).
>>>
>>> Would mangling the aarch64 builtins be a lot of work? Did other platforms
>>> break as well?
>>
>>
>> It's not a lot of work but I'd like to make sure we're doing the right
>> thing on both AArch32 and AArch64. So, for now can we just revert this
>> till the thing is sorted out.
>
>
> Ok, I'll commit the attached as soon as I've checked it isn't too broken. It
> is not a complete revert: splitting the rtti function is still cleaner, and
> the int128 symbols are still there.
>
> 2014-04-24 Marc Glisse
>
> PR libstdc++/43622
> gcc/cp/
> * rtti.c (emit_support_tinfos): Do not iterate on
> registered_builtin_types (partial revert).
> libstdc++/
> * config/abi/pre/gnu.ver (CXXABI_1.3.9): Remove __float128 symbols.
> * config/abi/pre/gnu-versioned-namespace.ver: Likewise.
> * config/abi/post/x86_64-linux-gnu/baseline_symbols.txt: Update.
>
> --
> Marc Glisse
> Index: gcc/cp/rtti.c
> ===
> --- gcc/cp/rtti.c (revision 209747)
> +++ gcc/cp/rtti.c (working copy)
> @@ -1539,22 +1539,20 @@ emit_support_tinfos (void)
> /*tag_scope=*/ts_current, false);
>pop_abi_namespace ();
>if (!COMPLETE_TYPE_P (bltn_type))
> return;
>dtor = CLASSTYPE_DESTRUCTORS (bltn_type);
>if (!dtor || DECL_EXTERNAL (dtor))
> return;
>doing_runtime = 1;
>for (ix = 0; fundamentals[ix]; ix++)
> emit_support_tinfo_1 (*fundamentals[ix]);
> - for (tree t = registered_builtin_types; t; t = TREE_CHAIN (t))
> -emit_support_tinfo_1 (TREE_VALUE (t));
> }
>
> /* Finish a type info decl. DECL_PTR is a pointer to an unemitted
> tinfo decl. Determine whether it needs emitting, and if so
> generate the initializer. */
>
> bool
> emit_tinfo_decl (tree decl)
> {
>tree type = TREE_TYPE (DECL_NAME (decl));
> Index: libstdc++-v3/config/abi/post/x86_64-linux-gnu/baseline_symbols.txt
> ===
> --- libstdc++-v3/config/abi/post/x86_64-linux-gnu/baseline_symbols.txt
> (revision 209747)
> +++ libstdc++-v3/config/abi/post/x86_64-linux-gnu/baseline_symbols.txt
> (working copy)
> @@ -2618,21 +2618,20 @@ OBJECT:16:_ZTISt16nested_exception@@CXXA
> OBJECT:16:_ZTISt8ios_base@@GLIBCXX_3.4
> OBJECT:16:_ZTISt9exception@@GLIBCXX_3.4
> OBJECT:16:_ZTISt9time_base@@GLIBCXX_3.4
> OBJECT:16:_ZTISt9type_info@@GLIBCXX_3.4
> OBJECT:16:_ZTIa@@CXXABI_1.3
> OBJECT:16:_ZTIb@@CXXABI_1.3
> OBJECT:16:_ZTIc@@CXXABI_1.3
> OBJECT:16:_ZTId@@CXXABI_1.3
> OBJECT:16:_ZTIe@@CXXABI_1.3
> OBJECT:16:_ZTIf@@CXXABI_1.3
> -OBJECT:16:_ZTIg@@CXXABI_1.3.9
> OBJECT:16:_ZTIh@@CXXABI_1.3
> OBJECT:16:_ZTIi@@CXXABI_1.3
> OBJECT:16:_ZTIj@@CXXABI_1.3
> OBJECT:16:_ZTIl@@CXXABI_1.3
> OBJECT:16:_ZTIm@@CXXABI_1.3
> OBJECT:16:_ZTIn@@CXXABI_1.3.5
> OBJECT:16:_ZTIo@@CXXABI_1.3.5
> OBJECT:16:_ZTIs@@CXXABI_1.3
> OBJECT:16:_ZTIt@@CXXABI_1.3
> OBJECT:16:_ZTIv@@CXXABI_1.3
> @@ -3119,21 +3118,20 @@ OBJECT:2:_ZNSt10ctype_base5printE@@GLIBC
> OBJECT:2:_ZNSt10ctype_base5punctE@@GLIBCXX_3.4
> OBJECT:2:_ZNSt10ctype_base5spaceE@@GLIBCXX_3.4
> OBJECT:2:_ZNSt10ctype_base5upperE@@GLIBCXX_3.4
> OBJECT:2:_ZNSt10ctype_base6xdigitE@@GLIBCXX_3.4
> OBJECT:2:_ZTSa@@CXXABI_1.3
> OBJECT:2:_ZTSb@@CXXABI_1.3
> OBJECT:2:_ZTSc@@CXXABI_1.3
> OBJECT:2:_ZTSd@@CXXABI_1.3
> OBJECT:2:_ZTSe@@CXXABI_1.3
> OBJECT:2:_ZTSf@@CXXABI_1.3
> -OBJECT:2:_ZTSg@@CXXABI_1.3.9
> OBJECT:2:_ZTSh@@CXXABI_1.3
> OBJECT:2:_ZTSi@@CXXABI_1.3
> OBJECT:2:_ZTSj@@CXXABI_1.3
> OBJECT:2:_ZTSl@@CXXABI_1.3
> OBJECT:2:_ZTSm@@CXXABI_1.3
> OBJECT:2:_ZTSn@@CXXABI_1.3.9
> OBJECT:2:_ZTSo@@CXXABI_1.3.9
> OBJECT:2:_ZTSs@@CXXABI_1.3
> OBJECT:2:_ZTSt@@CXXABI_1.3
> OBJECT:2:_ZTSv@@CXXABI_1.3
> @@ -3153,41 +3151,39 @@ OBJECT:32:_ZTIPKDe@@CXXABI_1.3.4
> OBJECT:32:_ZTIPKDf@@CXXABI_1.3.4
> OBJECT:32:_ZTIPKDi@@CXXABI_1.3.3
> OBJECT:32:_ZTIPKDn@@CXXABI_1.3.5
> OBJECT:32:_ZTIPKDs@@CXXABI_1.3.3
> OBJECT:32:_ZTIPKa@@CXXABI_1.3
> OBJECT:32:_ZTIPKb@@CXXABI_1.3
> OBJECT:32:_ZTIPKc@@CXXABI_1.3
> OBJEC
Re: [Committed][ARM][AArch64] Patches previously ok'd for stage1
On 14-04-23 11:38 AM, Kyrill Tkachov wrote: http://gcc.gnu.org/ml/gcc-patches/2014-03/msg00934.html (http://gcc.gnu.org/ml/gcc-patches/2014-03/msg01634.html) This patch breaks building arm-eabi with a 32bit host gcc. e.g ../../gcc/config/arm/aarch-common.c ../../gcc/config/arm/aarch-common.c:198: error: integer constant is too large for 'long' type ../../gcc/config/arm/aarch-common.c:205: error: integer constant is too large for 'long' type ../../gcc/config/arm/t-arm:83: recipe for target 'aarch-common.o' failed make[2]: *** [aarch-common.o] Error 1 Regards, Ryan Mansfield
Re: [Committed][ARM][AArch64] Patches previously ok'd for stage1
On 24/04/14 14:44, Ryan Mansfield wrote: On 14-04-23 11:38 AM, Kyrill Tkachov wrote: http://gcc.gnu.org/ml/gcc-patches/2014-03/msg00934.html (http://gcc.gnu.org/ml/gcc-patches/2014-03/msg01634.html) This patch breaks building arm-eabi with a 32bit host gcc. e.g ../../gcc/config/arm/aarch-common.c ../../gcc/config/arm/aarch-common.c:198: error: integer constant is too large for 'long' type ../../gcc/config/arm/aarch-common.c:205: error: integer constant is too large for 'long' type ../../gcc/config/arm/t-arm:83: recipe for target 'aarch-common.o' failed make[2]: *** [aarch-common.o] Error 1 Should be easy enough to fix by adding ULL suffixes to the literals. I'll look into it. Thanks, Kyrill Regards, Ryan Mansfield
Re: [Committed][ARM][AArch64] Patches previously ok'd for stage1
On Thu, Apr 24, 2014 at 2:54 PM, Kyrill Tkachov wrote:
> On 24/04/14 14:44, Ryan Mansfield wrote:
>>
>> On 14-04-23 11:38 AM, Kyrill Tkachov wrote:
>>>
>>> http://gcc.gnu.org/ml/gcc-patches/2014-03/msg00934.html
>>> (http://gcc.gnu.org/ml/gcc-patches/2014-03/msg01634.html)
>>
>> This patch breaks building arm-eabi with a 32bit host gcc.
>>
>> e.g
>>
>> ../../gcc/config/arm/aarch-common.c
>> ../../gcc/config/arm/aarch-common.c:198: error: integer constant is too
>> large for 'long' type
>> ../../gcc/config/arm/aarch-common.c:205: error: integer constant is too
>> large for 'long' type
>> ../../gcc/config/arm/t-arm:83: recipe for target 'aarch-common.o' failed
>> make[2]: *** [aarch-common.o] Error 1
>
>
> Should be easy enough to fix by adding ULL suffixes to the literals.
> I'll look into it.
No, I suspect you need to investigate using the HOST_WIDE_INT_{U}C
macros so that this is done properly.
Ramana
>
> Thanks,
> Kyrill
>
>>
>> Regards,
>>
>> Ryan Mansfield
>>
>
>
Re: [c++] typeinfo for target types
On Thu, 24 Apr 2014, Ramana Radhakrishnan wrote: Well some of these scalar types are not really user visible which is where I believe the problem is coming from and prima-facie I don't think we should be inventing mangling for some of these "internal" types. If the types are not user-visible, it is not clear to me why they need to be registered with the front-end... The vector types that are built on this are user visible, so I suspect that's why the scalar types need to be registered with the front-end. A lot of this comes from the original support for the intrinsics way that goes quite some time back so there is some digging needed here. Problematic part of the patch was reverted, arm and aarch64 should be ok now. Please do investigate... -- Marc Glisse
Re: [PATCH, AArch64] Enable shuffle on big-endian and turn on the testsuite
Marcus Shawcroft wrote: gcc/ChangeLog: 2014-04-11 Alan Lawrence * config/aarch64/aarch64.c (aarch64_evpc_tbl): enable for bigendian. gcc/testsuite/ChangeLog: 2014-04-11 Alan Lawrence * lib/target-supports.exp (check_effective_target_vect_perm): return true for aarch64_be. ChangeLog entries are sentences, start with a capital, otherwise. OK /Marcus Committed r209749 on trunk for Alan with sentence-case Changelog entries. Thanks Tejas.
[C PATCH] Improve error on attrs after declarator in a fndef (PR c/60915)
This PR is about not very clear error message when one tries to
add attributes *after* the declarator in a function definition.
cc1plus already handles this well, so I used the same message.
Regtested/bootstrapped on x86_64-linux, ok for trunk?
2014-04-24 Marek Polacek
PR c/60915
* c-parser.c (c_parser_declaration_or_fndef): Give better error if
function-definition has an attribute after the declarator.
* gcc.dg/pr60915.c: New test.
diff --git gcc/c/c-parser.c gcc/c/c-parser.c
index 0deab84..a76a7cc 100644
--- gcc/c/c-parser.c
+++ gcc/c/c-parser.c
@@ -1688,7 +1688,19 @@ c_parser_declaration_or_fndef (c_parser *parser, bool
fndef_ok,
if (c_parser_next_token_is_keyword (parser, RID_ASM))
asm_name = c_parser_simple_asm_expr (parser);
if (c_parser_next_token_is_keyword (parser, RID_ATTRIBUTE))
- postfix_attrs = c_parser_attributes (parser);
+ {
+ postfix_attrs = c_parser_attributes (parser);
+ if (c_parser_next_token_is (parser, CPP_OPEN_BRACE))
+ {
+ /* This means there is an attribute specifier after
+the declarator in a function definition. Provide
+some more information for the user. */
+ error_at (here, "attributes are not allowed on a "
+ "function-definition");
+ c_parser_skip_to_end_of_block_or_statement (parser);
+ return;
+ }
+ }
if (c_parser_next_token_is (parser, CPP_EQ))
{
tree d;
diff --git gcc/testsuite/gcc.dg/pr60915.c gcc/testsuite/gcc.dg/pr60915.c
index e69de29..73a6717 100644
--- gcc/testsuite/gcc.dg/pr60915.c
+++ gcc/testsuite/gcc.dg/pr60915.c
@@ -0,0 +1,7 @@
+/* PR c/60915 */
+/* { dg-do compile } */
+
+void /* { dg-error "attributes are not allowed on a function-definition" } */
+foo (void) __attribute__((__visibility__("default")))
+{
+}
Marek
[wide-int] Fix signed min / -1 quotient
For signed min / -1 we set the overflow flag (good) but also returned a
quotient of 0. It should be 0x80...0 instead. Since that's also the
value of the original dividend, we can just copy the representation over.
The value for division by 0 is probably pretty arbitrary. double-int.c
seems to treat it as division by one:
if (hden == 0 && lden == 0)
overflow = 1, lden = 1;
and while not important, it has the nice feature that here too we could
just copy the original dividend, rather than treat it differently from
signed min / -1.
This fixes libjava's Divide_1, which was the last remaining regression
on x86_64-linux-gnu. I have a couple of other patches queued up, but
I'm still running tests to compare the asm output for the gcc and g++
testsuites on a range of targets. (FWIW, the first round of these
tests picked up the same bug as Divide_1, in the output for
gcc.c-torture/compile/20010404-1.c.)
OK to install?
Thanks,
Richard
Index: gcc/wide-int.cc
===
--- gcc/wide-int.cc 2014-04-24 09:51:08.056774754 +0100
+++ gcc/wide-int.cc 2014-04-24 11:52:35.996541888 +0100
@@ -1726,8 +1726,10 @@ wi::divmod_internal (HOST_WIDE_INT *quot
&& wi::only_sign_bit_p (dividend))
overflow = true;
- /* If overflow is set, just get out. There will only be grief by
- continuing. */
+ /* Handle the overflow cases. Viewed as unsigned value, the quotient of
+ (signed min / -1) has the same representation as the orignal dividend.
+ We have traditionally made division by zero act as division by one,
+ so there too we use the original dividend. */
if (overflow)
{
if (remainder)
@@ -1738,8 +1741,9 @@ wi::divmod_internal (HOST_WIDE_INT *quot
if (oflow != 0)
*oflow = true;
if (quotient)
- quotient[0] = 0;
- return 1;
+ for (unsigned int i = 0; i < dividend_len; ++i)
+ quotient[i] = dividend_val[i];
+ return dividend_len;
}
if (oflow)
Re: [PATCH] Fix PR60911
>
> Simple IPA passes are supposed to see function bodies with IPA transforms
> applied - this is what the code in execute_one_pass tries to ensure.
> But that doesn't work anymore with on-demand function-body loading.
> The following addresses this in the least intrusive way - inlining
> do_per_function (apply_ipa_transforms) and adjusting it accordingly.
>
> This IMHO is definitely the solution for the 4.9 branch (and for
> the time being on trunk).
>
> Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
>
> Ok for trunk and branch?
I think it is fine for both 4.9 and mainline. I will try to make better version
for mainline as explained in PR hortly.
Can you, please, double check that it won't load all bodies prior late
optimization
by default?
Looking at gate of pass_omp_simd_clone, perhaps it actually kills late loading
of bodies and perhaps we need to mark in cgraph node whether the given node
needs clonning and page the gate return false if partition has no such unit?
bool
pass_omp_simd_clone::gate (function *)
{
return ((flag_openmp || flag_openmp_simd
|| flag_cilkplus
|| (in_lto_p && !flag_wpa))
&& (targetm.simd_clone.compute_vecsize_and_simdlen != NULL));
}
I did not see there the in_lto_p previously.
Honza
>
> Thanks,
> Richard.
>
> 2014-04-24 Richard Biener
>
> PR ipa/60911
> * passes.c (apply_ipa_transforms): Inline into only caller ...
> (execute_one_pass): ... here. Properly bring in function
> bodies for nodes we want to apply IPA transforms to.
>
> * gcc.dg/lto/pr60911_0.c: New testcase.
>
> Index: gcc/passes.c
> ===
> --- gcc/passes.c (revision 209742)
> +++ gcc/passes.c (working copy)
> @@ -2109,20 +2109,6 @@ execute_all_ipa_transforms (void)
> }
> }
>
> -/* Callback for do_per_function to apply all IPA transforms. */
> -
> -static void
> -apply_ipa_transforms (void *data)
> -{
> - struct cgraph_node *node = cgraph_get_node (current_function_decl);
> - if (!node->global.inlined_to && node->ipa_transforms_to_apply.exists ())
> -{
> - *(bool *)data = true;
> - execute_all_ipa_transforms ();
> - rebuild_cgraph_edges ();
> -}
> -}
> -
> /* Check if PASS is explicitly disabled or enabled and return
> the gate status. FUNC is the function to be processed, and
> GATE_STATUS is the gate status determined by pass manager by
> @@ -2194,8 +2180,26 @@ execute_one_pass (opt_pass *pass)
> Apply all trnasforms first. */
>if (pass->type == SIMPLE_IPA_PASS)
> {
> + struct cgraph_node *node;
>bool applied = false;
> - do_per_function (apply_ipa_transforms, (void *)&applied);
> + FOR_EACH_DEFINED_FUNCTION (node)
> + if (node->analyzed
> + && cgraph_function_with_gimple_body_p (node)
> + && (!node->clone_of || node->decl != node->clone_of->decl))
> + {
> + if (!node->global.inlined_to
> + && node->ipa_transforms_to_apply.exists ())
> + {
> + cgraph_get_body (node);
> + push_cfun (DECL_STRUCT_FUNCTION (node->decl));
> + execute_all_ipa_transforms ();
> + rebuild_cgraph_edges ();
> + free_dominance_info (CDI_DOMINATORS);
> + free_dominance_info (CDI_POST_DOMINATORS);
> + pop_cfun ();
> + applied = true;
> + }
> + }
>if (applied)
> symtab_remove_unreachable_nodes (true, dump_file);
>/* Restore current_pass. */
> Index: gcc/testsuite/gcc.dg/lto/pr60911_0.c
> ===
> --- gcc/testsuite/gcc.dg/lto/pr60911_0.c (revision 0)
> +++ gcc/testsuite/gcc.dg/lto/pr60911_0.c (working copy)
> @@ -0,0 +1,21 @@
> +// { dg-lto-do run }
> +// { dg-lto-options { { -O2 -flto -fipa-pta } } }
> +
> +int __attribute__ ((__noinline__)) f (unsigned *p, int *x)
> +{
> + int y = *p++ & 0xfff;
> + *x++ = y;
> + *x = *p;
> + return y;
> +}
> +
> +int
> +main ()
> +{
> + unsigned u[2] = { 0x3aad, 0x5ad1 };
> + int x[2] = { 17689, 23456 };
> +
> + if (f (u, x) != 0xaad || x[0] != 0xaad || x[1] != 0x5ad1)
> +__builtin_abort ();
> + return 0;
> +}
Re: [wide-int] Fix signed min / -1 quotient
This is fine with me.
kenny
On 04/24/2014 10:34 AM, Richard Sandiford wrote:
For signed min / -1 we set the overflow flag (good) but also returned a
quotient of 0. It should be 0x80...0 instead. Since that's also the
value of the original dividend, we can just copy the representation over.
The value for division by 0 is probably pretty arbitrary. double-int.c
seems to treat it as division by one:
if (hden == 0 && lden == 0)
overflow = 1, lden = 1;
and while not important, it has the nice feature that here too we could
just copy the original dividend, rather than treat it differently from
signed min / -1.
This fixes libjava's Divide_1, which was the last remaining regression
on x86_64-linux-gnu. I have a couple of other patches queued up, but
I'm still running tests to compare the asm output for the gcc and g++
testsuites on a range of targets. (FWIW, the first round of these
tests picked up the same bug as Divide_1, in the output for
gcc.c-torture/compile/20010404-1.c.)
OK to install?
Thanks,
Richard
Index: gcc/wide-int.cc
===
--- gcc/wide-int.cc 2014-04-24 09:51:08.056774754 +0100
+++ gcc/wide-int.cc 2014-04-24 11:52:35.996541888 +0100
@@ -1726,8 +1726,10 @@ wi::divmod_internal (HOST_WIDE_INT *quot
&& wi::only_sign_bit_p (dividend))
overflow = true;
- /* If overflow is set, just get out. There will only be grief by
- continuing. */
+ /* Handle the overflow cases. Viewed as unsigned value, the quotient of
+ (signed min / -1) has the same representation as the orignal dividend.
+ We have traditionally made division by zero act as division by one,
+ so there too we use the original dividend. */
if (overflow)
{
if (remainder)
@@ -1738,8 +1741,9 @@ wi::divmod_internal (HOST_WIDE_INT *quot
if (oflow != 0)
*oflow = true;
if (quotient)
- quotient[0] = 0;
- return 1;
+ for (unsigned int i = 0; i < dividend_len; ++i)
+ quotient[i] = dividend_val[i];
+ return dividend_len;
}
if (oflow)
Re: [PATCH 00/89] Compile-time gimple-checking
Hi, On Thu, 24 Apr 2014, Andrew MacLeod wrote: > Well, we ought to settle on one... either use the is_a, as_a, and > dyn_cast paradigm as they exist today, or we use the cast_as_method > approach everywhere. I'm not fond of each potential project having a > different approach... I'd like to see a consistent look throughout. > > I suspect the cast_as_method has compile time advantages, as well as > error reporting ones (have you seen the kind of message you get when > the template instantiation doesn't work right? ick!) , but it suffers > from having to modify the base class whenever a new derived class is > added... Well, when adding new derived classes is such a frequent event that this would be of any worry, then we have much more difficult problems. Adding types should be a well thought out and hence rare event. > (which seems a little "dirty" and could impact possible future > enhancements). Perhaps dirty from some artificial language cleanliness perspective (although why would methods be regarded as dirty?). I call it pragmatic and visually undisturbing. Ciao, Michael.
Examples of gimple statement API (was Re: [PATCH 03/89] Introduce gimple_bind and use it for accessors.)
On Thu, 2014-04-24 at 09:09 -0400, Andrew MacLeod wrote:
> On 04/24/2014 04:33 AM, Richard Biener wrote:
> > On Wed, Apr 23, 2014 at 11:23 PM, Jeff Law wrote:
> >> On 04/23/14 15:13, David Malcolm wrote:
> >>> On Wed, 2014-04-23 at 15:04 -0600, Jeff Law wrote:
> On 04/21/14 10:56, David Malcolm wrote:
> > This updates all of the gimple_bind_* accessors in gimple.h from taking
> > a
> > plain gimple to taking a gimple_bind (or const_gimple_bind), with the
> > checking happening at the point of cast.
> >
> > Various other types are strengthened from gimple to gimple_bind, and
> > from
> > plain vec to vec.
> >>>
> >>> [...]
> >>>
> This is fine, with the same requested changes as #2; specifically using
> an explicit cast rather than hiding the conversion in a method. Once
> those changes are in place, it's good for 4.9.1.
> >>> Thanks - presumably you mean
> >>> "good for *trunk* after 4.9.1 is released"
> >> Right. Sorry for the confusion.
> > Note I still want that less-typedefs (esp. the const_*) variants to be
> > explored.
> > Changing this will touch all the code again, so I'd like to avoid that.
> >
> > That is, shouldn't we go back to 'gimple' being 'gimple_statement_base'
> > and not 'gimple_statement_base *'? The main reason that we have so
> > many typedefs is that in C you had to use 'struct foo' each time you
> > refer to foo as a type - I suppose it was then convenient to do the
> > typedef to the pointer type. With 'gimple' being not a pointer type
> > we get const correctness in the way people would expect it to work.
> > [no, I don't suggest you change 'tree' or 'const_tree' at this point, just
> > gimple (and maybe gimple_seq) as you are working on the 'gimple'
> > type anyway].
> >
> >
>
> So if we change 'gimple' everywhere to be 'gimple *', can we just
> abandon the 'gimple' typedef completely and go directly to using
> something like gimple_stmt, or some other agreeable name instead?
>
> I think its more descriptive and then frees up the generic 'gimple' name
> should we decide to do something more with namespaces in the future...
There have been a few different proposals as to what the resulting
gimple API might look like, in various subthreads of this discusssion,
so I thought it might help the discussion to gather up the proposals,
and to apply them to some specific code examples, to see what the
results might look like.
So here are a couple of code fragments, from gcc/graphite-sese-to-poly.c
and gcc/tree-ssa-uninit.c respectively:
Status quo
==
static gimple
detect_commutative_reduction (scop_p scop, gimple stmt, vec *in,
vec *out)
{
if (scalar_close_phi_node_p (stmt))
{
gimple def, loop_phi, phi, close_phi = stmt;
tree init, lhs, arg = gimple_phi_arg_def (close_phi, 0);
if (TREE_CODE (arg) != SSA_NAME)
/* ...etc... */
static unsigned int
execute_late_warn_uninitialized (void)
{
basic_block bb;
gimple_stmt_iterator gsi;
vec worklist = vNULL;
pointer_set_t *added_to_worklist;
The currently-posted patch series
=
Here's the cumulative effect of the patch series I posted, using the
casting methods of the base class (the "stmt->as_a_gimple_phi" call):
-static gimple
+static gimple_phi
detect_commutative_reduction (scop_p scop, gimple stmt, vec *in,
vec *out)
{
if (scalar_close_phi_node_p (stmt))
{
- gimple def, loop_phi, phi, close_phi = stmt;
+ gimple def;
+ gimple_phi loop_phi, phi, close_phi = stmt->as_a_gimple_phi ();
tree init, lhs, arg = gimple_phi_arg_def (close_phi, 0);
if (TREE_CODE (arg) != SSA_NAME)
/* ...etc... */
execute_late_warn_uninitialized (void)
{
basic_block bb;
- gimple_stmt_iterator gsi;
- vec worklist = vNULL;
+ gimple_phi_iterator gsi;
+ vec worklist = vNULL;
pointer_set_t *added_to_worklist;
Direct use of is-a.h, retaining typedefs of pointers
The following patch shows what the above might look like using the patch
series as posted, but eliminating the casting methods in favor of
direct use of the is-a.h API (but still using lots of typedefs of
pointers):
-static gimple
+static gimple_phi
detect_commutative_reduction (scop_p scop, gimple stmt, vec *in,
vec *out)
{
if (scalar_close_phi_node_p (stmt))
{
- gimple def, loop_phi, phi, close_phi = stmt;
- tree init, lhs, arg = gimple_phi_arg_def (close_phi, 0);
+ gimple def;
+ gimple_phi loop_phi, phi, close_phi = as_a (stmt);
tree init, lhs, arg = gimple_phi_arg_def (close_phi, 0);
if (TREE_CODE (arg) != SSA_NAME)
/* ...etc... */
static unsigned int
execute_late_warn_uninitialized
Re: Add clobber_reg
> Richard Sandiford mentioned here ( > http://gcc.gnu.org/ml/gcc-patches/2014-04/msg00870.html ): > ... > Although we really should have a utility function like use_reg, but for > clobbers, so that the above would become: > >clobber_reg (&CALL_INSN_FUNCTION_USAGE (insn), gen_rtx_REG (word_mode, > 18)); ... > > > I've implemented a patch that adds clobber_reg and clobber_reg_mode, similar > to use_reg and use_reg_mode. Good idea indeed. > 2014-04-18 Tom de Vries > > * expr.c (clobber_reg_mode): New function. > * expr.h (clobber_reg): New function. OK, thanks. -- Eric Botcazou
Re: Add post_expand_call_insn hook
> The hook is called right after expansion of calls, and allows a target to do > additional processing, such as f.i. adding clobbers to > CALL_INSN_FUNCTION_USAGE. > > Instead of using the hook, we could add code to the preparation statements > operand of the different call expands, but that requires those expands not > to use the rtl template, and generate all the rtl through c code. Which > requires a rewrite of the call expands in case of Aarch64. If Aarch64 is the only problematic back-end, then it should be changed to do what the other back-ends already do to use use_reg. IMO adding such a bogus hook should be the very last resort solution. -- Eric Botcazou
Re: [c++] typeinfo for target types
Marc Glisse wrote: On Thu, 24 Apr 2014, Ramana Radhakrishnan wrote: On Wed, Apr 23, 2014 at 8:43 PM, Marc Glisse wrote: On Wed, 23 Apr 2014, Richard Henderson wrote: On 04/13/2014 01:41 AM, Marc Glisse wrote: Hello, this patch generates typeinfo for target types. On x86_64, it adds these 6 lines to nm -C libsupc++.a. A follow-up patch will be needed to export and version those in the shared library. + V typeinfo for __float128 + V typeinfo for __float128 const* + V typeinfo for __float128* + V typeinfo name for __float128 + V typeinfo name for __float128 const* + V typeinfo name for __float128* Bootstrap and testsuite on x86_64-linux-gnu (a bit of noise in tsan/tls_race.c). 2014-04-13 Marc Glisse PR libstdc++/43622 gcc/c-family/ * c-common.c (registered_builtin_types): Make non-static. * c-common.h (registered_builtin_types): Declare. gcc/cp/ * rtti.c (emit_support_tinfo_1): New function, extracted from emit_support_tinfos. (emit_support_tinfos): Call it and iterate on registered_builtin_types. This is causing aarch64 builds to break. If it is causing too much trouble, we could ifdef out the last 2 lines of emit_support_tinfos and revert the libstdc++ changes (or even revert the whole thing). Any c++ compilation aborts at That's surprising, the code I touched is only ever supposed to run while compiling one file in libsupc++, if I understand correctly. #0 fancy_abort (file=0x14195c8 "../../git-rh/gcc/cp/mangle.c", line=2303, function=0x1419ff8 "write_builtin_type") at ../../git-rh/gcc/diagnostic.c:1190 #1 0x007ce2b4 in write_builtin_type ( type=) at ../../git-rh/gcc/cp/mangle.c:2303 #2 0x007cc85c in write_type ( type=) at ../../git-rh/gcc/cp/mangle.c:1969 #3 0x007d4d98 in mangle_special_for_type ( type=, code=0x1419a98 "TI") at ../../git-rh/gcc/cp/mangle.c:3569 #4 0x007d4dcc in mangle_typeinfo_for_type ( type=) at ../../git-rh/gcc/cp/mangle.c:3585 #5 0x0070618c in get_tinfo_decl ( type=) at ../../git-rh/gcc/cp/rtti.c:422 #6 0x00709ff0 in emit_support_tinfo_1 ( bltn=) at ../../git-rh/gcc/cp/rtti.c:1485 #7 0x0070a344 in emit_support_tinfos () at ../../git-rh/gcc/cp/rtti.c:1550 Presumably the backend needs to grow some mangling support for its builtins, aarch64 has complicated builtins... __builtin_aarch64_simd_df uses double_aarch64_type_node which is not the same as double_type_node. I mostly looked at the x86 backend, so I didn't notice that aarch64 registers a lot more builtins. but in the meantime can we do something less drastic than abort? Sounds good, but I am not sure how exactly. We could use a separate hook (register_builtin_type_for_typeinfo?) so back-ends have to explicitly say they want typeinfo, but it is ugly having to register types multiple times. We could add a parameter to the existing register_builtin_type saying whether we want typeinfo, but that means updating all back-ends. We could also make typeinfo_in_lib_p more strict so for REAL_TYPE it only returns true for the types listed in fundamentals. Well some of these scalar types are not really user visible which is where I believe the problem is coming from and prima-facie I don't think we should be inventing mangling for some of these "internal" types. If the types are not user-visible, it is not clear to me why they need to be registered with the front-end... That's probably because of the way they are used in typedefs in arm_neon.h to build vector types and also them being used as internal base-type names to look up the mangling table. Perhaps a cleaner solution is to build only the vector types in terms of standard base-types and not have to define back-end-specific scalar types just to build their vector types. That will also mean changing how the mangling names are looked up ARM/AArch64 backend... Tejas. We could get the mangling functions to take a parameter that says whether errors should be fatal and skip generating the typeinfo when we can't mangle, but there is no convenient way to communicate this mangling failure (0 bytes written?). Would mangling the aarch64 builtins be a lot of work? Did other platforms break as well? It's not a lot of work but I'd like to make sure we're doing the right thing on both AArch32 and AArch64. So, for now can we just revert this till the thing is sorted out. Ok, I'll commit the attached as soon as I've checked it isn't too broken. It is not a complete revert: splitting the rtti function is still cleaner, and the int128 symbols are still there. 2014-04-24 Marc Glisse PR libstdc++/43622 gcc/cp/ * rtti.c (emit_support_tinfos): Do not iterate on registered_builtin_types (partial revert). libstdc++/ * config/abi/pre/gnu.ver (CXXABI_1.3.9): Remove __float128 symbols.
Re: [4.9.1 RFA] [tree-optimization/60902] Invalidate outputs of GIMPLE_ASMs when threading around loops
On 04/24/14 02:22, Richard Biener wrote: + + if (backedge_seen) + FOR_EACH_SSA_TREE_OPERAND (op, stmt, iter, SSA_OP_ALL_DEFS) You only need SSA_OP_DEF here, no need to process virtual operands. I went back and forth on this. I couldn't come up with a case where we'd do the wrong thing with virtuals, but processing all the DEFs is conservatively correct, so I left it. If you'd like to see this changed to only walk the real defs, I'm happy to make that change. jeff
Re: [Patch] Fix a typo in Chinese msg
On 04/24/14 01:23, Jincheng Miao wrote: There is a minor typo in zh_CN.po, should change '-pic' to '-fpic'. Best wishes, Jincheng Miao Thanks. Applied to the trunk. jeff
Re: [Patch] Fix a bug of consecutive range quantifiers in regex
On Thu, Apr 24, 2014 at 6:56 AM, Jonathan Wakely wrote:
> Unless I'm doing something wrong the new tests you added already give
> the right results, do you have a testcase that fails with the current
> code?
This testcase fails before the patch. Sorry for that.
--
Regards,
Tim Shen
commit f3339263db7aad7cb78fc9232d8de7752a47e66d
Author: tim
Date: Wed Apr 23 00:56:21 2014 -0400
2014-04-24 Tim Shen
* include/bits/regex_automaton.tcc (_StateSeq<>::_M_clone()):
Do _M_alt before _M_next.
* testsuite/28_regex/basic_regex/multiple_quantifiers.cc: Add testcases.
diff --git a/libstdc++-v3/include/bits/regex_automaton.tcc
b/libstdc++-v3/include/bits/regex_automaton.tcc
index 759b053..1476ae2 100644
--- a/libstdc++-v3/include/bits/regex_automaton.tcc
+++ b/libstdc++-v3/include/bits/regex_automaton.tcc
@@ -197,20 +197,18 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
// _M_insert_state() never return -1
auto __id = _M_nfa._M_insert_state(__dup);
__m[__u] = __id;
- if (__u == _M_end)
- continue;
- if (__dup._M_next != _S_invalid_state_id && __m[__dup._M_next] == -1)
- __stack.push(__dup._M_next);
if (__dup._M_opcode == _S_opcode_alternative
|| __dup._M_opcode == _S_opcode_subexpr_lookahead)
if (__dup._M_alt != _S_invalid_state_id && __m[__dup._M_alt] == -1)
__stack.push(__dup._M_alt);
+ if (__u == _M_end)
+ continue;
+ if (__dup._M_next != _S_invalid_state_id && __m[__dup._M_next] == -1)
+ __stack.push(__dup._M_next);
}
- long __size = static_cast(__m.size());
- for (long __k = 0; __k < __size; __k++)
+ for (auto __v : __m)
{
- long __v;
- if ((__v = __m[__k]) == -1)
+ if (__v == -1)
continue;
auto& __ref = _M_nfa[__v];
if (__ref._M_next != _S_invalid_state_id)
diff --git
a/libstdc++-v3/testsuite/28_regex/basic_regex/multiple_quantifiers.cc
b/libstdc++-v3/testsuite/28_regex/basic_regex/multiple_quantifiers.cc
index 5670cbb..8243eea 100644
--- a/libstdc++-v3/testsuite/28_regex/basic_regex/multiple_quantifiers.cc
+++ b/libstdc++-v3/testsuite/28_regex/basic_regex/multiple_quantifiers.cc
@@ -21,7 +21,10 @@
// Tests multiple consecutive quantifiers
#include
+#include
+#include
+using namespace __gnu_test;
using namespace std;
int
@@ -29,5 +32,6 @@ main()
{
regex re1("a++");
regex re2("(a+)+");
+ VERIFY(regex_match_debug("aa", regex("(a)*{3}")));
return 0;
}
Re: [PATCH] Add a couple of dialect and warning options regarding Objective-C instance variable scope
On Feb 6, 2014, at 1:25 AM, Dimitris Papavasiliou wrote: > This is a patch regarding a couple of Objective-C related dialect options and > warning switches. Ok. Committed revision 209753. If you could, please add documentation and a test case.
Re: Examples of gimple statement API (was Re: [PATCH 03/89] Introduce gimple_bind and use it for accessors.)
Hi, On Thu, 24 Apr 2014, David Malcolm wrote: > Implicit naming > === > Several people have suggested that the "gimple_" prefix is redundant. Not generally though (for instance I find it redundant in the cast-method names, but _not_ in the global types). > Andrew MacLeod suggested in: > http://gcc.gnu.org/ml/gcc-patches/2014-04/msg01297.html > that we could simple drop the "gimple_" prefix. Combining this with the > pointer approach, for example, gives: > > - gimple def, loop_phi, phi, close_phi = stmt; > - tree init, lhs, arg = gimple_phi_arg_def (close_phi, 0); > + gimple *def; > + phi *loop_phi, *phi, *close_phi = as_a (stmt); That is, I'm not fond of a global type named just "phi" or "bind" or "assign". There the gimple_ prefix is sort of fine, we could perhaps trade it for a _t suffix though (phi_t, assign_t? hmm don't know, still feels too broad). But for method names (that necessarily don't conflict with method names from other classes or even just with local variable names) such prefixes are useless. For similar reasons I find the "as_a_" prefix too verbose in method names, "as_" is enough to convey the meaning. OTOH the awkward _a suffix is necessary for the globally named templates to not clash with single word names of local variable like "as" or "is". That is, methods simply can be named much more sensible and still be shorter than global entities as they always carry class context with them. I'm sorta fond of methods :) Ciao, Michael.
Re: [Committed][ARM][AArch64] Patches previously ok'd for stage1
On 24/04/14 14:44, Ryan Mansfield wrote:
On 14-04-23 11:38 AM, Kyrill Tkachov wrote:
http://gcc.gnu.org/ml/gcc-patches/2014-03/msg00934.html
(http://gcc.gnu.org/ml/gcc-patches/2014-03/msg01634.html)
This patch breaks building arm-eabi with a 32bit host gcc.
Hi Ryan,
Does this patch fix it for you?
I'll test and bootstrap it on arm.
Kyrill
2014-04-24 Kyrylo Tkachov
* config/arm/aarch-common.c (aarch_rev16_shright_mask_imm_p):
Use HOST_WIDE_INT_C for mask literal.
(aarch_rev16_shleft_mask_imm_p): Likewise.
e.g
../../gcc/config/arm/aarch-common.c
../../gcc/config/arm/aarch-common.c:198: error: integer constant is too
large for 'long' type
../../gcc/config/arm/aarch-common.c:205: error: integer constant is too
large for 'long' type
../../gcc/config/arm/t-arm:83: recipe for target 'aarch-common.o' failed
make[2]: *** [aarch-common.o] Error 1
Regards,
Ryan Mansfield
commit 83b40d14694e0c89f293f19071f006c11a54ad22
Author: Kyrylo Tkachov
Date: Thu Apr 24 15:33:57 2014 +0100
[ARM] Use HOST_WIDE_INT_C
diff --git a/gcc/config/arm/aarch-common.c b/gcc/config/arm/aarch-common.c
index 884d4b3..d31191a 100644
--- a/gcc/config/arm/aarch-common.c
+++ b/gcc/config/arm/aarch-common.c
@@ -195,14 +195,18 @@ bool
aarch_rev16_shright_mask_imm_p (rtx val, enum machine_mode mode)
{
return CONST_INT_P (val)
- && INTVAL (val) == trunc_int_for_mode (0xff00ff00ff00ff, mode);
+ && INTVAL (val)
+== trunc_int_for_mode (HOST_WIDE_INT_C (0xff00ff00ff00ff),
+ mode);
}
bool
aarch_rev16_shleft_mask_imm_p (rtx val, enum machine_mode mode)
{
return CONST_INT_P (val)
- && INTVAL (val) == trunc_int_for_mode (0xff00ff00ff00ff00, mode);
+ && INTVAL (val)
+== trunc_int_for_mode (HOST_WIDE_INT_C (0xff00ff00ff00ff00),
+ mode);
}
[PATCH, trunk, 4.9, 4.8] Fix PR57653, filename information discarded when using -imacros
Allan reported this, but we've had people report the same issue to us.
Manuel supplied the patch, but couldn't bootstrap and regtest it.
He did have a question of whether this was the "correct" fix:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57653#c18
...so I thought I could at least bootstrap and regtest the patch, which I have
done on trunk, 4.9 and the 4.8 branches. They all passed with not regressions.
I can also confirm that the patch fixes the error Allan and we are seeing.
Although, I will note that I needed a fairly new distro installed to
see this. With an older distro (glibc?), the error doesn't recreate.
Can someone please review Manuel's patch for correctness? If it's ok,
Manuel can you commit this to trunk and the branches? Or do you want
me to commit it for you?
I will note that I attempted to create a testsuite test case for this,
but dg-error and dg-message both seem to only allow you to match the
error output after the line #/row #, so it seems impossible to test
for this. If someone has any suggestions on how a test case can be
written, I'm willing to try it.
Peter
PR c/57653
* c-family/c-opts.c:
Index: gcc/c-family/c-opts.c
===
--- gcc/c-family/c-opts.c (revision 209715)
+++ gcc/c-family/c-opts.c (working copy)
@@ -1357,6 +1357,10 @@
static void
push_command_line_include (void)
{
+ // This can happen if disabled by -imacros for example.
+ if (include_cursor > deferred_count)
+return;
+
if (!done_preinclude)
{
done_preinclude = true;
[PATCH] Fix PR60930
Hi,
PR60930 exposes an SLSR problem with a fold. When multiplying two
constants to create a new stride, the result must fit in the stride type
for the computation or the fold is invalid.
Bootstrapped and tested on powerpc64le-unknown-linux-gnu with no
regressions. The same patch applies equally to 4.8, 4.9, and trunk. Is
this ok for trunk (and for 4.8/4.9 after a suitable burn-in period)?
Thanks,
Bill
[gcc]
2014-04-24 Bill Schmidt
PR tree-optimization/60930
* gimple-ssa-strength-reduction.c (create_mul_imm_cand): Reject
creating a multiply candidate by folding two constant
multiplicands when the result overflows.
[gcc/testsuite]
2014-04-24 Bill Schmidt
PR tree-optimization/60930
* gcc.dg/torture/pr60930.c: New test.
Index: gcc/gimple-ssa-strength-reduction.c
===
--- gcc/gimple-ssa-strength-reduction.c (revision 209714)
+++ gcc/gimple-ssa-strength-reduction.c (working copy)
@@ -1114,15 +1114,18 @@ create_mul_imm_cand (gimple gs, tree base_in, tree
X = Y * c
X = (B + i') * (S * c) */
- base = base_cand->base_expr;
- index = base_cand->index;
temp = tree_to_double_int (base_cand->stride)
* tree_to_double_int (stride_in);
- stride = double_int_to_tree (TREE_TYPE (stride_in), temp);
- ctype = base_cand->cand_type;
- if (has_single_use (base_in))
- savings = (base_cand->dead_savings
- + stmt_cost (base_cand->cand_stmt, speed));
+ if (double_int_fits_to_tree_p (TREE_TYPE (stride_in), temp))
+ {
+ base = base_cand->base_expr;
+ index = base_cand->index;
+ stride = double_int_to_tree (TREE_TYPE (stride_in), temp);
+ ctype = base_cand->cand_type;
+ if (has_single_use (base_in))
+ savings = (base_cand->dead_savings
+ + stmt_cost (base_cand->cand_stmt, speed));
+ }
}
else if (base_cand->kind == CAND_ADD && integer_onep (base_cand->stride))
{
Index: gcc/testsuite/gcc.dg/torture/pr60930.c
===
--- gcc/testsuite/gcc.dg/torture/pr60930.c (revision 0)
+++ gcc/testsuite/gcc.dg/torture/pr60930.c (working copy)
@@ -0,0 +1,20 @@
+/* { dg-do run } */
+
+int x = 1;
+
+__attribute__((noinline, noclone)) void
+foo (unsigned long long t)
+{
+ asm volatile ("" : : "r" (&t));
+ if (t == 1)
+__builtin_abort ();
+}
+
+int
+main ()
+{
+ unsigned long long t = 0xULL * (0xUL * x);
+ if (t != 0x0001ULL)
+foo (t);;
+ return 0;
+}
Re: [Patch] Fix a bug of consecutive range quantifiers in regex
On 24/04/14 11:49 -0400, Tim Shen wrote: This testcase fails before the patch. Sorry for that. Great, thanks - OK for trunk. Assuming no problems on the trunk we might want to backport it for 4.9.1 in a few weeks.
Re: [Committed][ARM][AArch64] Patches previously ok'd for stage1
On 14-04-24 12:12 PM, Kyrill Tkachov wrote: On 24/04/14 14:44, Ryan Mansfield wrote: On 14-04-23 11:38 AM, Kyrill Tkachov wrote: http://gcc.gnu.org/ml/gcc-patches/2014-03/msg00934.html (http://gcc.gnu.org/ml/gcc-patches/2014-03/msg01634.html) This patch breaks building arm-eabi with a 32bit host gcc. Hi Ryan, Does this patch fix it for you? I'll test and bootstrap it on arm. Kyrill 2014-04-24 Kyrylo Tkachov * config/arm/aarch-common.c (aarch_rev16_shright_mask_imm_p): Use HOST_WIDE_INT_C for mask literal. (aarch_rev16_shleft_mask_imm_p): Likewise. Yes, your patch resolves the build issues. Thanks. Regards, Ryan Mansfield
Re: [Committed][ARM][AArch64] Patches previously ok'd for stage1
On 24/04/14 17:46, Ryan Mansfield wrote: On 14-04-24 12:12 PM, Kyrill Tkachov wrote: On 24/04/14 14:44, Ryan Mansfield wrote: On 14-04-23 11:38 AM, Kyrill Tkachov wrote: http://gcc.gnu.org/ml/gcc-patches/2014-03/msg00934.html (http://gcc.gnu.org/ml/gcc-patches/2014-03/msg01634.html) This patch breaks building arm-eabi with a 32bit host gcc. Hi Ryan, Does this patch fix it for you? I'll test and bootstrap it on arm. Kyrill 2014-04-24 Kyrylo Tkachov * config/arm/aarch-common.c (aarch_rev16_shright_mask_imm_p): Use HOST_WIDE_INT_C for mask literal. (aarch_rev16_shleft_mask_imm_p): Likewise. Yes, your patch resolves the build issues. Thanks. Thanks for testing. Regtest on cross arm-none-eabi passes. Bootstrap in progress. Ok to commit if no issues then? Kyrill Regards, Ryan Mansfield
[PATCH] Step down as a gengtype reviewer
Even though gengtype patches needing review are quite rare, I am unable to review quickly enough those few that do come. Thus stepping down, the patch below is committed. Index: ChangeLog === --- ChangeLog (revision 209731) +++ ChangeLog (working copy) @@ -1,3 +1,8 @@ +2014-04-24 Laurynas Biveinis + + * MAINTAINERS: Move myself from Reviewers to Write After Approval + section. + 2014-04-21 Rafael Ávila de Espíndola * MAINTAINERS (Write After Approval): Delete myself. Index: MAINTAINERS === --- MAINTAINERS (revision 209731) +++ MAINTAINERS (working copy) @@ -280,7 +280,6 @@ Fortran Tobias Schlüter tobias.schlue...@physik.uni-muenchen.de Fortran Paul Thomas pa...@gcc.gnu.org Fortran Janus Weil ja...@gcc.gnu.org -gengtype/GTY Laurynas Biveinis laurynas.bivei...@gmail.com Graphite Daniel Berlin dber...@dberlin.org Graphite Tobias Grosser gros...@fim.uni-passau.de Graphite Sebastian Pop sebastian@amd.com @@ -323,6 +322,7 @@ Jan Beulich jbeul...@novell.com David Billinghurst david.billinghu...@riotinto.com Tomas Bily tb...@suse.cz +Laurynas Biveinis laurynas.bivei...@gmail.com Eric Blake er...@gcc.gnu.org Phil Blundell p...@futuretv.com Hans Boehm hbo...@gcc.gnu.org -- Laurynas
[Patch] Fix crtstuff.c compilation with mingw build.
I sent an earlier patch to change how GCC configure was setting default values of caddr_t and ssize_t. That patch fixed a build problem I had when building GCC for Windows using the mingw tools but only because my patch was wrong. Here is a new patch to fix the problem. The problem was that crtstuff.c would not compile because it saw two different (incompatible) definitions of caddr_t, one coming from auto-host.h (set by the configure script) and one coming from the sys/types.h system header file (part of glibc in my case). Since crtstuff.c doesn't actually need or use caddr_t my patch undef's it after including auto-host.h in the same way that pid_t, rlim_t, ssize_t, and vfork are already undef'ed. Note that there is a FIXME in crtstuff that says including auto-host is wrong, but I don't have a fix for that larger issue. Tested with my mingw build and a linux based mips toolchain. OK to checkin? Steve Ellcey sell...@mips.com 2014-04-24 Steve Ellcey * crtstuff.c: Undef caddr_t. diff --git a/libgcc/crtstuff.c b/libgcc/crtstuff.c index 12bed4b..d09455f 100644 --- a/libgcc/crtstuff.c +++ b/libgcc/crtstuff.c @@ -54,6 +54,7 @@ see the files COPYING3 and COPYING.RUNTIME respectively. If not, see #include "auto-host.h" #undef pid_t #undef rlim_t +#undef caddr_t #undef ssize_t #undef vfork #include "tconfig.h"
Re: version typeinfo for 128bit types
Marc Glisse writes: > this is a follow-up for this patch: > http://gcc.gnu.org/ml/gcc-patches/2014-04/msg00618.html > > once committed, g++ will generate typeinfo for __float128, and it needs > versioning. While there, I noticed that __int128 has "typeinfo" but not > "typeinfo name", so I am adding it. I manually checked that the new symbols > were exactly the 12 I expected, with the new version number. > > I did not test the gnu-versioned-namespace version. > > I manually updated baseline for x86_64. It is awfully inconvenient to do. I > was expecting "make new-abi-baseline" to generate it for me, but it gives > me plenty of extra symbols compared to the current one. Some random > examples: It shouldn't be necessary to update all baselines whenever you add a new version to libstdc++.so.6. It seems to me that when you added CXXABI_1.3.9, you forgot to update libstdc++-v3/testsuite/util/testsuite_abi.cc for that. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [Patch] Fix obsolete autoconf macros in configure.ac
On Thu, 2014-04-24 at 10:23 +0200, Richard Biener wrote: > >> > +AC_CHECK_TYPES([ssize_t]) > >> > +AC_CHECK_TYPES([caddr_t]) > > > > But I am not sure what header file this code would go in. > > In system.h. > > > Steve Ellcey FYI: I ran into problems defining ssize_t and caddr_t in system.h because it was causing more typedef conflicts during the build. I have come up with a new fix for my mingw build problem and submitted that new patch to gcc-patches. http://gcc.gnu.org/ml/gcc-patches/2014-04/msg01577.html Steve Ellcey sell...@mips.com
RE: [PATCH, ARM] Suppress Redundant Flag Setting for Cortex-A15
> Hi, > > On 28 January 2014 13:10, Ramana Radhakrishnan > wrote: > > On Fri, Jan 24, 2014 at 5:16 PM, Ian Bolton > wrote: > >> Hi there! > >> > >> An existing optimisation for Thumb-2 converts t32 encodings to > >> t16 encodings to reduce codesize, at the expense of causing > >> redundant flag setting for ADD, AND, etc. This redundant flag > >> setting can have negative performance impact on cortex-a15. > >> > >> This patch introduces two new tuning options so that the conversion > >> from t32 to t16, which takes place in thumb2_reorg, can be > suppressed > >> for cortex-a15. > >> > >> To maintain some of the original benefit (reduced codesize), the > >> suppression is only done where the enclosing basic block is deemed > >> worthy of optimising for speed. > >> > >> This tested with no regressions and performance has improved for > >> the workloads tested on cortex-a15. (It might be beneficial to > >> other processors too, but that has not been investigated yet.) > >> > >> OK for stage 1? > > > > This is OK for stage1. > > > > Ramana > > > >> > >> Cheers, > >> Ian > >> > >> > >> 2014-01-24 Ian Bolton > >> > >> gcc/ > >> * config/arm/arm-protos.h (tune_params): New struct members. > >> * config/arm/arm.c: Initialise tune_params per processor. > >> (thumb2_reorg): Suppress conversion from t32 to t16 when > >> optimizing for speed, based on new tune_params. > > This causes > gcc.target/arm/negdi-1.c > gcc.target/arm/negdi-2.c > to FAIL when GCC is configured as: > --with-mode=ar > --with-cpu=cortex-a15 > --with-fpu=neon-vfpv4 > > both tests used to PASS. > (see http://cbuild.validation.linaro.org/build/cross- > validation/gcc/209561/report-build-info.html) Hi Christophe, I don't recall the failure when I did the work, but I see now that the test is looking for negs when my patch is specifically trying to avoid flag-setting operations. So we are now getting an rsb instead of a negs, as intended, and the test needs fixing! Open question: Should I look for either rsb or negs in a single scan-assembler or look for different ones dependent on the cpu in question or just not run the test for cortex-a15? Cheers, Ian
[PATCH] Detect a pack-unpack pattern in GCC vectorizer and optimize it.
Given the following loop:
int a[N];
short b[N*2];
for (int i = 0; i < N; ++i)
a[i] = b[i*2];
After being vectorized, the access to b[i*2] will be compiled into
several packing statements, while the type promotion from short to int
will be compiled into several unpacking statements. With this patch,
each pair of pack/unpack statements will be replaced by less expensive
statements (with shift or bit-and operations).
On x86_64, the loop above will be compiled into the following assembly
(with -O2 -ftree-vectorize):
movdqu 0x10(%rcx),%xmm3
movdqu -0x20(%rcx),%xmm0
movdqa %xmm0,%xmm2
punpcklwd %xmm3,%xmm0
punpckhwd %xmm3,%xmm2
movdqa %xmm0,%xmm3
punpcklwd %xmm2,%xmm0
punpckhwd %xmm2,%xmm3
movdqa %xmm1,%xmm2
punpcklwd %xmm3,%xmm0
pcmpgtw %xmm0,%xmm2
movdqa %xmm0,%xmm3
punpckhwd %xmm2,%xmm0
punpcklwd %xmm2,%xmm3
movups %xmm0,-0x10(%rdx)
movups %xmm3,-0x20(%rdx)
With this patch, the generated assembly is shown below:
movdqu 0x10(%rcx),%xmm0
movdqu -0x20(%rcx),%xmm1
pslld $0x10,%xmm0
psrad $0x10,%xmm0
pslld $0x10,%xmm1
movups %xmm0,-0x10(%rdx)
psrad $0x10,%xmm1
movups %xmm1,-0x20(%rdx)
Bootstrapped and tested on x86-64. OK for trunk?
thanks,
Cong
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 117cdd0..e7143f1 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,8 @@
+2014-04-23 Cong Hou
+
+ * tree-vect-stmts.c (detect_pack_unpack_pattern): New function.
+ (vect_gen_widened_results_half): Call detect_pack_unpack_pattern.
+
2014-04-23 David Malcolm
* is-a.h: Update comments to reflect the following changes to the
diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
index 62b07f4..a8755b3 100644
--- a/gcc/testsuite/ChangeLog
+++ b/gcc/testsuite/ChangeLog
@@ -1,3 +1,7 @@
+2014-04-23 Cong Hou
+
+ * gcc.dg/vect/vect-125.c: New test.
+
2014-04-23 Jeff Law
PR tree-optimization/60902
diff --git a/gcc/testsuite/gcc.dg/vect/vect-125.c
b/gcc/testsuite/gcc.dg/vect/vect-125.c
new file mode 100644
index 000..988dea6
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/vect/vect-125.c
@@ -0,0 +1,122 @@
+/* { dg-require-effective-target vect_int } */
+
+#include
+#include "tree-vect.h"
+
+#define N 64
+
+char b[N];
+unsigned char c[N];
+short d[N];
+unsigned short e[N];
+
+__attribute__((noinline)) void
+test1 ()
+{
+ int a[N];
+ int i;
+ for (i = 0; i < N/2; i++)
+{
+ a[i] = b[i*2];
+ a[i+N/2] = b[i*2+1];
+}
+ for (i = 0; i < N/2; i++)
+if (a[i] != b[i*2] || a[i+N/2] != b[i*2+1])
+ abort ();
+
+ for (i = 0; i < N/2; i++)
+{
+ a[i] = c[i*2];
+ a[i+N/2] = c[i*2+1];
+}
+ for (i = 0; i < N/2; i++)
+if (a[i] != c[i*2] || a[i+N/2] != c[i*2+1])
+ abort ();
+
+ for (i = 0; i < N/2; i++)
+{
+ a[i] = d[i*2];
+ a[i+N/2] = d[i*2+1];
+}
+ for (i = 0; i < N/2; i++)
+if (a[i] != d[i*2] || a[i+N/2] != d[i*2+1])
+ abort ();
+
+ for (i = 0; i < N/2; i++)
+{
+ a[i] = e[i*2];
+ a[i+N/2] = e[i*2+1];
+}
+ for (i = 0; i < N/2; i++)
+if (a[i] != e[i*2] || a[i+N/2] != e[i*2+1])
+ abort ();
+}
+
+__attribute__((noinline)) void
+test2 ()
+{
+ unsigned int a[N];
+ int i;
+ for (i = 0; i < N/2; i++)
+{
+ a[i] = b[i*2];
+ a[i+N/2] = b[i*2+1];
+}
+ for (i = 0; i < N/2; i++)
+if (a[i] != b[i*2] || a[i+N/2] != b[i*2+1])
+ abort ();
+
+ for (i = 0; i < N/2; i++)
+{
+ a[i] = c[i*2];
+ a[i+N/2] = c[i*2+1];
+}
+ for (i = 0; i < N/2; i++)
+if (a[i] != c[i*2] || a[i+N/2] != c[i*2+1])
+ abort ();
+
+ for (i = 0; i < N/2; i++)
+{
+ a[i] = d[i*2];
+ a[i+N/2] = d[i*2+1];
+}
+ for (i = 0; i < N/2; i++)
+if (a[i] != d[i*2] || a[i+N/2] != d[i*2+1])
+ abort ();
+
+ for (i = 0; i < N/2; i++)
+{
+ a[i] = e[i*2];
+ a[i+N/2] = e[i*2+1];
+}
+ for (i = 0; i < N/2; i++)
+if (a[i] != e[i*2] || a[i+N/2] != e[i*2+1])
+ abort ();
+}
+
+int
+main ()
+{
+ b[0] = CHAR_MIN;
+ c[0] = UCHAR_MAX;
+ d[0] = SHRT_MIN;
+ e[0] = USHRT_MAX;
+
+ int i;
+ for (i = 1; i < N; i++)
+{
+ b[i] = b[i-1] + 1;
+ c[i] = c[i-1] - 1;
+ d[i] = d[i-1] + 1;
+ e[i] = e[i-1] - 1;
+}
+
+ test1 ();
+ test2 ();
+ return 0;
+}
+
+/* { dg-final { scan-tree-dump-times "vectorized 4 loops" 2 "vect" } } */
+/* { dg-final { scan-tree-dump-times "A pack-unpack pattern is recognized" 32
"vect" } } */
+/* { dg-final { cleanup-tree-dump "vect" } } */
+
diff --git a/gcc/tree-vect-stmts.c b/gcc/tree-vect-stmts.c
index 1a51d6d..d0cf1f4 100644
--- a/gcc/tree-vect-stmts.c
+++ b/gcc/tree-vect-stmts.c
@@ -3191,6 +3191,174 @@ vectorizable_simd_clone_call (gimple stmt,
gimple_stmt_iterator *gsi,
}
+/* Function detect_pack_unpack_pattern
+
+ Detect the following pattern:
+
+ S1 vect3 = VEC_PERM_EXPR ;
+ or
+ S1 vect3 = VEC_PERM_EXPR ;
+
+ S2 vect4 = [vec_unpack_lo_expr] vect3;
+ or/and
+ S3 vect5 = [vec_unpack_hi_expr] vect3;
+
+ S1 is usually generated from accessi
Re: [Patch] Fix crtstuff.c compilation with mingw build.
"Steve Ellcey " writes: > diff --git a/libgcc/crtstuff.c b/libgcc/crtstuff.c > index 12bed4b..d09455f 100644 > --- a/libgcc/crtstuff.c > +++ b/libgcc/crtstuff.c > @@ -54,6 +54,7 @@ see the files COPYING3 and COPYING.RUNTIME respectively. > If not, see > #include "auto-host.h" > #undef pid_t > #undef rlim_t > +#undef caddr_t > #undef ssize_t > #undef vfork > #include "tconfig.h" It seems the undef's were sorted alphabetically. Please keep it this way. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: version typeinfo for 128bit types
On Thu, 24 Apr 2014, Rainer Orth wrote:
Marc Glisse writes:
this is a follow-up for this patch:
http://gcc.gnu.org/ml/gcc-patches/2014-04/msg00618.html
once committed, g++ will generate typeinfo for __float128, and it needs
versioning. While there, I noticed that __int128 has "typeinfo" but not
"typeinfo name", so I am adding it. I manually checked that the new symbols
were exactly the 12 I expected, with the new version number.
I did not test the gnu-versioned-namespace version.
I manually updated baseline for x86_64. It is awfully inconvenient to do. I
was expecting "make new-abi-baseline" to generate it for me, but it gives
me plenty of extra symbols compared to the current one. Some random
examples:
It shouldn't be necessary to update all baselines whenever you add a new
version to libstdc++.so.6. It seems to me that when you added
CXXABI_1.3.9, you forgot to update
libstdc++-v3/testsuite/util/testsuite_abi.cc for that.
I had no idea this file even existed, thanks for the pointer! It makes so
much more sense this way :-)
Grep seems to indicate that the manual is the only other place that needs
updating, but that can wait.
Is this patch ok, assuming the tests pass?
2014-04-24 Marc Glisse
* testsuite/util/testsuite_abi.cc (check_version): Update for
CXXABI_1.3.9.
--
Marc GlisseIndex: libstdc++-v3/testsuite/util/testsuite_abi.cc
===
--- libstdc++-v3/testsuite/util/testsuite_abi.cc(revision 209755)
+++ libstdc++-v3/testsuite/util/testsuite_abi.cc(working copy)
@@ -203,38 +203,39 @@ check_version(symbol& test, bool added)
known_versions.push_back("CXXABI_1.3");
known_versions.push_back("CXXABI_LDBL_1.3");
known_versions.push_back("CXXABI_1.3.1");
known_versions.push_back("CXXABI_1.3.2");
known_versions.push_back("CXXABI_1.3.3");
known_versions.push_back("CXXABI_1.3.4");
known_versions.push_back("CXXABI_1.3.5");
known_versions.push_back("CXXABI_1.3.6");
known_versions.push_back("CXXABI_1.3.7");
known_versions.push_back("CXXABI_1.3.8");
+ known_versions.push_back("CXXABI_1.3.9");
known_versions.push_back("CXXABI_TM_1");
}
compat_list::iterator begin = known_versions.begin();
compat_list::iterator end = known_versions.end();
// Check for compatible version.
if (test.version_name.size())
{
compat_list::iterator it1 = find(begin, end, test.version_name);
compat_list::iterator it2 = find(begin, end, test.name);
if (it1 != end)
test.version_status = symbol::compatible;
else
test.version_status = symbol::incompatible;
// Check that added symbols are added in the latest pre-release version.
bool latestp = (test.version_name == "GLIBCXX_3.4.20"
-|| test.version_name == "CXXABI_1.3.8"
+|| test.version_name == "CXXABI_1.3.9"
|| test.version_name == "CXXABI_TM_1");
if (added && !latestp)
test.version_status = symbol::incompatible;
// Check that long double compatibility symbols demangled as
// __float128 are put into some _LDBL_ version name.
if (added && test.demangled_name.find("__float128") != std::string::npos)
{
// Has to be in _LDBL_ version name.
if (test.version_name.find("_LDBL_") == std::string::npos)
Re: [C PATCH] Improve error on attrs after declarator in a fndef (PR c/60915)
On Thu, 24 Apr 2014, Marek Polacek wrote: This PR is about not very clear error message when one tries to add attributes *after* the declarator in a function definition. cc1plus already handles this well, so I used the same message. I thought you had an earlier version of the patch where, instead of "forbidden", you said "move the attribute" so users would know that writing the attribute *before* was fine? That sounded much better to me. -- Marc Glisse
