> I pondered changing the condition for swapping the insn order, but it
> didn't seem worth it. I doubt we see many 3->2 combinations where I3 is
> a JUMP_INSN, the result turns into two simple sets and the insn swapping
> code you wrote decides it needs to swap the insns.
I didn't actually write
Hi!
On Tue, Feb 11, 2014 at 01:13:09AM +, rth at gcc dot gnu.org wrote:
> --- Comment #9 from Richard Henderson ---
> Author: rth
> Date: Tue Feb 11 01:12:38 2014
> New Revision: 207677
>
> URL: http://gcc.gnu.org/viewcvs?rev=207677&root=gcc&view=rev
> Log:
> PR target/59927
>
> * c
Hi all,
In this PR the 128-bit load-duplicate intrinsics in neon.exp ICE on big-endian
with an unrecognisable insn error:
neon-vld1_dupQ.c:24:1: error: unrecognizable insn:
(insn 94 93 31 (set (subreg:DI (reg:V2DI 95 d16 [orig:137 D.14400 ] [137]) 0)
(subreg:DI (reg:V2DI 95 d16 [orig:1
Richard Biener writes:
> On Sun, Feb 9, 2014 at 9:30 PM, Robert Dewar wrote:
>> On 2/9/2014 3:23 PM, Richard Sandiford wrote:
can't we just reword the one warning where there is an ambiguity to
avoid the confusion, rather than creating such an earthquake, which
as Arno says, really
Hi,
this is an interesting regression from GCC 4.5 present on all active branches
and triggered by recent SRA improvements. For the attached testcase, we have
an unchecked conversion of a 3-byte slice of an array of 4 bytes to a record
type containing a 3-byte bit-field; an unchecked conversio
On 02/09/2014 09:00 PM, Richard Sandiford wrote:
+ return xstrdup (_("warning enabled by default"));
I think this is still wrong because this message really means, "this
warning cannot be controlled with a warning flag, but it can likely be
switched off by other means". I don't think
On 2/11/2014 4:45 AM, Richard Sandiford wrote:
OK, this version drops the "[enabled by default]" altogether.
Tested as before. OK to install?
Still a huge earthquake in terms of affecting test suites and
baselines of many users. is it really worth it? In the case of
GNAT we have only recently
This fixes the ICE seen in PR60060 which stems from us asking to
output debug-info for a function-scope global twice - once via
emitting the function and its BLOCK-associated vars and once
via the debug-hook through lto_write_globals ->
emit_debug_global_declarations.
The list of "global" variab
On Mon, Feb 10, 2014 at 5:35 PM, Jeff Law wrote:
> On 02/07/14 02:17, Richard Biener wrote:
>>>
>>> +2014-02-05 Jeff Law
>>> +
>>> + PR middle-end/54041
>>> + * expr.c (expand_expr_addr_1): Handle expand_expr returning an
>>> + object with an undesirable mode.
>>> +
>>> 2014
On Mon, Feb 10, 2014 at 9:38 PM, Richard Sandiford
wrote:
> Not 100% sure whether this is the preferred fix, but gcc.dg/vect/pr56787.c
> has lots of float * parameters that point who-knows-where and so is only
> vectorised if the target supports misaligned vector accesses:
>
> void
> foo (unsigned
Hi!
Ping again for test case and rather trivial patch to cure a GCC trunk ICE
in the Cilk Plus structured block checker if both -fcilkplus and -fopenmp
are specified.
Also, I'd still like to know whether the »Generalize diagnose_omp_blocks'
structured block logic« patch is fine, too? (If that on
Robert Dewar writes:
> On 2/11/2014 4:45 AM, Richard Sandiford wrote:
>> OK, this version drops the "[enabled by default]" altogether.
>> Tested as before. OK to install?
>
> Still a huge earthquake in terms of affecting test suites and
> baselines of many users. is it really worth it? In the cas
As described in the PR, a few libgomp testcases FAIL on Solaris 9/x86
because the SSE insns assume 16-byte stack alignment, while Solaris 9,
unlike Solaris 10, only guarantees the 4-byte alignment prescribed by
the i386 psABI. This can be fixed, at a slight performance penalty and
code size increa
On Tue, 11 Feb 2014, Evgeny Stupachenko wrote:
> Hi,
>
> The patch gives an expected 3 times gain for the test case in the PR52252
> (and even 6 times for AVX2).
> It passes make check and bootstrap on x86.
> spec2000/spec2006 got no regressions/gains on x86.
>
> Is this patch ok?
I've worked o
Hi!
On Tue, 11 Feb 2014 13:43:46 +0100, I wrote:
> Ping again for test case and rather trivial patch to cure a GCC trunk ICE
> in the Cilk Plus structured block checker if both -fcilkplus and -fopenmp
> are specified.
Jakub asked me to »please repost just the (hopefully small) trunk patch
alone«,
On Tue, Feb 11, 2014 at 11:40 AM, Eric Botcazou wrote:
> Hi,
>
> this is an interesting regression from GCC 4.5 present on all active branches
> and triggered by recent SRA improvements. For the attached testcase, we have
> an unchecked conversion of a 3-byte slice of an array of 4 bytes to a rec
On Tue, Feb 11, 2014 at 1:48 PM, Richard Sandiford
wrote:
> Robert Dewar writes:
>> On 2/11/2014 4:45 AM, Richard Sandiford wrote:
>>> OK, this version drops the "[enabled by default]" altogether.
>>> Tested as before. OK to install?
>>
>> Still a huge earthquake in terms of affecting test suite
On Tue, Feb 11, 2014 at 02:17:04PM +0100, Richard Biener wrote:
> > this is an interesting regression from GCC 4.5 present on all active
> > branches
> > and triggered by recent SRA improvements. For the attached testcase, we
> > have
> > an unchecked conversion of a 3-byte slice of an array of
On 2/11/2014 7:48 AM, Richard Sandiford wrote:
The patch deliberately didn't affect Ada's diagnostic routines given
your comments from the first round. Calling this a "huge earthquake"
for other languages seems like a gross overstatement.
Actually it's much less of an impact for Ada for two r
On Tue, Feb 11, 2014 at 2:22 PM, Jakub Jelinek wrote:
> On Tue, Feb 11, 2014 at 02:17:04PM +0100, Richard Biener wrote:
>> > this is an interesting regression from GCC 4.5 present on all active
>> > branches
>> > and triggered by recent SRA improvements. For the attached testcase, we
>> > have
Missed patch attached in plain-text.
I have copyright assignment on file with the FSF covering work on GCC.
Load/stores groups of length 3 is the most frequent non-power-of-2
case. It is used in RGB image processing (like test case in PR52252).
For sure we can extend the patch to length 5 and mor
Hi,
the following patch adds missing handling of error_mark_node result of
fname_decl within finish_fname.
ChangeLog
2014-02-11 Kai Tietz
PR c++/58835
* semantics.c (finish_fname): Handle error_mark_node.
Regression tested for x86_64-unknown-linux-gnu, i686-w64-mingw32. Ok
On Tue, Feb 11, 2014 at 02:15:00PM +0100, Thomas Schwinge wrote:
> Jakub asked me to »please repost just the (hopefully small) trunk patch
> alone«, so here we go:
>
> Consider the following code:
>
> void baz()
> {
> bad1:
> #pragma omp parallel
> goto bad1;
> }
>
Robert Dewar writes:
>> I don't think gcc, g++, gfortran, etc, have ever made a commitment
>> to producing textually identical warnings and errors for given inputs
>> across different releases. It seems ridiculous to require that,
>> especially if it stands in the way of improving the diagnostics
On 6 February 2014 22:51, Michael Hudson-Doyle
wrote:
> diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
> index 16c51a8..958c667 100644
> --- a/gcc/config/aarch64/aarch64.c
> +++ b/gcc/config/aarch64/aarch64.c
> @@ -1187,14 +1187,10 @@ aarch64_pass_by_reference (cumulativ
On Tue, Feb 11, 2014 at 02:51:08PM +, Marcus Shawcroft wrote:
> On 6 February 2014 22:51, Michael Hudson-Doyle
> wrote:
>
> > diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
> > index 16c51a8..958c667 100644
> > --- a/gcc/config/aarch64/aarch64.c
> > +++ b/gcc/config/
On 11/02/14 09:38, Kyrill Tkachov wrote:
Hi all,
In this PR the 128-bit load-duplicate intrinsics in neon.exp ICE on big-endian
with an unrecognisable insn error:
neon-vld1_dupQ.c:24:1: error: unrecognizable insn:
(insn 94 93 31 (set (subreg:DI (reg:V2DI 95 d16 [orig:137 D.14400 ] [137]) 0)
On 10 February 2014 09:55, Marcus Shawcroft wrote:
> On 30 January 2014 13:48, Kyrill Tkachov wrote:
>> Hi all,
>>
>> This patch wires up the aarch64 backend to use the Cortex-A57 rtx costs
>> table that is proposed at
>> http://gcc.gnu.org/ml/gcc-patches/2014-01/msg01954.html
>
> OK if release m
On Mon, Feb 10, 2014 at 11:01 AM, Kyrill Tkachov wrote:
> Hi all,
>
> This patchlet adds the part numbers for the Cortex-A53 and A57 cores so that
> they can be detected when parsing /proc/cpuinfo on AArch32 Linux systems.
> This will allow the -mcpu=native machinery to detect those cores.
>
> Tes
On Mon, Feb 3, 2014 at 3:56 PM, Renlin Li wrote:
> Hi all,
>
> This patch will ensure testsuite/gcc.target/arm/fixed_float_conversion.c is
> checked only when "-mfpu=vfp3 -mfloat-abi=softfp" is applicable for the
> target.
>
> Accordingly, two procs (check_effective_target_arm_vfp3_ok and
> add_op
On Tue, Feb 11, 2014 at 03:03:32PM +, Marcus Shawcroft wrote:
> On 10 February 2014 09:55, Marcus Shawcroft
> wrote:
> > On 30 January 2014 13:48, Kyrill Tkachov wrote:
> >> Hi all,
> >>
> >> This patch wires up the aarch64 backend to use the Cortex-A57 rtx costs
> >> table that is proposed
On Tue, 11 Feb 2014, Evgeny Stupachenko wrote:
> Missed patch attached in plain-text.
>
> I have copyright assignment on file with the FSF covering work on GCC.
>
> Load/stores groups of length 3 is the most frequent non-power-of-2
> case. It is used in RGB image processing (like test case in PR
On 2/11/2014 9:36 AM, Richard Sandiford wrote:
I find it hard to believe that
significant numbers of users are not fixing the sources of those
warnings and are instead requiring every release of GCC to produce
warnings with a particular wording.
Good enough for me, I think it is OK to make th
On 11/02/14 15:11, Ramana Radhakrishnan wrote:
On Mon, Feb 3, 2014 at 3:56 PM, Renlin Li wrote:
Hi all,
This patch will ensure testsuite/gcc.target/arm/fixed_float_conversion.c is
checked only when "-mfpu=vfp3 -mfloat-abi=softfp" is applicable for the
target.
Accordingly, two procs (check_eff
On Fri, Jan 31, 2014 at 03:49:40PM +0100, Richard Biener wrote:
> On Fri, Jan 31, 2014 at 3:45 PM, FX wrote:
> >> I've just seen that an explicit --enable-multilib is a way to do that.
> >
> > Yes, I was writing that as a reply when I received your email. (Also, it's
> > written in the configure
Hi!
On Fri, 31 Jan 2014 15:16:07 +0400, Ilmir Usmanov wrote:
> OpenACC 1.0 support -- GENERIC nodes and gimplify stubs.
Thanks! This one is nearly ready for commit, and can then go in already,
while the Fortran front end patches are still being dicussed. :-)
Please merge »OpenACC 1.0 sup
Added install hook:
/opt/gjit/bin/gcc -g -O2 -Wall t.c -o test -I/opt/gjit/include
-lgccjit -L/opt/gjit/lib
Compiles the helloworld examples correctly and it runs instead of
pointing to my gcc build dir. Am working on getting more involved with
this and started:
https://github.com/redbrain/spy
Am 2014-02-11 15:36, schrieb Richard Sandiford:
I thought the trend these days was to move towards -Werror, so that for
many people the expected output is to get no warnings at all. And bear
in mind that the kind of warnings that are not under -W control tend to
be those that are so likely to be
> Hmm. The intent was of course to only allow truly no-op converts via
> VIEW_CONVERT_EXPR - that is, the size of the operand type and the
> result type should be the same. So, isn't SRA doing it wrong when
> creating the VIEW_CONVERT_EXPR of a 3-byte type to a 4-byte type?
That's debatable IMO
On Mon, Feb 10, 2014 at 11:48 PM, Wei Mi wrote:
> Here is the updated patch, which follow UD chain to determine whether
> iv.base is defined by __gcovx.xxx[] var. It is a lot simpler than
> adding a tree bit.
>
> regression test and previously failed benchmark in piii mode is ok.
> Other test is g
Hi!
As discussed in the PR, this patch adds VCE if types aren't compatible,
in order not to create invalid debug stmts.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2014-02-11 Richard Henderson
Jakub Jelinek
PR debug/59776
* tree-sra.c (l
On 02/11/2014 09:36 AM, Jakub Jelinek wrote:
> Hi!
>
> As discussed in the PR, this patch adds VCE if types aren't compatible,
> in order not to create invalid debug stmts.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
>
> 2014-02-11 Richard Henderson
> Ja
Hi!
Right now we spent several minutes in verify_tree. The problems I see
is that merge_tlist does the exact opposite of what should it be doing with
copy flag (most merge_tlist calls are with copy=0, thus that means mostly
unnecessary copying, but for the single one for SAVE_EXPR it actually
pro
On Mon, Feb 10, 2014 at 6:02 AM, Renlin Li wrote:
> On 03/02/14 15:56, Renlin Li wrote:
>>
>> Hi all,
>>
>> This patch will ensure testsuite/gcc.target/arm/fixed_float_conversion.c
>> is checked only when "-mfpu=vfp3 -mfloat-abi=softfp" is applicable for the
>> target.
>>
>> Accordingly, two procs
On Tue, Feb 11, 2014 at 9:46 AM, H.J. Lu wrote:
> On Mon, Feb 10, 2014 at 6:02 AM, Renlin Li wrote:
>> On 03/02/14 15:56, Renlin Li wrote:
>>>
>>> Hi all,
>>>
>>> This patch will ensure testsuite/gcc.target/arm/fixed_float_conversion.c
>>> is checked only when "-mfpu=vfp3 -mfloat-abi=softfp" is a
On 11/02/14 17:47, H.J. Lu wrote:
On Tue, Feb 11, 2014 at 9:46 AM, H.J. Lu wrote:
On Mon, Feb 10, 2014 at 6:02 AM, Renlin Li wrote:
On 03/02/14 15:56, Renlin Li wrote:
Hi all,
This patch will ensure testsuite/gcc.target/arm/fixed_float_conversion.c
is checked only when "-mfpu=vfp3 -mfloat-a
>
> This fixes the ICE seen in PR60060 which stems from us asking to
> output debug-info for a function-scope global twice - once via
> emitting the function and its BLOCK-associated vars and once
> via the debug-hook through lto_write_globals ->
> emit_debug_global_declarations.
>
> The list of
Committed to branch dmalcolm/jit:
gcc/jit/
* internal-api.c (gcc::jit::recording::context::add_error_va): If
GCC_JIT_STR_OPTION_PROGNAME is NULL, use "libgccjit.so", as per
the comment in libgccjit.h
(gcc::jit::recording::label::replay_into): When reporting on an
>> +/* Return true if the use is defined by a gcov counter var.
>> + It is used to check if an iv candidate is generated for
>> + profiling. For profile generated ssa name, we should not
>> + use it as IV because gcov counter may have data-race for
>> + multithread program, it could involve
* (generic.texi): Fix typo
Index: generic.texi
===
--- generic.texi(revision 207627)
+++ generic.texi(working copy)
@@ -53,7 +53,7 @@ seems inelegant.
@node Deficiencies
@section Deficiencies
-There are many places in which
ok for google branch for now. Please resubmit to trunk and backport
the trunk version if needed.
thanks,
David
On Tue, Feb 11, 2014 at 10:29 AM, Wei Mi wrote:
>>> +/* Return true if the use is defined by a gcov counter var.
>>> + It is used to check if an iv candidate is generated for
>>> +
On Wed, Feb 12, 2014 at 12:00:30AM +0530, Prathamesh Kulkarni wrote:
> * (generic.texi): Fix typo
>
> Index: generic.texi
> ===
> --- generic.texi(revision 207627)
> +++ generic.texi(working copy)
> @@ -53,7 +53,7 @@ seems ine
Hello!
Now that Richard fixed ms_abi limitation w.r.t.
accumulate-outgoing-args, we can revert PR testsuite/58630 fix on
mainline. On mainline, ms_abi works without problems with and without
this option.
2014-02-11 Uros Bizjak
PR target/59927
Revert
2013-12-15 Uros Bizjak
On Tue, Feb 11, 2014 at 5:20 AM, Richard Biener
wrote:
> On Tue, Feb 11, 2014 at 1:48 PM, Richard Sandiford
> wrote:
>> Robert Dewar writes:
>>> On 2/11/2014 4:45 AM, Richard Sandiford wrote:
OK, this version drops the "[enabled by default]" altogether.
Tested as before. OK to install
Hi,
HAVE_AS_GOTOFF_IN_DATA defines a 32-bit assembler feature, we need to
pass --32 to assembler. Otherwise, we get the wrong result on x86-64.
We already pass --32 to assembler on x86. It should be OK to do it
in configure. OK for trunk?
Thanks.
H.J.
---
2014-02-11 H.J. Lu
PR targ
Hi H.J.,
> HAVE_AS_GOTOFF_IN_DATA defines a 32-bit assembler feature, we need to
> pass --32 to assembler. Otherwise, we get the wrong result on x86-64.
> We already pass --32 to assembler on x86. It should be OK to do it
> in configure. OK for trunk?
This would break Solaris/x86 with as config
On Tue, Feb 11, 2014 at 8:28 PM, H.J. Lu wrote:
> HAVE_AS_GOTOFF_IN_DATA defines a 32-bit assembler feature, we need to
> pass --32 to assembler. Otherwise, we get the wrong result on x86-64.
> We already pass --32 to assembler on x86. It should be OK to do it
> in configure. OK for trunk?
Unf
This is one more version of the patch to fix the PR59535
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59535
Here are the results of applying the patch:
ThumbThumb2
reload 2626334 2400154
lra (before the patch)
On Tue, Feb 11, 2014 at 11:40 AM, Rainer Orth
wrote:
> Hi H.J.,
>
>> HAVE_AS_GOTOFF_IN_DATA defines a 32-bit assembler feature, we need to
>> pass --32 to assembler. Otherwise, we get the wrong result on x86-64.
>> We already pass --32 to assembler on x86. It should be OK to do it
>> in configure
On 02/11/14 02:06, Eric Botcazou wrote:
I pondered changing the condition for swapping the insn order, but it
didn't seem worth it. I doubt we see many 3->2 combinations where I3 is
a JUMP_INSN, the result turns into two simple sets and the insn swapping
code you wrote decides it needs to swap t
[Re-send, since I never saw the original arrive on the list.]
After the first version passed Kai's testing, we chatted on IRC about
various other bits that might be relevant to the winx64 abi issues.
The conditional call to ix86_eax_live_at_start_p seemed to be harmless
either way, but confusing
"H.J. Lu" writes:
> On Tue, Feb 11, 2014 at 11:40 AM, Rainer Orth
> wrote:
>> Hi H.J.,
>>
>>> HAVE_AS_GOTOFF_IN_DATA defines a 32-bit assembler feature, we need to
>>> pass --32 to assembler. Otherwise, we get the wrong result on x86-64.
>>> We already pass --32 to assembler on x86. It should b
Hi!
Optional dummy arg support vars are often undefined in various paths,
while the predicated uninit analysis can sometimes avoid false positives,
sometimes it can't. So IMHO we should set TREE_NO_WARNING here, it is
already set on the other support vars like size.N, ubound.N, lbound.N, etc.
but
Committed to branch dmalcolm/jit:
gcc/testsuite/
* jit.dg/test-error-unplaced-label.c (verify_code): Update
expected error message to reflect commit
6cd4f82c5237cc328aea229cdaaa428ff09d6e98.
---
gcc/testsuite/ChangeLog.jit | 6 ++
gcc/testsuite/jit
On Tue, Feb 11, 2014 at 12:29 PM, Rainer Orth
wrote:
> "H.J. Lu" writes:
>
>> On Tue, Feb 11, 2014 at 11:40 AM, Rainer Orth
>> wrote:
>>> Hi H.J.,
>>>
HAVE_AS_GOTOFF_IN_DATA defines a 32-bit assembler feature, we need to
pass --32 to assembler. Otherwise, we get the wrong result on x86
Hi,
this is first part of fix for lto/59468 that is about ipa-devirt ICEs on
invalid C++ programs (violating ODR rule).
This patch hardens it wrt various low-level VTABLE corruptions - the case
virtual tables gets too small, their initalizer is missing or user decided to
rewrite the symbol by a di
On Tue, Feb 11, 2014 at 09:38:20PM +0100, Jakub Jelinek wrote:
>
> Optional dummy arg support vars are often undefined in various paths,
> while the predicated uninit analysis can sometimes avoid false positives,
> sometimes it can't. So IMHO we should set TREE_NO_WARNING here, it is
> already se
On Mon, Feb 10, 2014 at 8:14 PM, Michael Meissner
wrote:
> This patch fixes PR target/60137 that shows up when some vector types get
> allocated to GPR registers, and there wasn't a splitter for the type. It
> shows
> up when targetting ISA 2.07 (power8) when VSX is disabled but Altivec (VMX) is
On Mon, Feb 10, 2014 at 7:15 PM, Sriraman Tallam wrote:
> Hi Teresa,
>
>I have attached a patch to recognize and reorder split functions in
> the function reordering plugin. Please review.
>
> Thanks
> Sri
> Index: function_reordering_plugin/callgraph.c
> =
The following patch fixes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49008
This typo was not important as the code worked correctly in the most
cases as units required precence of only one another unit mostly.
Committed as rev. 207701.
2014-02-11 Vladimir Makarov
PR target/49
Committed to branch dmalcolm/jit:
gcc/jit/
* libgccjit.h (enum gcc_jit_types): Add GCC_JIT_TYPE_BOOL.
* internal-api.h (gcc::jit::recording::comparison::comparison): Use
GCC_JIT_TYPE_BOOL as the types of comparisons, rather than
GCC_JIT_TYPE_INT.
* interna
On Thu, Dec 19, 2013 at 10:19 PM, Teresa Johnson wrote:
> 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 re
On Tue, Feb 11, 2014 at 1:32 PM, Teresa Johnson wrote:
> On Mon, Feb 10, 2014 at 7:15 PM, Sriraman Tallam wrote:
>> Hi Teresa,
>>
>>I have attached a patch to recognize and reorder split functions in
>> the function reordering plugin. Please review.
>>
>> Thanks
>> Sri
>
>> Index: function_re
Is it better to add some logic in counts_to_freq to determine if the
profile count needs to be dropped completely to force profile
estimation?
David
On Mon, Feb 10, 2014 at 2:12 PM, Teresa Johnson wrote:
> This patch attempts to address the lost profile issue for COMDATs in
> more circumstances,
Remove DW_AT_GNU_addr_base from skeleton type unit DIEs.
GCC currently adds a DW_AT_GNU_addr_base attribute to skeleton type unit
DIEs, even though it's not needed there. By removing it, we can save
the 8 bytes that a DW_FORM_addr takes up, plus the 24 bytes that the
corresponding relocation takes
On Tue, Feb 11, 2014 at 3:55 PM, Cary Coutant wrote:
> Remove DW_AT_GNU_addr_base from skeleton type unit DIEs.
>
> GCC currently adds a DW_AT_GNU_addr_base attribute to skeleton type unit
> DIEs, even though it's not needed there. By removing it, we can save
> the 8 bytes that a DW_FORM_addr take
On Mon, 10 Feb 2014, Kirill Yukhin wrote:
> Index: htdocs/index.html
> ===
> + Intel AVX-512 support
> + [2014-02-07]
> + Intel AVX-512 support was added to GCC. That includes inline
> assembly
> + support, extended exi
On Tue, Feb 11, 2014 at 3:29 PM, Teresa Johnson wrote:
>
> On Feb 11, 2014 2:37 PM, "Sriraman Tallam" wrote:
>>
>> On Tue, Feb 11, 2014 at 1:32 PM, Teresa Johnson
>> wrote:
>> > On Mon, Feb 10, 2014 at 7:15 PM, Sriraman Tallam
>> > wrote:
>> >> Hi Teresa,
>> >>
>> >>I have attached a patch
On Tue, Feb 11, 2014 at 4:32 PM, Sriraman Tallam wrote:
> On Tue, Feb 11, 2014 at 3:29 PM, Teresa Johnson wrote:
>>
>> On Feb 11, 2014 2:37 PM, "Sriraman Tallam" wrote:
>>>
>>> On Tue, Feb 11, 2014 at 1:32 PM, Teresa Johnson
>>> wrote:
>>> > On Mon, Feb 10, 2014 at 7:15 PM, Sriraman Tallam
>>>
This small patch lets GCC emit a single unaligned load/store
instruction for m_GENERIC i386 CPUs.
Bootstrapped and passed regression test.
OK for Google branch?
thanks,
Cong
Index: gcc/config/i386/i386.c
===
--- gcc/config/i386/i
ok.
David
On Tue, Feb 11, 2014 at 4:50 PM, Cong Hou wrote:
> This small patch lets GCC emit a single unaligned load/store
> instruction for m_GENERIC i386 CPUs.
>
> Bootstrapped and passed regression test.
>
> OK for Google branch?
>
>
> thanks,
> Cong
>
>
> Index: gcc/config/i386/i386.c
> =
On Tue, Feb 11, 2014 at 4:39 PM, Teresa Johnson wrote:
> On Tue, Feb 11, 2014 at 4:32 PM, Sriraman Tallam wrote:
>> On Tue, Feb 11, 2014 at 3:29 PM, Teresa Johnson wrote:
>>>
>>> On Feb 11, 2014 2:37 PM, "Sriraman Tallam" wrote:
On Tue, Feb 11, 2014 at 1:32 PM, Teresa Johnson
wr
On Tue, 11 Feb 2014, Jakub Jelinek wrote:
> Hi!
>
> Right now we spent several minutes in verify_tree. The problems I see
> is that merge_tlist does the exact opposite of what should it be doing with
> copy flag (most merge_tlist calls are with copy=0, thus that means mostly
> unnecessary copyin
On Tue, 2014-02-11 at 16:51 +, Philip Herron wrote:
[adding the j...@gcc.gnu.org ML to the CC]
> Added install hook:
Thanks!
I don't know that this is needed for a 3-line patch, but have you done
the copyright assignment paperwork for GCC contribution? (I hope to
merge my branch into gcc tr
On Tue, Feb 11, 2014 at 4:51 PM, Sriraman Tallam wrote:
> On Tue, Feb 11, 2014 at 4:39 PM, Teresa Johnson wrote:
>> On Tue, Feb 11, 2014 at 4:32 PM, Sriraman Tallam wrote:
>>> On Tue, Feb 11, 2014 at 3:29 PM, Teresa Johnson
>>> wrote:
On Feb 11, 2014 2:37 PM, "Sriraman Tallam" wrote
On Tue, Feb 11, 2014 at 2:56 PM, Xinliang David Li wrote:
> Is it better to add some logic in counts_to_freq to determine if the
> profile count needs to be dropped completely to force profile
> estimation?
This is the problem I was mentioning below where we call
counts_to_freqs before we have th
Why is call graph needed to determine whether to drop the profile?
If that is needed, it might be possible to leverage the ipa_profile
pass as it will walk through all function nodes to do profile
annotation. With this you can make decision to drop callee profile in
caller's context.
David
On Tu
With this patch x_flag_complex_method won't be set to 2 for C++ so
that multiply/divide between std::complex objects won't be replaced by
expensive builtin function calls.
Bootstrapped and passed regression test.
OK for Google branch?
thanks,
Cong
Index: gcc/c-family/c-opts.c
===
ok.
David
On Tue, Feb 11, 2014 at 5:30 PM, Cong Hou wrote:
> With this patch x_flag_complex_method won't be set to 2 for C++ so
> that multiply/divide between std::complex objects won't be replaced by
> expensive builtin function calls.
>
> Bootstrapped and passed regression test.
>
> OK for Goo
On Tue, Feb 11, 2014 at 5:16 PM, Xinliang David Li wrote:
> Why is call graph needed to determine whether to drop the profile?
Because we detect this situation by looking for cases where the call
edge counts greatly exceed the callee node count.
>
> If that is needed, it might be possible to lev
On Tue, Feb 11, 2014 at 5:36 PM, Teresa Johnson wrote:
> On Tue, Feb 11, 2014 at 5:16 PM, Xinliang David Li wrote:
>> Why is call graph needed to determine whether to drop the profile?
>
> Because we detect this situation by looking for cases where the call
> edge counts greatly exceed the callee
Hi,
this patch implements warning when we merge two virtual tables that do not
match. It compares the size and also go into fields. I had to implement my
own comparsion code, since the vtables may subtly differ - in RTTI and also I
need to do so during DECL merging (since we will forget about the
On 02/11/2014 07:54 PM, Jan Hubicka wrote:
+ /* Allow combining RTTI and non-RTTI is OK. */
You mean combining -frtti and -fno-rtti compiles? Yes, that's fine,
though you need to prefer the -frtti version in case code from that
translation unit uses the RTTI info.
/aux/hubicka/fi
> On 02/11/2014 07:54 PM, Jan Hubicka wrote:
> >+ /* Allow combining RTTI and non-RTTI is OK. */
>
> You mean combining -frtti and -fno-rtti compiles? Yes, that's fine,
> though you need to prefer the -frtti version in case code from that
> translation unit uses the RTTI info.
Is there som
Hi,
the last version of this work is unreviewed, should be rather
straightforward...
Paolo.
Hi!
On Wed, 5 Feb 2014 16:33:19 -0800, Sharad Singhai wrote:
> I am really sorry about the delay.
No worries; not exactly a severe issue. ;-)
> I couldn't exactly reproduce the
> warning which you described
Maybe the version of makeinfo is relevant?
$ makeinfo --version | head -n 1
m
96 matches
Mail list logo
