> 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 maintaine
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 wrote:
>> Il 12/06/2012 08:52, Dinar Temirbulatov ha s
> 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]; } UINT1
On Fri, Jun 15, 2012 at 3:40 AM, Easwaran Raman wrote:
> ChangeLog entry has a gcc/ prefix that shouldn't be there. Here is the
> revised entry:
>
> 2012-06-14 Easwaran Raman
>
> * passes.c (init_optimization_passes): Remove pass_call_cdce
> from its current position and insert a
On Fri, Jun 15, 2012 at 7:47 AM, Sharad Singhai wrote:
> On Wed, Jun 13, 2012 at 4:48 AM, Richard Guenther
> wrote:
>> On Fri, Jun 8, 2012 at 7:16 AM, Sharad Singhai wrote:
>>> Okay, I have updated the attached patch so that the output from
>>> -ftree-vectorizer-verbose is considered diagnostic
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_retur
On Thu, Jun 14, 2012 at 11:00 PM, Jakub Jelinek 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.
>
> Bootstrapped/regtested on x86_
> 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 stre
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 mat
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 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
> x86_64-suse-linux
> and
On Fri, Jun 15, 2012 at 11:27 AM, Duncan Sands 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 the use of
> 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 Naci
[AArch64] Update LINK_SPEC.
* config/aarch64/aarch64-linux.h (LINUX_TARGET_LINK_SPEC): Remove
%{version:-v}, %{b} and %{!dynamic
> 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
2012/6/15 Eric Botcazou :
>> 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 rig
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 ea
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 Bo
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
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
> Sameera Deshpande
> Greta Yorsh
>
> * config/arm/arm-protos.h (arm_expand_epilogue
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
> Sameera Deshpande
> Greta Yorsh
>
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
> Sameera Deshpande
> Greta Yorsh
>
> * config/arm/arm-protos.h (thumb2_expand_return): New decl
On 31/05/12 15:09, Greta Yorsh wrote:
> As a result of the previous changes, epilogue_insns pattern can only be
> generated in Thumb1. After removing other cases in define_insn for
> epilogue_insns, the function arm_output_epilogue becomes dead code and can
> be eliminated, along with all its helpe
> 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
* 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" m
> 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 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.
B
> On Thu, Jun 14, 2012 at 5:33 PM, Michael Matz 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 Hon
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: _Z11fanc
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
* tree-vrp.c (set_and_canonicalize_value_range): Use canonical
predicates to set V
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.
2012-06
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 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 analysis to d
On Fri, Jun 15, 2012 at 2:40 PM, Duncan Sands 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 declarati
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.
(di
On Fri, Jun 15, 2012 at 4:48 AM, Richard Guenther
wrote:
> On Fri, Jun 15, 2012 at 11:27 AM, Duncan Sands 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.
On Fri, Jun 15, 2012 at 4:59 AM, Duncan Sands 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 e
On Fri, Jun 15, 2012 at 7:40 AM, Duncan Sands 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 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
what you should declare as such.
my code isn't using fancy_abort directly,
On Fri, Jun 15, 2012 at 8:25 AM, Richard Guenther
wrote:
> On Fri, Jun 15, 2012 at 2:40 PM, Duncan Sands 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"
>>> w
On Fri, Jun 15, 2012 at 9:18 AM, Duncan Sands 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,
as I mentioned a few days ago, I'm working on implementing this feature,
which I personally consider rather high priority, from the library point
of view too (eg, ).
I have been making some progress - I'm attaching below what I have so
far in my local tree - but I also think it's time to
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. */
static
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 indee
Richard Guenther wrote:
> On Fri, Jun 15, 2012 at 3:13 PM, Ulrich Weigand 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 the same check
On Fri, Jun 15, 2012 at 9:33 AM, Duncan Sands 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 think t
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 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.
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 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
http://gcc.gnu.org/ml/gcc-patc
On 15 June 2012 01:44, Jason Merrill 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 lan
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 n
> 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 co
On Jun 15, 2012, at 2:22 AM, Pedro Alves 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
against using a 10
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 tryin
Thanks. I found another one and I fixed it.
2012-06-15 Walter Lee
* config/tilegx/sync.md (atomic_fetch_): Fix typo.
Index: config/tilegx/sync.md
===
--- config/tilegx/sync.md (revision 188672)
+++ config/tilegx/sync.m
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 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 I
> CC: ebotcazou gcc-patches gingold rth joseph jay.krell
> From: mikestump
> To: palves
>
> On Jun 15, 2012, at 2:22 AM, Pedro Alves wrote:
> > It's not about example, but the fact that host compilers have been
> > compiling that code as part of building g
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 arm-none
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 otherwise
> "Eric" == Eric Botcazou 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 or most beau
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 modif
On Mon, Jun 11, 2012 at 7:32 AM, Richard Guenther 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 (it only can
On Fri, Jun 15, 2012 at 11:06 AM, Janis Johnson
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
> alignment. There are fe
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
* c-pretty-print.c (pp_c_specifier_qu
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
* c-pretty-print.c (pp_c_specifier_qualifier_list): Move con
> 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 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 -s
On Fri, Jun 15, 2012 at 11:06 AM, Ian Lance Taylor wrote:
> Richard Guenther 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 1677
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 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.
Eric> The
Gabriel Dos Reis 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,
Ba
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 upv
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 a
On 15 June 2012 20:04, Marc Glisse wrote:
> On Fri, 15 Jun 2012, Ramana Radhakrishnan wrote:
>
>> On 15 June 2012 18:18, Marc Glisse wrote:
>>>
>>> On Fri, 15 Jun 2012, Ramana Radhakrishnan wrote:
>>>
> I just noticed this part. Rereading my comment in
>
> http://gcc.gnu.org/bugzilla/
On Fri, Jun 15, 2012 at 2:17 PM, Ian Lance Taylor wrote:
> Gabriel Dos Reis 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
> I don't understand what the code being external, or the review, has to
> do with anything. This code is compiled with the same host compiler as
> everything else.
But, precisely, this line of reasoning is barely defensible in my opinion. If
you really want to go that route, then let's stop do
Gabriel Dos Reis writes:
> On Fri, Jun 15, 2012 at 2:17 PM, Ian Lance Taylor wrote:
>> Gabriel Dos Reis 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 ch
On Fri, Jun 15, 2012 at 3:31 PM, Ian Lance Taylor wrote:
> Gabriel Dos Reis writes:
>
>> On Fri, Jun 15, 2012 at 2:17 PM, Ian Lance Taylor wrote:
>>> Gabriel Dos Reis writes:
>>>
What we can do is what I suggested
in my last message: just give the language specification to the
d
[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 J
... but not actually fixing it.
I was hoping that the first patch might give the vectorizer enough
info to solve the costing problem, but no such luck. Nevertheless
it would seem that not having the info present at all would be a
bit of a hindrence when actually tweeking the vectorizer later...
---
gcc/config/i386/i386.c | 50 ++-
1 files changed, 40 insertions(+), 10 deletions(-)
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index e2f5740..578a756 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -31990,13 +
---
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 s
---
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(-)
di
> "Eric" == Eric Botcazou 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
Eric> opini
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.
On Fri, Jun 15, 2012 at 1:57 PM, Richard Henderson wrote:
> ... but not actually fixing it.
>
> I was hoping that the first patch might give the vectorizer enough
> info to solve the costing problem, but no such luck. Nevertheless
> it would seem that not having the info present at all would be a
On Fri, 15 Jun 2012, Mike Stump wrote:
> Yes, but why abstract the host? HOST_NARROW_INT is a nice way to
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.
* Constant
> 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;
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 I downloaded this afternoon does. And it seems that we would
need new costs
1 - 100 of 105 matches
Mail list logo
