Andrew wrote:
> Does the patch series at located at:
> http://gcc.gnu.org/ml/gcc-patches/2014-02/msg01407.html
> http://gcc.gnu.org/ml/gcc-patches/2014-02/msg01405.html
> Fix this code generation issue? I suspect it does and improves more
> than just the above code.
No, they don't help as is.
-
> On Apr 29, 2014, at 12:08 AM, Yury Gribov wrote:
>
> Andrew wrote:
> > Does the patch series at located at:
> > http://gcc.gnu.org/ml/gcc-patches/2014-02/msg01407.html
> > http://gcc.gnu.org/ml/gcc-patches/2014-02/msg01405.html
> > Fix this code generation issue? I suspect it does and improv
On 2014-04-28 10:14, Eric Botcazou wrote:
Ok, this makes sense. Which default to you have in mind for the -muser-mode
>option?
-mno-user-mode the default, it's usually what's done in this case I think.
I think its more natural to generate user-space code by default.
--
Sebastian Huber, embed
On Tue, Apr 29, 2014 at 09:50:56AM +0400, Yury Gribov wrote:
> I've recently noticed that GCC generates suboptimal code for Asan on
> ARM targets. E.g. for a 4-byte memory access check
>
> (shadow_val != 0) & (last_byte >= shadow_val)
I guess the important question is, if you write the same i
On Tue, Apr 29, 2014 at 8:26 AM, Swati Rathi wrote:
> On Monday 28 April 2014 02:46 PM, Richard Biener wrote:
>>
>> On Sat, Apr 26, 2014 at 4:07 PM, Richard Biener
>> wrote:
>>>
>>> On April 26, 2014 12:31:34 PM CEST, Swati Rathi
>>> wrote:
On Friday 25 April 2014 11:11 PM, Richard Bie
On Tue, Apr 29, 2014 at 7:50 AM, Yury Gribov wrote:
> Hi all,
>
> I've recently noticed that GCC generates suboptimal code for Asan on ARM
> targets. E.g. for a 4-byte memory access check
>
> (shadow_val != 0) & (last_byte >= shadow_val)
>
> we get the following sequence:
>
> movr2, r0
The following patch forces the availability of a 64bit HWI
(without applying the cleanups that result from this). I propose
this exact patch for a short time to get those that are affected
and do not want to be affected scream.
But honestly I don't see any important host architecture that
not al
Andrew wrote:
I think it would good to figure out how to improve this code gen
with the above patches rather than changing asan.
I suspect it might easy to expand them to handle this case too.
True, let me take a closer look and get back to you. When will this is
expected to land in trunk bt
On 28/04/14 18:03, Kenneth Zadeck wrote:
At this point we have believe that we have addressed all of the concerns
that the community has made about the wide-int branch. We have also
had each of the sections of the branch approved by the area maintainers.
We are awaiting a clean build on the ar
Kyrill Tkachov writes:
> On 28/04/14 18:03, Kenneth Zadeck wrote:
>> At this point we have believe that we have addressed all of the concerns
>> that the community has made about the wide-int branch. We have also
>> had each of the sections of the branch approved by the area maintainers.
>>
>> W
Hello,
Suppose the following C code.
int t = __sync_fetch_and_add(&s->r, 1);
s is a struct with member r, which is an volatile int.
Is this an atomic operation, even if you include the indirection? In
other words, can a thread come between the dereferencing operation and
the atomic increment of
On Tue, 29 Apr 2014, Richard Sandiford wrote:
> Kyrill Tkachov writes:
> > On 28/04/14 18:03, Kenneth Zadeck wrote:
> >> At this point we have believe that we have addressed all of the concerns
> >> that the community has made about the wide-int branch. We have also
> >> had each of the section
Richard Biener writes:
> On Tue, 29 Apr 2014, Richard Sandiford wrote:
>
>> Kyrill Tkachov writes:
>> > On 28/04/14 18:03, Kenneth Zadeck wrote:
>> >> At this point we have believe that we have addressed all of the concerns
>> >> that the community has made about the wide-int branch. We have al
On Tue, 2014-04-29 at 09:11 -0400, Leo Ferres wrote:
> Hello,
>
> Suppose the following C code.
>
> int t = __sync_fetch_and_add(&s->r, 1);
>
> s is a struct with member r, which is an volatile int.
>
> Is this an atomic operation, even if you include the indirection?
The atomic operation is o
Hello,
In gcc 4.4.6 we had no problem with the order of initialization.
In gcc 4.7.2 we do have a problem.
A CPP file defined GlobalObj_1 (declared extern in the H file):
CMyClass GlobalObj_1.
Another CPP file declared GlobalObj_2 (also declared extern in the H
file).= The CPP file used copy const
Kyrill Tkachov writes:
> On 28/04/14 18:03, Kenneth Zadeck wrote:
>> At this point we have believe that we have addressed all of the concerns
>> that the community has made about the wide-int branch. We have also
>> had each of the sections of the branch approved by the area maintainers.
>>
>> W
On 29 April 2014 16:25, Yaron Dayagi wrote:
> Hello,
> In gcc 4.4.6 we had no problem with the order of initialization.
> In gcc 4.7.2 we do have a problem.
> A CPP file defined GlobalObj_1 (declared extern in the H file):
> CMyClass GlobalObj_1.
> Another CPP file declared GlobalObj_2 (also declar
On 04/29/14 05:21, Richard Biener wrote:
The following patch forces the availability of a 64bit HWI
(without applying the cleanups that result from this). I propose
this exact patch for a short time to get those that are affected
and do not want to be affected scream.
But honestly I don't see
I've now confirmed this same issue occurs on a stock i386 build
when -fomit-frame-pointer is specified with -O2 and a test case
with reasonable register pressure.
On 28/04/14 07:47, Paul Shortis wrote:
I'm porting gcc to a 16 bit cpu with a two address ISA like x86.
When using LRA I was getti
Paul Shortis writes:
> I've now confirmed this same issue occurs on a stock i386 build
> when -fomit-frame-pointer is specified with -O2 and a test case
> with reasonable register pressure.
Then please open a bug report in gcc's bugzilla with the test case
and instructions on how to reproduce
Denis,
when building gcc for avr with --enable-checking=yes,rtl , I run into the
following error:
...
/home/vries/gcc_versions/devel/src/libgcc/unwind-c.c: In function
‘__gcc_personality_sj0’:
/home/vries/gcc_versions/devel/src/libgcc/unwind-c.c:234:1: internal compiler
error: RTL check: expe
21 matches
Mail list logo
