On Wed, Aug 15, 2012 at 10:17:18PM -0700, Gary Funck wrote:
> I can file a bug reported if necessary, but am wondering
> if it is a known requirement not to have "." on $PATH
> or to explicitly set CC and CXX?
Having . in $PATH is a serious bug (especially from security POV).
Just never do that.
On 08/15/12 22:26:08, Ian Lance Taylor wrote:
> it's a bug.
OK, thanks. I submitted a bug report.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54279
- Gary
On Wed, Aug 15, 2012 at 10:17 PM, Gary Funck wrote:
>
> 1. I have "." on $PATH.
>
> 2. In one build of the latest GCC trunk, I specify
>CC=/usr/bin/gcc and CXX=/usr/bin/g++ and everything
>works.
>
> 3. In another build, I don't specify CC or CXX.
>Therefore they default to 'gcc' and '
1. I have "." on $PATH.
2. In one build of the latest GCC trunk, I specify
CC=/usr/bin/gcc and CXX=/usr/bin/g++ and everything
works.
3. In another build, I don't specify CC or CXX.
Therefore they default to 'gcc' and 'g++'.
This fails:
g++: error trying to exec 'cc1plus': execvp:
This patch is okay, but the longlong.h patch is incomplete. It no
longer should test for _ARCH_COM or _ARCH_PWR, because those will not
work.
Committed the following as pre-approved off-list:
2012-08-15 Segher Boessenkool
* longlong.h: (powerpc): Delete _ARCH_PWR and _ARCH_COM handlin
On Wed, Aug 15, 2012 at 6:29 PM, Segher Boessenkool
wrote:
> 2012-08-15 Segher Boessenkool
>
> gcc/
> * config/rs6000/aix43.h (ASM_CPU_SPEC): Use %(asm_default)
> instead of -mppc.
> * config/rs6000/aix51.h (ASM_CPU_SPEC): Ditto.
This patch is okay.
Thanks, David
On Wed, 15 Aug 2012, David Edelsohn wrote:
> Does GCC "own" longlong.h, or is that part of GMP or some other project?
It is right now in sync between glibc and GCC; changes should be applied
in both places. It hasn't been in sync with GMP's version for many years.
--
Joseph S. Myers
jos...@co
On 4/08/2012, at 12:05 AM, Bernd Schmidt wrote:
> This patch allows us to change
>
> rn++
> rm=[rn]
>
> into
>
> rm=[rn + 4]
> rn++
The patch is OK with the following nitpicks.
[BTW, if anyone else wants to review this patch, it helps to read it from the
end.]
>
> Opportunities to do this
On Wed, Aug 15, 2012 at 6:29 PM, Segher Boessenkool
wrote:
> 2012-08-15 Segher Boessenkool
>
> gcc/
> * config/rs6000/aix43.h (TARGET_DEFAULT): Delete MASK_NEW_MNEMONICS.
> (RS6000_CALL_GLUE): Adjust for single assembler syntax.
> * config/rs6000/aix51.h (TARGET_DEFAULT,
On Wed, Aug 15, 2012 at 6:29 PM, Segher Boessenkool
wrote:
> It's always on now. Also remove -mcpu=common.
>
> 2012-08-15 Segher Boessenkool
>
> gcc/
> * common/config/rs6000/rs6000-common.c (rs6000_handle_option):
> Delete handling for -mno-powerpc and -mpowerpc.
> * c
On 08/04/2012 07:55 AM, Richard Sandiford wrote:
> Sandra Loosemore writes:
>> This is another patch that has been present in our local source base for some
>> years now. It originally came from MIPS; I've verified that we have legal
>> permission to contribute it to the FSF.
>>
>> The 74k.md par
On Wed, Aug 15, 2012 at 6:29 PM, Segher Boessenkool
wrote:
> This adds a builtin flag for "always enabled". The value 0 works
> right now as far as I can see, but that is too tricky and should
> be fixed some day.
>
> 2012-08-15 Segher Boessenkool
>
> gcc/
> * config/rs6000/rs6000.h (RS
On Wed, Aug 15, 2012 at 6:29 PM, Segher Boessenkool
wrote:
> 2012-08-15 Segher Boessenkool
>
> gcc/
> * config/rs6000/aix52.h (ASM_CPU_SPEC): Fix typo.
> * config/rs6000/aix53.h (ASM_CPU_SPEC): Ditto.
> * config/rs6000/aix61.h (ASM_CPU_SPEC): Ditto.
> * config/rs
On Wed, Aug 15, 2012 at 6:29 PM, Segher Boessenkool
wrote:
> This fixes PR54142, a problem I exposed when I made -mno-power the
> default.
>
> 2012-08-15 Segher Boessenkool
>
> gcc/
> PR54142
> * config/rs6000/driver-rs6000.c (asm_names): Use %(asm_default)
> instead of
Hi,
This patch replaces MEMBER_TYPE_FORCES_BLK with a target hook. I
also pass the type to the target hook in addition to field, which will
be used by i386 backend for
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20020
This patch doesn't change code generation. Tested on Linux/x86-64. I
also te
On Mon, Aug 6, 2012 at 1:27 PM, Paolo Bonzini wrote:
>> 2. sparseset has the same problem of memory clearing (for valgrind,
>> see sparseset_alloc).
>
> ... only the sparse array needs this clearing, but currently we do it
> for both.
And according to the fat comment before the xcalloc, it's not
There are some problems with it:
- On at least 4.6 and later, it crashes the compiler together with -m64;
- On older versions, it generates incorrect code together with -m64;
- Supposedly it doesn't actually work on 32-bit either, on the glibc side;
- It isn't listed in --target-help, because the o
2012-08-15 Segher Boessenkool
gcc/
* config/rs6000/aix43.h (ASM_CPU_SPEC): Use %(asm_default)
instead of -mppc.
* config/rs6000/aix51.h (ASM_CPU_SPEC): Ditto.
---
gcc/config/rs6000/aix43.h |2 +-
gcc/config/rs6000/aix51.h |2 +-
2 files changed, 2 insertions(+),
Here are some more patches to remove old, unused features from
the rs6000 port.
The first two and last patches fix up some spec strings so that
asm_default is used when it should. The third adds a "bitmask"
RS6000_BTM_ALWAYS for use by the fourth patch; the one builtin
that uses it probably shoul
This adds a builtin flag for "always enabled". The value 0 works
right now as far as I can see, but that is too tricky and should
be fixed some day.
2012-08-15 Segher Boessenkool
gcc/
* config/rs6000/rs6000.h (RS6000_BTM_ALWAYS): New.
---
gcc/config/rs6000/rs6000.h |1 +
1 files c
2012-08-15 Segher Boessenkool
gcc/
* config/rs6000/aix52.h (ASM_CPU_SPEC): Fix typo.
* config/rs6000/aix53.h (ASM_CPU_SPEC): Ditto.
* config/rs6000/aix61.h (ASM_CPU_SPEC): Ditto.
* config/rs6000/driver-rs6000.c (asm_names): Ditto.
---
gcc/config/rs6000/aix52.h
This fixes PR54142, a problem I exposed when I made -mno-power the
default.
2012-08-15 Segher Boessenkool
gcc/
PR54142
* config/rs6000/driver-rs6000.c (asm_names): Use %(asm_default)
instead of -mcom.
* config/rs6000/rs6000.h (ASM_CPU_SPEC): Ditto.
---
gcc/conf
On Wed, Aug 15, 2012 at 2:58 PM, Lawrence Crowl wrote:
>
> I do not much like _t names either.
Also, names ending in _t are reserved by POSIX if you #include
. Though that may only apply to global names, not to
types defined in classes or namespaces.
Ian
Richard Guenther wrote:
> On Wed, 15 Aug 2012, Ulrich Weigand wrote:
> > It seems flow_loops_find by itself is not quite enough, but everything
> > necessary to use the loop structures seems to be encapsulated in
> > loop_optimizer_init / loop_optimizer_finalize, which are already called
> > by a n
Hi all,
I have just committed as obvious a small patch fixing two
ICE-on-invalid PR involving CLASS declarations:
http://gcc.gnu.org/viewcvs?view=revision&revision=190420
Cheers,
Janus
Hi Jing, ping?
On Mon, Aug 13, 2012 at 10:58 AM, Han Shen(沈涵) wrote:
> Hi, the google/gcc-4_7 fails to linking anything (on x86-generic), by
> looking into specs file, it seems that 'link_emulation' section is
> missing in specs.
>
> The problem is in config/i386/linux.h, SUBTARGET_EXTRA_SPECS (w
On 8/15/12, Richard Henderson wrote:
> On 2012-08-15 07:29, Richard Guenther wrote:
>> + typedef typename Element::Element_t Element_t;
>
> Can we use something less ugly than Element_t?
> Such as
>
> typedef typename Element::T T;
>
> ? Given that this name is scoped anyway...
I do not much
On 8/15/12, Richard Guenther wrote:
> On Wed, 15 Aug 2012, Michael Matz wrote:
> > On Wed, 15 Aug 2012, Richard Guenther wrote:
> > > Like the following, only the coverage.c use is converted.
> > > I've never seen template function arguments anywhere and
> > > having to repeat them all
> > >
> > >
On 8/15/12, Richard Guenther wrote:
> On Sun, 12 Aug 2012, Diego Novillo wrote:
> > This implements a new C++ hash table.
> >
> > See http://gcc.gnu.org/ml/gcc-patches/2012-08/msg00711.html for
> > details.
>
> Now as we see the result I'd have prefered a more C++-way instead
> of making the conve
On Tue, Aug 14, 2012 at 2:34 PM, Gary Funck wrote:
> Attached, is an updated patch (with change logs).
>
> The test cases are now in gcc.target/i386 and the
> target selection is "dg-require-effective-target int128" only.
>
> Verified that the tests correctly detect the presence/lack
> of TImode s
On 08/15/2012 06:00 PM, Diego Novillo wrote:
> On the switch to C++ as the build language for GCC ...
Here are my results:
0:30 UTC - using C as the initial build language:
http://gcc.gnu.org/ml/gcc-testresults/2012-08/msg01329.html
and:
18:40 UTC - using C++ as the initial build language:
This patch has been updated to reflect changes in patch r190247, which removed
pfmon support.
The patch should be applied to google/main
Tested with crosstools.
2012-08-14 Chris Manghane
* libgcc/pmu-profile.c
(gcov_write_load_latency_infos): Removed unused function.
> "Jonathan" == Jonathan Wakely writes:
Jonathan> I like it, please go ahead and check that in it you're happy
Jonathan> with it.
I did. Thanks.
Tom
On Wed, Aug 15, 2012 at 1:21 PM, Tom Tromey wrote:
>> "Gaby" == Gabriel Dos Reis writes:
>
> Tom> I asked Keith to resurrect his patch for this.
>
> Gaby> Since people are concerned about typing rules, would it
> Gaby> be an option for GDB to allow people to input pointer
> Gaby> literals wit
> "Gaby" == Gabriel Dos Reis writes:
Tom> I asked Keith to resurrect his patch for this.
Gaby> Since people are concerned about typing rules, would it
Gaby> be an option for GDB to allow people to input pointer
Gaby> literals with the "p" suffix (or "0p" prefix instead of "0x")?
I think on
On Wed, Aug 15, 2012 at 12:53 PM, Tom Tromey wrote:
>> "Diego" == Diego Novillo writes:
>
> Diego> GDB folks, would it be hard to figure out that there is a single
> Diego> variant of the called function and trust the user that they are
> Diego> passing the right pointer value?
>
> I asked Ke
> "Diego" == Diego Novillo writes:
Diego> GDB folks, would it be hard to figure out that there is a single
Diego> variant of the called function and trust the user that they are
Diego> passing the right pointer value?
I asked Keith to resurrect his patch for this.
Tom
On Wed, Jul 25, 2012 at 11:11 AM, Sandra Loosemore
wrote:
> On 07/25/2012 09:57 AM, Richard Henderson wrote:
>>
>> I'll echo Nick's comments about arm asm in a common test.
>> There's no need to have anything but __asm__(""); there.
>>
>> Ok with that change.
>
> Thanks! Here's the version I comm
On Wed, Aug 15, 2012 at 05:49:34PM +0200, Jan Kratochvil wrote:
> On Wed, 15 Aug 2012 17:44:32 +0200, Michael Matz wrote:
> > On Wed, 15 Aug 2012, Jan Kratochvil wrote:
> > It's not needless as the examples here show. gdb is about helping people
> > debug their stuff, not about language lawyering
On Wed, 15 Aug 2012, Jakub Jelinek wrote:
> I was mainly interested in whether such an approach is acceptable, or
> whether I need to stop evaluating sizeof right away, create SIZEOF_EXPR
> and only fold it during fully_fold*. I've briefly looked at that today,
The approach is fine. Delaying ev
Hello,
This patch rewrites the rewriting part of
rewrite_into_loop_closed_ssa. This function took ~300s on the
simplified test case for PR54146, walking around the many thousands of
loops in the >400,000 basic blocks in the CFG, in
compute_global_livein.
For rewriting into LC-SSA, we can do bette
On 2012-08-15 07:29, Richard Guenther wrote:
> + typedef typename Element::Element_t Element_t;
Can we use something less ugly than Element_t?
Such as
typedef typename Element::T T;
? Given that this name is scoped anyway...
r~
On 12-08-15 11:44 , Michael Matz wrote:
Hi,
On Wed, 15 Aug 2012, Jan Kratochvil wrote:
It is a needless violation of C++ resolving rules.
It's not needless as the examples here show. gdb is about helping people
debug their stuff, not about language lawyering.
Agreed. If I'm passing a num
On Wed, Aug 15, 2012 at 03:39:29PM +, Joseph S. Myers wrote:
> On Wed, 18 Jul 2012, Jakub Jelinek wrote:
>
> > + if (warn_sizeof_pointer_memaccess
> > + && sizeof_arg != NULL_TREE)
> > + sizeof_pointer_memaccess_warning (c_last_sizeof_arg_loc,
> > +
Hi,
On Wed, 15 Aug 2012 17:44:32 +0200, Michael Matz wrote:
> On Wed, 15 Aug 2012, Jan Kratochvil wrote:
> It's not needless as the examples here show. gdb is about helping people
> debug their stuff, not about language lawyering.
In such case there should be a GDB setting for it as at least fr
Hi,
On Wed, 15 Aug 2012, Jan Kratochvil wrote:
> It is a needless violation of C++ resolving rules.
It's not needless as the examples here show. gdb is about helping people
debug their stuff, not about language lawyering.
> There are various easy way how to get it working (in .gdbinit or
> c
On Wed, 18 Jul 2012, Jakub Jelinek wrote:
> + if (warn_sizeof_pointer_memaccess
> + && sizeof_arg != NULL_TREE)
> + sizeof_pointer_memaccess_warning (c_last_sizeof_arg_loc,
> + expr.value, exprlist,
> +
Hi,
On Fri, Aug 10, 2012 at 05:12:31AM +0200, Jan Hubicka wrote:
>
> Do you have any data on memory usage? I was originally concerned
> about memory use of the whole predicate thingy on WPA level.
> Eventually we could add simple inheritance on conditions and sort
> them into mutiple vectors if
Hi,
On Fri, Aug 10, 2012 at 04:57:41PM +0200, Eric Botcazou wrote:
> > - ada/gcc-interface/utils.c:rest_of_subprog_body_compilation calls
> > dump_function which in turns calls dump_function_to_file which calls
> > push_cfun. But Ada front end has its idea of the
> > current_function_decl a
On Wed, 15 Aug 2012 14:23:37 +0200, Diego Novillo wrote:
> GDB folks, would it be hard to figure out that there is a single
> variant of the called function and trust the user that they are
> passing the right pointer value?
It is a needless violation of C++ resolving rules. There are various eas
(Adding other C++ maintainers in case someone else wants to have a stab.)
Ping?
Ollie
On Mon, Aug 13, 2012 at 4:01 PM, Ollie Wild wrote:
>
> On Mon, Aug 13, 2012 at 3:50 PM, Jakub Jelinek wrote:
> >
> > The formatting doesn't match GCC coding conventions in several ways.
> > You don't have sp
On 12-08-15 10:44 , Eric Botcazou wrote:
This implements the VEC re-write.
See http://gcc.gnu.org/ml/gcc-patches/2012-08/msg00711.html for
details.
You didn't update the head comment in vec.h though, is that on purpose?
Yes. I am updating it now that I'm *really* changing the interface.
D
On 14 August 2012 15:44, Tom Tromey wrote:
>> "Jonathan" == Jonathan Wakely writes:
>
> Jonathan> I prefer it as unique_ptr but I'm probably not your typical
> Jonathan> user of the pretty printers, so if anyone else has an opinion please
> Jonathan> share it.
>
> I prefer it too. Here's the
> This implements the VEC re-write.
>
> See http://gcc.gnu.org/ml/gcc-patches/2012-08/msg00711.html for
> details.
You didn't update the head comment in vec.h though, is that on purpose?
--
Eric Botcazou
On Wed, 15 Aug 2012, Michael Matz wrote:
> Hi,
>
> On Wed, 15 Aug 2012, Richard Guenther wrote:
>
> > Like the following, only the coverage.c use is converted. I've never
> > seen template function arguments anywhere and having to repeat them all
> > over the place is really really ugly (yes,
On Aug 15, 2012, at 4:59 AM, Richard Guenther wrote:
> and debugging becomes a nightmare (hello gdb people!)
> (gdb) call debug_tree (0x767fa5e8)
> Cannot resolve function debug_tree to any overloaded instance
Inquiring minds want to know if:
macro define debug_tree(A) ((tree)A)
makes the a
Hi,
On Wed, 15 Aug 2012, Richard Guenther wrote:
> Like the following, only the coverage.c use is converted. I've never
> seen template function arguments anywhere and having to repeat them all
> over the place is really really ugly (yes, even if only in the
> implementation).
>
> This goes
On Wed, 15 Aug 2012, Richard Guenther wrote:
> On Sun, 12 Aug 2012, Diego Novillo wrote:
>
> > This implements a new C++ hash table.
> >
> > See http://gcc.gnu.org/ml/gcc-patches/2012-08/msg00711.html for
> > details.
> >
> > Diego.
>
> Now as we see the result I'd have prefered a more C++-way
On Wed, Aug 15, 2012 at 2:53 PM, Jakub Jelinek wrote:
> On Wed, Aug 15, 2012 at 02:36:54PM +0200, Richard Guenther wrote:
>> On Wed, Aug 15, 2012 at 2:29 PM, Jakub Jelinek wrote:
>> > On Wed, Aug 15, 2012 at 02:15:03PM +0200, Richard Guenther wrote:
>> >> Ok. That would still leave us with the i
On Wed, Aug 15, 2012 at 02:36:54PM +0200, Richard Guenther wrote:
> On Wed, Aug 15, 2012 at 2:29 PM, Jakub Jelinek wrote:
> > On Wed, Aug 15, 2012 at 02:15:03PM +0200, Richard Guenther wrote:
> >> Ok. That would still leave us with the issue Ramana brought up - the
> >> target hook returning true
On Wed, Aug 15, 2012 at 2:29 PM, Jakub Jelinek wrote:
> On Wed, Aug 15, 2012 at 02:15:03PM +0200, Richard Guenther wrote:
>> Ok. That would still leave us with the issue Ramana brought up - the
>> target hook returning true unconditionally if a generic permute is
>> implemented.
>> We just avoid
On Wed, Aug 15, 2012 at 02:15:03PM +0200, Richard Guenther wrote:
> Ok. That would still leave us with the issue Ramana brought up - the
> target hook returning true unconditionally if a generic permute is
> implemented.
> We just avoid generic expansion by tree-vect-generic.c that way.
Yeah, if
On 12-08-15 08:18 , Richard Guenther wrote:
0 is fixed if you have recent enough gdb.
(gdb) call debug_tree (0)
as 0 is a null pointer constant.
Oh, cool. Progress.
GDB folks, would it be hard to figure out that there is a single variant
of the called function and trust the user that they
On 15 August 2012 13:07, Jakub Jelinek wrote:
> On Wed, Aug 15, 2012 at 01:46:05PM +0200, Richard Guenther wrote:
>> Well, we're waiting for someone to break the tie ... I'd go with the original
>> patch, improving the backends where necessary.
>
> E.g. i?86/x86_64 with just plain -msse2 has only
On Wed, 15 Aug 2012, Diego Novillo wrote:
> On 12-08-15 07:59 , Richard Guenther wrote:
>
> > (gdb) call debug_tree (*expr_p)
> >
> > constant 9>
> > (gdb) call debug_tree (0x767fa5e8)
> > Cannot resolve function debug_tree to any overloaded instance
>
> Yeah, in the absence of overloads
On 12-08-15 07:59 , Richard Guenther wrote:
(gdb) call debug_tree (*expr_p)
constant 9>
(gdb) call debug_tree (0x767fa5e8)
Cannot resolve function debug_tree to any overloaded instance
Yeah, in the absence of overloads this is annoying. Happens with 0, too.
Diego.
On Wed, Aug 15, 2012 at 2:07 PM, Jakub Jelinek wrote:
> On Wed, Aug 15, 2012 at 01:46:05PM +0200, Richard Guenther wrote:
>> Well, we're waiting for someone to break the tie ... I'd go with the original
>> patch, improving the backends where necessary.
>
> E.g. i?86/x86_64 with just plain -msse2 h
On Wed, Aug 15, 2012 at 01:46:05PM +0200, Richard Guenther wrote:
> Well, we're waiting for someone to break the tie ... I'd go with the original
> patch, improving the backends where necessary.
E.g. i?86/x86_64 with just plain -msse2 has only very small subset of
constant shuffles (and no variabl
On Wed, 15 Aug 2012, Ulrich Weigand wrote:
> Richard Guenther wrote:
> > On Tue, 14 Aug 2012, Ulrich Weigand wrote:
> > > Looks like this broke SPU build, since spu_machine_dependent_reorg
> > > accesses ->loop_depth. According to comments in the code, this
> > > was done because of concerns that
On Wed, Aug 15, 2012 at 1:56 PM, Ramana Radhakrishnan
wrote:
> [It looks like I missed hitting the send button on this response]
>
>>
>> Seems to be one instruction shorter at least ;-) Yes, there can be much
>> worse regressions than that because of the patch (like 40 instructions
>> instead of 4
Richard Guenther wrote:
> On Tue, 14 Aug 2012, Ulrich Weigand wrote:
> > Looks like this broke SPU build, since spu_machine_dependent_reorg
> > accesses ->loop_depth. According to comments in the code, this
> > was done because of concerns that loop_father may no longer be set up
> > this late in
On Sun, 12 Aug 2012, Diego Novillo wrote:
> I will be sending 6 patches that implement all the changes we
> have been making on the cxx-conversion branch. As described in
> http://gcc.gnu.org/ml/gcc/2012-08/msg00015.html, these patches
> change the default bootstrap process so that stage 1 alway
[It looks like I missed hitting the send button on this response]
>
> Seems to be one instruction shorter at least ;-) Yes, there can be much
> worse regressions than that because of the patch (like 40 instructions
> instead of 4, in the x86 backend).
If this is replacing 4 instructions with 40 i
On Wed, Aug 15, 2012 at 1:22 PM, Marc Glisse wrote:
> On Mon, 13 Aug 2012, Marc Glisse wrote:
>
>> I'll give it a few more days for the conversation to settle, so I know
>> what I should do between:
>> - the barely modified patch you accepted,
>> - the check asked by Jakub,
>> - the restriction to
On Mon, 13 Aug 2012, Marc Glisse wrote:
I'll give it a few more days for the conversation to settle, so I know what I
should do between:
- the barely modified patch you accepted,
- the check asked by Jakub,
- the restriction to identity that prevents any regression (well...),
- something else?
Hi Uros,
I send you new patch with fixed space/tab alignments.
About your comment.
It is more optimal to put adding of constant before adding of the
register only for case when 3 instructions must be generated to split
lea. In all other cases it does not matter and I left code
unchangeable.
Bes
On Wed, 15 Aug 2012, Richard Guenther wrote:
> On Wed, Aug 15, 2012 at 12:31 PM, Jakub Jelinek wrote:
> > On Wed, Aug 15, 2012 at 12:28:58PM +0200, Richard Guenther wrote:
> >> the function names make no sense - they should be talking about
> >> host-wide-ints, because that is what they are about
On Wed, Aug 15, 2012 at 12:31 PM, Jakub Jelinek wrote:
> On Wed, Aug 15, 2012 at 12:28:58PM +0200, Richard Guenther wrote:
>> the function names make no sense - they should be talking about
>> host-wide-ints, because that is what they are about. Thus,
>>
>> /* Conversion functions. */
>>
>>
On Wed, Aug 15, 2012 at 12:28:58PM +0200, Richard Guenther wrote:
> the function names make no sense - they should be talking about
> host-wide-ints, because that is what they are about. Thus,
>
> /* Conversion functions. */
>
> HOST_WIDE_INT to_signed_hwi () const;
> unsigned HOST_WIDE_I
On Tue, Aug 14, 2012 at 10:04 AM, Richard Guenther wrote:
> On Mon, 13 Aug 2012, Lawrence Crowl wrote:
>
>> On 8/13/12, Richard Guenther wrote:
>> > Increment/decrement operations did not exist, please do not add
>> > them at this point.
>>
>> Note that I have also added +=, -= and *= operations.
Dear all,
when looking at http://gcc.gnu.org/install/download.html, I wondered
whether some parts should be updated.
In particular
- Mentioning the GIT mirror at http://gcc.gnu.org/wiki/GitMirror
- Mentioning CLOOG/ISL for the in-tree build
Those changes I did in the patch below.
However, I
On Tue, Aug 14, 2012 at 10:46 PM, Lawrence Crowl wrote:
> You can check the error statically. Something like
>
> % cat limitstring.c
> #define LIMIT 32
>
> struct def {
> int x;
> char name[LIMIT+1];
> };
>
> struct def var[] = {
> { 3, "hello" },
> { 4, "name is much too too long for a r
On Tue, 14 Aug 2012, William J. Schmidt wrote:
> Currently we can insert an initializer that performs a multiply in too
> small of a type for correctness. For now, detect the problem and avoid
> the optimization when this would happen. Eventually I will fix this up
> to cause the multiply to be
On Tue, 14 Aug 2012, William J. Schmidt wrote:
> Replace the once vacuously true, and now vacuously false, test for
> existence of a conditional move instruction for a given mode, with one
> that actually checks what it's supposed to. Add a test case so we don't
> miss such things in future.
>
>
Hi,
There's white paper [1] available, which explains usage of MULX/ADCX/ADOX
[1] - http://download.intel.com/embedded/processor/whitepaper/327831.pdf
Thanks, K
85 matches
Mail list logo
