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
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
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
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
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
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
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
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
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
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),
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
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
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
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 -
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
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
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
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,
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
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));
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
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
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
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
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
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
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
28 matches
Mail list logo
