Re: Question about fold C_MAYBE_CONST_EXPR expressions
On Sun, Jul 24, 2016 at 11:04 PM, Prathamesh Kulkarni wrote: > On 24 July 2016 at 21:26, Bin.Cheng wrote: >> Hi, >> I ran into a problem that C frontend (in function >> build_conditional_expr) creates expression like (C_MAYBE_CONST_EXPR >> (NULL, x + const)). The inner expression (and its operands) have >> unsigned int type. After that, the expression needs to be casted to >> result type which is unsigned short. In this case, >> convert_to_integer/convert_to_integer_1 doesn't fold into >> C_MAYBE_CONST_EXPR and just returns (unsigned >> short)(C_MAYBE_CONST_EXPR (NULL, x + const)), as a result, (unsigned >> short)(x + const) won't be simplified as (unsigned short)x + const. >> My questions are, 1) Is it possible to fold type conversion into >> C_MAYBE_CONST_EXPR's inner expression in convert_to_integer_1? 2) If >> not, looks like there are couple of places the mentioned fold can be >> done, for example, after stripping C_MAYBE_CONST_EXPR and before (or >> during) gimplify. So which place is preferred? > Sorry, I have a very silly question: > I don't understand how the following transform > (unsigned short) (x + const) to (unsigned short)x + const would be legal > since the operands to PLUS_EXPR in latter case would have different types > (unsigned short, unsigned) ? > I suppose in GIMPLE (and GENERIC too?) > we require rhs1 and rhs2 to have same types ? I skipped type information for the const operand, of course the const will be converted to unsigned short which is the type for computation. Thanks, bin
Thread-safety of a profiled binary (and GCOV runtime library)
Hello. I've just analyzed PR68080, which exposes 2 interesting problems we have: 1) Majority of instrumented profiling code is not thread-safe, for instance edge profiler: PROF_edge_counter_11 = __gcov0._ZL20__gthread_mutex_lockP15pthread_mutex_t[0]; PROF_edge_counter_12 = PROF_edge_counter_11 + 1; __gcov0._ZL20__gthread_mutex_lockP15pthread_mutex_t[0] = PROF_edge_counter_12; I'm thinking about introducing a param (maybe option), that would instrument counter manipulation in a thread-safe way: __sync_fetch_and_add_8 (&__gcov0._ZL20__gthread_mutex_lockP15pthread_mutex_t[0], 1); That would also require very similar support for gcov run-time library. 2) The test-case creates a detached thread which is not properly joined. In such situation, the main thread reaches gcov_exit, calculates for instance PROFILE_SUMMARY and serializes counters to a file. However, as the created thread is still running, counters are still updated. The leads to a corrupted profile file. I'm wondering whether to prevent that? I can imagine we can lock the streaming code, where any profile updating thread would not be allowed to do that. Thanks, Martin
Re: possibly dead call from slsr_process_phi () to gimple_bb ()
On Mon, 25 Jul 2016, Prathamesh Kulkarni wrote: > Hi, > I am trying to write a WIP patch to warn for dead function calls, > and incidentally it caught the following dead call to gimple_bb() from > slsr_process_phi () in gimple-ssa-strength-reduction.c: > > if (SSA_NAME_IS_DEFAULT_DEF (arg)) >arg_bb = single_succ (ENTRY_BLOCK_PTR_FOR_FN (cfun)); > else >gimple_bb (SSA_NAME_DEF_STMT (arg)); > > Presumably it should be: > arg_bb = gimple_bb (SSA_NAME_DEF_STMT (arg)) ? Looks like so. Bill should know. Richard. > Thanks, > Prathamesh > > -- Richard Biener SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg)
Symbian support
I would ask to not remove existing support for Symbian. It's possible build and run app with gcc 5 series. I downloaded source code for gcc from gcc main page. Binutil was downloaded from main page. Version binutils - 2.25, 2.25.1, 2.26. Build script - https://github.com/fedor4ever/GCCE4Symbian/blob/master/build-toolchain.sh . GCC 6.1.0 inserts call to __sync_synchronize and linker fails with error: undefined reference to `__sync_synchronize'. If this is bug I can send preprocessed file. Always yours, Fiodar Stryzniou
Re: Symbian support
On 25/07/16 12:37, fedor...@mail.ru wrote: > GCC 6.1.0 inserts call to __sync_synchronize and linker fails with > error: undefined reference to `__sync_synchronize'. If this is bug I > can send preprocessed file. This is something that you can provide yourself. If it's a single-core cpu the function can be empty. Either that or you can build your program with a -mcpu= option which names a recent x86 processor. Andrew.
Mirror out of date
The mirror here: ftp://mirrors-usa.go-parts.com/gcc/releases/ Does not have gcc 6 from April.
Re: possibly dead call from slsr_process_phi () to gimple_bb ()
> On Jul 25, 2016, at 4:04 AM, Richard Biener wrote: > > On Mon, 25 Jul 2016, Prathamesh Kulkarni wrote: > >> Hi, >> I am trying to write a WIP patch to warn for dead function calls, >> and incidentally it caught the following dead call to gimple_bb() from >> slsr_process_phi () in gimple-ssa-strength-reduction.c: >> >> if (SSA_NAME_IS_DEFAULT_DEF (arg)) >> arg_bb = single_succ (ENTRY_BLOCK_PTR_FOR_FN (cfun)); >> else >> gimple_bb (SSA_NAME_DEF_STMT (arg)); >> >> Presumably it should be: >> arg_bb = gimple_bb (SSA_NAME_DEF_STMT (arg)) ? > > Looks like so. Bill should know. Certainly looks that way. I'll get that cleaned up. Thanks for the report! Bill > > Richard. > >> Thanks, >> Prathamesh >> >> > > -- > Richard Biener > SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB > 21284 (AG Nuernberg) >
Re: Thread-safety of a profiled binary (and GCOV runtime library)
On 07/25/16 04:14, Martin Liška wrote: Hello. I've just analyzed PR68080, which exposes 2 interesting problems we have: 1) Majority of instrumented profiling code is not thread-safe, for instance edge profiler: PROF_edge_counter_11 = __gcov0._ZL20__gthread_mutex_lockP15pthread_mutex_t[0]; PROF_edge_counter_12 = PROF_edge_counter_11 + 1; __gcov0._ZL20__gthread_mutex_lockP15pthread_mutex_t[0] = PROF_edge_counter_12; I'm thinking about introducing a param (maybe option), that would instrument counter manipulation in a thread-safe way: __sync_fetch_and_add_8 (&__gcov0._ZL20__gthread_mutex_lockP15pthread_mutex_t[0], 1); Agreed. (I'm frankly surprised people have got by without it for so long). Perhaps the existence of an existing threading flag on the command line is sufficient to clue the gcov machinery? I dislike inventing new knobs to twiddle. 2) The test-case creates a detached thread which is not properly joined. In such situation, the main thread reaches gcov_exit, calculates for instance PROFILE_SUMMARY and serializes counters to a file. However, as the created thread is still running, counters are still updated. The leads to a corrupted profile file. I'm wondering whether to prevent that? I can imagine we can lock the streaming code, where any profile updating thread would not be allowed to do that. An interesting problem. Conceptually one would want the detatched thread to stop instrumenting -- or instrument to its own set of counters. Neither's really doable within the existing machinery. Grabbing a lock for every counter update is going to be very expensive. Your phrasing of the problem might be enlightening. 'which is not *properly* joined'. I.e. don't do that. nathan
Re: Thread-safety of a profiled binary (and GCOV runtime library)
On Mon, Jul 25, 2016 at 2:06 PM, Nathan Sidwell wrote: > On 07/25/16 04:14, Martin Liška wrote: >> >> Hello. >> >> I've just analyzed PR68080, which exposes 2 interesting problems we have: >> >> 1) Majority of instrumented profiling code is not thread-safe, for >> instance edge profiler: >> >> PROF_edge_counter_11 = >> __gcov0._ZL20__gthread_mutex_lockP15pthread_mutex_t[0]; >> PROF_edge_counter_12 = PROF_edge_counter_11 + 1; >> __gcov0._ZL20__gthread_mutex_lockP15pthread_mutex_t[0] = >> PROF_edge_counter_12; >> >> I'm thinking about introducing a param (maybe option), that would >> instrument counter manipulation >> in a thread-safe way: >> >> __sync_fetch_and_add_8 >> (&__gcov0._ZL20__gthread_mutex_lockP15pthread_mutex_t[0], 1); > > > Agreed. (I'm frankly surprised people have got by without it for so long). > Perhaps the existence of an existing threading flag on the command line is > sufficient to clue the gcov machinery? I dislike inventing new knobs to > twiddle. > >> 2) The test-case creates a detached thread which is not properly joined. >> In such situation, the main >> thread reaches gcov_exit, calculates for instance PROFILE_SUMMARY and >> serializes counters to a file. >> However, as the created thread is still running, counters are still >> updated. The leads to a corrupted >> profile file. >> >> I'm wondering whether to prevent that? I can imagine we can lock the >> streaming code, where any profile >> updating thread would not be allowed to do that. > > > An interesting problem. Conceptually one would want the detatched thread to > stop instrumenting -- or instrument to its own set of counters. Neither's > really doable within the existing machinery. Grabbing a lock for every > counter update is going to be very expensive. > > Your phrasing of the problem might be enlightening. 'which is not > *properly* joined'. I.e. don't do that. There's pthread_detach () - do we wrap that appropriately? That said, another way to make counters thread-safe is to allocate per-thread counters and update those (for example by making the counters __TLS). The interesting part is then to merge them with the main set of counters during thread exit (properly locked or atomically of course). This would also solve the above mentioned issue but have quite a cost on the memory side. Richard. > > nathan
Re: Thread-safety of a profiled binary (and GCOV runtime library)
On 07/25/16 08:14, Richard Biener wrote: There's pthread_detach () - do we wrap that appropriately? That said, another way to make counters thread-safe is to allocate per-thread counters and update those (for example by making the counters __TLS). The interesting part is then to merge them with the main set of counters during thread exit (properly locked or atomically of course). This would also solve the above mentioned issue but have quite a cost on the memory side. I'm not aware of any of the pthread fns being wrapped. (IIRC it's fork, execFOO and exit). As you say, having TLS counters would increase memory, but I have no feel for the relative increase it might be in codebases it'd affect. Compute-wise it's probably no more expensive than using atomic adds, probably cheaper, if the atomic ops are fn calls. nathan
Re: Thread-safety of a profiled binary (and GCOV runtime library)
On 07/25/2016 02:06 PM, Nathan Sidwell wrote: > On 07/25/16 04:14, Martin Liška wrote: >> Hello. >> >> I've just analyzed PR68080, which exposes 2 interesting problems we have: >> >> 1) Majority of instrumented profiling code is not thread-safe, for instance >> edge profiler: >> >> PROF_edge_counter_11 = >> __gcov0._ZL20__gthread_mutex_lockP15pthread_mutex_t[0]; >> PROF_edge_counter_12 = PROF_edge_counter_11 + 1; >> __gcov0._ZL20__gthread_mutex_lockP15pthread_mutex_t[0] = >> PROF_edge_counter_12; >> >> I'm thinking about introducing a param (maybe option), that would instrument >> counter manipulation >> in a thread-safe way: >> >> __sync_fetch_and_add_8 >> (&__gcov0._ZL20__gthread_mutex_lockP15pthread_mutex_t[0], 1); > > Agreed. (I'm frankly surprised people have got by without it for so long). > Perhaps the existence of an existing threading flag on the command line is > sufficient to clue the gcov machinery? I dislike inventing new knobs to > twiddle. I'm also surprised about it :) Let's start without invention of a new flag, I'll work on that. > >> 2) The test-case creates a detached thread which is not properly joined. In >> such situation, the main >> thread reaches gcov_exit, calculates for instance PROFILE_SUMMARY and >> serializes counters to a file. >> However, as the created thread is still running, counters are still updated. >> The leads to a corrupted >> profile file. >> >> I'm wondering whether to prevent that? I can imagine we can lock the >> streaming code, where any profile >> updating thread would not be allowed to do that. > > An interesting problem. Conceptually one would want the detatched thread to > stop instrumenting -- or instrument to its own set of counters. Neither's > really doable within the existing machinery. Grabbing a lock for every > counter update is going to be very expensive. I like the idea sketched by Richard, utilizing TLS and merging counters, which fundamentally the same as merging with existing gcov file. However, I would put this lower priority than the former problem. Martin > > Your phrasing of the problem might be enlightening. 'which is not > *properly* joined'. I.e. don't do that. > > > nathan
Need help with PR71976 combine.c::get_last_value returns a wrong result
Tracking this wrong-code bug, I ended up in combine.c::get_last_value() which
returns a wrong result. gcc generates wrong code at least with: 4.9 head, 5.2,
6.1 and trunk from today.
Before combine we have:
(insn 43 31 44 2 (set (reg:QI 18 r18)
(const_int 0 [0])) bug-combin.c:29 56 {movqi_insn}
(nil))
(insn 44 43 45 2 (set (reg:QI 19 r19 [+1 ])
(const_int 0 [0])) bug-combin.c:29 56 {movqi_insn}
(nil))
(insn 45 44 46 2 (set (reg:QI 20 r20 [+2 ])
(const_int 0 [0])) bug-combin.c:29 56 {movqi_insn}
(nil))
(insn 46 45 47 2 (set (reg:QI 21 r21 [+3 ])
(const_int 0 [0])) bug-combin.c:29 56 {movqi_insn}
(nil))
(insn 47 46 48 2 (set (reg:QI 22 r22 [+4 ])
(const_int 0 [0])) bug-combin.c:29 56 {movqi_insn}
(nil))
(insn 48 47 49 2 (set (reg:QI 23 r23 [+5 ])
(reg:QI 65 [ _3+5 ])) bug-combin.c:29 56 {movqi_insn}
(nil))
(insn 49 48 50 2 (set (reg:QI 24 r24 [+6 ])
(reg:QI 66 [ _3+6 ])) bug-combin.c:29 56 {movqi_insn}
(nil))
(insn 50 49 51 2 (set (reg:QI 25 r25 [+7 ])
(reg:QI 67 [ _3+7 ])) bug-combin.c:29 56 {movqi_insn}
(nil))
(insn 51 50 52 2 (set (reg:QI 16 r16)
(const_int 40 [0x28])) bug-combin.c:29 56 {movqi_insn}
(nil))
(insn 52 51 61 2 (set (reg:DI 18 r18)
(ashiftrt:DI (reg:DI 18 r18)
(reg:QI 16 r16))) bug-combin.c:29 1417 {ashrdi3_insn}
(expr_list:REG_DEAD (reg:QI 16 r16)
(nil)))
insn-combine combines 51 -> 52 and then tries to simplify the resulting
(ashiftrt:DI (reg:DI 18 r18) (const_int 40)) in
simplify_shift_const_1 (code=ASHIFTRT, result_mode=DImode,
varop=0x7734ee70, orig_count=40) at
../../../gcc.gnu.org/trunk/gcc/combine.c:10181
note that reg:DI 18 is a hard register. In that function, the following piece
of code triggers which turns the shift offset from 40 to 0:
(gdb) p varop
$95 = (rtx) 0x7734ee70
(gdb) pr
(reg:DI 18 r18)
/* An arithmetic right shift of a quantity known to be -1 or 0
is a no-op. */
if (code == ASHIFTRT
&& (num_sign_bit_copies (varop, shift_mode)
== GET_MODE_PRECISION (shift_mode)))
{
count = 0;
break;
}
num_sign_bit_copies() eventually calls
combine.c::reg_num_sign_bit_copies_for_combine()
which returns const0_rtx because reg 18 is set in insn 43 to const0_rtx. Total
outcome is that the right shift of reg:DI 18 is transformed to a no-op move and
cancelled out in the remainder.
IIUC get_last_value should return 0 in this case?
/* If we don't have a value, or if it isn't for this basic block and
it's either a hard register, set more than once, or it's a live
at the beginning of the function, return 0.
Because if it's not live at the beginning of the function then the reg
is always set before being used (is never used without being set).
And, if it's set only once, and it's always set before use, then all
uses must have the same last value, even if it's not from this basic
block. */
if (value == 0
|| (rsp->last_set_label < label_tick_ebb_start
&& (regno < FIRST_PSEUDO_REGISTER
|| regno >= reg_n_sets_max
|| REG_N_SETS (regno) != 1
|| REGNO_REG_SET_P
(DF_LR_IN (ENTRY_BLOCK_PTR_FOR_FN (cfun)->next_bb), regno
return 0;
value is const_int 0
rsp->last_set_label is 2
label_tick_ebb_start is 1
so that the test "regno < FIRST_PSEUDO_REGISTER" never applies...
It follows
get_last_value_validate (loc=0x7fff8ee0, insn=0x7730cc00, tick=2,
replace=0) at ../../../gcc.gnu.org/trunk/gcc/combine.c:13062
(gdb) p insn
$5 = (rtx_insn *) 0x7730cc00
(gdb) pr
(insn 43 31 44 2 (set (reg:QI 18 r18)
(const_int 0 [0])) bug-combin.c:29 56 {movqi_insn}
(nil))
(gdb) p *loc
$6 = (rtx) 0x773094f0
(gdb) pr
(const_int 0 [0])
The comment of that function read:
/* Verify that all the registers and memory references mentioned in *LOC are
still valid. *LOC was part of a value set in INSN when label_tick was
equal to TICK. Return 0 if some are not. If REPLACE is nonzero, replace
the invalid references with (clobber (const_int 0)) and return 1. This
replacement is useful because we often can get useful information about
the form of a value (e.g., if it was produced by a shift that always
produces -1 or 0) even though we don't know exactly what registers it
was produced from. */
static int
get_last_value_validate (rtx *loc, rtx_insn *insn, int tick, int replace)
{
which does not make sense if *loc is a const_int because it has no "register"
or "memory references".
Which place of get_last_value should handle such sets of hard regs, and how?
Should get_last_value_validate be called for const0_rtx ?
Johann
Re: Thread-safety of a profiled binary (and GCOV runtime library)
On 07/25/16 08:28, Martin Liška wrote: I'm also surprised about it :) Let's start without invention of a new flag, I'll work on that. As using atomic add doesn't result in a change to the libgcov interface or structures, that's probably the best first approach. (It also probably gets the 90% case). thanks! I like the idea sketched by Richard, utilizing TLS and merging counters, which fundamentally the same as merging with existing gcov file. However, I would put this lower priority than the former problem. Richard's suggestion is interesting, and as it solves both problems it may be worth a quick experiment? Perhaps the memory cost isn't so overwhelming? After all, it'd be roughly the same per-thread cost as the current gcov counters are for the single threaded app they're designed for. nathan
Re: Thread-safety of a profiled binary (and GCOV runtime library)
On Mon, Jul 25, 2016 at 2:35 PM, Nathan Sidwell wrote:
> On 07/25/16 08:28, Martin Liška wrote:
>
>> I'm also surprised about it :) Let's start without invention of a new
>> flag, I'll work on that.
>
>
> As using atomic add doesn't result in a change to the libgcov interface or
> structures, that's probably the best first approach. (It also probably gets
> the 90% case). thanks!
>
>
>> I like the idea sketched by Richard, utilizing TLS and merging counters,
>> which fundamentally the same as merging with existing gcov file.
>> However, I would put this lower priority than the former problem.
>
>
> Richard's suggestion is interesting, and as it solves both problems it may
> be worth a quick experiment? Perhaps the memory cost isn't so overwhelming?
> After all, it'd be roughly the same per-thread cost as the current gcov
> counters are for the single threaded app they're designed for.
I think in the end implementing both and letting the user choose is
probably best.
So if we add an option make sure to use -fgcov-counter-type={simple,atomic,tls}
and thus sth extensible (with more options). Not sure if using atomics where
there is native support by default has a small enough overhead to be reasonable
(like on x86_64-linux). Only measurements will tell, of course.
ISTR some targts have limitations on the TLS segment size as well.
There is also the question about optimization - we go great lengths to ensure
that for example loop store motion applies to counter updates so we get
old_ctr = values[42];
for (;;)
...
values[42] = old_ctr + # iterations
using atomics there might show that we have no facility to optimize atomics
at all (given their usual semantics is to include some kind of barrier).
Richard.
> nathan
Re: Thread-safety of a profiled binary (and GCOV runtime library)
On 07/25/16 08:46, Richard Biener wrote: There is also the question about optimization - we go great lengths to ensure that for example loop store motion applies to counter updates so we get old_ctr = values[42]; for (;;) ... values[42] = old_ctr + # iterations using atomics there might show that we have no facility to optimize atomics at all (given their usual semantics is to include some kind of barrier). Hm, that suggests something along the lines of __builtin_gcov_add() and an associated optimization ... nathan
RE: Symbian support
I build for arm cpu. How write this function? Where I can see example implementation? GCC builded with multilib support. Always yours, Fiodar Stryzniou исходное сбщ Тема: Re: Symbian support От: Andrew Haley Дата: 25.07.2016 14.45 On 25/07/16 12:37, fedor...@mail.ru wrote: > GCC 6.1.0 inserts call to __sync_synchronize and linker fails with > error: undefined reference to `__sync_synchronize'. If this is bug I > can send preprocessed file. This is something that you can provide yourself. If it's a single-core cpu the function can be empty. Either that or you can build your program with a -mcpu= option which names a recent x86 processor. Andrew.
Re: Symbian support
On 25/07/16 14:17, fedor...@mail.ru wrote: > I build for arm cpu. How write this function? Where I can see example > implementation? GCC builded with multilib support. If your ARM cpu has only one core, the function can be empty. If it has more than one core, then you must tell GCC which model of ARM it is and GCC will generate the appropriate instruction. It's a DMB instruction. Andrew.
RE: [RFC v2] MIPS ABI Extension for IEEE Std 754 Non-Compliant Interlinking
On Thu, 14 Jul 2016, Maciej W. Rozycki wrote: > 2. An idea has been proposed to have objects marked by the assembler to >indicate whether they include an FP hardware instruction or not. The >latters would automatically become don't-cares as far as NaN encoding >is concerned and if all the objects were such in a given static link, I don't think presence of FP hardware instructions is much of a guide to whether code cares about NaN encodings. I'd expect most code simply doing arithmetic not to care (that is, the same object code would work correctly on systems with either NaN encoding - given the right encodings for that system as inputs, it would produce the right encodings as outputs), while code using a NaN encoding explicitly (typically through __builtin_nan or folded 0.0 / 0.0 in a static initializer) cares even if that object does not use FP instructions. (Formally, of course code knowing the ABI can creating encodings directly, implement issignaling itself, etc., but that should be rare.) -- Joseph S. Myers jos...@codesourcery.com
Re: GCC testsuite maintenance (was: [PATCH] Fix OpenACC vector_length parsing in fortran)
On Fri, 15 Jul 2016, Thomas Schwinge wrote: > > No, we want to have as little churn as possible in existing tests, the > > general policy is to add new tests (not just for OpenACC/OpenMP, but for > > all functionality). > > Hmm, that's something I had not been aware of, and I can't find this > covered in the documentation. So, you're basically saying that files in > the testsuite are write-once, and should not be maintained aside from > fixing errors, adjusting due to optimization changes, or due to changed > diagnostics, and the like? (Of course, I do agree that we shouldn't Yes, that's my view. It makes it easier to distinguish regressions from new tests that fail (on some platforms) if what a test tests doesn't change unnecessarily. -- Joseph S. Myers jos...@codesourcery.com
Re: DejaGnu directive matching multiple messages on the same line
On Wed, 20 Jul 2016, Jakub Jelinek wrote:
> On Wed, Jul 20, 2016 at 02:19:15PM -0600, Martin Sebor wrote:
> > Is there a way to express a requirement that a single line cause
> > two or more diagnostic messages (in any order) each matching one
> > of the regex strings?
>
> Sure, and it is used many times in the testsuite.
>
> whatever; /* { dg-error "whatever1" } */
> /* { dg-error "whatever2" "" { target *-*-* } 33 } */
But use something distinct in place of "", as if you use "" (or more
generally, the same string for multiple dg-error on the same line) then
you get multiple test assertions with the same name (the string that
appears after PASS: or FAIL: in the .sum file), which is bad for comparing
test results.
--
Joseph S. Myers
jos...@codesourcery.com
Re: Question about fold C_MAYBE_CONST_EXPR expressions
On Sun, 24 Jul 2016, Bin.Cheng wrote: > Hi, > I ran into a problem that C frontend (in function > build_conditional_expr) creates expression like (C_MAYBE_CONST_EXPR > (NULL, x + const)). The inner expression (and its operands) have > unsigned int type. After that, the expression needs to be casted to > result type which is unsigned short. In this case, > convert_to_integer/convert_to_integer_1 doesn't fold into > C_MAYBE_CONST_EXPR and just returns (unsigned > short)(C_MAYBE_CONST_EXPR (NULL, x + const)), as a result, (unsigned > short)(x + const) won't be simplified as (unsigned short)x + const. > My questions are, 1) Is it possible to fold type conversion into > C_MAYBE_CONST_EXPR's inner expression in convert_to_integer_1? 2) If > not, looks like there are couple of places the mentioned fold can be > done, for example, after stripping C_MAYBE_CONST_EXPR and before (or > during) gimplify. So which place is preferred? The folding should occur from, or after, c_fully_fold. In general, convert_to_* should do less optimization; the optimizations there should be moved to the match-and-simplify infrastructure. -- Joseph S. Myers jos...@codesourcery.com
Re: [libiberty] does anyone use regex.c with REGEX_MALLOC?
On 07/23/2016 04:33 AM, Aldy Hernandez wrote: Hi guys! I'm looking at libiberty's use of alloca() and trying to place some bounded checks at alloca() call points. Silly question, do we have any users of regex.c with REGEX_MALLOC set? I don't see any #define for REGEX_MALLOC anywhere in binutils or gcc, and it doesn't look like autoconf magic being set elsewhere. I'm pretty sure that's long long gone. regex came from glibc back in 2001. The REGEX_MALLOC bits were removed from glibc by Uli in 2002. I'll pre-approve removing those bits. Alternately, you could look to resync with glibc, though that could prove painful after 15 years of divergence. Another silly question, who are libiberty's consumers? GCC and binutils/gdb? Or should I be looking at additional packages for answers? Packages which have libiberty included are supposed to put this in their spec file for Fedora: Provides: bundled(libiberty) Presumably there's way to query RPM for that tag. You might ask Red Hat's security folks since I believe they pushed for that change to allow them to easily find bundled bits for security fixes/updates. That ought to give you a sense of who's using libiberty. Jeff
Re: GCC testsuite maintenance (was: [PATCH] Fix OpenACC vector_length parsing in fortran)
On Jul 25, 2016, at 9:37 AM, Joseph Myers wrote: > > On Fri, 15 Jul 2016, Thomas Schwinge wrote: > >>> No, we want to have as little churn as possible in existing tests, the >>> general policy is to add new tests (not just for OpenACC/OpenMP, but for >>> all functionality). >> >> Hmm, that's something I had not been aware of, and I can't find this >> covered in the documentation. So, you're basically saying that files in >> the testsuite are write-once, and should not be maintained aside from >> fixing errors, adjusting due to optimization changes, or due to changed >> diagnostics, and the like? (Of course, I do agree that we shouldn't > > Yes, that's my view. It makes it easier to distinguish regressions from > new tests that fail (on some platforms) if what a test tests doesn't > change unnecessarily. Right. Roughly the test suite is a monotonic, slow moving ever increasing mass. Generally we favor new files for new tests and little to no recoding or rearrangement of existing stuff. We do some limited forms for maintenance, for example, intptr_t to make a less portable test case, to be more portable, just to pick a random recent edit; but these tend to be very minor and very narrowly focused.
Re: [libiberty] does anyone use regex.c with REGEX_MALLOC?
On Mon, 25 Jul 2016, Jeff Law wrote: > I'll pre-approve removing those bits. Alternately, you could look to resync > with glibc, though that could prove painful after 15 years of divergence. The current glibc implementation is completely different; the libiberty version was replaced in glibc many years ago. Obsolete libiberty by gnulib for all its users and you get a portable version of the current glibc regex that way -- Joseph S. Myers jos...@codesourcery.com
Re: Need help with PR71976 combine.c::get_last_value returns a wrong result
On Mon, Jul 25, 2016 at 02:28:28PM +0200, Georg-Johann Lay wrote:
> (insn 43 31 44 2 (set (reg:QI 18 r18)
> (const_int 0 [0])) bug-combin.c:29 56 {movqi_insn}
> (nil))
> (insn 51 50 52 2 (set (reg:QI 16 r16)
> (const_int 40 [0x28])) bug-combin.c:29 56 {movqi_insn}
> (nil))
> (insn 52 51 61 2 (set (reg:DI 18 r18)
> (ashiftrt:DI (reg:DI 18 r18)
> (reg:QI 16 r16))) bug-combin.c:29 1417 {ashrdi3_insn}
> (expr_list:REG_DEAD (reg:QI 16 r16)
> (nil)))
> /* An arithmetic right shift of a quantity known to be -1 or 0
>is a no-op. */
> if (code == ASHIFTRT
> && (num_sign_bit_copies (varop, shift_mode)
> == GET_MODE_PRECISION (shift_mode)))
> {
> count = 0;
> break;
> }
>
> num_sign_bit_copies() eventually calls
> combine.c::reg_num_sign_bit_copies_for_combine()
>
> which returns const0_rtx because reg 18 is set in insn 43 to const0_rtx.
> Total outcome is that the right shift of reg:DI 18 is transformed to a
> no-op move and cancelled out in the remainder.
Why does num_sign_bit_copies return something bigger than 8?
> IIUC get_last_value should return 0 in this case?
>
> /* If we don't have a value, or if it isn't for this basic block and
> it's either a hard register, set more than once, or it's a live
> at the beginning of the function, return 0.
We do have a value, and it is for this bb.
Segher
Re: [libiberty] does anyone use regex.c with REGEX_MALLOC?
On 25/07/16 21:16, Joseph Myers wrote: On Mon, 25 Jul 2016, Jeff Law wrote: I'll pre-approve removing those bits. Alternately, you could look to resync with glibc, though that could prove painful after 15 years of divergence. The current glibc implementation is completely different; the libiberty version was replaced in glibc many years ago. Obsolete libiberty by gnulib for all its users and you get a portable version of the current glibc regex that way BTW, this is what Ayush is trying to do: https://gcc.gnu.org/ml/gcc-patches/2016-07/msg01302.html https://gcc.gnu.org/wiki/replacelibibertywithgnulib It would be great if someone could review his patches. I cannot approve them myself. You could even ask him to look next at replacing the libiberty version of regex.c with gnulib's in GCC. It is on his TODO list. Cheers, Manuel.
Re: Thread-safety of a profiled binary (and GCOV runtime library)
Martin Liška writes: > > I'm also surprised about it :) Let's start without invention of a new flag, > I'll work on that. You definitely need a new flag: atomic or per thread instrumentation will almost certainly have significant overhead (either at run time or in memory). Just making an existing facility a lot of slower without a way around it is not a good idea. BTW iirc there were patches from google on this a few years back. May be still in some branch. -Andi
