[sorry, should have gone to gcc-patches]
Here's my current patch for the bitfield reversal feature I've been
working on for a while, with an RX-specific pragma to apply it
"globally". Could someone please review this? It would be nice
to get it in before stage1 closes again...
Index: gcc/doc/extend.texi
==
Hi Walter,
I faced with similar problem when I worked on optimizing memcpy
expanding for x86.
x86-specific expander also needed alignment info and it was also
incorrect (i.e. too conservative). Routine get_mem_align_offset () is
used there to determine alignment, but after some moment it started to
On 10/02/2012 08:30 AM, Diego Novillo wrote:
Finally, I've been thinking of porting asan/tsan to replace mudflap.
Dodji, you expressed interest in it recently.
That's further out most likely.
Jeff
On Tue, Oct 02, 2012 at 10:30:02AM -0400, Diego Novillo wrote:
> Finally, I've been thinking of porting asan/tsan to replace mudflap.
> Dodji, you expressed interest in it recently.
>
> Jakub, Richi, Joseph, should we do this during the next stage 1?
> I'm not sure how much mudflap is actually use
On 2012-10-02 05:45 , Richard Guenther wrote:
Anybody else with things they want to merge during stage1?
I have the VEC API rename finished and currently under testing. I
expect to have it done by early next week.
There are some gengtype changes that will improve C++ parsing that
should g
I'm getting the following failure trying to compile gcc 4.8 on
TILE-Gx:
In file included from
/home/scratch/walt/gcc-svn/gcc-4.8.0-190448/libatomic/tas_n.c:25:0:
/home/scratch/walt/gcc-svn/gcc-4.8.0-190448/libatomic/tas_n.c: In function
'libat_test_and_set_8':
/home/scratch/walt/gcc-svn/gcc-4.8
On TILE-Gx, I'm observing a degradation in inlined memcpy/memset in
gcc 4.6 and later versus gcc 4.4. Though I find the problem on
TILE-Gx, I think this is a problem for any architectures with
SLOW_UNALIGNED_ACCESS set to 1.
Consider the following program:
struct foo {
int x;
};
void copy(st
On 10/02/2012 05:45 AM, Richard Guenther wrote:
I expect stage1 to close mid to end of October (after which it lasted
for more than 7 months).
Btw, I realize that the aarch64 port probably also wants to merge even if
I didn't see a merge proposal or know whether they have patches to
generic co
On Tue, Oct 02, 2012 at 09:57:53AM +0200, Basile Starynkevitch wrote:
> I observed in http://gcc.gnu.org/ml/gcc/2010-07/msg00248.html that
> sometimes mark_hook-s are not working (and MELT needs them strongly).
>
> Actually, the following test case shows that mark hooks are not emitted when
> i
On Tue, Oct 2, 2012 at 11:34 AM, Richard Guenther
wrote:
> On Tue, Oct 2, 2012 at 10:44 AM, Joern Rennecke
> wrote:
>> I'll have to prepare a few more patches to (supposedly) generic
>> code to support the ARCompact port, which we (Synopsys and Embecosm)
>> would like contribute in time for gcc 4
On Tue, Oct 2, 2012 at 10:44 AM, Joern Rennecke
wrote:
> I'll have to prepare a few more patches to (supposedly) generic
> code to support the ARCompact port, which we (Synopsys and Embecosm)
> would like contribute in time for gcc 4.8.
>
> How much time is left till we switch from phase 1 to phas
I'll have to prepare a few more patches to (supposedly) generic
code to support the ARCompact port, which we (Synopsys and Embecosm)
would like contribute in time for gcc 4.8.
How much time is left till we switch from phase 1 to phase 3?
Hello All,
I observed in http://gcc.gnu.org/ml/gcc/2010-07/msg00248.html that
sometimes mark_hook-s are not working (and MELT needs them strongly).
Actually, the following test case shows that mark hooks are not emitted when
indirectly inside a union member.
To be specific, with the followin
14 matches
Mail list logo
