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
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
> same revision".
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 VI48_AVX2_48_
> 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 an
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. Th
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 bi
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 at
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 "_storedqu_mask"
It seems like such a trick won't work for:
_loaddqu
Problem is V[32|16]QI modes, which enabled for
On Sat, 2014-07-26 13:31:42 -0400, Hans-Peter Nilsson 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 config-list.mk work for
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 a
On 27/06/14 17:01, Yufeng Zhang wrote:
On 27 June 2014 16:32, Tejas Belagod wrote:
2014-06-23 Tejas Belagod
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 000..aa6a84e
--- /dev/null
+++ b/gcc
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 implement
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/.
Us
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
On Thu, Aug 21, 2014 at 3:30 PM, Michael Meissner
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 system, but I had a pattern
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 gcc
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 aarch64_be
On Fri, Aug 22, 2014 at 01:11:28AM +0200, Gerald Pfeifer wrote:
> > + -fsanitize=float-cast-overflow: check that the
> > result
> > + of floating-point type to integer conversion does not overflow;
>
> "conversions" (plural)?
Ok, changed.
> > +A new -Wswitch-bool option has been
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
> non-const
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
> proper
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
PR c/61271
* ira-color.c (coalesced_pseudo_reg_slot_compare): Wrap LHS of
a comparison in parens.
* lra-spills.c
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
> >> cl
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 regressio
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, righ
2014-08-20 18:36 GMT+04:00 Sivanupandi, Pitchumani
:
> 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 Sivanupandi
>
> * config/a
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))
+ warn_logic
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 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 C99.pdf to quote from,
Hi,
maybe this old issue is already fixed. We used to ICE on:
typedef void (*fptr)() __attribute((noreturn));
template void foo();
template void bar();
fptr f = bar< foo<0> >;
but lately we simply reject it:
34938.C:5:10: error: no matches converting function ‘bar’ to type ‘fptr
{aka void (*
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));
template void foo();
template void bar();
fptr f = bar< foo<0> >;
but lately we simply reject it:
34938.C:5:10: error: no matches converting f
On 22 August 2014 00:22, Paolo Carlini wrote:
> Hi,
>
>
> On 08/22/2014 12:01 AM, Manuel López-Ibáñez wrote:
>>
>> On 21 August 2014 23:35, Jason Merrill wrote:
>>>
>>> On 08/21/2014 04:22 PM, Manuel López-Ibáńez wrote:
+ && TREE_CODE (x) != FUNCTION_DECL
+
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?
> >
>
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));
template void foo();
template void bar();
fptr f = bar< foo<0> >;
but lately we simply rejec
> > > 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 t
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 you
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 lack
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 w
On 22 August 2014 21:33, Paolo Carlini 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 cannot
Richard Biener wrote:
> On Wed, Aug 20, 2014 at 10:29 PM, Sebastian Pop 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 format
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
> 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
F
OK, thanks.
Jason
On Aug 22, 2014, at 5:18 AM, Bernd Schmidt 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 discussion nor do I have
Does your patch handle this correctly?
template struct A { };
A*p = 42;
Jason
On Nov 1, 2013, at 3:11 PM, tsaund...@mozilla.com wrote:
> From: tbsaunde
>
> diff --git a/ChangeLog b/ChangeLog
> index e925959..8c24d35 100644
> --- a/ChangeLog
> +++ b/ChangeLog
> @@ -1,3 +1,7 @@
> +2013-11-01 Trevor Saunders
> +
> +* MAINTAINERS (Write After Approval): Add myself.
> +
> 20
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 leas
Hi,
On 08/22/2014 10:45 PM, Jason Merrill wrote:
Does your patch handle this correctly?
template struct A { };
A*p = 42;
I would say yes:
34938_2.C:2:20: error: invalid conversion from ‘int’ to ‘Aconst>*’ [-fpermissive]
A*p = 42;
But, interestingly, in this case 4.8.x was incorrect, this
On Aug 21, 2014, at 6:33 PM, Tony Wang 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 exit() and _exit
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 a/gcc/config/aarch6
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 d
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 --gi
On Thu, 21 Aug 2014, Mike Stump wrote:
> On Aug 21, 2014, at 10:59 AM, Sandra Loosemore
> wrote:
> > On 08/21/2014 11:36 AM, Mike Stump wrote:
> >> On Aug 21, 2014, at 8:00 AM, Sandra Loosemore
> >> wrote:
> >>> tests that assume some non-default branch costs in the back end
> >>
> >> Thanks.
>
(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
Since nobody else seemed to be working on finishing up variable template
support, I've gone ahead and done it. There were only a few tweaks needed.
For the pr59638.C issue, I'm throwing away the implicit template
parameter list before we call start_decl so we don't actually create an
implicit
72 matches
Mail list logo
