On 07/21/2011 08:13 AM, Steve Kargl wrote:
There is generate_warning(). If one can disable this extension vai
-std=f95, then one should be able to emit a warning
But one does not have to. While for the compiler, it might be okay and
often is useful to emit warnings, having warnings printed fro
On Wed, 20 Jul 2011 14:41:16 -0700
Ian Lance Taylor wrote:
> Mike Stump writes:
>
> >> Presumably the fix will be to use -frandom-seed.
> >
> > But, the random seem was to ensure that things that should not collide,
> > don't. If you use 0, then things that should not collide, eventually will
Hi!
The 4.4 expr.c is significantly different from 4.5 that the PR48973
backport wasn't trivial, and apparently I've missed another place
- on the 4.4 branch the new pr48973-{1,2}.c tests fail on s390{,x}-linux.
The following patch fixes it, ok for 4.4 branch?
2011-07-21 Jakub Jelinek
Hi,
I added a few includes i need to define some new primitives.
Basile, i included two "c-family/*.h" files, but be aware that currently
GCC does not install this headers in the c-family directory but in the
directly in the plugin/include root directory with all other headers. I posted
a patch s
Richard Henderson wrote:
> On 07/20/2011 07:16 AM, Georg-Johann Lay wrote:
>> case CONST_INT:
>> case CONST_DOUBLE:
>> +case SYMBOL_REF:
>>/* Immediate constants are as cheap as registers. */
>>*total = 0;
>>return true;
>> @@ -5348,7 +5349,6 @@ avr_rtx_costs
On Wed, 20 Jul 2011, Ulrich Weigand wrote:
> Richard Guenther wrote:
> > On Tue, Jul 19, 2011 at 8:20 PM, Ulrich Weigand wrote:
> > > The problem is that in this expression
> > > disappear = VIEW_CONVERT_EXPR(x_8);
> > > the rhs is considered unaligned and blocks the SRA transformation.
> > >
>
On Wed, 20 Jul 2011, Jason Merrill wrote:
> The first patch adjusts the C++ front end's current support for the old GNU
> designated initializer syntax to support the C99 syntax as well.
>
> The second patch adjusts recog.h/genoutput.c to use a new macro
> HAVE_DESIGNATED_UNION_INITIALIZERS inste
Hello,
this patch binds scanning direction for statements within BB in function
substitute_and_fold with the do_dce flag. For DCE it is profitable to
walk statements
from last to first element, but in non-DCE passes - like VRP - it is
more profitable
to walk opposite direction.
ChangeLog gcc
20
This patch fixes the debug output of rtx_costs as enabled with -mdeb.
rtx_costs are typically computed for SET_SRC of patters, not of pattern/insn
as a whole resp for SETs.
This patch yields more accurate dumps of rtx_costs in asm file.
Ok?
Johann
* config/avr/avr.c (final_prescan_insn
On Thu, 21 Jul 2011 10:03:22 +0200
Romain Geissler wrote:
> Hi,
>
> I added a few includes i need to define some new primitives.
>
> Basile, i included two "c-family/*.h" files, but be aware that currently
> GCC does not install this headers in the c-family directory but in the
> directly in th
On Thu, Jul 21, 2011 at 5:57 AM, DJ Delorie wrote:
>
> In this PR, a cast to a volatile type is lost during forwprop1,
> resulting in the wrong access semantics being used for a memory-mapped
> peripheral register. Checking for loss of volatile in this patch
> solves the problem, but I don't know
On Thu, Jul 21, 2011 at 9:39 AM, Jakub Jelinek wrote:
> Hi!
>
> The 4.4 expr.c is significantly different from 4.5 that the PR48973
> backport wasn't trivial, and apparently I've missed another place
> - on the 4.4 branch the new pr48973-{1,2}.c tests fail on s390{,x}-linux.
>
> The following patc
On Thu, Jul 21, 2011 at 10:40 AM, Kai Tietz wrote:
> Hello,
>
> this patch binds scanning direction for statements within BB in function
> substitute_and_fold with the do_dce flag. For DCE it is profitable to
> walk statements
> from last to first element, but in non-DCE passes - like VRP - it is
2011/7/21 Basile Starynkevitch :
> And I want badly MELT to be compilable as a plugin to an umodified
> gcc-4.6-plugin-dev
> package on Debian.
>
> I don't understand if it is an issue related to building GCC & its plugin
> with C++, or
> it is an issue with 4.7 ?
>
> I am tempted to put in melt-
Hi,
On Thu, Jul 21, 2011 at 10:34:35AM +0200, Richard Guenther wrote:
> On Wed, 20 Jul 2011, Ulrich Weigand wrote:
>
> > Richard Guenther wrote:
> > > On Tue, Jul 19, 2011 at 8:20 PM, Ulrich Weigand
> > > wrote:
> > > > The problem is that in this expression
> > > > disappear = VIEW_CONVERT_E
Bernd Schmidt writes:
> On 07/07/11 16:34, Richard Sandiford wrote:
>> Is JUMP_LABEL ever null after this change? (In fully-complete rtl
>> sequences, I mean.) It looked like some of the null checks in the
>> patch might not be necessary any more.
>
> It turns out that computed jumps can have a
On Tue, Jul 19, 2011 at 6:47 AM, H.J. Lu wrote:
So, since copy_to_reg & co. expects x in Pmode or VOIDmode constant
(due to force_reg that won't do mode conversion), we have to implement
them with a mode conversion...
> This patch adds the missing Pmode check and conversion. OK for trunk?
> 20
Hello all,
After some delay due to other work, I'd like to submit an updated
version of my patch. This patch allows the ALLOCATE statement to
correctly support the stat= and errmsg= attributes.
The patch (allocate.diff) was produced by Mercurial but it has a diff
style that should be very si
Hello,
Updated and again merged variant of this patch.
We have now just two vrp related regressions by this patch,
and it is addressed already by a posted one.
2011-07-21 Kai Tietz
* fold-const.c (fold_unary_loc): Preserve indirect
comparison cast to none-boolean type.
On Tue, Jul 19, 2011 at 04:26:08PM -0700, Richard Henderson wrote:
> 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_
Dear Tobias,
>
> Build and regtested on x86-64-linux.
> OK for the trunk?
OK for trunk. The machinery is well used for other purposes and I do
not see any problem with your implementation.
We are making increasing use of scan-tree-dump-times in the tests. I
wonder if this is well advised? I ha
define_bypass requires two lists of reservation names. On targets with
fairly regular scheduling descriptions, it'd be nice to be able to use
filename-style globs to match several reservation names at once.
libiberty already provides an appropriate routine: fnmatch. It also has
a fallback defini
This is another place where we fail to properly keep single-use
chains by leaving around dead code. This confuses propagation
of comparisons which is restricted for non-single-uses.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.
Richard.
2011-07-21 Richard Guenther
On Thu, Jul 21, 2011 at 1:12 PM, Kai Tietz wrote:
> Hello,
>
> Updated and again merged variant of this patch.
> We have now just two vrp related regressions by this patch,
> and it is addressed already by a posted one.
>
> 2011-07-21 Kai Tietz
>
> * fold-const.c (fold_unary_loc): Preser
On Wed, 2011-07-20 at 20:00 +0200, Jakub Jelinek wrote:
> On Wed, Jul 20, 2011 at 10:16:10AM -0700, Michael Eager wrote:
> > but wait until the DWARF committee has had an
> > opportunity to review the proposal and incorporate it into a future version
> > of DWARF. Should you discover a need for an
Arnaud,
>> * Similarly to IRIX 6, there was a mismatch in ada/init.c for the type
>> of the signal handler installed with sigaction. g++ also doesn't like
>> arithmetic on void * ;-)
>
> I'm a bit puzzled as to why the C compiler isn't complaining, and what
> error message the C++ compiler is
Dear Paul,
On 07/21/2011 01:25 PM, Paul Richard Thomas wrote:
We are making increasing use of scan-tree-dump-times in the tests. I
wonder if this is well advised?
I think it is the only way to make sure that things work as advised -
the other possibility is to look at the assembler output: s
2011/7/21 Richard Guenther :
> With these two changes the patch is ok to commit (it will also
> regress gcc.target/i386/andor-2.c but that is an exact duplicate
> of the already regressed gcc.dg/tree-ssa/vrp47.c).
>
> Thanks,
> Richard.
>
Ok, retested with your comments and applied at rev 176563.
I forgot to include an updated ChangeLog (attached).
--
I'm not overweight, I'm undertall.
2011-07-21 Daniel Carrera
* trans.c (gfc_allocate_with_status): Split into two functions
gfc_allocate_using_malloc ad gfc_allocate_usig_lib.
(gfc_allocate_using_malloc): The stat
On 20 July 2011 21:35, Ulrich Weigand wrote:
> Ira Rosen wrote:
>
>> PR tree-optimization/49771
>> * gcc.dg/vect/pr49771.c: New test.
>
> This test fails (with wrong code) on spu-elf ...
>
>> +int
>> +foo (void)
>> +{
>> + int j;
>> + int i;
>> + for (i = 0; i < 1000; i++)
>> + for (j
As described in the PR, the use of LANGUAGE_C in CLooG breaks C++
bootstrap on IRIX 6.5. Both MIPS and Alpha C compilers predefine
LANGUAGE_C themselves, which clashes with the CLooG macro in
. In a bootstrap with C++, LANGUAGE_C of course isn't
defined, so the symbol is missing.
As a hack, I ha
> ... which explains why the C compiler accepts the code as is.
Thanks for the details. Patch is OK then.
Arno
From: Ramana Radhakrishnan
Hi,
While investigating cases where we generate excessive moves
between VFP and integer registers I came across a situation
where ivopts wasn't considering the mode in which auto-increment
was allowed in this situation. Changing legitimate_address_p
wasn't enough to ca
Ian,
>> I think something like this should work:
>>
>> AS_IF([test "$ENABLE_BUILD_WITH_CXX" = "yes"],
>> [AC_LANG_PUSH([C++])
>>AM_ICONV
>>AC_LANG_POP([C++])],
>> [AM_ICONV])
>>
>> Rationale for using AS_IF rather than plain 'if' is that any macros
>> required by AM_ICONV will get pull
This patch is part bug fix, part better optimization.
Firstly, my initial patch series introduced a bug that caused an
internal compiler error when the input to a multiply was a constant.
This was caused by the gimple verification rejecting such things. I'm
not totally clear how this ever work
On Tru64 UNIX, I ran into two problems with C++ bootstrap:
* gcc.c doesn't compile:
In file included from /vol/gcc/src/hg/trunk/local/gcc/../include/xregex.h:26:0,
from /vol/gcc/src/hg/trunk/local/gcc/gcc.c:38:
/vol/gcc/src/hg/trunk/local/gcc/../include/xregex2.h:402:13: error: c
On Wed, Jul 20, 2011 at 4:25 PM, Ian Lance Taylor wrote:
> Presumably the fix will be to use -frandom-seed. Does this patch fix
> the problem? (The only real change is to fragment.am, the other changes
> are all generated by automake).
This patch gets the build past the compiler and runtime, a
Hello!
Just a small optimization, we can reject non-register RTXes and wrong
subregs from index early. No functional change - these RTXes were
rejected in ix86_legitimate_address_p anyway.
2011-07-21 Uros Bizjak
* config/i386/i386.c (ix86_decompose_address): Reject all but
re
Hello,
this patch changes TRUTH-expression patterns into BIT-expression ones
and adjusts code-flow
for this.
ChangeLog gcc
2011-07-21 Kai Tietz
* tree-vrp.c (extract_range_from_binary_expr): Convert
truth expression to bimary expression,
(extract_range_from_unary_expr
This patch fixes PR49770 by introducing an indicator whether it's
worth to lose some TBAA in favor of using existing valueization.
Simple for now - always make sure use the valueized variant if
that is in any way different from the unvalueized one.
Bootstrapped and tested on x86_64-unknown-linux-
On 18/07/11 15:46, Richard Guenther wrote:
Will signedness be always the same? Usually the canonical check to
use would be !useless_type_conversion_p (type, TREE_TYPE (add_rhs)).
The signedness ought to be unimportant - any extend will be based on the
source type, and the signedness should no
On Wed, Jul 20, 2011 at 3:46 PM, H.J. Lu wrote:
> On Wed, Jul 20, 2011 at 2:49 PM, Uros Bizjak wrote:
>> On Wed, Jul 20, 2011 at 9:46 PM, Uros Bizjak wrote:
>>
>>> I have looked at example in rs6000.c, the only target that uses
>>> SUBREG_PROMOTED_UNSIGNED_P. Looking at other sources, S_P_U_P is
Hello,
this patch adds the ability for bitwise-truth operations to sink into
use-statement, if it is a cast, if type of it is compatible.
By this we can sink cases like
_Bool D1, D2, D3;
int R, x, y;
D1 = (bool) x;
D2 = (bool) y;
D3 = D1 & D2
R = (int) D3;
into R-statment as
R = x & y;
This f
On Thu, Jul 21, 2011 at 2:53 PM, Andrew Stubbs wrote:
> This patch is part bug fix, part better optimization.
>
> Firstly, my initial patch series introduced a bug that caused an internal
> compiler error when the input to a multiply was a constant. This was caused
> by the gimple verification rej
> Revised version, only 33 files modified now (instead of 51). We compile
> the C files for the compiler proper (and gnatbind) with the C++ compiler,
> but we keep compiling them with the C compiler in the other cases (library
> & tools). I think that this is in keeping with the other compilers (e
On Thu, Jul 21, 2011 at 3:09 PM, Kai Tietz wrote:
> Hello,
>
> this patch changes TRUTH-expression patterns into BIT-expression ones
> and adjusts code-flow
> for this.
>
> ChangeLog gcc
>
> 2011-07-21 Kai Tietz
>
> * tree-vrp.c (extract_range_from_binary_expr): Convert
> truth ex
Patch applied.
Index: ChangeLog
===
--- ChangeLog (revision 176569)
+++ ChangeLog (working copy)
@@ -1,3 +1,7 @@
+2011-07-21 Joseph Myers
+
+ * MAINTAINERS (Global Reviewers): Add self.
+
2011-07-20 David Edelsohn
On 07/21/2011 01:09 PM, Daniel Carrera wrote:
This patch now fixes an existing bug in GFortran whereby the ALLOCATE
statement only gets error checking if you are allocating a scalar.
Somehow that does not seem to work. I just tried a vanilla trunk with
just your patch applied. For the followin
On Sun, 10 Jul 2011, Joern Rennecke wrote:
> Quoting "Joseph S. Myers" :
>
> > On Tue, 5 Jul 2011, Joern Rennecke wrote:
> >
> > > This patch splits out a new generator genattr-enum from genattr, and it
> > > generates insn-attr-enum.h, which just makes the enum declarations.
> > > This new head
On Tue, Jul 19, 2011 at 11:01:10AM +0200, Richard Guenther wrote:
> Looks like sth for libiberty to avoid replicating it two times?
Done as follows:
2011-07-21 Jakub Jelinek
PR c++/49756
* libiberty.h (stack_limit_increase): New prototype.
* stack-limit.c: New file.
On Mon, 11 Jul 2011, Romain Geissler wrote:
> This patch add a new exception to the plugin header flattering strategy.
> c-family files can't be installed in the plugin include root directory as some
> other files like cp/cp-tree.h will look for them in the c-family directory.
>
> Furthermore, i
OK in the absence of middle-end or build-system maintainer objections
within 72 hours.
--
Joseph S. Myers
jos...@codesourcery.com
On 07/21/2011 01:39 AM, Georg-Johann Lay wrote:
> - fprintf (asm_out_file, "/* DEBUG: cost = %d. */\n",
> -rtx_cost (PATTERN (insn), INSN, !optimize_size));
> + rtx set;
> +
> + if ((set = single_set (insn), set))
> +fprintf (asm_out_file, "/* DEBUG: cost = %d.
These two patches fix PR49715, the inability to optimize unsigned -> float
compares when the unsigned operand also fits into an SImode signed
integer.
The first patch makes VRP handle SSA name creation during
substitute_and_fold nicely and the second implements the above transform.
Does anyone
On 07/21/2011 08:09 AM, Richard Guenther wrote:
> + /* It's not interesting to widen anything smaller than SImode. */
> + if (TYPE_PRECISION (TREE_TYPE (rhs1)) < GET_MODE_PRECISION (SImode)
> + || (!TYPE_UNSIGNED (TREE_TYPE (rhs1))
> + && TYPE_PRECISION (TREE_TYPE (rhs1)) == GET_MO
On 07/21/2011 04:19 PM, Tobias Burnus wrote:
On 07/21/2011 01:09 PM, Daniel Carrera wrote:
This patch now fixes an existing bug in GFortran whereby the ALLOCATE
statement only gets error checking if you are allocating a scalar.
Somehow that does not seem to work. I just tried a vanilla trunk w
Tested on Linux/X86-32.
2011-07-21 Ville Voutilainen
Warn about the use of final/override in non-c++0x mode, and add
__final for non-c++0x mode.
* cp-tree.h (cpp0x_warn_str): Add CPP0X_OVERRIDE_CONTROLS.
* error.c (maybe_warn_cpp0x): Adjust.
* parser
On Thu, 21 Jul 2011, Richard Henderson wrote:
> On 07/21/2011 08:09 AM, Richard Guenther wrote:
> > + /* It's not interesting to widen anything smaller than SImode. */
> > + if (TYPE_PRECISION (TREE_TYPE (rhs1)) < GET_MODE_PRECISION (SImode)
> > + || (!TYPE_UNSIGNED (TREE_TYPE (rhs1))
>
On Thu, 21 Jul 2011, Richard Henderson wrote:
> On 07/21/2011 08:09 AM, Richard Guenther wrote:
> > + /* It's not interesting to widen anything smaller than SImode. */
> > + if (TYPE_PRECISION (TREE_TYPE (rhs1)) < GET_MODE_PRECISION (SImode)
> > + || (!TYPE_UNSIGNED (TREE_TYPE (rhs1))
>
I have just updated to the latest svn revision, and it seems you
forgot to #include cpplib.h and langhooks.h.
Note about the c-family issue, you will be allowed to apply it (in the
trunk, and then in the melt branch) in 24 hours unless the plugin
maintainer block this one. I can't do it by myself
On Tue, 12 Jul 2011, Andrew Haley wrote:
> >> *(unsigned int*) &__tramp[0] = 0xe92d000f; /* stmfd sp!, {r0-r3} */ \
> >> *(unsigned int*) &__tramp[4] = 0xe59f; /* ldr r0, [pc] */ \
> >> *(unsigned int*) &__tramp[8] = 0xe59ff000; /* ldr pc, [pc] */ \
> > Your patch look
On 21 July 2011 18:23, Ville Voutilainen wrote:
> +struct F : E {}; { dg-error "cannot derive from ‘final’ base" }
Urgh, botched. Will send a new patch after I finish the test run. Note
to self: it's not
a good idea to run check-c++ target with make -j3. One might think
tests pass when
they don't
On 07/21/2011 05:20 PM, Daniel Carrera wrote:
From what you posted, it looks like I sent the wrong patch. I
generated the patch again with a different name just to make sure I'm
not mixing it up (attached).
The patch is identical to the previous one. I wonder what goes wrong,
but it applies c
On Tue, March 15, 2011 1:59 pm, Jason Merrill wrote:
> Now that we're in stage 1 of 4.7, I'm looking to apply this soon, but
> now I notice that it doesn't have a testcase. Could you add one?
>
Sorry I didn't see this earlier. Been busy with day-job stuff for
months and let my mail account overru
On Thu, Jul 21, 2011 at 5:12 AM, Kai Tietz wrote:
> 2011/7/21 Richard Guenther :
>> With these two changes the patch is ok to commit (it will also
>> regress gcc.target/i386/andor-2.c but that is an exact duplicate
>> of the already regressed gcc.dg/tree-ssa/vrp47.c).
>>
>> Thanks,
>> Richard.
>>
On Thu, Jul 21, 2011 at 8:40 AM, H.J. Lu wrote:
> On Thu, Jul 21, 2011 at 5:12 AM, Kai Tietz wrote:
>> 2011/7/21 Richard Guenther :
>>> With these two changes the patch is ok to commit (it will also
>>> regress gcc.target/i386/andor-2.c but that is an exact duplicate
>>> of the already regressed
Many of the NEON load/store instructions only allow address of the form:
(reg rN)
(post_inc (reg rN))
(post_modify (reg rN) (reg rM))
with no reg+const alternative. If vectorised code has several
consecutive loads, it's often better to use a series of post_incs such as:
*r1++
On Thu, 21 Jul 2011, Joseph S. Myers wrote:
> On Thu, 21 Jul 2011, Richard Henderson wrote:
>
> > On 07/21/2011 08:09 AM, Richard Guenther wrote:
> > > + /* It's not interesting to widen anything smaller than SImode. */
> > > + if (TYPE_PRECISION (TREE_TYPE (rhs1)) < GET_MODE_PRECISION (SImo
On Fri, April 1, 2011 11:06 pm, Jason Merrill wrote:
> Now that we're in stage 1 again, I'd like to get your decltype changes
> integrated. Sorry I didn't respond sooner.
>
No worries. I'm guilty of not checking mails for months due to other
commitments so didn't see either of your responses (or
On 07/21/11 17:42, Richard Sandiford wrote:
> Tested on arm-linux-gnueabi. Thoughts?
I'll try to find some time to look at it a bit. One thing I've always
wanted to do is move auto-inc-dec after reload, so that we can remove
inc_for_reload - do you think your new code could handle this?
Bernd
Basile Starynkevitch writes:
> I have a similar issue in the MELT branch, and I am passing to -frandom-seed
> the md5sum
> of relevant source files. With such a trick, the seed is reproducible from
> one build to
> the next one (of the exact same source tree), and does provide much more
> rand
Hello!
This is the same functionality as recently added to glibc [1].
2011-07-21 Uros Bizjak
* lib/target-supports.exp (check_avx_os_support_available): New.
(check_effective_target_avx_runtime): Use it.
Tested on x86_64-pc-linux-gnu {,-m32} AVX and non-AVX targets,
ommitted
On Thu, 21 Jul 2011 17:32:40 +0200
Romain Geissler wrote:
> I have just updated to the latest svn revision, and it seems you
> forgot to #include cpplib.h and langhooks.h.
Done. Committed revision 176577 of the MELT branch.
Thanks for spotting my mistake.
--
Basile STARYNKEVITCH http:
On Tue, 12 Jul 2011, Rainer Orth wrote:
> Only a couple of special defines (like FLOAT_WORD_ORDER_MISMATCH,
> QUIET_NAN_NEGATED) are moved to special t-* files in libgcc/config with
> [FDT]PBIT_CFLAGS similar to e.g. LIBGCC_SYNC_CFLAGS. If it were
> possible to have gcc define some __LIBGCC_* mac
Bernd Schmidt writes:
> On 07/21/11 17:42, Richard Sandiford wrote:
>> Tested on arm-linux-gnueabi. Thoughts?
>
> I'll try to find some time to look at it a bit.
Thanks.
> One thing I've always
> wanted to do is move auto-inc-dec after reload, so that we can remove
> inc_for_reload - do you thi
On 07/21/2011 05:36 PM, Tobias Burnus wrote:
The patch is identical to the previous one. I wonder what goes wrong,
...
I was using Mercurial wrong. I've been experimenting with using
Mercurial to work with GCC and was doing the diff wrong. The attached
file should be correct (fingers crossed
On Thu, Jul 21, 2011 at 08:51:46AM -0700, Ian Lance Taylor wrote:
> Basile Starynkevitch writes:
>
> > I have a similar issue in the MELT branch, and I am passing to
> > -frandom-seed the md5sum
> > of relevant source files. With such a trick, the seed is reproducible from
> > one build to
> >
Hi,
On Thu, Jul 21, 2011 at 07:37, Rainer Orth
wrote:
> As described in the PR, the use of LANGUAGE_C in CLooG breaks C++
> bootstrap on IRIX 6.5. Both MIPS and Alpha C compilers predefine
> LANGUAGE_C themselves, which clashes with the CLooG macro in
> . In a bootstrap with C++, LANGUAGE_C of
On 07/21/2011 08:47 AM, Richard Guenther wrote:
> Hm, of course some targets define unsigned float expanders just do
> do the complicated stuff manually (which is why I didn't look
> at the conversion optabs).
Unfortunately, there's no way to tell optabs.c not to widen
conversions all the way into
On Wed, Jul 20, 2011 at 9:06 PM, H.J. Lu wrote:
> The testcase is gcc.c-torture/compile/pr45728.c. This patch zero-extends
> symbol address to 64bit if needd. OK for trunk?
>
> Thanks.
>
>
> H.J.
>
> 2011-07-20 H.J. Lu
>
> PR target/49798
> * config/i386/i386.c (ix86_asm_in
On 07/21/2011 09:13 AM, H.J. Lu wrote:
>> >PR target/49798
>> >* config/i386/i386.c (ix86_asm_integer): New.
>> >(TARGET_ASM_INTEGER): Likewise.
>> >
> This is the updated patch, using the same approach in sparc_assemble_integer.
> OK for trunk?
Is there any reason why we d
On 07/21/11 13:28, Richard Sandiford wrote:
> +static void
> +process_bypass_2 (decl_t model, decl_t out_insn_reserv, void *data)
> +{
> + struct bypass_decl *bypass;
> + decl_t in_insn_reserv;
> +
> + in_insn_reserv = (decl_t) data;
> + bypass = XCNEW (struct bypass_decl);
> + bypass->latenc
On Thu, Jul 21, 2011 at 9:15 AM, Richard Henderson wrote:
> On 07/21/2011 09:13 AM, H.J. Lu wrote:
>>> > PR target/49798
>>> > * config/i386/i386.c (ix86_asm_integer): New.
>>> > (TARGET_ASM_INTEGER): Likewise.
>>> >
>> This is the updated patch, using the same approach in spa
On 07/21/2011 09:20 AM, H.J. Lu wrote:
> ".quad symbol" isn't really valid for 32bit.
Why not? We certainly know what value to put there.
> I can add a new ".xquad" directive,
> similar to ".xword" for sparc...
That seems like exactly the same meaningless complication.
r~
On Thu, Jul 21, 2011 at 9:23 AM, Richard Henderson wrote:
> On 07/21/2011 09:20 AM, H.J. Lu wrote:
>> ".quad symbol" isn't really valid for 32bit.
>
> Why not? We certainly know what value to put there.
>
x32 doesn't support 64bit relocation, like R_X86_64_64.
In many causes, generate
.long s
This obvious patch just removes unused tree_ssa_loop_version function
declaration from tree-flow.h. Will be committed in 24 hours if no objection.
2011-07-20 Roman Zhuykov
* tree-flow.h (tree_ssa_loop_version): Remove unused
declaration.
---
gcc/tree-flow.h |2 --
1 files
While building a data dependency graph for loop a ddg edge for some pair
of instructions with inter-loop dependency should be created only if
there is no edge for intra-loop dependency between these instructions.
Creating both of edges leads sometimes to the fact that function
generate_reg_moves cr
This patch fixes the compiler segfault found while regtesting trunk with SMS on
IA64 platform. Segfault happens on test gcc.dg/pr45259.c with -fmodulo-sched
enabled. The following jump instruction is given as argument for
doloop_condition_get function:
(jump_insn 86 85 88 7 (set (pc)
(reg
This patch should be applied only after previous patch. This patch allows SMS
to schedule loops with non-NULL condition under which the loop is infinite.
Infinite condition is an expression list and all of them should be false if we
want to use niter_expr. So, if each of expressions is a simple c
All the work described in next emails was done while trying to improve SMS
functionality. The main idea is to remove requrement of doloop_end instruction
pattern. This allows SMS to work on more platforms, for example x86-64 and
ARM.
All job was done on top of the following patch. This patch is
This patch adds an assertion in function rtl_lv_add_condition_to_bb.
It allows me to find mistakes easier while writing code which creates
complex loop versioning condition in previous patch.
2011-07-20 Roman Zhuykov
* cfgrtl.c (rtl_lv_add_condition_to_bb): New assertion.
---
gcc/cfgrt
This patch adds a multiply-and-add instruction expression to
simple_rhs_p function. When debugging my sms patches, the following
situation was found. Imagine a loop, with constant step > 1, where "n"
and "fin" is unknown at compile time.
for (c = n * step + fin; c != fin; c -= step) ...;
c is a
This patch moves the pass_sms before the pass_partition_blocks. There
is no doloop_end pattern on x86_64. That's why current SMS
implementation can't schedule any loops. But regtesting trunk with SMS
on x86_64 shows an ICE on gcc.dg/tree-prof/bb-reorg.c. The problem is
in an unconditional edge
This patch eliminates fake doloop_end pattern for ARM platform. The problem
with such a pattern is that it slows down the loop when SMS doesn't create good
schedule. So, i suppose fake pattern is no longer needed with new loop forms
supported.
2011-07-20 Roman Zhuykov
* config/arm/thu
This patch should be applied only after pending patches by Revital. This patch
significantly enhances the existing implementation of the SMS. Patch adds
support of scheduling loops without doloop pattern. The loop should meet the
following requirements.
First three are the same as for loop with
This patch removes a few XPASSes from the testsuite.
It also forces all the sse4_1-blendps* tests to compile with -O0. At
the point of the latest merge from trunk (175879), these tests were
flaky when compiled with -march=pentium3 -mtune=pentium4 -m32.
We were discussing this on IRC, and Jakub c
On 07/21/2011 06:01 PM, Daniel Carrera wrote:
I was using Mercurial wrong. I've been experimenting with using
Mercurial to work with GCC and was doing the diff wrong. The attached
file should be correct (fingers crossed).
Looks better :-)
The patch is OK after regtesting and fixing the follow
Ok. Updated patch and updated ChangeLog attached. Compiles fine and I'm
about to start running the test suite again.
Cheers,
Daniel.
On 07/21/2011 06:37 PM, Tobias Burnus wrote:
On 07/21/2011 06:01 PM, Daniel Carrera wrote:
I was using Mercurial wrong. I've been experimenting with using
Mer
On 07/21/2011 06:09 PM, Sebastian Pop wrote:
Hi,
On Thu, Jul 21, 2011 at 07:37, Rainer Orth
wrote:
As described in the PR, the use of LANGUAGE_C in CLooG breaks C++
bootstrap on IRIX 6.5. Both MIPS and Alpha C compilers predefine
LANGUAGE_C themselves, which clashes with the CLooG macro in
.
On Thu, Jul 21, 2011 at 6:28 PM, H.J. Lu wrote:
>>> ".quad symbol" isn't really valid for 32bit.
>>
>> Why not? We certainly know what value to put there.
>>
>
> x32 doesn't support 64bit relocation, like R_X86_64_64.
> In many causes, generate
>
> .long symbol
> .long 0
>
> for ".quad symbol"
1 - 100 of 196 matches
Mail list logo
