Hi all,
Asan pass currently ICEs if it sees int arguments used in
memcmp/memset/etc. functions (it expects uintptr_t there). Attached
patch fixes this.
Related bugreports:
* https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62140
* https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61897
Ok to commit?
On 08/22/2014 12:47 PM, Yury Gribov wrote:
Attached patch fixes this.
As usual I forgot to mention tests: this was bootstrapped on x64 and
regtested for x64 and i686 and also Asan-bootstrapped for x64.
-Y
On Sun, 2014-08-17 14:05:24 +0200, Manuel López-Ibáñez lopeziba...@gmail.com
wrote:
[...]
In config-list.mk, it says Make sure you have a recent enough gcc
(with ada support) in your path so that --enable-werror-always will
work For this commit in particular, recent enough means exactly the
Updated patch covering all comments from the previous thread:
https://gcc.gnu.org/ml/gcc-patches/2014-05/msg00401.html
This patch has merged together the odd-spreg work with the other ABI
work as these two features are now inseparable due to the inclusion of
a 4th FP ABI variant called FP64A. The
Hello,
This patch extends shift patterns with per-element
shift value. It was adopted by approach suggested
in previous patches.
Bootstrapped.
New tests on top of patch-set all pass
under simulator.
Is it ok for trunk?
gcc/
* config/i386/sse.md
(define_mode_iterator
OK with the documentation change and with the re-named option. Please
also update the name in the code.
changes made and committed as r214311
Using Common for Wdate-time when it is defined in c.opt does not
really make sense and breaks CPP(). I also took the opportunity to
move a duplicated testcase to c-c++-common.
(svn diff does not show the move).
Bootstrapped and regression tested on x86_64-linux-gnu.
OK?
gcc/c-family/ChangeLog:
Hi all,
The Cortex-A53 scheduler description is missing rules for insn types used by instructions
such as vrint*, vmaxnm, vminnm causing them to be assigned to the nothing
unit.
This patch causes such instructions to be treated the same way as other simple
FPU instructions.
Bootstrapped and
Hi,
When testing, I've noticed, that Asan-bootstrapped GCC should be
executed with ASAN_OPTIONS=detect_leaks=0 because of memory leaks in
GCC, reported by Leak Sanitizer.
When I ran Asan test on Asan-bootstrapped GCC, some of them fail with
memory leaks into GCC, even if Lsan is disabled.
On Fri, 22 Aug 2014, DJ Delorie wrote:
Maybe you need to refactor __glibcxx_digits so there is a version taking
the bitsize as an argument rather than using sizeof(T) * __CHAR_BIT__, but
that should be the only change needed to handle such types with the
existing macros. The bitsize
This patch fixes PR 61360.
The attribute enabled should actually be used enable/disable alternative
based on sub-targets.
In this pattern, it gets used across passes too.
However, modifying this attribute in LRA pass is not something it is meant for.
This patch allows enabling/disabling the
Hello,
This patch extends unaligned loads and stores patterns.
I've refactored original patch (stored on SVN's branch)
toward reducing complexity of conditions in
define_insn avx512_storedqumode_mask
It seems like such a trick won't work for:
sse2_avx_avx512f_loaddqumodemask_name
Problem
On Sat, 2014-07-26 13:31:42 -0400, Hans-Peter Nilsson h...@bitrange.com wrote:
On Fri, 25 Jul 2014, Hans-Peter Nilsson wrote:
Anyway, on to the point of this message: by the quoted list it
seems you have a local host called pluto using 4.9.1 as the host
gcc for some build; does
On 28/06/14 11:25, Marc Glisse wrote:
On Mon, 23 Jun 2014, Tejas Belagod wrote:
Here is a patch that restructures neon builtins to use vector types based on
standard base types. We previously defined arm_neon.h's neon vector
types(int8x8_t) using gcc's front-end vector extensions. We now move
On 27/06/14 17:01, Yufeng Zhang wrote:
On 27 June 2014 16:32, Tejas Belagod tbela...@arm.com wrote:
2014-06-23 Tejas Belagod tejas.bela...@arm.com
diff --git a/gcc/config/aarch64/aarch64-simd-builtin-types.def
b/gcc/config/aarch64/aarch64-simd-builtin-types.def
new file mode 100644
index
On 04/07/14 15:27, James Greenhalgh wrote:
On Fri, Jun 27, 2014 at 04:32:19PM +0100, Tejas Belagod wrote:
+/* Internal scalar builtin types. These types are used to support
+ neon intrinsic builtins. They are _not_ user-visible types. Therefore
+ the mangling for these types are
On 07/29/2014 12:36 AM, Joseph S. Myers wrote:
On Thu, 24 Jul 2014, Jakub Jelinek wrote:
Yeah. I believe gcc.c-torture/compile/ has been converted already,
so it is just about gcc.c-torture/execute/. Each of these tests has
it's own default idioms, e.g. -w in by default in gcc.c-torture/.
Hi,
On Cauldron 2014 we had a couple of talks about relaxation of ebx usage in
32bit PIC mode. It was decided that the best approach would be to not fix ebx
register, use speudo register for GOT base address and let allocator do the
rest. This should be similar to how clang and icc work with
On 08/13/2014 02:25 PM, Ilya Enkovich wrote:
Hi,
This patch is to fix wrong refactoring for cgraph_node::function_symbol
introduced by this patch:
https://gcc.gnu.org/ml/gcc-cvs/2014-07/msg00805.html. Here is how function
was refactored:
-cgraph_function_node (struct cgraph_node *node,
On Thu, Aug 21, 2014 at 3:30 PM, Michael Meissner
meiss...@linux.vnet.ibm.com wrote:
(I'm not sure if an earlier patch got mailed out, I'm sorry if there are
duplicate postings).
I had a thinko in my patch on August 11th, in that I allowed the wi constraint
to be FLOAT_REGS on a non-VSX
On Fri, 22 Aug 2014, Tejas Belagod wrote:
On 28/06/14 11:25, Marc Glisse wrote:
On Mon, 23 Jun 2014, Tejas Belagod wrote:
Here is a patch that restructures neon builtins to use vector types based
on
standard base types. We previously defined arm_neon.h's neon vector
types(int8x8_t) using
On 08/19/2014 04:31 PM, Yury Gribov wrote:
On 08/19/2014 03:37 PM, Dominique Dhumieres wrote:
Makes sense, I've attached new patch (retested as usual).
Well, you probably did not test with -m32:
Right, I only did plain make check until now. Thanks for reporting,
I'll check this tomorrow.
On 12/08/14 10:55, Alan Lawrence wrote:
Following patch replaces the current temporary inline assembler
implementation
of vget_high. So this patch adds a test first. We don't have any test
coverage
of vget_low, either, so add that too.
Passing on aarch64-none-elf and
On Fri, Aug 22, 2014 at 01:11:28AM +0200, Gerald Pfeifer wrote:
+ licode-fsanitize=float-cast-overflow/code: check that the
result
+ of floating-point type to integer conversion does not overflow;/li
conversions (plural)?
Ok, changed.
+liA new code-Wswitch-bool/code
On Thu, Aug 21, 2014 at 02:34:54PM -0400, Jason Merrill wrote:
On 08/21/2014 11:41 AM, Marek Polacek wrote:
+ current.lhs_type = cp_lexer_next_token_is (parser-lexer, CPP_NOT)
+ ? TRUTH_NOT_EXPR : ERROR_MARK;
...
+ rhs_type = cp_lexer_next_token_is (parser-lexer,
On Thu, Aug 21, 2014 at 03:38:25PM -0400, Vladimir Makarov wrote:
Sorry, Marek. I guess it is wrong. STACK_GROWS_DOWNWARD is only 0 or 1
in these files (it is achieved by redefinition of STACK_GROWS_DOWNWARD
in the files). FAME_GROWS_DOWNWARD can be 0 or anything non-zero (even
HI,
On 08/22/2014 04:48 PM, Marek Polacek wrote:
+ current.lhs_type = (cp_lexer_next_token_is (parser-lexer, CPP_NOT))
+? TRUTH_NOT_EXPR : ERROR_MARK;
IMHO, you want to close the parenthesis later, right before the semicolon.
Paolo.
On 08/13/2014 01:41 PM, Tobias Burnus wrote:
Cesar Philippidis wrote:
According to section 2.6.1 in the openacc spec, fortran loop variables
should be implicitly private like in openmp. This patch does just so.
Makes sense. Looking at the patch, I wonder whether the context is
properly
On 2014-08-22 10:51 AM, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-linux, ok for trunk?
Ok. Thanks, Marek.
2014-08-22 Marek Polacek pola...@redhat.com
PR c/61271
* ira-color.c (coalesced_pseudo_reg_slot_compare): Wrap LHS of
a comparison in parens.
On Thu, 21 Aug 2014, Mike Stump wrote:
1 - I use n843 for C99, which is slightly different from the standard, but in
this case I suspect it is the same.
Use N1256 (C99+TC1+TC2+TC3) instead.
--
Joseph S. Myers
jos...@codesourcery.com
On 08/21/2014 04:31 PM, Jan Hubicka wrote:
Hello,
following patch introduces a new symbol_table class, encapsulating
functions related to symbol table management. Apart from that, cgraph_edge
related functions become members of the class. Finally, a portion of
clean-up has been
On Fri, 22 Aug 2014, Manuel L?pez-Ib??ez wrote:
Using Common for Wdate-time when it is defined in c.opt does not
really make sense and breaks CPP(). I also took the opportunity to
move a duplicated testcase to c-c++-common.
(svn diff does not show the move).
Bootstrapped and regression
On Fri, Aug 22, 2014 at 04:53:53PM +0200, Paolo Carlini wrote:
HI,
On 08/22/2014 04:48 PM, Marek Polacek wrote:
+ current.lhs_type = (cp_lexer_next_token_is (parser-lexer, CPP_NOT))
+ ? TRUTH_NOT_EXPR : ERROR_MARK;
IMHO, you want to close the parenthesis later, right before
2014-08-20 18:36 GMT+04:00 Sivanupandi, Pitchumani
pitchumani.sivanupa...@atmel.com:
Attached patch removes avr devices that are not released
(may not be released in near future also).
If OK, could someone commit please?
Regards,
Pitchumani
gcc/ChangeLog
2014-08-20 Pitchumani
On 08/22/2014 11:59 AM, Marek Polacek wrote:
+ if (TREE_CODE (current.lhs) == INTEGER_CST)
+ warn_logical_not_parentheses (current.loc, current.tree_type,
+ current.lhs, rhs);
+ else if (EXPR_P (current.lhs))
+
On Fri, Aug 22, 2014 at 12:24:16PM -0400, Jason Merrill wrote:
On 08/22/2014 11:59 AM, Marek Polacek wrote:
+ if (TREE_CODE (current.lhs) == INTEGER_CST)
+warn_logical_not_parentheses (current.loc, current.tree_type,
+ current.lhs, rhs);
+
On 08/22/2014 12:33 PM, Marek Polacek wrote:
On Fri, Aug 22, 2014 at 12:24:16PM -0400, Jason Merrill wrote:
Sorry to nitpick, but now that we aren't checking the lhs for BOOLEAN_TYPE,
do we need to look at it at all?
I believe so: if the LHS is an INTEGER_CST, we can't use TREE_OPERAND
on it.
On Aug 22, 2014, at 8:42 AM, Joseph S. Myers jos...@codesourcery.com wrote:
On Thu, 21 Aug 2014, Mike Stump wrote:
1 - I use n843 for C99, which is slightly different from the standard, but
in this case I suspect it is the same.
Use N1256 (C99+TC1+TC2+TC3) instead.
Thanks. I had the
Hi,
maybe this old issue is already fixed. We used to ICE on:
typedef void (*fptr)() __attribute((noreturn));
templateint void foo();
templatefptr void bar();
fptr f = bar foo0 ;
but lately we simply reject it:
34938.C:5:10: error: no matches converting function ‘bar’ to type ‘fptr
{aka
On 08/22/2014 01:53 PM, Paolo Carlini wrote:
maybe this old issue is already fixed. We used to ICE on:
typedef void (*fptr)() __attribute((noreturn));
templateint void foo();
templatefptr void bar();
fptr f = bar foo0 ;
but lately we simply reject it:
34938.C:5:10: error: no matches
On 22 August 2014 00:22, Paolo Carlini paolo.carl...@oracle.com wrote:
Hi,
On 08/22/2014 12:01 AM, Manuel López-Ibáñez wrote:
On 21 August 2014 23:35, Jason Merrill ja...@redhat.com wrote:
On 08/21/2014 04:22 PM, Manuel López-Ibáńez wrote:
+TREE_CODE (x) !=
On 08/22/2014 02:24 PM, Manuel López-Ibáñez wrote:
+ DECL_P(member))
Missing space before paren.
OK with that fixed.
Jason
On Fri, Aug 22, 2014 at 12:52:51PM -0400, Jason Merrill wrote:
On 08/22/2014 12:33 PM, Marek Polacek wrote:
On Fri, Aug 22, 2014 at 12:24:16PM -0400, Jason Merrill wrote:
Sorry to nitpick, but now that we aren't checking the lhs for BOOLEAN_TYPE,
do we need to look at it at all?
I believe
OK, thanks.
Jason
Hi,
On 08/22/2014 08:17 PM, Jason Merrill wrote:
On 08/22/2014 01:53 PM, Paolo Carlini wrote:
maybe this old issue is already fixed. We used to ICE on:
typedef void (*fptr)() __attribute((noreturn));
templateint void foo();
templatefptr void bar();
fptr f = bar foo0 ;
but lately we simply
Maybe you need to refactor __glibcxx_digits so there is a version taking
the bitsize as an argument rather than using sizeof(T) * __CHAR_BIT__,
but
that should be the only change needed to handle such types with the
existing macros. The bitsize macros should be the only ones
On 08/22/2014 03:19 PM, Paolo Carlini wrote:
Ok. Currently in cases like the present one, dump_type_suffix upon a
pointer recurses and we end up calling pp_cxx_cv_qualifiers on the given
FUNCTION_TYPE / METHOD_TYPE. Thus pp_cxx_cv_qualifiers lacks the pointer
context, just sees the latter. Do
On 08/22/2014 03:24 PM, Marc Glisse wrote:
Note that there is a patch waiting for a review that makes us accept !v
for vector v:
Ah, indeed. I still think we might as well treat vectors the same as
other types here.
Jason
Hi,
On 08/22/2014 09:27 PM, Jason Merrill wrote:
On 08/22/2014 03:19 PM, Paolo Carlini wrote:
Ok. Currently in cases like the present one, dump_type_suffix upon a
pointer recurses and we end up calling pp_cxx_cv_qualifiers on the given
FUNCTION_TYPE / METHOD_TYPE. Thus pp_cxx_cv_qualifiers
On Fri, 22 Aug 2014, Marek Polacek wrote:
On Fri, Aug 22, 2014 at 12:52:51PM -0400, Jason Merrill wrote:
On 08/22/2014 12:33 PM, Marek Polacek wrote:
On Fri, Aug 22, 2014 at 12:24:16PM -0400, Jason Merrill wrote:
Sorry to nitpick, but now that we aren't checking the lhs for BOOLEAN_TYPE,
do
On 22 August 2014 21:33, Paolo Carlini paolo.carl...@oracle.com wrote:
Incidentally, I don't understand
+ pp_c_ws_string (pp, (func_type !method_type
vs
+ pp_c_ws_string (pp, (func_type || method_type
Surely the same logic is appropriate for both const and noreturn, and they
On Fri, 22 Aug 2014, Jason Merrill wrote:
On 08/22/2014 03:24 PM, Marc Glisse wrote:
Note that there is a patch waiting for a review that makes us accept !v
for vector v:
Ah, indeed. I still think we might as well treat vectors the same as other
types here.
Ok, now that it is a conscious
On 08/22/2014 03:47 PM, Manuel López-Ibáñez wrote:
Are there actually cases where the qualifiers mean different things
for function_type and method_type?
If a FUNCTION_TYPE is a typedef or template argument, TYPE_READONLY and
TYPE_VOLATILE are the function-cv-quals. A plain METHOD_TYPE
Richard Biener wrote:
On Wed, Aug 20, 2014 at 10:29 PM, Sebastian Pop seb...@gmail.com wrote:
James Greenhalgh wrote:
On Tue, Aug 19, 2014 at 09:39:56PM +0100, Steve Ellcey wrote:
Here is an official submission for the switch optimization described in
PR 54742. I have addressed the
On Fri, 22 Aug 2014, DJ Delorie wrote:
Maybe you need to refactor __glibcxx_digits so there is a version
taking
the bitsize as an argument rather than using sizeof(T) * __CHAR_BIT__,
but
that should be the only change needed to handle such types with the
existing
I don't see flag_iso as relevant here (since the macros are in the
implementation namespace). The definitions could reasonably be restricted
to c_dialect_cxx (), though, given that they are specifically for use by
libstdc++ (and it's easier to add a macro later for C if needed, than to
Hi again,
On 08/22/2014 09:33 PM, Paolo Carlini wrote:
Hi,
On 08/22/2014 09:27 PM, Jason Merrill wrote:
On 08/22/2014 03:19 PM, Paolo Carlini wrote:
Ok. Currently in cases like the present one, dump_type_suffix upon a
pointer recurses and we end up calling pp_cxx_cv_qualifiers on the
given
OK, thanks.
Jason
On Aug 22, 2014, at 5:18 AM, Bernd Schmidt ber...@codesourcery.com wrote:
Here's another attempt.
Ok?
Ok. Thanks a ton for doing the work.
The resolutions look fine, the translation looks good.
Before you check it in, consider:
930529-1.x has some alpha bits but I didn’t notice a
Does your patch handle this correctly?
template class T struct A { };
Avoid()const*p = 42;
Jason
On Nov 1, 2013, at 3:11 PM, tsaund...@mozilla.com wrote:
From: tbsaunde tbsaunde@138bc75d-0d04-0410-961f-82ee72b054a4
diff --git a/ChangeLog b/ChangeLog
index e925959..8c24d35 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,7 @@
+2013-11-01 Trevor Saunders tsaund...@mozilla.com
+
+*
PR 60606 reports an ICE on ARM when declaring a register variable in
register pc. Discussion in that bug suggests this usage should be
considered invalid and give an error. It turns out similar ICEs also
occur (after errors) for other cases of invalid register variables.
This patch fixes at
Hi,
On 08/22/2014 10:45 PM, Jason Merrill wrote:
Does your patch handle this correctly?
template class T struct A { };
Avoid()const*p = 42;
I would say yes:
34938_2.C:2:20: error: invalid conversion from ‘int’ to ‘Avoid()
const*’ [-fpermissive]
Avoid()const*p = 42;
But, interestingly, in
On Aug 21, 2014, at 6:33 PM, Tony Wang tony.w...@arm.com wrote:
Thanks for your reply, and I also thought of your suggestion to wrap the
_exit. The fact is that dejagnu does
the wrapper to both exit() and _exit(), but it give a higher priority to the
exit(), which means if you both
call
Delay cfi restore opcodes until the stack frame is deallocated.
This reduces the number of cfi advance opcodes required.
We perform a similar optimization in the x86_64 epilogue.
* config/aarch64/aarch64.c (aarch64_popwb_single_reg): Remove.
(aarch64_popwb_pair_reg): Remove.
Generic code already handles calls_alloca for determining
the need for a frame pointer.
* config/aarch64/aarch64.c (aarch64_frame_pointer_required): Don't
check calls_alloca.
---
gcc/config/aarch64/aarch64.c | 5 -
1 file changed, 5 deletions(-)
diff --git
We were marking more than necessary in aarch64_set_frame_expr.
Fold the reduced function into aarch64_expand_prologue as necessary.
* config/aarch64/aarch64.c (aarch64_set_frame_expr): Remove.
(aarch64_expand_prologue): Use REG_CFA_ADJUST_CFA directly,
or no special markup
... and other cleanups to the prologue and epilogue functions.
Moving around the epilogue .cfi_restore ops, in particular, is worth
several percentage points in the size of .eh_frame / .debug_frame.
The last numbers I have for this aren't quite comparible, since when
I collected them I was also
Don't continually re-read data from cfun-machine.
* config/aarch64/aarch64.c (aarch64_expand_prologue): Load
cfun-machine-frame.hard_fp_offset into a local variable.
---
gcc/config/aarch64/aarch64.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git
On Thu, 21 Aug 2014, Mike Stump wrote:
On Aug 21, 2014, at 10:59 AM, Sandra Loosemore san...@codesourcery.com
wrote:
On 08/21/2014 11:36 AM, Mike Stump wrote:
On Aug 21, 2014, at 8:00 AM, Sandra Loosemore
san...@codesourcery.com wrote:
tests that assume some non-default branch costs in
(Dropping gcc@ and people known to subscribe to gcc-patches
from the CC.)
Sorry for the drive-by review, but...
On Fri, 22 Aug 2014, Ilya Enkovich wrote:
Hi,
On Cauldron 2014 we had a couple of talks about relaxation of
ebx usage in 32bit PIC mode. It was decided that the best
approach
71 matches
Mail list logo
