Re: [Patch, fortran] PR54107: ICE on recursive interfaces and PR54195: symbol bogusly inserted twice in the interface.
Hi Mikael, The following patches fix both PR54107 and PR54195. good stuff, thank you! - In PR54107(comment 26), the procedure result is a procedure pointer whose interface is the procedure itself, which leads to an infinite recursion during resolution. - In PR54195, a type's type bound procedures are resolved twice, leading to a symbol being added twice in an interface and rejected. What about PR 54107 comment 4? This also still fails, right? You had already posted a patch for this in this PR, which however was quite different from the one you propose here. (I was assuming that the problems of comment 4 and comment 26 were quite similar.) Can your 'resolved' attribute also help to fix comment 4, or are you going to post the other patch later? The fix, as discussed in PR54195, adds a flag to mark a symbol as resolved. Why not add this flag directly to gfc_symbol instead of symbol_attribute? It seems we do not need the attribute for components (or do we?). This leads to two regressions. For class_20, a check to skip result symbols had to be removed (which was there to avoid duplicated resolution). For initialization_27 (among a few others) the code adding the default initialization code was guarded by a check against gfc_current_ns, which always ended triggering when there was more than one resolution but may not anymore. The fix removes it; I checked that gfc_current_ns wasn't used in the following code. Ok, this makes sense. The second fix makes the recursion through resolve_symbol, so that the flag just added triggers and PR54195 is fixed. Regression tested on x86_64-unknown-linux-gnu. OK for trunk? Yes, I think it's basically ok, except for the points mentioned above. Thanks, Janus
[PATCH] Last PR56113 PTA fix
This fixes a minor issue in the previous patch (forgot to add
the equiv class into the hash) and merges lookup and add to
avoid multiple bitmap_hash calls and hashtable lookups for another
minor speedup.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.
Richard.
2013-02-04 Richard Biener rguent...@suse.de
PR tree-optimization/56113
* tree-ssa-structalias.c (equiv_class_lookup, equiv_class_add):
Merge into ...
(equiv_class_lookup_or_add): ... this.
(label_visit): Adjust and fix error in previous patch.
(perform_var_substitution): Adjust.
Index: gcc/tree-ssa-structalias.c
===
*** gcc/tree-ssa-structalias.c (revision 195646)
--- gcc/tree-ssa-structalias.c (working copy)
*** equiv_class_label_eq (const void *p1, co
*** 1908,1961
bitmap_equal_p (eql1-labels, eql2-labels));
}
! /* Lookup a equivalence class in TABLE by the bitmap of LABELS it
!contains. Sets *REF_LABELS to the bitmap LABELS is equivalent to. */
! static unsigned int
! equiv_class_lookup (htab_t table, bitmap labels, bitmap *ref_labels)
{
! void **slot;
! struct equiv_class_label ecl;
ecl.labels = labels;
ecl.hashcode = bitmap_hash (labels);
!
! slot = htab_find_slot_with_hash (table, ecl,
! ecl.hashcode, NO_INSERT);
! if (!slot)
! {
! if (ref_labels)
! *ref_labels = NULL;
! return 0;
! }
! else
{
! equiv_class_label_t ec = (equiv_class_label_t) *slot;
! if (ref_labels)
! *ref_labels = ec-labels;
! return ec-equivalence_class;
}
- }
-
-
- /* Add an equivalence class named EQUIVALENCE_CLASS with labels LABELS
-to TABLE. */
! static void
! equiv_class_add (htab_t table, unsigned int equivalence_class,
!bitmap labels)
! {
! void **slot;
! equiv_class_label_t ecl = XNEW (struct equiv_class_label);
!
! ecl-labels = labels;
! ecl-equivalence_class = equivalence_class;
! ecl-hashcode = bitmap_hash (labels);
!
! slot = htab_find_slot_with_hash (table, ecl,
! ecl-hashcode, INSERT);
! gcc_assert (!*slot);
! *slot = (void *) ecl;
}
/* Perform offline variable substitution.
--- 1908,1936
bitmap_equal_p (eql1-labels, eql2-labels));
}
! /* Lookup a equivalence class in TABLE by the bitmap of LABELS with
!hash HAS it contains. Sets *REF_LABELS to the bitmap LABELS
!is equivalent to. */
! static equiv_class_label *
! equiv_class_lookup_or_add (htab_t table, bitmap labels)
{
! equiv_class_label **slot;
! equiv_class_label ecl;
ecl.labels = labels;
ecl.hashcode = bitmap_hash (labels);
! slot = (equiv_class_label **) htab_find_slot_with_hash (table, ecl,
! ecl.hashcode, INSERT);
! if (!*slot)
{
! *slot = XNEW (struct equiv_class_label);
! (*slot)-labels = labels;
! (*slot)-hashcode = ecl.hashcode;
! (*slot)-equivalence_class = 0;
}
! return *slot;
}
/* Perform offline variable substitution.
*** label_visit (constraint_graph_t graph, s
*** 2150,2155
--- 2125,2134
}
bitmap_set_bit (graph-points_to[n], FIRST_REF_NODE + n);
graph-pointer_label[n] = pointer_equiv_class++;
+ equiv_class_label_t ecl;
+ ecl = equiv_class_lookup_or_add (pointer_equiv_class_table,
+ graph-points_to[n]);
+ ecl-equivalence_class = graph-pointer_label[n];
return;
}
*** label_visit (constraint_graph_t graph, s
*** 2167,2188
if (!bitmap_empty_p (graph-points_to[n]))
{
! bitmap ref_points_to;
! unsigned int label = equiv_class_lookup (pointer_equiv_class_table,
! graph-points_to[n],
! ref_points_to);
! if (!label)
! {
! label = pointer_equiv_class++;
! equiv_class_add (pointer_equiv_class_table,
! label, graph-points_to[n]);
! }
else
{
BITMAP_FREE (graph-points_to[n]);
! graph-points_to[n] = ref_points_to;
}
! graph-pointer_label[n] = label;
}
}
--- 2146,2162
if (!bitmap_empty_p (graph-points_to[n]))
{
! equiv_class_label_t ecl;
! ecl = equiv_class_lookup_or_add (pointer_equiv_class_table,
! graph-points_to[n]);
! if (ecl-equivalence_class == 0)
! ecl-equivalence_class = pointer_equiv_class++;
else
{
BITMAP_FREE (graph-points_to[n]);
! graph-points_to[n] = ecl-labels;
}
! graph-pointer_label[n] = ecl-equivalence_class;
}
}
*** perform_var_substitution
Re: [PATCH] fix PR sanitizer/55617
On Sun, Feb 3, 2013 at 5:57 AM, Jack Howarth howa...@bromo.med.uc.edu wrote:
Currently darwin is unable to utilize libasan with constructors due to the
lack of
constructor priority support on that target. The asan_finish_file routine
inserts an
essential __asan_init into the array of constructors (via the __mod_init_func
section).
However the insertion occurs at the end, and due to the lack of priority
support for
constructors, these are executed from the start of the array of constructors
on program
startup. This causes code any instrumented code that executes before the
__asan_init
call to crash.
Since darwin sets...
#undef SUPPORTS_INIT_PRIORITY
#define SUPPORTS_INIT_PRIORITY 0
in gcc/config/darwin.h, all constructors are automatically set to
#define DEFAULT_INIT_PRIORITY 65535
in gcc/collect2.c. Any code that attempts to set the constructor/destructor
priority
on darwin results in a compile time error of constructor priorities are not
supported.
So asan alone should be unique in emitting priorities different from 65535 on
darwin.
The attached patch uses a va_gc vector of constructor symbol/priority records
to queue
this data as it is generated in calls to machopic_asm_out_constructor. Any
instances of
the static constructor with priority 99 emitted by asan are inserted safely
in the front
of the vector queue which retains the original order of the remaining
constructors in
the queue. The contents of the vector queue are later processed in a new
finalize_ctors
routine called from darwin_file_end if necessary. The patch also adds a
g++.dg/asan/pr55617.C
test case which is targeted to i?86-*-darwin* and x86_64-*-darwin*.
The patch reduces the failures observed when running
make -k check-g++ RUNTESTFLAGS=--target_board=unix'{-fsanitize=address}'
from 323 to only 85 on darwin (similar to the results on linux). The cov.C
testcase also
fails on gcc trunk with -fsanitize=address when recrafted into a dynamic
shared library
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55617#c28. This patch eliminates
those
crashes. This problem doesn't extend to when the shared library or module is
dlopen'd
(which works in stock gcc trunk and with this patch as well).
The patch has been bootstrap and regression tested on
x86_64-apple-darwin12.
Okay for gcc trunk?
But that does not work across translation units, no? ISTR collect2 has support
to handle constructor priorities all by itself (at link time,
considering all inputs).
I wonder why darwin cannot use that mechanism to support init priorities?
Richard.
Jack
ps Unfortunately the flag_sort variable is unavailable inside of
machopic_asm_out_constructor
so we have to unconditionally test for priority == 99.
Re: [PATCH][revised] fix PR sanitizer/55617
On Sun, Feb 3, 2013 at 9:25 PM, Jack Howarth howa...@bromo.med.uc.edu wrote:
Currently darwin is unable to utilize libasan with constructors due to the
lack of
constructor priority support on that target. The asan_finish_file routine
inserts an
essential __asan_init into the array of constructors (via the __mod_init_func
section).
However the insertion occurs at the end, and due to the lack of priority
support for
constructors, these are executed from the start of the array of constructors
on program
startup. This causes code any instrumented code that executes before the
__asan_init
call to crash.
Since darwin sets...
#undef SUPPORTS_INIT_PRIORITY
#define SUPPORTS_INIT_PRIORITY 0
in gcc/config/darwin.h, all constructors are automatically set to
#define DEFAULT_INIT_PRIORITY 65535
in gcc/collect2.c. Any code that attempts to set the constructor/destructor
priority
on darwin results in a compile time error of constructor priorities are not
supported.
So asan alone should be unique in emitting priorities different from 65535 on
darwin.
The attached patch uses a va_gc vector of constructor symbol/priority records
to queue
this data as it is generated in calls to machopic_asm_out_constructor. Any
instances of
the static constructor with priority MAX_RESERVED_INIT_PRIORITY-1 emitted by
asan are
inserted safely in the front of the vector queue which retains the original
order of the
remaining constructors in the queue. The contents of the vector queue are
later processed
in a new finalize_ctors routine called from darwin_file_end if necessary. The
patch also
adds a g++.dg/asan/pr55617.C test case which is targeted to i?86-*-darwin*
and x86_64-*-darwin*.
The patch reduces the failures observed when running
make -k check-g++ RUNTESTFLAGS=--target_board=unix'{-fsanitize=address}'
from 323 to only 85 on darwin (similar to the results on linux). The cov.C
testcase also
fails on gcc trunk with -fsanitize=address when recrafted into a dynamic
shared library
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55617#c28. This patch eliminates
those
crashes. This problem doesn't extend to when the shared library or module is
dlopen'd
(which works in stock gcc trunk and with this patch as well).
The patch has been bootstrap and regression tested on
x86_64-apple-darwin12.
Okay for gcc trunk?
See my other reply - this does not work for multiple TUs.
Richard.
Jack
ps Unfortunately the flag_sort variable is unavailable inside of
machopic_asm_out_constructor
so we have to unconditionally test for priority == MAX_RESERVED_INIT_PRIORITY
- 1.
Re: {PATCH,x86] Workarond for 55970
Hi Ian, It looks that i had to formulate my notes more precisely - the issue with which one our customer met is that there are plenty calls of C++ functions with member class function arguments for which an order of call is essential (see e.g. attached testy-case on C that emulates it. So I only care about an order of calls in incoming arguments. Yuri. 2013/2/1 Ian Lance Taylor i...@google.com: On Fri, Feb 1, 2013 at 5:10 AM, Yuri Rumyantsev ysrum...@gmail.com wrote: This is simple fix that is aimed to help users in porting their applications to x86 platforms which rely on an order of function argument evaluation. To preserve direct order of argument evaluation they need to be added additional option '-mno-push-args' to compile that looks reasonable price for non-C/C++ Standard conformance. I checked that adding this option does not affect on performance on Corei7 and Atom platforms. Note also that option -push-args is passed by default on all x86 platforms and it means that changing this macros will not likely affect on almost all gcc users. If your goal is to preserve the order in which function arguments are evaluated, this patch is not going to be reliable. It only affects the conversion from GIMPLE to RTL. The GIMPLE optimizers will have already had plenty of opportunity to change the function argument evaluation order. I don't think we should change the compiler to generate less efficient code in order to help non-standard-conforming programs when the change won't work reliably anyhow. Ian
Re: [PATCH] fix PR sanitizer/55617
Constructor priorities on Darwin aren't supposed to work across
translation units, see http://llvm.org/bugs/show_bug.cgi?id=12556:
I was told (by Apple folks) that darwin does not support cross-unit constructor
priorities, sorry. This is true for both gcc and llvm-gcc / clang. Within unit
priorities are emulated on darwin (via emission order).
Also, according to Nick Kledzik, constructors are executed on darwin strictly
in link order. So, when you link foo.o and bar.o, then first ctors from foo.o
are executed, then - from bar.o. Maybe this is even documented in some MachO
docs.
Yet it should be possible to delay the constructor emission for a
single TU until all the compiler passes do their job, and then sort
those constructors according to their priorities.
On Mon, Feb 4, 2013 at 1:22 PM, Richard Biener
richard.guent...@gmail.com wrote:
On Sun, Feb 3, 2013 at 5:57 AM, Jack Howarth howa...@bromo.med.uc.edu wrote:
Currently darwin is unable to utilize libasan with constructors due to
the lack of
constructor priority support on that target. The asan_finish_file routine
inserts an
essential __asan_init into the array of constructors (via the
__mod_init_func section).
However the insertion occurs at the end, and due to the lack of priority
support for
constructors, these are executed from the start of the array of constructors
on program
startup. This causes code any instrumented code that executes before the
__asan_init
call to crash.
Since darwin sets...
#undef SUPPORTS_INIT_PRIORITY
#define SUPPORTS_INIT_PRIORITY 0
in gcc/config/darwin.h, all constructors are automatically set to
#define DEFAULT_INIT_PRIORITY 65535
in gcc/collect2.c. Any code that attempts to set the constructor/destructor
priority
on darwin results in a compile time error of constructor priorities are not
supported.
So asan alone should be unique in emitting priorities different from 65535
on darwin.
The attached patch uses a va_gc vector of constructor symbol/priority
records to queue
this data as it is generated in calls to machopic_asm_out_constructor. Any
instances of
the static constructor with priority 99 emitted by asan are inserted safely
in the front
of the vector queue which retains the original order of the remaining
constructors in
the queue. The contents of the vector queue are later processed in a new
finalize_ctors
routine called from darwin_file_end if necessary. The patch also adds a
g++.dg/asan/pr55617.C
test case which is targeted to i?86-*-darwin* and x86_64-*-darwin*.
The patch reduces the failures observed when running
make -k check-g++ RUNTESTFLAGS=--target_board=unix'{-fsanitize=address}'
from 323 to only 85 on darwin (similar to the results on linux). The cov.C
testcase also
fails on gcc trunk with -fsanitize=address when recrafted into a dynamic
shared library
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55617#c28. This patch eliminates
those
crashes. This problem doesn't extend to when the shared library or module is
dlopen'd
(which works in stock gcc trunk and with this patch as well).
The patch has been bootstrap and regression tested on
x86_64-apple-darwin12.
Okay for gcc trunk?
But that does not work across translation units, no? ISTR collect2 has
support
to handle constructor priorities all by itself (at link time,
considering all inputs).
I wonder why darwin cannot use that mechanism to support init priorities?
Richard.
Jack
ps Unfortunately the flag_sort variable is unavailable inside of
machopic_asm_out_constructor
so we have to unconditionally test for priority == 99.
--
Alexander Potapenko
Software Engineer
Google Moscow
Re: [PATCH] fix PR sanitizer/55617
But that does not work across translation units, no? ISTR collect2 has support to handle constructor priorities all by itself (at link time, considering all inputs). I wonder why darwin cannot use that mechanism to support init priorities? Richard. (resending, sorry for top-posting) Constructor priorities on Darwin aren't supposed to work across translation units, see http://llvm.org/bugs/show_bug.cgi?id=12556: I was told (by Apple folks) that darwin does not support cross-unit constructor priorities, sorry. This is true for both gcc and llvm-gcc / clang. Within unit priorities are emulated on darwin (via emission order). Also, according to Nick Kledzik, constructors are executed on darwin strictly in link order. So, when you link foo.o and bar.o, then first ctors from foo.o are executed, then - from bar.o. Maybe this is even documented in some MachO docs. Yet it should be possible to delay the constructor emission for a single TU until all the compiler passes do their job, and then sort those constructors according to their priorities.
Re: [PATCH] fix PR sanitizer/55617
On Mon, Feb 04, 2013 at 10:22:48AM +0100, Richard Biener wrote: Okay for gcc trunk? But that does not work across translation units, no? ISTR collect2 has support to handle constructor priorities all by itself (at link time, considering all inputs). I wonder why the patch turned from initially at least supporting intra-CU support for ctor priorities into an ugly hack for asan. I guess asan doesn't care too much about inter-CU ctor priorities, it just needs its ctors to run before anything in the same CU is called (mainly the __asan_init call), other CUs either won't be asan instrumented, then it doesn't matter, or will be, but they will have their own __asan_init call. I wonder why darwin cannot use that mechanism to support init priorities? But sure, if collect2 can be used for full init prio support, the better. Jakub
Re: {PATCH,x86] Workarond for 55970
On Mon, Feb 4, 2013 at 10:31 AM, Yuri Rumyantsev ysrum...@gmail.com wrote:
Hi Ian,
It looks that i had to formulate my notes more precisely - the issue
with which one our customer met is that there are plenty calls of C++
functions with member class function arguments for which an order of
call is essential (see e.g. attached testy-case on C that emulates it.
So I only care about an order of calls in incoming arguments.
Even though I agree with Ian let me suggest sth. The order of side-effects
when evaluating function call arguments is currently determined by the
order we gimplify, thus solely by gimplify.c. Your patch changes behavior
in multiple places of the compiler, which is not acceptable. Instead
of changing the default order with a switch the only thing I would view
as possibly acceptable is to have a
-ffunction-call-argument-evaluation-order={left-to-right,right-to-left,undefined}
where 'undefined' would be the default. I'm not sure if we can guarantee
the order of evaluation of side-effects in that simple manner though.
Richard.
Yuri.
2013/2/1 Ian Lance Taylor i...@google.com:
On Fri, Feb 1, 2013 at 5:10 AM, Yuri Rumyantsev ysrum...@gmail.com wrote:
This is simple fix that is aimed to help users in porting their
applications to x86 platforms which rely on an order of function
argument evaluation. To preserve direct order of argument evaluation
they need to be added additional option '-mno-push-args' to compile
that looks reasonable price for non-C/C++ Standard conformance.
I checked that adding this option does not affect on performance on
Corei7 and Atom platforms. Note also that option -push-args is
passed by default on all x86 platforms and it means that changing this
macros will not likely affect on almost all gcc users.
If your goal is to preserve the order in which function arguments are
evaluated, this patch is not going to be reliable. It only affects
the conversion from GIMPLE to RTL. The GIMPLE optimizers will have
already had plenty of opportunity to change the function argument
evaluation order.
I don't think we should change the compiler to generate less efficient
code in order to help non-standard-conforming programs when the change
won't work reliably anyhow.
Ian
Re: [PATCH] fix PR sanitizer/55617
On Mon, Feb 4, 2013 at 10:55 AM, Alexander Potapenko gli...@google.com wrote: On Mon, Feb 4, 2013 at 1:38 PM, Jakub Jelinek ja...@redhat.com wrote: On Mon, Feb 04, 2013 at 10:22:48AM +0100, Richard Biener wrote: Okay for gcc trunk? But that does not work across translation units, no? ISTR collect2 has support to handle constructor priorities all by itself (at link time, considering all inputs). I wonder why the patch turned from initially at least supporting intra-CU support for ctor priorities into an ugly hack for asan. I guess asan doesn't care too much about inter-CU ctor priorities, it just needs its ctors to run before anything in the same CU is called (mainly the __asan_init call), other CUs either won't be asan instrumented, then it doesn't matter, or will be, but they will have their own __asan_init call. Yes, I was going to ask the same question. Since other compile-time instrumentation tools (like ThreadSanitizer) will benefit from this as well, it's better to provide the intra-CU support by sorting the list of constructors. Which should be done by the middle-end then? Not sure if have-ctor-priority-support is properly abstracted. Richard.
Re: {PATCH,x86] Workarond for 55970
Hi Richard,
We wrote:
Your patch changes behavior
in multiple places of the compiler, which is not acceptable.
I don't change behavior of compiler since option -mpush-args is
passed to compiler by default. We do change compiler behavior if only
option -mno-push-args was passed to compiler explicitly.
Best regards.
Yuri.
2013/2/4 Richard Biener richard.guent...@gmail.com:
On Mon, Feb 4, 2013 at 10:31 AM, Yuri Rumyantsev ysrum...@gmail.com wrote:
Hi Ian,
It looks that i had to formulate my notes more precisely - the issue
with which one our customer met is that there are plenty calls of C++
functions with member class function arguments for which an order of
call is essential (see e.g. attached testy-case on C that emulates it.
So I only care about an order of calls in incoming arguments.
Even though I agree with Ian let me suggest sth. The order of side-effects
when evaluating function call arguments is currently determined by the
order we gimplify, thus solely by gimplify.c. Your patch changes behavior
in multiple places of the compiler, which is not acceptable. Instead
of changing the default order with a switch the only thing I would view
as possibly acceptable is to have a
-ffunction-call-argument-evaluation-order={left-to-right,right-to-left,undefined}
where 'undefined' would be the default. I'm not sure if we can guarantee
the order of evaluation of side-effects in that simple manner though.
Richard.
Yuri.
2013/2/1 Ian Lance Taylor i...@google.com:
On Fri, Feb 1, 2013 at 5:10 AM, Yuri Rumyantsev ysrum...@gmail.com wrote:
This is simple fix that is aimed to help users in porting their
applications to x86 platforms which rely on an order of function
argument evaluation. To preserve direct order of argument evaluation
they need to be added additional option '-mno-push-args' to compile
that looks reasonable price for non-C/C++ Standard conformance.
I checked that adding this option does not affect on performance on
Corei7 and Atom platforms. Note also that option -push-args is
passed by default on all x86 platforms and it means that changing this
macros will not likely affect on almost all gcc users.
If your goal is to preserve the order in which function arguments are
evaluated, this patch is not going to be reliable. It only affects
the conversion from GIMPLE to RTL. The GIMPLE optimizers will have
already had plenty of opportunity to change the function argument
evaluation order.
I don't think we should change the compiler to generate less efficient
code in order to help non-standard-conforming programs when the change
won't work reliably anyhow.
Ian
Re: [Patch, fortran] PR54107: ICE on recursive interfaces and PR54195: symbol bogusly inserted twice in the interface.
Le 04/02/2013 09:37, Janus Weil a écrit :
- In PR54107(comment 26), the procedure result is a procedure pointer
whose interface is the procedure itself, which leads to an infinite
recursion during resolution.
- In PR54195, a type's type bound procedures are resolved twice, leading
to a symbol being added twice in an interface and rejected.
What about PR 54107 comment 4?
Ah, yes, this patch fixes comment26 only.
This also still fails, right? You had
already posted a patch for this in this PR, which however was quite
different from the one you propose here. (I was assuming that the
problems of comment 4 and comment 26 were quite similar.)
Well, that's what I thought and I even developed a patch limited to
trans-types.c and supposed to fix both. But it turned out that it
didn't, as comment26 is a recursion during resolution while comment4 is
a recursion during translation. I didn't investigate the reasons why
comment26 doesn't recurse during translation; I suppose it's caused by
code like this (several instances):
if (sym-attr.proc_pointer /* whatever */)
{
sym-attr.proc_pointer = 0;
type = build_pointer_type (gfc_get_function_type (sym));
sym-attr.proc_pointer = 1;
}
Can your 'resolved' attribute also help to fix comment 4, or are you
going to post the other patch later?
It can't really help for the reasons above; at the time we start
translation, all the symbols are resolved, so if we reuse that flag, we
have to clear it somewhere, so that it doesn't really mean 'resolved'
any more. I'll post the other patch later.
The fix, as discussed in PR54195, adds a flag to mark a symbol as
resolved.
Why not add this flag directly to gfc_symbol instead of
symbol_attribute? It seems we do not need the attribute for components
(or do we?).
Hum, indeed. symbol_attribute, despite its name, also applies to
components :-/.
OK, I'll move the flag to gfc_symbol.
Thanks for the review.
Mikael
[PATCH] Fix PR56188
This fixes PR56188, another oversight in the PTA speedups.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2013-02-04 Richard Biener rguent...@suse.de
PR tree-optimization/56188
* tree-ssa-structalias.c (label_visit): Consider case with
initially non-empty points-to set.
(perform_var_substitution): Dump node mapping and clean up.
Index: gcc/tree-ssa-structalias.c
===
--- gcc/tree-ssa-structalias.c (revision 195707)
+++ gcc/tree-ssa-structalias.c (working copy)
@@ -2101,13 +2101,17 @@ label_visit (constraint_graph_t graph, s
if (graph-points_to[w])
{
- if (first_pred == -1U)
- first_pred = w;
- else if (!graph-points_to[n])
+ if (!graph-points_to[n])
{
- graph-points_to[n] = BITMAP_ALLOC (predbitmap_obstack);
- bitmap_ior (graph-points_to[n],
- graph-points_to[first_pred], graph-points_to[w]);
+ if (first_pred == -1U)
+ first_pred = w;
+ else
+ {
+ graph-points_to[n] = BITMAP_ALLOC (predbitmap_obstack);
+ bitmap_ior (graph-points_to[n],
+ graph-points_to[first_pred],
+ graph-points_to[w]);
+ }
}
else
bitmap_ior_into(graph-points_to[n], graph-points_to[w]);
@@ -2231,14 +2235,20 @@ perform_var_substitution (constraint_gra
if (dump_file (dump_flags TDF_DETAILS))
for (i = 0; i FIRST_REF_NODE; i++)
{
- bool direct_node = bitmap_bit_p (graph-direct_nodes, i);
- fprintf (dump_file,
-Equivalence classes for %s node id %d:%s are pointer: %d
-, location:%d\n,
-direct_node ? Direct node : Indirect node, i,
-get_varinfo (i)-name,
-graph-pointer_label[si-node_mapping[i]],
-graph-loc_label[si-node_mapping[i]]);
+ unsigned j = si-node_mapping[i];
+ if (j != i)
+ fprintf (dump_file, %s node id %d (%s) mapped to SCC leader
+ node id %d (%s)\n,
+ bitmap_bit_p (graph-direct_nodes, i)
+ ? Direct : Indirect, i, get_varinfo (i)-name,
+ j, get_varinfo (j)-name);
+ else
+ fprintf (dump_file,
+ Equivalence classes for %s node id %d (%s): pointer %d
+ , location %d\n,
+ bitmap_bit_p (graph-direct_nodes, i)
+ ? direct : indirect, i, get_varinfo (i)-name,
+ graph-pointer_label[i], graph-loc_label[i]);
}
/* Quickly eliminate our non-pointer variables. */
[patch i386]: Fix PR target/56186
Hello,
this patch fixes reported regression about 128-bit return-type for x64 ABI.
ChangeLog 2013-02-04 Kai Tietz kti...@redhat.com
PR target/56186
* i386.c (function_value_64): Add additional valtype argument
and improve checking of return-argument types for 16-byte modes.
(ix86_function_value_1): Add additional valtype argument on call
of function_value_64.
(return_in_memory_ms_64): Sync 16-byte sized mode handling with
handling infunction_value_64 function.
Tested for x86_64-w64-mingw32, and for x86_64-unknown-linux-gnu. Ok for apply?
Regards,
Kai
Index: i386.c
===
--- i386.c (Revision 195572)
+++ i386.c (Arbeitskopie)
@@ -7324,7 +7324,8 @@ function_value_64 (enum machine_mode orig_mode, en
}
static rtx
-function_value_ms_64 (enum machine_mode orig_mode, enum machine_mode mode)
+function_value_ms_64 (enum machine_mode orig_mode, enum machine_mode mode,
+ const_tree valtype)
{
unsigned int regno = AX_REG;
@@ -7333,6 +7334,12 @@ static rtx
switch (GET_MODE_SIZE (mode))
{
case 16:
+ if (valtype != NULL_TREE
+ !VECTOR_INTEGER_TYPE_P (valtype)
+ !VECTOR_INTEGER_TYPE_P (valtype)
+ !INTEGRAL_TYPE_P (valtype)
+ !VECTOR_FLOAT_TYPE_P (valtype))
+ break;
if((SCALAR_INT_MODE_P (mode) || VECTOR_MODE_P (mode))
!COMPLEX_MODE_P (mode))
regno = FIRST_SSE_REG;
@@ -7361,7 +7368,7 @@ ix86_function_value_1 (const_tree valtype, const_t
fntype = fn ? TREE_TYPE (fn) : fntype_or_decl;
if (TARGET_64BIT ix86_function_type_abi (fntype) == MS_ABI)
-return function_value_ms_64 (orig_mode, mode);
+return function_value_ms_64 (orig_mode, mode, valtype);
else if (TARGET_64BIT)
return function_value_64 (orig_mode, mode, valtype);
else
@@ -7474,7 +7481,9 @@ return_in_memory_ms_64 (const_tree type, enum mach
HOST_WIDE_INT size = int_size_in_bytes (type);
/* __m128 is returned in xmm0. */
- if ((SCALAR_INT_MODE_P (mode) || VECTOR_MODE_P (mode))
+ if ((!type || VECTOR_INTEGER_TYPE_P (type) || INTEGRAL_TYPE_P (type)
+ || VECTOR_FLOAT_TYPE_P (type))
+ (SCALAR_INT_MODE_P (mode) || VECTOR_MODE_P (mode))
!COMPLEX_MODE_P (mode) (GET_MODE_SIZE (mode) == 16 || size == 16))
return false;
[PATCH] collect2 should accept more AIX linker flags to change shared library search order
Hi, when using -shared -Wl,-G to create AIX shared libraries for use with runtime linking, without also using -Wl,-brtl collect2 still does search for lib.a before lib.so, eventually registering global constructors found in static lib.a, which are not exported by lib.so, so the subsequent link step fails resolving these symbols. Thank you! /haubi/ 2013-02-04 Michael Haubenwallner michael.haubenwall...@salomon.at Accept all flags that enable aix runtime linking to change the library search order. Also there is a disabling flag. * collect2.c (aixrtl_flag): Enabled by -G and -bsvr4 too. Disabled by -bnortl. No false positive on -brtllib or -bnortllib. --- gcc/collect2.c | 10 -- 1 files changed, 8 insertions(+), 2 deletions(-) diff --git a/gcc/collect2.c b/gcc/collect2.c index 0db908f..a9fd7a7 100644 --- a/gcc/collect2.c +++ b/gcc/collect2.c @@ -1033,9 +1033,15 @@ main (int argc, char **argv) export_flag = 1; else if (arg[2] == '6' arg[3] == '4') aix64_flag = 1; - else if (arg[2] == 'r' arg[3] == 't' arg[4] == 'l') - aixrtl_flag = 1; + else if (arg[2] == 'r' arg[3] == 't' arg[4] == 'l' arg[5] == '\0') + aixrtl_flag = 1; /* -brtl (not -brtllib) */ + else if (arg[2] == 'n' arg[3] == 'o' arg[4] == 'r' arg[5] == 't' arg[6] == 'l' arg[7] == '\0') + aixrtl_flag = 0; /* -bnortl (not -bnortllib) */ + else if (arg[2] == 's' arg[3] == 'v' arg[4] == 'r' arg[5] == '4') + aixrtl_flag = 1; /* -bsvr4 enables -brtl */ } + if ((argv[i][0] == '-') (argv[i][1] == 'G')) + aixrtl_flag = 1; /* -G enables -brtl */ #endif } vflag = debug; -- 1.7.3.4
Re: [PATCH] fix PR sanitizer/55617
On Mon, Feb 04, 2013 at 10:38:29AM +0100, Jakub Jelinek wrote:
On Mon, Feb 04, 2013 at 10:22:48AM +0100, Richard Biener wrote:
Okay for gcc trunk?
But that does not work across translation units, no? ISTR collect2 has
support
to handle constructor priorities all by itself (at link time,
considering all inputs).
I wonder why the patch turned from initially at least supporting intra-CU
support for ctor priorities into an ugly hack for asan. I guess asan
doesn't care too much about inter-CU ctor priorities, it just needs its
ctors to run before anything in the same CU is called (mainly the
__asan_init call), other CUs either won't be asan instrumented, then it
doesn't matter, or will be, but they will have their own __asan_init call.
Jakub,
I switched to the simple insertion of the asan priorities for two reasons...
1) Mike seemed unconvinced that the single qsort with the proposed
sort_ctor_records
of...
+static int
+sort_ctor_records (const void * a, const void * b)
+{
+ const ctor_record *ca = (const ctor_record *)a;
+ const ctor_record *cb = (const ctor_record *)b;
+ if (ca-priority cb-priority)
+return 1;
+ if (ca-priority cb-priority)
+return -1;
+ if (ca-position cb-position)
+return -1;
+ if (ca-position cb-position)
+return 1;
+ return 0;
+}
would really be stable in absence of a second call to qsort.
2) Once I realized that darwin sets the default priority of constructors to
DEFAULT_INIT_PRIORITY 65535, the desired sorting method seemed rather unclear.
I assume we need to really sort these so that the priorities from
MAX_INIT_PRIORITY-1 through 0 appear first in the queue and then those with
MAX_INIT_PRIORITY, right? It isn't obvious how we can achieve that in
sort_ctor_record with a single pass through qsort.
Jack
I wonder why darwin cannot use that mechanism to support init priorities?
But sure, if collect2 can be used for full init prio support, the better.
Jakub
Re: [PATCH] fix PR sanitizer/55617
On Mon, Feb 04, 2013 at 09:22:27AM -0500, Jack Howarth wrote:
On Mon, Feb 04, 2013 at 10:38:29AM +0100, Jakub Jelinek wrote:
On Mon, Feb 04, 2013 at 10:22:48AM +0100, Richard Biener wrote:
Okay for gcc trunk?
But that does not work across translation units, no? ISTR collect2 has
support
to handle constructor priorities all by itself (at link time,
considering all inputs).
I wonder why the patch turned from initially at least supporting intra-CU
support for ctor priorities into an ugly hack for asan. I guess asan
doesn't care too much about inter-CU ctor priorities, it just needs its
ctors to run before anything in the same CU is called (mainly the
__asan_init call), other CUs either won't be asan instrumented, then it
doesn't matter, or will be, but they will have their own __asan_init call.
Jakub,
I switched to the simple insertion of the asan priorities for two
reasons...
1) Mike seemed unconvinced that the single qsort with the proposed
sort_ctor_records
of...
+static int
+sort_ctor_records (const void * a, const void * b)
+{
+ const ctor_record *ca = (const ctor_record *)a;
+ const ctor_record *cb = (const ctor_record *)b;
+ if (ca-priority cb-priority)
+return 1;
+ if (ca-priority cb-priority)
+return -1;
+ if (ca-position cb-position)
+return -1;
+ if (ca-position cb-position)
+return 1;
+ return 0;
+}
would really be stable in absence of a second call to qsort.
2) Once I realized that darwin sets the default priority of constructors to
DEFAULT_INIT_PRIORITY 65535, the desired sorting method seemed rather unclear.
I assume we need to really sort these so that the priorities from
MAX_INIT_PRIORITY-1 through 0 appear first in the queue and then those with
MAX_INIT_PRIORITY, right? It isn't obvious how we can achieve that in
sort_ctor_record with a single pass through qsort.
Jack
Nevermind. I now see sorting priorities from lower to higher throughout is
correct. I'll
repost the originally proposed patch for qsort later.
Jack
I wonder why darwin cannot use that mechanism to support init priorities?
But sure, if collect2 can be used for full init prio support, the better.
Jakub
Re: [PATCH] fix PR sanitizer/55617
On Mon, Feb 04, 2013 at 09:22:27AM -0500, Jack Howarth wrote:
I switched to the simple insertion of the asan priorities for two
reasons...
1) Mike seemed unconvinced that the single qsort with the proposed
sort_ctor_records
of...
+static int
+sort_ctor_records (const void * a, const void * b)
+{
+ const ctor_record *ca = (const ctor_record *)a;
+ const ctor_record *cb = (const ctor_record *)b;
+ if (ca-priority cb-priority)
+return 1;
+ if (ca-priority cb-priority)
+return -1;
+ if (ca-position cb-position)
+return -1;
Obviously this should have been return 1;
+ if (ca-position cb-position)
+return 1;
and this return -1;
+ return 0;
+}
would really be stable in absence of a second call to qsort.
Ugh, how can that not be stable? position is different in every vector
entry, so even the return 0; case above would happen only if qsort
(incorrectly) called it with two same pointers. So, the second and any
further calls to qsort with the same comparison function in this case
necessarily don't change anything in the array (ok, unless you have more
than 4billion ctors and overflow position, or unless your OS has a buggy
qsort (which wouldn't surprise me for Darwin)).
2) Once I realized that darwin sets the default priority of constructors to
DEFAULT_INIT_PRIORITY 65535, the desired sorting method seemed rather unclear.
I assume we need to really sort these so that the priorities from
MAX_INIT_PRIORITY-1 through 0 appear first in the queue and then those with
MAX_INIT_PRIORITY, right? It isn't obvious how we can achieve that in
sort_ctor_record with a single pass through qsort.
?? You simply sort by priority ascending, and for same priorities, by
position ascending.
Jakub
Re: [RFA] Fix DEBUG_RELOAD support
Matthew Gretton-Dann wrote: 2013-02-02 Matthew Gretton-Dann matthew.gretton-d...@linaro.org * gcc/reload.c (subst_reloads): Fix DEBUG_RELOAD build issue. This is OK. Thanks, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE ulrich.weig...@de.ibm.com
Re: [PATCH] fix PR sanitizer/55617
On Mon, Feb 04, 2013 at 03:44:04PM +0100, Jakub Jelinek wrote:
On Mon, Feb 04, 2013 at 09:22:27AM -0500, Jack Howarth wrote:
I switched to the simple insertion of the asan priorities for two
reasons...
1) Mike seemed unconvinced that the single qsort with the proposed
sort_ctor_records
of...
+static int
+sort_ctor_records (const void * a, const void * b)
+{
+ const ctor_record *ca = (const ctor_record *)a;
+ const ctor_record *cb = (const ctor_record *)b;
+ if (ca-priority cb-priority)
+return 1;
+ if (ca-priority cb-priority)
+return -1;
+ if (ca-position cb-position)
+return -1;
Obviously this should have been return 1;
+ if (ca-position cb-position)
+return 1;
and this return -1;
+ return 0;
+}
would really be stable in absence of a second call to qsort.
Ugh, how can that not be stable? position is different in every vector
entry, so even the return 0; case above would happen only if qsort
(incorrectly) called it with two same pointers. So, the second and any
further calls to qsort with the same comparison function in this case
necessarily don't change anything in the array (ok, unless you have more
than 4billion ctors and overflow position, or unless your OS has a buggy
qsort (which wouldn't surprise me for Darwin)).
Actually don't we need...
static int
sort_ctor_records (const void * a, const void * b)
{
const ctor_record *ca = (const ctor_record *)a;
const ctor_record *cb = (const ctor_record *)b;
if (ca-priority cb-priority)
return 1;
if (ca-priority cb-priority)
return -1;
if ((ca-priority == cb-priority) (ca-position cb-position))
return 1;
if ((ca-priority == cb-priority) (ca-position cb-position))
return -1;
return 0;
}
so that the last two checks only sort the original positions of constructors for
the same priority?
2) Once I realized that darwin sets the default priority of constructors to
DEFAULT_INIT_PRIORITY 65535, the desired sorting method seemed rather
unclear.
I assume we need to really sort these so that the priorities from
MAX_INIT_PRIORITY-1 through 0 appear first in the queue and then those with
MAX_INIT_PRIORITY, right? It isn't obvious how we can achieve that in
sort_ctor_record with a single pass through qsort.
?? You simply sort by priority ascending, and for same priorities, by
position ascending.
Jakub
[PATCH] Add missing explicit instantiation for std::lower_bound template
Hello, Since commit r195676[1], it looks like libstdc++-v3/src/c++11/hashtable_c++0x.cc is missing an explicit instantiation for std::lower_bound. This leads to libstdc++.so having the symbol for that (missing) instantiation be undefined, thus preventing executables from being linked with libstdc++. The patchlet below seems to fixed the issue for me. Boostrapped and tested on x86_64-unknown-linux-gnu. [1]: commit bc36b44c7cb0e5e97ac807b8fb17507e0fb09008 Author: fdumont fdumont@138bc75d-0d04-0410-961f-82ee72b054a4 Date: Fri Feb 1 20:44:41 2013 + 2013-02-01 François Dumont fdum...@gcc.gnu.org * include/bits/hashtable_policy.h (_Prime_rehash_policy::_M_next_bkt) (_Prime_rehash_policy::_M_need_rehash): Move definition... * src/c++11/hashtable_c++0x.cc: ... here. * src/shared/hashtable-aux.cc: Remove c++config.h include. * config/abi/gnu.ver (GLIBCXX_3.4.18): Export _Prime_rehash_policy symbols. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@195676 138bc75d-0d04-0410-961f-82ee72b054a4 libstdc++-v3/ChangeLog * libstdc++-v3/src/c++11/hashtable_c++0x.cc (namespace std): Add missing instantiation for std::lower_bound template. --- libstdc++-v3/ChangeLog| 6 ++ libstdc++-v3/src/c++11/hashtable_c++0x.cc | 7 +++ 2 files changed, 13 insertions(+) diff --git a/libstdc++-v3/ChangeLog b/libstdc++-v3/ChangeLog index 1a8a822..8ae9343 100644 --- a/libstdc++-v3/ChangeLog +++ b/libstdc++-v3/ChangeLog @@ -1,3 +1,9 @@ +2013-02-04 Dodji Seketeli do...@redhat.com + + Add missing explicit instantiation for std::lower_bound template + * libstdc++-v3/src/c++11/hashtable_c++0x.cc (namespace std): Add + missing instantiation for std::lower_bound template. + 2013-02-03 Richard Sandiford rdsandif...@googlemail.com Update copyright years. diff --git a/libstdc++-v3/src/c++11/hashtable_c++0x.cc b/libstdc++-v3/src/c++11/hashtable_c++0x.cc index 7617c58..942d119 100644 --- a/libstdc++-v3/src/c++11/hashtable_c++0x.cc +++ b/libstdc++-v3/src/c++11/hashtable_c++0x.cc @@ -94,4 +94,11 @@ namespace __detail _GLIBCXX_END_NAMESPACE_VERSION } // namespace __detail + + // Instantiations. + template unsigned long const* + lower_boundunsigned long const *, +unsigned long(unsigned long const*, + unsigned long const*, + const unsigned long ); } // namespace std -- Dodji
Re: [patch i386]: Fix PR target/56186
On 2013-02-04 05:38, Kai Tietz wrote: ChangeLog 2013-02-04 Kai Tietzkti...@redhat.com PR target/56186 * i386.c (function_value_64): Add additional valtype argument and improve checking of return-argument types for 16-byte modes. (ix86_function_value_1): Add additional valtype argument on call of function_value_64. (return_in_memory_ms_64): Sync 16-byte sized mode handling with handling infunction_value_64 function. Fix the function names in the changelog. Otherwise ok. r~
Re: [patch i386]: Fix PR target/56186
On Mon, Feb 04, 2013 at 02:38:23PM +0100, Kai Tietz wrote:
Tested for x86_64-w64-mingw32, and for x86_64-unknown-linux-gnu. Ok for
apply?
Please make sure to also test with a 4.7 based compiler (assuming
it is gcc47 and g++47) using
make check ALT_CC_UNDER_TEST=gcc47 ALT_CXX_UNDER_TEST=g++47
RUNTESTFLAGS='compat.exp struct-layout-1.exp'
Index: i386.c
===
--- i386.c(Revision 195572)
+++ i386.c(Arbeitskopie)
@@ -7324,7 +7324,8 @@ function_value_64 (enum machine_mode orig_mode, en
}
static rtx
-function_value_ms_64 (enum machine_mode orig_mode, enum machine_mode mode)
+function_value_ms_64 (enum machine_mode orig_mode, enum machine_mode mode,
+ const_tree valtype)
{
unsigned int regno = AX_REG;
@@ -7333,6 +7334,12 @@ static rtx
switch (GET_MODE_SIZE (mode))
{
case 16:
+ if (valtype != NULL_TREE
+!VECTOR_INTEGER_TYPE_P (valtype)
+ !VECTOR_INTEGER_TYPE_P (valtype)
Wrong whitespace above (spaces instead of tabs)?
+!INTEGRAL_TYPE_P (valtype)
+!VECTOR_FLOAT_TYPE_P (valtype))
+ break;
if((SCALAR_INT_MODE_P (mode) || VECTOR_MODE_P (mode))
!COMPLEX_MODE_P (mode))
regno = FIRST_SSE_REG;
Jakub
Re: [RFA] Fix DEBUG_RELOAD support
On 02/02/2013 02:27 PM, Matthew Gretton-Dann wrote: 2013-02-02 Matthew Gretton-Dannmatthew.gretton-d...@linaro.org * gcc/reload.c (subst_reloads): Fix DEBUG_RELOAD build issue. Thanks. Applied to the trunk. Jeff
[PATCH] Fix thinko in handle_error_attribute (PR middle-end/56167)
Hi!
Without this fix, we were letting in invalid error/warning attributes,
on function decls in addition to valid ones with STRING_CST argument also
attributes with various bogus arguments, and for e.g. VAR_DECLs which
shouldn't have any error/warning attributes those with STRING_CST arguments.
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
trunk?
2013-02-04 Jakub Jelinek ja...@redhat.com
PR middle-end/56167
* c-common.c (handle_error_attribute): Fix condition.
* gcc.dg/pr56167.c: New test.
--- gcc/c-family/c-common.c.jj 2013-01-30 19:01:11.0 +0100
+++ gcc/c-family/c-common.c 2013-02-01 08:46:07.741550116 +0100
@@ -6678,7 +6678,7 @@ handle_error_attribute (tree *node, tree
int ARG_UNUSED (flags), bool *no_add_attrs)
{
if (TREE_CODE (*node) == FUNCTION_DECL
- || TREE_CODE (TREE_VALUE (args)) == STRING_CST)
+ TREE_CODE (TREE_VALUE (args)) == STRING_CST)
/* Do nothing else, just set the attribute. We'll get at
it later with lookup_attribute. */
;
--- gcc/testsuite/gcc.dg/pr56167.c.jj 2013-02-01 08:50:11.268198682 +0100
+++ gcc/testsuite/gcc.dg/pr56167.c 2013-02-01 08:49:43.0 +0100
@@ -0,0 +1,15 @@
+/* PR middle-end/56167 */
+/* { dg-do compile } */
+
+extern void foo (void) __attribute__ ((error (0)));/* { dg-warning
attribute ignored } */
+extern void bar (void) __attribute__ ((warning (0))); /* { dg-warning
attribute ignored } */
+int var __attribute__ ((error (foo))); /* { dg-warning
attribute ignored } */
+
+int
+main ()
+{
+ foo ();
+ bar ();
+ var++;
+ return 0;
+}
Jakub
[PATCH] Port Jason's r195550 varasm.c change also to mingw/cygwin/solaris private copies (PR libstdc++/54314)
Hi!
In http://gcc.gnu.org/viewcvs?root=gccview=revrev=195550
Jason changed the default assemble_visibility target hook to avoid
complaining on DECL_ARTIFICIAL decls, even when they have some visibility
set (the C++ FE now sets visibility of construction vtables), this patch
ports that to solaris and winnt private variants of the hook.
Tested with Solaris cross on the testcase, ok for trunk?
2013-02-04 Jakub Jelinek ja...@redhat.com
PR libstdc++/54314
* config/i386/winnt.c (i386_pe_assemble_visibility): Don't warn
about visibility on artificial decls.
* config/sol2.c (solaris_assemble_visibility): Likewise.
--- gcc/config/i386/winnt.c.jj 2013-01-11 09:03:06.075488067 +0100
+++ gcc/config/i386/winnt.c 2013-02-04 11:40:31.314181511 +0100
@@ -250,8 +250,9 @@ i386_pe_assemble_visibility (tree decl,
if (!decl
|| !lookup_attribute (visibility, DECL_ATTRIBUTES (decl)))
return;
- warning (OPT_Wattributes, visibility attribute not supported
- in this configuration; ignored);
+ if (!DECL_ARTIFICIAL (decl))
+warning (OPT_Wattributes, visibility attribute not supported
+ in this configuration; ignored);
}
/* This is used as a target hook to modify the DECL_ASSEMBLER_NAME
--- gcc/config/sol2.c.jj2013-01-11 09:03:07.0 +0100
+++ gcc/config/sol2.c 2013-02-04 11:40:51.417065051 +0100
@@ -124,8 +124,7 @@ solaris_output_init_fini (FILE *file, tr
the visibility type VIS, which must not be VISIBILITY_DEFAULT. */
void
-solaris_assemble_visibility (tree decl ATTRIBUTE_UNUSED,
-int vis ATTRIBUTE_UNUSED)
+solaris_assemble_visibility (tree decl, int vis ATTRIBUTE_UNUSED)
{
#ifdef HAVE_GAS_HIDDEN
/* Sun as uses .symbolic for STV_PROTECTED. STV_INTERNAL is marked as
@@ -152,8 +151,9 @@ solaris_assemble_visibility (tree decl A
assemble_name (asm_out_file, name);
fprintf (asm_out_file, \n);
#else
- warning (OPT_Wattributes, visibility attribute not supported
- in this configuration; ignored);
+ if (!DECL_ARTIFICIAL (decl))
+warning (OPT_Wattributes, visibility attribute not supported
+ in this configuration; ignored);
#endif
}
Jakub
Re: [patch i386]: Fix PR target/56186
2013/2/4 Jakub Jelinek ja...@redhat.com:
On Mon, Feb 04, 2013 at 02:38:23PM +0100, Kai Tietz wrote:
Tested for x86_64-w64-mingw32, and for x86_64-unknown-linux-gnu. Ok for
apply?
Please make sure to also test with a 4.7 based compiler (assuming
it is gcc47 and g++47) using
make check ALT_CC_UNDER_TEST=gcc47 ALT_CXX_UNDER_TEST=g++47
RUNTESTFLAGS='compat.exp struct-layout-1.exp'
Index: i386.c
===
--- i386.c(Revision 195572)
+++ i386.c(Arbeitskopie)
@@ -7324,7 +7324,8 @@ function_value_64 (enum machine_mode orig_mode, en
}
static rtx
-function_value_ms_64 (enum machine_mode orig_mode, enum machine_mode mode)
+function_value_ms_64 (enum machine_mode orig_mode, enum machine_mode mode,
+ const_tree valtype)
{
unsigned int regno = AX_REG;
@@ -7333,6 +7334,12 @@ static rtx
switch (GET_MODE_SIZE (mode))
{
case 16:
+ if (valtype != NULL_TREE
+!VECTOR_INTEGER_TYPE_P (valtype)
+ !VECTOR_INTEGER_TYPE_P (valtype)
Wrong whitespace above (spaces instead of tabs)?
+!INTEGRAL_TYPE_P (valtype)
+!VECTOR_FLOAT_TYPE_P (valtype))
+ break;
if((SCALAR_INT_MODE_P (mode) || VECTOR_MODE_P (mode))
!COMPLEX_MODE_P (mode))
regno = FIRST_SSE_REG;
Jakub
I corrected this in applied patch. There were before spaces used
instead of tab.
Thanks for noticing it.
Kai
Re: [PATCH] Port Jason's r195550 varasm.c change also to mingw/cygwin/solaris private copies (PR libstdc++/54314)
2013/2/4 Jakub Jelinek ja...@redhat.com: Hi! In http://gcc.gnu.org/viewcvs?root=gccview=revrev=195550 Jason changed the default assemble_visibility target hook to avoid complaining on DECL_ARTIFICIAL decls, even when they have some visibility set (the C++ FE now sets visibility of construction vtables), this patch ports that to solaris and winnt private variants of the hook. Tested with Solaris cross on the testcase, ok for trunk? 2013-02-04 Jakub Jelinek ja...@redhat.com PR libstdc++/54314 * config/i386/winnt.c (i386_pe_assemble_visibility): Don't warn about visibility on artificial decls. The mingw-part is ok. Thanks, Kai
Re: [PATCH] Port Jason's r195550 varasm.c change also to mingw/cygwin/solaris private copies (PR libstdc++/54314)
OK, thanks. Jason
[v3] libstdc++/56202
Hi,
tested x96_64-linux, committed to mainline.
Thanks,
Paolo.
/
2013-02-04 Manuel López-Ibáñez m...@gcc.gnu.org
Paolo Carlini paolo.carl...@oracle.com
PR libstdc++/56202
* include/bits/random.tcc (binomial_distribution::
_M_waiting(_UniformRandomNumberGenerator, _IntType)): Avoid
division by zero.
Index: include/bits/random.tcc
===
--- include/bits/random.tcc (revision 195717)
+++ include/bits/random.tcc (working copy)
@@ -1658,6 +1658,12 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
do
{
const double __e = -std::log(1.0 - __aurng());
+ if (__t == __x)
+ {
+ if (__e)
+ return __x;
+ continue;
+ }
__sum += __e / (__t - __x);
__x += 1;
}
[PATCH] fix PR sanitizer/55617 via qsort
Currently darwin is unable to utilize libasan with constructors due to the
lack of
constructor priority support on that target. The asan_finish_file routine
inserts an
essential __asan_init into the array of constructors (via the __mod_init_func
section).
However the insertion occurs at the end, and due to the lack of priority
support for
constructors, these are executed from the front of the array of constructors on
program
startup. This causes code any instrumented code that executes before the
__asan_init
call to crash.
The attached patch uses a va_gc vector of constructor symbol/priority
records to
queue this data inside machopic_asm_out_constructor. When the ctors vector is
not empty,
the finalize_ctors routine is called in darwin_file_end to sort the queue by
priority,
using a qsort stabilized on original position for identical priority, prior to
emitting
the constructors. The patch also adds a g++.dg/asan/pr55617.C test case which is
targeted to i?86-*-darwin* and x86_64-*-darwin*.
The patch reduces the failures observed when running
make -k check-g++ RUNTESTFLAGS=--target_board=unix'{-fsanitize=address}'
from 323 to only 85 (which is similar to what linux shows). The cov.C testcase
also
fails on gcc trunk with -fsanitize=address when recrafted into a dynamic shared
library
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55617#c28. This patch eliminates
those
crashes. This problem doesn't extend to when the shared library or module is
dlopen'd
(which works in stock gcc trunk and with this patch as well).
The patch has been bootstrap and regression tested on x86_64-apple-darwin12.
Okay for gcc trunk?
Jack
ps The issue of inter module priority support remains unresolved (as it is in
clang/llvm).
The only solution for both compilers is to reorder the linkage of the modules
to insure that the
module with the asan constructor appears first.
/gcc
2013-02-04 Alexander Potapenko gli...@google.com
Jack Howarth howa...@bromo.med.uc.edu
Jakub Jelinek ja...@redhat.com
PR sanitizer/55617
* config/darwin.c (sort_ctor_records): Stabilized qsort
on constructor priority by using original position.
(finalize_ctors): New routine to sort constructors by
priority before use in assemble_integer.
(machopic_asm_out_constructor): Use finalize_ctors if needed.
/gcc/testsuite
2013-02-04 Alexander Potapenko gli...@google.com
Jack Howarth howa...@bromo.med.uc.edu
Jakub Jelinek ja...@redhat.com
PR sanitizer/55617
* g++.dg/asan/pr55617.C: New test.
Index: gcc/config/darwin.c
===
--- gcc/config/darwin.c (revision 195685)
+++ gcc/config/darwin.c (working copy)
@@ -83,6 +83,14 @@ along with GCC; see the file COPYING3.
kernel) the stubs might still be required, and this will be set true. */
int darwin_emit_branch_islands = false;
+typedef struct GTY(()) ctor_record {
+ rtx symbol;
+ int priority;/* constructor priority */
+ int position;/* original position */
+} ctor_record;
+
+static GTY(()) vecctor_record, va_gc *ctors = NULL;
+
/* A flag to determine whether we are running c++ or obj-c++. This has to be
settable from non-c-family contexts too (i.e. we can't use the c_dialect_
functions). */
@@ -1708,15 +1716,48 @@ machopic_select_rtx_section (enum machin
void
machopic_asm_out_constructor (rtx symbol, int priority ATTRIBUTE_UNUSED)
{
+ ctor_record new_elt = {symbol, priority, vec_safe_length (ctors)};
+
+ vec_safe_push (ctors, new_elt);
+
+ if (! MACHOPIC_INDIRECT)
+fprintf (asm_out_file, .reference .constructors_used\n);
+}
+
+static int
+sort_ctor_records (const void * a, const void * b)
+{
+ const ctor_record *ca = (const ctor_record *)a;
+ const ctor_record *cb = (const ctor_record *)b;
+ if (ca-priority cb-priority)
+return 1;
+ if (ca-priority cb-priority)
+return -1;
+ if (ca-position cb-position)
+return 1;
+ if (ca-position cb-position)
+return -1;
+ return 0;
+}
+
+static void
+finalize_ctors()
+{
+ unsigned int i;
+ ctor_record *elt;
+
if (MACHOPIC_INDIRECT)
switch_to_section (darwin_sections[mod_init_section]);
else
switch_to_section (darwin_sections[constructor_section]);
- assemble_align (POINTER_SIZE);
- assemble_integer (symbol, POINTER_SIZE / BITS_PER_UNIT, POINTER_SIZE, 1);
- if (! MACHOPIC_INDIRECT)
-fprintf (asm_out_file, .reference .constructors_used\n);
+ if (vec_safe_length (ctors) 1)
+ctors-qsort (sort_ctor_records);
+ FOR_EACH_VEC_SAFE_ELT (ctors, i, elt)
+{
+ assemble_align (POINTER_SIZE);
+ assemble_integer (elt-symbol, POINTER_SIZE / BITS_PER_UNIT,
POINTER_SIZE, 1);
+}
}
void
@@ -2762,6 +2803,8 @@ darwin_file_start (void)
void
darwin_file_end (void)
{
+ if (!vec_safe_is_empty (ctors))
+finalize_ctors();
[PATCH][Cilkplus] Exceptions in a spawning function
Hello Everyone,
This patch is for the Cilk Plus branch mainly affecting the C++
compiler. This patch will handle exceptions thrown by the spawning function (a
function called with _Cilk_spawn).
Thanks,
Balaji V. Iyer.
diff --git gcc/ChangeLog.cilkplus gcc/ChangeLog.cilkplus
old mode 100644
new mode 100755
index 97975d8..0cae431
--- gcc/ChangeLog.cilkplus
+++ gcc/ChangeLog.cilkplus
@@ -1,3 +1,22 @@
+2013-02-04 Balaji V. Iyer balaji.v.i...@intel.com
+
+ * cilk.c (cilk_init_builtins): Defined __cilkrts_rethrow builtin
+ function.
+ (build_cilk_sync): Added code to set exception flag and exception data
+ in the stack frame. Also added code to call __cilkrts_rethrow function.
+ Finally, inserted this code in the appropriate location of if-stmt.
+ (set_cilk_except_flag): New function.
+ (clear_cilk_except_flag): Likewise.
+ (set_cilk_except_data): Likewise.
+ (build_cilk_catch_sync): Likewise.
+ * cilk-builtins.def (BUILT_IN_CILK_RETHROW): New builtin function.
+ * c/c-objc-common.h (LANG_HOOKS_FRAME_CLEANUP): Set this hook to
+ c_install_body_with_frame_cleanup.
+ * langhooks-def.h (LANG_HOOKS_FRAME_CLEANUP): New #define.
+ (lhd_install_body_with_frame_cleanup): New function.
+ * langhooks.h (lang_hooks_for_cilkplus): New struct field called
+ install_body_with_frame_cleanup.
+
2013-01-24 Balaji V. Iyer balaji.v.i...@intel.com
* cgraphunit.c (cgraph_finalize_function): If cilkplus is enabled and
diff --git gcc/builtins.def gcc/builtins.def
old mode 100644
new mode 100755
diff --git gcc/c-family/ChangeLog.cilkplus gcc/c-family/ChangeLog.cilkplus
old mode 100644
new mode 100755
index 9a720b8..8bc0a17
--- gcc/c-family/ChangeLog.cilkplus
+++ gcc/c-family/ChangeLog.cilkplus
@@ -1,3 +1,11 @@
+2013-02-04 Balaji V. Iyer balaji.v.i...@intel.com
+
+ * c-cilk.c (build_cilk_wrapper_body): Replaced the function call for
+ install_body_with_frame_cleanup with the one from langhooks.
+ (build_cilk_for_body): Likewise.
+ (install_body_with_frame_cleanup): Renamed this function to
+ c_install_body_with_frame_cleanup.
+
2013-01-24 Balaji V. Iyer balaji.v.i...@intel.com
* c-cpp-elem-function.c (elem_fn_create_fn): Set the assembler name and
diff --git gcc/c-family/c-cilk.c gcc/c-family/c-cilk.c
old mode 100644
new mode 100755
index f1bace5..dee4579
--- gcc/c-family/c-cilk.c
+++ gcc/c-family/c-cilk.c
@@ -99,7 +99,6 @@ static void cilk_outline (tree inner_fn, tree *, struct
wrapper_data *);
static tree copy_decl_for_cilk (tree decl, copy_body_data *id);
static tree check_outlined_calls (tree *, int *, void *);
static tree build_cilk_wrapper (tree, tree *);
-static void install_body_with_frame_cleanup (tree, tree);
static bool var_mentioned_p (tree exp, tree var);
extern tree build_unary_op (location_t location, enum tree_code code,
@@ -135,7 +134,6 @@ call_graph_add_fn (tree fndecl, struct wrapper_data *wd)
tree_cons (NULL_TREE, fndecl, cilk_trees[CILK_TI_PENDING_FUNCTIONS]);
f-curr_properties = cfun-curr_properties;
-
gcc_assert (cfun == DECL_STRUCT_FUNCTION (outer));
gcc_assert (cfun-decl == outer);
@@ -1407,7 +1405,7 @@ build_cilk_wrapper_body (tree stmt,
cilk_outline (fndecl, stmt, wd);
stmt = fold_build_cleanup_point_expr (void_type_node, stmt);
gcc_assert (!DECL_SAVED_TREE (fndecl));
- install_body_with_frame_cleanup (fndecl, stmt);
+ lang_hooks.cilkplus.install_body_with_frame_cleanup (fndecl, stmt);
gcc_assert (DECL_SAVED_TREE (fndecl));
pop_cfun_to (outer);
@@ -1553,8 +1551,8 @@ check_outlined_calls (tree *tp,
/* This function installs the internal functions of spawn helper and parent.
*/
-static void
-install_body_with_frame_cleanup (tree fndecl, tree body)
+void
+c_install_body_with_frame_cleanup (tree fndecl, tree body)
{
tree list;
tree frame = make_cilk_frame (fndecl);
@@ -2455,7 +2453,7 @@ build_cilk_for_body (struct cilk_for_desc *cfd)
body = build3 (BIND_EXPR, void_type_node, loop_var, body, block);
TREE_CHAIN (loop_var) = cfd-var2;
if (contains_spawn (body))
-install_body_with_frame_cleanup (fndecl, body);
+lang_hooks.cilkplus.install_body_with_frame_cleanup (fndecl, body);
else
DECL_SAVED_TREE (fndecl) = body;
diff --git gcc/c/c-objc-common.h gcc/c/c-objc-common.h
index 8053c53..08ad087 100644
--- gcc/c/c-objc-common.h
+++ gcc/c/c-objc-common.h
@@ -122,4 +122,8 @@ along with GCC; see the file COPYING3. If not see
#undef LANG_HOOKS_CILK_CHECK_CTRL_FLOW
#define LANG_HOOKS_CILK_CHECK_CTRL_FLOW cilk_check_ctrl_flow
+
+#undef LANG_HOOKS_FRAME_CLEANUP
+#define LANG_HOOKS_FRAME_CLEANUP c_install_body_with_frame_cleanup
+
#endif /* GCC_C_OBJC_COMMON */
diff --git gcc/cilk-builtins.def gcc/cilk-builtins.def
old mode 100644
new mode 100755
index 5de740a..e483dd8
--- gcc/cilk-builtins.def
+++ gcc/cilk-builtins.def
@@ -24,6 +24,7 @@ along with GCC; see the file
[PATCH] Fix PR56131 - gcc.dg/pr56035.c ICEs gcc on sparc-linux
Eric,
This patch fixes PR56131.
The problem is that in delete_insn, while deleting an undeletable label (in
other words, transforming a label into a INSN_NOTE_DELETED_LABEL):
- we try to find the bb of a NOTE_INSN_BASIC_BLOCK following the label using
BLOCK_FOR_INSN (which is NULL) instead of NOTE_BASIC_BLOCK (which is not
NULL), and
- we don't handle the case that we find a NULL pointer for that bb gracefully.
This comment in insn-notes.def tells us that the bb info could be in either of
the two:
...
/* Record the struct for the following basic block. Uses
NOTE_BASIC_BLOCK. FIXME: Redundant with the basic block pointer
now included in every insn. */
INSN_NOTE (BASIC_BLOCK)
...
The patch fixes the problems by:
- using NOTE_BASIC_BLOCK to find the bb of NOTE_INSN_BASIC_BLOCK, and
- explicitly handling the cases that the bb of either the label or the note is
NULL.
Bootstrapped and reg-tested by Mikael Pettersson on both x86_64-linux and
sparc64-linux.
OK for trunk?
Thanks,
- Tom
2013-02-04 Tom de Vries t...@codesourcery.com
PR rtl-optimization/56131
* cfgrtl.c (delete_insn): Use NOTE_BASIC_BLOCK instead of BLOCK_FOR_INSN
to get the bb of a NOTE_INSN_BASIC_BLOCK. Handle the case that the bb
of the label is NULL. Add comment.
Index: gcc/cfgrtl.c
===
--- gcc/cfgrtl.c (revision 195240)
+++ gcc/cfgrtl.c (working copy)
@@ -135,7 +135,7 @@ delete_insn (rtx insn)
if (! can_delete_label_p (insn))
{
const char *name = LABEL_NAME (insn);
- basic_block bb = BLOCK_FOR_INSN (insn);
+ basic_block bb = NULL, label_bb = BLOCK_FOR_INSN (insn);
rtx bb_note = NEXT_INSN (insn);
really_delete = false;
@@ -143,8 +143,16 @@ delete_insn (rtx insn)
NOTE_KIND (insn) = NOTE_INSN_DELETED_LABEL;
NOTE_DELETED_LABEL_NAME (insn) = name;
- if (bb_note != NULL_RTX NOTE_INSN_BASIC_BLOCK_P (bb_note)
- BLOCK_FOR_INSN (bb_note) == bb)
+ if (bb_note != NULL_RTX
+ NOTE_INSN_BASIC_BLOCK_P (bb_note))
+ bb = NOTE_BASIC_BLOCK (bb_note);
+
+ /* If the note following the label starts a basic block, and the
+ label is a member of the same basic block, interchange the two.
+ If the label is not marked with a bb, assume it's the same bb. */
+ if (bb != NULL
+ (bb == label_bb
+ || label_bb == NULL))
{
reorder_insns_nobb (insn, insn, bb_note);
BB_HEAD (bb) = bb_note;
Re: [PATCH] collect2 should accept more AIX linker flags to change shared library search order
On Mon, Feb 4, 2013 at 5:56 AM, Michael Haubenwallner michael.haubenwall...@salomon.at wrote: when using -shared -Wl,-G to create AIX shared libraries for use with runtime linking, without also using -Wl,-brtl collect2 still does search for lib.a before lib.so, eventually registering global constructors found in static lib.a, which are not exported by lib.so, so the subsequent link step fails resolving these symbols. This is OK if it's OK with the AIX maintainers (do we have any AIX maintainers? dje?). I'll also preapprove a patch to use strcmp and strncmp here, I have no idea why this code is checking character by character. Ian
[testsuite] commited: fix typo in 4.7 testsuite/lib/target-supports.exp
This patch fixes the typo reported in PR testsuite/56206. Checked in as
obvious.
Janis
2013-02-04 Janis Johnson jani...@codesourcery.com
PR testsuite/56206
* lib/target-supports.exp (check_effective_target_arm_hard_vfp_ok):
Fix typo.
Index: testsuite/lib/target-supports.exp
===
--- testsuite/lib/target-supports.exp (revision 195723)
+++ testsuite/lib/target-supports.exp (working copy)
@@ -2061,7 +2061,7 @@
# options.
proc check_effective_target_arm_hard_vfp_ok { } {
-if { [check_effective_target_arm32] } {
+if { [check_effective_target_arm32]
! [check-flags [list { *-*-* } { -mfloat-abi=* } {
-mfloat-abi=hard }]] } {
return [check_no_compiler_messages arm_hard_vfp_ok executable {
int main() { return 0;}
Re: [Patch, fortran] PR54107: ICE on recursive interfaces and PR54195: symbol bogusly inserted twice in the interface.
Le 04/02/2013 14:02, Mikael Morin a écrit :
The fix, as discussed in PR54195, adds a flag to mark a symbol as
resolved.
Why not add this flag directly to gfc_symbol instead of
symbol_attribute? It seems we do not need the attribute for components
(or do we?).
Hum, indeed. symbol_attribute, despite its name, also applies to
components :-/.
OK, I'll move the flag to gfc_symbol.
Committed as follows. revision 195729.
The other patch will follow.
Index: testsuite/gfortran.dg/recursive_interface_1.f90
===
--- testsuite/gfortran.dg/recursive_interface_1.f90 (révision 0)
+++ testsuite/gfortran.dg/recursive_interface_1.f90 (révision 195729)
@@ -0,0 +1,20 @@
+! { dg-do compile }
+!
+! PR fortran/54107
+! The compiler used to ICE on recursive interfaces.
+
+module m
+ contains
+ function foo() result(r1)
+procedure(foo), pointer :: r1
+ end function foo
+
+ function bar() result(r2)
+procedure(baz), pointer :: r2
+ end function bar
+
+ function baz() result(r3)
+procedure(bar), pointer :: r3
+ end function baz
+end module m
+
Index: testsuite/ChangeLog
===
--- testsuite/ChangeLog (révision 195728)
+++ testsuite/ChangeLog (révision 195729)
@@ -1,3 +1,8 @@
+2013-02-04 Mikael Morin mik...@gcc.gnu.org
+
+ PR fortran/54107
+ * gfortran.dg/recursive_interface_1.f90: New test.
+
2013-02-04 Richard Guenther rguent...@suse.de
PR lto/56168
@@ -97,7 +102,7 @@
* lib/target-supports-dg.exp (dg-process-target): Use expr to
evaluate the end index in string range.
-2012-01-30 Tobias Burnus bur...@net-b.de
+2013-01-30 Tobias Burnus bur...@net-b.de
PR fortran/56138
* gfortran.dg/allocatable_function_6.f90: New.
Index: fortran/gfortran.h
===
--- fortran/gfortran.h (révision 195728)
+++ fortran/gfortran.h (révision 195729)
@@ -1248,6 +1248,9 @@ typedef struct gfc_symbol
unsigned equiv_built:1;
/* Set if this variable is used as an index name in a FORALL. */
unsigned forall_index:1;
+ /* Used to avoid multiple resolutions of a single symbol. */
+ unsigned resolved:1;
+
int refs;
struct gfc_namespace *ns;/* namespace containing this symbol */
Index: fortran/ChangeLog
===
--- fortran/ChangeLog (révision 195728)
+++ fortran/ChangeLog (révision 195729)
@@ -1,3 +1,12 @@
+2013-02-04 Mikael Morin mik...@gcc.gnu.org
+
+ PR fortran/54107
+ PR fortran/54195
+ * gfortran.h (struct gfc_symbol): New field 'resolved'.
+ * resolve.c (resolve_fl_var_and_proc): Don't skip result symbols.
+ (resolve_symbol): Skip duplicate calls. Don't check the current
+ namespace.
+
2013-02-02 Thomas Koenig tkoe...@gcc.gnu.org
PR fortran/50627
@@ -7,7 +16,7 @@
* parse.c (parse_module): Do not put namespace into
gsymbol on error.
-2012-01-30 Tobias Burnus bur...@net-b.de
+2013-01-30 Tobias Burnus bur...@net-b.de
PR fortran/56138
* trans-decl.c (gfc_trans_deferred_vars): Fix deferred-length
@@ -214,7 +223,7 @@
finalizer_insert_packed_call, generate_finalization_wrapper):
Clean up by using gfc_build_intrinsic_call.
-2012-01-07 Tobias Burnus bur...@net-b.de
+2013-01-07 Tobias Burnus bur...@net-b.de
PR fortran/55763
* resolve.c (resolve_select_type): Reject intrinsic types for
Index: fortran/resolve.c
===
--- fortran/resolve.c (révision 195728)
+++ fortran/resolve.c (révision 195729)
@@ -11051,11 +11051,6 @@ resolve_fl_var_and_proc (gfc_symbol *sym, int mp_f
{
gfc_array_spec *as;
- /* Avoid double diagnostics for function result symbols. */
- if ((sym-result || sym-attr.result) !sym-attr.dummy
- (sym-ns != gfc_current_ns))
-return SUCCESS;
-
if (sym-ts.type == BT_CLASS sym-attr.class_ok)
as = CLASS_DATA (sym)-as;
else
@@ -13170,6 +13165,10 @@ resolve_symbol (gfc_symbol *sym)
gfc_array_spec *as;
bool saved_specification_expr;
+ if (sym-resolved)
+return;
+ sym-resolved = 1;
+
if (sym-attr.artificial)
return;
@@ -13779,7 +13778,6 @@ resolve_symbol (gfc_symbol *sym)
described in 14.7.5, to those variables that have not already
been assigned one. */
if (sym-ts.type == BT_DERIVED
- sym-ns == gfc_current_ns
!sym-value
!sym-attr.allocatable
!sym-attr.alloc_comp)
Re: [PATCH] fix PR sanitizer/55617
On Feb 4, 2013, at 6:22 AM, Jack Howarth howa...@bromo.med.uc.edu wrote: I switched to the simple insertion of the asan priorities for two reasons... 1) Mike seemed unconvinced that the single qsort with the proposed sort_ctor_records of… would really be stable in absence of a second call to qsort. This is wrong; a mis-understanding of my point. Since the latest patch is correct with respect to this point, it doesn't matter.
Re: Ping: unreviewed copyright patches
Ian Lance Taylor i...@google.com writes: On Sun, Feb 3, 2013 at 2:19 AM, Richard Sandiford rdsandif...@googlemail.com wrote: Not exactly the most exciting patches, and certainly not worth more than one ping, but: libgcc copyright http://gcc.gnu.org/ml/gcc-patches/2013-01/msg00642.html This is OK. Thanks! Don't these count as obvious at this point? Well, I think the idea behind asking me to send per-directory patches was so that people could check that I was updating the right things. OKness for one directory wouldn't really carry over to another. But I'm glad to say this is the last of the patches anyway. Richard
Re: [PATCH] fix PR sanitizer/55617 via qsort
On Feb 4, 2013, at 9:22 AM, Jack Howarth howa...@bromo.med.uc.edu wrote: Currently darwin is unable to utilize libasan with constructors due to the lack of constructor priority support on that target. Okay for gcc trunk? Since asan doesn't need cross translation unit priorities, the patch is sufficient to fix all of the semantics needed for asan. I still have a preference, though small, for stable_sort instead of qsort, absent performance data saying qsort is better. Ok. ps The issue of inter module priority support remains unresolved (as it is in clang/llvm). The only solution for both compilers is to reorder the linkage of the modules to insure that the module with the asan constructor appears first. Since asan doesn't care who goes first, we don't need priorities across translation units for it.
Re: [PATCH] fix PR sanitizer/55617 via qsort
On Feb 4, 2013, at 11:23 AM, Mike Stump m...@mrs.kithrup.com wrote: On Feb 4, 2013, at 9:22 AM, Jack Howarth howa...@bromo.med.uc.edu wrote: Currently darwin is unable to utilize libasan with constructors due to the lack of constructor priority support on that target. Okay for gcc trunk? Since asan doesn't need cross translation unit priorities, the patch is sufficient to fix all of the semantics needed for asan. I still have a preference, though small, for stable_sort instead of qsort, absent performance data saying qsort is better. Ok. Oh, if you could, could you qsort of the dtors as well. The code exactly mirrors the ctors code.
Re: [PATCH] fix PR sanitizer/55617
On Feb 4, 2013, at 1:38 AM, Jakub Jelinek ja...@redhat.com wrote: On Mon, Feb 04, 2013 at 10:22:48AM +0100, Richard Biener wrote: Okay for gcc trunk? But that does not work across translation units, no? ISTR collect2 has support to handle constructor priorities all by itself (at link time, considering all inputs). I wonder why the patch turned from initially at least supporting intra-CU support for ctor priorities into an ugly hack for asan. I guess asan doesn't care too much about inter-CU ctor priorities, it just needs its ctors to run before anything in the same CU is called (mainly the __asan_init call), other CUs either won't be asan instrumented, then it doesn't matter, or will be, but they will have their own __asan_init call. I wonder why darwin cannot use that mechanism to support init priorities? But sure, if collect2 can be used for full init prio support, the better. It would be nice if someone contributed full init_priority support… I'd be happy to review that. A good patch for that would add it to clang for darwin, and have gcc use that same mechanism so that we can interoperate nicely. Absent interoperability… I think it would be annoying, as then you have to have a binary incompatibility to fix the one that is wrong.
[committed] Add copyright update script to contrib/
...now that all the output has been approved.
Richard
contrib/
* update-copyright.pl: New file.
Index: contrib/update-copyright.pl
===
--- /dev/null 2013-01-15 19:11:41.843960094 +
+++ contrib/update-copyright.pl 2013-02-04 19:40:37.903547053 +
@@ -0,0 +1,766 @@
+#!/usr/bin/python
+#
+# Copyright (C) 2013 Free Software Foundation, Inc.
+#
+# This script is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 3, or (at your option)
+# any later version.
+
+# This script adjusts the copyright notices at the top of source files
+# so that they have the form:
+#
+# Copyright - Free Software Foundation, Inc.
+#
+# It doesn't change code that is known to be maintained elsewhere or
+# that carries a non-FSF copyright.
+#
+# The script also doesn't change testsuite files, except those in
+# libstdc++-v3. This is because libstdc++-v3 has a conformance testsuite,
+# while most tests in other directories are just things that failed at some
+# point in the past.
+#
+# Pass --this-year to the script if you want it to add the current year
+# to all applicable notices. Pass --quilt if you are using quilt and
+# want files to be added to the quilt before being changed.
+#
+# By default the script will update all directories for which the
+# output has been vetted. You can instead pass the names of individual
+# directories, including those that haven't been approved. So:
+#
+#update-copyright.pl --this-year
+#
+# is the command that would be used at the beginning of a year to update
+# all copyright notices (and possibly at other times to check whether
+# new files have been added with old years). On the other hand:
+#
+#update-copyright.pl --this-year libjava
+#
+# would run the script on just libjava/.
+#
+# Note that things like --version output strings must be updated before
+# this script is run. There's already a separate procedure for that.
+
+import os
+import re
+import sys
+import time
+import subprocess
+
+class Errors:
+def __init__ (self):
+self.num_errors = 0
+
+def report (self, filename, string):
+if filename:
+string = filename + ': ' + string
+sys.stderr.write (string + '\n')
+self.num_errors += 1
+
+def ok (self):
+return self.num_errors == 0
+
+class GenericFilter:
+def __init__ (self):
+self.skip_files = set()
+self.skip_dirs = set()
+self.skip_extensions = set()
+self.fossilised_files = set()
+self.own_files = set()
+
+self.skip_files |= set ([
+# Skip licence files.
+'COPYING',
+'COPYING.LIB',
+'COPYING3',
+'COPYING3.LIB',
+'LICENSE',
+'fdl.texi',
+'gpl_v3.texi',
+'fdl-1.3.xml',
+'gpl-3.0.xml',
+
+# Skip auto- and libtool-related files
+'aclocal.m4',
+'compile',
+'config.guess',
+'config.sub',
+'depcomp',
+'install-sh',
+'libtool.m4',
+'ltmain.sh',
+'ltoptions.m4',
+'ltsugar.m4',
+'ltversion.m4',
+'lt~obsolete.m4',
+'missing',
+'mkdep',
+'mkinstalldirs',
+'move-if-change',
+'shlibpath.m4',
+'symlink-tree',
+'ylwrap',
+
+# Skip FSF mission statement, etc.
+'gnu.texi',
+'funding.texi',
+'appendix_free.xml',
+
+# Skip imported texinfo files.
+'texinfo.tex',
+])
+
+
+def get_line_filter (self, dir, filename):
+if filename.startswith ('ChangeLog'):
+# Ignore references to copyright in changelog entries.
+return re.compile ('\t')
+
+return None
+
+def skip_file (self, dir, filename):
+if filename in self.skip_files:
+return True
+
+(base, extension) = os.path.splitext (os.path.join (dir, filename))
+if extension in self.skip_extensions:
+return True
+
+if extension == '.in':
+# Skip .in files produced by automake.
+if os.path.exists (base + '.am'):
+return True
+
+# Skip files produced by autogen
+if (os.path.exists (base + '.def')
+and os.path.exists (base + '.tpl')):
+return True
+
+# Skip configure files produced by autoconf
+if filename == 'configure':
+if os.path.exists (base + '.ac'):
+return True
+if os.path.exists (base +
Re: Ping: unreviewed copyright patches
On Mon, Feb 04, 2013 at 06:59:38PM +, Richard Sandiford wrote: These days the guideline encourage updating all files, even ones that haven't changed, so I was hoping we could do that gcc-wide. If that is what the guidelines say, then I will not object. I am just a bit surprised that you can claim copyright for a year in which the file is not modified. Cheers, Ben signature.asc Description: Digital signature
Re: [Google 4.7 Split Dwarf] Use .debug_str for some strings. (issue7241067)
@@ -22385,21 +22448,21 @@
static void
output_indirect_strings (void)
{
+ switch_to_section (debug_str_section);
if (!dwarf_split_debug_info)
-{
- switch_to_section (debug_str_section);
- htab_traverse (debug_str_hash, output_indirect_string, NULL);
-}
+htab_traverse (debug_str_hash, output_indirect_string, NULL);
else
{
unsigned int offset = 0;
unsigned int cur_idx = 0;
+ htab_traverse (skeleton_debug_str_hash, output_indirect_string, NULL);
+
switch_to_section (debug_str_offsets_section);
htab_traverse_noresize (debug_str_hash,
output_index_string_offset,
offset);
- switch_to_section (debug_str_section);
+ switch_to_section (debug_str_dwo_section);
htab_traverse_noresize (debug_str_hash,
output_index_string,
cur_idx);
Doesn't this routine now need to check to see if debug_str_hash and
skeleton_debug_str_hash are non-NULL individually? It gets called if
either is non-NULL, but what will happen if only one is NULL?
-cary
[wwwdocs] Buildstat update for 4.7
Latest results for 4.7.x -tgc Testresults for 4.7.2 arm-unknown-linux-gnueabi i686-pc-linux-gnu (2) mipsel-unknown-linux-gnu powerpc-unknown-linux-gnu sparc-unknown-linux-gnu x86_64-pc-solaris2.10 Index: buildstat.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.7/buildstat.html,v retrieving revision 1.7 diff -u -r1.7 buildstat.html --- buildstat.html 15 Dec 2012 08:23:55 - 1.7 +++ buildstat.html 4 Feb 2013 19:54:03 - @@ -51,6 +51,14 @@ /tr tr +tdarm-unknown-linux-gnueabi/td +tdnbsp;/td +tdTest results: +a href=http://gcc.gnu.org/ml/gcc-testresults/2013-01/msg01105.html;4.7.2/a +/td +/tr + +tr tdhppa2.0w-hp-hpux11.00/td tdnbsp;/td tdTest results: @@ -136,6 +144,8 @@ tdi686-pc-linux-gnu/td tdnbsp;/td tdTest results: +a href=http://gcc.gnu.org/ml/gcc-testresults/2013-01/msg01089.html;4.7.2/a, +a href=http://gcc.gnu.org/ml/gcc-testresults/2012-12/msg02518.html;4.7.2/a, a href=http://gcc.gnu.org/ml/gcc-testresults/2012-09/msg00199.html;4.7.1/a, a href=http://gcc.gnu.org/ml/gcc-testresults/2012-06/msg01316.html;4.7.1/a, a href=http://gcc.gnu.org/ml/gcc-testresults/2012-06/msg01315.html;4.7.1/a @@ -143,6 +153,14 @@ /tr tr +tdmipsel-unknown-linux-gnu/td +tdnbsp;/td +tdTest results: +a href=http://gcc.gnu.org/ml/gcc-testresults/2013-01/msg01258.html;4.7.2/a +/td +/tr + +tr tdpowerpc-apple-darwin8.11.0/td tdnbsp;/td tdTest results: @@ -153,6 +171,14 @@ /tr tr +tdpowerpc-unknown-linux-gnu/td +tdnbsp;/td +tdTest results: +a href=http://gcc.gnu.org/ml/gcc-testresults/2013-01/msg00946.html;4.7.2/a +/td +/tr + +tr tds390x-ibm-linux-gnu/td tdnbsp;/td tdTest results: @@ -194,6 +220,14 @@ /tr tr +tdsparc-unknown-linux-gnu/td +tdnbsp;/td +tdTest results: +a href=http://gcc.gnu.org/ml/gcc-testresults/2013-01/msg01529.html;4.7.2/a +/td +/tr + +tr tdx86_64-apple-darwin10.8.0/td tdnbsp;/td tdTest results: @@ -220,6 +254,14 @@ /tr tr +tdx86_64-pc-solaris2.10/td +tdnbsp;/td +tdTest results: +a href=http://gcc.gnu.org/ml/gcc-testresults/2012-12/msg00430.html;4.7.2/a +/td +/tr + +tr tdx86_64-unknown-linux-gnu/td tdnbsp;/td tdTest results:
Re: Ping: unreviewed copyright patches
On Mon, Feb 4, 2013 at 11:55 AM, Ben Elliston b...@air.net.au wrote: On Mon, Feb 04, 2013 at 06:59:38PM +, Richard Sandiford wrote: These days the guideline encourage updating all files, even ones that haven't changed, so I was hoping we could do that gcc-wide. If that is what the guidelines say, then I will not object. I am just a bit surprised that you can claim copyright for a year in which the file is not modified. I've wondered about the policy for years, except that I didn't consider it very important. The thinking now aligns with what I always thought: the copyright year is based on the work as a whole. Each individual file is not individually copyrighted, any more than pages and chapters are individually copyrighted. Its the whole book. If you update a chapter, the book copyright date is updated. Makes more sense to me. My issue is likely my issue: too many names are used for the fixincludes copyright notices. Oh, well. Cheers -Bruce
Re: [PATCH] fix PR sanitizer/55617 via qsort
On Feb 4, 2013, at 11:23 AM, Mike Stump m...@mrs.kithrup.com wrote: On Feb 4, 2013, at 9:22 AM, Jack Howarth howa...@bromo.med.uc.edu wrote: Currently darwin is unable to utilize libasan with constructors due to the lack of constructor priority support on that target. Okay for gcc trunk? Since asan doesn't need cross translation unit priorities, the patch is sufficient to fix all of the semantics needed for asan. Ok. Committed revision 195735. Note, this doesn't have the test case in it. Please repost just the test case, thanks.
Re: [PATCH] fix PR sanitizer/55617 via qsort
On Mon, Feb 04, 2013 at 12:12:36PM -0800, Mike Stump wrote:
On Feb 4, 2013, at 11:23 AM, Mike Stump m...@mrs.kithrup.com wrote:
On Feb 4, 2013, at 9:22 AM, Jack Howarth howa...@bromo.med.uc.edu wrote:
Currently darwin is unable to utilize libasan with constructors due to
the lack of
constructor priority support on that target.
Okay for gcc trunk?
Since asan doesn't need cross translation unit priorities, the patch is
sufficient to fix all of the semantics needed for asan.
Ok.
Committed revision 195735.
Note, this doesn't have the test case in it. Please repost just the test
case, thanks.
Mike,
Sorry about that. Complete patch with testcase attached. I am currently
testing
the dtors sorting.
Jack
/gcc
2013-02-04 Alexander Potapenko gli...@google.com
Jack Howarth howa...@bromo.med.uc.edu
Jakub Jelinek ja...@redhat.com
PR sanitizer/55617
* config/darwin.c (sort_ctor_records): Stabilized qsort
on constructor priority by using original position.
(finalize_ctors): New routine to sort constructors by
priority before use in assemble_integer.
(machopic_asm_out_constructor): Use finalize_ctors if needed.
/gcc/testsuite
2013-02-04 Alexander Potapenko gli...@google.com
Jack Howarth howa...@bromo.med.uc.edu
Jakub Jelinek ja...@redhat.com
PR sanitizer/55617
* g++.dg/asan/pr55617.C: New test.
Index: gcc/config/darwin.c
===
--- gcc/config/darwin.c (revision 195685)
+++ gcc/config/darwin.c (working copy)
@@ -83,6 +83,14 @@ along with GCC; see the file COPYING3.
kernel) the stubs might still be required, and this will be set true. */
int darwin_emit_branch_islands = false;
+typedef struct GTY(()) ctor_record {
+ rtx symbol;
+ int priority;/* constructor priority */
+ int position;/* original position */
+} ctor_record;
+
+static GTY(()) vecctor_record, va_gc *ctors = NULL;
+
/* A flag to determine whether we are running c++ or obj-c++. This has to be
settable from non-c-family contexts too (i.e. we can't use the c_dialect_
functions). */
@@ -1708,15 +1716,48 @@ machopic_select_rtx_section (enum machin
void
machopic_asm_out_constructor (rtx symbol, int priority ATTRIBUTE_UNUSED)
{
+ ctor_record new_elt = {symbol, priority, vec_safe_length (ctors)};
+
+ vec_safe_push (ctors, new_elt);
+
+ if (! MACHOPIC_INDIRECT)
+fprintf (asm_out_file, .reference .constructors_used\n);
+}
+
+static int
+sort_ctor_records (const void * a, const void * b)
+{
+ const ctor_record *ca = (const ctor_record *)a;
+ const ctor_record *cb = (const ctor_record *)b;
+ if (ca-priority cb-priority)
+return 1;
+ if (ca-priority cb-priority)
+return -1;
+ if (ca-position cb-position)
+return 1;
+ if (ca-position cb-position)
+return -1;
+ return 0;
+}
+
+static void
+finalize_ctors()
+{
+ unsigned int i;
+ ctor_record *elt;
+
if (MACHOPIC_INDIRECT)
switch_to_section (darwin_sections[mod_init_section]);
else
switch_to_section (darwin_sections[constructor_section]);
- assemble_align (POINTER_SIZE);
- assemble_integer (symbol, POINTER_SIZE / BITS_PER_UNIT, POINTER_SIZE, 1);
- if (! MACHOPIC_INDIRECT)
-fprintf (asm_out_file, .reference .constructors_used\n);
+ if (vec_safe_length (ctors) 1)
+ctors-qsort (sort_ctor_records);
+ FOR_EACH_VEC_SAFE_ELT (ctors, i, elt)
+{
+ assemble_align (POINTER_SIZE);
+ assemble_integer (elt-symbol, POINTER_SIZE / BITS_PER_UNIT,
POINTER_SIZE, 1);
+}
}
void
@@ -2762,6 +2803,8 @@ darwin_file_start (void)
void
darwin_file_end (void)
{
+ if (!vec_safe_is_empty (ctors))
+finalize_ctors();
machopic_finish (asm_out_file);
if (strcmp (lang_hooks.name, GNU C++) == 0)
{
--- /dev/null 2013-02-02 10:53:51.0 -0500
+++ gcc/testsuite/g++.dg/asan/pr55617.C 2013-02-02 10:22:17.0 -0500
@@ -0,0 +1,8 @@
+// { dg-do run { target { i?86-*-darwin* x86_64-*-darwin* } } }
+
+struct c18 {
+ virtual void bar() { }
+};
+c18 ret;
+int main () {
+}
Re: [v3] libstdc++/56202
... committed this follow up. See Audit trail for details.
Paolo.
//
2013-02-04 Manuel López-Ibáñez m...@gcc.gnu.org
Paolo Carlini paolo.carl...@oracle.com
PR libstdc++/56202 (again)
* include/bits/random.tcc (binomial_distribution::
_M_waiting(_UniformRandomNumberGenerator, _IntType)): Fix thinko
in previous commit.
* include/bits/random.h: Fix comment typo.
Index: include/bits/random.h
===
--- include/bits/random.h (revision 195721)
+++ include/bits/random.h (working copy)
@@ -3770,7 +3770,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
* @brief A discrete binomial random number distribution.
*
* The formula for the binomial probability density function is
- * @f$p(i|t,p) = \binom{n}{i} p^i (1 - p)^{t - i}@f$ where @f$t@f$
+ * @f$p(i|t,p) = \binom{t}{i} p^i (1 - p)^{t - i}@f$ where @f$t@f$
* and @f$p@f$ are the parameters of the distribution.
*/
templatetypename _IntType = int
Index: include/bits/random.tcc
===
--- include/bits/random.tcc (revision 195722)
+++ include/bits/random.tcc (working copy)
@@ -1657,13 +1657,9 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
do
{
+ if (__t == __x)
+ return __x;
const double __e = -std::log(1.0 - __aurng());
- if (__t == __x)
- {
- if (__e)
- return __x;
- continue;
- }
__sum += __e / (__t - __x);
__x += 1;
}
Re: [committed] Add copyright update script to contrib/
On 4 February 2013 20:42:55 Richard Sandiford rdsandif...@googlemail.com wrote: ...now that all the output has been approved. Richard contrib/ * update-copyright.pl: New file. Index: contrib/update-copyright.pl === --- /dev/null 2013-01-15 19:11:41.843960094 + +++ contrib/update-copyright.pl 2013-02-04 19:40:37.903547053 + @@ -0,0 +1,766 @@ +#!/usr/bin/python I find this slightly confusing ;) Cheers, Sent with AquaMail for Android http://www.aqua-mail.com
Re: Ping: unreviewed copyright patches
On Mon, Feb 04, 2013 at 12:12:14PM -0800, Bruce Korb wrote: If you update a chapter, the book copyright date is updated. Makes more sense to me. OK. That's fine with me, then. Cheers, Ben -- These man-made problems have man-made solutions. Unfortunately, the men and women needed to solve them are all politicians. -- Peter Hartcher signature.asc Description: Digital signature
Re: [committed] Add copyright update script to contrib/
Bernhard Reutner-Fischer rep.dot@gmail.com writes: On 4 February 2013 20:42:55 Richard Sandiford rdsandif...@googlemail.com wrote: ...now that all the output has been approved. Richard contrib/ * update-copyright.pl: New file. Index: contrib/update-copyright.pl === --- /dev/null2013-01-15 19:11:41.843960094 + +++ contrib/update-copyright.pl 2013-02-04 19:40:37.903547053 + @@ -0,0 +1,766 @@ +#!/usr/bin/python I find this slightly confusing ;) Hah! That'll teach me for renaming the thing just before committing. :-) Now renamed to update-copyright.py, thanks. Richard
Re: [PATCH] fix PR sanitizer/55617 via qsort
On Feb 4, 2013, at 12:24 PM, Jack Howarth howa...@bromo.med.uc.edu wrote: Complete patch with testcase attached. Thanks. Committed revision 195737.
Re: [Google 4.7 Split Dwarf] Use .debug_str for some strings. (issue7241067)
On Mon, Feb 4, 2013 at 11:56 AM, Cary Coutant ccout...@google.com wrote:
@@ -22385,21 +22448,21 @@
static void
output_indirect_strings (void)
{
+ switch_to_section (debug_str_section);
if (!dwarf_split_debug_info)
-{
- switch_to_section (debug_str_section);
- htab_traverse (debug_str_hash, output_indirect_string, NULL);
-}
+htab_traverse (debug_str_hash, output_indirect_string, NULL);
else
{
unsigned int offset = 0;
unsigned int cur_idx = 0;
+ htab_traverse (skeleton_debug_str_hash, output_indirect_string, NULL);
+
switch_to_section (debug_str_offsets_section);
htab_traverse_noresize (debug_str_hash,
output_index_string_offset,
offset);
- switch_to_section (debug_str_section);
+ switch_to_section (debug_str_dwo_section);
htab_traverse_noresize (debug_str_hash,
output_index_string,
cur_idx);
Doesn't this routine now need to check to see if debug_str_hash and
skeleton_debug_str_hash are non-NULL individually? It gets called if
either is non-NULL, but what will happen if only one is NULL?
Ahh, good catch. Fixed as attached.
Sterling
patch.diff
Description: Binary data
Re: [PATCH] collect2 should accept more AIX linker flags to change shared library search order
2013-02-04 Michael Haubenwallner michael.haubenwall...@salomon.at Accept all flags that enable aix runtime linking to change the library search order. Also there is a disabling flag. * collect2.c (aixrtl_flag): Enabled by -G and -bsvr4 too. Disabled by -bnortl. No false positive on -brtllib or -bnortllib. This patch is okay, and I agree that it should use strncmp. Do you have SVN write access? Thanks, David
Re: [Google 4.7 Split Dwarf] Use .debug_str for some strings. (issue7241067)
Ahh, good catch. Fixed as attached. Looks good, thanks. OK for the google/gcc-4_7 branch. (And, yes, please do port this to trunk when Stage 1 reopens.) -cary
[PATCH] fix PR sanitizer/55617 via qsort - dtors part
Mike,
Attached is the requested qsort on destructors as well. After gcc branches
for 4.8, I would imagine the first baby step towards full constructor/destructor
priority support would be to remove...
/* The Apple assembler and linker do not support constructor priorities. */
#undef SUPPORTS_INIT_PRIORITY
#define SUPPORTS_INIT_PRIORITY 0
from gcc/config/darwin.h and craft a way to suppress the emission of the
(con//de)structor priority assembly which darwin's gas doesn't understand.
That should be sufficient (with the qsorting by priority) to give us full
constructor/destructor priority support within a module.
Jack
ps Bootstrap tested on x86_64-apple-darwin12 with no regressions in
asan.exp. Will post full regression testresults tomorrow.
/gcc
2013-02-04 Alexander Potapenko gli...@google.com
Jack Howarth howa...@bromo.med.uc.edu
Jakub Jelinek ja...@redhat.com
PR sanitizer/55617
* config/darwin.c (sort_dtor_records): Stabilized qsort
on destructor priority by using original position.
(finalize_dtors): New routine to sort destructors by
priority before use in assemble_integer.
(machopic_asm_out_destructor): Use finalize_dtors if needed.
Index: gcc/config/darwin.c
===
--- gcc/config/darwin.c (revision 195735)
+++ gcc/config/darwin.c (working copy)
@@ -89,7 +89,14 @@ typedef struct GTY(()) ctor_record {
int position;/* original position */
} ctor_record;
+typedef struct GTY(()) dtor_record {
+ rtx symbol;
+ int priority;/* destructor priority */
+ int position;/* original position */
+} dtor_record;
+
static GTY(()) vecctor_record, va_gc *ctors = NULL;
+static GTY(()) vecdtor_record, va_gc *dtors = NULL;
/* A flag to determine whether we are running c++ or obj-c++. This has to be
settable from non-c-family contexts too (i.e. we can't use the c_dialect_
@@ -1724,6 +1731,17 @@ machopic_asm_out_constructor (rtx symbol
fprintf (asm_out_file, .reference .constructors_used\n);
}
+void
+machopic_asm_out_destructor (rtx symbol, int priority ATTRIBUTE_UNUSED)
+{
+ dtor_record new_elt = {symbol, priority, vec_safe_length (dtors)};
+
+ vec_safe_push (dtors, new_elt);
+
+ if (! MACHOPIC_INDIRECT)
+fprintf (asm_out_file, .reference .destructors_used\n);
+}
+
static int
sort_ctor_records (const void * a, const void * b)
{
@@ -1740,6 +1758,22 @@ sort_ctor_records (const void * a, const
return 0;
}
+static int
+sort_dtor_records (const void * a, const void * b)
+{
+ const dtor_record *da = (const dtor_record *)a;
+ const dtor_record *db = (const dtor_record *)b;
+ if (da-priority db-priority)
+return 1;
+ if (da-priority db-priority)
+return -1;
+ if (da-position db-position)
+return 1;
+ if (da-position db-position)
+return -1;
+ return 0;
+}
+
static void
finalize_ctors()
{
@@ -1760,18 +1794,24 @@ finalize_ctors()
}
}
-void
-machopic_asm_out_destructor (rtx symbol, int priority ATTRIBUTE_UNUSED)
+static void
+finalize_dtors()
{
+ unsigned int i;
+ dtor_record *elt;
+
if (MACHOPIC_INDIRECT)
switch_to_section (darwin_sections[mod_term_section]);
else
switch_to_section (darwin_sections[destructor_section]);
- assemble_align (POINTER_SIZE);
- assemble_integer (symbol, POINTER_SIZE / BITS_PER_UNIT, POINTER_SIZE, 1);
- if (! MACHOPIC_INDIRECT)
-fprintf (asm_out_file, .reference .destructors_used\n);
+ if (vec_safe_length (dtors) 1)
+dtors-qsort (sort_dtor_records);
+ FOR_EACH_VEC_SAFE_ELT (dtors, i, elt)
+{
+ assemble_align (POINTER_SIZE);
+ assemble_integer (elt-symbol, POINTER_SIZE / BITS_PER_UNIT,
POINTER_SIZE, 1);
+}
}
void
@@ -2805,6 +2845,8 @@ darwin_file_end (void)
{
if (!vec_safe_is_empty (ctors))
finalize_ctors();
+ if (!vec_safe_is_empty (dtors))
+finalize_dtors();
machopic_finish (asm_out_file);
if (strcmp (lang_hooks.name, GNU C++) == 0)
{
Re: [Google 4.7 Split Dwarf] Use .debug_str for some strings. (issue7241067)
On Mon, Feb 4, 2013 at 1:45 PM, Cary Coutant ccout...@google.com wrote: Ahh, good catch. Fixed as attached. Looks good, thanks. OK for the google/gcc-4_7 branch. (And, yes, please do port this to trunk when Stage 1 reopens.) Thanks. Committed.
Re: [Patch, fortran] PR56008 (and PR47517) [F03] wrong code with lhs-realloc on assignment with derived types having allocatable components
Committed revision 195741. Thanks for the review. Paul On 28 January 2013 22:18, Thomas Koenig tkoe...@netcologne.de wrote: Hi Paul, This patch is sufficiently straightforward that the ChangeLog entry describes it completely. The fix for both bugs lay in the nullification of the allocatable components of the newly (re)allocated array. I think this fix is OK for trunk, for the reasons you mentioned. I also think it is straightforward enough (bordering on the obvious, but only after having read it :-) that it does not carry too much risk of a regression. So yes, OK from my side, unless somebody speaks up really quickly. Thomas -- The knack of flying is learning how to throw yourself at the ground and miss. --Hitchhikers Guide to the Galaxy
Re: [PATCH] fix PR sanitizer/55617 via qsort
On Mon, Feb 04, 2013 at 03:24:41PM -0500, Jack Howarth wrote:
--- /dev/null 2013-02-02 10:53:51.0 -0500
+++ gcc/testsuite/g++.dg/asan/pr55617.C 2013-02-02 10:22:17.0
-0500
@@ -0,0 +1,8 @@
+// { dg-do run { target { i?86-*-darwin* x86_64-*-darwin* } } }
There is nothing darwin specific on the testcase, is it?
Thus it should be just
// { dg-do run }
+
+struct c18 {
+ virtual void bar() { }
+};
+c18 ret;
+int main () {
+}
Jakub
Re: [PATCH] fix PR sanitizer/55617 via qsort - dtors part
On Mon, Feb 04, 2013 at 04:58:02PM -0500, Jack Howarth wrote:
--- gcc/config/darwin.c (revision 195735)
+++ gcc/config/darwin.c (working copy)
@@ -89,7 +89,14 @@ typedef struct GTY(()) ctor_record {
int position; /* original position */
} ctor_record;
+typedef struct GTY(()) dtor_record {
+ rtx symbol;
+ int priority;/* destructor priority */
+ int position;/* original position */
+} dtor_record;
The type is the same, so I'd just rename ctor_record to cdtor_record
or similar.
@@ -1740,6 +1758,22 @@ sort_ctor_records (const void * a, const
return 0;
}
+static int
+sort_dtor_records (const void * a, const void * b)
+{
+ const dtor_record *da = (const dtor_record *)a;
+ const dtor_record *db = (const dtor_record *)b;
+ if (da-priority db-priority)
+return 1;
+ if (da-priority db-priority)
+return -1;
+ if (da-position db-position)
+return 1;
+ if (da-position db-position)
+return -1;
+ return 0;
+}
And with that you don't need a new comparison function.
static void
finalize_ctors()
Please fix up formatting, missing space before (.
{
@@ -1760,18 +1794,24 @@ finalize_ctors()
}
}
-void
-machopic_asm_out_destructor (rtx symbol, int priority ATTRIBUTE_UNUSED)
+static void
+finalize_dtors()
And here too.
Jakub
Go patch committed: Always initialize nested_off
In PR 56198 Jakub points out that Import_archive::interpret_header did
not always initialized nested_off. This could never be an actual
problem, as nested_off was always set when an archive member might be
used. But it caused a compilation warning. Fixed with this patch.
Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu.
Committed to mainline.
Ian
diff -r 2c7569fc43a1 go/import-archive.cc
--- a/go/import-archive.cc Sat Feb 02 07:38:09 2013 -0800
+++ b/go/import-archive.cc Mon Feb 04 17:06:37 2013 -0800
@@ -277,6 +277,7 @@
return false;
}
+ *nested_off = 0;
if (hdr-ar_name[0] != '/')
{
const char* name_end = strchr(hdr-ar_name, '/');
@@ -288,7 +289,6 @@
return false;
}
pname-assign(hdr-ar_name, name_end - hdr-ar_name);
- *nested_off = 0;
}
else if (hdr-ar_name[1] == ' ')
{
@@ -327,8 +327,7 @@
return false;
}
pname-assign(name, name_end - 1 - name);
- if (nested_off != NULL)
-*nested_off = y;
+ *nested_off = y;
}
return true;
Re: [PATCH] Fix thinko in handle_error_attribute (PR middle-end/56167)
On Mon, 4 Feb 2013, Jakub Jelinek wrote: Hi! Without this fix, we were letting in invalid error/warning attributes, on function decls in addition to valid ones with STRING_CST argument also attributes with various bogus arguments, and for e.g. VAR_DECLs which shouldn't have any error/warning attributes those with STRING_CST arguments. Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? OK. -- Joseph S. Myers jos...@codesourcery.com
[PATCH][Revised] fix PR sanitizer/55617 via qsort - dtors part
Attached is the revised patch to sort destructors within code modules
by priority on darwin. The patch now uses a common cdtor_record structure
type and renamed sort_cdtor_records routine. Other misc. formatting issues
are addressed as well as well as enabling the g++.dg/asan/pr55617.C test
on all targets. Bootstrap tested on x86_64-apple-darwin12 with no
regressions in the asan.exp tests. Okay for gcc trunk after regression
testing?
Jack
/gcc
2013-02-04 Alexander Potapenko gli...@google.com
Jack Howarth howa...@bromo.med.uc.edu
Jakub Jelinek ja...@redhat.com
PR sanitizer/55617
* config/darwin.c (cdtor_record): Rename ctor_record.
(sort_cdtor_records): Rename sort_ctor_records.
(finalize_dtors): New routine to sort destructors by
priority before use in assemble_integer.
(machopic_asm_out_destructor): Use finalize_dtors if needed.
/gcc/testsuite
2013-02-04 Alexander Potapenko gli...@google.com
Jack Howarth howa...@bromo.med.uc.edu
Jakub Jelinek ja...@redhat.com
PR sanitizer/55617
* g++.dg/asan/pr55617.C: Run on all targets.
Index: gcc/testsuite/g++.dg/asan/pr55617.C
===
--- gcc/testsuite/g++.dg/asan/pr55617.C (revision 195743)
+++ gcc/testsuite/g++.dg/asan/pr55617.C (working copy)
@@ -1,4 +1,4 @@
-// { dg-do run { target { i?86-*-darwin* x86_64-*-darwin* } } }
+// { dg-do run }
struct c18 {
virtual void bar() { }
Index: gcc/config/darwin.c
===
--- gcc/config/darwin.c (revision 195743)
+++ gcc/config/darwin.c (working copy)
@@ -83,13 +83,14 @@ along with GCC; see the file COPYING3.
kernel) the stubs might still be required, and this will be set true. */
int darwin_emit_branch_islands = false;
-typedef struct GTY(()) ctor_record {
+typedef struct GTY(()) cdtor_record {
rtx symbol;
- int priority;/* constructor priority */
+ int priority;/* [con/de]structor priority */
int position;/* original position */
-} ctor_record;
+} cdtor_record;
-static GTY(()) vecctor_record, va_gc *ctors = NULL;
+static GTY(()) veccdtor_record, va_gc *ctors = NULL;
+static GTY(()) veccdtor_record, va_gc *dtors = NULL;
/* A flag to determine whether we are running c++ or obj-c++. This has to be
settable from non-c-family contexts too (i.e. we can't use the c_dialect_
@@ -1716,7 +1717,7 @@ machopic_select_rtx_section (enum machin
void
machopic_asm_out_constructor (rtx symbol, int priority ATTRIBUTE_UNUSED)
{
- ctor_record new_elt = {symbol, priority, vec_safe_length (ctors)};
+ cdtor_record new_elt = {symbol, priority, vec_safe_length (ctors)};
vec_safe_push (ctors, new_elt);
@@ -1724,27 +1725,38 @@ machopic_asm_out_constructor (rtx symbol
fprintf (asm_out_file, .reference .constructors_used\n);
}
+void
+machopic_asm_out_destructor (rtx symbol, int priority ATTRIBUTE_UNUSED)
+{
+ cdtor_record new_elt = {symbol, priority, vec_safe_length (dtors)};
+
+ vec_safe_push (dtors, new_elt);
+
+ if (! MACHOPIC_INDIRECT)
+fprintf (asm_out_file, .reference .destructors_used\n);
+}
+
static int
-sort_ctor_records (const void * a, const void * b)
+sort_cdtor_records (const void * a, const void * b)
{
- const ctor_record *ca = (const ctor_record *)a;
- const ctor_record *cb = (const ctor_record *)b;
- if (ca-priority cb-priority)
+ const cdtor_record *cda = (const cdtor_record *)a;
+ const cdtor_record *cdb = (const cdtor_record *)b;
+ if (cda-priority cdb-priority)
return 1;
- if (ca-priority cb-priority)
+ if (cda-priority cdb-priority)
return -1;
- if (ca-position cb-position)
+ if (cda-position cdb-position)
return 1;
- if (ca-position cb-position)
+ if (cda-position cdb-position)
return -1;
return 0;
}
static void
-finalize_ctors()
+finalize_ctors ()
{
unsigned int i;
- ctor_record *elt;
+ cdtor_record *elt;
if (MACHOPIC_INDIRECT)
switch_to_section (darwin_sections[mod_init_section]);
@@ -1752,7 +1764,7 @@ finalize_ctors()
switch_to_section (darwin_sections[constructor_section]);
if (vec_safe_length (ctors) 1)
-ctors-qsort (sort_ctor_records);
+ctors-qsort (sort_cdtor_records);
FOR_EACH_VEC_SAFE_ELT (ctors, i, elt)
{
assemble_align (POINTER_SIZE);
@@ -1760,18 +1772,24 @@ finalize_ctors()
}
}
-void
-machopic_asm_out_destructor (rtx symbol, int priority ATTRIBUTE_UNUSED)
+static void
+finalize_dtors ()
{
+ unsigned int i;
+ cdtor_record *elt;
+
if (MACHOPIC_INDIRECT)
switch_to_section (darwin_sections[mod_term_section]);
else
switch_to_section (darwin_sections[destructor_section]);
- assemble_align (POINTER_SIZE);
- assemble_integer (symbol, POINTER_SIZE / BITS_PER_UNIT, POINTER_SIZE, 1);
- if (! MACHOPIC_INDIRECT)
-fprintf (asm_out_file,
Re: [PATCH][Revised] fix PR sanitizer/55617 via qsort - dtors part
On Mon, Feb 04, 2013 at 08:58:45PM -0500, Jack Howarth wrote:
Attached is the revised patch to sort destructors within code modules
by priority on darwin. The patch now uses a common cdtor_record structure
type and renamed sort_cdtor_records routine. Other misc. formatting issues
are addressed as well as well as enabling the g++.dg/asan/pr55617.C test
on all targets. Bootstrap tested on x86_64-apple-darwin12 with no
regressions in the asan.exp tests. Okay for gcc trunk after regression
testing?
Jack
FYI, adding in the additional patch...
Index: gcc/config/darwin.h
===
--- gcc/config/darwin.h (revision 195747)
+++ gcc/config/darwin.h (working copy)
@@ -912,9 +912,8 @@ extern void darwin_driver_init (unsigned
darwin_driver_init (decoded_options_count, decoded_options)
#endif
-/* The Apple assembler and linker do not support constructor priorities. */
-#undef SUPPORTS_INIT_PRIORITY
-#define SUPPORTS_INIT_PRIORITY 0
+/* While Apple assembler and linker do not support constructor priorities,
+intra-module priority support is available via sort_cdtor_records. */
/* When building cross-compilers (and native crosses) we shall default to
providing an osx-version-min of this unless overridden by the User. */
bootstraps fine on x86_64-apple-darwin12 and now can compile the testcase
g++.dg/special/initpri1.C without errors and the resulting binary
runs fine. This change would put us on parity with clang++ that also only
supports intra-module constructor/destructor priorities. Also, I checked with
'grep -R PRIORIT *; in libstdc++ and I don't see any defines suggesting that
libstdc++ uses constructor/destructor priorities yet. I'll run a make check
and see how many test cases we need to XFAIL for this change.
Jack
/gcc
2013-02-04 Alexander Potapenko gli...@google.com
Jack Howarth howa...@bromo.med.uc.edu
Jakub Jelinek ja...@redhat.com
PR sanitizer/55617
* config/darwin.c (cdtor_record): Rename ctor_record.
(sort_cdtor_records): Rename sort_ctor_records.
(finalize_dtors): New routine to sort destructors by
priority before use in assemble_integer.
(machopic_asm_out_destructor): Use finalize_dtors if needed.
/gcc/testsuite
2013-02-04 Alexander Potapenko gli...@google.com
Jack Howarth howa...@bromo.med.uc.edu
Jakub Jelinek ja...@redhat.com
PR sanitizer/55617
* g++.dg/asan/pr55617.C: Run on all targets.
Index: gcc/testsuite/g++.dg/asan/pr55617.C
===
--- gcc/testsuite/g++.dg/asan/pr55617.C (revision 195743)
+++ gcc/testsuite/g++.dg/asan/pr55617.C (working copy)
@@ -1,4 +1,4 @@
-// { dg-do run { target { i?86-*-darwin* x86_64-*-darwin* } } }
+// { dg-do run }
struct c18 {
virtual void bar() { }
Index: gcc/config/darwin.c
===
--- gcc/config/darwin.c (revision 195743)
+++ gcc/config/darwin.c (working copy)
@@ -83,13 +83,14 @@ along with GCC; see the file COPYING3.
kernel) the stubs might still be required, and this will be set true. */
int darwin_emit_branch_islands = false;
-typedef struct GTY(()) ctor_record {
+typedef struct GTY(()) cdtor_record {
rtx symbol;
- int priority; /* constructor priority */
+ int priority; /* [con/de]structor priority */
int position; /* original position */
-} ctor_record;
+} cdtor_record;
-static GTY(()) vecctor_record, va_gc *ctors = NULL;
+static GTY(()) veccdtor_record, va_gc *ctors = NULL;
+static GTY(()) veccdtor_record, va_gc *dtors = NULL;
/* A flag to determine whether we are running c++ or obj-c++. This has to be
settable from non-c-family contexts too (i.e. we can't use the c_dialect_
@@ -1716,7 +1717,7 @@ machopic_select_rtx_section (enum machin
void
machopic_asm_out_constructor (rtx symbol, int priority ATTRIBUTE_UNUSED)
{
- ctor_record new_elt = {symbol, priority, vec_safe_length (ctors)};
+ cdtor_record new_elt = {symbol, priority, vec_safe_length (ctors)};
vec_safe_push (ctors, new_elt);
@@ -1724,27 +1725,38 @@ machopic_asm_out_constructor (rtx symbol
fprintf (asm_out_file, .reference .constructors_used\n);
}
+void
+machopic_asm_out_destructor (rtx symbol, int priority ATTRIBUTE_UNUSED)
+{
+ cdtor_record new_elt = {symbol, priority, vec_safe_length (dtors)};
+
+ vec_safe_push (dtors, new_elt);
+
+ if (! MACHOPIC_INDIRECT)
+fprintf (asm_out_file, .reference .destructors_used\n);
+}
+
static int
-sort_ctor_records (const void * a, const void * b)
+sort_cdtor_records (const void * a, const void * b)
{
- const ctor_record *ca = (const ctor_record *)a;
- const ctor_record *cb = (const ctor_record *)b;
- if (ca-priority cb-priority)
+
Re: [PR 54051 ARM] Fix alignment specifier alignment information for ARM.
Ramana, This issue also impacts ldrexh/ldrexb, as assembler doesn't accept ldrexh r1, [r0, #0]. May it be backported to 4.7 by now? Thanks - Joey On Tue, Jul 24, 2012 at 8:09 PM, Ramana Radhakrishnan ramana.radhakrish...@linaro.org wrote: Hi , While testing my neon intrinsics work with some testcases that I was writing up, I ran into PR54051 . The one change which is probably a bit long standing is the fact that for register only addressing modes i.e. something like mem (reg:SI) we were printing out addresses with an immediate of #0. Historically the reason for this appears to be to deal with an assembler bug of yesteryears where the assembler couldn't sometimes properly distinguish between auto-inc addressing forms and the register indirect addressing form which I'm informed is fixed. This patch has gone through a full test run with qemu in a cross environment with no regressions for armv7-a / neon / arm/ thumb with a v5t multilib for c, c++ . I intend to backport this to 4.7 as this is a regression compared to 4.6, after letting it be on trunk for a few days to see if the auto-testers pick anything else up unless there is an objection from anyone. regards Ramana PR target/54051 * config/arm/arm.c (arm_print_operand_address): Remove superfluous printing of #0. * config/arm/neon.md (neon_vld3_lanemode:VD): Remove alignment specifier. (neon_vld3_lanemode:VMQ): Likewise. (neon_vld3_dupmode:VDX): Likewise. (neon_vst3_lanemode:VD): Likewise. (neon_vst3_lanemode:VMQ): Likewise. PR target/54051 * gcc.target/arm/pr54051.c: New. * gcc.target/arm/vfp-1.c: Adjust test.
