libgcj's soversion was updated two weeks ago but LIBGCJ_SONAME was not
updated accordingly. I have sent a separate patch to java-patches@ to
add a comment to libjava/libtool-version to avoid this omission in the
future.
Patch attached.
Yaakov
Cygwin Ports
2011-07-20 Yaakov Selkowitz
* con
The gettext macros use config.rpath to determine the link library name
of libiconv and libintl (on non-glibc platforms); the import library
suffix is of importance, not the runtime library suffix. On PE
platforms, these differ, and by using the latter in config.rpath, the
gettext macros think shar
While reviewing the state of gcc constexpr vs. ISO C++, I noticed that
the bitset access operator was missing, so I added it thusly.
Like ice cream on a hot summer day, the expanded constexpr diagnostics
do not disappoint. Thanks Jason!
An example:
testsuite/23_containers/bitset/operations/cons
On Tue, Jul 19, 2011 at 6:16 PM, H.J. Lu wrote:
> On Tue, Jul 19, 2011 at 10:25 AM, Richard Henderson wrote:
>> On 07/19/2011 10:18 AM, H.J. Lu wrote:
>>> I had it in my x32 tree. But I reverted:
>>>
>>> http://gcc.gnu.org/ml/gcc-patches/2011-02/msg00954.html
>>>
>>> since Pmode is used in non-PI
This patch is one of patch set to add a new port (TI C6x) in gdb. In
this patch, "gdb" is removed from noconfigdirs in top-level configure.ac.
OK for gcc and binutils?
--
Yao (齐尧)
>From 321345017e27e908539502a3f08bc604c5f60c66 Mon Sep 17 00:00:00 2001
From: Yao Qi
Date: Mon, 11 Jul 2011 01:30:
"H.J. Lu" writes:
> It caused:
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49787
Here is a patch. Tested only by running configure, though I am starting
a bootstrap.
OK for mainline?
Ian
2011-07-19 Ian Lance Taylor
PR bootstrap/49787
* configure.ac: Move --enable-boo
On Tue, Jul 19, 2011 at 10:25 AM, Richard Henderson wrote:
> On 07/19/2011 10:18 AM, H.J. Lu wrote:
>> I had it in my x32 tree. But I reverted:
>>
>> http://gcc.gnu.org/ml/gcc-patches/2011-02/msg00954.html
>>
>> since Pmode is used in non-PIC tablejump, we have to put 64bit value for
>> labels wit
e of a separate problem with the infrastructure at IBM,
but I receive the following error during the first build of libstdc++:
In file included from /farm/dje/src/src/libstdc++-v3/src/debug.cc:30:0:
/tmp/20110719/powerpc-ibm-aix5.3.0.0/libstdc++-v3/include/debug/safe_local_iterator.h:91:50:
error: &
On Tue, Jul 19, 2011 at 5:26 PM, H.J. Lu wrote:
> On Tue, Jul 19, 2011 at 11:33 AM, Ian Lance Taylor wrote:
>> Ian Lance Taylor writes:
>>
>>> I would like to propose this patch as a step toward building gcc using a
>>> C++ compiler. This patch builds stage1 with the C compiler as usual,
>>> an
On Tue, Jul 19, 2011 at 11:33 AM, Ian Lance Taylor wrote:
> Ian Lance Taylor writes:
>
>> I would like to propose this patch as a step toward building gcc using a
>> C++ compiler. This patch builds stage1 with the C compiler as usual,
>> and defaults to building stages 2 and 3 with a C++ compile
On Tue, Jul 19, 2011 at 5:02 PM, Michael Meissner
wrote:
> (I had an emacs failure when sending out this message, and I may have sent out
> a blank message by accident -- sorry if I did).
>
> When I did the original power7 support, I switched all of the floating point
> operations to use VSX instr
On 07/15/2011 01:58 PM, Jakub Jelinek wrote:
> * dwarf2.h (DW_MACINFO_lo_user, DW_MACINFO_hi_user): Add.
> (DW_MACINFO_GNU_define_indirect, DW_MACINFO_GNU_undef_indirect,
> DW_MACINFO_GNU_transparent_include, DW_MACINFO_GNU_define_opcode):
> Add.
>
> * dwarf2out.c (dw
On Tue, Jul 19, 2011 at 1:33 PM, Ian Lance Taylor wrote:
> Ian Lance Taylor writes:
> I got agreement from two global reviewers and no objections.
>
> I have committed this patch.
Great!
-- Gaby
I've been distracted by other things, but got back to this today...
On Wed, 2011-07-06 at 16:58 +0200, Richard Guenther wrote:
> Ah, so we still have the ARRAY_REFs here. Yeah, well - then the
> issue boils down to get_inner_reference canonicalizing the offset
> according to what fold-const.c imp
Currently, FRV port is broken. It crashes on assertion in IRA because
the right pressure register classes can not be found.
I started work on this and found that register move cost for moving
between GPR_REGS (or QUAD_REGS) is too costly (40) although FRV
machine dependent code reports it cheap
On 07/16/2011 10:37 AM, Dodji Seketeli wrote:
test12.c:9:15: erreur: called object ‘var’ is not a function
test12.c:4:16: note: in expansion of macro 'C'
test12.c:3:14: note: expanded from here
test12.c:3:16: note: in expansion of macro 'B'
test12.c:2:14: note: expanded from here
test12.c:2:16: n
(I had an emacs failure when sending out this message, and I may have sent out
a blank message by accident -- sorry if I did).
When I did the original power7 support, I switched all of the floating point
operations to use VSX instructions instead of the traditional instructions.
The traditional fu
2011/7/19 Richard Guenther :
> On Tue, Jul 19, 2011 at 1:27 PM, Kai Tietz wrote:
>> Hello,
>>
>> So this is the updated patch for boolifying of comparisons. There are
>> two different kind of regression caused by this. One is fixed by the
>> VRP patch I've sent and it waits for review. The other
Hi Richard,
Thanks for committing! Just one small note:
2011/7/19 Richard Sandiford :
> needs to deal with linux64.h as well. I also kept the copyright notice
> the same on linux.h (even though it's only a one-liner now).
>
> Applied with those changes, thanks.
It's probably harmless, but with
On Tue, Jul 19, 2011 at 16:34, Delesley Hutchins wrote:
> 2011-07-19 DeLesley Hutchins
>
> * tree-threadsafe-analyze.c: Changes lock_expr_tab to be allocated by
> the garbage collector, and marked as a GC root.
OK.
Diego.
This patch changes lock_expr_tab so that it is allocated by the
garbage collector, and properly marked as a GC root.
Bootstrapped and passed GCC regression testsuite on x86_64-unknown-linux-gnu.
Okay for branches/annotalysis and google/main?
-DeLesley
2011-07-19 DeLesley Hutchins
*
Typos in warning messages, wrong message for NON_CALL_EXCEPTIONS, duplicated
TARGET_OPTIMIZATION_MISMATCH and OPTIMIZATION_MISMATCH entries.
Tested on i586-suse-linux, applied on the mainline as obvious.
2011-07-19 Eric Botcazou
* cif-code.def (OVERWRITABLE): Fix typo and move aroun
On Tue, Jul 19, 2011 at 03:13:59PM +0200, Jakub Jelinek wrote:
> I've bootstrapped/regtested on 4.5 branch on x86_64-linux and i686-linux
> following
> patches and committed to the branch. Will backport those that are needed
> for 4.4 also soon.
And here are the 4.4 backports, again bootstrapped
On Tue, Jul 19, 2011 at 6:30 PM, Jakub Jelinek wrote:
>> Sometimes, the compiler is really creative in inventing instructions:
>>
>> (insn 47 46 49 7 (set (reg:SI 68 [ D.1686 ])
>> (subreg:SI (plus:SF (reg:SF 159 [ D.1685 ])
>> (reg:SF 159 [ D.1685 ])) 0)) omp_atomic1.f90:
On Tue, Jul 19, 2011 at 10:49 AM, H.J. Lu wrote:
> On Tue, Jul 19, 2011 at 10:33 AM, Uros Bizjak wrote:
>> On Tue, Jul 19, 2011 at 6:37 PM, Uros Bizjak wrote:
> Sometimes, the compiler is really creative in inventing instructions:
>
> (insn 47 46 49 7 (set (reg:SI 68 [ D.1686 ])
Ian Lance Taylor writes:
> I would like to propose this patch as a step toward building gcc using a
> C++ compiler. This patch builds stage1 with the C compiler as usual,
> and defaults to building stages 2 and 3 with a C++ compiler built during
> stage 1. This means that the gcc installed and
Martin Jambor wrote:
> I had to add a test that the analyzed expression is not an SSA name.
> This has been approved by Rchi on IRC yesterday. Thus, I have
> committed the following as revision 175703 after successful run of c
> and c++ testsuite on sparc64 (and a bootstrap and test with another
Robert Millan writes:
> This patch splits those bits from:
>
> config/mips/linux.h
> config/mips/linux64.h
>
> which are applicable to GNU userland, into:
>
> config/mips/gnu-user.h
> config/mips/gnu-user64
>
> respectively. It is analogous to the split that was performed for
> config/i386/* by J
On Tue, Jul 19, 2011 at 10:49 AM, Uros Bizjak wrote:
> On Tue, Jul 19, 2011 at 6:47 AM, H.J. Lu wrote:
>
>> This patch adds the missing Pmode check and conversion. OK for trunk?
>
>> 2011-07-18 H.J. Lu
>>
>> * config/i386/i386.c (ix86_legitimize_address): Convert to
>> Pmode if
On Tue, Jul 19, 2011 at 6:47 AM, H.J. Lu wrote:
> This patch adds the missing Pmode check and conversion. OK for trunk?
> 2011-07-18 H.J. Lu
>
> * config/i386/i386.c (ix86_legitimize_address): Convert to
> Pmode if needed.
> (ix86_expand_move): Likewise.
> (ix86_e
On Tue, Jul 19, 2011 at 10:33 AM, Uros Bizjak wrote:
> On Tue, Jul 19, 2011 at 6:37 PM, Uros Bizjak wrote:
Sometimes, the compiler is really creative in inventing instructions:
(insn 47 46 49 7 (set (reg:SI 68 [ D.1686 ])
(subreg:SI (plus:SF (reg:SF 159 [ D.1685 ])
>>>
On Tue, 19 Jul 2011 16:09:59 +0200
Romain Geissler wrote:
> Hi,
>
> Melt is creating annoying *.c files next to the .so module file, and i
> just can no
> longer handle temporary files polluting my final binary directory.
> Here is a simple patch
> that allow the user to give an explicit coutput
Jason Merrill writes:
> On 07/19/2011 05:42 AM, Dodji Seketeli wrote:
>> If you are talking about the case of a macro A that can have (among the
>> tokens of its replacement list) a token B that itself is a macro, then
>> this is supported by the current setup.
>
> I was more thinking of the case
On Tue, Jul 19, 2011 at 7:33 PM, Uros Bizjak wrote:
Sometimes, the compiler is really creative in inventing instructions:
(insn 47 46 49 7 (set (reg:SI 68 [ D.1686 ])
(subreg:SI (plus:SF (reg:SF 159 [ D.1685 ])
(reg:SF 159 [ D.1685 ])) 0)) omp_atomi
On Tue, Jul 19, 2011 at 6:37 PM, Uros Bizjak wrote:
>>> Sometimes, the compiler is really creative in inventing instructions:
>>>
>>> (insn 47 46 49 7 (set (reg:SI 68 [ D.1686 ])
>>> (subreg:SI (plus:SF (reg:SF 159 [ D.1685 ])
>>> (reg:SF 159 [ D.1685 ])) 0)) omp_atomic1.f9
On 07/19/2011 03:21 AM, Georg-Johann Lay wrote:
>> Yes, it is sad that the backends have to work around the fact
>> that sign/zero_extension of constants is invalid rtl.
>
> Why is that invalid?
>
> (set (reg:HI A)
> (const_int 1000))
>
> (set (reg:SI B)
> (mult:SI (zero_extend:SI (reg
On 07/19/2011 10:18 AM, H.J. Lu wrote:
> I had it in my x32 tree. But I reverted:
>
> http://gcc.gnu.org/ml/gcc-patches/2011-02/msg00954.html
>
> since Pmode is used in non-PIC tablejump, we have to put 64bit value for
> labels with 0 upper 32bits in tablejump for x32.
The mode is completely con
The code was assuming that a template parameter pack can only be
followed by another parameter pack; this is not the case in this testcase.
Tested x86_64-pc-linux-gnu, applying to trunk and 4.6.
commit 4d9cede24b6be5a717b54cdcbc6bdbd00e19ef7f
Author: Jason Merrill
Date: Tue Jul 19 12:16:29 20
On Tue, Jul 19, 2011 at 10:12 AM, Richard Henderson wrote:
> On 07/18/2011 09:45 PM, H.J. Lu wrote:
>> @@ -14861,14 +14919,22 @@ ix86_output_addr_vec_elt (FILE *file, int value)
>> {
>> const char *directive = ASM_LONG;
>>
>> + if (TARGET_X32)
>> + {
>> + fprintf (file, "%s%s%d\n", di
On 07/18/2011 09:45 PM, H.J. Lu wrote:
> @@ -14861,14 +14919,22 @@ ix86_output_addr_vec_elt (FILE *file, int value)
> {
>const char *directive = ASM_LONG;
>
> + if (TARGET_X32)
> +{
> + fprintf (file, "%s%s%d\n", directive, LPREFIX, value);
> + fprintf (file, "%s0\n", directiv
On 07/19/2011 05:24 PM, Mikael Morin wrote:
On Monday 18 July 2011 21:37:24 Tobias Burnus wrote:
Now about your request:
I would be happy if someone could carefully read the function in expr.c
- and confirm that the second test case ("dg-error" line) is indeed
invalid. I think it is invalid beca
On 07/19/2011 05:42 AM, Dodji Seketeli wrote:
If you are talking about the case of a macro A that can have (among the
tokens of its replacement list) a token B that itself is a macro, then
this is supported by the current setup.
I was more thinking of the case of a macro A with a parameter X wh
On Tue, Jul 19, 2011 at 6:30 PM, Jakub Jelinek wrote:
> On Tue, Jul 19, 2011 at 06:26:33PM +0200, Uros Bizjak wrote:
>> Sometimes, the compiler is really creative in inventing instructions:
>>
>> (insn 47 46 49 7 (set (reg:SI 68 [ D.1686 ])
>> (subreg:SI (plus:SF (reg:SF 159 [ D.1685 ])
>>
On Tue, Jul 19, 2011 at 06:26:33PM +0200, Uros Bizjak wrote:
> Sometimes, the compiler is really creative in inventing instructions:
>
> (insn 47 46 49 7 (set (reg:SI 68 [ D.1686 ])
> (subreg:SI (plus:SF (reg:SF 159 [ D.1685 ])
> (reg:SF 159 [ D.1685 ])) 0)) omp_atomic1.f90
Ping.
On Tue, Jul 12, 2011 at 3:45 PM, Ian Lance Taylor wrote:
> This patch to the C frontend disables warnings about -Wstrict-overflow
> when handling expressions which will not be evaluated. This fixes PR
> 49705.
>
> Bootstrapped and tested on x86_64-unknown-linux-gnu.
>
> OK for mainline?
>
On Tue, Jul 19, 2011 at 4:42 PM, H.J. Lu wrote:
> On Tue, Jul 19, 2011 at 7:04 AM, Uros Bizjak wrote:
>> On Tue, Jul 19, 2011 at 3:47 PM, H.J. Lu wrote:
>>
Attached patch simply removes these two checks, as it seems they are
not needed. This also follows how other Pmode != ptr_mode tar
On Mon, Jul 18, 2011 at 21:38, Guozhi Wei wrote:
> 2011-07-19 Guozhi Wei
>
> Backport r176293 from gcc-4_6-branch
>
> 2011-07-14 Janis Johnson
>
> * gcc.target/arm/pr42093.c: Use "-fno-reorder-blocks".
This is not needed now. I committed a merge from gcc-4_6-b
Hi,
On Tue, 19 Jul 2011, Richard Guenther wrote:
> *** forward_propagate_comparison (gimple stm
> *** 1164,1170
> }
> /* We can propagate the condition into a statement that
>computes the logical negation of the comparison result. */
> ! else if (gi
On Monday 18 July 2011 21:37:24 Tobias Burnus wrote:
> As the coarray status is nontrivial to check, I have created a function
> for that - and I use it now for the interface checking. There are more
> cases, where the wrong check is used, leading to accepts-invalid and
> rejects-valid issues; howe
> * a/gcc/gcse.c (alloc_gcse_mem): Added code to run in PRE2.
And this is necessary because...???
Why not just make it a separate pass in ix86-reorg that uses LCM? Look
at mode switching for an example.
Ciao!
Steven
Committed as rev. 176464.
2011-07-19 Vladimir Makarov
* MAINTAINERS (Register Allocation): Move myself from reviewers to
maintainers.
Index: MAINTAINERS
===
--- MAINTAINERS(revision 176462)
+++ MAINTAINERS(working
Vladimir Makarov wrote:
> On 07/19/2011 04:13 AM, Georg-Johann Lay wrote:
>> Vladimir Makarov wrote:
>>> On 07/18/2011 04:14 PM, Richard Henderson wrote:
On 07/18/2011 12:15 PM, Georg-Johann Lay wrote:
>> However, what you've done is try very hard to work around reload
>> doing the Rig
Ketaki,
Some comments on your patch. Apologies for the delay. It's going in
the right direction, though it needs several adjustments.
Could you please add the document you sent me for the grammar to the
wiki page? It's better if we edit the grammar there instead of having
a separate document.
Hello Richard,
Thanks a lot for the review!
> it's not easy to follow the flow of this function, esp. I wonder
>
> + else
> + {
> + tree var = create_tmp_reg (TREE_TYPE (last_rhs1), "reassoc");
> + add_referenced_var (var);
> + stmts[i] = build_and_add_sum (var,
On Tue, Jul 19, 2011 at 7:04 AM, Uros Bizjak wrote:
> On Tue, Jul 19, 2011 at 3:47 PM, H.J. Lu wrote:
>
>>> Attached patch simply removes these two checks, as it seems they are
>>> not needed. This also follows how other Pmode != ptr_mode targets.
>>>
>>> 2011-07-19 Uros Bizjak
>>>
>>>
On Tue, Jul 19, 2011 at 04:09:59PM +0200, Romain Geissler wrote:
> Hi,
>
> Melt is creating annoying *.c files next to the .so module file, and i
> just can no
> longer handle temporary files polluting my final binary directory.
> Here is a simple patch
> that allow the user to give an explicit co
On 07/19/2011 04:13 AM, Georg-Johann Lay wrote:
Vladimir Makarov wrote:
On 07/18/2011 04:14 PM, Richard Henderson wrote:
On 07/18/2011 12:15 PM, Georg-Johann Lay wrote:
However, what you've done is try very hard to work around reload
doing the Right Thing with constant spilling, namely re-gene
Hi all,
I just committed a small patch for an ICE-on-invalid regression with
ALLOCATE, which was approved by Tobias in the PR:
http://gcc.gnu.org/viewcvs?view=revision&revision=176447
I will backport this to the 4.6 branch in a few days. Should I also
backport to 4.5?
Cheers,
Janus
Hi,
Melt is creating annoying *.c files next to the .so module file, and i
just can no
longer handle temporary files polluting my final binary directory.
Here is a simple patch
that allow the user to give an explicit coutput file path in all
translateto* modes.
By the way, trying to reach the C s
On Tue, Jul 19, 2011 at 3:47 PM, H.J. Lu wrote:
>> Attached patch simply removes these two checks, as it seems they are
>> not needed. This also follows how other Pmode != ptr_mode targets.
>>
>> 2011-07-19 Uros Bizjak
>>
>> PR target/49780
>> * config/i386/i386.c (ix86_legitimat
Bernd Schmidt writes:
> I'm not even getting to that point. ia64 has been pretty broken for me
> over the last couple of weeks.
>
> checking for exception model to use... configure: error: unable to
> detect exception model
> make: *** [configure-target-libstdc++-v3] Error 1
Did you look at conf
On 07/19/11 14:25, Andreas Schwab wrote:
> I'm now seeing this ICE:
>
> /bin/sh ./libtool --tag=GCJ --mode=compile
> /usr/local/gcc/gcc-20110719/Build/./gcc/gcj
> -B/usr/local/gcc/gcc-20110719/Build/ia64-suse-linux/libjava/
> -B/usr/local/gcc/gcc-20110719/Build/./gcc/
On Tue, Jul 19, 2011 at 2:16 AM, Uros Bizjak wrote:
> On Tue, Jul 19, 2011 at 10:46 AM, Richard Guenther
> wrote:
>
> TARGET_MEM_REF only works on ptr_mode. This patch allows 32bit
> address
> in x32 mode. OK for trunk?
Do you perhaps have a testcase
This removes the easy cases that seem no longer necessary. I left
the building of TRUHT_*_EXPRs for the sake of chaining conditions
in place. Fold is used as simplification machinery here and
it likely can handle TRUTH_*_EXPRs best. In the end this really
asks for a tree-affine.c like machinery
On Tue, Jul 19, 2011 at 3:27 PM, Ira Rosen wrote:
> On 19 July 2011 11:50, Richard Guenther wrote:
>> On Tue, Jul 19, 2011 at 8:25 AM, Ira Rosen wrote:
> ;
>>> +
>>> + if (!compare_tree_int (DR_STEP (dr), 0))
>>
>> integer_zerop (DR_STEP (dr))
>>
>
> Right. I'll change this with some other oppo
On 19 July 2011 11:50, Richard Guenther wrote:
> On Tue, Jul 19, 2011 at 8:25 AM, Ira Rosen wrote:
;
>> +
>> + if (!compare_tree_int (DR_STEP (dr), 0))
>
> integer_zerop (DR_STEP (dr))
>
Right. I'll change this with some other opportunity, if that's ok.
Thanks,
Ira
This splits out the real fix for PR18908 from the previous patch
which also adjusted integer_all_onesp. It also removes the
no longer appearing TRUTH_* exprs from expansion (and STATEMENT_LIST
while I'm there).
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.
Richard.
201
Hi!
I've bootstrapped/regtested on 4.5 branch on x86_64-linux and i686-linux
following
patches and committed to the branch. Will backport those that are needed
for 4.4 also soon.
Jakub
2011-07-19 Jakub Jelinek
Backport from mainline
2011-05-18 Jakub Jelinek
Hi!
This patch splits those bits from:
config/mips/linux.h
config/mips/linux64.h
which are applicable to GNU userland, into:
config/mips/gnu-user.h
config/mips/gnu-user64
respectively. It is analogous to the split that was performed for
config/i386/* by Joseph Myers in r172271.
I've verified
Hans-Peter Nilsson wrote:
> On Thu, 14 Jul 2011, Ulrich Weigand wrote:
> > I see that this went already in, but I'm wondering why this
> > change should be necessary. As far as register use is
> > concerned, setjmp ought to behave just like a regular function:
> > if a register is call-clobbered,
2011/7/19 Jakub Jelinek :
> On Tue, Jul 19, 2011 at 02:26:32PM +0200, Romain Geissler wrote:
>> 2011-07-18 Romain Geissler
>>
>> * gengtype-state.c (#include "bconfig.h"): include "bconfig.h"
>> if GENERATOR_FILE is defined, "config.h" otherwise.
>> * gengtype.c: Likewise.
>>
On Tue, Jul 19, 2011 at 02:26:32PM +0200, Romain Geissler wrote:
> 2011-07-18 Romain Geissler
>
> * gengtype-state.c (#include "bconfig.h"): include "bconfig.h"
> if GENERATOR_FILE is defined, "config.h" otherwise.
> * gengtype.c: Likewise.
> * gengtype-lex.l: Likewise.
2011/7/19 Laurynas Biveinis :
> 2011/7/18 Romain Geissler :
>> * gengtype-state.c (#include "bconfig.h"): #include "config.h"
>> with host CC
>
> include "bconfig.h" if GENERATOR_FILE is defined, "config.h" otherwise.
>
>> * gengtype.c: Likewise
>> * gengtype-lex.l: Like
I'm now seeing this ICE:
/bin/sh ./libtool --tag=GCJ --mode=compile
/usr/local/gcc/gcc-20110719/Build/./gcc/gcj
-B/usr/local/gcc/gcc-20110719/Build/ia64-suse-linux/libjava/
-B/usr/local/gcc/gcc-20110719/Build/./gcc/ -B/usr/ia64-suse-linux/bin/
-B/usr/ia64-suse-linux/lib/ -isystem /usr
Hello,
This minor patch add a primitive to get a list of s-expression from a
boxed C string of a strbuf.
This is only the MELT part, as the called C code was already written.
I compiled and test it.
Thanks!
Pierre Vittet
2011-07-18 Pierre Vittet
* melt/warmelt-base.melt (read_str
Richard Henderson wrote:
> On 07/18/2011 08:41 AM, Georg-Johann Lay wrote:
>> +(define_insn_and_split "*muluqihi3.uconst"
>> + [(set (match_operand:HI 0 "register_operand" "=r")
>> +(mult:HI (zero_extend:HI (match_operand:QI 1 "register_operand"
>> "r"))
>> +
On Tue, Jul 19, 2011 at 2:15 PM, Richard Sandiford
wrote:
> In 49742, we have:
>
> vect_array.21 = LOAD_LANES (MEM[(int[512] *)vect_pin.17_56]);
> vect_var_.22_58 = vect_array.21[0];
>
> predcom doesn't think that there are any dependencies between
> the two statements, so hoists the second one
In 49742, we have:
vect_array.21 = LOAD_LANES (MEM[(int[512] *)vect_pin.17_56]);
vect_var_.22_58 = vect_array.21[0];
predcom doesn't think that there are any dependencies between
the two statements, so hoists the second one as an invariant.
This in turn is because get_references_in_stmt ignor
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.
Richard.
2011-07-19 Richard Guenther
* Makefile.in (tree-ssa-forwprop.o): Depend on gimple-pretty-print.h.
* tree-ssa-forwprop.c: Include gimple-pretty-print.h.
(forward_propagate_comparison): Simp
2011/7/18 Romain Geissler :
> * gengtype-state.c (#include "bconfig.h"): #include "config.h"
> with host CC
include "bconfig.h" if GENERATOR_FILE is defined, "config.h" otherwise.
> * gengtype.c: Likewise
>* gengtype-lex.l: Likewise
>* gengtype-parse.c: Likewi
On Fri, Jul 15, 2011 at 9:42 AM, Kai Tietz wrote:
> Hello,
>
> This patch removes from tree-vrp the use of TRUTH-bitwise expression codes.
> Also
> it merges the handling for boolean compatible and non-boolean typed
> bitwise-binary
> expressions.
> Additional it adds primitive checks for bitwise
Hi,
I corrected a minor error (translatedebug_mode get installed instead
of translatequickly_mode).
Romain Geissler
Changelog
Description: Binary data
translatequickly_mode.diff
Description: Binary data
On Tue, Jul 19, 2011 at 1:27 PM, Kai Tietz wrote:
> Hello,
>
> So this is the updated patch for boolifying of comparisons. There are
> two different kind of regression caused by this. One is fixed by the
> VRP patch I've sent and it waits for review. The other one is about
> vectorization in gcc
On Tue, Jul 19, 2011 at 1:25 PM, Richard Sandiford
wrote:
>> On Sat, Jul 16, 2011 at 6:47 PM, H.J. Lu wrote:
> Yes, this is an example from PR I am referring to. Did you try to
> define LEGITIMIZE_RELOAD_ADDRESS? It is supposed to fix this.
>
They make things even more comp
On Thu, Jul 14, 2011 at 5:00 PM, Ilya Enkovich wrote:
>> 2011/7/14 Richard Guenther :
>>>
>>> But then how comes the option to override it is useful? It isn't dependent
>>> on the particular case. At least the option should be a --param.
>>>
>>> Richard.
>>>
>>
>> Option is still useful if you w
Hello,
So this is the updated patch for boolifying of comparisons. There are
two different kind of regression caused by this. One is fixed by the
VRP patch I've sent and it waits for review. The other one is about
vectorization in gcc.dg/vect/vect-cond3.c
testcase. This is caused by vectorizati
Uros Bizjak writes:
> On Sat, Jul 16, 2011 at 6:47 PM, H.J. Lu wrote:
Yes, this is an example from PR I am referring to. Did you try to
define LEGITIMIZE_RELOAD_ADDRESS? It is supposed to fix this.
>>>
>>> They make things even more complex. ix86_simplify_base_index_disp
>>> is cal
_comparison): Handle
BIT_NOT_EXPR and BIT_XOR_EXPR instead of TRUTH_NOT_EXPR.
* gcc.dg/tree-ssa/bool-10.c: Adjust expected pattern.
* gcc.dg/tree-ssa/bool-11.c: Likewise.
* gcc.dg/torture/20110719-1.c: New testcase.
Index: gcc/gimplify.c
==
Steve,
> I tried this (here is the libgcc/config.host entry for ia64*-*-linux*):
>
> ia64*-*-linux*)
> extra_parts="crtbegin.o crtend.o crtbeginS.o crtendS.o crtfastmath.o"
> tmake_file="ia64/t-ia64 t-softfp ia64/t-fprules-softfp
> ia64/t-softfp-compat ia64/t-glibc ia64/t-eh-ia64
Richard Henderson wrote:
> On 07/18/2011 12:15 PM, Georg-Johann Lay wrote:
>> Moreover, I wonder why target-independent code does not already
>> catch the situation because the pattern to be generated is just
>> an ordinary umulqihi3 widening multiplication.
>
> Yes, it is sad that the backends ha
2011/7/19 Jiangning Liu :
>
> I see a lot of feedbacks on other posts, but mine is still with ZERO
> response in the past 3 weeks, so I'm wondering if I made any mistake in my
> process? Who can help me?
It would be worth CC'ing the other relevant target maintainers as well
to get some feedback si
This patch fixes PR18908, both the redundant bitfield truncation and
the allegedly missing tree simplification of Bool ^ 1 to ~Bool. The
former is because we for no reason truncate the result of bitwise
binary expressions again (not needed, operands are already truncated).
The latter is because i
Hello...
Can *anybody* give me comments on this bug fix? Our customers have been
complaining about this bug with long history.
I see a lot of feedbacks on other posts, but mine is still with ZERO
response in the past 3 weeks, so I'm wondering if I made any mistake in my
process? Who can help me?
Jason Merrill writes:
> On 07/16/2011 10:37 AM, Dodji Seketeli wrote:
>> + /* This array of location is actually an array of pairs of
>> + locations. The elements inside it thus look like:
>> +
>> + x0,y0, x1,y1, x2,y2, , xn,yn.
>
> Pairs of locations still seems limited, give
On Tue, Jul 19, 2011 at 10:46 AM, Richard Guenther
wrote:
TARGET_MEM_REF only works on ptr_mode. This patch allows 32bit
address
in x32 mode. OK for trunk?
>>>
>>> Do you perhaps have a testcase to help in analyzing the problem?
>>>
>>
>> See:
>>
On Tue, Jul 19, 2011 at 10:24 AM, Jakub Jelinek wrote:
> On Mon, Jul 18, 2011 at 11:58:38PM +0200, Jakub Jelinek wrote:
>> Especially the FEs and gimplification are highly recursive on more complex
>> (especially badly generated) testcases, the following patch attempts to
>> increase stack size to
On Tue, Jul 19, 2011 at 8:44 AM, Ira Rosen wrote:
> Hi,
>
> This patch tries to reduce over-promotion of vector operations that
> could be done with narrower elements, e.g., for
>
> char a;
> int b, c;
> short d;
>
> b = (int) a;
> c = b << 2;
> d = (short) c;
>
> we currently produce six vec_unpa
On Tue, Jul 19, 2011 at 8:25 AM, Ira Rosen wrote:
> Hi,
>
> The vectorizer performs the following alias checks for data-refs with
> unknown dependence:
>
> ((store_ptr_0 + store_segment_length_0) <= load_ptr_0)
> || (load_ptr_0 + load_segment_length_0) <= store_ptr_0))
>
> where segment_length is
On Mon, Jul 18, 2011 at 10:42 PM, H.J. Lu wrote:
> On Mon, Jul 18, 2011 at 1:33 PM, Uros Bizjak wrote:
>> On Mon, Jul 18, 2011 at 10:25 PM, H.J. Lu wrote:
>>
>>> TARGET_MEM_REF only works on ptr_mode. This patch allows 32bit address
>>> in x32 mode. OK for trunk?
>>
>> Do you
On Mon, Jul 18, 2011 at 7:49 PM, Jakub Jelinek wrote:
> Hi!
>
> As the testcase below shows, fold_nonarray_ctor_reference doesn't have a
> correct check whether a field might overlap with the given offset, size
> access (in this case a BIT_FIELD_REF). The bitfield ref wants to read
> 8 bits start
1 - 100 of 105 matches
Mail list logo
