Re: [Patch, Fortran] PR55763 - Fix MOVE_ALLOC with CLASS(*)
Dear Tobias, That's fine - OK for trunk. Thanks for the patch! Paul On 27 December 2012 23:16, Tobias Burnus wrote: > *ping* > > http://gcc.gnu.org/ml/fortran/2012-12/msg00167.html > > Tobias Burnus: > >> Fix one of the remaining issues of PR 55763: MOVE_ALLOC with CLASS(*) >> either for both arguments or only for TO=. >> >> Build and regtested on x86-64-gnu-linux. >> OK for the trunk? >> >> Tobias > > -- The knack of flying is learning how to throw yourself at the ground and miss. --Hitchhikers Guide to the Galaxy
[Patch, Fortran] PR 55692: ICE on incorrect use of ASSOCIATED function
Hi all, here is a close-to-obvious patch for an ICE-on-invalid problem with ASSOCIATED: The relevant checks to catch the error were already there, but were not reached due to a gcc_assert(0) appearing earlier. The patch basically just removes the gcc_assert. Regtested on x86_64-unknown-linux-gnu. Ok for trunk? Cheers, Janus 2012-12-28 Janus Weil PR fortran/55692 * check.c (gfc_check_associated): Remove a "gcc_assert (0)". 2012-12-28 Janus Weil PR fortran/55692 * gfortran.dg/associated_7.f90: New. pr55692.diff Description: Binary data associated_7.f90 Description: Binary data
Re: [RFC PATCH] Implementing ifunc target hook
Joseph, Maxim, thank you for your input. I converted this macro into
a target hook as you said. I had to add gcc/config/linux-protos.h in order
to declare linux (that works for android) version of this hook - otherwise
I don't know where to declare it..
>> --- a/gcc/config/i386/i386.c
>> +++ b/gcc/config/i386/i386.c
>> @@ -29146,7 +29146,7 @@ make_name (tree decl, const char *suffix, bool
>> make_unique)
>>return global_var_name;
>> }
>>
>> -#if defined (ASM_OUTPUT_TYPE_DIRECTIVE) && HAVE_GNU_INDIRECT_FUNCTION
>> +#if defined (ASM_OUTPUT_TYPE_DIRECTIVE)
>>
>> /* Make a dispatcher declaration for the multi-versioned function DECL.
>> Calls to DECL function will be replaced with calls to the dispatcher
>> @@ -29213,7 +29213,7 @@ ix86_get_function_versions_dispatcher (void *decl)
>>
>>tree dispatch_decl = NULL;
>>
>> -#if defined (ASM_OUTPUT_TYPE_DIRECTIVE) && HAVE_GNU_INDIRECT_FUNCTION
>> +#if defined (ASM_OUTPUT_TYPE_DIRECTIVE)
>>struct cgraph_function_version_info *it_v = NULL;
>>struct cgraph_node *dispatcher_node = NULL;
>>struct cgraph_function_version_info *dispatcher_version_info = NULL;
>
>It seems you can move these variables inside the 'if (TARGET_HAS_IFUNC)'
>clause below and make >the code cleaner, no?
All variable declarations should be at the beginning of the routine.
Or is it changed right now?
>> @@ -29263,24 +29263,33 @@ ix86_get_function_versions_dispatcher (void *decl)
>>
>>default_node = default_version_info->this_node;
>>
>> -#if defined (ASM_OUTPUT_TYPE_DIRECTIVE) && HAVE_GNU_INDIRECT_FUNCTION
>> - /* Right now, the dispatching is done via ifunc. */
>> - dispatch_decl = make_dispatcher_decl (default_node->symbol.decl);
>> -
>> - dispatcher_node = cgraph_get_create_node (dispatch_decl);
>> - gcc_assert (dispatcher_node != NULL);
>> - dispatcher_node->dispatcher_function = 1;
>> - dispatcher_version_info
>> -= insert_new_cgraph_node_version (dispatcher_node);
>> - dispatcher_version_info->next = default_version_info;
>> - dispatcher_node->local.finalized = 1;
>> -
>> - /* Set the dispatcher for all the versions. */
>> - it_v = default_version_info;
>> - while (it_v->next != NULL)
>> +#if defined (ASM_OUTPUT_TYPE_DIRECTIVE)
>> + if (TARGET_HAS_IFUNC)
>> +{
>> + /* Right now, the dispatching is done via ifunc. */
>> + dispatch_decl = make_dispatcher_decl (default_node->symbol.decl);
>> +
>> + dispatcher_node = cgraph_get_create_node (dispatch_decl);
>> + gcc_assert (dispatcher_node != NULL);
>> + dispatcher_node->dispatcher_function = 1;
>> + dispatcher_version_info
>> + = insert_new_cgraph_node_version (dispatcher_node);
>> + dispatcher_version_info->next = default_version_info;
>> + dispatcher_node->local.finalized = 1;
>> +
>> + /* Set the dispatcher for all the versions. */
>> + it_v = default_version_info;
>> + while (it_v->next != NULL)
>> + {
>> + it_v->dispatcher_resolver = dispatch_decl;
>> + it_v = it_v->next;
>> + }
>> +}
>> + else
>> {
>> - it_v->dispatcher_resolver = dispatch_decl;
>> - it_v = it_v->next;
>> + error_at (DECL_SOURCE_LOCATION (default_node->symbol.decl),
>> + "multiversioning needs ifunc which is not supported "
>> + "on this target");
>> }
>
>This looks wrong. Before the patch this code would be ignored if
>!HAVE_GNU_INDIRECT_FUNCTION and after the patch it will produce an error.
>Removing the else-clause should fix this.
Mmm, I believe that we want this code not to be ignored, because we
want it to produces an error
if the target does not support ifuncs and we are compiling something
that uses ifuncs.. May be I
missed something..
>Please use same error message in both error cases. It seems you can just
>convert '#else' >preprocessor clause into 'else' code clause without touching
>the error_at() statement beyond >indentation updates.
Done.
thank you,
Alexander
2012/12/28 Maxim Kuvyrkov :
> On 27/12/2012, at 1:15 AM, Alexander Ivchenko wrote:
>
>> Hi,
>>
>> Currently Android dynamic loader does not support indirect functions
>> (And I don't think that
>> it will someday). But there is no way for us to specify that for gcc,
>> and for example, tests like
>> gcc.dg/attr-ifunc-* are failing on android right now.
>> The attached patch is indended to add the target hook for indicating
>> the support of ifunc on target.
>
> The idea behind the patch looks OK, but implementation needs a bit of
> tweaking.
>
> As Joseph mentioned, you need to convert this macro into a target hook. GCC
> is making a gradual transition away from target macros to target hook
> functions, and all new hooks should be added as functions, unless there is a
> compelling argument to make it a macro. For an example of adding a target
> hook function see rev 194608 (among many others).
>
>> --- a/gcc/config/i386/i386.c
>> +++ b/gcc/config/i386/i386.c
>> @@ -29146,7 +29146,7 @@ make_name (tre
Re: [RFC, x86] Changes for AVX and AVX2 processors
Hello! > New processors core-avx and core-avx2 are added. It was done to have > possibilities to turn new features on for these processors. Please review. I don't think this is a good approach, you are mixing an architecture with an ISA extension in the name. We already have processor_alias_table, where processor architecture and features (extensions) can be activated, depending on the name. Uros.
Re: [Patch, Fortran] PR 55692: ICE on incorrect use of ASSOCIATED function
Hi Janus, Janus Weil wrote: here is a close-to-obvious patch for an ICE-on-invalid problem with ASSOCIATED: The relevant checks to catch the error were already there, but were not reached due to a gcc_assert(0) appearing earlier. The patch basically just removes the gcc_assert. Regtested on x86_64-unknown-linux-gnu. Ok for trunk? OK. Thanks for the patch. Regards, Tobias 2012-12-28 Janus Weil PR fortran/55692 * check.c (gfc_check_associated): Remove a "gcc_assert (0)". 2012-12-28 Janus Weil PR fortran/55692 * gfortran.dg/associated_7.f90: New.
Re: [patch] std::unique_ptr improvements
On 28 December 2012 01:51, Lawrence Crowl wrote:
>
> I'm not getting errors when converting from derived to base.
> E.g. the following compiles, when it should not.
>
> std::unique_ptr acb_ad(new derived[3]);
I get an error:
shm$ cat up.cc
#include
struct base { };
struct derived : base { virtual ~derived() = default; };
std::unique_ptr acb_ad(new derived[3]);
shm$
shm$ g++11 up.cc -c
up.cc:4:53: error: use of deleted function ‘std::unique_ptr<_Tp [],
_Dp>::unique_ptr(_Up*) [with _Up = derived; =
void; _Tp = const base; _Dp = std::default_delete]’
std::unique_ptr acb_ad(new derived[3]);
^
In file included from /home/redi/gcc/4.x/include/c++/4.8.0/memory:81:0,
from up.cc:1:
/home/redi/gcc/4.x/include/c++/4.8.0/bits/unique_ptr.h:343:2: error:
declared here
unique_ptr(_Up* __p) = delete;
^
Re: [Patch, Fortran] PR 55692: ICE on incorrect use of ASSOCIATED function
>> here is a close-to-obvious patch for an ICE-on-invalid problem with >> ASSOCIATED: The relevant checks to catch the error were already there, >> but were not reached due to a gcc_assert(0) appearing earlier. The >> patch basically just removes the gcc_assert. >> >> Regtested on x86_64-unknown-linux-gnu. Ok for trunk? Thanks, Tobias. Committed as r194744. Cheers, Janus >> 2012-12-28 Janus Weil >> >> PR fortran/55692 >> * check.c (gfc_check_associated): Remove a "gcc_assert (0)". >> >> 2012-12-28 Janus Weil >> >> PR fortran/55692 >> * gfortran.dg/associated_7.f90: New. > >
Results for 4.8.0 20121228 (experimental) [trunk revision 194742] (GCC) testsuite on powerpc-ibm-aix7.1.0.0
LAST_UPDATED: Fri Dec 28 02:23:12 UTC 2012 (revision 194742) Native configuration is powerpc-ibm-aix7.1.0.0 === g++ tests === Running target unix FAIL: g++.dg/bprob/g++-bprob-2.C compilation, -g -fbranch-probabilities UNRESOLVED: g++.dg/bprob/g++-bprob-2.C execution,-g -fbranch-probabilities FAIL: g++.dg/bprob/g++-bprob-2.C compilation, -O0 -fbranch-probabilities UNRESOLVED: g++.dg/bprob/g++-bprob-2.C execution,-O0 -fbranch-probabilities FAIL: g++.dg/bprob/g++-bprob-2.C compilation, -O1 -fbranch-probabilities UNRESOLVED: g++.dg/bprob/g++-bprob-2.C execution,-O1 -fbranch-probabilities FAIL: g++.dg/bprob/g++-bprob-2.C compilation, -O2 -fbranch-probabilities UNRESOLVED: g++.dg/bprob/g++-bprob-2.C execution,-O2 -fbranch-probabilities FAIL: g++.dg/bprob/g++-bprob-2.C compilation, -O3 -fbranch-probabilities UNRESOLVED: g++.dg/bprob/g++-bprob-2.C execution,-O3 -fbranch-probabilities FAIL: g++.dg/bprob/g++-bprob-2.C compilation, -O3 -g -fbranch-probabilities UNRESOLVED: g++.dg/bprob/g++-bprob-2.C execution,-O3 -g -fbranch-probabilities FAIL: g++.dg/bprob/g++-bprob-2.C compilation, -Os -fbranch-probabilities UNRESOLVED: g++.dg/bprob/g++-bprob-2.C execution,-Os -fbranch-probabilities FAIL: tmpdir-g++.dg-struct-layout-1/t024 cp_compat_x_tst.o-cp_compat_y_tst.o execute FAIL: tmpdir-g++.dg-struct-layout-1/t026 cp_compat_x_tst.o-cp_compat_y_tst.o execute FAIL: tmpdir-g++.dg-struct-layout-1/t028 cp_compat_x_tst.o-cp_compat_y_tst.o execute FAIL: tmpdir-g++.dg-struct-layout-1/t029 cp_compat_x_tst.o-cp_compat_y_tst.o execute FAIL: tmpdir-g++.dg-struct-layout-1/t030 cp_compat_x_tst.o-cp_compat_y_tst.o execute FAIL: g++.dg/abi/anon1.C -std=c++98 scan-assembler-not globl FAIL: g++.dg/abi/anon1.C -std=c++11 scan-assembler-not globl FAIL: g++.dg/abi/vtt1.C -std=c++98 scan-assembler _ZTT1B FAIL: g++.dg/abi/vtt1.C -std=c++11 scan-assembler _ZTT1B FAIL: g++.dg/cpp/ucn-1.C (test for excess errors) FAIL: g++.dg/cpp0x/constexpr-53094-2.C (test for excess errors) FAIL: g++.dg/cpp0x/constexpr-53094-3.C (test for excess errors) FAIL: g++.dg/cpp0x/constexpr-55573.C (test for excess errors) FAIL: g++.dg/ext/alignof2.C -std=c++98 execution test FAIL: g++.dg/ext/alignof2.C -std=c++11 execution test FAIL: g++.dg/ext/visibility/anon1.C -std=c++98 scan-assembler-not globl.*_ZN.*1fEv FAIL: g++.dg/ext/visibility/anon1.C -std=c++11 scan-assembler-not globl.*_ZN.*1fEv FAIL: g++.dg/ext/visibility/anon2.C -std=c++98 scan-assembler-not globl.*_Z1fv FAIL: g++.dg/ext/visibility/anon2.C -std=c++11 scan-assembler-not globl.*_Z1fv FAIL: g++.dg/init/new40.C -std=c++98 execution test FAIL: g++.dg/init/new40.C -std=c++11 execution test FAIL: g++.dg/other/pr55650.C -std=gnu++98 (test for excess errors) FAIL: g++.dg/other/pr55650.C -std=gnu++11 (test for excess errors) FAIL: g++.dg/template/linkage1.C -std=c++11 scan-assembler-not (weak|glob)[^\\n]*_Z3fooIXadL_ZL11static_funcvEEEvv FAIL: g++.dg/warn/pr31246.C -std=gnu++98 (test for excess errors) FAIL: g++.dg/warn/pr31246.C -std=gnu++11 (test for excess errors) FAIL: g++.dg/gomp/tls-5.C -std=c++11 scan-assembler-not .data FAIL: g++.dg/tls/thread_local1.C scan-assembler-not .comm FAIL: g++.dg/tls/thread_local3.C -std=gnu++11 (test for excess errors) WARNING: g++.dg/tls/thread_local3.C -std=gnu++11 compilation failed to produce executable FAIL: g++.dg/tls/thread_local4.C -std=gnu++11 (test for excess errors) WARNING: g++.dg/tls/thread_local4.C -std=gnu++11 compilation failed to produce executable FAIL: g++.dg/tls/thread_local5.C -std=gnu++11 (test for excess errors) WARNING: g++.dg/tls/thread_local5.C -std=gnu++11 compilation failed to produce executable FAIL: g++.dg/tls/thread_local6.C (test for excess errors) WARNING: g++.dg/tls/thread_local6.C compilation failed to produce executable FAIL: g++.dg/tls/thread_local7.C scan-assembler-not .data FAIL: g++.dg/tls/thread_local7g.C scan-assembler-not .data FAIL: g++.old-deja/g++.mike/p8018.C -std=c++98 (test for excess errors) WARNING: g++.old-deja/g++.mike/p8018.C -std=c++98 compilation failed to produce executable XPASS: g++.old-deja/g++.other/init19.C -std=c++98 execution test XPASS: g++.old-deja/g++.other/init19.C -std=c++11 execution test === g++ Summary === # of expected passes45384 # of unexpected failures42 # of unexpected successes 2 # of expected failures 315 # of unresolved testcases 7 # of unsupported tests 971 /tmp/20121227/gcc/testsuite/g++/../../xg++ version 4.8.0 20121228 (experimental) [trunk revision 194742] (GCC) === gcc tests === Running target unix FAIL: gcc.c-torture/execute/loop-5.c compilation, -O3 -fomit-frame-pointer -funroll-loops UNRESOLVED: gcc.c-torture/execute/loop-5.c execution, -O3 -fomit-frame-pointer -funroll-loops FAIL: gcc.dg/cpp/assert4.c (test for excess errors) FAIL: gcc.dg/cpp/trad/include.c (test for excess errors) FAIL: gcc.dg/alias-7.c execution
Re: FDO patch -- make ic related vars TLS if target allows
David, Support for native TLS on AIX exposed a problem with this patch. A similar problem exists on Solaris 9. Some helper functions for TLS on AIX and Solaris 9 only are provided by libpthread. Promoting ic related variables to TLS breaks profiling of non-pthread appications. I completely agree with reducing race conditions and improving support for profiling of pthread applications, but why should this change be enabled for applications not built and run as multi-threaded? This feature should test more than the existence of target TLS support. Thanks, David
Re: [patch][RFC] bail out after front-end errors
On Tue, Mar 27, 2012 at 10:59 AM, Richard Guenther wrote:
> On Tue, Mar 27, 2012 at 10:32 AM, Steven Bosscher wrote:
>> On Tue, Mar 27, 2012 at 9:17 AM, Richard Guenther wrote:
>>> It would be nice to finally move
>>> the call to cgraph_finalize_compilation_unit to the middle-end ...
>>> (warning, if you try that you run into an issue with the Java frontend ...
>>> :/)
>>
>> Do you remember what issues that causes? I'm running into a great
>> number of issues there already with some varasm fixes (basically just
>> cleanups for the tree-ssa and unit-at-a-time era we're supposed to
>> live in - except Java).
>
> I think it was the
>
> /* Generate hidden aliases for Java. */
> if (candidates)
> {
> build_java_method_aliases (candidates);
> pointer_set_destroy (candidates);
> }
>
> hunk in cp_write_global_declarations that does not work when run
> before cgraph_finalize_compilation_unit
> (I simply tried to move that call out of, and after calling the
> langhook). So the problem materialized when
> building libjava I think.
Hello,
Coming back to this issue... Attached patch is an attempt to resolve
this part of the finalize_compilation_unit problem. Instead of
emitting aliases with assemble_alias after finalize_compilation_unit,
this patch uses cgraph_same_body_alias before it.
Bootstrapped&tested on powerpc64-unknown-linux-gnu.
Richi, Honza, does this make sense?
Ciao!
Steven
cp/
* decl2.c (collect_candidates_for_java_method_aliases): Remove.
(build_java_method_aliases): Rewrite to emit the aliases via the
cgraphunit machinery.
(cp_write_global_declarations): Adjust for abovementioned changes.
Index: cp/decl2.c
===
--- cp/decl2.c (revision 194725)
+++ cp/decl2.c (working copy)
stevenb@stevenb-laptop:~$ cat devel/java_method_aliases.diff
cp/
* decl2.c (collect_candidates_for_java_method_aliases): Remove.
(build_java_method_aliases): Rewrite to emit the aliases via the
cgraphunit machinery.
(cp_write_global_declarations): Adjust for abovementioned changes.
Index: cp/decl2.c
===
--- cp/decl2.c (revision 194725)
+++ cp/decl2.c (working copy)
@@ -3615,79 +3615,53 @@ generate_ctor_and_dtor_functions_for_priority (spl
/* Java requires that we be able to reference a local address for a
method, and not be confused by PLT entries. If hidden aliases are
- supported, collect and return all the functions for which we should
+ supported, emit one for each java function that we've emitted.
emit a hidden alias. */
-static struct pointer_set_t *
-collect_candidates_for_java_method_aliases (void)
+static void
+build_java_method_aliases (void)
{
+#ifdef HAVE_GAS_HIDDEN
struct cgraph_node *node;
- struct pointer_set_t *candidates = NULL;
+ tree fndecl;
+ vec candidates = vNULL;
+ unsigned int ix;
-#ifndef HAVE_GAS_HIDDEN
- return candidates;
-#endif
-
+ /* First collect all candidates. We cannot create the aliases
+ in place, it confuses the FOR_EACH_FUNCTION iterator. */
FOR_EACH_FUNCTION (node)
{
- tree fndecl = node->symbol.decl;
-
+ fndecl = node->symbol.decl;
if (DECL_CONTEXT (fndecl)
&& TYPE_P (DECL_CONTEXT (fndecl))
&& TYPE_FOR_JAVA (DECL_CONTEXT (fndecl))
&& TARGET_USE_LOCAL_THUNK_ALIAS_P (fndecl))
- {
- if (candidates == NULL)
- candidates = pointer_set_create ();
- pointer_set_insert (candidates, fndecl);
- }
+ candidates.safe_push (fndecl);
}
- return candidates;
-}
-
-
-/* Java requires that we be able to reference a local address for a
- method, and not be confused by PLT entries. If hidden aliases are
- supported, emit one for each java function that we've emitted.
- CANDIDATES is the set of FUNCTION_DECLs that were gathered
- by collect_candidates_for_java_method_aliases. */
-
-static void
-build_java_method_aliases (struct pointer_set_t *candidates)
-{
- struct cgraph_node *node;
-
-#ifndef HAVE_GAS_HIDDEN
- return;
-#endif
-
- FOR_EACH_FUNCTION (node)
+ /* Now add the aliases for the candidates collected above.
+ Mangle the name in a predictable way; we need to reference
+ this from a java compiled object file. */
+ FOR_EACH_VEC_ELT (candidates, ix, fndecl)
{
- tree fndecl = node->symbol.decl;
+ tree oid, nid, alias;
+ const char *oname;
+ char *nname;
- if (TREE_ASM_WRITTEN (fndecl)
- && pointer_set_contains (candidates, fndecl))
- {
- /* Mangle the name in a predictable way; we need to reference
-this from a java compiled object file. */
- tree oid, nid, alias;
- const char *oname;
- char *nname;
+ oid = DECL_ASSEMBLER_NAME (fndecl);
+ oname = IDENTIFIER_POINTER (oid);
+ gcc_assert (oname[0] == '_' && oname[1] == 'Z');
Re: [patch, libgfortran] PR55818 Reading a REAL from a file which doesn't end in a new line fails
On 12/27/2012 05:51 PM, Jerry DeLisle wrote:
Hi,
The attached patch fixes this problem by not calling hit_eof if EOF can be a
valid separator.
Regression tested on x86-64.
OK for trunk with test case from PR?
Regards,
Jerry
2012-12-27 Jerry DeLisle
PR libfortran/55818
* io/list_read.c (read_real): Do not call hit_eof when EOF can be
treated as a value separator
Attached updated patch addresses the similar problem with complex and character
variables (mentioned in subsequent PR comments). Regression tested on x86-64 linux.
OK for trunk with updated ChangeLog and test cases from PR?
Regards,
Jerry
Index: list_read.c
===
--- list_read.c (revision 194731)
+++ list_read.c (working copy)
@@ -951,6 +951,7 @@ read_character (st_parameter_dt *dtp, int length _
break;
CASE_SEPARATORS:
+case EOF:
unget_char (dtp, c); /* NULL value. */
eat_separator (dtp);
return;
@@ -975,8 +976,7 @@ read_character (st_parameter_dt *dtp, int length _
for (;;)
{
- if ((c = next_char (dtp)) == EOF)
- goto eof;
+ c = next_char (dtp);
switch (c)
{
CASE_DIGITS:
@@ -984,6 +984,7 @@ read_character (st_parameter_dt *dtp, int length _
break;
CASE_SEPARATORS:
+ case EOF:
unget_char (dtp, c);
goto done; /* String was only digits! */
@@ -1005,6 +1006,7 @@ read_character (st_parameter_dt *dtp, int length _
if ((c = next_char (dtp)) == EOF)
goto eof;
+
switch (c)
{
CASE_SEPARATORS:
@@ -1041,7 +1043,7 @@ read_character (st_parameter_dt *dtp, int length _
the string. */
if ((c = next_char (dtp)) == EOF)
- goto eof;
+ goto done_eof;
if (c == quote)
{
push_char (dtp, quote);
@@ -1315,6 +1317,7 @@ read_complex (st_parameter_dt *dtp, void * dest, i
break;
CASE_SEPARATORS:
+case EOF:
unget_char (dtp, c);
eat_separator (dtp);
return;
@@ -1369,7 +1372,7 @@ eol_4:
goto bad_complex;
c = next_char (dtp);
- if (!is_separator (c))
+ if (!is_separator (c) && (c != EOF))
goto bad_complex;
unget_char (dtp, c);
@@ -1429,6 +1432,7 @@ read_real (st_parameter_dt *dtp, void * dest, int
goto got_sign;
CASE_SEPARATORS:
+case EOF:
unget_char (dtp, c); /* Single null. */
eat_separator (dtp);
return;
@@ -1484,6 +1488,7 @@ read_real (st_parameter_dt *dtp, void * dest, int
goto got_repeat;
CASE_SEPARATORS:
+ case EOF:
if (c != '\n' && c != ',' && c != '\r' && c != ';')
unget_char (dtp, c);
goto done;
Re: FDO patch -- make ic related vars TLS if target allows
Is there a way to tell if the program is going to be multi-threaded? If not, it might be useful to introduce a compiler option such as -fmt which also enables -lpthread. Using tricks like weakrefs can introduce unnecessary runtime overhead. David On Fri, Dec 28, 2012 at 8:26 AM, David Edelsohn wrote: > David, > > Support for native TLS on AIX exposed a problem with this patch. A > similar problem exists on Solaris 9. > > Some helper functions for TLS on AIX and Solaris 9 only are provided > by libpthread. Promoting ic related variables to TLS breaks profiling > of non-pthread appications. I completely agree with reducing race > conditions and improving support for profiling of pthread > applications, but why should this change be enabled for applications > not built and run as multi-threaded? This feature should test more > than the existence of target TLS support. > > Thanks, David
Re: atomic update of profile counters (issue7000044)
Hi Honza, In the other thread of discussion (similar patch in google-4_7 branch), you said you were thinking if to let this patch into trunk in stage 3. Can you give some update? Thanks, -Rong On Fri, Dec 21, 2012 at 10:37 AM, Rong Xu wrote: > On Fri, Dec 21, 2012 at 1:25 AM, Jan Hubicka wrote: >>> Hi, >>> >>> This patch adds support of atomic update of profiles counters. The goal is >>> to improve >>> the poor counter values for highly thread programs. >>> >>> The atomic update is under a new option -fprofile-gen-atomic= >>> N=0: default, no atomic update >>> N=1: atomic update edge counters. >>> N=2: atomic update some of value profile counters (currently indirect-call >>> and one value profile). >>> N=3: both edge counter and the above value profile counters. >>> Other value: fall back to the default. >>> >>> This patch is a simple porting of the version in google-4_7 branch. It uses >>> __atomic_fetch_add >>> based on Andrew Pinski's suggestion. Note I did not apply to all the value >>> profiles as >>> the indirect-call profile is the most relevant one here. >>> >>> Test with bootstrap. >>> >>> Comments and suggestions are welcomed. >>> >>> Thanks, >>> >>> -Rong >>> >>> >>> 2012-12-20 Rong Xu >>> >>> * libgcc/libgcov.c (__gcov_one_value_profiler_body_atomic): New >>> function. Atomic update profile counters. >>> (__gcov_one_value_profiler_atomic): Ditto. >>> (__gcov_indirect_call_profiler_atomic): Ditto. >>> * gcc/gcov-io.h: Macros for atomic update. >>> * gcc/common.opt: New option. >>> * gcc/tree-profile.c (gimple_init_edge_profiler): Atomic >>> update profile counters. >>> (gimple_gen_edge_profiler): Ditto. >> >> The patch looks resonable. Eventually we probably should provide rest of >> the value counters >> in thread safe manner. What happens on targets not having atomic operations? > > From > http://gcc.gnu.org/onlinedocs/gcc/_005f_005fsync-Builtins.html#_005f_005fsync-Builtins, > it says: > "If a particular operation cannot be implemented on the target > processor, a warning is generated and a call an external function is > generated. " > > So I think there will be a warning and eventually a link error of unsat. > > Thanks, > > -Rong > > >> >> Honza
Re: atomic update of profile counters (issue7000044)
It would be great if this can make into gcc4.8. The patch has close to 0 impact on code stability. David On Fri, Dec 28, 2012 at 11:32 AM, Rong Xu wrote: > Hi Honza, > > In the other thread of discussion (similar patch in google-4_7 > branch), you said you were thinking if to let this patch into trunk in > stage 3. Can you give some update? > > Thanks, > > -Rong > > On Fri, Dec 21, 2012 at 10:37 AM, Rong Xu wrote: >> On Fri, Dec 21, 2012 at 1:25 AM, Jan Hubicka wrote: Hi, This patch adds support of atomic update of profiles counters. The goal is to improve the poor counter values for highly thread programs. The atomic update is under a new option -fprofile-gen-atomic= N=0: default, no atomic update N=1: atomic update edge counters. N=2: atomic update some of value profile counters (currently indirect-call and one value profile). N=3: both edge counter and the above value profile counters. Other value: fall back to the default. This patch is a simple porting of the version in google-4_7 branch. It uses __atomic_fetch_add based on Andrew Pinski's suggestion. Note I did not apply to all the value profiles as the indirect-call profile is the most relevant one here. Test with bootstrap. Comments and suggestions are welcomed. Thanks, -Rong 2012-12-20 Rong Xu * libgcc/libgcov.c (__gcov_one_value_profiler_body_atomic): New function. Atomic update profile counters. (__gcov_one_value_profiler_atomic): Ditto. (__gcov_indirect_call_profiler_atomic): Ditto. * gcc/gcov-io.h: Macros for atomic update. * gcc/common.opt: New option. * gcc/tree-profile.c (gimple_init_edge_profiler): Atomic update profile counters. (gimple_gen_edge_profiler): Ditto. >>> >>> The patch looks resonable. Eventually we probably should provide rest of >>> the value counters >>> in thread safe manner. What happens on targets not having atomic >>> operations? >> >> From >> http://gcc.gnu.org/onlinedocs/gcc/_005f_005fsync-Builtins.html#_005f_005fsync-Builtins, >> it says: >> "If a particular operation cannot be implemented on the target >> processor, a warning is generated and a call an external function is >> generated. " >> >> So I think there will be a warning and eventually a link error of unsat. >> >> Thanks, >> >> -Rong >> >> >>> >>> Honza
Re: FDO patch -- make ic related vars TLS if target allows
Hi, David The front-end drivers use -pthread and that often adds -lpthread. But -pthread is not passed to cc1, etc. I am not certain if there is a way for the compiler to ascertain that it is being invoked to compile a file intended for a multi-threaded application. It knows bout OpenMP and __thread, but that does not encompass all pthreads applications. Thanks, David On Fri, Dec 28, 2012 at 2:08 PM, Xinliang David Li wrote: > Is there a way to tell if the program is going to be multi-threaded? > If not, it might be useful to introduce a compiler option such as -fmt > which also enables -lpthread. Using tricks like weakrefs can > introduce unnecessary runtime overhead. > > David > > On Fri, Dec 28, 2012 at 8:26 AM, David Edelsohn wrote: >> David, >> >> Support for native TLS on AIX exposed a problem with this patch. A >> similar problem exists on Solaris 9. >> >> Some helper functions for TLS on AIX and Solaris 9 only are provided >> by libpthread. Promoting ic related variables to TLS breaks profiling >> of non-pthread appications. I completely agree with reducing race >> conditions and improving support for profiling of pthread >> applications, but why should this change be enabled for applications >> not built and run as multi-threaded? This feature should test more >> than the existence of target TLS support. >> >> Thanks, David
Re: [RFC PATCH, i386]: Use %r15 for REAL_PIC_OFFSET_TABLE_REGNUM on x86_64
On 12/27/2012 12:08 AM, Uros Bizjak wrote: > The alternative approach is changing cpuid definition in cpuid.h (as > in attached patch) to preserve %rbx, but we can't detect various code > model settings there. Since the change depends on the definition of > __PIC__, we unnecessary preserve %rbx also for -mcmodel=small. Certainly we can. We also control the preprocessor defines. All that's needed is that we create one for the code model. r~
[wwwdocs] Clean up some references to cvs.html
In http://gcc.gnu.org/PR54711 Andrew wrote the following: >> I am not sure where the sources >> for the web pages are. Are they in the GCC source tree somewhere? > Weird, IIRC instructions used to be on the write-access page. > Gerald? They are on the cvs.html page: http://gcc.gnu.org/cvs.html I don't know if they are linked from anywhere though. Planning to simplify/improve things partly based on that thread, I noticed that we actually have too many references to that page, so before I proceed with the other changes, this one cleans things up a bit (and reduces the number of direct references we have to CVS or Subversion). Applied. Gerald Index: projects/beginner.html === RCS file: /cvs/gcc/wwwdocs/htdocs/projects/beginner.html,v retrieving revision 1.56 diff -u -3 -p -r1.56 beginner.html --- projects/beginner.html 20 Sep 2009 21:25:28 - 1.56 +++ projects/beginner.html 29 Dec 2012 00:22:58 - @@ -22,7 +22,7 @@ you have no programming skills, href="documentation.html">help with documentation or with the http://gcc.gnu.org/bugzilla/";>bug database. -We assume that you already know how to get the +We assume that you already know how to get the latest sources, configure and build the compiler, and run the test suite. You should also familiarize yourself with the requirements for contributions to GCC. Index: projects/cfo.html === RCS file: /cvs/gcc/wwwdocs/htdocs/projects/cfo.html,v retrieving revision 1.8 diff -u -3 -p -r1.8 cfo.html --- projects/cfo.html 30 Dec 2008 10:04:46 - 1.8 +++ projects/cfo.html 29 Dec 2012 00:22:58 - @@ -28,8 +28,7 @@ added. To do list published. 2004-11-16 -The branch is now open. Checkout the cfo-branch branch by following the -instructions found in the CVS documentation. +The branch is now open. @@ -45,8 +44,8 @@ algorithms). The implementation currentl Contributing -Checkout the cfo-branch branch following the instructions found in the -CVS documentation. +Checkout the cfo-branch branch from +our respository. When posting to the development lists, please mark messages and patches with [cfo] in the subject. The usual contribution and testing rules apply. This Index: projects/cxx-reflection/index.html === RCS file: /cvs/gcc/wwwdocs/htdocs/projects/cxx-reflection/index.html,v retrieving revision 1.4 diff -u -3 -p -r1.4 index.html --- projects/cxx-reflection/index.html 25 Aug 2003 14:02:36 - 1.4 +++ projects/cxx-reflection/index.html 29 Dec 2012 00:22:58 - @@ -22,8 +22,7 @@ constrained genericity in C++. Contributing Checkout the cxx-reflection-branch branch -following the instructions found in the CVS -documentation. +in our respository. When posting to the development lists, please mark messages and patches with [cxx-reflection] in the subject. As this is a branch, and not Index: projects/tree-ssa/index.html === RCS file: /cvs/gcc/wwwdocs/htdocs/projects/tree-ssa/index.html,v retrieving revision 1.41 diff -u -3 -p -r1.41 index.html --- projects/tree-ssa/index.html25 Apr 2009 22:58:23 - 1.41 +++ projects/tree-ssa/index.html29 Dec 2012 00:22:59 - @@ -78,8 +78,7 @@ href="http://gcc.gnu.org/wiki/GettingSta Contributing Checkout the tree-ssa-20020619-branch branch -following the instructions found in the CVS documentation. +in our respository. All contributions to the branch must also comply with the requirements detailed in the
Re: [RFC, x86] Changes for AVX and AVX2 processors
Hello, processor_alias_table contains the same processor type for all "corei7", "corei7-avx", "core-avx-i" and "core-avx2". At least, it has consequence on checking x86_avx256_split_unaligned_load & ix86_tune_mask: for all these processors it results the same. Moreover we cannot turn new features on for AVX/AVX2 using initial_ix86_tune_features. . 2012/12/28 Uros Bizjak : > Hello! > >> New processors core-avx and core-avx2 are added. It was done to have >> possibilities to turn new features on for these processors. Please review. > > I don't think this is a good approach, you are mixing an architecture > with an ISA extension in the name. We already have > processor_alias_table, where processor architecture and features > (extensions) can be activated, depending on the name. > > Uros.
