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 operan
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
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))
>
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/
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 func
The mirror here:
ftp://mirrors-usa.go-parts.com/gcc/releases/
Does not have gcc 6 from April.
> 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-s
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];
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:
>>
>> P
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 wit
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_cou
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 {m
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
9
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
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 s
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
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 o
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 a
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
> co
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 ma
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 cas
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
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 so
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 ma
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)
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 libi
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 existin
27 matches
Mail list logo
