* ping *
Tobias Burnus wrote:
*ping*
http://gcc.gnu.org/ml/gcc-patches/2013-12/msg00584.html
On December 6, 2013, Tobias Burnus wrote:
A rather simple fix for an ICE on invalid bug (low-priority 4.8/4.9
regression).
Bootstrapped and regtested without new failure on x86-64-gnu-linux.
OK for t
On Thu, Dec 12, 2013 at 5:13 PM, Jan Hubicka wrote:
>> On Wed, Dec 11, 2013 at 1:21 AM, Martin Liška wrote:
>> > Hello,
>> >I prepared a collection of systemtap graphs for GIMP.
>> >
>> > 1) just my profile-based function reordering: 550 pages
>> > 2) just -freorder-blocks-and-partitions: 646
On 12/14/13 12:53, Jakub Jelinek wrote:
2013-12-14 Jakub Jelinek
* ubsan.c: Include tree-ssanames.h, asan.h and gimplify-me.h.
(ubsan_type_descriptor): Handle BOOLEAN_TYPE and ENUMERAL_TYPE
like INTEGER_TYPE.
(instrument_bool_enum_load): New function.
(
Ok.
David
On Thu, Dec 19, 2013 at 5:42 PM, Dehao Chen wrote:
> This patch fix the bug to honor max-lipo-group for AutoFDO.
>
> Bootstrapped and passed regression test.
>
> OK for google-4_8 branch?
>
> Thanks,
> Dehao
>
> Index: gcc/auto-profile.c
>
>
On 12/16/13 11:40, Jakub Jelinek wrote:
On Mon, Dec 16, 2013 at 11:25:33AM -0700, Jeff Law wrote:
As you note, there's some question as to whether or not this should
be acceptable for 4.9. Yes it's well contained, but we really need
to draw the line. Is this the last thing for the sanitizers t
PR53623 is a case where transformations by the tree-ssa optimizers are
inhibiting the RTL optimizers.
As noted in c#5 we have something like this:
(set (reg:HI %ax) (mem:HI (whatever)))
(set (reg:DI %rdx) (sign_extend:DI (reg:HI %ax))
(set (reg:DI %rax) (zero_extend:DI (reg:QI %al))
Th
Here's a patch that splits up 20_util/hash/chi2_quality.cc *and*
increases some of the iteration numbers for simulator targets to
something that passes for all working targets mentioned below.
I am a bit worried about the stability of these tests and the
implementation, seeing this amount of target
Just something I noticed while working on 53623.
Dumps for extension elimination are keyed on -fdump-rtl-ree, not
dump-rtl-see and that optimizer eliminates both zero and sign extensions.
Installed on the trunk.
jeff
* doc/invoke.texi: (dump-rtl-ree): Fix typo and clarify ree
This patch fix the bug to honor max-lipo-group for AutoFDO.
Bootstrapped and passed regression test.
OK for google-4_8 branch?
Thanks,
Dehao
Index: gcc/auto-profile.c
===
--- gcc/auto-profile.c (revision 206135)
+++ gcc/auto-prof
As discussed in http://gcc.gnu.org/ml/gcc-patches/2013-11/msg02808.html
bootstrap + same regression tests as previous rev, ok?
2013-12-19 Trevor saunders
gcc/
* vec.h (stack_vec): Convert to a templaate specialization of
auto_vec.
* config/i386/i386.c, df-scan.c, funct
On Thu, Dec 19, 2013 at 2:06 PM, Steven Bosscher wrote:
> On Thu, Dec 19, 2013 at 8:33 PM, Teresa Johnson wrote:
>> 2013-12-19 Teresa Johnson <>
>>
>> PR gcov-profile/59542
>> * bb-reorder.c (duplicate_computed_gotos): Invoke fixup_partitions
>> if we have made any change
On Thu, Dec 19, 2013 at 8:33 PM, Teresa Johnson wrote:
> 2013-12-19 Teresa Johnson <>
>
> PR gcov-profile/59542
> * bb-reorder.c (duplicate_computed_gotos): Invoke fixup_partitions
> if we have made any changes.
>
> Index: bb-reorder.c
> ===
On 12/19/2013, 3:42 PM, Jakub Jelinek wrote:
Hi!
This patch is an attempt to fix various signed integer overflows,
invalid shifts and loads of uninialized bool value.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
This is solely from gcc build, make check has other issues
On Thu, Dec 19, 2013 at 11:50:02AM +0100, Bernd Edlinger wrote:
> Isn't the actual invocation of the build-g++ also including
> /sysroot_for_host/include
> in that case? Why doesn't this cause problems then?
Yes, and that causes failures too. BUILD_CPPFLAGS is the culprit.
See http://gcc.gnu.org
On Thu, Dec 19, 2013 at 9:42 PM, Jakub Jelinek wrote:
> Hi!
>
> This patch is an attempt to fix various signed integer overflows,
> invalid shifts and loads of uninialized bool value.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
Ok.
Thanks,
Richard.
> This is solely
Hi!
This patch is an attempt to fix various signed integer overflows,
invalid shifts and loads of uninialized bool value.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
This is solely from gcc build, make check has other issues too, but I'd
prefer to do it incrementally, be
On Thu, Dec 19, 2013 at 12:38:49PM +0100, Steven Bosscher wrote:
> >> Why not use active_insn_p instead of hand-checks for USE and CLOBBER insns?
> >
> > Because it brings in the JUMP_TABLE_DATA mess into the picture?
>
> Not as long as you look only between BB_HEAD and BB_END
> (JUMP_TABLE_DATA o
Computed goto duplication needs to fixup partition boundaries if it
performed any block duplication.
Bootstrapped and tested on x86_64-unknown-linux-gnu. Ok for trunk?
2013-12-19 Teresa Johnson
PR gcov-profile/59542
* bb-reorder.c (duplicate_computed_gotos): Invoke fixup_parti
Aldy Hernandez wrote:
>
>>> I'm still unsure whether the IPA inliner (not the early inliner)
>will add
>>> other nested transactions, so we may have to do everything in
>.tmmark and
>>> handle the dual code paths :(. Either way, this is a start.
>>
>> Sure it will. At least with cross-unit inlin
On 06/12/13 17:19, Kyrill Tkachov wrote:
Hi all,
Following the implementation of the Crypto intrinsics I posted earlier this
week, this patch implements the vceq_p64 and vtst_p64 intrinsics that operate on
the new poly64_t type. They do not have a regular form and can thus not be
autogenerated f
Hi Jakub,
Attached, please find a fixed patch. I have answered your questions
below. Is this OK for trunk?
Here are the ChangeLog entries:
Gcc/cp/ChangeLog
2013-12-19 Balaji V. Iyer
* parser.c (cp_parser_direct_declarator): When Cilk Plus is enabled
see if there is an
On Thu, 19 Dec 2013, H.J. Lu wrote:
> Here is the updated patch. OK to install?
OK.
--
Joseph S. Myers
jos...@codesourcery.com
Ping.
Thanks,
Kyrill
On 06/12/13 17:19, Kyrill Tkachov wrote:
Hi all,
Following the implementation of the Crypto intrinsics I posted earlier this
week, this patch implements the vceq_p64 and vtst_p64 intrinsics that operate on
the new poly64_t type. They do not have a regular form and can thus
On 18/12/13 15:32, Ramana Radhakrishnan wrote:
On Tue, Dec 3, 2013 at 1:46 PM, Kyrill Tkachov wrote:
Ping?
http://gcc.gnu.org/ml/gcc-patches/2013-11/msg02351.html
Thanks,
Kyrill
Ok if no objections in 24 hours.
Thanks Ramana, I've committed it as r206128 together with this obvious change
t
On Thu, Dec 19, 2013 at 8:13 AM, Joseph S. Myers
wrote:
> On Wed, 18 Dec 2013, H.J. Lu wrote:
>
>> On Wed, Dec 18, 2013 at 4:13 PM, Joseph S. Myers
>> wrote:
>> > On Mon, 2 Dec 2013, H.J. Lu wrote:
>> >
>> >> @@ -3952,6 +3955,10 @@ process_command (unsigned int
>> >> decoded_options_count,
>> >>
On 19 December 2013 16:13, Richard Earnshaw wrote:
>
> OK with that change.
Thanks.
The bugzilla entry is targeted at 4.8, but it is a latent problem
which affects 4.7 too.
Is it ok for 4.8, and should it be considered for 4.7?
On Thu, Dec 19, 2013 at 06:02:48PM +0100, Uros Bizjak wrote:
> IIRC, Intel was against using project names, and this "recommendation"
> was lifted some time ago. So if you think that these names are of some
> benefits to users, I'm all for longer, more descriptive names that are
> easy to remember.
On 12/18/2013, 5:03 PM, Richard Sandiford wrote:
Hi Vlad,
The initial LRA merge added the lra_in_progress check to this code
in simplify_subreg_regno:
/* Give the backend a chance to disallow the mode change. */
if (GET_MODE_CLASS (xmode) != MODE_COMPLEX_INT
&& GET_MODE_CLASS (xmo
On Thu, Dec 19, 2013 at 5:55 PM, H.J. Lu wrote:
> >> Just say Intel Broadwell CPU.
> > Done. Other options report instruction sets, so i left them.
> >
> > OK for trunk?
> >
> > 2013-12-19 Tocar Ilya
> >
> > * config.gcc: Support march=broadwell.
> >
On Wed, Dec 18, 2013 at 1:46 PM, Yvan Roux wrote:
> Hi,
>
> this patch from Vladimir fixes an ICE when compiling newlib in Thumb1.
> It returns NO_REGS in THUMB_SECONDARY_OUTPUT_RELOAD_CLASS, the same
> way we did for THUMB_SECONDARY_INPUT_RELOAD_CLASS.
This is OK if there are no regressions for
I'm still unsure whether the IPA inliner (not the early inliner) will add
other nested transactions, so we may have to do everything in .tmmark and
handle the dual code paths :(. Either way, this is a start.
Sure it will. At least with cross-unit inlining with LTO. You can of
course simply
On 19/12/13 16:42, Eric Botcazou wrote:
>> This generates:
>>
>> sub sp, sp, #n
>> str ip, [sp]
>>
>> which can be done in one instruction, vis:
>>
>> str ip, [sp, #-n]!
>>
>> Very similar code to do this essentially already exists a few lines
>> earlier (in the args_to_p
On Thu, Dec 19, 2013 at 8:53 AM, Uros Bizjak wrote:
> On Thu, Dec 19, 2013 at 5:50 PM, H.J. Lu wrote:
>
>> Just say Intel Broadwell CPU.
> Done. Other options report instruction sets, so i left them.
>
> OK for trunk?
>
> 2013-12-19 Tocar Ilya
>
>
On Thu, Dec 19, 2013 at 5:50 PM, H.J. Lu wrote:
>>> >> Just say Intel Broadwell CPU.
>>> > Done. Other options report instruction sets, so i left them.
>>> >
>>> > OK for trunk?
>>> >
>>> > 2013-12-19 Tocar Ilya
>>> >
>>> > * config.gcc: Support march=broadwell.
>>> > * config/
On 12/19/13 09:42, Jakub Jelinek wrote:
On Mon, Dec 16, 2013 at 01:55:50PM -0700, Jeff Law wrote:
On 12/16/13 11:43, Jakub Jelinek wrote:
On Mon, Dec 16, 2013 at 07:40:16PM +0100, Jakub Jelinek wrote:
It can be the last thing, sure. I think the still unimplemented and
potentially useful are t
On Thu, Dec 19, 2013 at 8:45 AM, Jakub Jelinek wrote:
> On Thu, Dec 19, 2013 at 05:41:26PM +0100, Uros Bizjak wrote:
>> >> Just say Intel Broadwell CPU.
>> > Done. Other options report instruction sets, so i left them.
>> >
>> > OK for trunk?
>> >
>> > 2013-12-19 Tocar Ilya
>> >
>> > *
Hi!
Ping.
On Tue, 10 Dec 2013 13:53:39 +0100, I wrote:
> At the end of this email you can find the patch that I'd like to apply to
> gomp-4_0-branch for OpenACC structured blocks, after the following two
> have been approved:
> On Fri, 06 Dec 2013 19:33:35 +0100, I wrote:
> > On Fri, 15 Nov 2013
On Thu, Dec 19, 2013 at 5:45 PM, Jakub Jelinek wrote:
> On Thu, Dec 19, 2013 at 05:41:26PM +0100, Uros Bizjak wrote:
>> >> Just say Intel Broadwell CPU.
>> > Done. Other options report instruction sets, so i left them.
>> >
>> > OK for trunk?
>> >
>> > 2013-12-19 Tocar Ilya
>> >
>> > *
> This generates:
>
> sub sp, sp, #n
> str ip, [sp]
>
> which can be done in one instruction, vis:
>
> str ip, [sp, #-n]!
>
> Very similar code to do this essentially already exists a few lines
> earlier (in the args_to_push == 0 case), but needs tweaking to use
>
On Thu, Dec 19, 2013 at 05:41:26PM +0100, Uros Bizjak wrote:
> >> Just say Intel Broadwell CPU.
> > Done. Other options report instruction sets, so i left them.
> >
> > OK for trunk?
> >
> > 2013-12-19 Tocar Ilya
> >
> > * config.gcc: Support march=broadwell.
> > * config/i386/dr
Hi!
Ping.
On Fri, 13 Dec 2013 11:13:03 +0100, I wrote:
> On Thu, 5 Sep 2013 18:11:05 +0200, Jakub Jelinek wrote:
> > 4) the reference testcase showed a problem with fold_stmt calls
> > we do very early, during gimplification, because for TREE_READONLY
> > vars with DECL_INITIAL fold_stmt can rep
On Mon, Dec 16, 2013 at 01:55:50PM -0700, Jeff Law wrote:
> On 12/16/13 11:43, Jakub Jelinek wrote:
> >On Mon, Dec 16, 2013 at 07:40:16PM +0100, Jakub Jelinek wrote:
> >>It can be the last thing, sure. I think the still unimplemented and
> >>potentially useful are the floating point overflow sanit
On Thu, Dec 19, 2013 at 4:35 PM, Ilya Tocar wrote:
>> > Why not -march=broadwell instead?
>> >
>>
>> If people don't mind long names, "broadwell" works for me.
>
> Done.
>
>> > * config/i386/driver-i386.c (host_detect_local_cpu): Detect broadwell.
>
>>^Capital B
On 19/12/13 10:35, Jakub Jelinek wrote:
On Thu, Dec 19, 2013 at 10:33:45AM +, Kyrill Tkachov wrote:
The recently added c-c++-common/cilk-plus/SE/ef_error.c test needs
an effective target check for fopenmp, otherwise it will fail to
compile on targets that don't support openmp, for example th
On Thu, Dec 19, 2013 at 04:33:25PM +, Kyrill Tkachov wrote:
> Thanks for the hint, it now passes on bare metal arm.
> Patch attached. Ok for trunk?
Sure.
>
> Kyrill
>
> 2013-12-19 Kyrylo Tkachov
>
> * c-c++-common/cilk-plus/SE/ef_error.c: Use -fopen-simd.
> --- a/gcc/testsuite/c-c++
On Wed, Dec 18, 2013 at 1:39 PM, Jan Hubicka wrote:
>> > OK, so the explanation is not as simple as claim that non-POD types
>> > needs to be constructed or copied by constructor and C++ FE always
>> > generate an explicit vtbl store?
>>
>> No as optimizers may combine stores for example.
>
> Yep,
On Thu, Dec 19, 2013 at 5:04 PM, Aldy Hernandez wrote:
> As discussed in the PR, we already remove nested transactions in the tmlower
> stage, but inlining may add more nested transactions later.
>
> The problem with removing these nested transactions after proper IPA, is
> that we'd either have t
On 19/12/13 15:38, Charles Baylis wrote:
> On Tue, Nov 26, 2013 at 10:25:50AM +, Richard Earnshaw wrote:
>> I've just spotted another problem (that was always there):
>>> @@ -42,15 +42,15 @@
>>>
>>> (define_insn "*thumb_ldm4_ia"
>>>[(match_parallel 0 "load_multiple_operation"
>>> -[(
On Wed, 18 Dec 2013, H.J. Lu wrote:
> On Wed, Dec 18, 2013 at 4:13 PM, Joseph S. Myers
> wrote:
> > On Mon, 2 Dec 2013, H.J. Lu wrote:
> >
> >> @@ -3952,6 +3955,10 @@ process_command (unsigned int decoded_options_count,
> >>free (fname);
> >> continue;
> >> }
> >> +
As discussed in the PR, we already remove nested transactions in the
tmlower stage, but inlining may add more nested transactions later.
The problem with removing these nested transactions after proper IPA, is
that we'd either have to add another IPA pass later or remove the
problematic transa
Hi,
The gcc.dg/long-long-compare-1.c test case was using -mcbranchdi for
sh4-*-* targets. The option has been deprecated in 4.9 and now outputs
a warning which causes the test case to fail.
Committed as obvious as rev 206121.
Cheers,
Oleg
testsuite/ChangeLog:
* gcc.dg/long-long-compare-
On 02/12/13 10:11, Eric Botcazou wrote:
>> My apologies for taking so long to look at this.
>
> No problem, all the more so that...
>
>>> 2013-09-05 Eric Botcazou
>>>
>>> * config/arm/arm.c (arm_expand_prologue): In a nested APCS frame with
>>> arguments to push onto the stack and no v
> > Why not -march=broadwell instead?
> >
>
> If people don't mind long names, "broadwell" works for me.
Done.
> > * config/i386/driver-i386.c (host_detect_local_cpu): Detect broadwell.
>^Capital B.
Thanks, fixed.
> Just say Intel Broadwell CPU.
Done. Other
On Thu, 2013-12-19 at 01:19 +, Jonathan Wakely wrote:
> On 19 December 2013 00:10, Oleg Endo wrote:
> > Hello,
> >
> > When writing code such as
> > ...
> > throw std::logic_error ("cold coffee");
> > ...
> > currently the construction of std::string happens in the code that
> > throws the ex
On 04/12/13 15:14, Kyrill Tkachov wrote:
> Hi all,
>
> This is the final patch in the series, adding the documentation for the
> intrinsics. Most of it is autogenerated from neon-docgen.ml and the ones that
> are not are added explicitly in neon-docgen.ml so that they appear in the
> generated
On 04/12/13 15:14, Kyrill Tkachov wrote:
> Hi all,
>
> This patch adds the testsuite for the crypto intrinsics.
>
> A new effective target check is added as usual and an option-adding procedure
> as
> well.
> Most of the tests here are autogenerated using the neon-testgen.ml script and
> are p
On 04/12/13 15:14, Kyrill Tkachov wrote:
> Hi all,
>
> These are the changes to the arm backend that add support for the intrinsics.
> neon.ml is modified to support the new poly64_t and poly128_t types and all
> their associated intrinsics.
>
> Technically, arm_neon.h is generated from the ML s
The patch is OK. Feel free to submit now, if you want.
Thanks. Done in r206116.
-Y
On Thu, Dec 19, 2013 at 9:33 AM, Yury Gribov wrote:
> Frankly in my experience Perl with `use warnings' and `use strict' isn't
> that bad. We could just as well massage existing script.
I suppose.
> Got it. Attached new version of script and ChangeLog entry. Will submit
> tomorrow if noone obje
On 12/19/2013 05:47 PM, Diego Novillo wrote:
The patch is fine (some tweaks below).
If someone volunteers to re-write it in Python,
I think it would make it easier to keep extending.
Frankly in my experience Perl with `use warnings' and `use strict' isn't
that bad. We could just as well massag
On Thu, Dec 19, 2013 at 8:04 AM, Yury Gribov wrote:
> On 12/19/2013 04:17 PM, Yury Gribov wrote:
>>> In my experience mklog is pretty much useless, e.g. if you
>>> add a new function, it will list the previous function as being modified
>>> rather than the new one, etc.
>>
>> In my experience it p
On Thu, Dec 19, 2013 at 5:18 AM, Jakub Jelinek wrote:
> On Thu, Dec 19, 2013 at 05:11:07PM +0400, Ilya Tocar wrote:
>> This patch adds march for broadwell cpu.
>> -march=bdw is the same as -march=core-avx2 but with support for rdseed,
>> adcx, prefetchw. OK for trunk?
>
> Why not -march=broadwell
On Thu, Dec 19, 2013 at 05:11:07PM +0400, Ilya Tocar wrote:
> This patch adds march for broadwell cpu.
> -march=bdw is the same as -march=core-avx2 but with support for rdseed,
> adcx, prefetchw. OK for trunk?
Why not -march=broadwell instead?
Jakub
On Thu, Dec 19, 2013 at 5:11 AM, Ilya Tocar wrote:
> Hi,
> This patch adds march for broadwell cpu.
> -march=bdw is the same as -march=core-avx2 but with support for rdseed,
> adcx, prefetchw. OK for trunk?
>
> Thanks.
>
> 2013-12-19 Tocar Ilya
>
> * config.gcc: Support march=bdw.
>
Hi,
This patch adds march for broadwell cpu.
-march=bdw is the same as -march=core-avx2 but with support for rdseed,
adcx, prefetchw. OK for trunk?
Thanks.
2013-12-19 Tocar Ilya
* config.gcc: Support march=bdw.
* config/i386/driver-i386.c (host_detect_local_cpu): Detect broa
On 12/19/2013 04:17 PM, Yury Gribov wrote:
>> In my experience mklog is pretty much useless, e.g. if you
>> add a new function, it will list the previous function as being modified
>> rather than the new one, etc.
>
> In my experience it prints both the old and the new one. If that's a
> problem w
Hi,
On Thu, 19 Dec 2013 11:55:03, Eric Botcazou wrote:
>
>> In general I like the comment, and I am open for other suggestions how
>> to call the parameter.
>
> I think that using EXPAND in the parameter's name is confusing because it
> needs to be distinguished from MODIFIER and its enumeration
On Thu, Dec 19, 2013 at 04:02:47PM +0400, Maxim Ostapenko wrote:
> Sorry, ChangeLog and patch, of course.
> 2013-12-19 Max Ostapenko
>
> * cfgexpand.c (expand_stack_vars): Optionally disable asan stack
> protection.
Too long lines in ChangeLog, wrap to 80 columns.
> (expand_used
In my experience mklog is pretty much useless, e.g. if you
add a new function, it will list the previous function as being modified
rather than the new one, etc.
In my experience it prints both the old and the new one. If that's a
problem we could probably fix it (I mean I can volunteer).
Her
On Thu, Dec 19, 2013 at 12:51:43PM +0100, Thomas Schwinge wrote:
> OK for gomp-4_0-branch, and trunk (without the first hunk, obviously)?
>
> commit 1f4dbb1842804b39c3b7ac1e80783734516dc965
> Author: Thomas Schwinge
> Date: Thu Dec 19 12:41:21 2013 +0100
>
> Add clobber for object, after l
Sorry, ChangeLog and patch, of course.
-Maxim.
2013-12-19 Max Ostapenko
* cfgexpand.c (expand_stack_vars): Optionally disable asan stack protection.
(expand_used_vars): Likewise.
(partition_stack_vars): Likewise.
* asan.c (asan_emit_stack_protection): Optionally disable after return stack
2013-12-18 Max Ostapenko
* gcc/asan.c (asan_emit_stack_protection): Optionally disable
stack protection.
(instrument_derefs): Optionally disable memory access
instrumentation.
(instrument_mem_region_access): Likewise.
(instrument_strlen_call): Likewise.
(asan_finish_file)
Hi!
On Wed, 18 Dec 2013 22:46:48 +0100, Jakub Jelinek wrote:
> On Wed, Dec 18, 2013 at 09:03:40PM +0100, Thomas Schwinge wrote:
> > On Mon, 16 Dec 2013 16:38:18 +0100, Jakub Jelinek wrote:
> > > The reason for 3 separate arrays is that some of the values
> > > are always variable, some are somet
On Thu, Dec 19, 2013 at 9:02 AM, Jakub Jelinek wrote:
> On Wed, Dec 18, 2013 at 11:21:52PM +0100, Steven Bosscher wrote:
>> On Wednesday, December 18, 2013, Jakub Jelinek wrote:
>> > As discussed in the PR, this testcase ICEs on arm, because ifcvt
>> > is relying on active instruction counts from v
> In general I like the comment, and I am open for other suggestions how
> to call the parameter.
I think that using EXPAND in the parameter's name is confusing because it
needs to be distinguished from MODIFIER and its enumeration type. And since
it would be true only after calling get_inner_r
On 18/12/13 12:39, James Greenhalgh wrote:
>
> Hi,
>
> Recently it was pointed out that GCC 4.8 can generate instruction
> aliases which are no longer mentioned in the AArch64 portion of the
> ARMv8 architecture reference manual.
>
> It turns out that a series of patches to GCC 4.9 actually
> co
On Thu, Dec 19, 2013 at 02:28:11PM +0400, Yury Gribov wrote:
> > No gcc/ prefixes in ChangeLog entries.
>
> Should we update contrib/mklog then?
In my experience mklog is pretty much useless, e.g. if you
add a new function, it will list the previous function as being modified
rather than the new
On Thu, 19 Dec 2013 20:41:43, Alan Modra wrote:
>
> On Wed, Dec 18, 2013 at 02:32:01PM +0100, Bernd Edlinger wrote:
>> I wonder if the GMPINC="" is still necessary, as the actual host g++
>> invocation also has GMP-directories
>> but does not use them because of the -DGENERATOR_FILE.
>
> The issue
On Thu, Dec 19, 2013 at 10:33:45AM +, Kyrill Tkachov wrote:
> The recently added c-c++-common/cilk-plus/SE/ef_error.c test needs
> an effective target check for fopenmp, otherwise it will fail to
> compile on targets that don't support openmp, for example the bare
> metal arm-none-eabi.
Or jus
Hi!
On Thu, Dec 19, 2013 at 10:13:17AM +, Gopalasubramanian, Ganesh wrote:
> @@ -30044,25 +30053,49 @@
> break;
> case PROCESSOR_COREI7_AVX:
>arg_str = "corei7-avx";
> - priority = P_PROC_SSE4_2;
> + priority = P_PROC_AVX;
>
Hi all,
The recently added c-c++-common/cilk-plus/SE/ef_error.c test needs an effective
target check for fopenmp, otherwise it will fail to compile on targets that
don't support openmp, for example the bare metal arm-none-eabi.
I've committed the attached patch to fix that as r206109.
Thanks
> No gcc/ prefixes in ChangeLog entries.
Should we update contrib/mklog then?
-Y
On Thursday 19 December 2013, Gopalasubramanian, Ganesh wrote:
> > Sorry, I must have been looking at an older version, but as I said I
> > already did enable it in the latest patch. (see
> > http://gcc.gnu.org/ml/gcc-patches/2013-12/msg01577.html )
>
> Sorry for causing another revision but we wo
On Thu, Dec 19, 2013 at 11:01 AM, Gopalasubramanian, Ganesh
wrote:
>> Please provide updated ChangeLog.
>
> --- gcc/ChangeLog (revision 206106)
> +++ gcc/ChangeLog (working copy)
> @@ -1,3 +1,14 @@
> +2013-12-19 Ganesh Gopalasubramanian
> +
> + * config/i386/i386.c: Include cf
> Sorry, I must have been looking at an older version, but as I said I already
> did enable it in the latest patch. (see
> http://gcc.gnu.org/ml/gcc-patches/2013-12/msg01577.html )
Sorry for causing another revision but we would like to stick with "btver1" and
"btver2" rather than "BOBCAT" or "
On Thu, Dec 19, 2013 at 02:12:44PM +0400, Konstantin Serebryany wrote:
> Please review a small patch (backport from upstream) for libsanitizer.
> We are having difficulties on our side and (likely) won't make a full
> libsanitizer merge until early Jan.
Ok.
> +2013-12-19 Kostya Serebryany
> +
Hi,
Please review a small patch (backport from upstream) for libsanitizer.
We are having difficulties on our side and (likely) won't make a full
libsanitizer merge until early Jan.
Index: libsanitizer/ChangeLog
===
--- libsanitizer/C
On Wed, Dec 18, 2013 at 02:32:01PM +0100, Bernd Edlinger wrote:
> I wonder if the GMPINC="" is still necessary, as the actual host g++
> invocation also has GMP-directories
> but does not use them because of the -DGENERATOR_FILE.
The issue isn't finding gmp.h, it's finding other host headers you
> Please provide updated ChangeLog.
--- gcc/ChangeLog (revision 206106)
+++ gcc/ChangeLog (working copy)
@@ -1,3 +1,14 @@
+2013-12-19 Ganesh Gopalasubramanian
+
+ * config/i386/i386.c: Include cfgloop.h.
+ (ix86_loop_memcount): New function.
+ (ix86_loop_unroll_ad
On Thu, 19 Dec 2013, Sharad Singhai wrote:
> I am really sorry, I forgot to add gcc internal documentation for dump
> functions. Sorry about a very long delay.
>
> The attached patch adds some documentation about how to use the new
> dump infrastructure. This doc is attached to 'passes' documenta
On Thursday 19 December 2013, Gopalasubramanian, Ganesh wrote:
> > Yes, I changed that in the last patch, though I consider it momentarily
> > problematic because you do not yet enable AVX with march=btver2 (AVX
> > versions would currently be better than btver2 versions for a btver2
> > arch), but
I am really sorry, I forgot to add gcc internal documentation for dump
functions. Sorry about a very long delay.
The attached patch adds some documentation about how to use the new
dump infrastructure. This doc is attached to 'passes' documentation
node as that seemed the most logical place. Also,
tree.h has:
/* In a RECORD_TYPE, UNION_TYPE, QUAL_UNION_TYPE or ARRAY_TYPE, it means
the type has BLKmode only because it lacks the alignment required for
its size. */
#define TYPE_NO_FORCE_BLK(NODE) \
(TYPE_CHECK (NODE)->type_common.no_force_blk_flag)
and it's the only usage of the flag
2013/12/17 Monk Chiang :
>
> I add comment to describe why I adding TARGET_CPU_DEFAULT,
> and fix typo in ChangeLog fle.
>
> Thank you for your suggestion.
>
> Index: ChangeLog
> ===
> --- ChangeLog (revision 206039)
> +++ ChangeLog
Hi,
On Mon, 16 Dec 2013 17:22:59, Eric Botcazou wrote:
>
>> That sounds less conservative though. Anyway, that was just some thought
>> to fix the eventual fallout of making more types have BLKmode.
>
> In the end I was too optimistic... Testing a revised patch on x86 revealed a
> obscure case wh
> Because it brings in the JUMP_TABLE_DATA mess into the picture? Some of the
> places already guard it with INSN_P and similar checks and do more things
> than just counting the insns under those conditionals, so in other places
> one can't just use say prev_active_insn or next_active_insn anyway
On Wed, Dec 18, 2013 at 11:21:52PM +0100, Steven Bosscher wrote:
> On Wednesday, December 18, 2013, Jakub Jelinek wrote:
> > As discussed in the PR, this testcase ICEs on arm, because ifcvt
> > is relying on active instruction counts from various routines
> > (count_bb_insns, flow_find_cross_jump a
97 matches
Mail list logo
