I took that patch and applied it to the gcc sources,
but I still see the error on ppc:
...
[bergner@makalu-lp1 asan]$
On Tue, Jun 03, 2014 at 10:19:48AM +0400, Yury Gribov wrote:
I took that patch and applied it to the gcc sources,
but I still see the error on ppc:
...
[bergner@makalu-lp1 asan]$
On Mon, Jun 02, 2014 at 09:11:20PM +0200, Paul Richard Thomas wrote:
First I should say many thanks for this support for gfortran. This is
the one area for which we have professional support and I for one am
truly grateful.
I have scanned through the patch and can see nothing to object to.
Hi,
This patch does not allow splitting in case bounds are returned until retutrned
bounds are supported. It also propagates instrumentation marks for generated
call and function.
Bootstrapped and tested on linux-x86_64.
Thanks,
Ilya
--
gcc/
2014-06-03 Ilya Enkovich
Hi,
This patch preserves CALL_WITH_BOUNDS flag for calls during PRE.
Bootstrapped and tested on linux-x86_64.
Thanks,
Ilya
--
gcc/
2014-06-03 Ilya Enkovich ilya.enkov...@intel.com
* tree-ssa-pre.c (create_component_ref_by_pieces_1): Store
CALL_WITH_BOUNDS_P for calls.
When a bitwise OR gimple statement has for operands SSA_NAME initialized
directly from memory source (no cast or other unary statement intervening), a
symbolic number will be used only partly initialized. This was discovered by
valgrind and reported as PR61328. This patch fixes that by moving
Segher Boessenkool seg...@kernel.crashing.org writes:
On Mon, Jun 02, 2014 at 08:14:49PM +0100, Richard Sandiford wrote:
As per the patch I just posted, all ports have moved over to the new
way of defining constraints. This patch removes the associated m
column from backends.html. (Note that
On 27 May 2014 23:27, Kugan kugan.vivekanandara...@linaro.org wrote:
Due to the cost changes in IRA, now part of the arguments(v0.d[1]) for
multf3 ends up in stack. Reason for this us, in IRA, assign_hard_reg,
while iterating for the cost for assigning register to reg:TI 99,
allocates
Hi,
This patch adjusts alloc-free removal algorithm in DCE to take into account
BUILT_IN_CHKP_BNDRET call returning bounds of allocated memory.
Bootstrapped and tested on linux-x86_64.
Thanks,
Ilya
--
gcc/
2014-06-03 Ilya Enkovich ilya.enkov...@intel.com
* tree-ssa-dce.c: Include
On Thu, May 29, 2014 at 6:29 PM, Jonathan Wakely jwak...@redhat.com wrote:
On 26/05/14 19:19 +0400, Konstantin Serebryany wrote:
It does look useful but I'm concerned about a proliferation of
container checks, we already have the libstdc++ Debug Mode
and I'd
like to see some of the
Hi,
This patch allows BUILT_IN_CHKP_BNDRET as a consumer of a result of
BUILT_IN_STACK_SAVE call.
Bootstrapped and tested on linux-x86_64.
Thanks,
Ilya
--
gcc/
2014-06-03 Ilya Enkovich ilya.enkov...@intel.com
* tree-ssa-ccp.c (insert_clobber_before_stack_restore): Handle
As discussed with Tobias on IRC yesterday, the fact that I'd like to
eventually backport the Fortran OpenMP 4.0 support to 4.9 branch
poses a problem with the module.c changes
But this is by design, because we’re not supposed to add new features
(especially API-changing or module-changing
On June 3, 2014 9:18:29 AM CEST, Thomas Preud'homme thomas.preudho...@arm.com
wrote:
When a bitwise OR gimple statement has for operands SSA_NAME
initialized directly from memory source (no cast or other unary
statement intervening), a symbolic number will be used only partly
initialized. This
Hi all,
This is a second try on outline Asan instrumentation (original patch:
https://gcc.gnu.org/ml/gcc-patches/2014-05/msg02194.html).
This patch adds support for replacing Asan inline checks with function
calls. This feature has been recently added to LLVM to
* reduce long compiler
On Jun 2, 2014, at 7:54 PM, Andreas Schwab sch...@linux-m68k.org wrote:
Regtested on ia64-suse-linux and installed as obvious.
Andreas.
* config/ia64/ia64.c
(ia64_first_cycle_multipass_dfa_lookahead_guard): Check
pending_data_specs first.
diff --git
Looks mostly ok. Any reason why you are not re-creating
MINUS_EXPR in build_symbolic_expr? That is, build
inv - t (for non-pointers, of course)?
It's more uniform and compare_values expects an INTEGER_CST on the RHS,
although the patch was lacking a small tweak to the function:
@@ -1205,19
On Mon, 2 Jun 2014, Marc Glisse wrote:
(plus (bit_not @0) @0)
if (INTEGRAL_TYPE_P (TREE_TYPE (@0)))
{ build_int_cst (TREE_TYPE (@0), -1); })
+(match_and_simplify
+ (plus @0 (bit_not @0))
+ if (INTEGRAL_TYPE_P (TREE_TYPE (@0)))
+ { build_int_cst (TREE_TYPE (@0), -1); })
On 3 June 2014 02:05, Andrew Pinski apin...@cavium.com wrote:
This factors out the IF_THEN_ELSE from aarch64_rtx_costs as that function was
getting too large.
OK? Build and tested for aarch64-elf with no regressions.
OK, Thanks /Marcus
On Tue, Jun 03, 2014 at 12:03:02PM +0400, Yury Gribov wrote:
--- a/gcc/asan.c
+++ b/gcc/asan.c
@@ -257,6 +257,8 @@ struct asan_mem_ref
static alloc_pool asan_mem_ref_alloc_pool;
+static int asan_num_accesses;
+
/* This creates the alloc pool used to store the instances of
On 3 June 2014 02:05, Andrew Pinski apin...@cavium.com wrote:
- if (GET_CODE (op0) == NE
- || GET_CODE (op0) == EQ)
+ if (cmpcode == NE
+ || cmpcode == EQ)
Those two can go back on one line ?
}
- else if (GET_CODE (op0) == LT
-
On Mon, Jun 2, 2014 at 4:51 PM, Ilya Enkovich enkovich@gmail.com wrote:
Hi,
This patch adds support for normal builtin function calls (target ones are
not instrumented). The basic idea of the patch is to make call expr copy
with no bounds and expand it instead. If expr is going to be
On Mon, Jun 2, 2014 at 5:13 PM, Ilya Enkovich enkovich@gmail.com wrote:
2014-06-02 17:37 GMT+04:00 Richard Biener richard.guent...@gmail.com:
On Mon, Jun 2, 2014 at 2:44 PM, Ilya Enkovich enkovich@gmail.com wrote:
2014-06-02 15:35 GMT+04:00 Richard Biener richard.guent...@gmail.com:
On
On Mon, Jun 2, 2014 at 5:15 PM, Ilya Enkovich enkovich@gmail.com wrote:
Hi,
In the most case we follow transparent alias chains wne assemble names. But
in some cases it is not performed. For instrumented functions it is critical
and following patch fixes that. It also adds a
On Mon, Jun 2, 2014 at 5:22 PM, Ilya Enkovich enkovich@gmail.com wrote:
Hi,
This patch prevents output of both instrumented and not instrumented weakref
variants.
Shouldn't one of them be reclaimed instead at some point?
Richard.
Thanks,
Ilya
--
gcc/
2014-06-02 Ilya Enkovich
On Mon, Jun 2, 2014 at 5:56 PM, Ilya Enkovich enkovich@gmail.com wrote:
Hi,
This patch adds support for inlining instrumented calls. Changes are mostly
to support returned bounds. Also generated mem-to-mem assignments are
registered to be later instrumented with appropriate bounds
On Mon, Jun 2, 2014 at 8:59 PM, Jan Hubicka hubi...@ucw.cz wrote:
Yeah, I discussed this with martin today on irc. For aliasing we'd like to
know whether a decl possibly has its address taken. Currently we only trust
TREE_ADDRESSABLE for statics - and lto might change those to hidden
On Mon, Jun 02, 2014 at 08:59:35PM +0200, Jan Hubicka wrote:
Yeah, I discussed this with martin today on irc. For aliasing we'd like to
know whether a decl possibly has its address taken. Currently we only trust
TREE_ADDRESSABLE for statics - and lto might change those to hidden
On Mon, Jun 2, 2014 at 11:21 PM, Teresa Johnson tejohn...@google.com wrote:
This patch fixes an ICE due to memory corruption discovered while building a
large application with FDO and LIPO on the google branch. I don't have a small
reproducer, but the same code appears on trunk, and I believe
On Tue, Jun 3, 2014 at 3:39 AM, Jason Merrill ja...@redhat.com wrote:
The C++ front end wants to be able to build up objects of the various
typeinfo derived classes (such as __si_class_type_info) without needing to
see the full definition of the class. As part of this we build a VAR_DECL
for
On Tue, Jun 3, 2014 at 7:55 AM, Ilya Enkovich enkovich@gmail.com wrote:
2014-06-02 21:27 GMT+04:00 Jeff Law l...@redhat.com:
On 06/02/14 04:48, Ilya Enkovich wrote:
Hmm, so if I understand things correctly, src_fun has no loop
structures attached, thus there's nothing to copy. Presumably
Any reason why the BUILT_IN_* names so differ from the actual function
names? I.e. why not use BUILT_IN_ASAN_{LOAD,STORE}{1,2,4,8,16,N}
(no underscore before N, no CHECK_)?
Makes sense.
Wouldn't it be better to do
...
so that you don't risk signed overflow? Maybe also
Yeah, that looks
On Tue, Jun 3, 2014 at 9:13 AM, Ilya Enkovich enkovich@gmail.com wrote:
Hi,
This patch preserves CALL_WITH_BOUNDS flag for calls during PRE.
Ok.
Richard.
Bootstrapped and tested on linux-x86_64.
Thanks,
Ilya
--
gcc/
2014-06-03 Ilya Enkovich ilya.enkov...@intel.com
*
On Tue, Jun 03, 2014 at 01:33:39PM +0400, Yury Gribov wrote:
Also note (but, already preexisting issue) is that the
__asan_report* and __asan_{load,store}* calls are declared in
sanitizer.def as having 1st argument PTR type, while in the library
it is uptr (aka PTRMODE). So, either we should
On Tue, Jun 3, 2014 at 1:33 PM, Yury Gribov y.gri...@samsung.com wrote:
Any reason why the BUILT_IN_* names so differ from the actual function
names? I.e. why not use BUILT_IN_ASAN_{LOAD,STORE}{1,2,4,8,16,N}
(no underscore before N, no CHECK_)?
Makes sense.
Wouldn't it be better to do
Hi,
This patch adds myself to the MAINTAINERS file. Commmitted as r211167.
The ChangeLog and patch are shown below.
Regards,
Andrew
Andrew Bennett
Software Design Engineer, MIPS Processor IP
Imagination Technologies Limited
t: +44 (0)113 2429814
www.imgtec.com
2014-06-03 Andrew Bennett
On Tue, 3 Jun 2014, Richard Biener wrote:
On Mon, 2 Jun 2014, Marc Glisse wrote:
(plus (bit_not @0) @0)
if (INTEGRAL_TYPE_P (TREE_TYPE (@0)))
{ build_int_cst (TREE_TYPE (@0), -1); })
+(match_and_simplify
+ (plus @0 (bit_not @0))
+ if (INTEGRAL_TYPE_P (TREE_TYPE (@0)))
+ {
On Tue, Jun 3, 2014 at 9:23 AM, Ilya Enkovich enkovich@gmail.com wrote:
Hi,
This patch adjusts alloc-free removal algorithm in DCE to take into account
BUILT_IN_CHKP_BNDRET call returning bounds of allocated memory.
Bootstrapped and tested on linux-x86_64.
Thanks,
Ilya
--
gcc/
On Tue, 3 Jun 2014, Marc Glisse wrote:
On Tue, 3 Jun 2014, Richard Biener wrote:
On Mon, 2 Jun 2014, Marc Glisse wrote:
(plus (bit_not @0) @0)
if (INTEGRAL_TYPE_P (TREE_TYPE (@0)))
{ build_int_cst (TREE_TYPE (@0), -1); })
+(match_and_simplify
+ (plus @0
On Tue, Jun 3, 2014 at 9:38 AM, Ilya Enkovich enkovich@gmail.com wrote:
Hi,
This patch allows BUILT_IN_CHKP_BNDRET as a consumer of a result of
BUILT_IN_STACK_SAVE call.
Bootstrapped and tested on linux-x86_64.
Thanks,
Ilya
--
gcc/
2014-06-03 Ilya Enkovich
Hi!
Ping -- OK to commit to trunk?
On Wed, 28 May 2014 23:55:31 +0200, Jan Hubicka hubi...@ucw.cz wrote:
On Mon, 26 May 2014 02:16:35 -0700, Andrew Pinski pins...@gmail.com wrote:
On Mon, May 26, 2014 at 1:59 AM, Dominique Dhumieres domi...@lps.ens.fr
wrote:
r210901 breaks bootstrap
Hi!
Ping.
On Thu, 22 May 2014 12:58:05 +0200, I wrote:
Ping.
On Fri, 14 Mar 2014 12:22:29 +0100, I wrote:
$ ../configure --enable-foo='--enable-a=1 --enable-b=2 --enable-c=3'
[...]
$ make configure-zlib
config.status: creating Makefile
config.status:
Ok, this fixes it. We'll output an ext...#0, which is little more than a MOV,
but that seems appropriate in the circumstance.
Regression tested check-gcc and check-g++ on aarch64-none-elf and
aarch64_be-none-elf.
Ok for trunk?
--Alan
Alan Lawrence wrote:
Yes, reproduced. Seems the mid-end
Hi Gerald,
On Tue, 27 May 2014, Mike Stump wrote:
So, I read the doc bits, and they look fine. I’m not a doc reviewer,
but, the changes are usual and customary for a port, and trivial.
Yes, and I'd like to emphasize this point: Just because a file
matches *.texi doesn't mean that ports,
Rainer Orth r...@cebitec.uni-bielefeld.de writes:
Joseph S. Myers jos...@codesourcery.com writes:
[...]
Thanks for the explanation. The driver changes are OK.
Thanks. I still need approval for the doc and build parts, as well as
the Darwin and DJGPP changes. For the latter two, I've
Ian Lance Taylor i...@google.com writes:
This patch to libgo, from Peter Collingbourne, changes some of the C
code to make it easier to compile libgo with a compiler other than GCC.
Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu.
Committed to mainline.
[...]
diff -r
2014-06-03 13:02 GMT+04:00 Richard Biener richard.guent...@gmail.com:
On Mon, Jun 2, 2014 at 5:22 PM, Ilya Enkovich enkovich@gmail.com wrote:
Hi,
This patch prevents output of both instrumented and not instrumented weakref
variants.
Shouldn't one of them be reclaimed instead at some
On Tue, Jun 3, 2014 at 10:11 AM, Eric Botcazou ebotca...@adacore.com wrote:
Looks mostly ok. Any reason why you are not re-creating
MINUS_EXPR in build_symbolic_expr? That is, build
inv - t (for non-pointers, of course)?
It's more uniform and compare_values expects an INTEGER_CST on the
On 28 May 2014 08:30, Bin.Cheng amker.ch...@gmail.com wrote:
Missing patch.
On Wed, May 28, 2014 at 3:02 PM, bin.cheng bin.ch...@arm.com wrote:
Hi,
I was surprised that GCC didn't support addressing modes like
[REG+OFF]/[REG_REG] for instructions ldr/str in vectorization scenarios.
The
On 3 June 2014 11:21, Alan Lawrence alan.lawre...@arm.com wrote:
Ok, this fixes it. We'll output an ext...#0, which is little more than a
MOV,
but that seems appropriate in the circumstance.
Regression tested check-gcc and check-g++ on aarch64-none-elf and
aarch64_be-none-elf.
Ok for
gcc/ChangeLog:
* config/aarch64/aarch64.c (aarch64_evpc_ext): Allow+handle location==0.
?
--Alan
Marcus Shawcroft wrote:
On 3 June 2014 11:21, Alan Lawrence alan.lawre...@arm.com wrote:
Ok, this fixes it. We'll output an ext...#0, which is little more than a
MOV,
but that seems
On 3 June 2014 12:19, Alan Lawrence alan.lawre...@arm.com wrote:
gcc/ChangeLog:
* config/aarch64/aarch64.c (aarch64_evpc_ext): Allow+handle
location==0.
?
Allow and handle location == 0.
Otherwise OK
/Marcus
2014-06-03 13:45 GMT+04:00 Richard Biener richard.guent...@gmail.com:
On Tue, Jun 3, 2014 at 9:23 AM, Ilya Enkovich enkovich@gmail.com wrote:
Hi,
This patch adjusts alloc-free removal algorithm in DCE to take into account
BUILT_IN_CHKP_BNDRET call returning bounds of allocated memory.
I've pushed this as r211174, after merging with the EXT changes (r211058): the
following instructions are equivalent
ext vdest.8b, vsrc.8b, vsrc.8b, #4
rev64 vdest.2s, vsrc.2s
and can both be output for a __builtin_shuffle mask of {1,0}. The latter seems
more readable and so I've put the call
On Tue, Jun 3, 2014 at 1:36 PM, Ilya Enkovich enkovich@gmail.com wrote:
2014-06-03 13:45 GMT+04:00 Richard Biener richard.guent...@gmail.com:
On Tue, Jun 3, 2014 at 9:23 AM, Ilya Enkovich enkovich@gmail.com wrote:
Hi,
This patch adjusts alloc-free removal algorithm in DCE to take into
Pushed as r211177.
Thanks, Alan
Marcus Shawcroft wrote:
On 3 June 2014 12:19, Alan Lawrence alan.lawre...@arm.com wrote:
gcc/ChangeLog:
* config/aarch64/aarch64.c (aarch64_evpc_ext): Allow+handle
location==0.
?
Allow and handle location == 0.
Otherwise OK
/Marcus
On Tue, 2014-06-03 at 08:41 +0200, Jakub Jelinek wrote:
On Tue, Jun 03, 2014 at 10:19:48AM +0400, Yury Gribov wrote:
I took that patch and applied it to the gcc sources,
but I still see the error on ppc:
...
[bergner@makalu-lp1 asan]$
The following arranges for complex C-expressions (multi-stmt ones)
in the transform pattern to be outlined to a separate function.
This avoids the need for using stmt expressions which are not
necessarily supported by all C++ host compilers.
The patch doesn't address the stmt expressions being
It adds -lasan early, but after the libraries and
object files that are explicitly added to the linker command.
Since -lm is explicitly added to the linker command, the implicitly
added -lasan comes after. The -v command is below.
Hm, -lasan manages to override user-specified -lm on gcc
On Tue, Jun 03, 2014 at 08:06:41AM -0500, Peter Bergner wrote:
On Tue, 2014-06-03 at 08:41 +0200, Jakub Jelinek wrote:
On Tue, Jun 03, 2014 at 10:19:48AM +0400, Yury Gribov wrote:
I took that patch and applied it to the gcc sources,
but I still see the error on ppc:
...
I've added a bug report for the stores group case:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61403
On Wed, May 28, 2014 at 5:18 PM, Evgeny Stupachenko evstu...@gmail.com wrote:
Ping.
Test is modified according to the fix in the test for loads.
diff --git
2014-06-03 15:56 GMT+04:00 Richard Biener richard.guent...@gmail.com:
On Tue, Jun 3, 2014 at 1:36 PM, Ilya Enkovich enkovich@gmail.com wrote:
2014-06-03 13:45 GMT+04:00 Richard Biener richard.guent...@gmail.com:
On Tue, Jun 3, 2014 at 9:23 AM, Ilya Enkovich enkovich@gmail.com
wrote:
On Tue, 2014-06-03 at 15:21 +0200, Jakub Jelinek wrote:
On Tue, Jun 03, 2014 at 08:06:41AM -0500, Peter Bergner wrote:
No LD_PRELOAD. It adds -lasan early, but after the libraries and
object files that are explicitly added to the linker command.
Since -lm is explicitly added to the linker
On Tue, Jun 3, 2014 at 3:27 PM, Ilya Enkovich enkovich@gmail.com wrote:
2014-06-03 15:56 GMT+04:00 Richard Biener richard.guent...@gmail.com:
On Tue, Jun 3, 2014 at 1:36 PM, Ilya Enkovich enkovich@gmail.com wrote:
2014-06-03 13:45 GMT+04:00 Richard Biener richard.guent...@gmail.com:
On
Hello,
apparently it is possible to have a PHI in the middle basic block of
value_replacement, so I need to move it as well when I move the statement
and remove the block.
Bootstrap and testsuite on x86_64-linux-gnu (re-running for various
reasons but they had completed successfully
Honza,
How can we make further progress with the large regression on AIX?
Thanks, David
On Fri, May 30, 2014 at 1:24 PM, David Edelsohn dje@gmail.com wrote:
Honza,
For example g++.dg/abi/vcall1.C fails at a call in a localalias
function, which jumps to a bad location:
(gdb) up
#1
Ping?
On Sat, 17 May 2014, Marc Glisse wrote:
Ping Jakub?
https://gcc.gnu.org/ml/gcc-patches/2014-04/msg01104.html
On Wed, 23 Apr 2014, Richard Biener wrote:
On Fri, Apr 18, 2014 at 8:27 PM, Marc Glisse marc.gli...@inria.fr wrote:
Thanks for the comments!
On Fri, 18 Apr 2014, Jakub
On Tue, Jun 3, 2014 at 3:48 PM, Marc Glisse marc.gli...@inria.fr wrote:
Hello,
apparently it is possible to have a PHI in the middle basic block of
value_replacement, so I need to move it as well when I move the statement
and remove the block.
Bootstrap and testsuite on x86_64-linux-gnu
Here the testcase defines std::initializer_list as a non-template class,
so looking up its argument fails. I don't want to get into a lot of
sanity checking for the definition of initializer_list, but this seems
simple enough.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit
2014-06-03 17:41 GMT+04:00 Richard Biener richard.guent...@gmail.com:
On Tue, Jun 3, 2014 at 3:27 PM, Ilya Enkovich enkovich@gmail.com wrote:
2014-06-03 15:56 GMT+04:00 Richard Biener richard.guent...@gmail.com:
On Tue, Jun 3, 2014 at 1:36 PM, Ilya Enkovich enkovich@gmail.com
wrote:
Hi,
Attached patch adds support for Atmel devices tiny441, tiny828 and tiny841.
Please commit if the patch is OK.
Note: This is continuation of patch attached in
https://gcc.gnu.org/ml/gcc-patches/2014-06/msg00049.html
Regards,
Pitchumani
gcc/ChangeLog
2014-06-03 Vishnu K S
Hi,
implementing the resolution seems rather straightforward, just check
LOOKUP_ONLYCONVERTING in standard_conversion. However, while playing
with some additional tests outside bug testsuite (similar to
nullptr32.C), I noticed a latent issue: in case of base initializers we
were setting
On Tue, 3 Jun 2014, Richard Biener wrote:
On Tue, Jun 3, 2014 at 3:48 PM, Marc Glisse marc.gli...@inria.fr wrote:
Hello,
apparently it is possible to have a PHI in the middle basic block of
value_replacement, so I need to move it as well when I move the statement
and remove the block.
.. wondering if I should check DECL_CONSTRUCTOR_P (fn) too.
Paolo.
On Mon, Jun 02, 2014 at 06:00:04PM -0400, Jason Merrill wrote:
On 05/24/2014 04:00 AM, Marek Polacek wrote:
+ /* Warn if the condition has boolean value. */
+ tree e = cond;
+ while (TREE_CODE (e) == COMPOUND_EXPR)
+e = TREE_OPERAND (e, 1);
+
+ if (TREE_CODE
On 06/03/2014 10:30 AM, Paolo Carlini wrote:
implementing the resolution seems rather straightforward, just check
LOOKUP_ONLYCONVERTING in standard_conversion.
Yep. Though it would be better to return a bad_p conversion than none
at all.
However, while playing
with some additional tests
Hi,
On 06/03/2014 05:02 PM, Jason Merrill wrote:
Right. In the case of
+ TDerived()
+ : TBaseT(nullptr) { }
we have direct-initialization of TBaseT, but the parameter of the
TBase constructor is copy-initialized, so nullptr32.C is ill-formed;
please drop this hunk of the patch.
Oops,
A small further tweak: let's try lookup first and when we do create a
new decl, stash it in local_specializations.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 92a208c9176551243e305e779c7aaa730cace8f5
Author: Jason Merrill ja...@redhat.com
Date: Tue Jun 3 10:09:23 2014 -0400
PR
On 06/03/2014 11:24 AM, Paolo Carlini wrote:
+ if (NULLPTR_TYPE_P (from) (flags LOOKUP_ONLYCONVERTING))
+ conv-bad_p = true;
Thanks. What kind of error message do we get with this change? Would
adding something to convert_like_real provide a more helpful diagnostic?
On 06/03/2014 10:57 AM, Marek Polacek wrote:
+ if (TREE_CODE (orig_type) == BOOLEAN_TYPE
+ || (truth_value_p (TREE_CODE (cond))
+ TREE_CODE (orig_type) != INTEGER_TYPE))
I don't think you need the truth_value_p check, either, just the
BOOLEAN_TYPE check.
On Tue, Jun 03, 2014 at 11:46:35AM -0400, Jason Merrill wrote:
On 06/03/2014 10:57 AM, Marek Polacek wrote:
+ if (TREE_CODE (orig_type) == BOOLEAN_TYPE
+ || (truth_value_p (TREE_CODE (cond))
+ TREE_CODE (orig_type) != INTEGER_TYPE))
I don't think you need the
Hi,
in PR 61340 it has been reported that clang warns about unhandeld enum
values in a switch (gcc does not, I guess I'll open a new PR for
that).
Fixed thusly by adding a default label with a gcc_unreachable() in
both. The potentially unhandled enum value in both cases is
IPA_REF_ALIAS which
For shadowed declaration note we were calling warning_at, while we
should use inform.
Regtested/bootstrapped on x86_64-linux, ok for trunk?
2014-06-03 Marek Polacek pola...@redhat.com
PR c/48062
* c-decl.c (warn_if_shadowing): Call inform instead of warning_at.
*
On Tue, Jun 03, 2014 at 06:01:57PM +0200, Marek Polacek wrote:
For shadowed declaration note we were calling warning_at, while we
should use inform.
Regtested/bootstrapped on x86_64-linux, ok for trunk?
Shouldn't you remember the return value from warning/warning_at calls
which fall through
On Mon, Jun 2, 2014 at 8:59 PM, Jan Hubicka hubi...@ucw.cz wrote:
Yeah, I discussed this with martin today on irc. For aliasing we'd like
to know whether a decl possibly has its address taken. Currently we only
trust TREE_ADDRESSABLE for statics - and lto might change those to hidden
On Jun 3, 2014, at 3:40 AM, Rainer Orth r...@cebitec.uni-bielefeld.de wrote:
It's been another week, and I still need approval for the build, doc,
and Darwin changes:
So, the darwin bits look trivial enough, if the entire scheme is what people
want to do. My question would be, why do we want
2014-06-03 18:26 GMT+04:00 S, Pitchumani pitchuman...@atmel.com:
Hi,
Attached patch adds support for Atmel devices tiny441, tiny828 and tiny841.
Please commit if the patch is OK.
Note: This is continuation of patch attached in
https://gcc.gnu.org/ml/gcc-patches/2014-06/msg00049.html
2014-06-02 13:47 GMT+04:00 S, Pitchumani pitchuman...@atmel.com:
Hi,
Attached patch adds support for Atmel ATA devices (ata6616c,
ata6617c, ata664251, ata6612c, ata6613c and ata6614q).
Please commit if the patch is OK. I do not have commit access.
Regards,
Pitchumani
gcc/ChangeLog
Hi,
On 06/03/2014 05:41 PM, Jason Merrill wrote:
On 06/03/2014 11:24 AM, Paolo Carlini wrote:
+ if (NULLPTR_TYPE_P (from) (flags LOOKUP_ONLYCONVERTING))
+conv-bad_p = true;
Thanks. What kind of error message do we get with this change? Would
adding something to
On Tue, Jun 03, 2014 at 06:07:03PM +0200, Jakub Jelinek wrote:
On Tue, Jun 03, 2014 at 06:01:57PM +0200, Marek Polacek wrote:
For shadowed declaration note we were calling warning_at, while we
should use inform.
Regtested/bootstrapped on x86_64-linux, ok for trunk?
Shouldn't you
On 3 June 2014 12:08, Marcus Shawcroft marcus.shawcr...@gmail.com wrote:
On 28 May 2014 08:30, Bin.Cheng amker.ch...@gmail.com wrote:
So is it OK?
2014-05-28 Bin Cheng bin.ch...@arm.com
* config/aarch64/aarch64.c (aarch64_classify_address)
OK.
Jason
OK, thanks.
Jason
On 3 Jun 2014, at 18:08, Charles Baylis charles.bay...@linaro.org wrote:
On 3 June 2014 12:08, Marcus Shawcroft marcus.shawcr...@gmail.com wrote:
On 28 May 2014 08:30, Bin.Cheng amker.ch...@gmail.com wrote:
So is it OK?
2014-05-28 Bin Cheng bin.ch...@arm.com
*
On 06/03/14 08:08, Richard Biener wrote:
On Tue, Jun 3, 2014 at 3:48 PM, Marc Glisse marc.gli...@inria.fr wrote:
Hello,
apparently it is possible to have a PHI in the middle basic block of
value_replacement, so I need to move it as well when I move the statement
and remove the block.
Hello!
When configured with --with-arch=core-avx-i --with-cpu=core-avx-i,
g++.dg/ext/mv[14,15].C tests fail on corei7 [1] since the default CPU
is the same as the checked cpu in the test. The patch compiles the
testcase with -march=x86-64 as the generic CPU
2014-06-03 Uros Bizjak
Hello,
this patch fixes a nit detected in ix86_function_value_regno_p. For
x64 ms-abi we don't have DX_REG-register as valid function-value
register.
ChangeLog
2014-06-03 Kai Tietz kti...@redhat.com
* config/i386/i386.c (ix86_function_value_regno_p): Disallow DX_REG for
Matthew Fortune matthew.fort...@imgtec.com writes:
Mike Stump mikest...@comcast.net writes:
On May 28, 2014, at 7:27 AM, Richard Earnshaw rearn...@arm.com wrote:
Speed of implementation. We're gradually replacing these with proper
builtins, but that takes a lot more work.
As an owner
Sandra Loosemore san...@codesourcery.com writes:
Catherine included an earlier version of this patch with the microMIPS
submission a couple years ago:
https://gcc.gnu.org/ml/gcc-patches/2012-07/msg00972.html
Richard's response was:
Looks like the wrong place to do this. Please treat this
Hi,
in PR 61340 it has been reported that clang warns about unhandeld enum
values in a switch (gcc does not, I guess I'll open a new PR for
that).
Fixed thusly by adding a default label with a gcc_unreachable() in
both. The potentially unhandled enum value in both cases is
On 05/27/2014 04:01 PM, Tobias Burnus wrote:
Bernd Schmidt wrote:
Compiling Fortran code with the ptx backend I'm working on results in
assembler warnings about mismatch between function calls and function decls.
Bootstrapped and tested on x86_64-linux. Ok?
OK.
The change/bug is due to my
1 - 100 of 125 matches
Mail list logo
