On 4/16/2014 03:22, Ian Lance Taylor wrote:
> On Tue, Apr 15, 2014 at 4:45 AM, Douglas B Rupp wrote:
>> On 04/14/2014 02:01 PM, Ian Lance Taylor wrote:
>>
>> No I considered that but I think that number will be very small. Will you
>> concede, in hindsight, that it would be better had the name bee
Ran into a fragile test case:
FAIL: g+.dg/cpp0x/nsdmi-union5.C -std=c+11 scan-assembler 7
$ cat nsdmi-union5.C
// PR c++/58701
// { dg-require-effective-target c++11 }
// { dg-final { scan-assembler "7" } }
static union
{
union
{
int i = 7;
};
};
Two issues make it very fragile. It onl
> On Apr 16, 2014, at 12:42 AM, "Joey Ye" wrote:
>
> Ran into a fragile test case:
> FAIL: g+.dg/cpp0x/nsdmi-union5.C -std=c+11 scan-assembler 7
>
> $ cat nsdmi-union5.C
> // PR c++/58701
> // { dg-require-effective-target c++11 }
> // { dg-final { scan-assembler "7" } }
>
> static union
> {
On Wed, Apr 16, 2014 at 10:24 AM, wrote:
>
>
>> On Apr 16, 2014, at 12:42 AM, "Joey Ye" wrote:
>>
>> Ran into a fragile test case:
>> FAIL: g+.dg/cpp0x/nsdmi-union5.C -std=c+11 scan-assembler 7
>>
>> $ cat nsdmi-union5.C
>> // PR c++/58701
>> // { dg-require-effective-target c++11 }
>> // { dg-f
Forwarding this to the gcc list, since it seems to be more releavant
to the topic of this list. Sorry for the confusion.
Regards,
Akos Vandra
-- Forwarded message --
From: Akos Vandra
Date: 16 April 2014 12:48
Subject: Using GCC to convert markup to C++
To: gcc-h...@gcc.gnu.or
I have made a curious performance observation with gcc under 64 bit
cygwin on a corei7. I'm genuinely puzzled and couldn't find any
information about it. Perhaps this is only indirectly a gcc question
though, bear with me.
I have two trivial programs which assign a loop variable to a local
va
Hi,
You cannot learn useful timing information from a single run of a short
test like this - there are far too many other factors that come into play.
You cannot learn useful timing information from unoptimised code.
There is too much luck involved in a test like this to be useful. You
need op
Hello,
I completely agree with David.
Note that your results will greatly vary depending on the machine you
run the tests on. Performance on such tests it is very
machine-dependant, so the conclusion cannot be generalized.
David
2014-04-16 16:49 GMT+02:00 David Brown :
>
> Hi,
>
> You cannot lea
Hi David,
Sorry, I had included more information in an earlier draft which I
edited out for brevity.
> You cannot learn useful timing
> information from a single run of a short
> test like this - there are far too many
> other factors that come into play.
I didn't mention that I have run it d
On 04/16/2014 12:01 AM, John Marino wrote:
> On 4/16/2014 03:22, Ian Lance Taylor wrote:
>> On Tue, Apr 15, 2014 at 4:45 AM, Douglas B Rupp wrote:
>>> On 04/14/2014 02:01 PM, Ian Lance Taylor wrote:
>>>
>>> No I considered that but I think that number will be very small. Will you
>>> concede, in h
In order to see what difference a different processor makes I also tried
the same code on a fairly old 32 bit "AMD Athlon(tm) XP 3000+" with the
current stable gcc (4.7.2). The difference is even more striking
(dereferencing is much faster). I see that the size of the code inside
the loop for t
On April 16, 2014 7:45:55 PM CEST, Peter Schneider wrote:
>In order to see what difference a different processor makes I also
>tried
>the same code on a fairly old 32 bit "AMD Athlon(tm) XP 3000+" with the
>
>current stable gcc (4.7.2). The difference is even more striking
>(dereferencing is muc
> Because GCC would then be already incompatible with the Intel compiler from
> which this interface was drawn, way back when the ia64 support was added to
> GCC and we redesigned GCC's exception handling.
The irony being that WindRiver is now owned by Intel...
Doug, what does this unwind.h from
On 04/16/2014 12:38 PM, Eric Botcazou wrote:
Because GCC would then be already incompatible with the Intel compiler from
which this interface was drawn, way back when the ia64 support was added to
GCC and we redesigned GCC's exception handling.
The irony being that WindRiver is now owned by Int
On Wed, Apr 16, 2014 at 12:01 AM, John Marino wrote:
> On 4/16/2014 03:22, Ian Lance Taylor wrote:
>> On Tue, Apr 15, 2014 at 4:45 AM, Douglas B Rupp wrote:
>>> On 04/14/2014 02:01 PM, Ian Lance Taylor wrote:
>>>
>>> No I considered that but I think that number will be very small. Will you
>>> co
On 04/16/2014 12:48 PM, Douglas B Rupp wrote:
> On 04/16/2014 12:38 PM, Eric Botcazou wrote:
>>> Because GCC would then be already incompatible with the Intel compiler from
>>> which this interface was drawn, way back when the ia64 support was added to
>>> GCC and we redesigned GCC's exception hand
On 04/16/2014 12:55 PM, Richard Henderson wrote:
Is it a (reasonably) close match, interface-wise? Ought we be using
--with-system-libunwind for VxWorks7, like we do for hpux?
It looks reasonable at first glance, but there's a disturbing comment in
the code something to the effect:
until w
On 04/16/14 00:30, pshor...@dataworx.com.au wrote:
I had left the movsi patterns unimplemented because I was told that if I
did this then gcc would create expands/splits to use 16 bit moves. So, I
removed my movsi patterns and all seemed well.
Correct. GCC can synthesize movsi from movhi. How
Solved... kind of.
*ldsi is one of the patterns movsi is expanded to and as the name
suggests it only handles register loads. I know that at some
stages memory references will pass the register_operand predicate
so I changed the predicate for operand 0 and added an alternative
to *ldsi that c
On 04/16/2014 03:05 PM, Paul Shortis wrote:
> Solved... kind of.
>
> *ldsi is one of the patterns movsi is expanded to and as the name suggests it
> only handles register loads. I know that at some stages memory references will
> pass the register_operand predicate so I changed the predicate for o
Snapshot gcc-4.9-20140416 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.9-20140416/
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
> It looks reasonable at first glance, but there's a disturbing comment in
> the code something to the effect:
>
> until we have a GCC compatible unwinding library, hide the API
Indeed, it looks like it was written from scratch for the Diab compiler and
is not fully compatible, but it is meant t
On Wed, Apr 16, 2014 at 3:53 PM, Eric Botcazou wrote:
>> It looks reasonable at first glance, but there's a disturbing comment in
>> the code something to the effect:
>>
>> until we have a GCC compatible unwinding library, hide the API
>
> Indeed, it looks like it was written from scratch for the
On 04/16/2014 05:56 PM, Ian Lance Taylor wrote:
I'm still not clear on what the real problem is.
It seems to me that when using GCC, if you #include , you
will get the GCC version, since it will come from the installed
GCC include directory, which is searched ahead of /usr/include. That
seems
On 04/16/14 16:19, Richard Henderson wrote:
The register allocators only select an alternative for a move. They do not
choose between N different patterns, separately describing loads, stores, and
register-to-register movement.
I'm fairly sure the documentation is quite clear on this, and GCC
While debugging some gdb-related FAILs, I discovered that gcc's
-fstack-check option effectively calls alloca() to adjust the stack
pointer.
However, it doesn't mark the stack adjustment as FRAME_RELATED even
when it's setting up the local variables for the function.
In the case of rx-elf, for t
On 17.04.2014 13:00, Jeff Law wrote:
On 04/16/14 16:19, Richard Henderson wrote:
The register allocators only select an alternative for a move. They
do not
choose between N different patterns, separately describing loads,
stores, and
register-to-register movement.
I'm fairly sure the docum
27 matches
Mail list logo
