Re: [PATCH] Enable building of libsanitizer on sparc linux again.
David Miller da...@davemloft.net writes: From: Dodji Seketeli do...@redhat.com Date: Thu, 15 Nov 2012 11:56:40 +0100 David Miller da...@davemloft.net wrote From: Dodji Seketeli do...@redhat.com Date: Wed, 14 Nov 2012 14:26:40 +0100 I guess we could do that. That would build libsanitizer, but asan will still not be available on sparc if the asan_shadow_offset() target hook is not provided. Is that OK to you? Yes. So, here is the (IMO obvious) patch to enable libsanitizer's build on sparc linux, even if asan is not supported on that platform yet. OK for trunk? I'm fine with it. Thanks. Committed to trunk, revision r193552. -- Dodji
Re: [PATCH 00/13] Request to merge Address Sanitizer in
Jack Howarth howa...@bromo.med.uc.edu writes:
The Google branch is missing the required
interception/mach_override/mach_override.h and
interception/mach_override/mach_override.c files from compiler-rt svn
for darwin. I have posted what I believe to be the final patch which
eanbles libsanitizer on darwin...
http://gcc.gnu.org/ml/gcc-patches/2012-11/msg01285.html
I see in that thread that Mike Stump has approves the patch if no
asan{-darwin} people disagrees. I'll abide by principle, FWIW. :-)
which has been tested with the existing asan testsuite, the
use-after-free.c testcase as well as the Polyhedron 2005 benchmarks
for -O1 -g -fno-omit-frame-pointer -faddress-sanitizer and -O3
-funroll-loops -ffast-math -g -fno-omit-frame-pointer
-faddress-sanitizer to prove that the current mach_override from
upstream is sufficient for darwin to use.
I see. Thanks.
Due to the large number of maintainers for libsanitizer, it is unclear
who is the person responsible for upstream merges to lobby for these
files to be ported into gcc trunk. With Alexander Potapenko's commit
of the bug fix to mach_override/mach_override.c required for FSF
gcc...
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20121112/155989.html
...there really is no reason to continue to delay (as the interpose code
simply won't
be completed in time for gcc 4.8.0).
It makes sense to me.
Can we please get some movement on importing these missing files from
upstream?
Well, given that
Konstantin Serebryany konstantin.s.serebry...@gmail.com writes:
I see no problems with committing mach_override to gcc.
The code should be verbatim copy from
llvm/projects/compiler-rt/lib/interception/mach_override
Note that this code comes with an MIT license and was not developed by
Google (we did add quite a few patches).
... Konstantin who is one of the libsanitizer maintainers agrees, I see
no reason to delay this either.
So, Jack, as you are on top of this topic and has the platform to test
at hand, I guess you could just import the missing files from the llvm
repository and commit them to GCC, unless a GCC maintainers disagrees,
of course.
Thus, you could maybe just send the patch of the file you are about to
commit as a reply to this thread, so that Konstantin and Alexander can
officially ACK it? I am mentioning Alexander because of what Konstantin
is saying ...
Also, Alexander Potapenko is the best person to ask about asan-darwin.
here.
Maybe we can add him to the list of sanitizer maintainers?
Seconded. At least for libsanitier/Darwin.
Cheers.
--
Dodji
Re: [PATCH v2, testsuite]: Add dg-error for unsupported floating suffix
On Fri, Nov 16, 2012 at 08:53:54AM +0100, Uros Bizjak wrote:
2012-11-16 Uros Bizjak ubiz...@gmail.com
* lib/target_suports.exp
(check_effective_target_has_w_floating_suffix): New procedure.
(check_effective_target_has_q_floating_suffix): Ditto.
* g++.dg/cpp0x/gnu_fext-numeric-literals.C: Add dg-error directive
for unsupported non-standard suffix on floating constant.
* g++.dg/cpp0x/std_fext-numeric-literals.C: Ditto.
Attached patch was re-tested on alphaev68-linux-gnu and
x86_64-linux-gnu and committed to mainline SVN.
Perhaps just bike-shed, but I'd write it as:
+# Return 1 if the target supports 'w' suffix on floating constant
+# 0 otherwise.
+
+proc check_effective_target_has_w_floating_suffix { } {
if [check_effective_target_c++] {
opts=-std=gnu++03
else
opts=
}
+return [check_no_compiler_messages w_fp_suffix object {
+ float dummy = 1.0w;
} $opts]
but I admit I haven't tested it.
Jakub
Patch ping
Hi! - PR54921 invalidate sp in cselib on fp setter insn http://gcc.gnu.org/ml/gcc-patches/2012-10/msg02035.html (perhaps in light of PR54402 the single_succ (ENTRY_BLOCK_PTR) from the patch should be nuked) - PR55188 testcase fix for targets with different branch cost http://gcc.gnu.org/ml/gcc-patches/2012-11/msg00361.html - PR55137 fold reassociation fix http://gcc.gnu.org/ml/gcc-patches/2012-11/msg00636.html (alternatively also retry with unsigned atype if the reassociation would fail otherwise) - PR55236 range test optimization fix with -fwrapv http://gcc.gnu.org/ml/gcc-patches/2012-11/msg00707.html (perhaps PLUS_EXPR can be handled similarly instead of bailing out) Jakub
Re: [PATCH v2, testsuite]: Add dg-error for unsupported floating suffix
On Fri, Nov 16, 2012 at 9:52 AM, Jakub Jelinek ja...@redhat.com wrote:
2012-11-16 Uros Bizjak ubiz...@gmail.com
* lib/target_suports.exp
(check_effective_target_has_w_floating_suffix): New procedure.
(check_effective_target_has_q_floating_suffix): Ditto.
* g++.dg/cpp0x/gnu_fext-numeric-literals.C: Add dg-error directive
for unsupported non-standard suffix on floating constant.
* g++.dg/cpp0x/std_fext-numeric-literals.C: Ditto.
Attached patch was re-tested on alphaev68-linux-gnu and
x86_64-linux-gnu and committed to mainline SVN.
Perhaps just bike-shed, but I'd write it as:
Actually, a very good idea!
I will commit the following addendum when alpha finishes testing:
--cut here--
Index: target-supports.exp
===
--- target-supports.exp (revision 193551)
+++ target-supports.exp (working copy)
@@ -1746,18 +1746,26 @@
# 0 otherwise.
proc check_effective_target_has_w_floating_suffix { } {
+set opts
+if [check_effective_target_c++] {
+append opts -std=gnu++03
+}
return [check_no_compiler_messages w_fp_suffix object {
float dummy = 1.0w;
-} -std=gnu++03 -w]
+} $opts]
}
# Return 1 if the target supports 'q' suffix on floating constant
# 0 otherwise.
proc check_effective_target_has_q_floating_suffix { } {
+set opts
+if [check_effective_target_c++] {
+append opts -std=gnu++03
+}
return [check_no_compiler_messages q_fp_suffix object {
float dummy = 1.0q;
-} -std=gnu++03 -w]
+} $opts]
}
# Return 1 if the target supports compiling fixed-point,
# 0 otherwise.
--cut here--
Thanks,
Uros.
Re: ASAN merge...
On 11/14/2012 01:49 PM, Richard Earnshaw wrote: Please please don't get into the habit of calling it ARM32 and ARM64, you're just sowing confusion; there are good reasons why those names weren't adopted (some technical, some not) and I'm not about to rehash them all now. AArch32 and AArch64 aren't that much harder to type and they are completely unambiguous. And they can't be pronounced in any reasonable way. I think you're going to lose this one. Andrew
Re: [PATCH] asan testsuite (take 3)
On Thu, Nov 15, 2012 at 05:01:49PM -0800, Andrew Pinski wrote:
All of these tests failure for me because my addr2line is too old and
does not support dwarf4. Can we move over to using libbacktrace in
libsanitzer instead of depending on addr2line here?
The problem is that addr2line doesn't fail in that case, merely prints
some extra message to stderr and continues working. And dejagnu combines
both stderr and stdout together.
Does the following fix the problem? The second hunk is desirable
even if the first hunk doesn't help.
As for libbacktrace, as I said earlier, IMHO we should use it both to
symbolize all the printed backtraces (both gathered by the fast
unwind and libbacktrace gathered backtraces), and to gather backtraces
in places that aren't performance sensitive in the library (like, all
__asan_report_error callers).
Haven't studied libbacktrace too much, can it provide right now
just function name or function name and file:line info too?
2012-11-16 Jakub Jelinek ja...@redhat.com
* lib/asan-dg.exp (asan_symbolize): Prune BFD: prefixed error messages
from addr2line_output. Increment idx if asking for more than one
address
in one object.
--- gcc/testsuite/lib/asan-dg.exp.jj2012-11-14 23:57:07.0 +0100
+++ gcc/testsuite/lib/asan-dg.exp 2012-11-16 10:50:20.697041456 +0100
@@ -127,7 +127,9 @@ proc asan_symbolize { output } {
set args -f -e $key $arr($key)
set status [remote_exec host $addr2line_name $args]
if { [lindex $status 0] 0 } continue
- set addr2line_output [regexp -inline -all -line ^\[^\n\r]*
[lindex $status 1]]
+ regsub -all \r\n [lindex $status 1] \n addr2line_output
+ regsub -all (^|\n|\r)BFD: \[^\n\r\]* $addr2line_output
addr2line_output
+ set addr2line_output [regexp -inline -all -line ^\[^\n\r]*
$addr2line_output]
set idx 0
foreach val $arr($key) {
if { [expr $idx + 1] [llength $addr2line_output] } {
@@ -137,6 +139,7 @@ proc asan_symbolize { output } {
set newkey $key+$val
set repl($newkey) $fnname $fileline
}
+ set idx [expr $idx + 2]
}
}
}
Jakub
Re: [PATCH ARM]Define LOGICAL_OP_NON_SHORT_CIRCUIT for ARM target
On 16 November 2012 05:37, Bin Cheng bin.ch...@arm.com wrote: Hi, This patch defines LOGICAL_OP_NON_SHORT_CIRCUIT for ARM target and prefers short circuit for armv6-m and Thumb2+Os. === --- gcc/config/arm/arm.h (revision 193494) +++ gcc/config/arm/arm.h (working copy) @@ -2012,10 +2012,16 @@ enum arm_auto_incmodes || (X) == arg_pointer_rtx) /* Try to generate sequences that don't involve branches, we can then use - conditional instructions */ + conditional instructions. */ #define BRANCH_COST(speed_p, predictable_p) \ (current_tune-branch_cost (speed_p, predictable_p)) +/* False if short circuit operation is preferred. */ +#define LOGICAL_OP_NON_SHORT_CIRCUIT \ + ((optimize_size) \ + ? (TARGET_THUMB ? false : true) \ + : (current_tune-logical_op_non_short_circuit[TARGET_ARM])) + This changes the definition of LOGICAL_OP_NON_SHORT_CIRCUIT for all cores supported by the ARM backend. In gcc/fold-const.c LOGICAL_OP_NON_SHORT_CIRCUIT is defined as follows: #ifndef LOGICAL_OP_NON_SHORT_CIRCUIT #define LOGICAL_OP_NON_SHORT_CIRCUIT \ (BRANCH_COST (optimize_function_for_speed_p (cfun), \ false) = 2) #endif Now whilst this is probably wrong for most ARM cores, can you please keep it as the default for cores which you haven't benchmarked the change on? The optimise for code size changes are probably on all cores without further testing. Thanks, Matt -- Matthew Gretton-Dann Linaro Toolchain Working Group matthew.gretton-d...@linaro.org
Re: [PATCH, generic] New RTL primitive: `define_subst'
Yeah, one or other way to being able to debug what exactly has been
performed during the iterator expansion is certainly desirable for the
future.
We actually have internal machinery for dumping MDs with expanded
iterators and substs, but this looks really kinda hack now.
We're going to submit it as subsequent patch after that one
is checked in (there'll be no change in `define_subst' interface) and some
discussion about necessary infrastructure changes is performed.
It's fairly easy to dump MD-file with expanded iterators and subst -
we could do it in any gen*-utility with a small piece of code. Like
this:
+void
+print_rtl_list (struct queue_elem **q)
+{
+ struct queue_elem *elem;
+ for (elem = *q; elem ; elem = elem-next)
+debug_rtx (elem-data);
+}
...
+ print_rtl_list (define_attr_queue);
+ print_rtl_list (define_pred_queue);
+ print_rtl_list (define_insn_queue);
+ print_rtl_list (define_cond_exec_queue);
+ print_rtl_list (define_subst_queue);
+ print_rtl_list (other_queue);
Currently I just don't know what way should be used to invoke it - in
our development we use an environment variable as a trigger for this,
but this is a real hack:
+ if (getenv (__DUMP_RTL_LIST))
+{
+ print_rtl_list (define_attr_queue);
...
+}
I don't believe this way is appropriate to be in the trunk - so, could
you please advise how it should be done? Maybe we should introduce a
new gen-utility which should be used only for dumping md-files and add
a new target into makefile to invoke it, or should we add a command
line option to existing utilities?
--
Thanks, Michael
--
---
Best regards,
Michael V. Zolotukhin,
Software Engineer
Intel Corporation.
[PATCH, testsuite]: Fix g++.dg/mv[1,6].C failure with non-default architecture
Hello!
2012-11-16 Uros Bizjak ubiz...@gmail.com
* g++.dg/mv1.C (dg-options): Add -march=x86-64.
* g++.dg/mv6.C (dg-options): Ditto.
Tested on x86_64-linux-gnu {,-m32} configured --with-arch=corei7-avx
and committed to mainline SVN.
Uros.
Index: g++.dg/mv1.C
===
--- g++.dg/mv1.C(revision 193549)
+++ g++.dg/mv1.C(working copy)
@@ -1,7 +1,7 @@
/* Test case to check if Multiversioning works. */
/* { dg-do run { target i?86-*-* x86_64-*-* } } */
/* { dg-require-ifunc } */
-/* { dg-options -O2 -fPIC -mno-avx -mno-popcnt } */
+/* { dg-options -O2 -fPIC -march=x86-64 -mno-avx -mno-popcnt } */
#include assert.h
Index: g++.dg/mv6.C
===
--- g++.dg/mv6.C(revision 193549)
+++ g++.dg/mv6.C(working copy)
@@ -2,6 +2,7 @@
/* { dg-do run { target i?86-*-* x86_64-*-* } } */
/* { dg-require-ifunc } */
+/* { dg-options -march=x86-64 } */
class Foo
{
Re: VEC re-write [patch 03/25]
2012/11/16 Martin Jambor mjam...@suse.cz: Hi, On Thu, Nov 15, 2012 at 04:53:25PM -0500, Diego Novillo wrote: [ The patch is too big for e-mail. It's available at http://www.airs.com/~dnovillo/pub/vec-rewrite/06vec.diff ] when I tried to wget it, I got ERROR 404: Not Found. (I downloaded 01vec.diff fine.) Silly me. I wrote the wrong names in the script. It should be: http://www.airs.com/~dnovillo/pub/vec-rewrite/03me.diff Sorry. Diego.
Re: VEC re-write [patch 06/25]
On Thu, Nov 15, 2012 at 4:53 PM, Diego Novillo dnovi...@google.com wrote: [ The patch is too big for e-mail. It's available at http://www.airs.com/~dnovillo/pub/vec-rewrite/06vec.diff ] This is the wrong link. The correct one is http://www.airs.com/~dnovillo/pub/vec-rewrite/06cp.diff Diego.
Re: VEC re-write [patch 01/25]
On Fri, Nov 16, 2012 at 5:23 AM, Pedro Alves pal...@redhat.com wrote: Was this considered? Yup. I just did not implement it. Would be a good follow up, though. Diego.
Re: VEC re-write [patch 01/25]
On 16-11-2012 12:13, Diego Novillo wrote:
On Fri, Nov 16, 2012 at 5:23 AM, Pedro Alves pal...@redhat.com wrote:
Was this considered?
Yup. I just did not implement it. Would be a good follow up, though.
Ah, good to know. Thanks.
For the archives, cause gcc-patches@ bounced my mail for not being subscribed
with this address (too many recipients) what I had sent was:
On 15-11-2012 21:53, Diego Novillo wrote:
The only thing I could not do is create proper ctors and dtors for the
vec class. Since these vectors are stored in unions, we
have to keep them as PODs (C++03 does not allow non-PODs in unions).
How many cases are there of vecs in unions vs not in unions?
It would seem natural to me to extend the POD vec type with a
class that just adds the ctors and dtors, and call that new type
the vec that is used mostly everywhere. The base POD vec (suggest
struct vec_pod, and then struct vec : vec_pod {}) would then only
be used in unions, and then only the code that needs to worry about
initializing/releasing the unions would need to care about this. Was
this considered?
--
Pedro Alves
RE: [PATCH ARM]Define LOGICAL_OP_NON_SHORT_CIRCUIT for ARM target
-Original Message- From: Matthew Gretton-Dann [mailto:matthew.gretton-d...@linaro.org] Sent: Friday, November 16, 2012 6:30 PM To: Bin Cheng Cc: gcc-patches@gcc.gnu.org Subject: Re: [PATCH ARM]Define LOGICAL_OP_NON_SHORT_CIRCUIT for ARM target On 16 November 2012 05:37, Bin Cheng bin.ch...@arm.com wrote: Hi, This patch defines LOGICAL_OP_NON_SHORT_CIRCUIT for ARM target and prefers short circuit for armv6-m and Thumb2+Os. === --- gcc/config/arm/arm.h (revision 193494) +++ gcc/config/arm/arm.h (working copy) @@ -2012,10 +2012,16 @@ enum arm_auto_incmodes || (X) == arg_pointer_rtx) /* Try to generate sequences that don't involve branches, we can then use - conditional instructions */ + conditional instructions. */ #define BRANCH_COST(speed_p, predictable_p) \ (current_tune-branch_cost (speed_p, predictable_p)) +/* False if short circuit operation is preferred. */ #define +LOGICAL_OP_NON_SHORT_CIRCUIT \ + ((optimize_size) \ + ? (TARGET_THUMB ? false : true) \ + : (current_tune-logical_op_non_short_circuit[TARGET_ARM])) + This changes the definition of LOGICAL_OP_NON_SHORT_CIRCUIT for all cores supported by the ARM backend. In gcc/fold-const.c LOGICAL_OP_NON_SHORT_CIRCUIT is defined as follows: #ifndef LOGICAL_OP_NON_SHORT_CIRCUIT #define LOGICAL_OP_NON_SHORT_CIRCUIT \ (BRANCH_COST (optimize_function_for_speed_p (cfun), \ false) = 2) #endif Now whilst this is probably wrong for most ARM cores, can you please keep it as the default for cores which you haven't benchmarked the change on? The optimise for code size changes are probably on all cores without further testing. Thanks for your comments, I am not sure what's the meaning of probably wrong for most ARM cores, I deduced the value of field logical_op_non_short_circuit from the previously default macro and the BRANCH_COST for all arm tune_params, so this patch should not change the behavior on ARM cores other than v6m. Or did I miss something? Thanks.
[PATCH] PR c++/54875 - Error when instantiating an alias template that resolves to an enum
Hello,
Consider this short example:
1 templatetypename T
2 using AddConst = T const;
3
4 enum FwdEnum : int;
5
6 int main() {
7AddConstFwdEnum *ptr = nullptr;
8 }
At line 7, when we build the type for AddConstFwdEnum in
lookup_template_class_1, the resulting type is the enum FwdEnum. This
confuses lookup_template_class_1 near the if below, wrongly making it
taking the branch and thus calling tsubst_enum while it shouldn't:
if (TREE_CODE (t) == ENUMERAL_TYPE !is_dependent_type)
/* Now that the type has been registered on the instantiations
list, we set up the enumerators. Because the enumeration
constants may involve the enumeration type itself, we make
sure to register the type first, and then create the
constants. That way, doing tsubst_expr for the enumeration
constants won't result in recursive calls here; we'll find
the instantiation and exit above. */
tsubst_enum (template_type, t, arglist);
Before the alias template feature, the only reason why TREE_CODE (t)
== ENUMERAL_TYPE would be true is when lookup_template_class_1 is
called for an enum that is a member of a class template. But that
condition can be also true for an alias template instantiation as
well.
So I guess that condition should be changed to TREE_CODE
(template_type) == ENUMERAL_TYPE, to specifically detect the member
enum of a class template case.
This is what the one-liner patchlet below does.
Bootstrapped and tested on x86_64-unknown-linux-gnu against trunk.
gcc/cp/
* pt.c (lookup_template_class_1): Look at the type of the
potential member enum of class template to determine if we are
actually substituting into a member enum of class template.
gcc/testsuite/
* g++.dg/cpp0x/alias-decl-27.C: New test.
---
gcc/cp/pt.c| 2 +-
gcc/testsuite/g++.dg/cpp0x/alias-decl-27.C | 11 +++
2 files changed, 12 insertions(+), 1 deletion(-)
create mode 100644 gcc/testsuite/g++.dg/cpp0x/alias-decl-27.C
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 3c9bb56..101b22d 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -7487,7 +7487,7 @@ lookup_template_class_1 (tree d1, tree arglist, tree
in_decl, tree context,
= tree_cons (arglist, t,
DECL_TEMPLATE_INSTANTIATIONS (templ));
- if (TREE_CODE (t) == ENUMERAL_TYPE !is_dependent_type)
+ if (TREE_CODE (template_type) == ENUMERAL_TYPE !is_dependent_type)
/* Now that the type has been registered on the instantiations
list, we set up the enumerators. Because the enumeration
constants may involve the enumeration type itself, we make
diff --git a/gcc/testsuite/g++.dg/cpp0x/alias-decl-27.C
b/gcc/testsuite/g++.dg/cpp0x/alias-decl-27.C
new file mode 100644
index 000..91208ab
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/alias-decl-27.C
@@ -0,0 +1,11 @@
+// Origin: PR c++/54875
+// { dg-do compile { target c++11 } }
+
+templatetypename T
+using AddConst = T const;
+
+enum FwdEnum : int;
+
+int main() {
+ AddConstFwdEnum *ptr = nullptr;
+}
--
1.7.11.7
--
Dodji
[PING] [PATCH] PR c++/53609 - Wrong argument deduction for pack expansion in argument pack
I am friendly pinging the patch below ...
Dodji Seketeli do...@redhat.com a écrit:
Hello,
Consider this example:
1templateclass...I struct List {};
2templateint T struct Z {static const int value = T;};
3templateint...T using LZ = ListZT...;
4
5templateclass...U
6struct F
7{
8 using N = LZU::value...; //#1 This should amount to
ListZU::value...
9}
10
11FZ1, Z2 ::N A; //#2
which G++ fails to compile, with this error message:
test-PR53609-3.cc: In instantiation of 'struct FZ1, Z2 ':
test-PR53609-3.cc:11:15: required from here
test-PR53609-3.cc:3:43: error: wrong number of template arguments (2, should
be 1)
templateint...T using LZ = ListZT...;
^
test-PR53609-3.cc:2:24: error: provided for 'templateint T struct Z'
templateint T struct Z {static const int value = T;};
I think this is because in #1, when we substitute the argument pack
{U::value...} into the pack expansion ZT..., tsubst_pack_expansion
yields ZU::value..., instead of ZU::value..., so the instantiation
of LZ amounts to ListZU::value... , instead of
ListZU::value
The idea of this patch is to make tsubst_pack_expansion support
substituting an argument pack (into a pack expansion) where one of the
arguments (let's call it the Ith argument) is itself a pack expansion
P. In that case, the Ith element resulting from the substituting
should be a pack expansion P'.
The pattern of P' is then the pattern of P into which the pattern of
the Ith argument of the argument pack has been substituted.
Tested on x86_64-unknown-linux-gnu against trunk.
gcc/cp/
* pt.c (real_argument_pack_element_p)
(any_non_real_argument_pack_element_p)
(arg_pack_select_for_pack_expansion)
(set_arg_pack_select_index_for_pack_expansion): New static
functions.
(has_bare_parameter_packs): Factorized out of ...
(check_for_bare_parameter_packs): ... here.
(tsubst_pack_expansion): Support substituting an argument pack
that contains a pack expansion.
gcc/testsuite/
* g++.dg/cpp0x/variadic139.C: New test.
* g++.dg/cpp0x/variadic140.C: Likewise.
* g++.dg/cpp0x/variadic141.C: Likewise.
---
gcc/cp/pt.c | 151
--
gcc/testsuite/g++.dg/cpp0x/variadic139.C | 14 +++
gcc/testsuite/g++.dg/cpp0x/variadic140.C | 22 +
gcc/testsuite/g++.dg/cpp0x/variadic141.C | 22 +
4 files changed, 182 insertions(+), 27 deletions(-)
create mode 100644 gcc/testsuite/g++.dg/cpp0x/variadic139.C
create mode 100644 gcc/testsuite/g++.dg/cpp0x/variadic140.C
create mode 100644 gcc/testsuite/g++.dg/cpp0x/variadic141.C
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 16952bf..bcfe83f 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -3310,6 +3310,29 @@ make_pack_expansion (tree arg)
return result;
}
+/* Return NULL_TREE iff T contains *NO* unexpanded parameter packs.
+ Return the TREE_LIST of unexpanded parameter packs otherwise. */
+
+static tree
+has_bare_parameter_packs (tree t)
+{
+ tree parameter_packs = NULL_TREE;
+ struct find_parameter_pack_data ppd;
+
+ if (!processing_template_decl || !t || t == error_mark_node)
+return NULL_TREE;
+
+ if (TREE_CODE (t) == TYPE_DECL)
+t = TREE_TYPE (t);
+
+ ppd.parameter_packs = parameter_packs;
+ ppd.visited = pointer_set_create ();
+ cp_walk_tree (t, find_parameter_packs_r, ppd, ppd.visited);
+ pointer_set_destroy (ppd.visited);
+
+ return parameter_packs;
+}
+
/* Checks T for any bare parameter packs, which have not yet been
expanded, and issues an error if any are found. This operation can
only be done on full expressions or types (e.g., an expression
@@ -3327,19 +3350,7 @@ make_pack_expansion (tree arg)
bool
check_for_bare_parameter_packs (tree t)
{
- tree parameter_packs = NULL_TREE;
- struct find_parameter_pack_data ppd;
-
- if (!processing_template_decl || !t || t == error_mark_node)
-return false;
-
- if (TREE_CODE (t) == TYPE_DECL)
-t = TREE_TYPE (t);
-
- ppd.parameter_packs = parameter_packs;
- ppd.visited = pointer_set_create ();
- cp_walk_tree (t, find_parameter_packs_r, ppd, ppd.visited);
- pointer_set_destroy (ppd.visited);
+ tree parameter_packs = has_bare_parameter_packs (t);
if (parameter_packs)
{
@@ -9065,6 +9076,86 @@ make_fnparm_pack (tree spec_parm)
return extract_fnparm_pack (NULL_TREE, spec_parm);
}
+/* Return true iff the Ith element of the argument pack ARG_PACK is
+ *NOT* a pack expansion. */
+
+static bool
+real_argument_pack_element_p (tree arg_pack, int i)
+{
+ return !PACK_EXPANSION_P (TREE_VEC_ELT
+ (ARGUMENT_PACK_ARGS (arg_pack), i));
+}
+
+/* Return true iff ARG_PACK is an argument pack that
[PING] [PATCH] PR c++/54401 - Confusing diagnostics about type-alias at class scope
I am friendly pinging the patch below ...
Dodji Seketeli do...@redhat.com a écrit:
Hello,
Consider this invalid example given in the PR, where T is not defined:
1templatetypename
2struct X {
3using type = T;
4};
g++ yields the confusing diagnostics:
test.cc:3:10: error: expected nested-name-specifier before 'type'
using type = T;
^
test.cc:3:10: error: using-declaration for non-member at class scope
test.cc:3:15: error: expected ';' before '=' token
using type = T;
^
test.cc:3:15: error: expected unqualified-id before '=' token
I think this is because in cp_parser_member_declaration we tentatively
parse an alias declaration; we then have a somewhat meaningful
diagnostic which alas is not emitted because we are parsing
tentatively. As the parsing didn't succeed (because the input is
invalid) we try to parse a using declaration, which fails as well; but
then the diagnostic emitted is the one for the failed attempt at
parsing a using declaration, not an alias declaration. Oops.
The idea of this patch is to detect in advance that we want to parse
an alias declaration, parse it non-tentatively, and then if an error
arises, emit it.
I also changed cp_parser_alias_declaration to get out directly when it
detects that the type-id is invalid, rather than going on nonetheless
and emitting more (irrelevant) error diagnostics.
We are now getting the following output:
test.cc:3:18: erreur: expected type-specifier before ‘T’
using type = T;
^
test.cc:3:18: erreur: ‘T’ does not name a type
I don't really like the before 'T' there, but I think we maybe could
revisit the format of what cp_parser_error emits in general, now that
we have caret diagnostics; We could maybe do away with the before T
altogether?
In the mean time, it seems to me that this patch brings an improvement
over what we already have in trunk, and the issue above could be
addressed separately.
Tested on x86_64-unknown-linux-gnu against trunk.
gcc/cp/
* parser.c (cp_parser_expecting_alias_declaration_p): New static
function.
(cp_parser_block_declaration): Use it.
(cp_parser_member_declaration): Likewise. Don't parse the using
declaration tentatively.
(cp_parser_alias_declaration): Get out if the type-id is invalid.
gcc/testsuite/
* g++.dg/cpp0x/alias-decl-23.C: New test.
---
gcc/cp/parser.c| 38
+++---
gcc/testsuite/g++.dg/cpp0x/alias-decl-23.C | 7 ++
2 files changed, 36 insertions(+), 9 deletions(-)
create mode 100644 gcc/testsuite/g++.dg/cpp0x/alias-decl-23.C
diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index e8c0378..cab2d09 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -1937,6 +1937,8 @@ static bool cp_parser_using_declaration
(cp_parser *, bool);
static void cp_parser_using_directive
(cp_parser *);
+static bool cp_parser_expecting_alias_declaration_p
+ (cp_parser*);
static tree cp_parser_alias_declaration
(cp_parser *);
static void cp_parser_asm_definition
@@ -10292,11 +10294,7 @@ cp_parser_block_declaration (cp_parser *parser,
cp_parser_using_directive (parser);
/* If the second token after 'using' is '=', then we have an
alias-declaration. */
- else if (cxx_dialect = cxx0x
- token2-type == CPP_NAME
- ((cp_lexer_peek_nth_token (parser-lexer, 3)-type == CPP_EQ)
-|| (cp_lexer_peek_nth_token (parser-lexer, 3)-keyword
-== RID_ATTRIBUTE)))
+ else if (cp_parser_expecting_alias_declaration_p (parser))
cp_parser_alias_declaration (parser);
/* Otherwise, it's a using-declaration. */
else
@@ -15079,6 +15077,24 @@ cp_parser_using_declaration (cp_parser* parser,
return true;
}
+/* Return TRUE if the coming tokens reasonably denote the beginning of
+ an alias declaration. */
+
+static bool
+cp_parser_expecting_alias_declaration_p (cp_parser* parser)
+{
+ if (cxx_dialect cxx0x)
+return false;
+ cp_parser_parse_tentatively (parser);
+ cp_parser_require_keyword (parser, RID_USING, RT_USING);
+ cp_parser_identifier (parser);
+ cp_parser_attributes_opt (parser);
+ cp_parser_require (parser, CPP_EQ, RT_EQ);
+ bool is_ok = !cp_parser_error_occurred (parser);
+ cp_parser_abort_tentative_parse (parser);
+ return is_ok;
+}
+
/* Parse an alias-declaration.
alias-declaration:
@@ -15141,6 +15157,9 @@ cp_parser_alias_declaration (cp_parser* parser)
if (parser-num_template_parameter_lists)
parser-type_definition_forbidden_message = saved_message;
+ if (type == error_mark_node)
+return error_mark_node;
+
cp_parser_require (parser, CPP_SEMICOLON, RT_SEMICOLON);
if (cp_parser_error_occurred (parser))
@@ -18849,10 +18868,11 @@
Re: [PR 55238] More careful pass-through handling in find_aggregate_values_for_callers_subset
* testsuite/gcc.dg/torture/pr55238.c: New test. Does this PR rely on hidden visibility? The new testcase uses attribute visibility hidden, but does not check DejaGNU dg-require-visibility and fails on AIX. void __attribute__ ((visibility (hidden))) gz_error (gz_state *state, int err, char *msg) Thanks, David
Re: [PATCH] PR c++/54875 - Error when instantiating an alias template that resolves to an enum
On 11/16/2012 07:43 AM, Dodji Seketeli wrote: So I guess that condition should be changed to TREE_CODE (template_type) == ENUMERAL_TYPE, to specifically detect the member enum of a class template case. Why does that help? What is template_type in the alias template case? Jason
Re: [PATCH 00/13] Request to merge Address Sanitizer in
On Fri, Nov 16, 2012 at 09:27:26AM +0100, Dodji Seketeli wrote:
Jack Howarth howa...@bromo.med.uc.edu writes:
The Google branch is missing the required
interception/mach_override/mach_override.h and
interception/mach_override/mach_override.c files from compiler-rt svn
for darwin. I have posted what I believe to be the final patch which
eanbles libsanitizer on darwin...
http://gcc.gnu.org/ml/gcc-patches/2012-11/msg01285.html
I see in that thread that Mike Stump has approves the patch if no
asan{-darwin} people disagrees. I'll abide by principle, FWIW. :-)
which has been tested with the existing asan testsuite, the
use-after-free.c testcase as well as the Polyhedron 2005 benchmarks
for -O1 -g -fno-omit-frame-pointer -faddress-sanitizer and -O3
-funroll-loops -ffast-math -g -fno-omit-frame-pointer
-faddress-sanitizer to prove that the current mach_override from
upstream is sufficient for darwin to use.
I see. Thanks.
Due to the large number of maintainers for libsanitizer, it is unclear
who is the person responsible for upstream merges to lobby for these
files to be ported into gcc trunk. With Alexander Potapenko's commit
of the bug fix to mach_override/mach_override.c required for FSF
gcc...
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20121112/155989.html
...there really is no reason to continue to delay (as the interpose code
simply won't
be completed in time for gcc 4.8.0).
It makes sense to me.
Can we please get some movement on importing these missing files from
upstream?
Well, given that
Konstantin Serebryany konstantin.s.serebry...@gmail.com writes:
I see no problems with committing mach_override to gcc.
The code should be verbatim copy from
llvm/projects/compiler-rt/lib/interception/mach_override
Note that this code comes with an MIT license and was not developed by
Google (we did add quite a few patches).
... Konstantin who is one of the libsanitizer maintainers agrees, I see
no reason to delay this either.
So, Jack, as you are on top of this topic and has the platform to test
at hand, I guess you could just import the missing files from the llvm
repository and commit them to GCC, unless a GCC maintainers disagrees,
of course.
Can one of the libsanitizer maintainers handle the importation? The only
requirements are that they use a mach_override/mach_override.c and
mach_override/mach_override.h from on or after llvm r168032...
Author: glider
Date: Thu Nov 15 02:32:16 2012
New Revision: 168032
URL: http://llvm.org/viewvc/llvm-project?rev=168032view=rev
Log:
[ASan] Add the lea $imm(%rip),%rax instruction to mach_override.c
The need for this has been reported by Jack Howarth (howarth at
bromo.med.uc.edu) who's porting ASan-Darwin to GCC
Modified:
compiler-rt/trunk/lib/interception/mach_override/mach_override.c
Modified: compiler-rt/trunk/lib/interception/mach_override/mach_override.c
URL:
http://llvm.org/viewvc/llvm-project/compiler-rt/trunk/lib/interception/mach_override/mach_override.c?rev=168032r1=168031r2=168032view=diff
==
--- compiler-rt/trunk/lib/interception/mach_override/mach_override.c (original)
+++ compiler-rt/trunk/lib/interception/mach_override/mach_override.c Thu Nov 15
02:32:16 2012
@@ -725,6 +725,8 @@
{ 0x2, {0xFF, 0x00}, {0x89, 0x00} }, //
mov r/m32,r32 or r/m16,r16
{ 0x3, {0xFF, 0xFF, 0xFF}, {0x49, 0x89, 0xF8} }, //
mov %rdi,%r8
{ 0x4, {0xFF, 0xFF, 0xFF, 0xFF}, {0x40, 0x0F, 0xBE, 0xCE} }, //
movsbl %sil,%ecx
+{ 0x7, {0xFF, 0xFF, 0xFF, 0x00, 0x00, 0x00, 0x00},
+ {0x48, 0x8D, 0x05, 0x00, 0x00, 0x00, 0x00} }, // lea
$imm(%rip),%rax
{ 0x3, {0xFF, 0xFF, 0xFF}, {0x0F, 0xBE, 0xCE} }, // movsbl, %dh, %ecx
{ 0x3, {0xFF, 0xFF, 0x00}, {0xFF, 0x77, 0x00} }, // pushq $imm(%rdi)
{ 0x2, {0xFF, 0xFF}, {0xDB, 0xE3} }, // fninit
and place these two files in libsanitizer/interception/mach_override. I am
unclear on what adjustments
you are doing to the licensing comments in these files. The imported files
could just be tacked onto
my posted patch (reattached to this message) and done as a single commit.
Thanks in advance.
Jack
ps I assume that these changes should also be committed to the gcc asan branch
as well.
Thus, you could maybe just send the patch of the file you are about to
commit as a reply to this thread, so that Konstantin and Alexander can
officially ACK it? I am mentioning Alexander because of what Konstantin
is saying ...
Also, Alexander Potapenko is the best person to ask about asan-darwin.
here.
Maybe we can add him to the list of sanitizer maintainers?
Seconded. At least for libsanitier/Darwin.
Cheers.
--
Dodji
The attached patch assumes that the current
[PATCH][RFC] Bug handling SUBREG (MEM) - MEM having side-effects?
Hi,
I seem to have uncovered what seems to be a bug with handling SUBREG (MEM) with
the MEM having side-effects while testing aarch64-4.7. This bug seems to be
latent on trunk.
Here is a test case reduced from gcc.c-torture/execute/scal-to-vec1.c.
#define vector(elcount, type) \
__attribute__((vector_size((elcount)*sizeof(type type
#define vidx(type, vec, idx) (*((type *) (vec) + idx))
#define operl(a, b, op) (a op b)
#define operr(a, b, op) (b op a)
#define check(type, count, vec0, vec1, num, op, lr) \
do {\
int __i; \
for (__i = 0; __i count; __i++) {\
if (vidx (type, vec1, __i) != oper##lr (num, vidx (type, vec0, __i),
op)) \
__builtin_abort (); \
}\
} while (0)
#define veccompare(type, count, v0, v1) \
do {\
int __i; \
for (__i = 0; __i count; __i++) { \
if (vidx (type, v0, __i) != vidx (type, v1, __i)) \
__builtin_abort (); \
} \
} while (0)
volatile int one = 1;
int main (int argc, char *argv[]) {
vector(8, short) v0 = {one, 1, 2, 3, 4, 5, 6, 7};
vector(8, short) v1;
v1 = 2 v0; check (short, 8, v0, v1, 2, , l);
return 0;
}
When compiled with -O1, the combiner tries to combine these two instructions:
(insn 87 86 89 4 (set (reg:SI 154 [ MEM[base: D.2294_40, offset: 0B] ])
(sign_extend:SI (mem:HI (pre_inc:DI (reg:DI 113 [ ivtmp.23 ])) [0
MEM[base: D.2294_40, offset: 0B]+0 S2 A16]))) scal-to-vec1.c:35 54
{*extendhisi2_aarch64}
(expr_list:REG_INC (reg:DI 113 [ ivtmp.23 ])
(nil)))
(insn 89 87 90 4 (set (reg:SI 155)
(ashift:SI (reg:SI 158)
(subreg:QI (reg:SI 154 [ MEM[base: D.2294_40, offset: 0B] ]) 0)))
scal-to-vec1.c:35 331 {*ashlsi3_insn}
(expr_list:REG_DEAD (reg:SI 154 [ MEM[base: D.2294_40, offset: 0B] ])
(nil)))
It tries to forward-propagate reg 154 to insn 89 and the intermediate RTL looks
like this:
(insn 89 87 90 4 (set (reg:SI 155)
(ashift:SI (reg:SI 158)
(subreg:QI ((sign_extend:SI (mem:HI (pre_inc:DI (reg:DI 113
[ivtmp.23 ])) [0 MEM[base:
D.2294_40, offset: 0B]+0 S2 A16])))
The combiner then recursively tries to simplify this RTL. During simplifying the
subreg part of the RTL i.e.
(subreg:QI ((sign_extend:SI (mem:HI (pre_inc:DI (reg:DI 113 ivtmp.23 ])) [0
MEM[base: D.2294_40, offset:
0B]+0 S2 A16])))
combine_simplify_rtx () calls simplify_subreg () and this returns
(subreg:QI (mem:HI (pre_inc:DI (reg:DI 113 ivtmp.23 ])) [0
MEM[base: D.2294_40, offset: 0B]+0 S2 A16])))
The code that does this is in combine.c:combine_simplify_rtx ()
...
rtx temp;
temp = simplify_subreg (mode, SUBREG_REG (x), op0_mode,
SUBREG_BYTE (x));
if (temp)
return temp;
}
...
So, the above tree is returned as is and insn 87 gets combined into insn 89 to
become
(insn 89 87 90 4 (set (reg:SI 155)
(ashift:SI (reg:SI 158)
(subreg:QI (mem:HI (pre_inc:DI (reg:DI 113 ivtmp.23 ])) [0
MEM[base: D.2294_40, offset: 0B]+0 S2 A16])))
This ends up in reload and in cleanup_subreg_operands () the subreg:QI (mem:HI)
gets narrowed to mem:QI, but the interesting bit is that the pre_inc stays the
same, so becomes a pre_inc for a QI mode address rather than the original HI
mode address and therefore instead of addressing a byte and incrementing the
address by 2 to get the next half word, the address gets incremented by 1!
Also, I feel this is a latent bug on the trunk. This is because while the
combiner takes the same path on the trunk, the address expression is not a
pre_inc there - the trunk wants to keep the addressing to a mem (plus (reg)
(const)) and therefore combine_simplify_rtx () simplifies the subreg expression
right down to the narrowed memref i.e. mem:QI (plus:DI (reg:DI) (const)). This
gets combined to insn 89 to become
(insn 89 87 90 4 (set (reg:SI 155)
(ashift:SI (reg:SI 158) (mem:QI (plus:DI (reg:DI) (const
This then, gets later checked with recog () and since the predicate for operand
2 does not allow memory operands for shifts in aarch64.md, does not get combined
and all is well.
After the discussions Richard Earnshaw had on IRC with Andrew Pinski, it was
felt that it was best to fix the standard predicate
'general_operand' to not allow SUBREG (MEM) with side-effects as it has known
issues associated with it - particularly reload not being able to deal with such
cases. 'general_operand' currently outlaws cases like paradoxical SUBREG (MEM)
on targets with insn scheduling and SUBREG (MEM) with non-zero SUBREG_BYTE. This
is another case it should not allow. Here is a patch that tightens
general_operands to not allow SUBREG (MEM) with MEM having side-effects.
I would like to hear some thoughts on this.
Thanks,
Tejas Belagod
ARM.diff --git a/gcc/recog.c b/gcc/recog.c
Re: [PATCH] PR c++/54875 - Error when instantiating an alias template that resolves to an enum
Jason Merrill ja...@redhat.com writes: On 11/16/2012 07:43 AM, Dodji Seketeli wrote: So I guess that condition should be changed to TREE_CODE (template_type) == ENUMERAL_TYPE, to specifically detect the member enum of a class template case. Why does that help? What is template_type in the alias template case? template_type is the template_type_parm T, which new name is AddConst. -- Dodji
Re: [PATCH] PR c++/54875 - Error when instantiating an alias template that resolves to an enum
Ah, I see. OK. Jason
Re: [PATCH] asan testsuite (take 3)
On Fri, Nov 16, 2012 at 2:06 AM, Jakub Jelinek ja...@redhat.com wrote: Haven't studied libbacktrace too much, can it provide right now just function name or function name and file:line info too? Yes. backtrace_syminfo reads the symbol table to map a PC value to a symbol name. backtrace_pcinfo reads the debug info to map a PC value to file:line and function. The latter can return multiple instances of file:line/function information for the case of an inlined function. Also libbacktrace can separate the gathering of the backtrace from the symbolization of the backtrace. But it is true that libbacktrace, which uses the unwind info, will always be slower than walking up a linked list of frame pointers. Ian
Re: [PING] [PATCH] PR c++/54401 - Confusing diagnostics about type-alias at class scope
Would it work to just do a cp_parser_commit_to_tentative_parse after we see the '='? Jason
Patch: add AM_MAINTAINER_MODE in libsanitizer
My build of gcc today tried to run autoconf in libsanitizer. However, I had the wrong version in my path, so the build died. In gcc it is normal to use AM_MAINTAINER_MODE to avoid this problem. I think this is missing from libsanitizer/configure.ac due to an oversight. This patch adds the missing call. Ok? Tom 2012-11-16 Tom Tromey tro...@redhat.com * configure.ac: Invoke AM_MAINTAINER_MODE. * aclocal.m4, configure, Makefile.in, asan/Makefile.in, interception/Makefile.in, sanitizer_common/Makefile.in: Rebuild. diff --git a/libsanitizer/configure.ac b/libsanitizer/configure.ac index 76a19b6..4fb576f 100644 --- a/libsanitizer/configure.ac +++ b/libsanitizer/configure.ac @@ -24,6 +24,7 @@ AC_SUBST(target_alias) AM_INIT_AUTOMAKE(foreign) AM_ENABLE_MULTILIB(, ..) +AM_MAINTAINER_MODE # Calculate toolexeclibdir # Also toolexecdir, though it's only used in toolexeclibdir
Re: Patch: add AM_MAINTAINER_MODE in libsanitizer
On Fri, Nov 16, 2012 at 07:57:59AM -0700, Tom Tromey wrote: My build of gcc today tried to run autoconf in libsanitizer. However, I had the wrong version in my path, so the build died. In gcc it is normal to use AM_MAINTAINER_MODE to avoid this problem. I think this is missing from libsanitizer/configure.ac due to an oversight. This patch adds the missing call. Ok? Yes, thanks. 2012-11-16 Tom Tromey tro...@redhat.com * configure.ac: Invoke AM_MAINTAINER_MODE. * aclocal.m4, configure, Makefile.in, asan/Makefile.in, interception/Makefile.in, sanitizer_common/Makefile.in: Rebuild. diff --git a/libsanitizer/configure.ac b/libsanitizer/configure.ac index 76a19b6..4fb576f 100644 --- a/libsanitizer/configure.ac +++ b/libsanitizer/configure.ac @@ -24,6 +24,7 @@ AC_SUBST(target_alias) AM_INIT_AUTOMAKE(foreign) AM_ENABLE_MULTILIB(, ..) +AM_MAINTAINER_MODE # Calculate toolexeclibdir # Also toolexecdir, though it's only used in toolexeclibdir Jakub
Re: Patch: add AM_MAINTAINER_MODE in libsanitizer
Tom Tromey tro...@redhat.com a écrit: My build of gcc today tried to run autoconf in libsanitizer. However, I had the wrong version in my path, so the build died. In gcc it is normal to use AM_MAINTAINER_MODE to avoid this problem. I think this is missing from libsanitizer/configure.ac due to an oversight. This patch adds the missing call. Ok? Yes. 2012-11-16 Tom Tromey tro...@redhat.com * configure.ac: Invoke AM_MAINTAINER_MODE. * aclocal.m4, configure, Makefile.in, asan/Makefile.in, interception/Makefile.in, sanitizer_common/Makefile.in: Rebuild. Thanks. diff --git a/libsanitizer/configure.ac b/libsanitizer/configure.ac index 76a19b6..4fb576f 100644 --- a/libsanitizer/configure.ac +++ b/libsanitizer/configure.ac @@ -24,6 +24,7 @@ AC_SUBST(target_alias) AM_INIT_AUTOMAKE(foreign) AM_ENABLE_MULTILIB(, ..) +AM_MAINTAINER_MODE # Calculate toolexeclibdir # Also toolexecdir, though it's only used in toolexeclibdir -- Dodji
Re: VEC re-write [patch 02/25]
2012-11-15 Diego Novillo dnovi...@google.com * gengtype-lex.l (VEC): Remove. Add characters in the set [\!\\.-]. * gengtype-parse.c (token_names): Remove VEC. (require_template_declaration): Remove handling of VEC_TOKEN. (type): Likewise. Call create_user_defined_type when parsing GTY((user)). * gengtype-state.c (type_lineloc): handle TYPE_UNDEFINED. (write_state_undefined_type): New. (write_state_type): Call write_state_undefined_type for TYPE_UNDEFINED. (read_state_type): Call read_state_undefined_type for TYPE_UNDEFINED. * gengtype.c (dbgprint_count_type_at): Handle TYPE_UNDEFINED. (create_user_defined_type): Make extern. (type_for_name): Factor out of resolve_typedef. (create_undefined_type): New (resolve_typedef): Call it when we cannot find a previous typedef and the type is not a template. (find_structure): Accept TYPE_UNDEFINED. (set_gc_used_type): Add argument ALLOWED_UNDEFINED_TYPES, default to false. Emit an error for TYPE_UNDEFINED unless LEVEL is GC_UNUSED or ALLOWED_UNDEFINED_TYPES is set. Set ALLOWED_UNDEFINED_TYPES to true for TYPE_USER_STRUCT. (filter_type_name): Accept templates with more than one argument. (output_mangled_typename): Handle TYPE_UNDEFINED (walk_type): Likewise. (write_types_process_field): Likewise. (write_func_for_structure): If CHAIN_NEXT is set, ORIG_S should not be a user-defined type. (write_types_local_user_process_field): Handle TYPE_ARRAY, TYPE_NONE and TYPE_UNDEFINED. (write_types_local_process_field): Likewise. (contains_scalar_p): Return 0 for TYPE_USER_STRUCT. (write_root): Reject user-defined types that are not pointers. Handle TYPE_NONE, TYPE_UNDEFINED, TYPE_UNION, TYPE_LANG_STRUCT and TYPE_PARAM_STRUCT. (output_typename): Handle TYPE_NONE, TYPE_UNDEFINED, and TYPE_ARRAY. (dump_typekind): Handle TYPE_UNDEFINED. * gengtype.h (enum typekind): Add TYPE_UNDEFINED. (create_user_defined_type): Declare. (enum gty_token): Remove VEC_TOKEN. OK. Thanks, -- Laurynas
Re: ASAN merge...
On Fri, Nov 16, 2012 at 1:54 AM, Andrew Haley a...@redhat.com wrote: On 11/14/2012 01:49 PM, Richard Earnshaw wrote: Please please don't get into the habit of calling it ARM32 and ARM64, you're just sowing confusion; there are good reasons why those names weren't adopted (some technical, some not) and I'm not about to rehash them all now. AArch32 and AArch64 aren't that much harder to type and they are completely unambiguous. And they can't be pronounced in any reasonable way. I think you're going to lose this one. I expect it's pronounced with a sort of throat-clearing noise that is hard to write. Sort of like the gargling sound represented by argh. argh32 and argh64. Ian
Re: ASAN merge...
On 16/11/12 15:35, Ian Lance Taylor wrote: On Fri, Nov 16, 2012 at 1:54 AM, Andrew Haley a...@redhat.com wrote: On 11/14/2012 01:49 PM, Richard Earnshaw wrote: Please please don't get into the habit of calling it ARM32 and ARM64, you're just sowing confusion; there are good reasons why those names weren't adopted (some technical, some not) and I'm not about to rehash them all now. AArch32 and AArch64 aren't that much harder to type and they are completely unambiguous. And they can't be pronounced in any reasonable way. I think you're going to lose this one. I expect it's pronounced with a sort of throat-clearing noise that is hard to write. Sort of like the gargling sound represented by argh. argh32 and argh64. Ian No, its pronounced Ay-Arch. It's not really hard to say, or think. R.
[PATCH, testsuite]: Cleanup some leftover dump files
Hello!
2012-11-16 Uros Bizjak ubiz...@gmail.com
* lib/gcc-dg.exp (cleanup-saved-temps): Add .mii to suffixes.
* gcc.dg/hoist-register-pressure-1.c: Cleanup hoist rtl dump.
* gcc.dg/hoist-register-pressure-2.c: Ditto.
* gcc.dg/hoist-register-pressure-3.c: Ditto.
* gcc.dg/tree-prof/peel-1.c: Cleanup loop2_unroll rtl dump.
* gcc.dg/tree-prof/unroll-1.c: Ditto.
Tested on x86_64-linux-gnu, committed to mainline SVN.
Uros.
Index: gcc.dg/hoist-register-pressure-1.c
===
--- gcc.dg/hoist-register-pressure-1.c (revision 193549)
+++ gcc.dg/hoist-register-pressure-1.c (working copy)
@@ -1,5 +1,6 @@
/* { dg-options -Os -fdump-rtl-hoist } */
/* { dg-final { scan-rtl-dump PRE/HOIST: end of bb .* copying expression
hoist { target { nonpic } } } } */
+/* { dg-final { cleanup-rtl-dump hoist } } */
#define BUF 100
int a[BUF];
Index: gcc.dg/hoist-register-pressure-2.c
===
--- gcc.dg/hoist-register-pressure-2.c (revision 193549)
+++ gcc.dg/hoist-register-pressure-2.c (working copy)
@@ -1,5 +1,6 @@
/* { dg-options -Os -fdump-rtl-hoist } */
/* { dg-final { scan-rtl-dump PRE/HOIST: end of bb .* copying expression
hoist } } */
+/* { dg-final { cleanup-rtl-dump hoist } } */
#define BUF 100
int a[BUF];
Index: gcc.dg/hoist-register-pressure-3.c
===
--- gcc.dg/hoist-register-pressure-3.c (revision 193549)
+++ gcc.dg/hoist-register-pressure-3.c (working copy)
@@ -1,5 +1,6 @@
/* { dg-options -Os -fdump-rtl-hoist } */
/* { dg-final { scan-rtl-dump PRE/HOIST: end of bb .* copying expression
hoist } } */
+/* { dg-final { cleanup-rtl-dump hoist } } */
#define BUF 100
int a[BUF];
Index: gcc.dg/tree-prof/peel-1.c
===
--- gcc.dg/tree-prof/peel-1.c (revision 193549)
+++ gcc.dg/tree-prof/peel-1.c (working copy)
@@ -22,4 +22,4 @@
/* { dg-final-use { scan-rtl-dump Considering simply peeling loop
loop2_unroll } } */
/* In fact one peeling is enough; we however mispredict number of iterations
of the loop
at least until loop_ch is schedule ahead of profiling pass. */
-/* { dg-final-use { cleanup-rtl-dump Decided to simply peel the loop 2 times
} } */
+/* { dg-final-use { cleanup-rtl-dump loop2_unroll } } */
Index: gcc.dg/tree-prof/unroll-1.c
===
--- gcc.dg/tree-prof/unroll-1.c (revision 193549)
+++ gcc.dg/tree-prof/unroll-1.c (working copy)
@@ -20,4 +20,4 @@
return 0;
}
/* { dg-final-use { scan-rtl-dump Considering unrolling loop with constant
number of iterations loop2_unroll } } */
-/* { dg-final-use { cleanup-rtl-dump Not unrolling loop, doesn't roll } } */
+/* { dg-final-use { cleanup-rtl-dump loop2_unroll } } */
Index: lib/gcc-dg.exp
===
--- lib/gcc-dg.exp (revision 193549)
+++ lib/gcc-dg.exp (working copy)
@@ -549,7 +549,7 @@
set suffixes {}
# add the to-be-kept suffixes
-foreach suffix {.ii .i .s .o .gkd} {
+foreach suffix {.mii .ii .i .s .o .gkd} {
if {[lsearch $args $suffix] 0} {
lappend suffixes $suffix
}
Re: [PING] [PATCH] PR c++/54401 - Confusing diagnostics about type-alias at class scope
On Fri, Nov 16, 2012 at 8:51 AM, Jason Merrill ja...@redhat.com wrote: Would it work to just do a cp_parser_commit_to_tentative_parse after we see the '='? I like that solution better. -- Gaby
Re: [PATCH 00/13] Request to merge Address Sanitizer in
On Fri, Nov 16, 2012 at 09:27:26AM +0100, Dodji Seketeli wrote:
Jack Howarth howa...@bromo.med.uc.edu writes:
The Google branch is missing the required
interception/mach_override/mach_override.h and
interception/mach_override/mach_override.c files from compiler-rt svn
for darwin. I have posted what I believe to be the final patch which
eanbles libsanitizer on darwin...
http://gcc.gnu.org/ml/gcc-patches/2012-11/msg01285.html
I see in that thread that Mike Stump has approves the patch if no
asan{-darwin} people disagrees. I'll abide by principle, FWIW. :-)
which has been tested with the existing asan testsuite, the
use-after-free.c testcase as well as the Polyhedron 2005 benchmarks
for -O1 -g -fno-omit-frame-pointer -faddress-sanitizer and -O3
-funroll-loops -ffast-math -g -fno-omit-frame-pointer
-faddress-sanitizer to prove that the current mach_override from
upstream is sufficient for darwin to use.
I see. Thanks.
Due to the large number of maintainers for libsanitizer, it is unclear
who is the person responsible for upstream merges to lobby for these
files to be ported into gcc trunk. With Alexander Potapenko's commit
of the bug fix to mach_override/mach_override.c required for FSF
gcc...
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20121112/155989.html
...there really is no reason to continue to delay (as the interpose code
simply won't
be completed in time for gcc 4.8.0).
It makes sense to me.
Can we please get some movement on importing these missing files from
upstream?
Well, given that
Konstantin Serebryany konstantin.s.serebry...@gmail.com writes:
I see no problems with committing mach_override to gcc.
The code should be verbatim copy from
llvm/projects/compiler-rt/lib/interception/mach_override
Note that this code comes with an MIT license and was not developed by
Google (we did add quite a few patches).
... Konstantin who is one of the libsanitizer maintainers agrees, I see
no reason to delay this either.
So, Jack, as you are on top of this topic and has the platform to test
at hand, I guess you could just import the missing files from the llvm
repository and commit them to GCC, unless a GCC maintainers disagrees,
of course.
Dodji,
Attached is a new version of the patch adjusted for the bit-rot from
the maintainer-mode checkins of today and with the missing files for
libsanitizer/interception/mach_override/mach_override.c and
libsanitizer/interception/mach_override/mach_override.h from llvm
compiler-rt svn at...
r168032 | glider | 2012-11-15 03:32:16 -0500 (Thu, 15 Nov 2012) | 3 lines
[ASan] Add the lea $imm(%rip),%rax instruction to mach_override.c
The need for this has been reported by Jack Howarth (howa...@bromo.med.uc.edu)
who's porting ASan-Darwin to GCC
added to the patch so that you can make any required licensing adjustments to
the comments at the top of those files. Hopefully we can get this in soon as
the build parts keep bit-rotting.
Jack
ps I added you to the ChangeLog for the llvm file imports since I believe that
should be
done by the libsanitizer maintainers. Thanks in advance for handling the commit
in
both gcc trunk and gcc asan branch.
Thus, you could maybe just send the patch of the file you are about to
commit as a reply to this thread, so that Konstantin and Alexander can
officially ACK it? I am mentioning Alexander because of what Konstantin
is saying ...
Also, Alexander Potapenko is the best person to ask about asan-darwin.
here.
Maybe we can add him to the list of sanitizer maintainers?
Seconded. At least for libsanitier/Darwin.
Cheers.
--
Dodji
gcc/
2012-11-16 Jack Howarth howa...@bromo.med.uc.edu
* config/darwin.h (LINK_COMMAND_SPEC_A): Deal with -faddress-sanitizer.
libsanitizer/
2012-11-16 Dodji Seketeli do...@redhat.com
Jack Howarth howa...@bromo.med.uc.edu
* interception/mach_override/mach_override.c: Migrate from llvm.
* interception/mach_override/mach_override.h: Likewise.
* configure.tgt: Add darwin to supported targets.
* configure.ac: Define USING_MACH_OVERRIDE when on darwin.
* interception/Makefile.am: Compile mach_override.c when
USING_MACH_OVERRIDE defined.
* configure: Regenerated.
* interception/Makefile.in: Likewise.
--- /dev/null 2012-11-16 10:24:58.0 -0500
+++ libsanitizer/interception/mach_override/mach_override.c 2012-11-16
10:26:42.0 -0500
@@ -0,0 +1,970 @@
+/***
+ mach_override.c
+ Copyright (c) 2003-2009 Jonathan 'Wolf' Rentzsch:
http://rentzsch.com
+ Some rights reserved:
http://opensource.org/licenses/mit-license.php
+
+
Re: [PATCH 00/13] Request to merge Address Sanitizer in
On Fri, Nov 16, 2012 at 10:57:04AM -0500, Jack Howarth wrote: +case $host in + *-*-darwin*) MACH_OVERRIDE=true ;; + *) MACH_OVERRIDE=false ;; +esac +AM_CONDITIONAL(USING_MACH_OVERRIDE, $MACH_OVERRIDE) + Shouldn't AM_CONDITIONAL follow AM_INIT_AUTOMAKE? I'd say move it before AC_CONFIG_FILES or so. Jakub
[Patch AArch64] Refactor thunks code generation
Hi,
I'm sending this on behalf of Sofiane Naci who
is currently on holiday.
Code generation for C++ thunks previously spat out assembly code,
which affects scheduling of the generated code.
This patch rewrites the code to generate RTL patterns.
A full aarch64-none-elf regression run shows no issues.
Thanks
Sofiane
---
gcc/
2012-11-16 Sofiane Naci sofiane.n...@arm.com
* config/aarch64/aarch64.c
(aarch64_output_mi_thunk): Refactor to generate RTL patterns.
diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index 4437fef..7d1e7a2 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -2335,9 +2335,10 @@ aarch64_output_mi_thunk (FILE *file, tree thunk ATTRIBUTE_UNUSED,
to return a pointer to an aggregate. On AArch64 a result value
pointer will be in x8. */
int this_regno = R0_REGNUM;
+ rtx this_rtx, temp0, temp1, addr, insn, funexp;
- /* Make sure unwind info is emitted for the thunk if needed. */
- final_start_function (emit_barrier (), file, 1);
+ reload_completed = 1;
+ emit_note (NOTE_INSN_PROLOGUE_END);
if (vcall_offset == 0)
aarch64_add_constant (file, this_regno, IP1_REGNUM, delta);
@@ -2345,37 +2346,55 @@ aarch64_output_mi_thunk (FILE *file, tree thunk ATTRIBUTE_UNUSED,
{
gcc_assert ((vcall_offset 0x7) == 0);
- if (delta == 0)
- asm_fprintf (file, \tldr\t%r, [%r]\n, IP0_REGNUM, this_regno);
- else if (delta = -256 delta 256)
- asm_fprintf (file, \tldr\t%r, [%r,%wd]!\n, IP0_REGNUM, this_regno,
- delta);
- else
- {
- aarch64_add_constant (file, this_regno, IP1_REGNUM, delta);
+ this_rtx = gen_rtx_REG (Pmode, this_regno);
+ temp0 = gen_rtx_REG (Pmode, IP0_REGNUM);
+ temp1 = gen_rtx_REG (Pmode, IP1_REGNUM);
- asm_fprintf (file, \tldr\t%r, [%r]\n, IP0_REGNUM, this_regno);
+ addr = this_rtx;
+ if (delta != 0)
+ {
+ if (delta = -256 delta 256)
+ addr = gen_rtx_PRE_MODIFY (Pmode, this_rtx,
+ plus_constant (Pmode, this_rtx, delta));
+ else
+ aarch64_add_constant (file, this_regno, IP1_REGNUM, delta);
}
+ aarch64_emit_move (temp0, gen_rtx_MEM (Pmode, addr));
+
if (vcall_offset = -256 vcall_offset 32768)
- asm_fprintf (file, \tldr\t%r, [%r,%wd]\n, IP1_REGNUM, IP0_REGNUM,
- vcall_offset);
+ addr = plus_constant (Pmode, temp0, vcall_offset);
else
{
aarch64_build_constant (file, IP1_REGNUM, vcall_offset);
- asm_fprintf (file, \tldr\t%r, [%r,%r]\n, IP1_REGNUM, IP0_REGNUM,
- IP1_REGNUM);
+ addr = gen_rtx_PLUS (Pmode, temp0, temp1);
}
- asm_fprintf (file, \tadd\t%r, %r, %r\n, this_regno, this_regno,
- IP1_REGNUM);
+ aarch64_emit_move (temp1, gen_rtx_MEM (Pmode,addr));
+ emit_insn (gen_add2_insn (this_rtx, temp1));
}
- output_asm_insn (b\t%a0, XEXP (DECL_RTL (function), 0));
+ /* Generate a tail call to the target function. */
+ if (!TREE_USED (function))
+{
+ assemble_external (function);
+ TREE_USED (function) = 1;
+}
+ funexp = XEXP (DECL_RTL (function), 0);
+ funexp = gen_rtx_MEM (FUNCTION_MODE, funexp);
+ insn = emit_call_insn (gen_sibcall (funexp, const0_rtx, NULL_RTX));
+ SIBLING_CALL_P (insn) = 1;
+
+ insn = get_insns ();
+ shorten_branches (insn);
+ final_start_function (insn, file, 1);
+ final (insn, file, 1);
final_end_function ();
+
+ /* Stop pretending to be a post-reload pass. */
+ reload_completed = 0;
}
-
static int
aarch64_tls_operand_p_1 (rtx *x, void *data ATTRIBUTE_UNUSED)
{
Go patch committed: Add + to Make-lang.in as needed
This patch adds + to gcc/go/Make-lang.in as needed so that the make -j option will work correctly when doing an LTO bootstrap. This corresponds to similar patches to other frontends. Bootstrapped on x86_64-unknown-linux-gnu. Committed to mainline. Ian Index: gcc/go/Make-lang.in === --- gcc/go/Make-lang.in (revision 193484) +++ gcc/go/Make-lang.in (working copy) @@ -38,7 +38,7 @@ gospec.o: $(srcdir)/go/gospec.c $(SYSTEM GCCGO_OBJS = $(GCC_OBJS) gospec.o gccgo$(exeext): $(GCCGO_OBJS) $(EXTRA_GCC_OBJS) libcommon-target.a $(LIBDEPS) - $(LINKER) $(ALL_LINKERFLAGS) $(LDFLAGS) -o $@ \ + +$(LINKER) $(ALL_LINKERFLAGS) $(LDFLAGS) -o $@ \ $(GCCGO_OBJS) $(EXTRA_GCC_OBJS) libcommon-target.a \ $(EXTRA_GCC_LIBS) $(LIBS) @@ -76,7 +76,7 @@ GO_OBJS = \ go/unsafe.o go1$(exeext): $(GO_OBJS) attribs.o $(BACKEND) $(LIBDEPS) - $(CXX) $(ALL_CXXFLAGS) $(LDFLAGS) -o $@ \ + +$(CXX) $(ALL_CXXFLAGS) $(LDFLAGS) -o $@ \ $(GO_OBJS) attribs.o $(BACKEND) $(LIBS) $(BACKENDLIBS) # Documentation.
Go patch committed: Don't remove float conversion of typed constant
This patch to the Go frontend fixes the case of float64(float32(1.0)).
Here float32(1.0) is a typed constant. The compiler was translating
that to float64(1.0), which is not correct. Bootstrapped and ran Go
testsuite on x86_64-unknown-linux-gnu. Committed to mainline and 4.7
branch.
Ian
Index: gcc/go/gofrontend/expressions.cc
===
--- gcc/go/gofrontend/expressions.cc (revision 193484)
+++ gcc/go/gofrontend/expressions.cc (working copy)
@@ -2962,6 +2962,46 @@ Type_conversion_expression::do_lower(Gog
{
if (!nc.set_type(type, true, location))
return Expression::make_error(location);
+
+ // Don't simply convert to or from a float or complex type
+ // with a different size. That may change the value.
+ Type* vtype = val-type();
+ if (vtype-is_abstract())
+ ;
+ else if (type-float_type() != NULL)
+ {
+ if (vtype-float_type() != NULL)
+ {
+ if (type-float_type()-bits() != vtype-float_type()-bits())
+ return this;
+ }
+ else if (vtype-complex_type() != NULL)
+ {
+ if (type-float_type()-bits() * 2
+ != vtype-complex_type()-bits())
+ return this;
+ }
+ }
+ else if (type-complex_type() != NULL)
+ {
+ if (vtype-complex_type() != NULL)
+ {
+ if (type-complex_type()-bits()
+ != vtype-complex_type()-bits())
+ return this;
+ }
+ else if (vtype-float_type() != NULL)
+ {
+ if (type-complex_type()-bits()
+ != vtype-float_type()-bits() * 2)
+ return this;
+ }
+ }
+ else if (vtype-float_type() != NULL)
+ return this;
+ else if (vtype-complex_type() != NULL)
+ return this;
+
return nc.expression(location);
}
}
Re: VEC re-write [patch 09/25]
Diego == Diego Novillo dnovi...@google.com writes: Diego 2012-11-15 Diego Novillo dnovi...@google.com Diego Adjust for new vec API (http://gcc.gnu.org/wiki/cxx-conversion/cxx-vec) Diego * boehm.c: Use new vec API in vec.h. Diego * class.c: Likewise. Diego * constants.c: Likewise. Diego * decl.c: Likewise. Diego * expr.c: Likewise. Diego * java-tree.h: Likewise. Diego * jcf-parse.c: Likewise. Diego * resource.c: Likewise. Diego * verify-glue.c: Likewise. Looks nice. Thanks. I have one nit: Diego= build_utf8_ref (unmangle_classname (IDENTIFIER_POINTER (sig), Diego -IDENTIFIER_LENGTH (sig))); Diego -e = VEC_index (constructor_elt, v, idx--); Diego +IDENTIFIER_LENGTH (sig))); Diego +e = (*v)[idx--]; Looks like a spurious reindentation of the IDENTIFIER_LENGTH line. Tom
patch to fix PR55330
The following patch fixes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55330
The problem was in a complex interaction of inheritance and
constraint passes. The test would be compiled successfully if we
increased the number constraint passes. But for such pass interaction,
it hard to know how many passes we need (it can be depended on register
pressure). So my solution for the problem is to put a limit on number
of inheritance passes. I did some experiments. The most important is
the first inheritance pass. The 3rd inheritance pass has practically no
affect on code generation on most tests, e.g. SPEC2000 code on x86-64 is
not changed when we add the 3rd pass. The limit might be defined as a
compiler parameter but after some thoughts I've decided not to do this
as it is not easy to describe constraints on the value and changing the
value I use has no practical sense.
The patch was successfully bootstrapped on x86/x86-64.
Committed as rev. 193567.
2012-11-16 Vladimir Makarov vmaka...@redhat.com
PR rtl-optimization/55330
* lra-constraints.c (MAX_INHERITANCE_PASSES): New macro.
(lra_inheritance, lra_undo_inheritance): Use it to limit number of
the passes.
2012-11-16 Vladimir Makarov vmaka...@redhat.com
PR rtl-optimization/55330
* gfortran.dg/pr55330.f90: New test.
Index: lra-constraints.c
===
--- lra-constraints.c (revision 193557)
+++ lra-constraints.c (working copy)
@@ -4633,6 +4633,21 @@ inherit_in_ebb (rtx head, rtx tail)
return change_p;
}
+/* The maximal number of inheritance/split passes in LRA. It should
+ be more 1 in order to perform caller saves transformations and much
+ less MAX_CONSTRAINT_ITERATION_NUMBER to prevent LRA to do as many
+ as permitted constraint passes in some complicated cases. The
+ first inheritance/split pass has a biggest impact on generated code
+ quality. Each subsequent affects generated code in less degree.
+ For example, the 3rd pass does not change generated SPEC2000 code
+ at all on x86-64. */
+#define MAX_INHERITANCE_PASSES 2
+
+#if MAX_INHERITANCE_PASSES = 0 \
+|| MAX_INHERITANCE_PASSES = MAX_CONSTRAINT_ITERATION_NUMBER - 8
+#error wrong MAX_INHERITANCE_PASSES value
+#endif
+
/* This value affects EBB forming. If probability of edge from EBB to
a BB is not greater than the following value, we don't add the BB
to EBB. */
@@ -4649,8 +4664,10 @@ lra_inheritance (void)
basic_block bb, start_bb;
edge e;
- timevar_push (TV_LRA_INHERITANCE);
lra_inheritance_iter++;
+ if (lra_inheritance_iter MAX_INHERITANCE_PASSES)
+return;
+ timevar_push (TV_LRA_INHERITANCE);
if (lra_dump_file != NULL)
fprintf (lra_dump_file, \n** Inheritance #%d: **\n\n,
lra_inheritance_iter);
@@ -4920,6 +4937,8 @@ lra_undo_inheritance (void)
bool change_p;
lra_undo_inheritance_iter++;
+ if (lra_undo_inheritance_iter MAX_INHERITANCE_PASSES)
+return false;
if (lra_dump_file != NULL)
fprintf (lra_dump_file,
\n** Undoing inheritance #%d: **\n\n,
Index: testsuite/gfortran.dg/pr55330.f90
===
--- testsuite/gfortran.dg/pr55330.f90 (revision 0)
+++ testsuite/gfortran.dg/pr55330.f90 (working copy)
@@ -0,0 +1,73 @@
+! PR rtl-optimization/55330
+! { dg-do compile }
+! { dg-options -O -fPIC -fno-dse -fno-guess-branch-probability }
+
+module global
+ publicp, line
+ interface p
+module procedure p
+ end interface
+ character(128) :: line = 'abcdefghijklmnopqrstuvwxyz'
+contains
+ subroutine p()
+character(128) :: word
+word = line
+call redirect_((/word/))
+ end subroutine
+ subroutine redirect_ (ch)
+character(*) :: ch(:)
+if (ch(1) /= line) call abort ()
+ end subroutine redirect_
+end module global
+
+module my_module
+ implicit none
+ type point
+real :: x
+ end type point
+ type(point), pointer, public :: stdin = NULL()
+contains
+ subroutine my_p(w)
+character(128) :: w
+call r(stdin,(/w/))
+ end subroutine my_p
+ subroutine r(ptr, io)
+use global
+type(point), pointer :: ptr
+character(128) :: io(:)
+if (associated (ptr)) call abort ()
+if (io(1) .ne. line) call abort ()
+ end subroutine r
+end module my_module
+
+program main
+ use global
+ use my_module
+
+ integer :: i(6) = (/1,6,3,4,5,2/)
+ character (6) :: a = 'hello ', t
+ character(len=1) :: s(6) = (/'g','g','d','d','a','o'/)
+ equivalence (s, t)
+
+ call option_stopwatch_s (a)
+ call p ()
+ call my_p (line)
+
+ s = s(i)
+ call option_stopwatch_a ((/a,'hola! ', t/))
+
+contains
+
+ subroutine option_stopwatch_s(a)
+character (*), intent(in) :: a
+character (len=len(a)) :: b
+
+b = 'hola! '
+call option_stopwatch_a((/a, b, 'goddag'/))
+ end subroutine option_stopwatch_s
+ subroutine
Re: [PATCH 00/13] Request to merge Address Sanitizer in
On Fri, Nov 16, 2012 at 05:00:22PM +0100, Jakub Jelinek wrote:
On Fri, Nov 16, 2012 at 10:57:04AM -0500, Jack Howarth wrote:
+case $host in
+ *-*-darwin*) MACH_OVERRIDE=true ;;
+ *) MACH_OVERRIDE=false ;;
+esac
+AM_CONDITIONAL(USING_MACH_OVERRIDE, $MACH_OVERRIDE)
+
Shouldn't AM_CONDITIONAL follow AM_INIT_AUTOMAKE? I'd say move it
before AC_CONFIG_FILES or so.
Jakub
Jakub,
Done. Any chance you can commit this one (with yourself in the ChangeLog
for the file imports from llvm) before this one bit-rots? Thanks in advance.
Jack
ps The configure.ac readjustment was tested on x86_64-apple-darwin12.
gcc/
2012-11-16 Jack Howarth howa...@bromo.med.uc.edu
* config/darwin.h (LINK_COMMAND_SPEC_A): Deal with -faddress-sanitizer.
libsanitizer/
2012-11-16 Dodji Seketeli do...@redhat.com
Jack Howarth howa...@bromo.med.uc.edu
* interception/mach_override/mach_override.c: Migrate from llvm.
* interception/mach_override/mach_override.h: Likewise.
* configure.tgt: Add darwin to supported targets.
* configure.ac: Define USING_MACH_OVERRIDE when on darwin.
* interception/Makefile.am: Compile mach_override.c when
USING_MACH_OVERRIDE defined.
* configure: Regenerated.
* interception/Makefile.in: Likewise.
--- /dev/null 2012-11-16 10:24:58.0 -0500
+++ libsanitizer/interception/mach_override/mach_override.c 2012-11-16
10:26:42.0 -0500
@@ -0,0 +1,970 @@
+/***
+ mach_override.c
+ Copyright (c) 2003-2009 Jonathan 'Wolf' Rentzsch:
http://rentzsch.com
+ Some rights reserved:
http://opensource.org/licenses/mit-license.php
+
+
***/
+#ifdef __APPLE__
+
+#include mach_override.h
+
+#include mach-o/dyld.h
+#include mach/mach_host.h
+#include mach/mach_init.h
+#include mach/vm_map.h
+#include sys/mman.h
+
+#include CoreServices/CoreServices.h
+
+//#define DEBUG_DISASM 1
+#undef DEBUG_DISASM
+
+/**
+*
+* Constants
+*
+**/
+#pragma mark -
+#pragma mark (Constants)
+
+#if defined(__ppc__) || defined(__POWERPC__)
+
+static
+long kIslandTemplate[] = {
+ 0x9001FFFC, // stw r0,-4(SP)
+ 0x3C00DEAD, // lis r0,0xDEAD
+ 0x6000BEEF, // ori r0,r0,0xBEEF
+ 0x7C0903A6, // mtctr r0
+ 0x8001FFFC, // lwz r0,-4(SP)
+ 0x6000, // nop ; optionally replaced
+ 0x4E800420 // bctr
+};
+
+#define kAddressHi 3
+#define kAddressLo 5
+#define kInstructionHi 10
+#define kInstructionLo 11
+
+#elif defined(__i386__)
+
+#define kOriginalInstructionsSize 16
+
+static
+unsigned char kIslandTemplate[] = {
+ // kOriginalInstructionsSize nop instructions so that we
+ // should have enough space to host original instructions
+ 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90,
+ 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90,
+ // Now the real jump instruction
+ 0xE9, 0xEF, 0xBE, 0xAD, 0xDE
+};
+
+#define kInstructions 0
+#define kJumpAddresskInstructions + kOriginalInstructionsSize + 1
+#elif defined(__x86_64__)
+
+#define kOriginalInstructionsSize 32
+
+#define kJumpAddresskOriginalInstructionsSize + 6
+
+static
+unsigned char kIslandTemplate[] = {
+ // kOriginalInstructionsSize nop instructions so that we
+ // should have enough space to host original instructions
+ 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90,
+ 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90,
+ 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90,
+ 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90,
+ // Now the real jump instruction
+ 0xFF, 0x25, 0x00, 0x00, 0x00, 0x00,
+0x00, 0x00, 0x00, 0x00,
+0x00, 0x00, 0x00, 0x00
+};
+
+#endif
+
+#definekAllocateHigh 1
+#definekAllocateNormal 0
+
+/**
+*
+* Data Types
+*
+**/
+#pragma mark -
+#pragma mark (Data Types)
+
+typedefstruct {
+ charinstructions[sizeof(kIslandTemplate)];
+ int allocatedHigh;
+} BranchIsland;
+
+/**
+*
+* Funky Protos
+*
+**/
+#pragma mark -
+#pragma mark (Funky Protos)
+
+
+ static mach_error_t
+allocateBranchIsland(
+ BranchIsland**island,
+ int allocateHigh,
+ void *originalFunctionAddress);
+
+ static mach_error_t
+freeBranchIsland(
+ BranchIsland*island );
+
+ static mach_error_t
Re: [PATCH 00/13] Request to merge Address Sanitizer in
Also, Alexander Potapenko is the best person to ask about asan-darwin. here. Maybe we can add him to the list of sanitizer maintainers? Seconded. At least for libsanitier/Darwin. Cheers. I can take this, but I'll be busy within the several upcoming days (till mid-next-week), so I won't be able to merge any patches from LLVM into GCC. Also, I'm not a GCC committer yet, and I guess someone will need to nominate me.
Re: [PATCH 00/13] Request to merge Address Sanitizer in
On Fri, Nov 16, 2012 at 08:55:52PM +0400, Alexander Potapenko wrote: Also, Alexander Potapenko is the best person to ask about asan-darwin. here. Maybe we can add him to the list of sanitizer maintainers? Seconded. At least for libsanitier/Darwin. Cheers. I can take this, but I'll be busy within the several upcoming days (till mid-next-week), so I won't be able to merge any patches from LLVM into GCC. Also, I'm not a GCC committer yet, and I guess someone will need to nominate me. Hopefully either Jakub or Dodji can handle the initial import of the mach_override files for now. I rather not have to keep updating the patches in the meanwhile for bit-rot. Jack
[patch] Remove DECL_RESTRICTED_P
Hi,
that's not really a bugfix, but I don't see the point in keeping this flag,
which was already dead in 4.7, one more release.
Tested on x86_64-suse-linux, OK for the mainline?
2012-11-16 Eric Botcazou ebotca...@adacore.com
* tree.h (DECL_RESTRICTED_P): Delete.
(DECL_READ_P): Add comment.
(DECL_NONSHAREABLE): Likewise.
(struct tree_decl_common): Remove decl_restricted_flag, add decl_flag_3.
* tree-emutls.c (new_emutls_decl): Do not deal with DECL_RESTRICTED_P.
* tree-streamer-in.c (unpack_ts_decl_common_value_fields): Likewise.
* tree-streamer-out.c (pack_ts_decl_common_value_fields): Likewise.
fortran/
* trans-decl.c (gfc_finish_var_decl): Do not set DECL_RESTRICTED_P.
--
Eric BotcazouIndex: tree.h
===
--- tree.h (revision 193557)
+++ tree.h (working copy)
@@ -1324,18 +1324,13 @@ extern void omp_clause_range_check_faile
(TREE_CHECK3 (NODE, VAR_DECL, PARM_DECL, \
RESULT_DECL)-decl_common.decl_by_reference_flag)
-/* In a RESULT_DECL, PARM_DECL and VAR_DECL, means that this decl
- can be used as restricted tag to disambiguate against other restrict
- pointers. Used by fortran to capture something like non-addressability
- (which it isn't really because the middle-end does take addresses of
- such variables). */
-#define DECL_RESTRICTED_P(NODE) \
- (TREE_CHECK3 (NODE, VAR_DECL, PARM_DECL, \
- RESULT_DECL)-decl_common.decl_restricted_flag)
-
+/* In VAR_DECL and PARM_DECL, set when the decl has been used except for
+ being set. */
#define DECL_READ_P(NODE) \
(TREE_CHECK2 (NODE, VAR_DECL, PARM_DECL)-decl_common.decl_read_flag)
+/* In VAR_DECL or RESULT_DECL, set when significant code movement precludes
+ attempting to share the stack slot with some other variable. */
#define DECL_NONSHAREABLE(NODE) \
(TREE_CHECK2 (NODE, VAR_DECL, \
RESULT_DECL)-decl_common.decl_nonshareable_flag)
@@ -2854,26 +2849,22 @@ struct GTY(()) tree_decl_common {
In VAR_DECL, PARM_DECL and RESULT_DECL, this is
DECL_HAS_VALUE_EXPR_P. */
unsigned decl_flag_2 : 1;
+ /* 1 bit unused. */
+ unsigned decl_flag_3 : 1;
/* Logically, these two would go in a theoretical base shared by var and
parm decl. */
unsigned gimple_reg_flag : 1;
/* In VAR_DECL, PARM_DECL and RESULT_DECL, this is DECL_BY_REFERENCE. */
unsigned decl_by_reference_flag : 1;
- /* In VAR_DECL, PARM_DECL and RESULT_DECL, this is DECL_RESTRICTED_P. */
- unsigned decl_restricted_flag : 1;
-
- /* In VAR_DECL and PARM_DECL set when the decl has been used except for
- being set. */
+ /* In a VAR_DECL and PARM_DECL, this is DECL_READ_P. */
unsigned decl_read_flag : 1;
-
- /* In VAR_DECL or RESULT_DECL set when significant code movement precludes
- attempting to share the stack slot with some other variable. */
+ /* In a VAR_DECL or RESULT_DECL, this is DECL_NONSHAREABLE. */
unsigned decl_nonshareable_flag : 1;
/* DECL_OFFSET_ALIGN, used only for FIELD_DECLs. */
unsigned int off_align : 8;
- /* 24-bits unused. */
+ /* 24 bits unused. */
/* DECL_ALIGN. It should have the same size as TYPE_ALIGN. */
unsigned int align;
Index: tree-emutls.c
===
--- tree-emutls.c (revision 193557)
+++ tree-emutls.c (working copy)
@@ -295,7 +295,6 @@ new_emutls_decl (tree decl, tree alias_o
DECL_WEAK (to) = DECL_WEAK (decl);
DECL_VISIBILITY (to) = DECL_VISIBILITY (decl);
DECL_VISIBILITY_SPECIFIED (to) = DECL_VISIBILITY_SPECIFIED (decl);
- DECL_RESTRICTED_P (to) = DECL_RESTRICTED_P (decl);
DECL_DLLIMPORT_P (to) = DECL_DLLIMPORT_P (decl);
DECL_ATTRIBUTES (to) = targetm.merge_decl_attributes (decl, to);
Index: fortran/trans-decl.c
===
--- fortran/trans-decl.c (revision 193557)
+++ fortran/trans-decl.c (working copy)
@@ -611,12 +611,6 @@ gfc_finish_var_decl (tree decl, gfc_symb
if (sym-attr.threadprivate
(TREE_STATIC (decl) || DECL_EXTERNAL (decl)))
DECL_TLS_MODEL (decl) = decl_default_tls_model (decl);
-
- if (!sym-attr.target
- !sym-attr.pointer
- !sym-attr.cray_pointee
- !sym-attr.proc_pointer)
-DECL_RESTRICTED_P (decl) = 1;
}
Index: tree-streamer-out.c
===
--- tree-streamer-out.c (revision 193557)
+++ tree-streamer-out.c (working copy)
@@ -202,7 +202,6 @@ pack_ts_decl_common_value_fields (struct
if (TREE_CODE (expr) == VAR_DECL
|| TREE_CODE (expr) == PARM_DECL)
bp_pack_value (bp, DECL_HAS_VALUE_EXPR_P (expr), 1);
- bp_pack_value (bp, DECL_RESTRICTED_P (expr), 1);
}
}
Index: tree-streamer-in.c
===
--- tree-streamer-in.c (revision 193557)
+++ tree-streamer-in.c (working copy)
@@ -236,7 +236,6 @@
[PATCH AArch64] Fix faulty commit of testsuite/gcc.target/aarch64/csinc-2.c
A commit I did earlier in the week got truncated somehow, leading
to a broken testcase for AArch64 target.
I've just commited this fix as obvious on trunk and the
arm/aarch64-4.7-branch.
Cheers
Ian
Index: gcc/testsuite/gcc.target/aarch64/csinc-2.c
===
--- gcc/testsuite/gcc.target/aarch64/csinc-2.c (revision 193571)
+++ gcc/testsuite/gcc.target/aarch64/csinc-2.c (revision 193572)
@@ -12,3 +12,7 @@ typedef long long s64;
s64
foo2 (s64 a, s64 b)
+{
+ return (a == b) ? 7 : 1;
+ /* { dg-final { scan-assembler csinc\tx\[0-9\].*xzr } } */
+}
Re: add typedef printers to libstdc++
Tom == Tom Tromey tro...@redhat.com writes:
Jonathan Please go ahead and commit, thanks, Tom!
Tom Thanks. The needed gdb patches are still pending, so I plan to wait
Tom until those go in before committing to libstdc++. I hope it will be
Tom next week sometime.
Hahaha, next week. The patches went in this week.
I rebased and re-tested my libstdc++ patch. While testing it with an
older gdb, I noticed a Tcl error from the test suite, so here is a new
version that correctly reports unsupported for the new tests.
The change from the last version is this addition in proc gdb-test:
+ } else {
+ unsupported $testname
+ close $fd
+ return
+ }
Ok?
Tom
b/libstdc++-v3/ChangeLog:
2012-11-16 Tom Tromey tro...@redhat.com
* testsuite/libstdc++-prettyprinters/whatis.cc: New file.
* testsuite/lib/gdb-test.exp (whatis-test): New proc.
(gdb-test): Handle 'whatis' tests.
(gdb_batch_check): New proc.
(gdb_version_check): Rewrite to use gdb_batch_check.
* python/libstdcxx/v6/printers.py: Import gdb.types.
(FilteringTypePrinter): New class.
(add_one_type_printer, register_type_printers): New functions.
(register_libstdcxx_printers): Call register_type_printers.
diff --git a/libstdc++-v3/python/libstdcxx/v6/printers.py
b/libstdc++-v3/python/libstdcxx/v6/printers.py
index 5197284..294ec4c 100644
--- a/libstdc++-v3/python/libstdcxx/v6/printers.py
+++ b/libstdc++-v3/python/libstdcxx/v6/printers.py
@@ -26,6 +26,15 @@ try:
except ImportError:
_use_gdb_pp = False
+# Try to install type-printers.
+_use_type_printing = False
+try:
+import gdb.types
+if hasattr(gdb.types, 'TypePrinter'):
+_use_type_printing = True
+except ImportError:
+pass
+
# Starting with the type ORIG, search for the member type NAME. This
# handles searching upward through superclasses. This is needed to
# work around http://sourceware.org/bugzilla/show_bug.cgi?id=13615.
@@ -801,6 +810,97 @@ class Printer(object):
libstdcxx_printer = None
+class FilteringTypePrinter(object):
+def __init__(self, match, name):
+self.match = match
+self.name = name
+self.enabled = True
+
+class _recognizer(object):
+def __init__(self, match, name):
+self.match = match
+self.name = name
+self.type_obj = None
+
+def recognize(self, type_obj):
+if type_obj.tag is None:
+return None
+
+if self.type_obj is None:
+if not self.match in type_obj.tag:
+# Filter didn't match.
+return None
+try:
+self.type_obj = gdb.lookup_type(self.name).strip_typedefs()
+except:
+pass
+if self.type_obj == type_obj:
+return self.name
+return None
+
+def instantiate(self):
+return self._recognizer(self.match, self.name)
+
+def add_one_type_printer(obj, match, name):
+printer = FilteringTypePrinter(match, 'std::' + name)
+gdb.types.register_type_printer(obj, printer)
+
+def register_type_printers(obj):
+global _use_type_printing
+
+if not _use_type_printing:
+return
+
+for pfx in ('', 'w'):
+add_one_type_printer(obj, 'basic_string', pfx + 'string')
+add_one_type_printer(obj, 'basic_ios', pfx + 'ios')
+add_one_type_printer(obj, 'basic_streambuf', pfx + 'streambuf')
+add_one_type_printer(obj, 'basic_istream', pfx + 'istream')
+add_one_type_printer(obj, 'basic_ostream', pfx + 'ostream')
+add_one_type_printer(obj, 'basic_iostream', pfx + 'iostream')
+add_one_type_printer(obj, 'basic_stringbuf', pfx + 'stringbuf')
+add_one_type_printer(obj, 'basic_istringstream',
+ pfx + 'istringstream')
+add_one_type_printer(obj, 'basic_ostringstream',
+ pfx + 'ostringstream')
+add_one_type_printer(obj, 'basic_stringstream',
+ pfx + 'stringstream')
+add_one_type_printer(obj, 'basic_filebuf', pfx + 'filebuf')
+add_one_type_printer(obj, 'basic_ifstream', pfx + 'ifstream')
+add_one_type_printer(obj, 'basic_ofstream', pfx + 'ofstream')
+add_one_type_printer(obj, 'basic_fstream', pfx + 'fstream')
+add_one_type_printer(obj, 'basic_regex', pfx + 'regex')
+add_one_type_printer(obj, 'sub_match', pfx + 'csub_match')
+add_one_type_printer(obj, 'sub_match', pfx + 'ssub_match')
+add_one_type_printer(obj, 'match_results', pfx + 'cmatch')
+add_one_type_printer(obj, 'match_results', pfx + 'smatch')
+add_one_type_printer(obj, 'regex_iterator', pfx + 'cregex_iterator')
+add_one_type_printer(obj, 'regex_iterator', pfx + 'sregex_iterator')
+add_one_type_printer(obj,
Re: [patch] update zlib to 1.2.7
On 11/16/2012 05:34 PM, Matthias Klose wrote: this is an update of zlib from 1.2.5 to 1.2.7, the compressed changes are attached. No merge glitches. Ok for the trunk? Fine by me, because I guess we should keep up with supported zlib, as long as it all still works. Andrew.
[Patch, Fortran, committed] PR 55297: [4.8 Regression] [OOP] type-bound operator clashes with abstract interface
Hi all, I have just committed an obvious patch for a recent OOP regression: http://gcc.gnu.org/viewcvs?root=gccview=revrev=193568 Thanks to Damian for reporting ... Cheers, Janus
Re: add typedef printers to libstdc++
On 16 November 2012 18:05, Tom Tromey wrote:
Tom == Tom Tromey tro...@redhat.com writes:
Jonathan Please go ahead and commit, thanks, Tom!
Tom Thanks. The needed gdb patches are still pending, so I plan to wait
Tom until those go in before committing to libstdc++. I hope it will be
Tom next week sometime.
Hahaha, next week. The patches went in this week.
I rebased and re-tested my libstdc++ patch. While testing it with an
older gdb, I noticed a Tcl error from the test suite, so here is a new
version that correctly reports unsupported for the new tests.
The change from the last version is this addition in proc gdb-test:
+ } else {
+ unsupported $testname
+ close $fd
+ return
+ }
Ok?
Yes, thanks
Re: [PATCH, generic] New RTL primitive: `define_subst'
On 11/16/2012 03:21 AM, Michael Zolotukhin wrote: Maybe we should introduce a new gen-utility which should be used only for dumping md-files and add a new target into makefile to invoke it, This is exactly what I suggested somewhere up-thread. r~
Re: [patch] Fix PR middle-end/55321
On 11/15/2012 03:08 PM, Eric Botcazou wrote: For a naked call to memcpy? I don't think so, this is a call so there will be an abnormal edge at the Tree level. The problem arises only when the abnormal edge is created during RTL expansion. Well, there's a call at the tree level for __sync_synchronize as well. So the question is: why does __s_s ICE but memcmp doesn't? I suppose it's the mere rarity with which HAVE_cmpmemsi is defined, and expansion of gen_cmpmemsi fails. There are plenty of other calls to emit_library_call_value that are not subsequently protected by emit_libcall_block_1, but they are probably sufficiently rare on common platforms that they'd be difficult to trigger. r~
Re: VEC re-write [patch 09/25]
On Fri, Nov 16, 2012 at 11:32 AM, Tom Tromey tro...@redhat.com wrote: Diego= build_utf8_ref (unmangle_classname (IDENTIFIER_POINTER (sig), Diego -IDENTIFIER_LENGTH (sig))); Diego -e = VEC_index (constructor_elt, v, idx--); Diego +IDENTIFIER_LENGTH (sig))); Diego +e = (*v)[idx--]; Looks like a spurious reindentation of the IDENTIFIER_LENGTH line. Thanks. Fixed. Diego.
[PATCH AArch64] Implement bswaphi2 with rev16
This patch implements the standard pattern bswaphi2 for AArch64.
Regression tests all pass.
OK for trunk and backport to arm/aarch64-4.7-branch?
Cheers,
Ian
2012-11-16 Ian Bolton ian.bol...@arm.com
* gcc/config/aarch64/aarch64.md (bswaphi2): New pattern.
* gcc/testsuite/gcc.target/aarch64/builtin-bswap-1.c: New test.
* gcc/testsuite/gcc.target/aarch64/builtin-bswap-2.c: New test.
-
diff --git a/gcc/config/aarch64/aarch64.md b/gcc/config/aarch64/aarch64.md
index e6086a9..22c7103 100644
--- a/gcc/config/aarch64/aarch64.md
+++ b/gcc/config/aarch64/aarch64.md
@@ -2340,6 +2340,15 @@
(set_attr mode MODE)]
)
+(define_insn bswaphi2
+ [(set (match_operand:HI 0 register_operand =r)
+(bswap:HI (match_operand:HI 1 register_operand r)))]
+
+ rev16\\t%w0, %w1
+ [(set_attr v8type rev)
+ (set_attr mode HI)]
+)
+
;; ---
;; Floating-point intrinsics
;; ---
diff --git a/gcc/testsuite/gcc.target/aarch64/builtin-bswap-1.c
b/gcc/testsuite/gcc.target/aarch64/builtin-bswap-1.c
new file mode 100644
index 000..a6706e6
--- /dev/null
+++ b/gcc/testsuite/gcc.target/aarch64/builtin-bswap-1.c
@@ -0,0 +1,18 @@
+/* { dg-do compile } */
+/* { dg-options -O2 } */
+
+/* { dg-final { scan-assembler-times rev16\\t 2 } } */
+
+/* rev16 */
+short
+swaps16 (short x)
+{
+ return __builtin_bswap16 (x);
+}
+
+/* rev16 */
+unsigned short
+swapu16 (unsigned short x)
+{
+ return __builtin_bswap16 (x);
+}
diff --git a/gcc/testsuite/gcc.target/aarch64/builtin-bswap-2.c
b/gcc/testsuite/gcc.target/aarch64/builtin-bswap-2.c
new file mode 100644
index 000..6018b48
--- /dev/null
+++ b/gcc/testsuite/gcc.target/aarch64/builtin-bswap-2.c
@@ -0,0 +1,18 @@
+/* { dg-do compile } */
+/* { dg-options -O2 } */
+
+/* { dg-final { scan-assembler-times rev16\\t 2 } } */
+
+/* rev16 */
+unsigned short
+swapu16_1 (unsigned short x)
+{
+ return (x 8) | (x 8);
+}
+
+/* rev16 */
+unsigned short
+swapu16_2 (unsigned short x)
+{
+ return (x 8) | (x 8);
+}
Re: [PATCH] Fix part of PR bootstrap/55051 (issue6846063)
This patch addresses the bogus Invocation mismatch messages seen in parallel
profiledbootstrap builds of gcc. See PR bootstrap/55051 for a discussion of
why this is occurring and why this checking is inaccurate.
Profilebootstrapped and tested on x86_64-unknown-linux-gnu. Ok for trunk?
2012-11-15 Teresa Johnson tejohn...@google.com
PR bootstrap/55051
* libgcov.c (gcov_exit): Remove checking against first
merged summary for program, as multiple simultaneous
processes attempting to update gcda files may cause
summaries to temporarily differ.
Index: libgcov.c
===
--- libgcov.c (revision 193522)
+++ libgcov.c (working copy)
@@ -365,7 +365,6 @@ gcov_exit (void)
struct gcov_info *gi_ptr;
const struct gcov_fn_info *gfi_ptr;
struct gcov_summary this_prg; /* summary for program. */
- struct gcov_summary all_prg; /* summary for all instances of program. */
struct gcov_ctr_summary *cs_ptr;
const struct gcov_ctr_info *ci_ptr;
unsigned t_ix;
@@ -382,7 +381,6 @@ gcov_exit (void)
if (gcov_dump_complete)
return;
- memset (all_prg, 0, sizeof (all_prg));
/* Find the totals for this execution. */
memset (this_prg, 0, sizeof (this_prg));
for (gi_ptr = gcov_list; gi_ptr; gi_ptr = gi_ptr-next)
@@ -469,7 +467,7 @@ gcov_exit (void)
unsigned n_counts;
struct gcov_summary prg; /* summary for this object over all
program. */
- struct gcov_ctr_summary *cs_prg, *cs_tprg, *cs_all;
+ struct gcov_ctr_summary *cs_prg, *cs_tprg;
int error = 0;
gcov_unsigned_t tag, length;
gcov_position_t summary_pos = 0;
@@ -684,7 +682,6 @@ gcov_exit (void)
{
cs_prg = prg.ctrs[t_ix];
cs_tprg = this_prg.ctrs[t_ix];
- cs_all = all_prg.ctrs[t_ix];
if (gi_ptr-merge[t_ix])
{
@@ -702,24 +699,6 @@ gcov_exit (void)
}
else if (cs_prg-runs)
goto read_mismatch;
-
- if (!cs_all-runs cs_prg-runs)
- memcpy (cs_all, cs_prg, sizeof (*cs_all));
- else if (!all_prg.checksum
- (!GCOV_LOCKED || cs_all-runs == cs_prg-runs)
- /* Don't compare the histograms, which may have slight
- variations depending on the order they were updated
- due to the truncating integer divides used in the
- merge. */
-memcmp (cs_all, cs_prg,
- sizeof (*cs_all) - (sizeof (gcov_bucket_type)
- * GCOV_HISTOGRAM_SIZE)))
Please keep the massage around with !GCOV_LOCKED. In that case user should be
informed that parallel exeuction is bad idea (tm).
The memcpy/memcmp pair with sizeof (gcov_bucket_type) adjustment is ugly. Just
copy those few relevant values into temporary vars.
OK with this change.
Honza
Re: [PATCH] Fix dom ICE (PR tree-optimization/55329)
On 11/15/2012 01:14 PM, Jakub Jelinek wrote: Hi! On the following testcase we ICE, because tree_ssa_dominator_optimize modifies the bitmap while iterating it. In particular, it contained just a single bit in it, bitmap_clear_bit turned the bitmap into empty bitmap and bitmap_set_bit on a lower bit reused the same bitmap_element with lower index, but higher bit set in it, therefore EXECUTE_IF_SET_IN_BITMAP in next iteration gave bit above highest basic block. Fixed by never clearing any bits from the bitmap while traversing it, it isn't IMHO a big deal, gimple_purge_all_dead_eh_edges will in a few insns find out the forwarder block doesn't have any EDGE_EH edges and will do nothing for it, on the other side to handle even chained forwarder blocks it loops to find the last one. Insertion of bits looks safe to me, we don't care if those inserted bits are processed again or not (nothing will be done for them anymore). Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? 2012-11-15 Jakub Jelinek ja...@redhat.com PR tree-optimization/55329 * tree-ssa-dom.c (tree_ssa_dominator_optimize): Never clear bits in needed_eh_cleanup while iterating over the bitmap. Look through all forwarder blocks at once. * g++.dg/opt/pr55329.C: New test. This is fine. I've still got a todo on my list from 2009 to have checking code to detect when a bitmap is changing while we're iterating on it. jeff
Re: [PATCH] Function Multiversioning Bug, checking for function versions
Hi,
The previous patch was incomplete because the front-end strips off
invalid target attributes which I did not consider. The attached
updated patch handles this with updated test cases.
Thanks,
-Sri.
On Thu, Nov 15, 2012 at 2:08 PM, Sriraman Tallam tmsri...@google.com wrote:
Hi,
Currently, function multiversioning determines that two functions
are different by comparing the arch type and isa flags that are set
after the target string is processed. This leads to cases where the
versions become identical when the command-line target options are
altered.
For example, these two versions:
__attribute__ target ((sse4.2)))
int foo ()
{
}
__attribute__ target ((popcnt)))
int foo ()
{
}
become identical when -mpopcnt and -msse4.2 are used while building,
leading to build errors.
To avoid this, I have modified the function version determination to
just compare the target string.
Patch attached. Is this alright to submit?
Thanks,
-Sri.
* doc/tm.texi.in (TARGET_OPTION_SUPPORTS_FUNCTION_VERSIONS): Document
new target hook.
* doc/tm.texi: Regenerate.
* c-family/c-common.c (handle_target_attribute): Retain target attribute
for targets that support versioning.
* target.def (supports_function_versions): New hook.
* config/i386/i386.c (ix86_function_versions): Use target string
to check for function versions instead of target flags.
* testsuite/g++.dg/mv1.C: Remove target options.
* testsuite/g++.dg/mv2.C: Ditto.
* testsuite/g++.dg/mv3.C: Ditto.
* testsuite/g++.dg/mv4.C: Ditto.
* testsuite/g++.dg/mv5.C: Ditto.
* cp/class.c (add_method): Remove calls
to DECL_FUNCTION_SPECIFIC_TARGET.
* config/i386/i386.c (ix86_function_versions): Use target string
to check for function versions instead of target flags.
* (ix86_supports_function_versions): New function.
* (is_function_default_version): Check target string.
* TARGET_OPTION_SUPPORTS_FUNCTION_VERSIONS: New macro.
Index: doc/tm.texi
===
--- doc/tm.texi (revision 193485)
+++ doc/tm.texi (working copy)
@@ -9937,6 +9937,11 @@ different target specific attributes, that is, the
different target machines.
@end deftypefn
+@deftypefn {Target Hook} bool TARGET_OPTION_SUPPORTS_FUNCTION_VERSIONS (void)
+This target hook returns @code{true} if the target supports function
+multiversioning.
+@end deftypefn
+
@deftypefn {Target Hook} bool TARGET_CAN_INLINE_P (tree @var{caller}, tree
@var{callee})
This target hook returns @code{false} if the @var{caller} function
cannot inline @var{callee}, based on target specific information. By
Index: doc/tm.texi.in
===
--- doc/tm.texi.in (revision 193485)
+++ doc/tm.texi.in (working copy)
@@ -9798,6 +9798,11 @@ different target specific attributes, that is, the
different target machines.
@end deftypefn
+@hook TARGET_OPTION_SUPPORTS_FUNCTION_VERSIONS
+This target hook returns @code{true} if the target supports function
+multiversioning.
+@end deftypefn
+
@hook TARGET_CAN_INLINE_P
This target hook returns @code{false} if the @var{caller} function
cannot inline @var{callee}, based on target specific information. By
Index: c-family/c-common.c
===
--- c-family/c-common.c (revision 193485)
+++ c-family/c-common.c (working copy)
@@ -8720,8 +8720,12 @@ handle_target_attribute (tree *node, tree name, tr
warning (OPT_Wattributes, %qE attribute ignored, name);
*no_add_attrs = true;
}
+ /* Do not strip invalid target attributes for targets which support function
+ multiversioning as the target string is used to determine versioned
+ functions. */
else if (! targetm.target_option.valid_attribute_p (*node, name, args,
- flags))
+ flags)
+ ! targetm.target_option.supports_function_versions ())
*no_add_attrs = true;
return NULL_TREE;
Index: target.def
===
--- target.def (revision 193485)
+++ target.def (working copy)
@@ -2826,6 +2826,14 @@ DEFHOOK
bool, (tree decl1, tree decl2),
hook_bool_tree_tree_false)
+/* This function returns true if the target supports function
+ multiversioning. */
+DEFHOOK
+(supports_function_versions,
+ ,
+ bool, (void),
+ hool_bool_void_false)
+
/* Function to determine if one function can inline another function. */
#undef HOOK_PREFIX
#define HOOK_PREFIX TARGET_
Index: testsuite/g++.dg/mv2.C
===
--- testsuite/g++.dg/mv2.C (revision 193485)
+++ testsuite/g++.dg/mv2.C (working copy)
@@ -2,7 +2,7 @@
dispatching order
[patch] instrument clones
The included small change to g++.dg/tm/pr51516.C fixes the remaining TM
regression. With two code paths, there are two instances of the
constructor (a clone and an uninstrumented version), so that part of the
test is no longer relevant.
However... in fixing this, I noticed that for some odd reason we are not
instrumenting clones at all. I have no idea, how we missed this, but if
you look at the (currently) generated code for:
__attribute__((transaction_callable))
void cloneme()
{
foo = 666;
}
...you will notice that the clone version has no instrumentation.
This is because the iteration with get_bb_regions_uninstrumented() exits
if there are no exit_blocks, which is always the case for TM clones. I
added a new parameter so we can force traversal of the clone if we are
looking at a clone.
But then this is problematic if the clone has inline assembly because
collect_bb2reg() does not stop at irrevocable blocks. So if we
indiscriminately scan clones, we plow right through irrevocable blocks
and try to incorrectly instrument them. Fixed with yet another parameter.
With this patch we have no TM regressions whatsoever, and as a bonus we
are instrumenting clones :-).
OK?
commit 92723b5bb9d6791b1f3466e5106db13f143da2ca
Author: Aldy Hernandez al...@redhat.com
Date: Fri Nov 16 15:12:47 2012 -0600
* trans-mem (collect_bb2reg): Stop scanning at irrevocable
* blocks.
(get_bb_regions_instrumented): Add new traverse_clone argument and
use it.
(expand_regions_1): Same.
(expand_region): Same.
(execute_tm_mark): Pass new argument to expand_regions.
(expand_block_edges): Pass new argument to
get_bb_regions_instrumented.
testsuite/
* g++.dg/tm/pr51516.C: Adjust for uninstrumented code path.
* gcc.dg/tm/clone-1.c: New test.
diff --git a/gcc/testsuite/g++.dg/tm/pr51516.C
b/gcc/testsuite/g++.dg/tm/pr51516.C
index c13ae47..4e91006 100644
--- a/gcc/testsuite/g++.dg/tm/pr51516.C
+++ b/gcc/testsuite/g++.dg/tm/pr51516.C
@@ -18,5 +18,4 @@ int main()
}
/* { dg-final { scan-assembler-not _ITM_getTMCloneOrIrrevocable } } */
-/* { dg-final { scan-tree-dump-times ;; Function C::C 1 optimized } } */
/* { dg-final { cleanup-tree-dump optimized } } */
diff --git a/gcc/testsuite/gcc.dg/tm/clone-1.c
b/gcc/testsuite/gcc.dg/tm/clone-1.c
new file mode 100644
index 000..4050add
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/tm/clone-1.c
@@ -0,0 +1,13 @@
+/* { dg-do compile } */
+/* { dg-options -fgnu-tm -fdump-tree-tmmark } */
+
+int foo;
+
+__attribute__((transaction_callable))
+void cloneme()
+{
+ foo = 666;
+}
+
+/* { dg-final { scan-tree-dump-times ITM_WU.*foo 1 tmmark } } */
+/* { dg-final { cleanup-tree-dump tmmark } } */
diff --git a/gcc/trans-mem.c b/gcc/trans-mem.c
index a7b4a9c..14d0ca9 100644
--- a/gcc/trans-mem.c
+++ b/gcc/trans-mem.c
@@ -138,7 +138,7 @@
static void *expand_regions (struct tm_region *,
void *(*callback)(struct tm_region *, void *),
-void *);
+void *, bool);
/* Return the attributes we want to examine for X, or NULL if it's not
@@ -2457,7 +2457,7 @@ collect_bb2reg (struct tm_region *region, void *data)
region-exit_blocks,
region-irr_blocks,
NULL,
- /*stop_at_irr_p=*/false);
+ /*stop_at_irr_p=*/true);
// We expect expand_region to perform a post-order traversal of the region
// tree. Therefore the last region seen for any bb is the innermost.
@@ -2491,14 +2491,14 @@ collect_bb2reg (struct tm_region *region, void *data)
// only known instance of this block sharing.
static VEC(tm_region_p, heap) *
-get_bb_regions_instrumented (void)
+get_bb_regions_instrumented (bool traverse_clones)
{
unsigned n = last_basic_block;
VEC(tm_region_p, heap) *ret;
ret = VEC_alloc (tm_region_p, heap, n);
VEC_safe_grow_cleared (tm_region_p, heap, ret, n);
- expand_regions (all_tm_regions, collect_bb2reg, ret);
+ expand_regions (all_tm_regions, collect_bb2reg, ret, traverse_clones);
return ret;
}
@@ -2826,11 +2826,13 @@ execute_tm_mark (void)
{
pending_edge_inserts_p = false;
- expand_regions (all_tm_regions, generate_tm_state, NULL);
+ expand_regions (all_tm_regions, generate_tm_state, NULL,
+ /*traverse_clones=*/true);
tm_log_init ();
- VEC(tm_region_p, heap) *bb_regions = get_bb_regions_instrumented ();
+ VEC(tm_region_p, heap) *bb_regions
+= get_bb_regions_instrumented (/*traverse_clones=*/true);
struct tm_region *r;
unsigned i;
@@ -2844,7 +2846,8 @@ execute_tm_mark (void)
propagate_tm_flags_out (all_tm_regions);
// Expand GIMPLE_TRANSACTIONs into calls into the runtime.
- expand_regions (all_tm_regions, expand_transaction, NULL);
+ expand_regions (all_tm_regions,
Re: [Bug libstdc++/54075] [4.7.1] unordered_map insert still slower than 4.6.2
Attached patch applied. 2012-11-16 François Dumont fdum...@gcc.gnu.org * include/bits/hashtable_policy.h (_Prime_rehash_policy): Remove automatic shrink. (_Prime_rehash_policy::_M_bkt_for_elements): Do not call _M_next_bkt anymore. (_Prime_rehash_policy::_M_next_bkt): Move usage of _S_growth_factor ... (_Prime_rehash_policy::_M_need_rehash): ... here. * include/bits/hashtable.h (_Hashtable): Adapt. * testsuite/performance/23_containers/insert_erase/41975.cc: Add _USE_TR1 to force build using std::tr1 container. * testsuite/performance/23_containers/insert/unordered_set.cc: Likewise. * testsuite/performance/23_containers/insert/54075.cc: New. Note that I have used std::random_device in 54075 test. I also preferred to test both std and std::tr1 containers in a single run without relying on a macro check. As long as we try to align std containers performance on tr1 ones it is better maybe later we could limit it to test only std:: container per default. I have also added several use cases and here is the result: 54075.cc std::tr1::unordered_set without hash code cached 30 Foo insertions 10r9u1s 13765616mem0pf 54075.cc std::tr1::unordered_set without hash code cached 10 times insertion of 30 Foo 21r 21u 0s0mem 0pf 54075.cc std::tr1::unordered_set with hash code cached 30 Foo insertions 15r 14u0s 18561984mem0pf 54075.cc std::tr1::unordered_set with hash code cached 10 times insertion of 30 Foo 23r 23u 0s0mem 0pf 54075.cc std::tr1::unordered_multiset without hash code cached 30 Foo insertions 9r8u1s 13761968mem0pf 54075.cc std::tr1::unordered_multiset without hash code cached 10 times insertion of 30 Foo 113r 107u7s 126686848mem0pf 54075.cc std::tr1::unordered_multiset with hash code cached 30 Foo insertions 100r 100u0s 18561984mem0pf 54075.cc std::tr1::unordered_multiset with hash code cached 10 times insertion of 30 Foo 111r 107u4s 174686864mem0pf 54075.cc std::unordered_set without hash code cached 30 Foo insertions 9r8u1s 13761936mem 0pf 54075.cc std::unordered_set without hash code cached 10 times insertion of 30 Foo 34r 34u 0s0mem0pf 54075.cc std::unordered_set with hash code cached 30 Foo insertions 10r 10u1s 18562000mem 0pf 54075.cc std::unordered_set with hash code cached 10 times insertion of 30 Foo 37r 37u 0s0mem0pf 54075.cc std::unordered_multiset without hash code cached 30 Foo insertions 8r9u0s 13761936mem0pf 54075.cc std::unordered_multiset without hash code cached 10 times insertion of 30 Foo 34r 34u 0s0mem 0pf 54075.cc std::unordered_multiset with hash code cached 30 Foo insertions 10r 10u0s 18562000mem0pf 54075.cc std::unordered_multiset with hash code cached 10 times insertion of 30 Foo 37r 37u 0s0mem 0pf There is one surprising result; std::tr1::unordered_multiset is quite bad, I haven't check yet why and it is not my priority, I take it as a good news for the moment. The other important result is this one: 54075.cc std::tr1::unordered_set without hash code cached 10 times insertion of 30 Foo 21r 21u 0s0mem0pf 54075.cc std::unordered_set without hash code cached 10 times insertion of 30 Foo 34r 34u 0s0mem0pf We can see that inserting the same elements again, that is to say detecting the collisions, is slower in the new implementation. It is the problem I had already signaled in bugzilla entry. In the new implementation when we need to look for bucket elements we have to check the hash code of each element to see if we are still in the same bucket, in the former there was a nullptr to signal the end of the bucket. I think I am going to try to add an empty node to mark the end of the bucket. It will introduce a memory tradeoff of one empty node for each non-empty bucket but it will also limit the impact of caching the hash code or node because we won't need to use it so often. François On 11/14/2012 11:54 AM, Paolo Carlini wrote: Hi, On 11/13/2012 10:40 PM, François Dumont wrote: 2012-11-13 François Dumont fdum...@gcc.gnu.org * include/bits/hashtable_policy.h (_Prime_rehash_policy): Remove automatic shrink. (_Prime_rehash_policy::_M_bkt_for_elements): Do not call _M_next_bkt anymore. (_Prime_rehash_policy::_M_next_bkt): Move usage of
Re: [Bug libstdc++/54075] [4.7.1] unordered_map insert still slower than 4.6.2
Hi, On 11/16/2012 10:58 PM, François Dumont wrote: We can see that inserting the same elements again, that is to say detecting the collisions, is slower in the new implementation. It is the problem I had already signaled in bugzilla entry. In the new implementation when we need to look for bucket elements we have to check the hash code of each element to see if we are still in the same bucket, in the former there was a nullptr to signal the end of the bucket. I think I am going to try to add an empty node to mark the end of the bucket. It will introduce a memory tradeoff of one empty node for each non-empty bucket but it will also limit the impact of caching the hash code or node because we won't need to use it so often. Ok, seems and idea worth trying. There is something I don't understand in the extended batch of insert performance tests: for the std:: containers I see much much less difference between the cached and non cached cases, compared to the old batch. How so? Is the insert performance impact of caching serious or not, I'm a bit confused now... Paolo.
Re: [PATCH] PR c++/53609 - Wrong argument deduction for pack expansion in argument pack
It seems like your new code is a generalization of the old code for
handling substitution of a pack for itself (arg_from_parm_pack and such)
and the code for handling other packs with a single pack expansion
argument, and should replace those rather than adding on.
The solution that if at a certain index all the packs have expansion
arguments then the substitution produces a pack expansion seems right to
me, but if one pack has an expansion and another pack has a normal
argument, we can't do the substitution and need to fall back on the
PACK_EXPANSION_EXTRA_ARGS mechanism.
+set_arg_pack_select_index_for_pack_expansion (tree aps,
+ int i,
+ tree arg_pack)
+{
+ if (any_non_real_argument_pack_element_p (arg_pack))
I don't think we care if *any* element is an expansion (and please talk
about expansions rather than non-real elements). What we care about
is whether the i'th element is an expansion. And we need to compare all
the pack elements, so I think this needs to be handled in the main
function rather than encapsulated here.
+ TREE_VEC_ELT (args_vec, i) =
+ TREE_VEC_ELT (ARGUMENT_PACK_ARGS (arg_pack), i);
Aren't the LHS and RHS the same location here?
Jason
[PATCH, RFC] Enable libsanitizer on powerpc{,64}
Attached below is an initial port of ASAN to powerpc*-linux.
With the patch below along with Jakub's ASAN testsuite patch:
http://gcc.gnu.org/ml/gcc-patches/2012-11/msg01365.html
ASAN not only builds, but seems to be working. The lone ASAN
test case does fail, but it seems to be related to us using
_Unwind_Backtrace() and we end up with two extra frames at the
bottom of our stack frame, so we don't match the expected
results.
==47550== ERROR: AddressSanitizer stack-buffer-overflow on address
0x0fffe65540a4 at pc 0xfff769d0d70 bp 0xfffe6553ed0 sp 0xfffe6553fe8
READ of size 1 at 0x0fffe65540a4 thread T0
#0 0xfff769dc388 in
_ZN6__asan13GetStackTraceEPN11__sanitizer10StackTraceEmmm
/home/bergner/gcc/gcc-fsf-mainline-asan/libsanitizer/asan/asan_linux.cc:160
#1 0xfff769df4f0 in __asan_report_error
/home/bergner/gcc/gcc-fsf-mainline-asan/libsanitizer/asan/asan_report.cc:471
(discriminator 5)
#2 0xfff769d0dbc in __interceptor_memcmp
/home/bergner/gcc/gcc-fsf-mainline-asan/libsanitizer/asan/asan_interceptors.cc:218
(discriminator 1)
#3 0x1b4c in main
/home/bergner/gcc/gcc-fsf-mainline-asan/gcc/testsuite/c-c++-common/asan/memcmp-1.c:12
...which doesn't match:
/* { dg-output #0 0x\[0-9a-f\]+ (in _*(interceptor_|)memcmp
|\[(\])\[^\n\r]*(\n|\r\n|\r) } */
/* { dg-output #1 0x\[0-9a-f\]+ (in _*main|\[(\])\[^\n\r]*(\n|\r\n|\r) }
*/
because the frame numbers are off. Any ideas on how to fix that?
We cannot use the FastUnwindStack, since that uses exclusively the
frame pointer which ppc almost never uses. We also can have stack
frames above or below the stack pointer, depending on whether the
function is a leaf or not. And with shrink wrapping, can we even
be sure if the frame pointer is even setup even on those systems
that do use the frame pointer? I've seen others say we should
use libbacktrace, and I think I have to agree with them for the
reasons above.
One question that I have is that the toplev.c test for port support
tests for !FRAME_GROWS_DOWNWARD. The rs6000 port has FRAME_GROWS_DOWNWARD
defined as (flag_stack_protect != 0), so ASAN only works when we use
-fstack-protector. Is there a technical reason why FRAME_GROWS_DOWNWARD
must be false?
I should also note, the code setting the page size is very fragile.
On PPC/PPC64 kernels, you can configure the kernel to use different
page sizes. My systems are running 64K page sizes, but could just
as easily be 4K or some other number. Shouldn't we be calling
getpagesize() or sysconf() to query the page size and then computing
the other values from that?
I also don't like all the #ifdef's sprinkling the code. Can't we
use some configure fragments to help remove many/most of these?
Does anyone have any thoughts on the patch? Does it look reasonable?
Peter
gcc/
* config/rs6000/rs6000.c (TARGET_ASAN_SHADOW_OFFSET): Define.
(rs6000_asan_shadow_offset): New function.
libsanitizer/
* configure.tgt: Enable build on powerpc and powerpc64 linux.
* sanitizer_common/sanitizer_common.h (kPageSizeBits): Set for powerpc
and powerpc64.
(kPageSize): Likewise.
(kCacheLineSize): Likewise.
(kMmapGranularity): Likewise.
* sanitizer_common/sanitizer_linux.cc (__NR_mmap) Call for powerpc64.
(__NR_fstat): Likewise.
* sanitizer_common/sanitizer_stacktrace.cc (patch_pc): Align to 4 bytes.
* asan/asan_mapping.h (SHADOW_OFFSET): Define for powerpc and powerpc64.
(kHighMemEnd): Set for powerpc and powerpc64.
* asan/asan_linux.cc (GetPcSpBp): Add powerpc and powerpc64 support.
(GetStackTrace): Use _Unwind_Backtrace for powerpc and powerpc64.
Index: libsanitizer/configure.tgt
===
--- libsanitizer/configure.tgt (revision 193575)
+++ libsanitizer/configure.tgt (working copy)
@@ -20,6 +20,8 @@
# Filter out unsupported systems.
case ${target} in
+ powerpc*-*-linux*)
+ ;;
x86_64-*-linux* | i?86-*-linux* | sparc*-*-linux*)
;;
*)
Index: libsanitizer/sanitizer_common/sanitizer_common.h
===
--- libsanitizer/sanitizer_common/sanitizer_common.h(revision 193575)
+++ libsanitizer/sanitizer_common/sanitizer_common.h(working copy)
@@ -21,12 +21,24 @@
// Constants.
const uptr kWordSize = __WORDSIZE / 8;
const uptr kWordSizeInBits = 8 * kWordSize;
+#if defined(__powerpc__) || defined(__powerpc64__)
+// Current PPC64 kernels use 64K pages sizes, but they can be
+// configured with 4K or even other sizes, so we should probably
+// use getpagesize() or sysconf(_SC_PAGESIZE) here rather than
+// hardcoding the values.
+const uptr kPageSizeBits = 16;
+const uptr kPageSize = 1UL kPageSizeBits;
+const uptr kCacheLineSize = 128;
+const uptr kMmapGranularity = kPageSize;
+#elif !defined( _WIN32)
const uptr kPageSizeBits = 12;
const uptr kPageSize = 1UL kPageSizeBits;
const
Re: [tsan] ThreadSanitizer instrumentation part
Hi, Is it ok for the trunk? Thanks, Wei. On Tue, Nov 13, 2012 at 5:06 PM, Wei Mi w...@google.com wrote: Thanks for catching this. I update the patch. Regards, Wei. On Tue, Nov 13, 2012 at 4:54 PM, Richard Henderson r...@redhat.com wrote: On 11/13/2012 04:08 PM, Wei Mi wrote: +extern void tsan_finish_file (void); + +#endif /* TREE_TSAN */ +/* ThreadSanitizer, a data race detector. + Copyright (C) 2011 Free Software Foundation, Inc. + Contributed by Dmitry Vyukov dvyu...@google.com Careful, you've got double applied patches there. r~
Re: VEC re-write [patch 01/25]
On Thu, Nov 15, 2012 at 1:53 PM, Diego Novillo dnovi...@google.com wrote: 2012-11-15 Diego Novillo dnovi...@google.com * vec.c (register_overhead): Convert it into member function of vec_prefix. (release_overhead): Likewise. (calculate_allocation): Likewise. (vec_heap_free): Remove. (vec_gc_o_reserve_1): Remove. (vec_heap_o_reserve_1): Remove. (vec_stack_o_reserve_1): Remove. (vec_stack_o_reserve_exact): Remove. (register_stack_vec): New. (stack_vec_register_index): New. (unregister_stack_vec): New. (vec_assert_fail): Remove. * vec.h: Conditionally include ggc.h. Document conditional hackery. Update top-level documentation. (ALONE_VEC_CHECK_INFO): Remove. (VEC_CHECK_INFO): Remove. (ALONE_VEC_CHECK_DECL): Remove. (VEC_CHECK_DECL): Remove. (ALONE_VEC_CHECK_PASS): Remove. (VEC_CHECK_PASS): Remove. (VEC_ASSERT): Remove. (vec_prefix): Add friends va_gc, va_gc_atomic, va_heap and va_stack. Mark fields alloc_ and num_ as protected. (struct vec_t): Remove. Remove all function members. (struct vl_embed): Declare. (struct vl_ptr): Declare. (free): Remove. (reserve_exact): Remove. (reserve): Remove. (safe_splice): Remove. (safe_push): Remove. (safe_grow): Remove. (safe_grow_cleared): Remove. (safe_insert): Remove. (DEF_VEC_I): Remove. (DEF_VEC_ALLOC_I): Remove. (DEF_VEC_P): Remove. (DEF_VEC_ALLOC_P): Remove. (DEF_VEC_O): Remove. (DEF_VEC_ALLOC_O): Remove. (DEF_VEC_ALLOC_P_STACK): Remove. (DEF_VEC_ALLOC_O_STACK): Remove. (DEF_VEC_ALLOC_I_STACK): Remove. (DEF_VEC_A): Remove. (DEF_VEC_ALLOC_A): Remove. (vec_stack_p_reserve_exact_1): Remove. (vec_stack_o_reserve): Remove. (vec_stack_o_reserve_exact): Remove. (VEC_length): Remove. (VEC_empty): Remove. (VEC_address): Remove. (vec_address): Remove. (VEC_last): Remove. (VEC_index): Remove. (VEC_iterate): Remove. (VEC_embedded_size): Remove. (VEC_embedded_init): Remove. (VEC_free): Remove. (VEC_copy): Remove. (VEC_space): Remove. (VEC_reserve): Remove. (VEC_reserve_exact): Remove. (VEC_splice): Remove. (VEC_safe_splice): Remove. (VEC_quick_push): Remove. (VEC_safe_push): Remove. (VEC_pop): Remove. (VEC_truncate): Remove. (VEC_safe_grow): Remove. (VEC_replace): Remove. (VEC_quick_insert): Remove. (VEC_safe_insert): Remove. (VEC_ordered_remove): Remove. (VEC_unordered_remove): Remove. (VEC_block_remove): Remove. (VEC_lower_bound): Remove. (VEC_alloc): Remove. (VEC_qsort): Remove. (va_heap): Declare. (va_heap::default_layout): New typedef to vl_ptr. (va_heap::reserve): New. (va_heap::release): New. (va_gc): Declare. (va_gc::default_layout): New typedef to vl_embed. (va_gc::reserve): New. (va_gc::release): New. (va_gc_atomic): Declare. Inherit from va_gc. (va_stack): Declare. (va_stack::default_layout): New typedef to vl_ptr. (va_stack::alloc): New. (va_stack::reserve): New. (va_stack::release): New. (register_stack_vec): Declare. (stack_vec_register_index): Declare. (unregister_stack_vec): Declare. (vecT, A = va_heap, L = typename A::default_layout): Declare empty vec template. (vecT, A, vl_embed): Partial specialization for embedded layout. (vecT, A, vl_embed::allocated): New. (vecT, A, vl_embed::length): New. (vecT, A, vl_embed::is_empty): New. (vecT, A, vl_embed::address): New. (vecT, A, vl_embed::operator[]): New. (vecT, A, vl_embed::last New. (vecT, A, vl_embed::space): New. (vecT, A, vl_embed::iterate): New. (vecT, A, vl_embed::iterate): New. (vecT, A, vl_embed::copy): New. (vecT, A, vl_embed::splice): New. (vecT, A, vl_embed::quick_push New. (vecT, A, vl_embed::pop New. (vecT, A, vl_embed::truncate): New. (vecT, A, vl_embed::quick_insert): New. (vecT, A, vl_embed::ordered_remove): New. (vecT, A, vl_embed::unordered_remove): New. (vecT, A, vl_embed::block_remove): New. (vecT, A, vl_embed::qsort): New. (vecT, A, vl_embed::lower_bound): New. (vecT, A, vl_embed::embedded_size): New. (vecT, A, vl_embed::embedded_init): New. (vecT, A, vl_embed::quick_grow): New.
Re: VEC re-write [patch 08/25]
On Thu, Nov 15, 2012 at 1:53 PM, Diego Novillo dnovi...@google.com wrote: 2012-11-15 Diego Novillo dnovi...@google.com Adjust for new vec API (http://gcc.gnu.org/wiki/cxx-conversion/cxx-vec) * go-lang.c: Use new vec API in vec.h. * gofrontend/expressions.cc: Likewise. * gofrontend/gogo-tree.cc: Likewise. * godump.c: Likewise. This is OK. Please don't commit the patches to the two files in gcc/go/gofrontend. Send them to me and I will commit them. Thanks. Ian
Re: VEC re-write [patch 12/25]
On Thu, Nov 15, 2012 at 1:53 PM, Diego Novillo dnovi...@google.com wrote: 2012-11-15 Diego Novillo dnovi...@google.com Adjust for new vec API (http://gcc.gnu.org/wiki/cxx-conversion/cxx-vec) * config/bfin/bfin.c: Use new vec API in vec.h. I think that changes like this count as obvious and do not require separate approval if the rest of the patches are approved. Ian
Re: VEC re-write [patch 12/25]
On 11/16/2012 04:19 PM, Ian Lance Taylor wrote: On Thu, Nov 15, 2012 at 1:53 PM, Diego Novillo dnovi...@google.com wrote: 2012-11-15 Diego Novillo dnovi...@google.com Adjust for new vec API (http://gcc.gnu.org/wiki/cxx-conversion/cxx-vec) * config/bfin/bfin.c: Use new vec API in vec.h. I think that changes like this count as obvious and do not require separate approval if the rest of the patches are approved. Agreed. jeff
Re: VEC re-write [patch 05/25]
On Thu, Nov 15, 2012 at 1:53 PM, Diego Novillo dnovi...@google.com wrote:
2012-11-15 Diego Novillo dnovi...@google.com
Adjust for new vec API
(http://gcc.gnu.org/wiki/cxx-conversion/cxx-vec)
* c-common.c: Use new vec API in vec.h.
* c-common.h: Likewise.
* c-gimplify.c: Likewise.
* c-pragma.c: Likewise.
* c-pretty-print.c: Likewise.
* c-pretty-print.h: Likewise.
* c-semantics.c: Likewise.
* c-decl.c: Likewise.
* c-parser.c: Likewise.
* c-tree.h: Likewise.
* c-typeck.c: Likewise.
{
gcc_assert (decl DECL_P (decl) TREE_STATIC (decl));
- while (!VEC_empty (tree, types_used_by_cur_var_decl))
+ while (types_used_by_cur_var_decl !types_used_by_cur_var_decl-is_empty
())
vec_safe_is_empty?
This is OK.
Thanks.
Ian
Re: [PATCH, RFC] Enable libsanitizer on powerpc{,64}
On Fri, Nov 16, 2012 at 3:08 PM, Peter Bergner berg...@vnet.ibm.com wrote:
Attached below is an initial port of ASAN to powerpc*-linux.
With the patch below along with Jakub's ASAN testsuite patch:
http://gcc.gnu.org/ml/gcc-patches/2012-11/msg01365.html
ASAN not only builds, but seems to be working.
Outstanding!
The lone ASAN
test case does fail, but it seems to be related to us using
_Unwind_Backtrace() and we end up with two extra frames at the
bottom of our stack frame, so we don't match the expected
results.
Maybe just drop those two frames before reporting them?
(if we always have them)
==47550== ERROR: AddressSanitizer stack-buffer-overflow on address
0x0fffe65540a4 at pc 0xfff769d0d70 bp 0xfffe6553ed0 sp 0xfffe6553fe8
READ of size 1 at 0x0fffe65540a4 thread T0
#0 0xfff769dc388 in
_ZN6__asan13GetStackTraceEPN11__sanitizer10StackTraceEmmm
/home/bergner/gcc/gcc-fsf-mainline-asan/libsanitizer/asan/asan_linux.cc:160
#1 0xfff769df4f0 in __asan_report_error
/home/bergner/gcc/gcc-fsf-mainline-asan/libsanitizer/asan/asan_report.cc:471
(discriminator 5)
#2 0xfff769d0dbc in __interceptor_memcmp
/home/bergner/gcc/gcc-fsf-mainline-asan/libsanitizer/asan/asan_interceptors.cc:218
(discriminator 1)
#3 0x1b4c in main
/home/bergner/gcc/gcc-fsf-mainline-asan/gcc/testsuite/c-c++-common/asan/memcmp-1.c:12
...which doesn't match:
/* { dg-output #0 0x\[0-9a-f\]+ (in _*(interceptor_|)memcmp
|\[(\])\[^\n\r]*(\n|\r\n|\r) } */
/* { dg-output #1 0x\[0-9a-f\]+ (in _*main|\[(\])\[^\n\r]*(\n|\r\n|\r)
} */
because the frame numbers are off. Any ideas on how to fix that?
We cannot use the FastUnwindStack, since that uses exclusively the
frame pointer which ppc almost never uses. We also can have stack
frames above or below the stack pointer, depending on whether the
function is a leaf or not. And with shrink wrapping, can we even
be sure if the frame pointer is even setup even on those systems
that do use the frame pointer? I've seen others say we should
use libbacktrace, and I think I have to agree with them for the
reasons above.
FastUnwindStack is clearly x86-only thing.
I'd love to have fast solutions for other architectures, but for now
libbacktrace (or any other library call)
is ok for non-x86.
We just need to make sure that those functions do not call malloc/etc.
One question that I have is that the toplev.c test for port support
tests for !FRAME_GROWS_DOWNWARD. The rs6000 port has FRAME_GROWS_DOWNWARD
defined as (flag_stack_protect != 0), so ASAN only works when we use
-fstack-protector. Is there a technical reason why FRAME_GROWS_DOWNWARD
must be false?
Hopefully some one else can comment here
I should also note, the code setting the page size is very fragile.
On PPC/PPC64 kernels, you can configure the kernel to use different
page sizes. My systems are running 64K page sizes, but could just
as easily be 4K or some other number. Shouldn't we be calling
getpagesize() or sysconf() to query the page size and then computing
the other values from that?
I also don't like all the #ifdef's sprinkling the code. Can't we
use some configure fragments to help remove many/most of these?
We'll probably have to add some config-like headers as we get more platforms.
Not necessarily now.
Does anyone have any thoughts on the patch? Does it look reasonable?
Peter
gcc/
* config/rs6000/rs6000.c (TARGET_ASAN_SHADOW_OFFSET): Define.
(rs6000_asan_shadow_offset): New function.
libsanitizer/
* configure.tgt: Enable build on powerpc and powerpc64 linux.
* sanitizer_common/sanitizer_common.h (kPageSizeBits): Set for powerpc
and powerpc64.
(kPageSize): Likewise.
(kCacheLineSize): Likewise.
(kMmapGranularity): Likewise.
* sanitizer_common/sanitizer_linux.cc (__NR_mmap) Call for powerpc64.
(__NR_fstat): Likewise.
* sanitizer_common/sanitizer_stacktrace.cc (patch_pc): Align to 4
bytes.
* asan/asan_mapping.h (SHADOW_OFFSET): Define for powerpc and
powerpc64.
(kHighMemEnd): Set for powerpc and powerpc64.
* asan/asan_linux.cc (GetPcSpBp): Add powerpc and powerpc64 support.
(GetStackTrace): Use _Unwind_Backtrace for powerpc and powerpc64.
Index: libsanitizer/configure.tgt
===
--- libsanitizer/configure.tgt (revision 193575)
+++ libsanitizer/configure.tgt (working copy)
@@ -20,6 +20,8 @@
# Filter out unsupported systems.
case ${target} in
+ powerpc*-*-linux*)
+ ;;
x86_64-*-linux* | i?86-*-linux* | sparc*-*-linux*)
;;
*)
Index: libsanitizer/sanitizer_common/sanitizer_common.h
===
--- libsanitizer/sanitizer_common/sanitizer_common.h(revision 193575)
+++ libsanitizer/sanitizer_common/sanitizer_common.h(working copy)
@@
libgo patch committed: Fix use of __atomic_compare_exchange_n
Based on advice from Dmitry Vyukov, this patch fixes the use of __atomic_compare_exchange_n in libgo. The Go library assumes a strong compare-exchange operation, and always assumes sequential consistency around the operation. Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu, where, as it happens, this patch makes no different anyhow. Committed to mainline. Ian diff -r db71d396d9e5 libgo/runtime/runtime.h --- a/libgo/runtime/runtime.h Fri Nov 16 08:03:04 2012 -0800 +++ b/libgo/runtime/runtime.h Fri Nov 16 16:43:50 2012 -0800 @@ -518,7 +518,7 @@ void free(void *v); #define runtime_cas(pval, old, new) __sync_bool_compare_and_swap (pval, old, new) #define runtime_casp(pval, old, new) __sync_bool_compare_and_swap (pval, old, new) -#define runtime_cas64(pval, pold, new) __atomic_compare_exchange_n (pval, pold, new, 1, __ATOMIC_SEQ_CST, __ATOMIC_RELAXED) +#define runtime_cas64(pval, pold, new) __atomic_compare_exchange_n (pval, pold, new, 0, __ATOMIC_SEQ_CST, __ATOMIC_SEQ_CST) #define runtime_xadd(p, v) __sync_add_and_fetch (p, v) #define runtime_xadd64(p, v) __sync_add_and_fetch (p, v) #define runtime_xchg(p, v) __atomic_exchange_n (p, v, __ATOMIC_SEQ_CST)
[doc] extend.texi copy-editing, 6/N (various coding standards fixes)
I've committed another installment of my copy-edits to extend.texi. For this
patch, I went through the table at
http://gcc.gnu.org/codingconventions.html#Spelling
and tried to check off everything I haven't already addressed by prior patches
in this series. I also took care of a few of the listed markup issues that I
could easily check for with search-and-replace.
-Sandra
2012-11-16 Sandra Loosemore san...@codesourcery.com
gcc/
* doc/extend.texi: Various copy-edits to comply with GCC coding
standards for spelling, terminology, and markup, including use of
American spelling, correct use of terms like back end and
run time, use correct name for GCC, use @: markup.
Index: gcc/doc/extend.texi
===
--- gcc/doc/extend.texi (revision 193581)
+++ gcc/doc/extend.texi (working copy)
@@ -601,7 +601,7 @@ an inline function. It can be used only
are always inlined, never compiled as a separate function, such
as those using @code{__attribute__ ((__always_inline__))} or
@code{__attribute__ ((__gnu_inline__))} extern inline functions.
-For example following does link or runtime checking of open
+For example following does link- or run-time checking of open
arguments for optimized code:
@smallexample
#ifdef __OPTIMIZE__
@@ -916,7 +916,7 @@ examine and set these two fictitious var
@cindex @code{W} floating point suffix
@cindex @code{Q} floating point suffix
-As an extension, the GNU C compiler supports additional floating
+As an extension, GNU C supports additional floating
types, @code{__float80} and @code{__float128} to support 80-bit
(@code{XFmode}) and 128-bit (@code{TFmode}) floating types.
Support for additional types includes the arithmetic operators:
@@ -1000,7 +1000,7 @@ as library calls.
@cindex @code{DD} integer suffix
@cindex @code{DL} integer suffix
-As an extension, the GNU C compiler supports decimal floating types as
+As an extension, GNU C supports decimal floating types as
defined in the N1312 draft of ISO/IEC WDTR24732. Support for decimal
floating types in GCC will evolve as the draft technical report changes.
Calling conventions for any target might also change. Not all targets
@@ -1106,7 +1106,7 @@ extension for floating-point constants o
@cindex @code{ULK} fixed-suffix
@cindex @code{ULLK} fixed-suffix
-As an extension, the GNU C compiler supports fixed-point types as
+As an extension, GNU C supports fixed-point types as
defined in the N1169 draft of ISO/IEC DTR 18037. Support for fixed-point
types in GCC will evolve as the draft technical report changes.
Calling conventions for any target might also change. Not all targets
@@ -1218,7 +1218,7 @@ Fixed-point types are supported by the D
@section Named Address Spaces
@cindex Named Address Spaces
-As an extension, the GNU C compiler supports named address spaces as
+As an extension, GNU C supports named address spaces as
defined in the N1275 draft of ISO/IEC DTR 18037. Support for named
address spaces in GCC will evolve as the draft technical report
changes. Calling conventions for any target might also change. At
@@ -1345,7 +1345,7 @@ together with attribute @code{progmem}.
@item
Reading across the 64@tie{}KiB section boundary of
the @code{__flash} or @code{__flash@var{N}} address spaces
-shows undefined behaviour. The only address space that
+shows undefined behavior. The only address space that
supports reading across the 64@tie{}KiB flash segment boundaries is
@code{__memx}.
@@ -1463,14 +1463,14 @@ initialized, as if they were flexible ar
cases that were useful, it also allowed initializations in situations
that would corrupt later data. Non-empty initialization of zero-length
arrays is now treated like any case where there are more initializer
-elements than the array holds, in that a suitable warning about excess
-elements in array is given, and the excess elements (all of them, in
+elements than the array holds, in that a suitable warning about ``excess
+elements in array'' is given, and the excess elements (all of them, in
this case) are ignored.
Instead GCC allows static initialization of flexible array members.
This is equivalent to defining a new structure containing the original
structure followed by an array of sufficient size to contain the data.
-I.e.@: in the following, @code{f1} is constructed as if it were declared
+E.g.@: in the following, @code{f1} is constructed as if it were declared
like @code{f2}.
@smallexample
@@ -1693,7 +1693,7 @@ yet been replaced with spaces.
In ISO C99, arrays that are not lvalues still decay to pointers, and
may be subscripted, although they may not be modified or used after
the next sequence point and the unary @samp{} operator may not be
-applied to them. As an extension, GCC allows such arrays to be
+applied to them. As an extension, GNU C allows such arrays to be
subscripted in C90 mode, though otherwise they do not decay
Re: [COMMITTED] Move libsanitizer configure logic to subdirectory
On Tue, 13 Nov 2012, Richard Henderson wrote: As discussed elsewhere. Tested on x86_64-linux. +2012-11-13 Richard Henderson r...@redhat.com + + * configure.ac: Move libsanitizer logic to subdirectory. + * configure: Regenerate. + Thanks and sorry for copypasting the wrong pattern in the first place. +++ b/libsanitizer/configure.tgt @@ -0,0 +1,28 @@ +# -*- shell-script -*- +# Copyright (C) 2012 Free Software Foundation, Inc. + +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation; either version 2 of the License, or +# (at your option) any later version. Heh, version 2... But licensing changes are never obvious, right? brgds, H-P
