On Tue, Aug 14, 2012 at 10:45 PM, Diego Novillo dnovi...@google.com wrote:
On 12-08-14 16:39 , Steven Bosscher wrote:
I seriously doubt that ;-)
Anyway, it's not so simple, this 80-len(everything else). I was
looking for a solution like that but it can't be done: there is no
everything
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
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.
The
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, Aug 14, 2012 at 10:46 PM, Lawrence Crowl cr...@googlers.com 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
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:04 AM, Richard Guenther rguent...@suse.de wrote:
On Mon, 13 Aug 2012, Lawrence Crowl wrote:
On 8/13/12, Richard Guenther richard.guent...@gmail.com wrote:
Increment/decrement operations did not exist, please do not add
them at this point.
Note that I have also
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_INT
On Wed, Aug 15, 2012 at 12:31 PM, Jakub Jelinek ja...@redhat.com 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, 15 Aug 2012, Richard Guenther wrote:
On Wed, Aug 15, 2012 at 12:31 PM, Jakub Jelinek ja...@redhat.com 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
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.
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?
On Wed, Aug 15, 2012 at 1:22 PM, Marc Glisse marc.gli...@inria.fr 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
[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 in
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 Wed, Aug 15, 2012 at 1:56 PM, Ramana Radhakrishnan
ramana.radhakrish...@linaro.org 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
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 loop_father
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 variable
On Wed, Aug 15, 2012 at 2:07 PM, Jakub Jelinek ja...@redhat.com 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
On 12-08-15 07:59 , Richard Guenther wrote:
(gdb) call debug_tree (*expr_p)
integer_cst 0x7695d7c0 type integer_type 0x767fa5e8 int
constant 9
(gdb) call debug_tree (0x767fa5e8)
Cannot resolve function debug_tree to any overloaded instance
Yeah, in the absence of overloads this
On Wed, 15 Aug 2012, Diego Novillo wrote:
On 12-08-15 07:59 , Richard Guenther wrote:
(gdb) call debug_tree (*expr_p)
integer_cst 0x7695d7c0 type integer_type 0x767fa5e8 int
constant 9
(gdb) call debug_tree (0x767fa5e8)
Cannot resolve function debug_tree to any
On 15 August 2012 13:07, Jakub Jelinek ja...@redhat.com 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
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
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 Wed, Aug 15, 2012 at 2:29 PM, Jakub Jelinek ja...@redhat.com 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
On Wed, Aug 15, 2012 at 2:53 PM, Jakub Jelinek ja...@redhat.com 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 ja...@redhat.com wrote:
On Wed, Aug 15, 2012 at 02:15:03PM +0200, Richard Guenther wrote:
Ok. That would
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 instead
of
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 with
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
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, even if
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 14 August 2012 15:44, Tom Tromey wrote:
Jonathan == Jonathan Wakely jwakely@gmail.com writes:
Jonathan I prefer it as unique_ptrdatum 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.
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.
(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 a...@google.com wrote:
On Mon, Aug 13, 2012 at 3:50 PM, Jakub Jelinek ja...@redhat.com wrote:
The formatting doesn't match GCC coding conventions in several
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 easy
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 and
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
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 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
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 from
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,
+
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
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~
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
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
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, Jul 25, 2012 at 11:11 AM, Sandra Loosemore
san...@codesourcery.com 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
Diego == Diego Novillo dnovi...@google.com 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, Aug 15, 2012 at 12:53 PM, Tom Tromey tro...@redhat.com wrote:
Diego == Diego Novillo dnovi...@google.com 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
Gaby == Gabriel Dos Reis g...@integrable-solutions.net 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)?
On Wed, Aug 15, 2012 at 1:21 PM, Tom Tromey tro...@redhat.com wrote:
Gaby == Gabriel Dos Reis g...@integrable-solutions.net 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
Jonathan == Jonathan Wakely jwakely@gmail.com writes:
Jonathan I like it, please go ahead and check that in it you're happy
Jonathan with it.
I did. Thanks.
Tom
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 cm...@google.com
* libgcc/pmu-profile.c
(gcov_write_load_latency_infos): Removed unused
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:
On Tue, Aug 14, 2012 at 2:34 PM, Gary Funck g...@intrepid.com 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
On 8/15/12, Richard Guenther rguent...@suse.de 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
On 8/15/12, Richard Guenther rguent...@suse.de 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 Henderson r...@redhat.com 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
Hi Jing, ping?
On Mon, Aug 13, 2012 at 10:58 AM, Han Shen(沈涵) shen...@google.com 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,
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=revisionrevision=190420
Cheers,
Janus
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 number of
On Wed, Aug 15, 2012 at 2:58 PM, Lawrence Crowl cr...@google.com wrote:
I do not much like _t names either.
Also, names ending in _t are reserved by POSIX if you #include
sys/types.h. Though that may only apply to global names, not to
types defined in classes or namespaces.
Ian
This fixes PR54142, a problem I exposed when I made -mno-power the
default.
2012-08-15 Segher Boessenkool seg...@kernel.crashing.org
gcc/
PR54142
* config/rs6000/driver-rs6000.c (asm_names): Use %(asm_default)
instead of -mcom.
* config/rs6000/rs6000.h
2012-08-15 Segher Boessenkool seg...@kernel.crashing.org
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.
---
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 seg...@kernel.crashing.org
gcc/
* config/rs6000/rs6000.h (RS6000_BTM_ALWAYS): New.
---
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 should
2012-08-15 Segher Boessenkool seg...@kernel.crashing.org
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
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
On Mon, Aug 6, 2012 at 1:27 PM, Paolo Bonzini bonz...@gnu.org 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,
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
On Wed, Aug 15, 2012 at 6:29 PM, Segher Boessenkool
seg...@kernel.crashing.org wrote:
This fixes PR54142, a problem I exposed when I made -mno-power the
default.
2012-08-15 Segher Boessenkool seg...@kernel.crashing.org
gcc/
PR54142
* config/rs6000/driver-rs6000.c
On Wed, Aug 15, 2012 at 6:29 PM, Segher Boessenkool
seg...@kernel.crashing.org wrote:
2012-08-15 Segher Boessenkool seg...@kernel.crashing.org
gcc/
* config/rs6000/aix52.h (ASM_CPU_SPEC): Fix typo.
* config/rs6000/aix53.h (ASM_CPU_SPEC): Ditto.
*
On 08/04/2012 07:55 AM, Richard Sandiford wrote:
Sandra Loosemoresan...@codesourcery.com 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.
On Wed, Aug 15, 2012 at 6:29 PM, Segher Boessenkool
seg...@kernel.crashing.org wrote:
2012-08-15 Segher Boessenkool seg...@kernel.crashing.org
gcc/
* config/rs6000/aix43.h (TARGET_DEFAULT): Delete MASK_NEW_MNEMONICS.
(RS6000_CALL_GLUE): Adjust for single assembler syntax.
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 are
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
On Wed, Aug 15, 2012 at 6:29 PM, Segher Boessenkool
seg...@kernel.crashing.org wrote:
2012-08-15 Segher Boessenkool seg...@kernel.crashing.org
gcc/
* config/rs6000/aix43.h (ASM_CPU_SPEC): Use %(asm_default)
instead of -mppc.
* config/rs6000/aix51.h (ASM_CPU_SPEC):
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:
On Wed, Aug 15, 2012 at 10:17 PM, Gary Funck g...@intrepid.com 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
79 matches
Mail list logo
