test.c:
extern bar(unsigned char p[3][2]);
void foo(int i)
{
unsigned char data[3][2] = {{1,1}, {1,0}, {1,1}};
bar(data);
}
First, note, I'm not an ARM expert. However, the first question I
have is are we sure the initializer is always going to be suitably
aligned? What guarantees
SSA_NAME_VALUE is, in effect, a chain of values. ie, it's possible for
SSA_NAME_VALUE of any given SSA_NAME to refer to another SSA_NAME. In
many cases it is advantageous to look deeper into those chains,
particularly when simplifying conditionals for jump threading.
The problem with
Hi,
Fixing PR target/61633
The two split patterns associated with aarch64_ashr_sisd_or_int_mode3
split the instruction into a NEG followed by an SHL. The split uses one
of the input operands as a scratch register to hold the output of the
NEG resulting in register corruption.
This patch
I'd rather drop the scan-assembler. I'm not convinced that the fragile
nature of this is required. Can you add a note to the README that says
that this is meant to be a complete execution test for the Advanced
SIMD intrinsics and does not cover all the assembler that is
Sure.
generated. If
I don't have permissions to commit this patch, but I do have a release
on file with the FSF.
Problem description:
The text for using Explicit Register Variables is confusing, redundant,
and fails to make certain essential information clear.
Some specific problems:
- There is no reason to
On June 29, 2014 9:53:03 PM CEST, Jan Hubicka hubi...@ucw.cz wrote:
In addition of pr61644 and pr61646, this commit breaks a lot of
fortran tests with -flto -O0.
Hello,
the problem here is that we have POINTER_TYPE that points to array of
variable
length (not sure why it happens only with -O0).
Richard Biener richard.guent...@gmail.com writes:
On June 27, 2014 2:50:33 PM CEST, Rainer Orth r...@cebitec.uni-bielefeld.de
wrote:
Richard Biener rguent...@suse.de writes:
The following patch enables bswap-from-load for STRICT_ALIGNMENT
targets when the load is aligned instead of
Please revert the original patch instead which was not tested properly. I'll
get back to this after I return from vacation.
OK, I will bootstrap and revert tomorrow morning.
Note that testusite passes with the patch; the problem appears only at -O0
-flto and fortran
that we apparently do
When we integrated GCJ/libgcj, it looks like we did not proceed
doing that fully as it came to the web pages, and sadly nobody
else has been looking after them for a while.
2014-06-30 Gerald Pfeifer ger...@pfeifer.com
* build-snapshot.html: Remove.
* gcj2.html: Remove link to
I applied the small patch on top of this, mostly triggered by the
markup issue.
Let me know if there is anything you'd like to see differently; I
am thinking to push back to GCC 4.9 as well later.
Gerald
2014-06-30 Gerald Pfeifer ger...@pfeifer.com
* doc/install.texi (Specific,
Looks good to me. Thanks for the fix.
Yufeng
On 06/30/14 10:44, Gerald Pfeifer wrote:
I applied the small patch on top of this, mostly triggered by the
markup issue.
Let me know if there is anything you'd like to see differently; I
am thinking to push back to GCC 4.9 as well later.
Gerald
Hi Bill,
Bill Schmidt wrote:
The test in gfortran.dg/round_4.f90, introduced in GCC 4.9, checks for
correct behavior of different rounding modes. However, for
quad-precision floating-point, it requires that the number
0.100481 be exactly represented. Since
On 30 June 2014 10:41, Kyrill Tkachov kyrylo.tkac...@arm.com wrote:
Here it is.
Now it applies cleanly to 4.9 and the tests are in gcc.target/aarch64
instead of gcc.target/aarch64/simd
Tested on aarch64-none-elf and aarch64_be-none-elf.
Ok to apply?
OK, thanks.
/Marcus
On 30/06/14 11:44, Marcus Shawcroft wrote:
On 30 June 2014 10:41, Kyrill Tkachov kyrylo.tkac...@arm.com wrote:
Here it is.
Now it applies cleanly to 4.9 and the tests are in gcc.target/aarch64
instead of gcc.target/aarch64/simd
Tested on aarch64-none-elf and aarch64_be-none-elf.
Ok to apply?
On 30 June 2014 09:03, Ramana Radhakrishnan ramana@googlemail.com wrote:
+ Move the tests to gcc.target/arm/ to gcc.target/aarch64 if the
AArch64 maintainers agree. For the extra AArch64 variants guard them
with #ifdef __aarch64__ #endif.
Given that the intrinsics in aarch64 are a
Mike Stump wrote:
On Jun 28, 2014, at 3:31 AM, Ulrich Weigand uweig...@de.ibm.com wrote:
Mike Stump wrote:
(rs6000_aggregate_candidate): Use wide-int interfaces.
[snip]
- /* Can't handle incomplete types. */
- if (!COMPLETE_TYPE_P (type))
-return -1;
+ /* Can't handle
On 06/17/2014 10:00 PM, Jeff Law wrote:
On 06/13/14 04:26, mliska wrote:
Hi,
this small patch prepares remaining needed infrastructure for the new pass.
Changelog:
2014-06-13 Martin Liska mli...@suse.cz
Honza Hubicka hubi...@ucw.cz
* ipa-utils.h
Apparently I didn't pay much attention to no_sanitize_undefined
attribute when adding new features to ubsan, so we would instrument
stuff even though the function is marked with this attribute.
Thus fixed new testcases added.
Bootstrapped/regtested on x86_64-linux, ok for trunk?
2014-06-30
On 06/17/2014 09:52 PM, Jeff Law wrote:
On 06/13/14 04:48, mliska wrote:
Hi,
many tests rely on a precise number of scanned functions in a dump file. If
IPA ICF decides to merge some function and(or) read-only variables, counts do
not match.
Martin
Changelog:
2014-06-13 Martin Liska
On 06/17/2014 09:53 PM, Jeff Law wrote:
On 06/13/14 05:16, mliska wrote:
Hi,
this is a new collection of tests for IPA ICF pass.
Martin
Changelog:
2014-06-13 Martin Liska mli...@suse.cz
Honza Hubicka hubi...@ucw.cz
* gcc/testsuite/g++.dg/ipa/ipa-se-1.C: New test.
*
Hello,
I still miss an approval for the middle-end part of
http://gcc.gnu.org/ml/gcc-patches/2014-06/msg01038.html
thanks,
Christian
Hmm, I wonder why we need BINFOs at all for the ptrmemfunc RECORD_TYPEs,
which are not classes.
Jason
On 18 June 2014 00:02, Ramana Radhakrishnan ramana@googlemail.com wrote:
Interesting workaround but can we investigate further how to fix this
at the source rather than working around in the backend in this form.
It's still a kludge that we carry in the backend rather than fix the
problem
Hi!
-fsanitize=bounds is one of the -fsanitize=undefined suboptions, therefore
it should be documented as such.
Fixed thusly, committed to trunk as obvious.
2014-06-30 Jakub Jelinek ja...@redhat.com
* doc/invoke.texi (-fsanitize=bounds): Move to the table with
On Mon, Jun 30, 2014 at 02:08:26PM +0200, Marek Polacek wrote:
Apparently I didn't pay much attention to no_sanitize_undefined
attribute when adding new features to ubsan, so we would instrument
stuff even though the function is marked with this attribute.
Thus fixed new testcases added.
On Mon, Jun 30, 2014 at 02:58:53PM +0200, Jakub Jelinek wrote:
On Mon, Jun 30, 2014 at 02:08:26PM +0200, Marek Polacek wrote:
Apparently I didn't pay much attention to no_sanitize_undefined
attribute when adding new features to ubsan, so we would instrument
stuff even though the function is
On Fri, Jun 27, 2014 at 08:49:24AM +0200, Marek Polacek wrote:
On Fri, Jun 27, 2014 at 08:36:38AM +0200, Sebastian Huber wrote:
Thanks for your patience. It would be nice if this can be applied to GCC
4.9 as well.
Can someone please commit this for me, since I don't have write access.
On Mon, Jun 30, 2014 at 03:00:11PM +0200, Jakub Jelinek wrote:
Actually, please change current_function_decl != 0 to
current_function_decl != NULL_TREE everywhere in the patch.
Ok with that change.
Ok, I'm applying the following then.
2014-06-30 Marek Polacek pola...@redhat.com
*
On 30/06/14 13:53, Charles Baylis wrote:
On 18 June 2014 00:02, Ramana Radhakrishnan ramana@googlemail.com wrote:
Interesting workaround but can we investigate further how to fix this
at the source rather than working around in the backend in this form.
It's still a kludge that we carry
Hello,
The vxworks_override_option code is general enough to apply to both regular
VxWorks and VxWorksAE configurations.
The VxWorksAE configuration files miss the triggering bits, however, with
various kinds of consequences. One example is -fPIC being accepted without
-mrtp, while it should be
Ping.
https://gcc.gnu.org/ml/gcc-patches/2014-06/msg01771.html
Kyrill
On 23/06/14 15:30, Kyrill Tkachov wrote:
Hi all,
This patch implements some absolute compare intrinsics in arm_neon.h.
Execution tests are added.
Tested aarch64-none-elf, aarch64_be-none-elf, bootstrapped on aarch64 linux
Ping.
https://gcc.gnu.org/ml/gcc-patches/2014-06/msg01615.html
Kyrill
On 20/06/14 15:17, Kyrill Tkachov wrote:
Hi all,
Now that Alan fixed the float64x1_t machinery, this patch implements
some low-hanging intrinsics
in arm_neon.h.
Tested aarch64-none-elf and bootstrapped on aarch64-linux.
With the patch attached ...
On Jun 30, 2014, at 15:29 , Olivier Hainque hain...@adacore.com wrote:
Hello,
The vxworks_override_option code is general enough to apply to both regular
VxWorks and VxWorksAE configurations.
The VxWorksAE configuration files miss the triggering bits, however,
Note that testusite passes with the patch; ...
Confirmed. There is a typo
s/fileds/fields/
I have seen the failures because I now run the gfortran testsuite with
the addition of '-g -flto'. Is it worth pushing in this direction?
Cheers,
Dominique
Hi,
I think it's fair to say that this issue is rather tricky, considering
that among the compilers I have at hand none gets it right without
regressing on parse/pr26997.C. The basic issue is simple: in C++11
(void)[]{};
is well formed, thus cp_parser_tokens_start_cast_expression should
OK.
Jason
On 27/06/14 09:29, Kyrill Tkachov wrote:
Hi all,
This patch generalises the TARGET_MACRO_FUSION_PAIR_P hook usage to work
on more than just
compares and conditional branches for which it was initially designed
for (for x86).
There are some instructions in arm and aarch64 that can be fused
Siva == Siva Chandra sivachan...@google.com writes:
Siva +# Load the xmethods.
Siva +from libstdcxx.v6.xmethods import register_libstdcxx_xmethods
Siva +register_libstdcxx_xmethods (gdb.current_objfile ())
I don't think any addition to the hook file should be needed.
Siva +# The object
unify_one_argument was assuming that there's no way we can get a
type/value mismatch in a nested deduction, but it can happen with
variadic templates; deduction should just fail in that case.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 40c2934a737ba5d2e406e079a2b249245dfb17ab
Author:
On 06/17/2014 04:54 PM, Martin Jambor wrote:
Weird... does the following (untested) patch help?
diff --git a/gcc/tree-sra.c b/gcc/tree-sra.c
index 0afa197..747b1b6 100644
--- a/gcc/tree-sra.c
+++ b/gcc/tree-sra.c
@@ -3277,6 +3277,8 @@ sra_modify_assign (gimple *stmt, gimple_stmt_iterator
*gsi)
OK.
Jason
On 06/28/2014 05:57 PM, Ed Smith-Rowland wrote:
OK?
I would also like to apply this to 4.9.
OK.
Jason
This is a reminder message on fix for PR 61561 which is ICE while
compiling something which is valid* 'C' code.
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61561).
Ramana, Richard, I am very appreciated for your attention and error
indication, your work made my patch simple and tiny. And I
On Sun, Jun 29, 2014 at 9:48 PM, Bill Schmidt
wschm...@linux.vnet.ibm.com wrote:
Hi,
The test in gfortran.dg/round_4.f90, introduced in GCC 4.9, checks for
correct behavior of different rounding modes. However, for
quad-precision floating-point, it requires that the number
Note that testusite passes with the patch; ...
Confirmed. There is a typo
s/fileds/fields/
I have seen the failures because I now run the gfortran testsuite with
On 06/29/2014 12:51 PM, Uros Bizjak wrote:
I believe that attached v2 patch addresses all your review comments.
Patch was bootstrapped and regression tested on x86_64-linux-gnu {,-m32}.
Looks good, thanks.
r~
On 06/30/2014 08:42 AM, Jason Merrill wrote:
Hmm, I wonder why we need BINFOs at all for the ptrmemfunc RECORD_TYPEs,
which are not classes.
I'm working on removing both BINFO and TYPE_LANG_SPECIFIC.
Jason
On 06/29/2014 11:14 AM, Uros Bizjak wrote:
if (MEM_READONLY_P (x))
+if (GET_CODE (mem_addr) == AND)
+ return 1;
return 0;
Certainly missing braces here. But with that fixed the patch looks plausible.
I'll look at it closer later today.
r~
On Jun 29, 2014, at 6:48 PM, Bill Schmidt wschm...@linux.vnet.ibm.com wrote:
+! { dg-skip-if IBM long double 31 bits of precision, test requires 38 {
powerpc*-*-linux* } }
Thanks for the comment. Can someone confirm that this fails on darwin and
should be skipped there as well?
On 06/30/2014 08:42 AM, Jason Merrill wrote:
Hmm, I wonder why we need BINFOs at all for the ptrmemfunc RECORD_TYPEs,
which are not classes.
I'm working on removing both BINFO and TYPE_LANG_SPECIFIC.
Works for me! :)
Thanks,
Honza
This patch adds the -Wincompatible-pointer-types option for a warning
we already have, so it's possible to suppress this specific warning, or
use it with -Werror= and so on.
As a followup change, I'm considering printing the types of the pointers;
saying merely e.g. assignment from incompatible
Basically everything I wrote in the patch for -Wincompatible-pointer-types
applies here as well. A new option, -Wint-conversion (to be compatible
with clang), is added to allow more fine-grained control over the warnings.
I think we should print the types here as well, and moreover, we could hint
We were missing a way the function being called can be dependent.
Tested x86_64-pc-linux-gnu, applying to 4.8, 4.9, trunk.
commit 687aa57720473c7962c9eb9cf79c67cf068ba005
Author: Jason Merrill ja...@redhat.com
Date: Mon Jun 30 13:50:38 2014 -0400
PR c++/61647
* pt.c
On 06/30/14 06:14, Christian Bruel wrote:
Hello,
I still miss an approval for the middle-end part of
http://gcc.gnu.org/ml/gcc-patches/2014-06/msg01038.html
Didn't I ack that patch last week?
https://gcc.gnu.org/ml/gcc-patches/2014-06/msg01401.html
Thanks,
Jeff
decl_mangling_context was failing to recognize a lambda in template
context as a lambda.
Tested x86_64-pc-linux-gnu, applying to 4.9 and trunk.
commit 1ba7cf95c0b024c7a3372e0734d7bf620f31dd14
Author: Jason Merrill ja...@redhat.com
Date: Mon Jun 30 12:08:09 2014 -0400
PR c++/61566
*
On 06/30/2014 11:58 AM, Jason Merrill wrote:
On 06/30/2014 08:42 AM, Jason Merrill wrote:
Hmm, I wonder why we need BINFOs at all for the ptrmemfunc RECORD_TYPEs,
which are not classes.
I'm working on removing both BINFO and TYPE_LANG_SPECIFIC.
Like so. Applying to trunk.
commit
On 06/30/14 05:49, Martin Liška wrote:
On 06/17/2014 10:00 PM, Jeff Law wrote:
On 06/13/14 04:26, mliska wrote:
Hi,
this small patch prepares remaining needed infrastructure for
the new pass.
Changelog:
2014-06-13 Martin Liska mli...@suse.cz
Honza Hubicka hubi...@ucw.cz
combine.c includes a check which prevents
(ashiftrt (xor A C2) C1)
from being commuted to
(xor (ashiftrt A C1) (ashiftrt C2 C1))
for constants C1, C2 if C2 has its sign bit set.
Specifically, this prevents (ashiftrt (not A) C1) from being commuted to
(not (ashiftrt A C1))
because the
On 06/26/14 12:46, Jan Hubicka wrote:
So you've added this at -O2, what is the general compile-time
impact? Would it make more sense to instead have it be part of -O3,
particularly since ICF is rarely going to improve performance (sans
icache issues).
I think code size optimization not
On 06/28/14 16:33, Marc Glisse wrote:
In an earlier version of the patch, I was using
get_or_create_ssa_default_def (cfun, sym);
(I was reusing the same variable). This passed bootstrap+testsuite on
all languages except for ada. Indeed, the compiler wanted to coalesce
several SSA_NAMEs,
On 03/04/14 09:40, Marek Polacek wrote:
This should fix ICE on insane alignment. Normally, check_user_alignment
detects e.g. alignment 1 32, but not 1 28. However, record_align
is in bits, so it's actually 8 * (1 28) and that's greater than
INT_MAX. This patch rejects such code.
In the
Hello!
After fixing _.barriers and _.eh_range passes w.r.t. CALL_ARG_LOCATION
notes, we can finaly move handling of trap shadows (PR 56858) and insn
alignments into their own passes.
Additionally, the patch skips handling of BARRIERs in
alpha_pad_function_end, since CALL_ARG_LOCATION notes are
On 06/26/14 07:42, Teresa Johnson wrote:
The following patch fixes a big inefficiency when using -fdump-tree-all
for large source files. I found that when using this option the
compile time became unreasonably slow, and I traced this to the fact
that dump_begin/dump_end are called around every
On Mon, 30 Jun 2014, Marek Polacek wrote:
This patch adds the -Wincompatible-pointer-types option for a warning
we already have, so it's possible to suppress this specific warning, or
use it with -Werror= and so on.
As a followup change, I'm considering printing the types of the pointers;
On Mon, 30 Jun 2014, Marek Polacek wrote:
Basically everything I wrote in the patch for -Wincompatible-pointer-types
applies here as well. A new option, -Wint-conversion (to be compatible
with clang), is added to allow more fine-grained control over the warnings.
I think we should print the
When we're devirtualizing, we need to make sure that any virtual
functions are synthesized or instantiated even if the vtable isn't going
to be emitted. My earlier patches for 53808 handled this for
synthesized destructors, but the issue is more general.
Tested x86_64-pc-linux-gnu, applying
On Thu, Jun 26, 2014 at 06:42:09AM -0700, Teresa Johnson wrote:
2014-06-26 Teresa Johnson tejohn...@google.com
* c-family/c-common.h (get_dump_info): Declare.
* c-family/c-gimplify.c (c_genericize): Use saved dump files.
* c-family/c-opts.c (c_common_parse_file):
I refactored the code and added comments. A bug (prematurely breaking
from a loop) was fixed during the refactoring.
(My last mail was wrongly set to HTML instead of plain text. I
apologize for that.)
2014-06-30 Yi Yang ahyan...@google.com
* auto-profile.c (get_locus_information)
On 06/27/14 02:29, Kyrill Tkachov wrote:
Hi all,
This patch generalises the TARGET_MACRO_FUSION_PAIR_P hook usage to work
on more than just
compares and conditional branches for which it was initially designed
for (for x86).
There are some instructions in arm and aarch64 that can be fused
On 06/26/14 04:56, Tom de Vries wrote:
On 19-06-14 18:47, Richard Henderson wrote:
And I forgot to mention it might be worth while to notice simple
recursion.
Avoid the early exit path if caller == callee, despite the caller-save
info not
being valid.
Richard,
attached patch enables
On 06/27/14 08:49, Joseph S. Myers wrote:
With a 4.8-based compiler for ARM, I've observed an ICE in the
var-tracking.c:add_stores handling of COND_EXEC. A large testcase
from building Qt can be found at
https://bugs.launchpad.net/gcc-linaro/+bug/1312931; a somewhat
reduced version (for the
You don't need extra space to store file name in locus_information_t.
Use pointer instead.
Dehao
On Mon, Jun 30, 2014 at 1:36 PM, Yi Yang ahyan...@google.com wrote:
I refactored the code and added comments. A bug (prematurely breaking
from a loop) was fixed during the refactoring.
(My last
Can you please add this and the other one to gcc-4.10/changes.html?
I can provide help if you need any.
Gerald
On Mon, Jun 30, 2014 at 10:51:59PM +0200, Gerald Pfeifer wrote:
Can you please add this and the other one to gcc-4.10/changes.html?
I can provide help if you need any.
We don't have gcc-4.10/ directory, because the version of the next release
is still to be decided (hopefully at Cauldron next
On Mon, Jun 30, 2014 at 5:54 PM, Richard Henderson r...@redhat.com wrote:
On 06/29/2014 11:14 AM, Uros Bizjak wrote:
if (MEM_READONLY_P (x))
+if (GET_CODE (mem_addr) == AND)
+ return 1;
return 0;
Certainly missing braces here. But with that fixed the patch looks plausible.
On 06/30/14 02:18, David Wohlferd wrote:
I don't have permissions to commit this patch, but I do have a release
on file with the FSF.
Problem description:
The text for using Explicit Register Variables is confusing, redundant,
and fails to make certain essential information clear.
Some
On 06/29/14 03:22, Marc Glisse wrote:
After looking at PR 61597, I updated the 2 conditions to:
+ if ((TREE_CODE (valbase) == VAR_DECL
+!is_global_var (valbase))
+ || TREE_CODE (valbase) == PARM_DECL)
a PARM_DECL is a local variable and returning its
Fixed.
Also, I spotted some warnings caused by me using %lfs in snprintf().
I changed these to %f and tested.
On Mon, Jun 30, 2014 at 1:49 PM, Dehao Chen de...@google.com wrote:
You don't need extra space to store file name in locus_information_t.
Use pointer instead.
Dehao
On Mon, Jun
On Mon, 30 Jun 2014, Jakub Jelinek wrote:
We don't have gcc-4.10/ directory, because the version of the next
release is still to be decided (hopefully at Cauldron next month).
I'm a bit worried we'll miss entries in the meantime.
Can we use gcc-4.10/ for now and rename later if we go for
GCC
On 06/30/14 13:05, Alan Lawrence wrote:
combine.c includes a check which prevents
(ashiftrt (xor A C2) C1)
from being commuted to
(xor (ashiftrt A C1) (ashiftrt C2 C1))
for constants C1, C2 if C2 has its sign bit set.
Specifically, this prevents (ashiftrt (not A) C1) from being commuted to
Let's use %d to replace %f (manual conversion, let's do xx%).
Dehao
On Mon, Jun 30, 2014 at 2:06 PM, Yi Yang ahyan...@google.com wrote:
Fixed.
Also, I spotted some warnings caused by me using %lfs in snprintf().
I changed these to %f and tested.
On Mon, Jun 30, 2014 at 1:49 PM, Dehao Chen
On 06/28/2014 08:49 AM, Jan Hubicka wrote:
Hi,
this patch enhances alias manipulation for symtab_node. Honza suggested
following changes.
Patch is pre approved, will be committed if no comments and regressions.
Bootstrapped on x86_64-pc-linux-gnu, regression tests have been running.
This is intermediate result, which is meant to be consumed by further
post-processing. For this reason I'd prefer to put a number without
that percentage sign.
I'd just output (int)(probability*1+0.5). Does this look good
for you? Or maybe change that to 100 since six digits are more
On Mon, 30 Jun 2014, Jeff Law wrote:
On 06/29/14 03:22, Marc Glisse wrote:
After looking at PR 61597, I updated the 2 conditions to:
+ if ((TREE_CODE (valbase) == VAR_DECL
+!is_global_var (valbase))
+ || TREE_CODE (valbase) == PARM_DECL)
a PARM_DECL is
Applied.
Gerald
Index: projects/cfg.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/projects/cfg.html,v
retrieving revision 1.19
diff -u -r1.19 cfg.html
--- projects/cfg.html 3 Dec 2013 01:04:42 - 1.19
+++ projects/cfg.html
On June 29, 2014 9:53:03 PM CEST, Jan Hubicka hubi...@ucw.cz wrote:
In addition of pr61644 and pr61646, this commit breaks a lot of
fortran tests with -flto -O0.
Hello,
the problem here is that we have POINTER_TYPE that points to array of
variable
length (not sure why it happens only with
gcc/ChangeLog:
* cgraph.h (iterate_direct_aliases): New function.
(FOR_EACH_ALIAS): New macro iterates all direct aliases for a node.
* cgraph.c (cgraph_for_node_thunks_and_aliases): Usage of
FOR_EACH_ALIAS added.
(cgraph_for_node_and_aliases): Likewise.
*
Fixed. (outputting only the integer percentage)
On Mon, Jun 30, 2014 at 2:20 PM, Yi Yang ahyan...@google.com wrote:
This is intermediate result, which is meant to be consumed by further
post-processing. For this reason I'd prefer to put a number without
that percentage sign.
I'd just output
Jason,
I made a verifier that types not considered anonymous are not built
from types that are anonymous and that public types have TREE_PUBLIC
flag on their TYPE_DECLS (as that seem to be what tree.h says).
This catches two cases in C++ FE and several other cases elsewhere.
Does something like
Jason,
this is non-C++ specific part where I needed updating. The i386.c change will
need to be propagated into other backends. I also wonder if I should copy
PUBLIC flag from component type in complex numbers - can we produce complex
number from anonymous type?
Finally
On Jun 30, 2014, at 12:50 PM, Jeff Law l...@redhat.com wrote:
On 03/04/14 09:40, Marek Polacek wrote:
This should fix ICE on insane alignment. Normally, check_user_alignment
detects e.g. alignment 1 32, but not 1 28. However, record_align
is in bits, so it's actually 8 * (1 28) and that's
On Jun 30, 2014, at 3:40 PM, Mike Stump mikest...@comcast.net wrote:
Is this still applicable after the wide-int changes? I haven't looked
closely.
Oops, forgot to state what I wanted to state… Yes, it still aborts post
wide-int…
On 6/30/2014 2:01 PM, Jeff Law wrote:
On 06/30/14 02:18, David Wohlferd wrote:
I don't have permissions to commit this patch, but I do have a release
on file with the FSF.
Problem description:
The text for using Explicit Register Variables is confusing, redundant,
and fails to make certain
Instead of storing percentages of the branch probabilities, store them
times REG_BR_PROB_BASE.
On Mon, Jun 30, 2014 at 3:26 PM, Yi Yang ahyan...@google.com wrote:
Fixed. (outputting only the integer percentage)
On Mon, Jun 30, 2014 at 2:20 PM, Yi Yang ahyan...@google.com wrote:
This is
There is no need for fill_invalid_locus_information, just initialize
every field to 0, and if it's unknown location, no need to output this
line.
Dehao
On Mon, Jun 30, 2014 at 4:26 PM, Yi Yang ahyan...@google.com wrote:
Instead of storing percentages of the branch probabilities, store them
Removed fill_invalid_locus_information. Change the function call to a
return statement.
On Mon, Jun 30, 2014 at 4:42 PM, Dehao Chen de...@google.com wrote:
There is no need for fill_invalid_locus_information, just initialize
every field to 0, and if it's unknown location, no need to output this
Done.
On Mon, Jun 30, 2014 at 5:20 PM, Dehao Chen de...@google.com wrote:
For get_locus_information, can you cal get_inline_stack and directly use its
output to get the function name instead?
Dehao
On Mon, Jun 30, 2014 at 4:47 PM, Yi Yang ahyan...@google.com wrote:
Removed
Fixed a style error (missing a space before a left parenthesis)
On Mon, Jun 30, 2014 at 5:41 PM, Yi Yang ahyan...@google.com wrote:
Done.
On Mon, Jun 30, 2014 at 5:20 PM, Dehao Chen de...@google.com wrote:
For get_locus_information, can you cal get_inline_stack and directly use its
output
On Mon, Jun 30, 2014 at 8:00 AM, Tom Tromey tro...@redhat.com wrote:
Siva == Siva Chandra sivachan...@google.com writes:
Siva +# Load the xmethods.
Siva +from libstdcxx.v6.xmethods import register_libstdcxx_xmethods
Siva +register_libstdcxx_xmethods (gdb.current_objfile ())
I don't think
On Jun 30, 2014, at 4:10 PM, David Wohlferd d...@limegreensocks.com wrote:
- Vague descriptions of things that are reported to work on certain
platforms are not useful (On the SPARC, there are reports that).
I'd disagree. But what's more important here is the registers that are
available
1 - 100 of 107 matches
Mail list logo
