Snapshot gcc-4.9-20140625 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.9-20140625/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.9 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
On Wed, 25 Jun 2014, Sebastian Huber wrote:
> In case __auto_type discards const and volatile qualifiers, then shouldn't
> this generate a warning (-Wconst-qual)
>
> __auto_type __atomic_load_ptr = (PTR);
>
> ?
No. The discarding is for qualifiers on the type itself (remembering that
qualifie
On 2014-06-25 15:25, Joseph S. Myers wrote:
On Wed, 25 Jun 2014, Sebastian Huber wrote:
I think the inheritance of the volatile qualifier via __typeof__
(*__atomic_load_ptr) is an implementation flaw.
See the comment in c_parser_typeof_specifier:
/* For use in macros such as those in
On 2014-06-25, 10:01 AM, Vladimir Makarov wrote:
On 2014-06-24, 10:57 AM, Ramana Radhakrishnan wrote:
I've tried this options too. As I guessed it resulted in GCC
improvement of eon only by 6% which improved overall score by less 0.5%.
No change for LLVM though. Eon is more fp benchmark w
On 2014-06-25, 10:37 AM, Marc Glisse wrote:
On Wed, 25 Jun 2014, Vladimir Makarov wrote:
Maybe. But in this case LLVM did a right thing. The variable
addressing was through a restrict pointer.
Ah, gcc implements (on purpose?) a weak version of restrict, where it
only considers that 2 restri
On Wed, 25 Jun 2014, Vladimir Makarov wrote:
Maybe. But in this case LLVM did a right thing. The variable addressing was
through a restrict pointer.
Ah, gcc implements (on purpose?) a weak version of restrict, where it only
considers that 2 restrict pointers don't alias, whereas all other
On 2014-06-25, 10:02 AM, Richard Biener wrote:
On Wed, Jun 25, 2014 at 4:00 PM, Vladimir Makarov wrote:
On 2014-06-25, 5:32 AM, Renato Golin wrote:
On 25 June 2014 10:26, Bingfeng Mei wrote:
Why is GCC code size so much bigger than LLVM? Does -Ofast have more
unrolling
on GCC? It doesn't s
Dear gcc contributors,
could you please answer a few questions about unit tests? Is it
possible to use them in gcc? Or maybe there is some analogue? I would
be very grateful for your comments.
--
Cheers, Roman Gareev
On Wed, Jun 25, 2014 at 04:02:49PM +0200, Richard Biener wrote:
> > That might be a consequence of difference in aliasing I wrote about. I
> > looked at the code generated by LLVM and GCC of an interpreter and saw
> > bigger code generated by GCC too.
> >
> > A sequence of bytecodes execution
On Wed, Jun 25, 2014 at 4:00 PM, Vladimir Makarov wrote:
> On 2014-06-25, 5:32 AM, Renato Golin wrote:
>>
>> On 25 June 2014 10:26, Bingfeng Mei wrote:
>>>
>>> Why is GCC code size so much bigger than LLVM? Does -Ofast have more
>>> unrolling
>>> on GCC? It doesn't seem increasing code size help
On 2014-06-24, 10:57 AM, Ramana Radhakrishnan wrote:
The ball-park number you have probably won't change much.
I don't think Neon can improve score for SPECInt2000 significantly but
may be I am wrong.
It won't probably improve the overall score by a large amount but some
individual benchmar
On 2014-06-25, 5:32 AM, Renato Golin wrote:
On 25 June 2014 10:26, Bingfeng Mei wrote:
Why is GCC code size so much bigger than LLVM? Does -Ofast have more unrolling
on GCC? It doesn't seem increasing code size help performance (164.gzip &
197.parser)
Is there comparisons for O2? I guess that
On Wed, 25 Jun 2014, Sebastian Huber wrote:
> I think the inheritance of the volatile qualifier via __typeof__
> (*__atomic_load_ptr) is an implementation flaw.
See the comment in c_parser_typeof_specifier:
/* For use in macros such as those in , remove
_Atomic and const qualifier
Hello,
GCC provides its own version of stdatomic.h since GCC 4.9. Here we have:
#define atomic_load_explicit(PTR, MO) \
__extension__ \
({
On Wed, Jun 25, 2014 at 11:53 AM, Bin.Cheng wrote:
> On Wed, Jun 25, 2014 at 5:47 PM, Bin.Cheng wrote:
>> On Wed, Jun 25, 2014 at 5:26 PM, Bingfeng Mei wrote:
>>> Thanks for nice benchmarks. Vladimir.
>>>
>>> Why is GCC code size so much bigger than LLVM? Does -Ofast have more
>>> unrolling
>>
On Wed, Jun 25, 2014 at 5:47 PM, Bin.Cheng wrote:
> On Wed, Jun 25, 2014 at 5:26 PM, Bingfeng Mei wrote:
>> Thanks for nice benchmarks. Vladimir.
>>
>> Why is GCC code size so much bigger than LLVM? Does -Ofast have more
>> unrolling
> On the contrary, I don't think rtl unrolling is enabled by d
On Wed, Jun 25, 2014 at 5:26 PM, Bingfeng Mei wrote:
> Thanks for nice benchmarks. Vladimir.
>
> Why is GCC code size so much bigger than LLVM? Does -Ofast have more unrolling
On the contrary, I don't think rtl unrolling is enabled by default on
GCC with level O3/Ofast. There is no unroll dump fil
On 25 June 2014 10:26, Bingfeng Mei wrote:
> Why is GCC code size so much bigger than LLVM? Does -Ofast have more unrolling
> on GCC? It doesn't seem increasing code size help performance (164.gzip &
> 197.parser)
> Is there comparisons for O2? I guess that is more useful for typical
> mobile/emb
Thanks for nice benchmarks. Vladimir.
Why is GCC code size so much bigger than LLVM? Does -Ofast have more unrolling
on GCC? It doesn't seem increasing code size help performance (164.gzip &
197.parser)
Is there comparisons for O2? I guess that is more useful for typical
mobile/embedded programme
19 matches
Mail list logo
