On Tue, Aug 14, 2012 at 10:45 PM, Diego Novillo 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 else". It d
On 14/08/2012, at 7:08 PM, Richard Sandiford wrote:
> OK with those changes, thanks.
Checked in with the noted changes and a fixed bug.
It turns out that mips_linked_madd_p is also called via
mips_macc_chains_reorder, which may pass a (use ...) instruction, which causes
get_attr_* to blow up.
This patch to the Go frontend, from Diego, updates it for the conversion
of GCC to building with C++. Bootstrapped and ran Go testsuite on
x86_64-unknown-linux-gnu. Committed to mainline.
Ian
diff -r 681a1ae3f72c go/expressions.cc
--- a/go/expressions.cc Fri Aug 10 21:07:57 2012 -0700
+++ b/go/
Hi,
Right now we only produce ins when a zero_extract is used on the
right hand side. We can do better by adding some patterns which
combine for the ins instruction. This patch adds those patterns and a
testcase which shows a simple example where the code is improved.
OK? Bootstrapped and tes
This patch adds an xfail manifest for trunk for x86_64 builds. I find
this useful to determine whether my patch has introduced new failures.
The failures in these manifest are always present in trunk and
deciding what to ignore is not very straightforward.
I will keep maintaining this manifest out
If a target implements (some) atomics by only setting
sync_compare_and_swap_optab libfuncs (see
cris.c:cris_init_libfuncs), a code-path less travelled is used.
There's a bug there, causing sync/atomic operators to be
implemented with the reverse operator, e.g. minus instead of
plus.
This should ha
On Tue, Aug 14, 2012 at 4:27 PM, Ian Lance Taylor wrote:
> On Tue, Aug 14, 2012 at 3:47 PM, Maxim Kuvyrkov
> wrote:
>
>> I think this patch will break MIPS Android build due to mismatch of
>> ElfW(type) when _MIPS_SZPTR == 64. I think the right way to fix this is to
>> make Bionic export link
On Tue, Aug 14, 2012 at 3:47 PM, Maxim Kuvyrkov wrote:
> On 15/08/2012, at 7:39 AM, H.J. Lu wrote:
>
>> On Tue, Aug 14, 2012 at 12:38 PM, H.J. Lu wrote:
>>> On Thu, Aug 9, 2012 at 3:17 PM, Ian Lance Taylor wrote:
On Thu, Aug 9, 2012 at 9:39 AM, H.J. Lu wrote:
>
> Bionic C library d
On Tue, Aug 14, 2012 at 3:47 PM, Maxim Kuvyrkov wrote:
> I think this patch will break MIPS Android build due to mismatch of
> ElfW(type) when _MIPS_SZPTR == 64. I think the right way to fix this is to
> make Bionic export link.h or already-existing linker.h, but I differ to Ian
> for final j
On 15/08/2012, at 7:39 AM, H.J. Lu wrote:
> On Tue, Aug 14, 2012 at 12:38 PM, H.J. Lu wrote:
>> On Thu, Aug 9, 2012 at 3:17 PM, Ian Lance Taylor wrote:
>>> On Thu, Aug 9, 2012 at 9:39 AM, H.J. Lu wrote:
Bionic C library doesn't provide link.h.
>>>
>>> Does Bionic provide dl_iterate_
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 performed in a sufficiently wide type.
Bootstrapped and
The main purpose of this patch is to allow elements of assumed-shape
arrays (which are scalars) and assumed-rank arrays with C_LOC.
There are several other issues with the current C_LOC handling (and with
C_F_POINTER), but I want to fix the most important reject-valid issues
first as they bloc
Thanks, Andrew!
Bill
On Tue, 2012-08-14 at 14:17 -0700, Andrew Pinski wrote:
> On Tue, Aug 14, 2012 at 2:15 PM, Andrew Pinski wrote:
> > On Tue, Aug 14, 2012 at 2:11 PM, William J. Schmidt
> > wrote:
> >> Replace the once vacuously true, and now vacuously false, test for
> >> existence of a con
On Tue, 14 Aug 2012, Diego Novillo wrote:
> OK to install after the merge?
Yep, this looks good. Thanks!
Gerald
Attached, is an updated patch (with change logs).
The test cases are now in gcc.target/i386 and the
target selection is "dg-require-effective-target int128" only.
Verified that the tests correctly detect the presence/lack
of TImode support.
- Gary
Index: gcc/config/i386/i386.h
==
On Tue, Aug 14, 2012 at 2:15 PM, Andrew Pinski wrote:
> On Tue, Aug 14, 2012 at 2:11 PM, 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 su
On Tue, Aug 14, 2012 at 2:11 PM, 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
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 test is powerpc-specific. It would be good to have an
On 8/14/12, Steven Bosscher wrote:
> On Aug 14, 2012 Diego Novillo wrote:
> > On 12-08-14 14:26 , Steven Bosscher wrote:
> > > Many unused timevars, many timevars that measure completely
> > > different passes, passes with the wrong timevar, etc.
> > >
> > > Time for a bit of maintenance / janito
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 else". It depends on the configuration -- more
specifically on HAVE_USER_TIME, HAV
On Tue, Aug 14, 2012 at 9:25 PM, Diego Novillo wrote:
>> This 32 is just currently the longest name length of all timevars (for
>> "straight-line strength reduction"), but there are a few more long
>> ones ("PCH preprocessor state restore" ...). I didn't look at the
>> total length of the lines th
On Tue, Aug 14, 2012 at 12:38 PM, H.J. Lu wrote:
> On Thu, Aug 9, 2012 at 3:17 PM, Ian Lance Taylor wrote:
>> On Thu, Aug 9, 2012 at 9:39 AM, H.J. Lu wrote:
>>>
>>> Bionic C library doesn't provide link.h.
>>
>> Does Bionic provide dl_iterate_phdr? If it does, I'll just note in
>> passing that
On Thu, Aug 9, 2012 at 3:17 PM, Ian Lance Taylor wrote:
> On Thu, Aug 9, 2012 at 9:39 AM, H.J. Lu wrote:
>>
>> Bionic C library doesn't provide link.h.
>
> Does Bionic provide dl_iterate_phdr? If it does, I'll just note in
> passing that it would be straightforward to simply incorporate the
> re
On 12-08-14 15:20 , Steven Bosscher wrote:
On Tue, Aug 14, 2012 at 9:17 PM, Diego Novillo wrote:
Is 32 the longest we can tolerate?
This 32 is just currently the longest name length of all timevars (for
"straight-line strength reduction"), but there are a few more long
ones ("PCH preprocessor
On Tue, Aug 14, 2012 at 9:17 PM, Diego Novillo wrote:
> Is 32 the longest we can tolerate?
This 32 is just currently the longest name length of all timevars (for
"straight-line strength reduction"), but there are a few more long
ones ("PCH preprocessor state restore" ...). I didn't look at the
to
On 12-08-14 15:06 , Steven Bosscher wrote:
On Tue, Aug 14, 2012 at 8:40 PM, Diego Novillo wrote:
On 12-08-14 14:26 , Steven Bosscher wrote:
@@ -505,6 +507,16 @@ timevar_print (FILE *fp)
TIMEVAR. */
start_time = now;
+#ifdef ENABLE_CHECKING
+ /* Pester those who add timevars with
On Tue, Aug 14, 2012 at 8:40 PM, Diego Novillo wrote:
> On 12-08-14 14:26 , Steven Bosscher wrote:
>>
>> Hello,
>>
>> Many unused timevars, many timevars that measure completely different
>> passes, passes with the wrong timevar, etc.
>>
>> Time for a bit of maintenance / janitorial.
>>
>> Bootstr
On 12-08-14 09:48 , Diego Novillo wrote:
This merge touches several files, so I'm thinking that the best time is
going to be on Thu 16/Aug around 2:00 GMT.
So, the fixes I needed from Lawrence are already in so we can proceed
with the merge. I'll commit the merge tonight at ~2:00 GMT.
Afte
On 12-08-14 14:26 , Steven Bosscher wrote:
Hello,
Many unused timevars, many timevars that measure completely different
passes, passes with the wrong timevar, etc.
Time for a bit of maintenance / janitorial.
Bootstrapped&tested on powerpc64-unknown-linux-gnu. OK for trunk?
Ciao!
Steven
Hello,
Many unused timevars, many timevars that measure completely different
passes, passes with the wrong timevar, etc.
Time for a bit of maintenance / janitorial.
Bootstrapped&tested on powerpc64-unknown-linux-gnu. OK for trunk?
Ciao!
Steven
timevar_tlc.diff
Description: Binary data
+ger...@pfiefer.com
On Tue, Aug 14, 2012 at 10:51 AM, Sriraman Tallam wrote:
> Hi Gerald,
>
>Is this release note alright?
>
> Thanks,
> -Sri.
>
> On Fri, Aug 10, 2012 at 7:20 PM, Sriraman Tallam wrote:
>> Hi,
>>
>>I have added a release note for x86 builtins __builtin_cpu_is and
>> __bu
Hi Gerald,
Is this release note alright?
Thanks,
-Sri.
On Fri, Aug 10, 2012 at 7:20 PM, Sriraman Tallam wrote:
> Hi,
>
>I have added a release note for x86 builtins __builtin_cpu_is and
> __builtin_cpu_supports. They were checked in to trunk in rev. 186789.
> Is this ok to submit?
>
> Th
Hi, Dodji,
Thanks for the review. I've fixed all the addressed issues. I'm
attaching the related changes:
Thanks,
Dehao
libcpp/ChangeLog:
2012-08-01 Dehao Chen
* include/line-map.h (MAX_SOURCE_LOCATION): New value.
(location_adhoc_data_init): New.
(location_adhoc_data
On Tue, Aug 14, 2012 at 9:12 AM, Gary Funck wrote:
> On 08/14/12 15:33:10, Joseph S. Myers wrote:
>> On Tue, 14 Aug 2012, Jakub Jelinek wrote:
>>
>> > On Mon, Aug 13, 2012 at 09:20:32PM -0700, Gary Funck wrote:
>> > > --- gcc/testsuite/gcc.dg/pr20020-1.c (revision 0)
>> > > +++ gcc/testsuite/
On 08/14/12 15:33:10, Joseph S. Myers wrote:
> On Tue, 14 Aug 2012, Jakub Jelinek wrote:
>
> > On Mon, Aug 13, 2012 at 09:20:32PM -0700, Gary Funck wrote:
> > > --- gcc/testsuite/gcc.dg/pr20020-1.c (revision 0)
> > > +++ gcc/testsuite/gcc.dg/pr20020-1.c (revision 0)
> > > @@ -0,0 +1,25 @
Gerald,
I have this queued up in my local tree, waiting for the final
merge of the cxx-conversion branch.
OK to install after the merge?
Thanks. Diego.
Index: index.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/index.html,v
retriev
On Mon, Aug 13, 2012 at 9:50 PM, Richard Henderson wrote:
> On 08/13/2012 12:33 PM, Uros Bizjak wrote:
>> AFAIU fma3 is better than fma4 for bdver2 (the only CPU that
>> implements both FMA sets). Current description of bdver2 doesn't even
>> enable fma4 in processor_alias_table due to this fact.
On Tue, 14 Aug 2012, Jakub Jelinek wrote:
> On Mon, Aug 13, 2012 at 09:20:32PM -0700, Gary Funck wrote:
> > --- gcc/testsuite/gcc.dg/pr20020-1.c(revision 0)
> > +++ gcc/testsuite/gcc.dg/pr20020-1.c(revision 0)
> > @@ -0,0 +1,25 @@
> > +/* Target is restricted to x86_64 type archite
On Tue, Aug 14, 2012 at 3:35 PM, Yuri Rumyantsev wrote:
> Uros,
>
> Let me try to explain you why I used such code duplication:
>
> Here we have a common case of LEA with 3 different registers - r0
> (target), r1(base), r2(index) and possible offset.
> To get the better scheduling we first try to
On Mon, Aug 13, 2012 at 6:18 PM, Mike Stump wrote:
> On Aug 13, 2012, at 4:56 PM, Sterling Augustine wrote:
>> The enclosed patch adjusts the test so it will pass on darwin. The
>> issue was that it looked for some elf-specific assembly directives,
>> which it shouldn't.
>>
>> OK for mainline?
>
>
On Tue, 14 Aug 2012, Richard Guenther wrote:
>
> This implements constant pool entry sharing for CONST_VECTORs with the
> same bit-pattern by canonicalizing them to the same-sized mode with
> the least number of elements. Ideally we would be able to hash and
> compare the in-memory representatio
Hi,
This fixes PR target/54212.. The problem here was we were
marking a number of patterns in neon.md as predicable. Advanced SIMD
instructions are not predicable in ARM state, however are allowed to
exist in Thumb2 in IT blocks ( though this is a feature that is
deprecated and is document
> "Jonathan" == Jonathan Wakely writes:
Jonathan> I prefer it as unique_ptr but I'm probably not your typical
Jonathan> user of the pretty printers, so if anyone else has an opinion please
Jonathan> share it.
I prefer it too. Here's the updated patch. Let me know what you think.
Tom
2012
On 12-08-14 10:05 , Simon Baldwin wrote:
Update contrib/testsuite-management/powerpc-grtev3-linux-gnu.xfail.
Tested with build followed by validate_failures.py. Okay for all applicable
branches?
2012-08-14 Simon Baldwin
* testsuite-management/powerpc-grtev3-linux-gnu.xfail: Add new
Update contrib/testsuite-management/powerpc-grtev3-linux-gnu.xfail.
Tested with build followed by validate_failures.py. Okay for all applicable
branches?
2012-08-14 Simon Baldwin
* testsuite-management/powerpc-grtev3-linux-gnu.xfail: Add new entries
for soft-float.
Index: c
> OK, provided that the patches in the above threads apply without conflicts.
> If there are conflicts, please repost for review.
Comitted to 4.7 branch: http://gcc.gnu.org/ml/gcc-cvs/2012-08/msg00360.html
Thanks, K
Attached is the first 4.8 merge of the Fortran related changes from
wiki/Gfortran#news into the 4.8 release notes.
I have committed the patch as obvious, however, I am happy for any comments.
Possibly easier to read: http://gcc.gnu.org/gcc-4.8/changes.html (all in
the "Fortran" section)
Tobi
On 12-08-12 16:04 , Diego Novillo wrote:
I will be sending 6 patches that implement all the changes we
have been making on the cxx-conversion branch. As described in
http://gcc.gnu.org/ml/gcc/2012-08/msg00015.html, these patches
change the default bootstrap process so that stage 1 always
builds
This implements constant pool entry sharing for CONST_VECTORs with the
same bit-pattern by canonicalizing them to the same-sized mode with
the least number of elements. Ideally we would be able to hash and
compare the in-memory representation of a constant (together with
its alignment requirement
Uros,
Let me try to explain you why I used such code duplication:
Here we have a common case of LEA with 3 different registers - r0
(target), r1(base), r2(index) and possible offset.
To get the better scheduling we first try to determine what register
is prefirable for inititial setting - r1 or r
On 12-08-14 09:19 , Diego Novillo wrote:
+static const char *
+filter_type_name (const char *type_name)
+{
Maybe this function should return const-less char *? The casts to cast
the const away for freeing it look a bit awkward.
Done.
I was too quick. The problem here is that we sometime
On 12-08-14 04:38 , Dodji Seketeli wrote:
Hello Diego,
Just some minor comments.
Diego Novillo a écrit:
[...]
+@section User-provided marking routines for template types
+When a template type @code{TP} is marked with @code{GTY}, all
+instances of that type are considered user-provided types
On 12-08-14 01:39 , Laurynas Biveinis wrote:
(walk_type): Set D->IN_PTR_FILED when walking a TYPE_POINTER.
"FIELD"
Done.
+fields is completely handled by user-provided routines. Section
+@ref{User GC} for details on what functions need to be provided.
"See Section ... " ?
Don
On Tue, Aug 14, 2012 at 2:45 PM, Jakub Jelinek wrote:
>> >> 2. Passing function arguments in HW registers.
>> >> The main problem here is that backward copy propagation phase (aka
>> >> combine instructions) can propagate HW argument registers to
>> >> instructions evaluating argument values (e.g
On Tue, Aug 14, 2012 at 2:45 PM, Jakub Jelinek wrote:
> On Tue, Aug 14, 2012 at 02:40:42PM +0200, Richard Guenther wrote:
>> On Tue, Aug 14, 2012 at 2:02 PM, Uros Bizjak wrote:
>> > On Tue, Aug 14, 2012 at 1:51 PM, Yuri Rumyantsev
>> > wrote:
>> >
>> >> 2. Passing function arguments in HW regis
On Tue, Aug 14, 2012 at 02:40:42PM +0200, Richard Guenther wrote:
> On Tue, Aug 14, 2012 at 2:02 PM, Uros Bizjak wrote:
> > On Tue, Aug 14, 2012 at 1:51 PM, Yuri Rumyantsev wrote:
> >
> >> 2. Passing function arguments in HW registers.
> >> The main problem here is that backward copy propagation
On Tue, Aug 14, 2012 at 2:02 PM, Uros Bizjak wrote:
> On Tue, Aug 14, 2012 at 1:51 PM, Yuri Rumyantsev wrote:
>
>> 2. Passing function arguments in HW registers.
>> The main problem here is that backward copy propagation phase (aka
>> combine instructions) can propagate HW argument registers to
>
On 08/13/2012 04:32 PM, Mikael Morin wrote:
here is a fix for PR47586: missing deep copy for the case:
dt_w_alloc = ptr_func(arg)
The patch set looks okay. I am not 100% sure how compatible your changes
are with regards to finalization and coarray components, but I have the
impression they do
On Tue, Aug 14, 2012 at 2:28 PM, Yuri Rumyantsev wrote:
> Thanks a lot forr your comments.
>
> I prepared new patch and ChangeLog. Testing of x32 is in progress.
>
> It it OK for trunk?
>
> 2012-08-14 Yuri Rumyantsev
>
> * config/i386/i386-protos.h (ix86_split_lea_for_addr) : Add
>
Hi Uros,
Thanks a lot forr your comments.
I prepared new patch and ChangeLog. Testing of x32 is in progress.
It it OK for trunk?
2012-08-14 Yuri Rumyantsev
* config/i386/i386-protos.h (ix86_split_lea_for_addr) : Add
additional argument.
* config/i386/i386.md (ix86_s
On Tue, Aug 14, 2012 at 1:51 PM, Yuri Rumyantsev wrote:
> 2. Passing function arguments in HW registers.
> The main problem here is that backward copy propagation phase (aka
> combine instructions) can propagate HW argument registers to
> instructions evaluating argument values (e.g. issue#46829
On 08/14/12 08:30:59, Jakub Jelinek wrote:
> On Mon, Aug 13, 2012 at 09:20:32PM -0700, Gary Funck wrote:
> > --- gcc/testsuite/gcc.dg/pr20020-1.c(revision 0)
> > +++ gcc/testsuite/gcc.dg/pr20020-1.c(revision 0)
> > @@ -0,0 +1,25 @@
> > +/* Target is restricted to x86_64 type archite
Hi Richard,
These changes try to resolve the known problem with the first
instruction scheduler for x86 platform. The main issue is the
existence of hardware registers that are used for unloading of
function arguments passing in HW registers and for passing function
arguments in HW registers.
1. U
Oleg Endo wrote:
> This patch adds basic support for utilizing the SH div0s instruction to
> simplify some integer sign comparisons such as '(a < 0) == (b < 0)'.
> Tested on rev 190332 with
> make -k check RUNTESTFLAGS="--target_board=sh-sim
> \{-m2/-ml,-m2/-mb,-m2a/-mb,-m4/-ml,-m4/-mb,-m4a/-ml,-m
Oleg Endo wrote:
> This adds support for the SH2A instructions movu.b and movu.w for
> zero-extending mem loads with displacement addressing.
> Tested on rev 190332 with
> make -k check RUNTESTFLAGS="--target_board=sh-sim
> \{-m2/-ml,-m2/-mb,-m2a/-mb,-m4/-ml,-m4/-mb,-m4a/-ml,-m4a/-mb}"
>
> and no
This makes --without-cloog and --without-isl disable GRAPHITE support
as intended.
Tested up to building stage2 with --without-isl, verified ISL was not
used or checked for, tested up to building stage2 without --without-isl,
verified system ISL was picked up.
Ok for trunk?
Thanks,
Richard.
20
This makes the re-gimplification process create anonymous SSA names
instead of creating first decls and then SSA names. The only
fix needed is to SESE which does jump through hoops initializing
a value when that is not needed.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk
On Tue, 14 Aug 2012, Richard Guenther wrote:
>
> This adds verification code that we do not try to rewrite a symbol
> into SSA form that is already partly in SSA form. That would lead
> to silent wrong-code generation.
>
> Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.
On Tue, 14 Aug 2012, Steven Bosscher wrote:
> On Tue, Aug 14, 2012 at 12:48 PM, Richard Guenther wrote:
> > If SPU md reorg would like to look at loop structures it should
> > compute them. Simply call flow_loops_find, which hopefully works
> > in CFG RTL mode (which I think is the mode availabl
On Tue, Aug 14, 2012 at 12:48 PM, Richard Guenther wrote:
> If SPU md reorg would like to look at loop structures it should
> compute them. Simply call flow_loops_find, which hopefully works
> in CFG RTL mode (which I think is the mode available from md reorg?).
No, the CFG is destroyed just bef
On Tue, 14 Aug 2012, Ulrich Weigand wrote:
> Richard Guenther wrote:
>
> > Accessing loop_depth (bb->loop_father) isn't very expensive. The
> > following removes the duplicate info in basic-blocks which is not
> > properly kept up-to-date at the moment.
>
> Looks like this broke SPU build, sinc
On Tue, Aug 14, 2012 at 12:07 PM, Steven Bosscher wrote:
> Hello,
>
> Verifying loop fathers now passes on powerpc64-unknown-linux-gnu.
>
> Also speed up fix_loop_structure by requiring DOM_OK so that fast DOM
> queries are available.
>
> Bootstrapped&tested on powerpc64-unknown-linux-gnu. OK for
On 08/14/2012 11:57 AM, Mikael Morin wrote:
On 14/08/2012 11:33, Tobias Burnus wrote:
Thus, I removed ST_LABEL_ENDDO_TARGET, use "=type" and added a comment,
but I didn't do the verify_st_order change.
Build and regested on x86-64-linux.
OK for the trunk?
OK, apart for:
* gfortran.dg/
Richard Guenther wrote:
> Accessing loop_depth (bb->loop_father) isn't very expensive. The
> following removes the duplicate info in basic-blocks which is not
> properly kept up-to-date at the moment.
Looks like this broke SPU build, since spu_machine_dependent_reorg
accesses ->loop_depth. Acco
Hello,
Verifying loop fathers now passes on powerpc64-unknown-linux-gnu.
Also speed up fix_loop_structure by requiring DOM_OK so that fast DOM
queries are available.
Bootstrapped&tested on powerpc64-unknown-linux-gnu. OK for trunk?
Ciao!
Steven
cfg_loop_father.diff
Description: Binary data
On Tue, Aug 14, 2012 at 12:03 PM, Steven Bosscher wrote:
> Hello,
>
> Checking overhead in dominance.c gives measurable compile time
> increases on a set of cc1-i files. Most of the checking should be done
> only with non-release checks enabled.
>
> Bootstrapped&tested on powerpc64-unknown-linux-g
On 14/08/2012 11:33, Tobias Burnus wrote:
> This patch adds a -Wconversion warning (enabled also by -Wall) for
> CMPLX(real, real)
> if the real arguments have a higher kind number/precision as the
> default-kind of complex/real. I think most of the time, this precision
> loss is unintended; it c
Hello,
Checking overhead in dominance.c gives measurable compile time
increases on a set of cc1-i files. Most of the checking should be done
only with non-release checks enabled.
Bootstrapped&tested on powerpc64-unknown-linux-gnu. OK for trunk?
Ciao!
Steven
dom_checking_assert.diff
Description
This removes the overhead of clearing a vector of n_basic_blocks
elements per anti expression during insertion by making it a vector
indexed by pred edge index and allocating it once for each basic
block instead. This can make a significant difference for large
functions.
Bootstrap and regtest p
On 14/08/2012 11:33, Tobias Burnus wrote:
> Thus, I removed ST_LABEL_ENDDO_TARGET, use "=type" and added a comment,
> but I didn't do the verify_st_order change.
>
> Build and regested on x86-64-linux.
> OK for the trunk?
>
OK, apart for:
* gfortran.dg/data_constraints_1.f90: Update dg-w
On Mon, Aug 13, 2012 at 10:49 AM, Richard Guenther
wrote:
> On Sun, Aug 12, 2012 at 11:49 PM, Steven Bosscher
> wrote:
>> Hello,
>>
>> This patch tried to use non-clearing memory allocation where possible.
>> This is especially important for very large functions, when arrays of
>> size in the or
I'm sorry the conversation about this patch went to private
incidentally. Resend the key point.
On Tue, Jul 24, 2012 at 8:40 PM, Julian Brown wrote:
> On Mon, 23 Jul 2012 13:48:22 +0800
> Ye Joey wrote:
>
>> Since v7m and v6m are very different. It is high desired to have
>> separate tuning for
On 08/09/2012 02:13 PM, Mikael Morin wrote:
On 08/08/2012 19:12, Tobias Burnus wrote:
With this patch, I think the only unimplemented obsolescence warning is for
"(8) Fixed form source -- see B.2.7."
For the latter, I would like to see a possibility to silence that
warning, given that there is
This patch adds a -Wconversion warning (enabled also by -Wall) for
CMPLX(real, real)
if the real arguments have a higher kind number/precision as the
default-kind of complex/real. I think most of the time, this precision
loss is unintended; it can be silenced when using a kind= parameter (or
This adds verification code that we do not try to rewrite a symbol
into SSA form that is already partly in SSA form. That would lead
to silent wrong-code generation.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.
Richard.
2012-08-14 Richard Guenther
* tree-i
OK for google/gcc-4_7.
thanks
Carrot
On Tue, Aug 14, 2012 at 7:14 AM, Han Shen(沈涵) wrote:
>
> Hi Carrot, could you take a look at this patch? Thanks!
>
> The modification is in upstream trunk patch revision - 186859.
>
> The same patch has been back ported to google/gcc-4_6
> (http://codereview.
On 14/08/2012 07:03, Paul Richard Thomas wrote:
>> ... but I have the feeling that this makes (*code) unreachable and that
>> that's wrong. Shouldn't it be "root->next = *code;" ?
>
> No. That caused the regression that I mentioned. (*code) is
> resolved, at entry. resolve_code steps on to (*co
On Tue, Aug 14, 2012 at 10:45:18AM +0200, Uros Bizjak wrote:
> > The 46829 failure is due to combine pass blindly propagating r8 into
> > divmod instruction. This is invalid for divmod, which expects ax
> > there.
> > This can be fixed by introducing "ax_register_operand" predicate, but
> > I think
On Tue, Aug 14, 2012 at 10:36 AM, Uros Bizjak wrote:
>> Patch aims to fix instability introduced by first scheduler on x86. In
>> particular it targets following list:
>>
>> [1] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46843
>> [2] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46829
>> [3] http:
On 14/08/2012 07:03, Paul Richard Thomas wrote:
>> However, if we do it before, we also overwrite components to be assigned
>> with a typebound call, and this can have some side effects as the LHS's
>> argument can be INTENT(INOUT).
>
> This might be so but it is what the standard dictates should
Hello Diego,
Just some minor comments.
Diego Novillo a écrit:
[...]
> +@section User-provided marking routines for template types
> +When a template type @code{TP} is marked with @code{GTY}, all
> +instances of that type are considered user-provided types. This means
> +that the individual in
On Mon, Aug 13, 2012 at 9:39 PM, Igor Zamyatin wrote:
> Patch aims to fix instability introduced by first scheduler on x86. In
> particular it targets following list:
>
> [1] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46843
> [2] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46829
> [3] http://gcc
On Mon, Aug 13, 2012 at 9:39 PM, Igor Zamyatin wrote:
> Hi all!
>
> Patch aims to fix instability introduced by first scheduler on x86. In
> particular it targets following list:
>
> [1] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46843
> [2] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46829
> [3]
On Mon, 13 Aug 2012, Lawrence Crowl wrote:
> On 8/13/12, Richard Guenther wrote:
> > Increment/decrement operations did not exist, please do not add
> > them at this point.
>
> Note that I have also added +=, -= and *= operations. Having them
> has three advantages. First, it matches expectati
Dehao Chen writes:
> Index: libcpp/line-map.c
[...]
> + /* Data structure to associate an arbitrary data to a source location. */
> + struct location_adhoc_data {
> + source_location locus;
> + void *data;
> + };
> +
> + /* The following data structure encodes a location with some adhoc da
Maxim Kuvyrkov writes:
> I thought I'll butt in since I did a very similar thing for
> sync_memmodel a couple of months ago.
Thanks.
> + /* We take care in instruction definitions to make sure accum_in operand is
> + a register_operand or [a more restrictive] muldiv_target_operand. */
> +
96 matches
Mail list logo
