Hello All,
This is a discussion complementing
http://gcc.gnu.org/ml/gcc-patches/2009-06/msg01587.html. So plugins here
means GPLv3 licensed GCC plugins.
First, I believe that progressively, there will be some plugins
dedicated to the compilation of some major specific free software,
mostly
daniel.tian wrote:
> But I have already defined the PROMOTE_MODE which will convert all the
> QImode, HImode to SImode in computation.
? That's not what the code you posted says:
> PROMOTE_MODE, stolen from mips, is defined in my port:
> #define PROMOTE_MODE(MODE, UNSIGNEDP, TYPE) \
> if
Daniel Berlin wrote:
> Also, what do you expect the semantics to be?
Since we don't expect an iterator to return the same bit twice when
iterating in any case, the ideal would be that it shouldn't matter what
happens to bits that the iterator has already passed.
> In particular, are new bits p
On Mon, Jun 22, 2009 at 1:20 PM, Basile
STARYNKEVITCH wrote:
> Hello All,
>
> This is a discussion complementing
> http://gcc.gnu.org/ml/gcc-patches/2009-06/msg01587.html. So plugins here
> means GPLv3 licensed GCC plugins.
>
> First, I believe that progressively, there will be some plugins dedicat
On Mon, Jun 22, 2009 at 1:45 PM, Dave
Korn wrote:
> Daniel Berlin wrote:
>
>> Also, what do you expect the semantics to be?
>
> Since we don't expect an iterator to return the same bit twice when
> iterating in any case, the ideal would be that it shouldn't matter what
> happens to bits that the i
Hi, Soufiane
Thanks for your interest in GCC and OpenCL. There currently is a GCC
Summer of Code project working on OpenCL and members of the GCC
community working on OpenCL projects. Hopefully you can collaborate
with one of them.
David
On Sat, Jun 20, 2009 at 5:01 PM, soufiane
BAGHDADI wrote
Richard Guenther wrote:
> On Mon, Jun 22, 2009 at 1:45 PM, Dave
> Korn wrote:
>> Daniel Berlin wrote:
>>
>>> Also, what do you expect the semantics to be?
>> Since we don't expect an iterator to return the same bit twice when
>> iterating in any case, the ideal would be that it shouldn't matter wh
I took a look. I don't think it would be hideously hacky to do something
like ...
#define EXECUTE_IF_SET_IN_BITMAP(BITMAP, MIN, BITNUM, ITER) \
for ((BITMAP)->ro_flag = true, \
bmp_iter_set_init (&(ITER), (BITMAP), (MIN), &(BITNUM));
Hello, Ayal,
It may be a stupid a question :-). After reading the modulo scheduling code in
GCC,
I have a question about necessity of generating reg moves. The reg move is
supposed
to break register lifetime > II in absence of rotating register file. However,
in current GCC implementation, it see
Daniel Berlin wrote:
On Sat, Jun 20, 2009 at 10:54 AM, Jeff Law wrote:
Imagine a loop like this
EXECUTE_IF_SET_IN_BITMAP (something, 0, i, bi)
{
bitmap_clear_bit (something, i)
[ ... whatever code we want to process i, ... ]
}
This code is unsafe.
No, this is known, and in fact,
gcc-4.3.2 seems to produce bad code when
accessing an array of small 'volatile'
objects -- it may try to access multiple
such objects in a 'parallel' fashion.
E.g., instead of reading two consecutive
'volatile short's sequentially it reads
a single 32-bit longword. This may crash
e.g., when access
On 06/20/2009 04:38 AM, Bernie Innocenti wrote:
On 06/20/09 04:59, Jason Merrill wrote:
Any thoughts on what to do about the non-branch directories under
branches/? The complete set is ARM apple csl dead gcj ibm ix86 suse
ubuntu. The only solution I can think of would be to specifically
enum
Richard Guenther wrote:
On Sat, Jun 20, 2009 at 4:54 PM, Jeff Law wrote:
Imagine a loop like this
EXECUTE_IF_SET_IN_BITMAP (something, 0, i, bi)
{
bitmap_clear_bit (something, i)
[ ... whatever code we want to process i, ... ]
}
This code is unsafe.
If bit I happens to be the only bi
Richard Guenther wrote:
> > It is known (but maybe not appropriately documented) that deleting
> > bits in the bitmap you iterate over is not safe. If it would be me I would
> > see if I could make it safe though.
On Mon, Jun 22, 2009 at 10:06:38AM -0700, Jeff Law wrote:
> It's not a huge deal -
Till Straumann wrote:
> gcc-4.3.2 seems to produce bad code when
> accessing an array of small 'volatile'
> objects -- it may try to access multiple
> such objects in a 'parallel' fashion.
> E.g., instead of reading two consecutive
> 'volatile short's sequentially it reads
> a single 32-bit longwor
Andrew Haley wrote:
Till Straumann wrote:
gcc-4.3.2 seems to produce bad code when
accessing an array of small 'volatile'
objects -- it may try to access multiple
such objects in a 'parallel' fashion.
E.g., instead of reading two consecutive
'volatile short's sequentially it reads
a single 32
On Mon, Jun 22, 2009 at 11:14 AM, Till
Straumann wrote:
> Andrew Haley wrote:
>>
>> Till Straumann wrote:
>>
>>>
>>> gcc-4.3.2 seems to produce bad code when
>>> accessing an array of small 'volatile'
>>> objects -- it may try to access multiple
>>> such objects in a 'parallel' fashion.
>>> E.g., i
Joe Buck wrote:
> As a general rule there is a performance cost for making iterators
> on a data structure safe with respect to modifications of that data
> structure. I'm not in a position to say what the right solution is
> in this case, but passes that iterate over bitmaps without modifying
>
Paolo Bonzini wrote:
>
>> I took a look. I don't think it would be hideously hacky to do
>> something like ...
>>
>> #define EXECUTE_IF_SET_IN_BITMAP(BITMAP, MIN, BITNUM, ITER)\
>> for ((BITMAP)->ro_flag = true,\
>> bmp_iter_set_init (&(ITER), (BITMAP), (MIN),
H.J. Lu wrote:
> On Mon, Jun 22, 2009 at 11:14 AM, Till
> Straumann wrote:
>> Andrew Haley wrote:
>>> Till Straumann wrote:
>>>
gcc-4.3.2 seems to produce bad code when
accessing an array of small 'volatile'
objects -- it may try to access multiple
such objects in a 'parallel' f
That's roughly the same that 4.3.3 produces.
I had not quoted the full assembly code but just
the essential part that is executed when
source and destination are 4-byte aligned
and are more than 4-bytes apart.
Otherwise (not longword-aligned) the
(correct) code labeled '.L5' is executed.
-- Till
On Sat, 20 Jun 2009, Ian Lance Taylor wrote:
> That said,
> I'm perfectly amenable to moving the new warning to -Wextra or just
> turning it on only with -Wc++-compat. I don't personally care that
> much, actually.
I also agree with Robert's comments that all warnings are about valid C,
with -Wa
On Mon, Jun 22, 2009 at 04:51:17PM -0700, Kaveh R. GHAZI wrote:
> I also agree with Robert's comments that all warnings are about valid C,
> with -Wall we diagnose what we subjectively feel is dubious coding
> practice. Not everyone will agree with what -Wall contains, that's not a
> reason to fre
Joe Buck wrote:
On Mon, Jun 22, 2009 at 04:51:17PM -0700, Kaveh R. GHAZI wrote:
I also agree with Robert's comments that all warnings are about valid C,
with -Wall we diagnose what we subjectively feel is dubious coding
practice. Not everyone will agree with what -Wall contains, that's not a
re
Gabriel Dos Reis writes:
> Historically, many C programmers have resisted that idea (even when we could
> argue that it really is bad style programming.)
They have?(!)
This warning warns about: goto L; { int x = 3; L: ... }
but not about: goto L; { int x; L: ... }
right?
So... is
On Mon, Jun 22, 2009 at 10:43 PM, Miles Bader wrote:
> Gabriel Dos Reis writes:
>> Historically, many C programmers have resisted that idea (even when we could
>> argue that it really is bad style programming.)
>
> They have?(!)
>
> This warning warns about: goto L; { int x = 3; L: ... }
> but n
On Mon, Jun 22, 2009 at 09:45:52PM -0400, Robert Dewar wrote:
> Joe Buck wrote:
>> I think that this should be the standard: a warning belongs in -Wall if
>> it tends to expose bugs. If it doesn't, then it's just somebody's idea
>> of proper coding style but with no evidence in support of its corr
Richard Guenther wrote:
On Mon, Jun 22, 2009 at 1:20 PM, Basile
STARYNKEVITCH wrote:
I would prefer some discussion to happen, instead of blindly proposing
patches on gcc-patches@ and have them rejected until I find a consensus.
Do you think that
1. We should not care about where system wide p
28 matches
Mail list logo
