Jacek Caban sent this:
http://gcc.gnu.org/ml/gcc-patches/2012-03/msg01987.html
in response to this:
http://gcc.gnu.org/ml/gcc-patches/2012-03/msg01986.html
But it never got reviewed. Could you review and commit?
No, I don't have approval rights here, you need a Windows maintainer (Kai).
On 14/06/12 19:46, Dinar Temirbulatov wrote:
Hi,
OK for trunk?
thanks, Dinar.
I'm still not comfortable about the code bloat that this is likely to
incurr at -O2.
R.
On Tue, Jun 12, 2012 at 11:00 AM, Paolo Bonzini bonz...@gnu.org wrote:
Il 12/06/2012 08:52, Dinar
But note that in libdecnumber we have:
10de71e1 (meissner 2007-03-24 17:04:47 + 25) typedef unsigned int
UINT32; 10de71e1 (meissner 2007-03-24 17:04:47 + 26) typedef unsigned
long long UINT64; 10de71e1 (meissner 2007-03-24 17:04:47 + 27) typedef
struct { UINT64 w[2]; } UINT128;
On Fri, Jun 15, 2012 at 3:40 AM, Easwaran Raman era...@google.com wrote:
ChangeLog entry has a gcc/ prefix that shouldn't be there. Here is the
revised entry:
2012-06-14 Easwaran Raman era...@google.com
* passes.c (init_optimization_passes): Remove pass_call_cdce
from its
On Fri, Jun 15, 2012 at 7:47 AM, Sharad Singhai sing...@google.com wrote:
On Wed, Jun 13, 2012 at 4:48 AM, Richard Guenther
richard.guent...@gmail.com wrote:
On Fri, Jun 8, 2012 at 7:16 AM, Sharad Singhai sing...@google.com wrote:
Okay, I have updated the attached patch so that the output from
On 31/05/12 14:50, Greta Yorsh wrote:
This patch updates ldm_stm_operation_p to check for loads that if SP is in
the register list, then the base register is SP. It guarantees that SP is
reset correctly when an LDM instruction is interrupted. Otherwise, we might
end up with a corrupt stack.
On 31/05/12 14:53, Greta Yorsh wrote:
This patch adds new define_insn patterns for epilogue with integer
registers.
The patterns can handle pop multiple with writeback and return (loading into
PC directly).
To handle return, the patterns use a new special predicate
pop_multiple_return,
On Thu, Jun 14, 2012 at 11:00 PM, Jakub Jelinek ja...@redhat.com wrote:
Hi!
While looking at pattern recognizer, I've noticed that we needlessly
allocate a single member array from heap. An automatic variable for that
would be fine, but BB_VINFO_BB is also addressable.
If we don't do it, we'll get another PR saying this works in LTO mode with
other versions of the Ada compiler (which is true) so I'll proceed.
Here is what I've installed after bootstrapping/regtesting on x86_64-suse-linux
and i586-suse-linux. It adds the flag to 'struct function' and streams
On 06/15/2012 09:12 AM, Eric Botcazou wrote:
Generally speaking, I'd avoid taking anything in libdecnumber as an example.
It's not about example, but the fact that host compilers have been
compiling that code as part of building gcc for years, without anyone
complaining, afaik. It doesn't
My plugin is written in C++. When including headers from gcc-4.6 it wraps them
in 'extern C' to prevent name mangling. Some of the plugin headers include
gcc/system.h which includes the C++ header cstring if it detects the use of a
C++ compiler. As a result cstring routines included this way
On Fri, Jun 15, 2012 at 11:13 AM, Eric Botcazou ebotca...@adacore.com wrote:
If we don't do it, we'll get another PR saying this works in LTO mode with
other versions of the Ada compiler (which is true) so I'll proceed.
Here is what I've installed after bootstrapping/regtesting on
On Fri, Jun 15, 2012 at 11:27 AM, Duncan Sands baldr...@free.fr wrote:
My plugin is written in C++. When including headers from gcc-4.6 it wraps
them
in 'extern C' to prevent name mangling. Some of the plugin headers
include
gcc/system.h which includes the C++ header cstring if it detects
It's not about example, but the fact that host compilers have been
compiling that code as part of building gcc for years, without anyone
complaining, afaik. It doesn't matter whether the code pointed at
is the ugliest or most beautiful code on earth. What matters is whether
it uses long
On 14/06/12 13:24, Sofiane Naci wrote:
Hi,
This patch updates LINK_SPEC in the AArch64 port.
Thanks
Sofiane
-
2012-06-14 Sofiane Nacisofiane.n...@arm.com
[AArch64] Update LINK_SPEC.
* config/aarch64/aarch64-linux.h (LINUX_TARGET_LINK_SPEC): Remove
Btw, I think we should enable this flag by default for all languages but
Java so that if you enable -fnon-call-exceptions for C or C++ you don't get
too many spurious exceptions from dead code.
The flag isn't formally tied to -fnon-call-exceptions though, so there might be
subtleties in C++,
Hi Richard,
Uh, I don't think we should do that. Why do we include cstring here anyways?
Ian - you added this include in rev. 167764, I don't think that was proper.
But I'm not sure wrapping a system.h include inside extern C from a C++
plugin is proper either ...
since the plugin needs to
2012/6/15 Eric Botcazou ebotca...@adacore.com:
Jacek Caban sent this:
http://gcc.gnu.org/ml/gcc-patches/2012-03/msg01987.html
in response to this:
http://gcc.gnu.org/ml/gcc-patches/2012-03/msg01986.html
But it never got reviewed. Could you review and commit?
No, I don't have approval
On 15/06/12 10:48, Eric Botcazou wrote:
It's not about example, but the fact that host compilers have been
compiling that code as part of building gcc for years, without anyone
complaining, afaik. It doesn't matter whether the code pointed at
is the ugliest or most beautiful code on earth.
On 31/05/12 14:55, Greta Yorsh wrote:
New define insn pattern for epilogue with floating point registers (DFmode)
and a new function that emits RTL for this pattern. This function is a
helper for epilogue extension. It is used by a later patch.
ChangeLog:
gcc
2012-05-31 Ian Bolton
On 31/05/12 14:58, Greta Yorsh wrote:
Helper function for epilogue expansion. Emit RTL for APCS frame epilogue
(when -mapcs-frame command line option is specified).
This function is used by a later patch.
For APCS frame epilogue, the compiler currently generates LDM with SP as
both the base
On 31/05/12 14:59, Greta Yorsh wrote:
The main function for epilogue RTL generation, used by expand epilogue
patterns.
ChangeLog:
gcc
2012-05-31 Ian Bolton ian.bol...@arm.com
Sameera Deshpande sameera.deshpa...@arm.com
Greta Yorsh greta.yo...@arm.com
This is the ICE on the assignment to a component of a vector_type, which comes
from the VIEW_CONVERT_EXPR generated to turn it into an array array. Now that
VECTOR_TYPEs can be GIMPLE registers, this construct breaks.
Fixed by marking the vector as addressable, as suggested by Richard. Tested
On 31/05/12 15:02, Greta Yorsh wrote:
Add a new parameter to the function output_return_instruction to handle
simple cases of return when no epilogue needs to be printed out.
ChangeLog:
gcc
2012-05-31 Ian Bolton ian.bol...@arm.com
Sameera Deshpande
On 31/05/12 15:04, Greta Yorsh wrote:
Generate RTL for return in Thumb2 mode. Used by expand of return insn.
ChangeLog:
gcc
2012-05-31 Ian Bolton ian.bol...@arm.com
Sameera Deshpande sameera.deshpa...@arm.com
Greta Yorsh greta.yo...@arm.com
*
There are several ports that currently require long long support in the
back-end -- see need_64bit_hwint in config.gcc.
Yes, all the 64-bit ports at least, but you shouldn't need 'long long' to build
the compiler e.g. for the AVR.
--
Eric Botcazou
This adds a testcase I reduced from a genmodes miscompile with one of
my pending VRP patches.
Committed.
Richard.
2012-06-15 Richard Guenther rguent...@suse.de
* gcc.c-torture/execute/20120615-1.c: New testcase.
Index: gcc/testsuite/gcc.c-torture/execute/20120615-1.c
Hi,
On Thu, 14 Jun 2012, Richard Guenther wrote:
Restarted regstrapping the thing on x86_64 again. Okay if that
passes?
Ok.
But I wonder how the symtab cannot be ready when we gimplify - after
all we gimplify only from after cgraph_finalize_compilation_unit ...
Ready may have been
Whoops, I forgot to commit that last patch. Check now.
The warning is there on the 4.7 branch now.
--
Eric Botcazou
On Fri, Jun 15, 2012 at 11:59 AM, Duncan Sands baldr...@free.fr wrote:
Hi Richard,
Uh, I don't think we should do that. Why do we include cstring here
anyways?
Ian - you added this include in rev. 167764, I don't think that was
proper.
But I'm not sure wrapping a system.h include inside
On 06/15/12 06:40, Eric Botcazou wrote:
Whoops, I forgot to commit that last patch. Check now.
The warning is there on the 4.7 branch now.
Arghhh, that's the second time. I wonder why the warning doesn't show
up on my bootstraps.
Anyway, committed the attached patch to branch.
On Thu, Jun 14, 2012 at 5:33 PM, Michael Matz m...@suse.de wrote:
Hi,
On Thu, 14 Jun 2012, Michael Matz wrote:
In any case, this patch is currently in regstrapping on x86-64. Okay if
it passes (modulo changes for the above symtab_get_node() issue)?
After discussion with Honza,
Hi Richard,
As system.h is supposed to only include system headers and do nothing
else it has to be prepared to be included from C++ already, so no extern C
wrapping should be necessary for it.
it defines fancy_abort. Not wrapping system.h in extern C results in
undefined symbol:
This makes set_and_canonicalize_value_range more consistent. To be
used in further patches.
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
Richard.
2012-06-15 Richard Guenther rguent...@suse.de
* tree-vrp.c (set_and_canonicalize_value_range): Use canonical
This tries to completely implement the intersect primitive for
VRP (what extract_range_from_assert does at its end when merging
new and old knowledge).
Bootstrap and regtest pending on x86_64-unknown-linux-gnu.
I plan to re-organize vrp_meet in a similar fashion as a followup.
Richard.
Hello,
PR tree-optimization/53636 is a crash due to an invalid unaligned access
generated by the vectorizer.
The problem is that vect_compute_data_ref_alignment uses DR_ALIGNED_TO
as computed by the default data-ref analysis to decide whether an access
is sufficiently aligned for the vectorizer.
On Fri, Jun 15, 2012 at 3:13 PM, Ulrich Weigand uweig...@de.ibm.com wrote:
Hello,
PR tree-optimization/53636 is a crash due to an invalid unaligned access
generated by the vectorizer.
The problem is that vect_compute_data_ref_alignment uses DR_ALIGNED_TO
as computed by the default data-ref
On Fri, Jun 15, 2012 at 2:40 PM, Duncan Sands baldr...@free.fr wrote:
Hi Richard,
As system.h is supposed to only include system headers and do nothing
else it has to be prepared to be included from C++ already, so no extern
C
wrapping should be necessary for it.
it defines fancy_abort.
Hi,
When building for, say, mips-linux-gnu, the build of objects from fixed-bit.c
produces a lot of set but not used warnings for min_high min_low.
looking at the code, these appear to be genuine.
Fixed as below.
OK for trunk?
Iain
libgcc:
* fixed-bit.c (SATFRACT): Adjust
This patch cleans up the predicates and constraints that are now
redundant after the removal of FPA and Maverick co-processor support.
Tested on arm-eabi.
* arm.md (addsf3, adddf3): Use s_register_operand.
(subsf3, subdf3): Likewise.
(mulsf3, muldf3): Likewise.
On Fri, Jun 15, 2012 at 4:48 AM, Richard Guenther
richard.guent...@gmail.com wrote:
On Fri, Jun 15, 2012 at 11:27 AM, Duncan Sands baldr...@free.fr wrote:
My plugin is written in C++. When including headers from gcc-4.6 it wraps
them
in 'extern C' to prevent name mangling. Some of the plugin
On Fri, Jun 15, 2012 at 4:59 AM, Duncan Sands baldr...@free.fr wrote:
Hi Richard,
Uh, I don't think we should do that. Why do we include cstring here
anyways?
Ian - you added this include in rev. 167764, I don't think that was
proper.
But I'm not sure wrapping a system.h include inside
On Fri, Jun 15, 2012 at 7:40 AM, Duncan Sands baldr...@free.fr wrote:
Hi Richard,
As system.h is supposed to only include system headers and do nothing
else it has to be prepared to be included from C++ already, so no extern
C
wrapping should be necessary for it.
it defines fancy_abort.
On Fri, Jun 15, 2012 at 8:25 AM, Richard Guenther
richard.guent...@gmail.com wrote:
On Fri, Jun 15, 2012 at 2:40 PM, Duncan Sands baldr...@free.fr wrote:
Hi Richard,
As system.h is supposed to only include system headers and do nothing
else it has to be prepared to be included from C++
On Fri, Jun 15, 2012 at 9:18 AM, Duncan Sands baldr...@free.fr wrote:
Hi Gabriel,
it defines fancy_abort. Not wrapping system.h in extern C results in
undefined symbol: _Z11fancy_abortPKciS0_
when loading the plugin.
If you want fancy_abort to have a C language specification, that is
Hi Gabriel,
Richard just reminded me that we have two fancy_aborts.
Could you tell which one your code is indirectly using?
the one installed as plugin/include/system.h, which seems to be
gcc/include/system.h. It is used for example in tree.h here:
/* Advance to the next argument. */
Hi,
On Wed, 6 Jun 2012, Richard Guenther wrote:
Regstrapped this patch (all languages+Ada) on x86_64-linux, with and
without the above scheduler hacks, no regressions (without the
scheduler hacks).
The n_temp_slots_in_use part is ok.
The rest is also a good idea, and indeed the
Richard Guenther wrote:
On Fri, Jun 15, 2012 at 3:13 PM, Ulrich Weigand uweig...@de.ibm.com wrote:
However, there is a second case where we need to check every pass: if
we're not actually vectorizing any loop, but are performing basic-block
SLP. In this case, it would appear that we need
On Fri, Jun 15, 2012 at 9:33 AM, Duncan Sands baldr...@free.fr wrote:
Hi Gabriel,
Richard just reminded me that we have two fancy_aborts.
Could you tell which one your code is indirectly using?
the one installed as plugin/include/system.h, which seems to be
gcc/include/system.h.
OK. I
Hi Gabriel,
Richard just reminded me that we have two fancy_aborts.
Could you tell which one your code is indirectly using?
the one installed as plugin/include/system.h, which seems to be
gcc/include/system.h.
OK. I think that declaration has to have the C language spec.
Would you prepare
On Fri, Jun 15, 2012 at 10:13 AM, Duncan Sands baldr...@free.fr wrote:
Hi Gabriel,
Richard just reminded me that we have two fancy_aborts.
Could you tell which one your code is indirectly using?
the one installed as plugin/include/system.h, which seems to be
gcc/include/system.h.
OK.
Hello Everyone,
This patch is for the Cilkplus branch affecting both C and C++ compilers.
This patch will fix the ICE when the user uses the -flto flag.
Thanks,
Balaji V. Iyer.
Index: gcc/tree.h
===
--- gcc/tree.h (revision
Richard Guenther richard.guent...@gmail.com writes:
Ian - you added this include in rev. 167764, I don't think that was proper.
But I'm not sure wrapping a system.h include inside extern C from a C++
plugin is proper either ...
I did commit 167764 but I didn't write it. It's from
On 15 June 2012 01:44, Jason Merrill ja...@redhat.com wrote:
OK.
Thanks, now committed with the only change being that the PR number is
now referenced in the Changelog.
Ramana
Btw, I think we should enable this flag by default for all languages but
Java so that if you enable -fnon-call-exceptions for C or C++ you don't get
too many spurious exceptions from dead code.
The attached patch enables it for the C family of languages (I'm not too sure
about the other
On Thu, 14 Jun 2012, Ramana Radhakrishnan wrote:
While experimenting with the fixes to allow neon intrinsics to work
with __builtin_shuffle I hit the fact that __builtin_shuffle isn't
really supported by the C++ frontend.I'm keen we use __builtin_shuffle
for these intrinsics, but that means we
I just noticed this part. Rereading my comment in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51033#c22
I haven't been able to make it break with -std=c++11 . Is there
something I'm missing here ?
it seems like this may break things with -std=c++11 and you used the old
version from comment
On Jun 15, 2012, at 2:22 AM, Pedro Alves pal...@redhat.com wrote:
It's not about example, but the fact that host compilers have been
compiling that code as part of building gcc for years, without anyone
complaining
Yeah, I think we should just jump to c++ 11 and not look back... Fighting
On Fri, 15 Jun 2012, Ramana Radhakrishnan wrote:
I just noticed this part. Rereading my comment in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51033#c22
I haven't been able to make it break with -std=c++11 . Is there
something I'm missing here ?
I don't remember. It might just be that
Thanks. I found another one and I fixed it.
2012-06-15 Walter Lee w...@tilera.com
* config/tilegx/sync.md (atomic_fetch_fetchop_namemode): Fix typo.
Index: config/tilegx/sync.md
===
--- config/tilegx/sync.md (revision
Hi, Richard,
How about if I add and utilize umul_highpart_di to the libgcc
instead of expanding
multiplication for the high part directly, or add my own function with
with pre-shift, post-shift, and
64-bit constant and 64-bit operand as function parameters for division
for less than -O3?
On 15 June 2012 18:18, Marc Glisse marc.gli...@inria.fr wrote:
On Fri, 15 Jun 2012, Ramana Radhakrishnan wrote:
I just noticed this part. Rereading my comment in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51033#c22
I haven't been able to make it break with -std=c++11 . Is there
something
CC: ebotcazou gcc-patches gingold rth joseph jay.krell
From: mikestump
To: palves
On Jun 15, 2012, at 2:22 AM, Pedro Alves pal...@redhat.com wrote:
It's not about example, but the fact that host compilers have been
compiling that code as part of
This test modifies dg-message, dg-warning, and dg-error test directives
for several G++ tests by adding comments that will be added to lines in
the test summary to eliminate non-unique lines for checks of messages
for the same line of source code in a test.
Tested on i686-pc-linux-gnu and
Like the C stackalign tests, the tests in g++.dg/torture/stackalign use
two sets of torture options: the usual optimization sets used as default
for torture tests, and sets of options that are specific to stack
alignment. There are fewer stack alignment options used for the G++
tests but
Eric == Eric Botcazou ebotca...@adacore.com writes:
Pedro It's not about example, but the fact that host compilers have been
Pedro compiling that code as part of building gcc for years, without anyone
Pedro complaining, afaik. It doesn't matter whether the code pointed at
Pedro is the ugliest
GCOV tests for C++ are run for both std=gnu++98 and std=gnu++11. Those
options are not reported by GCOV-specific lines in the test summary,
leading to non-unique lines. This patch modifies the GCOV test support
to use a testname that includes the extra flags used for a set of tests
and also
On Mon, Jun 11, 2012 at 7:32 AM, Richard Guenther rguent...@suse.de wrote:
This makes ao_ref_from_mem less conservative if either MEM_OFFSET or
MEM_SIZE is not set. From other alias.c code and
set_mem_attributes_minus_bitpos one has to conclude that MEM_EXPR
is always conservatively correct
On Fri, Jun 15, 2012 at 11:06 AM, Janis Johnson
janis_john...@mentor.com wrote:
Like the C stackalign tests, the tests in g++.dg/torture/stackalign use
two sets of torture options: the usual optimization sets used as default
for torture tests, and sets of options that are specific to stack
This patch is for google/main.
Revert Fission patches r182490, r182891, r183042, and r183320.
These will be going into trunk, and will eventually merge back into
google/main from there.
r182490:
gcc/c-family/
2011-12-19 Sterling Augustine saugust...@google.com
*
This patch is for google/gcc-4_7.
Revert Fission patches r182490, r182891, r183042, and r183320.
This will clear the way to backport the final patches from trunk.
r182490:
gcc/c-family/
2011-12-19 Sterling Augustine saugust...@google.com
* c-pretty-print.c
It's true that this is a pedantic violation; but the point here is that
there is no practical barrier to using 'long long'. This code has been
in the tree since 2007; so if there is some issue with it, it ought to
have surfaced by now.
The whole compiler is written using HOST_WIDE_INT and
On Fri, 15 Jun 2012, Ramana Radhakrishnan wrote:
On 15 June 2012 18:18, Marc Glisse marc.gli...@inria.fr wrote:
On Fri, 15 Jun 2012, Ramana Radhakrishnan wrote:
I just noticed this part. Rereading my comment in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51033#c22
I haven't been able to
On Fri, Jun 15, 2012 at 11:06 AM, Ian Lance Taylor i...@google.com wrote:
Richard Guenther richard.guent...@gmail.com writes:
Ian - you added this include in rev. 167764, I don't think that was proper.
But I'm not sure wrapping a system.h include inside extern C from a C++
plugin is proper
Second ping for patch that reorganized warning documentation
http://gcc.gnu.org/ml/gcc-patches/2012-05/msg02024.html
http://gcc.gnu.org/ml/gcc-patches/2012-06/msg00423.html
Eric == Eric Botcazou ebotca...@adacore.com writes:
It's true that this is a pedantic violation; but the point here is that
there is no practical barrier to using 'long long'. This code has been
in the tree since 2007; so if there is some issue with it, it ought to
have surfaced by now.
Gabriel Dos Reis g...@integrable-solutions.net writes:
What we can do is what I suggested
in my last message: just give the language specification to the declarations
that matter in gcc/system.h.
Sure, just have to check #ifdef ENABLE_BUILD_WITH_CXX to know what
specification to give.
Ian
On Jun 15, 2012, at 11:07 AM, Janis Johnson wrote:
GCOV tests for C++ are run for both std=gnu++98 and std=gnu++11. Those
options are not reported by GCOV-specific lines in the test summary,
OK for mainline?
Ok.
It is scary that upvar is ever used
Hello Everyone,
This patch is for the Cilkplus branch affecting both C and C++ compilers.
The dwarf output function was looking for debugging information for an
internally generated spawn helper which is not there. So this patch will make
sure that those functions are excluded.
Thanks,
On 06/15/2012 12:32 PM, Mike Stump wrote:
On Jun 15, 2012, at 11:07 AM, Janis Johnson wrote:
GCOV tests for C++ are run for both std=gnu++98 and std=gnu++11. Those
options are not reported by GCOV-specific lines in the test summary,
OK for mainline?
Ok.
It is scary that upvar is ever
On Fri, 15 Jun 2012, Tom Tromey wrote:
HOST_WIDE_INT is also not very persuasive to me. We did many things in
Although HOST_WIDE_INT is used for too many different things (see Diego's
and my architectural goals documents for more discussion, specifically
HOST_WIDE_INT, HOST_WIDEST_INT and
On 15 June 2012 20:04, Marc Glisse marc.gli...@inria.fr wrote:
On Fri, 15 Jun 2012, Ramana Radhakrishnan wrote:
On 15 June 2012 18:18, Marc Glisse marc.gli...@inria.fr wrote:
On Fri, 15 Jun 2012, Ramana Radhakrishnan wrote:
I just noticed this part. Rereading my comment in
On Fri, Jun 15, 2012 at 2:17 PM, Ian Lance Taylor i...@google.com wrote:
Gabriel Dos Reis g...@integrable-solutions.net writes:
What we can do is what I suggested
in my last message: just give the language specification to the declarations
that matter in gcc/system.h.
Sure, just have to
Gabriel Dos Reis g...@integrable-solutions.net writes:
On Fri, Jun 15, 2012 at 2:17 PM, Ian Lance Taylor i...@google.com wrote:
Gabriel Dos Reis g...@integrable-solutions.net writes:
What we can do is what I suggested
in my last message: just give the language specification to the
[this time as plain text, sorry]
Date: Fri, 15 Jun 2012 19:58:23 +
From: joseph
To: tromey
CC: ebotcazou palves gcc-patches gingold rth mikestump
Subject: Re: long long availability in host compiler (Re: constant that
doesn't fit in 32bits in alpha.c)
On Fri, 15 Jun
---
gcc/expmed.c | 438 +++-
gcc/machmode.h |8 +-
2 files changed, 249 insertions(+), 197 deletions(-)
diff --git a/gcc/expmed.c b/gcc/expmed.c
index b456bac..16c5c24 100644
--- a/gcc/expmed.c
+++ b/gcc/expmed.c
@@ -2,7 +2,7 @@
and
---
gcc/config/i386/i386-protos.h |1 +
gcc/config/i386/i386.c| 76 +
gcc/config/i386/predicates.md |7
gcc/config/i386/sse.md| 72 +++---
4 files changed, 97 insertions(+), 59 deletions(-)
Eric == Eric Botcazou ebotca...@adacore.com writes:
Tom I don't understand what the code being external, or the review, has to
Tom do with anything. This code is compiled with the same host compiler as
Tom everything else.
Eric But, precisely, this line of reasoning is barely defensible in my
On Jun 15, 2012, at 1:11 PM, Eric Botcazou wrote:
Why would HOST_WIDE_INT be obsolete?
For the same reason that we don't use HOST_NARROW_INT instead of int. In
practice, int is portable enough for us now. In reality, long long is portable
for us now. 20 years ago, it wasn't portable enough.
Back when we added C++11 auto deduction, I thought we could shortcut the
normal deduction in some templates, when the type is adequately
describable (thus the late, unlamented function describable_type). Over
time various problems with this have arisen, of which this is the most
recent; as a
On Jun 14, 2012, H.J. Lu hjl.to...@gmail.com wrote:
On Tue, Jun 12, 2012 at 1:42 PM, Richard Henderson r...@redhat.com wrote:
On 2012-06-05 12:33, Alexandre Oliva wrote:
for gcc/ChangeLog
from Alexandre Oliva aol...@redhat.com
PR debug/49888
* var-tracking.c: Include
On Fri, Jun 15, 2012 at 3:06 PM, Richard Henderson r...@redhat.com wrote:
On 2012-06-15 14:42, H.J. Lu wrote:
Latency/throughput info is in Intel optimization reference manual.
Which instructions aren't covered?
Ok, good. The rather old opt ref manual that I had didn't cover these.
The one
On Fri, 15 Jun 2012, Mike Stump wrote:
On Jun 15, 2012, at 2:46 PM, Joseph S. Myers wrote:
HOST_WIDE_INT is an abstraction about the *target*; the target determines
the required properties. The salient properties include:
* At least as wide as target address space.
The first person
93 matches
Mail list logo
