Re: [patch]: 2 of 7 Fix of PR target/53912 bootstrap fails using default c++ mode in stage 2 and 3 for native x86_64-w64-mingw32
Ping
2012/11/29 Kai Tietz :
> Hello,
>
> this trivial patch fixes a bootstrap issue on LLP64 hosts.
>
> ChangeLog
>
> 2012-11-29 Kai Tietz
>
> PR target/53912
> * ggc-common.c (POINTER_HASH): Cast from pointer via intptr_t.
>
> Tested for i686-w64-mingw32, x86_64-w64-mingw32, and
> x86_64-unknown-gnu-linux. Ok for apply?
>
> Regards,
> Kai
>
> Index: ggc-common.c
> ===
> --- ggc-common.c(Revision 193925)
> +++ ggc-common.c(Arbeitskopie)
> @@ -304,7 +304,7 @@ struct ptr_data
>enum gt_types_enum type;
> };
>
> -#define POINTER_HASH(x) (hashval_t)((long)x >> 3)
> +#define POINTER_HASH(x) (hashval_t)((intptr_t)x >> 3)
>
> /* Register an object in the hash table. */
--
| (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| (")_(") him gain world domination
Re: [patch]: 3 of 7 Fix of PR target/53912 bootstrap fails using default c++ mode in stage 2 and 3 for native x86_64-w64-mingw32
Ping
2012/11/29 Kai Tietz :
> Hello,
>
> this trivial patch fixes a bootstrap issue on LLP64 hosts.
>
> ChangeLog
>
> 2012-11-29 Kai Tietz
>
> PR target/53912
> * pointer-set.c (hash1): Cast from pointer via uintptr_t.
>
> Tested for i686-w64-mingw32, x86_64-w64-mingw32, and
> x86_64-unknown-gnu-linux. Ok for apply?
>
> Regards,
> Kai
>
> Index: pointer-set.c
> ===
> --- pointer-set.c (Revision 193925)
> +++ pointer-set.c (Arbeitskopie)
> @@ -64,7 +64,7 @@ hash1 (const void *p, unsigned long max, unsigned
> #endif
>const unsigned long shift = HOST_BITS_PER_LONG - logmax;
>
> - return ((A * (unsigned long) p) >> shift) & (max - 1);
> + return ((A * (uintptr_t) p) >> shift) & (max - 1);
> }
>
> /* Allocate an empty pointer set. */
--
| (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| (")_(") him gain world domination
Re: [patch tree-dump.c]: 7 of 7 Fix of PR target/53912 bootstrap fails using default c++ mode in stage 2 and 3 for native x86_64-w64-mingw32
Ping
2012/11/29 Kai Tietz :
> Updated variant using HOST_WIDE_INT_PRINT.
>
> Tested for i686-w64-mingw32 and x86_64-w64-mingw32. Ok for apply?
>
> Kai
>
> Index: tree-dump.c
> ===
> --- tree-dump.c (Revision 193925)
> +++ tree-dump.c (Arbeitskopie)
> @@ -177,7 +177,8 @@ void
> dump_pointer (dump_info_p di, const char *field, void *ptr)
> {
>dump_maybe_newline (di);
> - fprintf (di->stream, "%-4s: %-8lx ", field, (unsigned long) ptr);
> + fprintf (di->stream, "%-4s: %-8" HOST_WIDE_INT_PRINT "x ", field,
> + (HOST_WIDE_INT) (uintptr_t) ptr);
>di->column += 15;
> }
--
| (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| (")_(") him gain world domination
Re: [patch print-tree.c]: 5 of 7 Fix of PR target/53912 bootstrap fails using default c++ mode in stage 2 and 3 for native x86_64-w64-mingw32
Ping
2012/11/29 Kai Tietz :
> Hello,
>
> this trivial patch fixes a bootstrap issue on LLP64 hosts.
>
> ChangeLog
>
> 2012-11-29 Kai Tietz
>
> PR target/53912
> * print-tree.c (print_node): Cast from pointer via uintptr_t.
>
> Tested for i686-w64-mingw32, x86_64-w64-mingw32, and
> x86_64-unknown-gnu-linux. Ok for apply?
>
> Regards,
> Kai
>
> Index: print-tree.c
> ===
> --- print-tree.c(Revision 193925)
> +++ print-tree.c(Arbeitskopie)
> @@ -255,7 +255,7 @@ print_node (FILE *file, const char *prefix, tree n
>/* Allow this function to be called if the table is not there. */
>if (table)
> {
> - hash = ((unsigned long) node) % HASH_SIZE;
> + hash = ((uintptr_t) node) % HASH_SIZE;
>
>/* If node is in the table, just mention its address. */
>for (b = table[hash]; b; b = b->next)
--
| (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| (")_(") him gain world domination
Re: [patch stmt.c]: 6 of 7 Fix of PR target/53912 bootstrap fails using default c++ mode in stage 2 and 3 for native x86_64-w64-mingw32
Ping
2012/11/29 Kai Tietz :
> Hello,
>
> this trivial patch fixes a bootstrap issue on LLP64 hosts.
>
> ChangeLog
>
> 2012-11-29 Kai Tietz
>
> PR target/53912
> * stmt.c (compute_cases_per_edge): Cast from pointer via intptr_t.
> (expand_case): Likewise.
>
> Tested for i686-w64-mingw32, x86_64-w64-mingw32, and
> x86_64-unknown-gnu-linux. Ok for apply?
>
> Regards,
> Kai
>
> Index: stmt.c
> ===
> --- stmt.c (Revision 193925)
> +++ stmt.c (Arbeitskopie)
> @@ -2061,7 +2061,7 @@ compute_cases_per_edge (gimple stmt)
>tree lab = CASE_LABEL (elt);
>basic_block case_bb = label_to_block_fn (cfun, lab);
>edge case_edge = find_edge (bb, case_bb);
> - case_edge->aux = (void *)((long)(case_edge->aux) + 1);
> + case_edge->aux = (void *)((intptr_t)(case_edge->aux) + 1);
> }
> }
>
> @@ -2176,7 +2176,7 @@ expand_case (gimple stmt)
>edge case_edge = find_edge (bb, case_bb);
>case_list = add_case_node (
>case_list, low, high, lab,
> - case_edge->probability / (long)(case_edge->aux),
> + case_edge->probability / (intptr_t)(case_edge->aux),
>case_node_pool);
> }
>pointer_set_destroy (seen_labels);
--
| (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| (")_(") him gain world domination
Re: [PATCH] Fix PR gcov-profile/55551 (issue6868045)
> 2012-12-01 Teresa Johnson > > PR gcov-profile/1 > * lto-cgraph.c (merge_profile_summaries): Handle scaled histogram > entries that map to the same index. Path is OK. It would be nice to figure out why you have non-zero runs and sum_max zero. It is legally possible when you build your main w/o profiling and exit early, but I would expect this to be bug in Mozilla's FDO build rather than intention. It can easilly happen when you profile library and load it into something that do not use it. Honza
Re: [cxx-conversion] graphite-related hash tables
On Sun, Dec 2, 2012, at 02:42 AM, Lawrence Crowl wrote: > Change graphite-related hash tables from htab_t to hash_table: > > graphite-clast-to-gimple.c ivs_params::newivs_index > graphite-clast-to-gimple.c ivs_params::params_index > graphite-clast-to-gimple.c print_generated_program::params_index > graphite-clast-to-gimple.c gloog::newivs_index > graphite-clast-to-gimple.c gloog::params_index > graphite.c graphite_transform_loops::bb_pbb_mapping > sese.c copy_bb_and_scalar_dependences::rename_map > > Move hash table declarations to a new graphite-htab.h, because they > are used in few places. > > Remove unused: > > htab_t scop::original_pddrs > SCOP_ORIGINAL_PDDRS > > Remove unused: > > insert_loop_close_phis > insert_guard_phis > debug_ivtype_map > ivtype_map_elt_info > new_ivtype_map_elt > > > Tested on x86-64. > > Okay for branch? Hi Lawrance, from the point of graphite, the update looks very good. Thanks lot for getting the new hash table implementation in. Also, thanks for the dead code removal. Assuming the test suite passes and this is just a no-behavior change intended commit, I am fine with this. No idea, who needs to sign off branch commits, though. Cheers Tobi
Re: [PATCH] Don't bypass blocks with multiple latch edges (PR middle-end/54838)
> Like this? Regtested/bootstrapped on x86_64-linux, ok for trunk? > > 2012-12-01 Marek Polacek > > PR middle-end/54838 > * cprop.c (bypass_block): Determine number of latches. Return > when there is more than one latch edge. > > * gcc.dg/pr54838.c: New test. That's fine, thanks for your patience. -- Eric Botcazou
Re: [PATCH] Fix PR55521 by switching libsanitizer from mach_override to mac interpose functions on darwin
On Sun, Dec 2, 2012 at 10:21 AM, Alexander Potapenko wrote:
> Hi Jack,
>
> IIUC the wrappers for dispatch_async_f, dispatch_sync_f and other
> dispatch_smth_f do not need blocks support in the compiler, since
> regular functions are passed into them. So you may want to add the
> dynamic interceptors for those back.
> The remaining problem is that dispach_async and other functions using
> blocks won't be intercepted. This may lead to assertion failures in
> big projects (e.g. we needed those for Chrome).
> Overall, the change looks good. Do you want me to backport
> MISSING_BLOCKS_SUPPORT into the LLVM version of the runtime?
Please remember that all non-trivial patches to files that exist in
the upstream (llvm) repository should go there first.
Otherwise we'll be drown in merges.
--kcc
>
> Alex
>
> On Sun, Dec 2, 2012 at 6:43 AM, Jack Howarth wrote:
>>The attached patch eliminates PR 55521/sanitizer by switching libasan on
>> darwin
>> from using mach_override to mac function interposition via the importation
>> of the
>> asan/dynamic/asan_interceptors_dynamic.cc file from llvm.org's compiler-rt
>> svn.
>> The changes involve defining USING_MAC_INTERPOSE in configure.ac rather than
>> rather than USING_MACH_OVERRIDE, introduction of the use of
>> USING_MAC_INTERPOSE
>> in Makefile.am to avoid building the interception subdirectory, the passage
>> of
>> -DMAC_INTERPOSE_FUNCTIONS in asan/Makefile.am when USING_MAC_INTERPOSE as
>> well as
>> the introduction of a -DMISSING_BLOCKS_SUPPORT flag to disable code that
>> requires
>> blocks support which FSF gcc lacks. The depreciated usage of
>> USING_MACH_OVERRIDE
>> is also removed from interception/Makefile.am. Bootstrapped on
>> x86_64-apple-darwin10,
>> x86_64-apple-darwin11 and x86_64-apple-darwin12. Passes...
>>
>> make -k check RUNTESTFLAGS="asan.exp --target_board=unix'{-m32,-m64}'"
>>
>> and fixes the previously failing cond1.C test case from PR55521 on all three
>> targets.
>> Okay for gcc trunk?
>> Jack
>>
>
>
>
> --
> Alexander Potapenko
> Software Engineer
> Google Moscow
Re: [i386] scalar ops that preserve the high part of a vector
On Sat, Dec 1, 2012 at 6:27 PM, Marc Glisse wrote: > here is a patch. If it is accepted, I'll extend it to other vm patterns > (mul, div, min, max are likely candidates, but I need to check the doc). It > passed bootstrap+testsuite on x86_64-linux. > > > 2012-12-01 Marc Glisse > > PR target/54855 > gcc/ > * config/i386/sse.md (_vm3): Rewrite > pattern. > * config/i386/i386-builtin-types.def: New function types. > * config/i386/i386.c (ix86_expand_args_builtin): Likewise. > (bdesc_args) <__builtin_ia32_addss, __builtin_ia32_subss, > __builtin_ia32_addsd, __builtin_ia32_subsd>: Change prototype. > * config/i386/xmmintrin.h: Adapt to new builtin prototype. > * config/i386/emmintrin.h: Likewise. > * doc/extend.texi (X86 Built-in Functions): Document changed > prototype. > > testsuite/ > * gcc.target/i386/pr54855-1.c: New testcase. > * gcc.target/i386/pr54855-2.c: New testcase. Yes, the approach looks correct to me, but I wonder why we have different representations for v4sf and v2df cases? I'd say that we should canonicalize patterns somewhere in the middle end (probably to vec_merge variant, as IMO vec_dup looks like degenerated vec_merge variant), otherwise we will have pattern explosion. However, the patch is too late for 4.8, but definitely a wanted generalization and fix of a (partially) wrong representation. I have also CCd HJ for his opinion, since the patch touches published headers. Thanks, Uros.
Re: [RFA:] fix group-loads of VOIDmode constants, expr.c:emit_group_load_1
On Sat, 1 Dec 2012, Eric Botcazou wrote: > > Of course this matters only to >64bit (i.e. >registersize) values like > > TImode, alias __int128. The problem here is that group-loading a > > constant for a function return-value doesn't work; it's passed to > > simplify_gen_subreg which horks on the VOIDmode constant. Thankfully, > > the code below the context handles this case, twice the register-mode, > > just fine, so let's just gate the simplify_gen_subreg call with a test > > for a VOIDmode source. > > IMO that's not as clear a cut as it seems. simplify_gen_subreg is supposed to > work on VOIDmode constants, at least to be callable on them, because there is > the simplify_gen_subreg -> simplify_subreg -> simplify_immed_subreg path. Oops, that parallel I quoted should've had TImode, not VOIDmode. The documentation is pretty clear. Tested as before (but mmix targets only :) Committed. gcc: * config/mmix/mmix.c (mmix_function_value): Set the mode of the returned PARALLEL to that of the return-value, not VOIDmode. Index: gcc/config/mmix/mmix.c === --- gcc/config/mmix/mmix.c (revision 192677) +++ gcc/config/mmix/mmix.c (working copy) @@ -754,7 +754,7 @@ mmix_function_value (const_tree valtype, gen_rtx_REG (cmode, first_val_regnum + nregs - 1), const0_rtx); - return gen_rtx_PARALLEL (VOIDmode, gen_rtvec_v (nregs, vec)); + return gen_rtx_PARALLEL (mode, gen_rtvec_v (nregs, vec)); } /* Implements TARGET_LIBCALL_VALUE. */ brgds, H-P
Re: [i386] scalar ops that preserve the high part of a vector
On Sun, 2 Dec 2012, Uros Bizjak wrote: On Sat, Dec 1, 2012 at 6:27 PM, Marc Glisse wrote: here is a patch. If it is accepted, I'll extend it to other vm patterns (mul, div, min, max are likely candidates, but I need to check the doc). It passed bootstrap+testsuite on x86_64-linux. 2012-12-01 Marc Glisse PR target/54855 gcc/ * config/i386/sse.md (_vm3): Rewrite pattern. * config/i386/i386-builtin-types.def: New function types. * config/i386/i386.c (ix86_expand_args_builtin): Likewise. (bdesc_args) <__builtin_ia32_addss, __builtin_ia32_subss, __builtin_ia32_addsd, __builtin_ia32_subsd>: Change prototype. * config/i386/xmmintrin.h: Adapt to new builtin prototype. * config/i386/emmintrin.h: Likewise. * doc/extend.texi (X86 Built-in Functions): Document changed prototype. testsuite/ * gcc.target/i386/pr54855-1.c: New testcase. * gcc.target/i386/pr54855-2.c: New testcase. Yes, the approach looks correct to me, but I wonder why we have different representations for v4sf and v2df cases? I'd say that we should canonicalize patterns somewhere in the middle end (probably to vec_merge variant, as IMO vec_dup looks like degenerated vec_merge variant), otherwise we will have pattern explosion. (I assume s/vec_dup/vec_concat/ above) Note that this comes from ix86_expand_vector_set, which purposedly uses VEC_CONCAT for V2DF and VEC_MERGE for V4SF. It is true that we could use the VEC_MERGE version more widely, but this code that selects the most appropriate pattern depending on the mode seems good to me. And I wouldn't call the few extra entries in sse.md an explosion quite yet... (also, using VEC_DUPLICATE is quite artificial, in the special case where we set the first element of the vector, a subreg should work as well) However, the patch is too late for 4.8, That's fine, I can hold it for 4.9. I'd like to finalize the patch now while it is fresh though (I would still redo a quick bootstrap+testsuite before commit when trunk re-opens). Thanks, -- Marc Glisse
Re: New option to turn off stack reuse for temporaries
Hello David, Sorry to come so late into the discussion, but... On 21/06/12 00:50, Xinliang David Li wrote: > One of the most common runtime errors we have seen in gcc-4_7 is > caused by dangling references to temporaries whole life time have > ended > > e.g, > > const A& a = foo(); > > or > foo (A());// where temp's address is saved and used after foo. > > Of course this is user error according to the standard, > [...] ... is the first of your 2 examples really a user error? If so, it breaks GotW #88: A Candidate For the “Most Important const” [1]. Can you please clarify? Thanks in advance! Olivier [1] http://herbsutter.com/2008/01/01/gotw-88-a-candidate-for-the-most-important-const/
Re: [PATCH] Fix up var-tracking notes emitted in between bbs (PR middle-end/43631)
On Thu, Nov 15, 2012 at 12:02 AM, Jakub Jelinek wrote: > 2012-11-14 Jakub Jelinek < > > > PR middle-end/43631 > * var-tracking.c (emit_note_insn_var_location, emit_notes_in_bb): > Clear BLOCK_FOR_INSN on notes emitted in between basic blocks, > don't adjust BB_END when inserting note after BB_END of some bb. Hello Jakub, Please don't forget to commit this one! :-) Ciao! Steven
Re: [Patch, Fortran] PR 55548: SYSTEM_CLOCK with integer(8) provides nanosecond resolution, but only microsecond precision (without -lrt)
Hi all, since the first version of my SYSTEM_CLOCK patch was not so well received, I propose here an alternative patch: It does not use a fixed COUNT_RATE, but adjusts it to match the resolution of the underlying library function which is used. For the int4 version it additionally limits COUNT_RATE to 1000, in order to provide a reasonable maximum timespan. The patch also has the effect that the reported COUNT_RATE can now depend e.g. on the linker flags used (as does the precision of the clock: 1 nanosec with -lrt and 1 microsec without). Does anyone agree with me that this represents an improvement of the SYSTEM_CLOCK behavior? Cheers, Janus 2012/12/1 Janus Weil : > Hi all, > > here is a straightforward patch for the intrinsic procedure > SYSTEM_CLOCK. It does two things: > 1) It reduces the resolution of the int8 version from 1 nanosecond to > 1 microsecond (COUNT_RATE = 100). > 2) It adds an int16 version with nanosecond precision. > > The motivation for item #1 was mainly that the actual precision is > usually not better than 1 microsec anyway (unless linking with -lrt). > This results in SYSTEM_CLOCK giving values whose last three digits are > zero. One can argue that this is not a dramatic misbehavior, but it > has disadvantages for certain applications, like e.g. using > SYSTEM_CLOCK to initialize the random seed in a Monte-Carlo > simulation. In general, I would say that the value of COUNT_RATE > should not be larger than the actual precision of the clock used. > > Moreover, the microsecond resolution for int8 arguments has the > advantage that it is compatible with ifort's behavior. Also I think a > resolution of 1 microsecond is sufficient for most applications. If > someone really needs more, he can now use the int16 version (and link > with -lrt). > > Regtested on x86_64-unknown-linux-gnu (although we don't actually seem > to have any test cases for SYSTEM_CLOCK yet). Ok for trunk? > > Btw, does it make sense to also add an int2 version? If yes, which > resolution? Note that most other compilers seem to have an int2 > version of SYSTEM_CLOCK ... > > Cheers, > Janus > > > 2012-12-01 Janus Weil > > PR fortran/55548 > * gfortran.map (GFORTRAN_1.5): Add _gfortran_system_clock_16. > * intrinsics/system_clock.c (system_clock_8): Change resolution to > one microsec. > (system_clock_16): New function (with nanosecond resolution). > > 2012-12-01 Janus Weil > > PR fortran/55548 > * intrinsic.texi (SYSTEM_CLOCK): Update documentation of SYSTEM_CLOCK. > > 2012-12-01 Janus Weil > > PR fortran/55548 > * gfortran.dg/system_clock_1.f90: New test case. pr55548_v2.diff Description: Binary data
Re: [Patch, Fortran] PR 55548: SYSTEM_CLOCK with integer(8) provides nanosecond resolution, but only microsecond precision (without -lrt)
Janne Blomqvist wrote: Needing to link with librt in order to access clock_gettime is an unfortunate wart in glibc, but other C libraries exist out there (heck, given the success of Android, glibc is certainly a minority even if you limit yourself to Linux), and of those that provide clock_gettime, most have it directly in libc and not in a separate library. I think that has changed in GLIBC 2.17: http://sourceware.org/git/?p=glibc.git;a=blob_plain;f=NEWS;hb=HEAD Tobias
Re: [patch] RFA: more fixes for PR55006
On Thu, Nov 29, 2012 at 9:14 PM, Dominique Dhumieres wrote: >> Of course, I also verified that the darwin10 and sparc issues that >> spawned this long thread are fixed. > > Confirmed: bootstrapped on top of r193939, aermod.f90 is now correctly > compiled. Thanks for the extra testing. Updated patch attached, after committing the optabs.c and part of the fwprop.c changes separately. Ciao! Steven PR55006_2.diff Description: Binary data
Re: [PATCH] AIX native TLS support
I checked in the patch. The problem, at least for libgomp testsuite, is GCC is not correctly emitting the definitions of some variables specified with #pragma omp threadprivate(XXX) The symptoms are the variable is placed in a TLS section anchor block, which never should happen, or the BSS variable is not visible. - David
Re: [Patch, Fortran] PR 55548: SYSTEM_CLOCK with integer(8) provides nanosecond resolution, but only microsecond precision (without -lrt)
>> Needing to link with librt in order to access clock_gettime is an >> unfortunate wart in glibc, but other C libraries exist out there >> (heck, given the success of Android, glibc is certainly a minority >> even if you limit yourself to Linux), and of those that provide >> clock_gettime, most have it directly in libc and not in a separate >> library. > > I think that has changed in GLIBC 2.17: > http://sourceware.org/git/?p=glibc.git;a=blob_plain;f=NEWS;hb=HEAD good, having clock_gettime in the core library will certainly improve the situation. Still, for pre-2.17 versions of glibc or libraries which don't provide clock_gettime, I think we should fix the discrepancy between nominal resolution and actual precision of SYSTEM_CLOCK with int8 arguments. I have provided two different patches in this direction, and I would be very grateful for comments regarding which one would be preferable (I now tend to prefer the second one), and what would be needed to make it suitable for acceptance into trunk. Cheers, Janus
Re: Simplify a VEC_SELECT from one half of a VEC_CONCAT
While I was there, I decided to improve another bit of VEC_SELECT
simplification (this supersedes the patch in the father of this message).
Adding Uros in Cc: because I am touching the x86 backend. Sorry to add yet
another insn variant, but I don't see how we can avoid it here.
The x86 and RTL parts are independent, but the testcases need both.
bootstrap+testsuite on x86_64-linux. (for next stage1 I assume)
2012-12-02 Marc Glisse
PR target/43147
PR target/44551
gcc/
* simplify-rtx.c (simplify_binary_operation_1) :
Improve VEC_SELECT and VEC_CONCAT subcases.
* config/i386/sse.md (*sse_shufps__single): New.
gcc/testsuite/
* gcc.target/i386/pr43147.c: New testcase.
* gcc.target/i386/pr44551.c: New testcase.
--
Marc GlisseIndex: simplify-rtx.c
===
--- simplify-rtx.c (revision 194051)
+++ simplify-rtx.c (working copy)
@@ -3317,98 +3317,20 @@ simplify_binary_operation_1 (enum rtx_co
gcc_assert (VECTOR_MODE_P (GET_MODE (trueop0)));
gcc_assert (mode == GET_MODE_INNER (GET_MODE (trueop0)));
gcc_assert (GET_CODE (trueop1) == PARALLEL);
gcc_assert (XVECLEN (trueop1, 0) == 1);
gcc_assert (CONST_INT_P (XVECEXP (trueop1, 0, 0)));
if (GET_CODE (trueop0) == CONST_VECTOR)
return CONST_VECTOR_ELT (trueop0, INTVAL (XVECEXP
(trueop1, 0, 0)));
- /* Extract a scalar element from a nested VEC_SELECT expression
-(with optional nested VEC_CONCAT expression). Some targets
-(i386) extract scalar element from a vector using chain of
-nested VEC_SELECT expressions. When input operand is a memory
-operand, this operation can be simplified to a simple scalar
-load from an offseted memory address. */
- if (GET_CODE (trueop0) == VEC_SELECT)
- {
- rtx op0 = XEXP (trueop0, 0);
- rtx op1 = XEXP (trueop0, 1);
-
- enum machine_mode opmode = GET_MODE (op0);
- int elt_size = GET_MODE_SIZE (GET_MODE_INNER (opmode));
- int n_elts = GET_MODE_SIZE (opmode) / elt_size;
-
- int i = INTVAL (XVECEXP (trueop1, 0, 0));
- int elem;
-
- rtvec vec;
- rtx tmp_op, tmp;
-
- gcc_assert (GET_CODE (op1) == PARALLEL);
- gcc_assert (i < n_elts);
-
- /* Select element, pointed by nested selector. */
- elem = INTVAL (XVECEXP (op1, 0, i));
-
- /* Handle the case when nested VEC_SELECT wraps VEC_CONCAT. */
- if (GET_CODE (op0) == VEC_CONCAT)
- {
- rtx op00 = XEXP (op0, 0);
- rtx op01 = XEXP (op0, 1);
-
- enum machine_mode mode00, mode01;
- int n_elts00, n_elts01;
-
- mode00 = GET_MODE (op00);
- mode01 = GET_MODE (op01);
-
- /* Find out number of elements of each operand. */
- if (VECTOR_MODE_P (mode00))
- {
- elt_size = GET_MODE_SIZE (GET_MODE_INNER (mode00));
- n_elts00 = GET_MODE_SIZE (mode00) / elt_size;
- }
- else
- n_elts00 = 1;
-
- if (VECTOR_MODE_P (mode01))
- {
- elt_size = GET_MODE_SIZE (GET_MODE_INNER (mode01));
- n_elts01 = GET_MODE_SIZE (mode01) / elt_size;
- }
- else
- n_elts01 = 1;
-
- gcc_assert (n_elts == n_elts00 + n_elts01);
-
- /* Select correct operand of VEC_CONCAT
-and adjust selector. */
- if (elem < n_elts01)
- tmp_op = op00;
- else
- {
- tmp_op = op01;
- elem -= n_elts00;
- }
- }
- else
- tmp_op = op0;
-
- vec = rtvec_alloc (1);
- RTVEC_ELT (vec, 0) = GEN_INT (elem);
-
- tmp = gen_rtx_fmt_ee (code, mode,
- tmp_op, gen_rtx_PARALLEL (VOIDmode, vec));
- return tmp;
- }
if (GET_CODE (trueop0) == VEC_DUPLICATE
&& GET_MODE (XEXP (trueop0, 0)) == mode)
return XEXP (trueop0, 0);
}
else
{
gcc_assert (VECTOR_MODE_P (GET_MODE (trueop0)));
gcc_assert (GET_MODE_INNER (mode)
== GET_MODE_INNER (GET_MODE (trueop0)));
gcc_assert (GET_CODE (trueop1) == PARALLEL);
@@ -3482,44 +3404,96 @@ simplify_binary_operation_1 (enum rtx_co
rtx subop0, subop1;
gcc_assert (i0 < 2 && i1 < 2);
subop0 = XEXP (trueop0, i
Re: [PATCH] Fix PR55521 by switching libsanitizer from mach_override to mac interpose functions on darwin
On Sun, Dec 02, 2012 at 10:21:02AM +0400, Alexander Potapenko wrote:
> Hi Jack,
>
> IIUC the wrappers for dispatch_async_f, dispatch_sync_f and other
> dispatch_smth_f do not need blocks support in the compiler, since
> regular functions are passed into them. So you may want to add the
> dynamic interceptors for those back.
Alex,
This seems to only require the readjustment of the preprocessor
statements in libsanitizer/asan/dynamic/asan_interceptors_dynamic.cc.
I'll post the revised patch as soon as regression testing is finished.
> The remaining problem is that dispach_async and other functions using
> blocks won't be intercepted. This may lead to assertion failures in
> big projects (e.g. we needed those for Chrome).
In theory that is a problem, however my understanding was that the asan
dispatch support was added for use by objc/obj-c++ code. The objc/obj-c++
in FSF gcc is very fragile, on later darwin, since it runs against the
system Objective-C runtime but the compiler is only based on a merge
of the remaining bits of code from the old FSF gcc Apple branch circa
2006. IMHO, it is insane to try to do any production work with our
objc/obj-c++ compiler and current Mac OS X releases.
> Overall, the change looks good. Do you want me to backport
> MISSING_BLOCKS_SUPPORT into the LLVM version of the runtime?
Yes, as it should be transparent to llvm's builds.
Jack
>
> Alex
>
> On Sun, Dec 2, 2012 at 6:43 AM, Jack Howarth wrote:
> >The attached patch eliminates PR 55521/sanitizer by switching libasan on
> > darwin
> > from using mach_override to mac function interposition via the importation
> > of the
> > asan/dynamic/asan_interceptors_dynamic.cc file from llvm.org's compiler-rt
> > svn.
> > The changes involve defining USING_MAC_INTERPOSE in configure.ac rather than
> > rather than USING_MACH_OVERRIDE, introduction of the use of
> > USING_MAC_INTERPOSE
> > in Makefile.am to avoid building the interception subdirectory, the passage
> > of
> > -DMAC_INTERPOSE_FUNCTIONS in asan/Makefile.am when USING_MAC_INTERPOSE as
> > well as
> > the introduction of a -DMISSING_BLOCKS_SUPPORT flag to disable code that
> > requires
> > blocks support which FSF gcc lacks. The depreciated usage of
> > USING_MACH_OVERRIDE
> > is also removed from interception/Makefile.am. Bootstrapped on
> > x86_64-apple-darwin10,
> > x86_64-apple-darwin11 and x86_64-apple-darwin12. Passes...
> >
> > make -k check RUNTESTFLAGS="asan.exp --target_board=unix'{-m32,-m64}'"
> >
> > and fixes the previously failing cond1.C test case from PR55521 on all
> > three targets.
> > Okay for gcc trunk?
> > Jack
> >
>
>
>
> --
> Alexander Potapenko
> Software Engineer
> Google Moscow
Re: [PATCH] Fix PR55521 by switching libsanitizer from mach_override to mac interpose functions on darwin
On Sun, Dec 2, 2012 at 10:15 PM, Jack Howarth wrote:
> On Sun, Dec 02, 2012 at 10:21:02AM +0400, Alexander Potapenko wrote:
>> Hi Jack,
>>
>> IIUC the wrappers for dispatch_async_f, dispatch_sync_f and other
>> dispatch_smth_f do not need blocks support in the compiler, since
>> regular functions are passed into them. So you may want to add the
>> dynamic interceptors for those back.
>
> Alex,
> This seems to only require the readjustment of the preprocessor
> statements in libsanitizer/asan/dynamic/asan_interceptors_dynamic.cc.
> I'll post the revised patch as soon as regression testing is finished.
>
>> The remaining problem is that dispach_async and other functions using
>> blocks won't be intercepted. This may lead to assertion failures in
>> big projects (e.g. we needed those for Chrome).
>
> In theory that is a problem, however my understanding was that the asan
> dispatch support was added for use by objc/obj-c++ code. The objc/obj-c++
> in FSF gcc is very fragile, on later darwin, since it runs against the
> system Objective-C runtime but the compiler is only based on a merge
> of the remaining bits of code from the old FSF gcc Apple branch circa
> 2006. IMHO, it is insane to try to do any production work with our
> objc/obj-c++ compiler and current Mac OS X releases.
Ok, this makes sense.
>> Overall, the change looks good. Do you want me to backport
>> MISSING_BLOCKS_SUPPORT into the LLVM version of the runtime?
>
> Yes, as it should be transparent to llvm's builds.
I'll do that tomorrow morning then.
>>
>> Alex
>>
>> On Sun, Dec 2, 2012 at 6:43 AM, Jack Howarth
>> wrote:
>> >The attached patch eliminates PR 55521/sanitizer by switching libasan
>> > on darwin
>> > from using mach_override to mac function interposition via the importation
>> > of the
>> > asan/dynamic/asan_interceptors_dynamic.cc file from llvm.org's compiler-rt
>> > svn.
>> > The changes involve defining USING_MAC_INTERPOSE in configure.ac rather
>> > than
>> > rather than USING_MACH_OVERRIDE, introduction of the use of
>> > USING_MAC_INTERPOSE
>> > in Makefile.am to avoid building the interception subdirectory, the
>> > passage of
>> > -DMAC_INTERPOSE_FUNCTIONS in asan/Makefile.am when USING_MAC_INTERPOSE as
>> > well as
>> > the introduction of a -DMISSING_BLOCKS_SUPPORT flag to disable code that
>> > requires
>> > blocks support which FSF gcc lacks. The depreciated usage of
>> > USING_MACH_OVERRIDE
>> > is also removed from interception/Makefile.am. Bootstrapped on
>> > x86_64-apple-darwin10,
>> > x86_64-apple-darwin11 and x86_64-apple-darwin12. Passes...
>> >
>> > make -k check RUNTESTFLAGS="asan.exp --target_board=unix'{-m32,-m64}'"
>> >
>> > and fixes the previously failing cond1.C test case from PR55521 on all
>> > three targets.
>> > Okay for gcc trunk?
>> > Jack
>> >
>>
>>
>>
>> --
>> Alexander Potapenko
>> Software Engineer
>> Google Moscow
--
Alexander Potapenko
Software Engineer
Google Moscow
Re: Simplify a VEC_SELECT from one half of a VEC_CONCAT
On Sun, Dec 2, 2012 at 6:39 PM, Marc Glisse wrote: > While I was there, I decided to improve another bit of VEC_SELECT > simplification (this supersedes the patch in the father of this message). > > Adding Uros in Cc: because I am touching the x86 backend. Sorry to add yet > another insn variant, but I don't see how we can avoid it here. > > The x86 and RTL parts are independent, but the testcases need both. > > bootstrap+testsuite on x86_64-linux. (for next stage1 I assume) > > 2012-12-02 Marc Glisse > > PR target/43147 > PR target/44551 > gcc/ > * simplify-rtx.c (simplify_binary_operation_1) : > Improve VEC_SELECT and VEC_CONCAT subcases. > * config/i386/sse.md (*sse_shufps__single): New. > > gcc/testsuite/ > * gcc.target/i386/pr43147.c: New testcase. > * gcc.target/i386/pr44551.c: New testcase. x86 part and testcases are OK, together with RTL part. I will leave to RTL maintainer if the combined patch is still OK for 4.8. Thanks, Uros.
Re: [Patch, Fortran] PR 55548: SYSTEM_CLOCK with integer(8) provides nanosecond resolution, but only microsecond precision (without -lrt)
On Sun, Dec 2, 2012 at 3:19 PM, Janus Weil wrote: > Hi all, > > since the first version of my SYSTEM_CLOCK patch was not so well > received, I propose here an alternative patch: It does not use a fixed > COUNT_RATE, but adjusts it to match the resolution of the underlying > library function which is used. For the int4 version it additionally > limits COUNT_RATE to 1000, in order to provide a reasonable maximum > timespan. The patch also has the effect that the reported COUNT_RATE > can now depend e.g. on the linker flags used (as does the precision of > the clock: 1 nanosec with -lrt and 1 microsec without). > > Does anyone agree with me that this represents an improvement of the > SYSTEM_CLOCK behavior? Hi, this looks better than the first path, IMHO. I worry slightly that a changing count rate could confuse users, but OTOH I agree you have a point in that the current behavior can give users a false impression of better accuracy than what is actually provided. An issue with the idea of changing count rate is that using an OS API providing some particular resolution doesn't in itself guarantee that the underlying hardware clock is actually capable of that resolution. But I suppose there's not much we can do about that anyway (if one has clock_gettime, one probably also has clock_getres, but at least on Linux that seems to always return 1 ns as the resolution). Unless somebody else has objections, together with a documentation patch and a ChangeLog entry, this is Ok for trunk. (As a follow-up, somebody familiar with Windows could provide some info on what the resolution there is, and can we do something to improve our current implementation; e.g. do both mingw and cygwin provide gettimeofday() or do we really fall back to time()? ) > > Cheers, > Janus > > > > 2012/12/1 Janus Weil : >> Hi all, >> >> here is a straightforward patch for the intrinsic procedure >> SYSTEM_CLOCK. It does two things: >> 1) It reduces the resolution of the int8 version from 1 nanosecond to >> 1 microsecond (COUNT_RATE = 100). >> 2) It adds an int16 version with nanosecond precision. >> >> The motivation for item #1 was mainly that the actual precision is >> usually not better than 1 microsec anyway (unless linking with -lrt). >> This results in SYSTEM_CLOCK giving values whose last three digits are >> zero. One can argue that this is not a dramatic misbehavior, but it >> has disadvantages for certain applications, like e.g. using >> SYSTEM_CLOCK to initialize the random seed in a Monte-Carlo >> simulation. In general, I would say that the value of COUNT_RATE >> should not be larger than the actual precision of the clock used. >> >> Moreover, the microsecond resolution for int8 arguments has the >> advantage that it is compatible with ifort's behavior. Also I think a >> resolution of 1 microsecond is sufficient for most applications. If >> someone really needs more, he can now use the int16 version (and link >> with -lrt). >> >> Regtested on x86_64-unknown-linux-gnu (although we don't actually seem >> to have any test cases for SYSTEM_CLOCK yet). Ok for trunk? >> >> Btw, does it make sense to also add an int2 version? If yes, which >> resolution? Note that most other compilers seem to have an int2 >> version of SYSTEM_CLOCK ... >> >> Cheers, >> Janus >> >> >> 2012-12-01 Janus Weil >> >> PR fortran/55548 >> * gfortran.map (GFORTRAN_1.5): Add _gfortran_system_clock_16. >> * intrinsics/system_clock.c (system_clock_8): Change resolution to >> one microsec. >> (system_clock_16): New function (with nanosecond resolution). >> >> 2012-12-01 Janus Weil >> >> PR fortran/55548 >> * intrinsic.texi (SYSTEM_CLOCK): Update documentation of SYSTEM_CLOCK. >> >> 2012-12-01 Janus Weil >> >> PR fortran/55548 >> * gfortran.dg/system_clock_1.f90: New test case. -- Janne Blomqvist
[PATCH][Revised] Fix PR55521 by switching libsanitizer from mach_overrideto mac interpose functions on darwin
The attached patch eliminates PR 55521/sanitizer by switching libasan on
darwin
from using mach_override to mac function interposition via the importation of
the
asan/dynamic/asan_interceptors_dynamic.cc file from llvm.org's compiler-rt svn.
The changes involve defining USING_MAC_INTERPOSE in configure.ac rather than
rather than USING_MACH_OVERRIDE, introduction of the use of USING_MAC_INTERPOSE
in Makefile.am to avoid building the interception subdirectory, the passage of
-DMAC_INTERPOSE_FUNCTIONS in asan/Makefile.am when USING_MAC_INTERPOSE as well
as
the introduction of a -DMISSING_BLOCKS_SUPPORT flag to disable code that
requires
blocks support which FSF gcc lacks. The depreciated usage of
USING_MACH_OVERRIDE
is also removed from interception/Makefile.am. Bootstrapped on
x86_64-apple-darwin10,
x86_64-apple-darwin11 and x86_64-apple-darwin12. Passes...
make -k check RUNTESTFLAGS="asan.exp --target_board=unix'{-m32,-m64}'"
and fixes the previously failing cond1.C test case from PR55521 on all three
targets.
This revision adjusts the placement of the MAC_INTERPOSE_FUNCTIONS wrappers in
libsanitizer/asan/dynamic/asan_interceptors_dynamic.cc to allow interpose to
operate on those dispatch calls which don't require blocks support.
Okay for gcc trunk?
Jack
ps The switch from mach_override to mac function interposition reduces the
failures
in the g++ testsuite from 841 to 323. While this is higher than the 107 seen
with
x86_64 Fedora 15, the number of failures emitting ASAN:SIGSEGV messages is lower
on darwin at 8 compared to linux at 10.
2012-12-02 Kostya Serebryany k...@google.com
Jack Howarth
/libsanitizer
PR 55521/sanitizer
* configure.ac: Define USING_MAC_INTERPOSE when on darwin.
* Makefile.am: Don't build interception subdir when
USING_MAC_INTERPOSE defined.
* asan/Makefile.am: Pass -DMAC_INTERPOSE_FUNCTIONS and
-DMISSING_BLOCKS_SUPPORT when USING_MAC_INTERPOSE defined.
Compile asan_interceptors_dynamic.cc but not libinterception
when USING_MAC_INTERPOSE defined.
* interception/Makefile.am: Remove usage of USING_MACH_OVERRIDE.
* configure: Regenerated.
* Makefile.in: Likewise.
* asan/Makefile.in: Likewise.
* interception/Makefile.in: Likewise.
* asan/asan_intercepted_functions.h: Use MISSING_BLOCKS_SUPPORT.
* asan/asan_mac.cc: Likewise.
* asan/dynamic/asan_interceptors_dynamic.cc: Migrate from llvm
and use MISSING_BLOCKS_SUPPORT.
Index: libsanitizer/asan/asan_mac.cc
===
--- libsanitizer/asan/asan_mac.cc (revision 194037)
+++ libsanitizer/asan/asan_mac.cc (working copy)
@@ -383,7 +383,7 @@ INTERCEPTOR(void, dispatch_group_async_f
asan_dispatch_call_block_and_release);
}
-#if MAC_INTERPOSE_FUNCTIONS
+#if defined(MAC_INTERPOSE_FUNCTIONS) && !defined(MISSING_BLOCKS_SUPPORT)
// dispatch_async, dispatch_group_async and others tailcall the corresponding
// dispatch_*_f functions. When wrapping functions with mach_override, those
// dispatch_*_f are intercepted automatically. But with dylib interposition
Index: libsanitizer/asan/asan_intercepted_functions.h
===
--- libsanitizer/asan/asan_intercepted_functions.h (revision 194037)
+++ libsanitizer/asan/asan_intercepted_functions.h (working copy)
@@ -203,7 +203,7 @@ DECLARE_FUNCTION_AND_WRAPPER(void, __CFI
DECLARE_FUNCTION_AND_WRAPPER(CFStringRef, CFStringCreateCopy,
CFAllocatorRef alloc, CFStringRef str);
DECLARE_FUNCTION_AND_WRAPPER(void, free, void* ptr);
-#if MAC_INTERPOSE_FUNCTIONS
+#if defined(MAC_INTERPOSE_FUNCTIONS) && !defined(MISSING_BLOCKS_SUPPORT)
DECLARE_FUNCTION_AND_WRAPPER(void, dispatch_group_async,
dispatch_group_t dg,
dispatch_queue_t dq, void (^work)(void));
Index: libsanitizer/asan/Makefile.am
===
--- libsanitizer/asan/Makefile.am (revision 194037)
+++ libsanitizer/asan/Makefile.am (working copy)
@@ -4,6 +4,9 @@ AM_CPPFLAGS = -I $(top_srcdir)/include -
gcc_version := $(shell cat $(top_srcdir)/../gcc/BASE-VER)
DEFS = -D_GNU_SOURCE -D_DEBUG -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS
-D__STDC_LIMIT_MACROS -DASAN_HAS_EXCEPTIONS=1
-DASAN_FLEXIBLE_MAPPING_AND_OFFSET=0 -DASAN_NEEDS_SEGV=1
+if USING_MAC_INTERPOSE
+DEFS += -DMAC_INTERPOSE_FUNCTIONS -DMISSING_BLOCKS_SUPPORT
+endif
AM_CXXFLAGS = -Wall -W -Wno-unused-parameter -Wwrite-strings -pedantic
-Wno-long-long -fPIC -fno-builtin -fno-exceptions -fomit-frame-pointer
-funwind-tables -fvisibility=hidden -Wno-variadic-macros -Wno-c99-extensions
ACLOCAL_AMFLAGS = -I $(top_srcdir) -I $(top_srcdir)/config
@@ -29,8 +32,14 @@ asan_files = \
asan_th
Re: [Patch, Fortran] PR 55548: SYSTEM_CLOCK with integer(8) provides nanosecond resolution, but only microsecond precision (without -lrt)
On Sun, Dec 2, 2012 at 4:46 PM, Tobias Burnus wrote: > Janne Blomqvist wrote: >> >> Needing to link with librt in order to access clock_gettime is an >> unfortunate wart in glibc, but other C libraries exist out there >> (heck, given the success of Android, glibc is certainly a minority >> even if you limit yourself to Linux), and of those that provide >> clock_gettime, most have it directly in libc and not in a separate >> library. > > > I think that has changed in GLIBC 2.17: > http://sourceware.org/git/?p=glibc.git;a=blob_plain;f=NEWS;hb=HEAD Ah, nice! That means we can look forward to 1 ns resolution on Linux systems regardless of whether librt is linked or not; the code is there already in order to support other systems where clock_* is already in libc, so all that is required is a recompile against a newer glibc. As an aside, the reason why we don't unconditionally link in librt is exactly that explained in the link. -- Janne Blomqvist
[patch][c++] Stop in cp_write_global_declarations after writing a PCH
Hello,
The C++ front end pushes everything through the compiler queue after
writing a PCH. This is pointless: After the PCH is written nothing the
compiler does has any effect on it anymore.
This patch makes the C++ front end stop after writing the PCH,
speeding up PCH creation
The C front end has behaved this way since 2004
(http://gcc.gnu.org/ml/gcc-patches/2004-07/msg00738.html).
Bootstrapped&tested on powerpc64-unknown-linux-gnu and x86_64-unknown-linux-gnu.
OK for trunk?
Ciao!
Steven
* decl2.c (cp_write_global_declarations): Return after writing a PCH.
Index: decl2.c
===
--- decl2.c (revision 194052)
+++ decl2.c (working copy)
@@ -3944,8 +3944,13 @@ cp_write_global_declarations (void)
|| !vec_safe_is_empty (decl_namespace_list))
return;
+ /* This is the point to write out a PCH if we're doing that.
+ In that case we do not want to do anything else. */
if (pch_file)
-c_common_write_pch ();
+{
+ c_common_write_pch ();
+ return;
+}
cgraph_process_same_body_aliases ();
Compile time at -O2 (test = patched, orig = unpatched):
$ for i in 1 2 3 ; do time ~/devel/build-test/gcc/xg++
-B../devel/build-test/gcc/ -w -O2 slow.h ; done ; ls -ltr
real0m8.577s
user0m8.037s
sys 0m0.540s
real0m8.580s
user0m8.093s
sys 0m0.484s
real0m8.595s
user0m8.093s
sys 0m0.500s
total 100440
-rw-r--r-- 1 stevenb stevenb 4017783 2012-12-02 21:16 slow.h
-rw-r--r-- 1 stevenb stevenb 98722192 2012-12-02 21:20 slow.h.gch
$ for i in 1 2 3 ; do time ~/devel/build-orig/gcc/xg++
-B../devel/build-orig/gcc/ -w -O2 slow.h ; done ; ls -ltr
real0m10.795s
user0m10.273s
sys 0m0.520s
real0m10.876s
user0m10.365s
sys 0m0.544s
real0m10.767s
user0m10.245s
sys 0m0.520s
total 100440
-rw-r--r-- 1 stevenb stevenb 4017783 2012-12-02 21:16 slow.h
-rw-r--r-- 1 stevenb stevenb 98722192 2012-12-02 21:20 slow.h.gch
Re: [Patch, Fortran] PR 55548: SYSTEM_CLOCK with integer(8) provides nanosecond resolution, but only microsecond precision (without -lrt)
Hi, >> since the first version of my SYSTEM_CLOCK patch was not so well >> received, I propose here an alternative patch: It does not use a fixed >> COUNT_RATE, but adjusts it to match the resolution of the underlying >> library function which is used. For the int4 version it additionally >> limits COUNT_RATE to 1000, in order to provide a reasonable maximum >> timespan. The patch also has the effect that the reported COUNT_RATE >> can now depend e.g. on the linker flags used (as does the precision of >> the clock: 1 nanosec with -lrt and 1 microsec without). >> >> Does anyone agree with me that this represents an improvement of the >> SYSTEM_CLOCK behavior? > > this looks better than the first path, IMHO. I worry slightly that a > changing count rate could confuse users, but OTOH I agree you have a > point in that the current behavior can give users a false impression > of better accuracy than what is actually provided. > > An issue with the idea of changing count rate is that using an OS API > providing some particular resolution doesn't in itself guarantee that > the underlying hardware clock is actually capable of that resolution. > But I suppose there's not much we can do about that anyway (if one has > clock_gettime, one probably also has clock_getres, but at least on > Linux that seems to always return 1 ns as the resolution). > > Unless somebody else has objections, together with a documentation > patch and a ChangeLog entry, this is Ok for trunk. thanks, Janne. Here is an updated patch with docu and ChangeLog. I will wait another day before committing, in order to allow for further comments. Cheers, Janus 2012-12-02 Janus Weil PR fortran/55548 * intrinsics/system_clock.c (gf_gettime_mono): Add argument 'tck', which returns the clock resolution. (system_clock_4): Get resolution from gf_gettime_mono, but limit to 1000/s. (system_clock_8): Get resolution from gf_gettime_mono. 2012-12-02 Janus Weil PR fortran/55548 * intrinsic.texi (SYSTEM_CLOCK): Update documentation of SYSTEM_CLOCK. >> 2012/12/1 Janus Weil : >>> Hi all, >>> >>> here is a straightforward patch for the intrinsic procedure >>> SYSTEM_CLOCK. It does two things: >>> 1) It reduces the resolution of the int8 version from 1 nanosecond to >>> 1 microsecond (COUNT_RATE = 100). >>> 2) It adds an int16 version with nanosecond precision. >>> >>> The motivation for item #1 was mainly that the actual precision is >>> usually not better than 1 microsec anyway (unless linking with -lrt). >>> This results in SYSTEM_CLOCK giving values whose last three digits are >>> zero. One can argue that this is not a dramatic misbehavior, but it >>> has disadvantages for certain applications, like e.g. using >>> SYSTEM_CLOCK to initialize the random seed in a Monte-Carlo >>> simulation. In general, I would say that the value of COUNT_RATE >>> should not be larger than the actual precision of the clock used. >>> >>> Moreover, the microsecond resolution for int8 arguments has the >>> advantage that it is compatible with ifort's behavior. Also I think a >>> resolution of 1 microsecond is sufficient for most applications. If >>> someone really needs more, he can now use the int16 version (and link >>> with -lrt). >>> >>> Regtested on x86_64-unknown-linux-gnu (although we don't actually seem >>> to have any test cases for SYSTEM_CLOCK yet). Ok for trunk? >>> >>> Btw, does it make sense to also add an int2 version? If yes, which >>> resolution? Note that most other compilers seem to have an int2 >>> version of SYSTEM_CLOCK ... >>> >>> Cheers, >>> Janus >>> >>> >>> 2012-12-01 Janus Weil >>> >>> PR fortran/55548 >>> * gfortran.map (GFORTRAN_1.5): Add _gfortran_system_clock_16. >>> * intrinsics/system_clock.c (system_clock_8): Change resolution to >>> one microsec. >>> (system_clock_16): New function (with nanosecond resolution). >>> >>> 2012-12-01 Janus Weil >>> >>> PR fortran/55548 >>> * intrinsic.texi (SYSTEM_CLOCK): Update documentation of SYSTEM_CLOCK. >>> >>> 2012-12-01 Janus Weil >>> >>> PR fortran/55548 >>> * gfortran.dg/system_clock_1.f90: New test case. > > > > -- > Janne Blomqvist pr55548_v3.diff Description: Binary data
Re: [Patch, Fortran] No-op Patch - a.k.a. FINAL wrapper update
Hi Tobias, >> In my version of the patch I introduced a routine 'gfc_is_finalizable' to >> perform this decision. > > > Okay. How about the following patch? It's the same without the renaming. > > Build an regtested on x86-64-linux.* > OK for the trunk? Yes, looks ok to me. Thanks for the patch! Cheers, Janus
Re: New option to turn off stack reuse for temporaries
My first example is not correct --- according to the standard, the
lifetime of the temporary should be extended. The second example is an
user error.
C++ standard says this in 12.2.5:
"
The second context is when a reference is bound to a temporary. The
temporary to which the reference is
bound or the temporary that is the complete object of a subobject to
which the reference is bound persists
for the lifetime of the reference except:
— A temporary bound to a reference member in a constructor’s
ctor-initializer (12.6.2) persists until the
constructor exits.
— A temporary bound to a reference parameter in a function call
(5.2.2) persists until the completion of
the full-expression containing the call.
— The lifetime of a temporary bound to the returned value in a
function return statement (6.6.3) is not
extended; the temporary is destroyed at the end of the full-expression
in the return statement.
— A temporary bound to a reference in a new-initializer (5.3.4)
persists until the completion of the
full-expression containing the new-initializer. [Example:
struct S { int mi; const std::pair& mp; };
S a { 1, {2,3} };
S* p = new S{ 1, {2,3} }; // Creates dangling reference
— end example ] [ Note: This may introduce a dangling reference, and
implementations are encouraged
to issue a warning in such a case. — end note ]
"
David
On Sun, Dec 2, 2012 at 4:31 AM, Olivier Ballereau
wrote:
> Hello David,
>
> Sorry to come so late into the discussion, but...
>
> On 21/06/12 00:50, Xinliang David Li wrote:
>> One of the most common runtime errors we have seen in gcc-4_7 is
>> caused by dangling references to temporaries whole life time have
>> ended
>>
>> e.g,
>>
>> const A& a = foo();
>>
>> or
>> foo (A());// where temp's address is saved and used after foo.
>>
>> Of course this is user error according to the standard,
>> [...]
>
> ... is the first of your 2 examples really a user error? If so, it
> breaks GotW #88: A Candidate For the “Most Important const” [1]. Can you
> please clarify?
>
> Thanks in advance!
> Olivier
>
> [1]
> http://herbsutter.com/2008/01/01/gotw-88-a-candidate-for-the-most-important-const/
>
Go patch committed: Fix nil func calls, constant float type conversions
This patch to the Go frontend fixes two small, unrelated, things.
Calls to a nil func value (corresponding to a NULL function pointer in
C) should panic in Go, and panics should be recoverable. They were not
recoverable in gccgo, because the exception unwinder does not unwind
past a zero PC (because uw_frame_state_for checks for this and returns
_URC_END_OF_STACK). To fix this I added a runtime nil check before
every call through a func value.
I changed the way the code handles explicit conversions of constant
float or complex values. Rather than postponing them to runtime, I use
mpfr_set_prec to reduce the precision as needed.
Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu.
Committed to mainline and 4.7 branch.
Ian
diff -r 623a0f780e0f go/expressions.cc
--- a/go/expressions.cc Fri Nov 30 16:14:46 2012 -0800
+++ b/go/expressions.cc Sun Dec 02 18:57:12 2012 -0800
@@ -2965,46 +2965,6 @@
{
if (!nc.set_type(type, true, location))
return Expression::make_error(location);
-
- // Don't simply convert to or from a float or complex type
- // with a different size. That may change the value.
- Type* vtype = val->type();
- if (vtype->is_abstract())
- ;
- else if (type->float_type() != NULL)
- {
- if (vtype->float_type() != NULL)
- {
- if (type->float_type()->bits() != vtype->float_type()->bits())
- return this;
- }
- else if (vtype->complex_type() != NULL)
- {
- if (type->float_type()->bits() * 2
- != vtype->complex_type()->bits())
- return this;
- }
- }
- else if (type->complex_type() != NULL)
- {
- if (vtype->complex_type() != NULL)
- {
- if (type->complex_type()->bits()
- != vtype->complex_type()->bits())
- return this;
- }
- else if (vtype->float_type() != NULL)
- {
- if (type->complex_type()->bits()
- != vtype->float_type()->bits() * 2)
- return this;
- }
- }
- else if (vtype->float_type() != NULL)
- return this;
- else if (vtype->complex_type() != NULL)
- return this;
-
return nc.expression(location);
}
}
@@ -9239,6 +9199,9 @@
}
}
+ if (func == NULL)
+fn = save_expr(fn);
+
tree ret = build_call_array(excess_type != NULL_TREE ? excess_type : rettype,
fn, nargs, args);
delete[] args;
@@ -9272,6 +9235,24 @@
if (this->results_ != NULL)
ret = this->set_results(context, ret);
+ // We can't unwind the stack past a call to nil, so we need to
+ // insert an explicit check so that the panic can be recovered.
+ if (func == NULL)
+{
+ tree compare = fold_build2_loc(location.gcc_location(), EQ_EXPR,
+ boolean_type_node, fn,
+ fold_convert_loc(location.gcc_location(),
+ TREE_TYPE(fn),
+ null_pointer_node));
+ tree crash = build3_loc(location.gcc_location(), COND_EXPR,
+ void_type_node, compare,
+ gogo->runtime_error(RUNTIME_ERROR_NIL_DEREFERENCE,
+ location),
+ NULL_TREE);
+ ret = fold_build2_loc(location.gcc_location(), COMPOUND_EXPR,
+ TREE_TYPE(ret), crash, ret);
+}
+
this->tree_ = ret;
return ret;
@@ -14229,7 +14210,7 @@
bool
Numeric_constant::check_float_type(Float_type* type, bool issue_error,
- Location location) const
+ Location location)
{
mpfr_t val;
switch (this->classification_)
@@ -14282,6 +14263,29 @@
}
ret = exp <= max_exp;
+
+ if (ret)
+ {
+ // Round the constant to the desired type.
+ mpfr_t t;
+ mpfr_init(t);
+ switch (type->bits())
+ {
+ case 32:
+ mpfr_set_prec(t, 24);
+ break;
+ case 64:
+ mpfr_set_prec(t, 53);
+ break;
+ default:
+ go_unreachable();
+ }
+ mpfr_set(t, val, GMP_RNDN);
+ mpfr_set(val, t, GMP_RNDN);
+ mpfr_clear(t);
+
+ this->set_float(type, val);
+ }
}
mpfr_clear(val);
@@ -14296,7 +14300,7 @@
bool
Numeric_constant::check_complex_type(Complex_type* type, bool issue_error,
- Location location) const
+ Location location)
{
if (type->is_abstract())
return true;
@@ -14315,46 +14319,77 @@
}
mpfr_t real;
+ mpfr_t imag;
switch (this->classification_)
{
case NC_INT:
case NC_RUNE:
mpfr_init_set_z(real, this->u_.int_val, GMP_RNDN);
+ mpfr_init_set_ui(imag, 0, GMP_RNDN);
break;
case NC_FLOAT:
mpfr_init_set(real, this->u_.float_val, GMP_RNDN);
+ mpfr_init_set_ui(imag, 0, GMP_RNDN);
break;
case NC_COMPLEX:
- if (!mpfr_nan_p(this->u_.complex_val.imag)
- && !mpfr_inf_p(this->u_.complex_val.imag)
- && !mpfr_zero_p(this->u_.complex_val.imag))
- {
- if (mpfr_get_exp(this->u_.complex_val.imag) > max_exp)
- {
- if (issue_error)
- error_at(location, "complex imaginary part overflow");
- return false;
- }
- }
mpfr_init_set(real, this->u_.complex_val.real, GMP_RNDN);
+ mpfr_init_set(imag, this->u_.complex_val.imag, GMP_RNDN);
Re: [patch]: 3 of 7 Fix of PR target/53912 bootstrap fails using default c++ mode in stage 2 and 3 for native x86_64-w64-mingw32
On Thu, Nov 29, 2012 at 4:07 AM, Kai Tietz wrote: > > 2012-11-29 Kai Tietz > > PR target/53912 > * pointer-set.c (hash1): Cast from pointer via uintptr_t. This is OK. Thanks. Ian
Re: [patch tree-dump.c]: 7 of 7 Fix of PR target/53912 bootstrap fails using default c++ mode in stage 2 and 3 for native x86_64-w64-mingw32
On Thu, Nov 29, 2012 at 5:40 AM, Kai Tietz wrote:
> Updated variant using HOST_WIDE_INT_PRINT.
>
> Tested for i686-w64-mingw32 and x86_64-w64-mingw32. Ok for apply?
>
> Kai
>
> Index: tree-dump.c
> ===
> --- tree-dump.c (Revision 193925)
> +++ tree-dump.c (Arbeitskopie)
> @@ -177,7 +177,8 @@ void
> dump_pointer (dump_info_p di, const char *field, void *ptr)
> {
>dump_maybe_newline (di);
> - fprintf (di->stream, "%-4s: %-8lx ", field, (unsigned long) ptr);
> + fprintf (di->stream, "%-4s: %-8" HOST_WIDE_INT_PRINT "x ", field,
> + (HOST_WIDE_INT) (uintptr_t) ptr);
>di->column += 15;
> }
You should cast to (unsigned HOST_WIDE_INT), not (HOST_WIDE_INT). The
%x printf conversion specifier expects an unsigned type. This is OK
with that change and a ChangeLog entry.
Ian
Re: [patch]: 2 of 7 Fix of PR target/53912 bootstrap fails using default c++ mode in stage 2 and 3 for native x86_64-w64-mingw32
On Thu, Nov 29, 2012 at 4:05 AM, Kai Tietz wrote: > > 2012-11-29 Kai Tietz > > PR target/53912 > * ggc-common.c (POINTER_HASH): Cast from pointer via intptr_t. This is OK. Thanks. Ian
Go patch committed: Don't encode non-ASCII characters in identifiers
Go permits non-ASCII characters in identifiers. A long time ago I
thought I needed to encode those before passing them to GIMPLE. Looking
at the -fextended-identifiers support, I see that that should not be
true. This patch removes the encoding. This should give a better
debugging experience and will fix the names used in type reflection.
Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu.
Committed to mainline.
Ian
diff -r c2163c885896 go/lex.cc
--- a/go/lex.cc Sun Dec 02 19:23:21 2012 -0800
+++ b/go/lex.cc Sun Dec 02 22:49:14 2012 -0800
@@ -915,12 +915,8 @@
}
if (is_invalid && !Lex::is_invalid_identifier(buf))
buf.append("$INVALID$");
+ buf.append(p, pnext - p);
p = pnext;
- char ubuf[50];
- // This assumes that all assemblers can handle an identifier
- // with a '$' character.
- snprintf(ubuf, sizeof ubuf, "$U%x$", ci);
- buf.append(ubuf);
}
}
Location location = this->location();
Re: [PATCH] asan unit tests from llvm lit-test
Looks good.
Long term the fact that we need to completely fork these tests makes me sad.
I'd really love to see a way to make them compiler-neutral.
All we need is to mock FileCheck (or put it into libsanitizer/aux somehow).
Ideas?
--kcc
On Sat, Dec 1, 2012 at 12:35 AM, Wei Mi wrote:
> Thanks for the comments! Here is the second version patch. Please see
> if it is ok.
> (-Wno-attributes is kept or else we will get a warning because of
> __attribute__((always_inline))).
>
> These tests are excluded for now because unsupported features or needs
> some twists to be included.
> blacklist-1.c (use -asan-blacklist=)
> initialization-blacklist-1.C (use -asan-blacklist=)
> initialization-bug-1.c(use -asan-initialization-order)
> initialization-nobug-1.C (use -asan-initialization-order)
> initialization-bug-any-order.cc (use -asan-initialization-order)
> interface-symbols-1.c (needs to be added to
> libsanitizer/Makefile.am)
> log-path_test.cc (needs to twist dg-final
> commands, skip for now)
>
> Test results:
> gcc summary
> # of expected passes248
> # of unexpected failures39
> # of unsupported tests 27
>
> g++ summary
> # of expected passes468
> # of unexpected failures56
> # of unsupported tests 50
>
> Thanks,
> Wei.
>
> On Wed, Nov 28, 2012 at 2:14 AM, Jakub Jelinek wrote:
>> Hi!
>>
>> On Wed, Nov 28, 2012 at 01:15:20AM -0800, Wei Mi wrote:
>>> I try to migrate the left asan lit-tests from llvm (class3). This is a
>>> preliminary version patch. Please forgive it has many mistakes.
>>
>> Thanks for working on it.
>>
>>> A known problems: I hardcoded -m32 in (set link_flags
>>> "[asan_link_flags [get_multilibs -m32]] $link_flags") in
>>> gcc/testsuite/lib/asan-dg.exp to make 32 bit library path included in
>>> ld_library_path. I don't know the elegant way to fix it.
>>
>> That is wrong, no *.exp file should do anything with -m32/-m64.
>> If user wants to test both -m32 and -m64, it should be done through
>> RUNTESTFLAGS='--target_board=unix\{-m32,-m64\}'
>> on the command line of make check if desired (or any other options deemed
>> necessary to test). Not all targets support both -m32 and -m64 (e.g. even
>> i686-linux doesn't), some targets have other ABI options (e.g. -m31/-m64 on
>> s390x, mips has more variants, etc.). It must be user's choice what he
>> wants to test for what multilibs.
>>
>>> * g++.dg/asan/linux: New, migrate from llvm asan lit-test.
>>> * g++.dg/asan/linux/interception-test-1.C: Likewise.
>>> * g++.dg/asan/linux/interception-failure-test-1.C: Likewise.
>>> * g++.dg/asan/linux/interception-malloc-test-1.C: Likewise.
>>
>> Why the linux/ subdirectories (which you seem to run for all targets
>> anyway)? That doesn't make any sense. All tests that won't run on certain
>> targets because of some required features (whether it is e.g. dlopen, mmap,
>> pthreads) should be guarded, e.g.
>> // { dg-require-effective-target pthread }
>> or
>> /* { dg-run { target pthread } } */
>> and similar. If some check_effective_target_* tcl test is missing, it can
>> be always added (e.g. dlopen doesn't have any, and you can't assume dlopen
>> works everywhere).
>>
>>> * g++.dg/asan/Helpers: Likewise.
>>> * g++.dg/asan/Helpers/initialization-blacklist-1.tmp: Likewise.
>>> * g++.dg/asan/Helpers/initialization-blacklist-extra-1.C: Likewise.
>>
>> We aren't a CamelCase shop, I'd strongly prefer if we could avoid that
>> ugliness. Ditto for SharedLibs/ etc. subdirs. And why you need the subdirs
>> at all? The usual way how to handle e.g. the dg-additional-sources is just
>> make sure the additional sources are either named in a way that doesn't
>> match the normal wildcard (for C++ e.g. *.cc instead of *.C) or add some dg
>> directive in there that it won't run, or be dg-do compile only test etc.
>>
>>> +if { [string match "*blacklist-1.c" $source] } {
>>> + set blacklist_options $options
>>> + set blist_tmp [glob
>>> $srcdir/c-c++-common/asan/Helpers/blacklist-1.tmp]
>>> + lappend blacklist_options
>>> "additional_flags=-asan-blacklist=$blist_tmp"
>>> + set result [eval [list saved_asan_target_compile $source $dest $type
>>> $blacklist_options]]
>>> + return $result
>>> +} elseif { [string match "*interface-symbols-1.c" $source] } {
>>> + set result [eval [list saved_asan_target_compile \
>>> +$source "interface-symbols-1.exe" \
>>> +"executable" $options]]
>>> + if { [string match "" $result] } {
>>> +set exefile [glob interface-symbols-1.exe]
>>> +set asan_interface_h [glob
>>> $srcdir/../../libsanitizer/include/sanitizer/asan_interface.h]
>>> +set script [glob
>>> $srcdir/c-c++-common/asan/Helpers/interface_symbols.sh]
>>> +set diff_result [exec sh $scri
Go patch committed: Fix field tracking in global var initializer
This patch to the Go compiler avoids a crash if a tracked field is referenced in the initializer for a global variable. Bootstrapped on x86_64-unknown-linux-gnu. Committed to mainline. Ian diff -r 879fac2f2103 go/expressions.cc --- a/go/expressions.cc Sun Dec 02 22:55:02 2012 -0800 +++ b/go/expressions.cc Sun Dec 02 23:19:27 2012 -0800 @@ -10651,7 +10651,8 @@ // them if they are not referenced. The effect is that the only // strings, indicating field references, that will wind up in the // executable will be those for functions that are actually needed. - function->func_value()->set_in_unique_section(); + if (function != NULL) +function->func_value()->set_in_unique_section(); var->set_in_unique_section(); return this;
Re: [PATCH][Revised] Fix PR55521 by switching libsanitizer from mach_overrideto mac interpose functions on darwin
Hi Jack,
May I ask you to attach the complete patch (with ChangeLog entries and
regenerated files, if possible)?
May I also ask you to update libsanitizer/merge.sh to handle
libsanitizer/asan/dynamic ?
Assuming the files from upstream are copied verbatim (are they?), the
patch is ok.
Still, please give Alex (gli...@google.com) a chance to review it as well.
Thanks,
--kcc
On Mon, Dec 3, 2012 at 12:09 AM, Jack Howarth wrote:
>The attached patch eliminates PR 55521/sanitizer by switching libasan on
> darwin
> from using mach_override to mac function interposition via the importation of
> the
> asan/dynamic/asan_interceptors_dynamic.cc file from llvm.org's compiler-rt
> svn.
> The changes involve defining USING_MAC_INTERPOSE in configure.ac rather than
> rather than USING_MACH_OVERRIDE, introduction of the use of
> USING_MAC_INTERPOSE
> in Makefile.am to avoid building the interception subdirectory, the passage of
> -DMAC_INTERPOSE_FUNCTIONS in asan/Makefile.am when USING_MAC_INTERPOSE as
> well as
> the introduction of a -DMISSING_BLOCKS_SUPPORT flag to disable code that
> requires
> blocks support which FSF gcc lacks. The depreciated usage of
> USING_MACH_OVERRIDE
> is also removed from interception/Makefile.am. Bootstrapped on
> x86_64-apple-darwin10,
> x86_64-apple-darwin11 and x86_64-apple-darwin12. Passes...
>
> make -k check RUNTESTFLAGS="asan.exp --target_board=unix'{-m32,-m64}'"
>
> and fixes the previously failing cond1.C test case from PR55521 on all three
> targets.
> This revision adjusts the placement of the MAC_INTERPOSE_FUNCTIONS wrappers in
> libsanitizer/asan/dynamic/asan_interceptors_dynamic.cc to allow interpose to
> operate on those dispatch calls which don't require blocks support.
> Okay for gcc trunk?
> Jack
> ps The switch from mach_override to mac function interposition reduces the
> failures
> in the g++ testsuite from 841 to 323. While this is higher than the 107 seen
> with
> x86_64 Fedora 15, the number of failures emitting ASAN:SIGSEGV messages is
> lower
> on darwin at 8 compared to linux at 10.
>
