> Hi,
>
> PR 49495 is actually a bug in the verifier that does not look through
> aliases at one point. Fixed wit the patch below (created a special
> function, otherwise I just wasn't able to fit the 80 column limit).
> Bootstrapped and tested on x86_64-linux. OK for trunk?
>
> Thanks,
>
> Ma
On 01/07/11 20:56, Janis Johnson wrote:
> On 07/01/2011 02:02 AM, Richard Earnshaw wrote:
>> On 24/06/11 14:18, Ramana Radhakrishnan wrote:
>>> On 24/06/11 01:40, Janis Johnson wrote:
Test gcc.target/arm/pr42093.c, added by Ramana, requires support for
arm_thumb2 but fails for those targe
> Not clear why this never showed up on the 4.6 branch, but this now prevents a
> parallel LTO bootstrap with Ada enabled from completing on the mainline.
>
> Parallel LTO-bootstrapped, applied on the mainline and 4.6 branch.
>
>
> 2011-07-01 Eric Botcazou
>
> * gcc-interface/Make-lan
On Mon, Jul 4, 2011 at 7:13 AM, H.J. Lu wrote:
In one SSE2 int->float split, when TARGET_USE_VECTOR_CONVERTS is true,
TARGET_INTER_UNIT_MOVES is false and GENERAL_REG_P (op1) is true. we
will get gcc_unreachable. This patch removes TARGET_INTER_UNIT_MOVES
check. OK for trunk
Georg-Johann Lay wrote:
> Some runtime and checks for error/warning for C/C++.
Note that some tests fail because of pending
http://gcc.gnu.org/ml/gcc-patches/2011-06/msg02318.html
Johann
testsuite/
* gcc.target/avr/avr.exp: Run over cpp files, too.
* gcc.target/avr/torture/avr-t
Georg-Johann Lay wrote:
http://gcc.gnu.org/ml/gcc-patches/2011-06/msg02318.html
> avr_insert_attributes uses TREE_READONLY on get readonlyness of node.
>
> That does not work for C++ arrays: it gives false error
> "variable must be const in order to be put into read-only section by
> means of '_
> The changle is obviously correct, but I wonder how the bootstrap dies w/o
> '+'. It should IMO just prevent the parallelizm and take longer.
Same cryptic error as PR driver/46750.
--
Eric Botcazou
On Fri, 1 Jul 2011, Rainer Orth wrote:
> I don't need approval for the patch, but would be grateful for
> improvements to wording.
I find it quite clear, thanks. If you'd like, "is not" instead of
"isn't" is the only suggestion I found.
Gerald
It happens that OpenBSD suffers from a bogus fixinclude that changes
its perfectly valid NULL define from (void *)0 to 0. The fix itself
appears to be very old and is completely bogus - it replaces
(void *)0 with 0 under the assumption the former is invalid for C++ -
which is true - but 0 is ina
2011/7/4 Georg-Johann Lay :
> Georg-Johann Lay wrote:
>> Some runtime and checks for error/warning for C/C++.
>
> Note that some tests fail because of pending
>
> http://gcc.gnu.org/ml/gcc-patches/2011-06/msg02318.html
>
> Johann
>
> testsuite/
> * gcc.target/avr/avr.exp: Run over cpp files,
Handling of negative steps broke one of the many asserts in
the vectorizer. The following patch drops one that I can't
make sense of. I think all asserts need comments - especially
this one would, as I can't see why using vf is correct to
test against and not nelements (and why <= vf and not < v
Julian Brown wrote:
> The most awkward change in the patch is to generic code (expmed.c,
> {store,extract}_bit_field_1): in big-endian mode, the existing behaviour
> (when inserting/extracting a bitfield to a memory location) is
> definitely bogus: "unit" is set to BITS_PER_UNIT for memory locatio
The current implementation of __builtin_avr_fmul/fmuls/fmulsu has a
gap if no hardware multiplier is available.
This patch closes that gap by providing libgcc implementations named
__fmul, __fmuls resp. __fmulsu.
The implementations yield the same result as respective FMUL*
instructions and have
This fixes an oversight in split_bbs_on_noreturn_calls.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied everywhere.
Richard.
2011-07-04 Richard Guenther
PR tree-optimization/49615
* tree-cfgcleanup.c (split_bbs_on_noreturn_calls): Fix
basic-block index c
2011/7/4 Georg-Johann Lay :
> Georg-Johann Lay wrote:
>
> http://gcc.gnu.org/ml/gcc-patches/2011-06/msg02318.html
>
>> avr_insert_attributes uses TREE_READONLY on get readonlyness of node.
>>
>> That does not work for C++ arrays: it gives false error
>> "variable must be const in order to be put in
2011/7/4 Georg-Johann Lay :
> The current implementation of __builtin_avr_fmul/fmuls/fmulsu has a
> gap if no hardware multiplier is available.
>
> This patch closes that gap by providing libgcc implementations named
> __fmul, __fmuls resp. __fmulsu.
>
> The implementations yield the same result as
Richard Guenther wrote on 04/07/2011 02:38:50 PM:
> Handling of negative steps broke one of the many asserts in
> the vectorizer. The following patch drops one that I can't
> make sense of. I think all asserts need comments - especially
> this one would, as I can't see why using vf is correct
On Mon, 4 Jul 2011, Ira Rosen wrote:
>
>
> Richard Guenther wrote on 04/07/2011 02:38:50 PM:
>
> > Handling of negative steps broke one of the many asserts in
> > the vectorizer. The following patch drops one that I can't
> > make sense of. I think all asserts need comments - especially
> >
Hi Richard,
On Mon, Jul 4, 2011 at 4:04 AM, Richard Guenther wrote:
>
> It happens that OpenBSD suffers from a bogus fixinclude that changes
> its perfectly valid NULL define from (void *)0 to 0. The fix itself
> appears to be very old and is completely bogus - it replaces
> (void *)0 with 0 und
On Mon, 4 Jul 2011, Bruce Korb wrote:
> Hi Richard,
>
> On Mon, Jul 4, 2011 at 4:04 AM, Richard Guenther wrote:
> >
> > It happens that OpenBSD suffers from a bogus fixinclude that changes
> > its perfectly valid NULL define from (void *)0 to 0. The fix itself
> > appears to be very old and is
On Fri, Jul 1, 2011 at 5:23 PM, Kai Tietz wrote:
> So updated patch (bootstrapped and tested for all standard languages
> plus Ada and Obj-C++) on x86_64-pc-linux-gnu host.
>
> Index: gcc-head/gcc/tree-ssa-forwprop.c
> ===
> --- gcc-h
Frank,
this patch has remained unreviewed for a week. Could you please have a
look?
Thanks.
Rainer
Rainer Orth writes:
> This is the first of two patches to get mudflap fully working on
> Solaris 11, both with Sun ld and GNU ld.
>
> It addresses a couple of testsuite failures:
>
> *
On Wed, Jun 29, 2011 at 4:19 AM, Richard Guenther wrote:
>
> The following patch makes us handle invariant loads during vectorization.
> Dependence analysis currently isn't clever enough to disambiguate them
> thus we insert versioning-for-alias checks. For the testcase hoisting
> the load is sti
On Mon, Jul 4, 2011 at 3:18 AM, Uros Bizjak wrote:
> On Mon, Jul 4, 2011 at 7:13 AM, H.J. Lu wrote:
>
> In one SSE2 int->float split, when TARGET_USE_VECTOR_CONVERTS is true,
> TARGET_INTER_UNIT_MOVES is false and GENERAL_REG_P (op1) is true. we
> will get gcc_unreachable. This patch
On Thu, Jun 30, 2011 at 4:39 PM, William J. Schmidt
wrote:
> This is the first of three patches related to lowering addressing
> expressions to MEM_REFs and TARGET_MEM_REFs in late gimple. This patch
> contains the new pass together with supporting changes in existing
> modules. The second patch
On 01/07/11 13:25, Richard Guenther wrote:
Well - some operations work the same on both signedness if you
just care about the twos-complement result. This includes
multiplication (but not for example division). For this special
case I suggest to not bother trying to invent a generic predicate
b
On 28/06/11 15:14, Andrew Stubbs wrote:
On 28/06/11 13:33, Andrew Stubbs wrote:
On 23/06/11 15:41, Andrew Stubbs wrote:
If one or both of the inputs to a widening multiply are of unsigned type
then the compiler will attempt to use usmul_widen_optab or
umul_widen_optab, respectively.
That works
On 28/06/11 16:08, Andrew Stubbs wrote:
On 23/06/11 15:41, Andrew Stubbs wrote:
This patch removes the restriction that the inputs to a widening
multiply must be of the same mode.
It does this by extending the smaller of the two inputs to match the
larger; therefore, it remains the case that su
On 28/06/11 16:30, Andrew Stubbs wrote:
On 23/06/11 15:42, Andrew Stubbs wrote:
This patch fixes the case where widening multiply-and-accumulate were
not recognised because the multiplication itself is not actually
widening.
This can happen when you have "DI + SI * SI" - the multiplication will
On Mon, Jul 4, 2011 at 8:51 AM, Richard Guenther wrote:
> On Mon, 4 Jul 2011, Bruce Korb wrote:
>
>> Hi Richard,
>>
>> On Mon, Jul 4, 2011 at 4:04 AM, Richard Guenther wrote:
>> >
>> > It happens that OpenBSD suffers from a bogus fixinclude that changes
>> > its perfectly valid NULL define from (
On 07/01/2011 10:27 AM, Bernd Schmidt wrote:
> * simplify-rtx.c (simplify_const_binary_operation): Use the
> shift_truncation_mask hook instead of performing modulo by
> width. Compare against mode precision, not bitsize.
> * combine.c (combine_simplify_rtx, simplify_shift_
Hi,
On Mon, 4 Jul 2011, Richard Guenther wrote:
> I still do not like the implementation of yet another CSE machinery
> given that we already have two.
>From reading it it really seems to be a normal block-local CSE, without
anything fancy. Hence, moving the pass just a little earlier (before
On Fri, Jul 1, 2011 at 21:35, Gabriel Charette wrote:
> As variables are discovered (while parsing the header) they are added to the
> varpool and their RTL is built.
>
> We do not stream, nor the varpool, nor the RTL (and I don't think we want to
> + that wouldn't
> work with multiple pph).
Ri
Hi!
If -L doesn't have an argument, find_spec_file ICEs on it, as
the argument is NULL. As suggested by Joseph, this disregards in
this loop all options which don't have the required argument.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for
trunk/4.6?
2011-07-04 Jakub Jelinek
Hi!
In dead_debug_* we don't immediately rescan insns, because that kills all
the df links we need to use, only queue their rescanning.
There are two kinds of changes we do on the debug insns without immediate
rescanning:
1) reset the debug insn
2) replace a reg use with DEBUG_EXPR of the same mo
Hi!
On the attached testcase simplify-rtx.c was endlessly oscillating when
trying to simplify a complex debug insn location. The first
hunk changes oscillation between 3 possible expressions into oscillation
between 2 possible expressions, by preferring to change second argument
instead of first,
On Jun 30, 2011, at 10:38 AM, Georg-Johann Lay wrote:
> Is
> ./testsuite/gcc.target/avr/
> realm of avr port maintainers?
I'm fine with the avr people reviewing and approving all they think is ready
for the tree. If they go out into the weeds, we can reign them in, I'm sure
that would never h
On Jul 4, 2011, at 4:07 AM, Denis Chertykov wrote:
>>
>> testsuite/
>>* gcc.target/avr/torture/progmem-1.cpp: New file.
>
> I don't know who must approve tests.
> If me then Approved
You! If there are ugly details more related to the test suite framework, feel
free to kick it up.
"Joseph S. Myers" writes:
> On Mon, 20 Jun 2011, Rainer Orth wrote:
>
>> * Move all remaining unwinder-only macros to libgcc: UNW_IVMS_MODE,
>> MD_UNW_COMPATIBLE_PERSONALITY_P, MD_FROB_UPDATE_CONTEXT.
>
> I don't see any sign of macros being poisoned in system.h. For macros
> used in target-i
Hi!
Before http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=168951
set_mem_attributes_minus_bitpos would set MEM_NOTRAP_P for decls
based on whether they are DECL_WEAK or not, but now it is set only
from !tree_could_trap_p.
These patches adjust tree_could_trap_p to say that references
to weak var
My last run_acats patch broke platforms where CONFIG_SHELL doesn't
support type -p (like Solaris < 11 /bin/ksh): when using awk to extract
the last output field, the exit code is from the last command in the
pipe (always 0), not type, so the which function returns an empty
string.
This patch fixes
Hi!
The following testcase ICEs, because simplify_gen_binary (IOR, HImode, ...)
simplifies into (subreg:HI (reg:SI ...) 0), but was still passing
mode (HImode) as second argument to recursive combine_simplify_rtx call.
The second argument is op0_mode, so is supposed to be the real
mode which shoul
Latest results for 4.6.x
-tgc
Testresults for 4.6.1:
hppa2.0w-hp-hpux11.00
hppa2.0w-hp-hpux11.11
hppa64-hp-hpux11.11
i386-pc-solaris2.10
i686-pc-linux-gnu (2)
sparc-sun-solaris2.8
x86_64-unknown-linux-gnu
Testresults for 4.6.0
sparc-sun-solaris2.10
x86_64-unknown-linux-gnu
Inde
> 2011-07-04 Jakub Jelinek
>
> PR rtl-optimization/49472
> * simplify-rtx.c (simplify_unary_operation_1) : When
> negating MULT, negate the second operand instead of first.
> (simplify_binary_operation_1) : If one operand is
> a NEG and the other is MULT, don't atte
> This patch fixes this by decoupling type/type -p from extracting the
> last field.
>
> Bootstrapped on i386-pc-solaris2.10 and i386-pc-solaris2.11.
>
> Ok for mainline, 4.6 and 4.5 branches (where the offending patch has
> been installed)?
OK, but if this new patch introduces new regressions,
Arnaud Charlet writes:
>> This patch fixes this by decoupling type/type -p from extracting the
>> last field.
>>
>> Bootstrapped on i386-pc-solaris2.10 and i386-pc-solaris2.11.
>>
>> Ok for mainline, 4.6 and 4.5 branches (where the offending patch has
>> been installed)?
>
> OK, but if this new
Ok, reworked version. The folding of X op X and !X op !X seems indeed
not being necessary. So function simplifies much.
Bootstrapped and regression tested for all standard languages (plus
Ada and Obj-C++). Ok for apply?
Regards,
Kai
Index: gcc-head/gcc/tree-ssa-forwprop.c
==
On Jul 4, 2011, at 4:04 AM, Richard Guenther wrote:
> It happens that OpenBSD suffers from a bogus fixinclude that changes
> its perfectly valid NULL define from (void *)0 to 0. The fix itself
> appears to be very old and is completely bogus
I don't agree with the completely bogus part. Why not
Dear Jakub,
Yes! OK for trunk and, if you will, for 4.6.
Thanks
Paul
On Mon, Jul 4, 2011 at 7:22 PM, Jakub Jelinek wrote:
> Hi!
>
> If -L doesn't have an argument, find_spec_file ICEs on it, as
> the argument is NULL. As suggested by Joseph, this disregards in
> this loop all options which d
This test was exposing multiple failures. To isolate them better, I split
it in two. I simplified c1eabi1.{cc,h} to test a single header file.
This fails in assembly comparison because we do not emit static
initializers properly out of the pph image.
The original test fails because c2eabi1.h in
Jason Merrill writes:
| On 06/14/2011 01:38 PM, Jason Merrill wrote:
| > While I was at it, I've also tweaked the compiler to also print the
| > typedef-stripped version of a type when appropriate, which should help
| > with understanding template error messages.
|
| I noticed that this was some
"H.J. Lu" writes:
> RTL-based forward propagation pass shouldn't propagate hard register.
That's seems a bit draconian. Many fixed hard registers ought to be OK.
E.g. there doesn't seem to be anything wrong with propagating uses of
the stack or frame pointers, subject to the usual availability c
Richard Henderson wrote:
On 07/03/2011 08:06 AM, Thomas Klein wrote:
> +/*
> + * Write prolouge part of stack check into asm file.
> + * For Thumb this may look like this:
> + * push {rsym,ramn}
> + * ldr rsym, .LSPCHK0
> + * ldr rsym, [rsym]
> + * ldr ramn, .LSPCHK0 + 4
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
> For 4.6, I think safer would be just the first one liner change to pass
> VOIDmode to combine_simplify_rtx. Is that ok for 4.6?
>
> 2011-07-04 Jakub Jelinek
>
> PR rtl-optimization/49619
> * combine.c (combine_
This patch adds an assertion to x1ten-hellos to make sure that the
loop counter is properly initialized and ends in 10. It also calls
exit instead of return.
In c1eabi1.h I forgot to surround the system function signatures in
extern "C" {}.
Tested on x86_64. Committed.
Diego.
* g++.
On Mon, Jul 4, 2011 at 12:57 PM, Richard Sandiford
wrote:
> "H.J. Lu" writes:
>> RTL-based forward propagation pass shouldn't propagate hard register.
>
> That's seems a bit draconian. Many fixed hard registers ought to be OK.
> E.g. there doesn't seem to be anything wrong with propagating uses
The test c1meteor-contest.cc had similar issues as c1eabi1.cc. The
inclusion of system headers that have been PPH'd confuse the compiler.
I split the test so we have one version without additional includes
and another with the standard includes.
The version without additional includes works fine.
On Mon, Jul 4, 2011 at 1:52 PM, H.J. Lu wrote:
> On Mon, Jul 4, 2011 at 12:57 PM, Richard Sandiford
> wrote:
>> "H.J. Lu" writes:
>>> RTL-based forward propagation pass shouldn't propagate hard register.
>>
>> That's seems a bit draconian. Many fixed hard registers ought to be OK.
>> E.g. there
I thought of a different way to do it that would stay encapsulated in
type_as_string, so this is the version I'm going to check in.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 689a3e58f4eebbcdafec81f06e8af699045fff3a
Author: Jason Merrill
Date: Fri Jul 1 00:16:46 2011 -0400
*
Jason Merrill writes:
| I thought of a different way to do it that would stay encapsulated in
| type_as_string, so this is the version I'm going to check in.
OK, thanks.
-- Gaby
Before this patch, GCC described the candidate as
template decltype (((TypeC*)this)->TypeC::b.template
typename TypeA::type TypeB::fn [with int U = U, int N = 10, typename
TypeA::type = TypeA::type]()) TypeC::fn()
after the patch, it's
template decltype (((TypeC*)this)->TypeC::b.fn()) TypeC:
On 06/29/2011 05:15 PM, Jason Merrill wrote:
This patch adds support for use of 'this' (implicitly or explicitly) in
the trailing-return-type of a member function.
The above patch wasn't enough, though. The following patch fixes some
issues that arose with real uses, including mangling.
Tes
Jason Merrill writes:
| Before this patch, GCC described the candidate as
|
| template decltype (((TypeC*)this)->TypeC::b.template
| typename TypeA::type TypeB::fn [with int U = U, int N = 10,
| typename TypeA::type = TypeA::type]()) TypeC::fn()
ouch!
| after the patch, it's
|
| template decl
On 1 July 2011 20:38, Joseph S. Myers wrote:
Hi Joseph,
Thanks for your comments.
> On Fri, 1 Jul 2011, Dr. David Alan Gilbert wrote:
>
>> +/* For write */
>> +#include
>> +/* For abort */
>> +#include
>
> Please don't include system headers in libgcc without appropriate
> inhibit_libc check
On Mon, Jul 04, 2011 at 01:57:34PM -0700, H.J. Lu wrote:
> forward_propagate_subreg issue was introduced by
>
> http://gcc.gnu.org/ml/gcc-patches/2009-08/msg01203.html
>
> Before that, fwprop never tries to work on hard registers.
I question this claim. It seems to me that fwprop did look at
p
On Mon, Jul 4, 2011 at 4:54 PM, Alan Modra wrote:
> On Mon, Jul 04, 2011 at 01:57:34PM -0700, H.J. Lu wrote:
>> forward_propagate_subreg issue was introduced by
>>
>> http://gcc.gnu.org/ml/gcc-patches/2009-08/msg01203.html
>>
>> Before that, fwprop never tries to work on hard registers.
>
> I que
Hi,
GCJ is available on RTEMS/pc386. Here is the libjava testsuite result
on RTEMS/pc386:
=== libjava Summary ===
# of expected passes2249
# of unexpected failures94
# of untested testcases 66
As the testsuite result is good enough, I think it's time to get t
PING...
I just merged with the latest code base and generated new patch as attached.
Thanks,
-Jiangning
> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Jiangning Liu
> Sent: 2011年6月28日 4:38 PM
> To: gcc-patches@gcc.gnu.org
On Mon, Jul 04, 2011 at 05:09:28PM -0700, H.J. Lu wrote:
> On Mon, Jul 4, 2011 at 4:54 PM, Alan Modra wrote:
> > I didn't set out to do anything special with hard regs one way or the
> > other, just extended what was already done for paradoxical subregs to
> > sign and zero extended subregs.
>
>
Richard Guenther wrote on 04/07/2011 03:30:59 PM:
> >
> > Richard Guenther wrote on 04/07/2011 02:38:50 PM:
> >
> > > Handling of negative steps broke one of the many asserts in
> > > the vectorizer. The following patch drops one that I can't
> > > make sense of. I think all asserts need comm
70 matches
Mail list logo
