Re: [RFC][SSA] Iterator to visit SSA

Hi Richard, On 5 September 2016 at 17:57, Richard Biener wrote: > On Mon, Sep 5, 2016 at 7:26 AM, Kugan Vivekanandarajah > wrote: >> Hi All, >> >> While looking at gcc source, I noticed that we are iterating over SSA >> variable

Re: [PATCH] Delete GCJ

On 9/5/16, Bernd Edlinger wrote: > On 05.09.2016 17:13, Andrew Haley wrote: > > As discussed. I think I should ask a Global reviewer to approve this > > one. For obvious reasons I haven't included the diffs to the deleted > > gcc/java and libjava directories. The

Re: [PATCH, i386] Spellcheck hints for the i386 backend option handling (PR middle-end/77475)

On Mon, 2016-09-05 at 21:00 +0200, Uros Bizjak wrote: > On Mon, Sep 5, 2016 at 7:25 PM, Jakub Jelinek > wrote: > > Hi! > > > > While most of the i386.opt -m= options have enum args and thus > > cmdline_handle_error handles those, -march=/-mtune=/-m*-strategy= > > (and also

Re: [PATCH] Fix template-params-12f.C on darwin/vxworks (PR debug/77389)

On Sep 4, 2016, at 10:23 AM, Dominique d'Humières wrote: > > The same should apply to g++.dg/debug/dwarf2/template-params-12g.C: > > --- ../_clean/gcc/testsuite/g++.dg/debug/dwarf2/template-params-12g.C > 2016-08-12 09:59:34.0 +0200 > +++

Re: [PATCH] Delete GCJ

On 05.09.2016 17:13, Andrew Haley wrote: > As discussed. I think I should ask a Global reviewer to approve this > one. For obvious reasons I haven't included the diffs to the deleted > gcc/java and libjava directories. The whole tree, post GCJ-deletion, > is at

[PATCH] Fix a few simple cases where -Wparentheses does not warn for omitted middle value

Hi, I've noticed that there is already a -Wparentheses warning for code like int y = x == 2 ?: 1 => warning: the omitted middle operand in ?: will always be 'true', suggest explicit middle operand [-Wparentheses] But it is not emitted for code that uses bool, like: void foo(bool x) { int

Re: [GCC][PATCH] Add __artificial__ attribute to Aarch64 NEON intrinsics

On Mon, Sep 5, 2016 at 4:53 AM, Tamar Christina wrote: > Hi all, > > This patch adds __artificial__ attribute to the intrinsics > in arm_neon.h so that costs are associated to the user > function during profiling and during the intrinsics are > are hidden in trace. > >

[committed] Fix check_effective_target_vect_simd_clones comment

Hi! I've noticed the comment in check_effective_target_vect_simd_clones doesn't match the reality, fixed thusly, committed to trunk as obvious. 2016-09-05 Jakub Jelinek * lib/target-supports.exp (check_effective_target_vect_simd_clones): Update comment to

[committed] Cherry-pick asan fix (PR sanitizer/77396)

Hi! Upstream has accepted my fix, so I've cherry-picked it to trunk and added another testcase, bootstrapped/regtested on x86_64-linux and i686-linux, committed to trunk. 2016-09-05 Jakub Jelinek PR sanitizer/77396 * asan/asan_globals.cc: Cherry-pick

Re: [MPX] Fix for PR77267

2016-09-05 12:56 GMT+03:00 Alexander Ivchenko : > Ok, thanks. The full updated patch is below. I also removed the > '--whole-archive' thing from -static-libmpxwrappers case. This version is OK for trunk with proper ChangeLog and after proper testing. > Would that be possible

Re: [PATCH, i386] Spellcheck hints for the i386 backend option handling (PR middle-end/77475)

On 05/09/16 20:42, Manuel López-Ibáñez wrote: On 05/09/16 18:25, Jakub Jelinek wrote: Hi! While most of the i386.opt -m= options have enum args and thus cmdline_handle_error handles those, -march=/-mtune=/-m*-strategy= (and also -mrecip=) don't use that, with the CPU strings being

Re: [PATCHv2] Add a warning for suspicious use of conditional expressions in boolean context

On 09/05/16 21:23, Denis Campredon wrote: > Hi, > Your patch does not emit warning for the following case: > void f(int j){bool i = j ?: 3;} > > But for emit one for > void f(){bool i = 4 ?: 2;} > Regards > Yes, good point. It is probably not completely unrealistic that the middle expression may

Re: [PATCH, i386] Spellcheck hints for the i386 backend option handling (PR middle-end/77475)

On Mon, Sep 05, 2016 at 08:42:37PM +0100, Manuel López-Ibáñez wrote: > Something like the following should avoid a lot of (future) duplication > (untested): You're right. I've missed that I actually push the candidates into a vector anyway, so the concatenation can be done in a common code. >

Re: [v3, patch, variant] user-defined operator& and std::variant

On Sat, Sep 3, 2016 at 12:46 PM, Mikhail Strelnikov wrote: > Hello, > > Following code does not compile, > > #include > > namespace n > { > template > void operator&(T) {} > struct s{}; > } > > int main() > { > std::variant v; > std::get(v); > } > > error:

Re: [PATCH, i386] Spellcheck hints for the i386 backend option handling (PR middle-end/77475)

On 05/09/16 18:25, Jakub Jelinek wrote: Hi! While most of the i386.opt -m= options have enum args and thus cmdline_handle_error handles those, -march=/-mtune=/-m*-strategy= (and also -mrecip=) don't use that, with the CPU strings being maintained inside of a function rather than in some

Re: [PATCH, i386] Spellcheck hints for the i386 backend option handling (PR middle-end/77475)

On Mon, Sep 5, 2016 at 7:25 PM, Jakub Jelinek wrote: > Hi! > > While most of the i386.opt -m= options have enum args and thus > cmdline_handle_error handles those, -march=/-mtune=/-m*-strategy= (and also > -mrecip=) don't use that, with the CPU strings being maintained

Re: [PATCH, i386] Fix ICE with a md builtin call (PR target/69255)

On Mon, Sep 5, 2016 at 7:14 PM, Jakub Jelinek wrote: > Hi! > > As the testcase shows, if we want to diagnose a md builtin not enabled in > the current ISA, we call error and then return const0_rtx. That isn't a > good choice if the result is BLKmode, which can happen for vector

Re: [PATCH] Delete GCJ

On 9/5/16, Gerald Pfeifer wrote: > On Mon, 5 Sep 2016, Andrew Haley wrote: >> As discussed. I think I should ask a Global reviewer to approve this >> one. For obvious reasons I haven't included the diffs to the deleted >> gcc/java and libjava directories. The whole tree,

Re: [PATCH, i386]: Fix zero-extension optimizations from mask registers (PR target/77476)

On Mon, Sep 5, 2016 at 7:07 PM, Jakub Jelinek wrote: > Hi! > > On Fri, Aug 05, 2016 at 02:22:39PM +0200, Uros Bizjak wrote: >> 2016-08-05 Uros Bizjak >> >> * config/i386/i386.md (*zero_extendsidi2): Add (*r,*k) alternative. >> (zero_extenddi2):

Re: [PATCH] Delete GCJ

On 9/5/16, Matthias Klose wrote: > On 05.09.2016 17:13, Andrew Haley wrote: >> As discussed. I think I should ask a Global reviewer to approve this >> one. For obvious reasons I haven't included the diffs to the deleted >> gcc/java and libjava directories. The whole tree, post

Ping**2! Re: [PATCH, Fortran] Extension: AUTOMATIC/STATIC symbol attributes with -fdec-static

https://gcc.gnu.org/ml/fortran/2016-08/msg00173.html On Mon, Aug 29, 2016 at 8:36 AM, Fritz Reese wrote: > > https://gcc.gnu.org/ml/fortran/2016-08/msg00077.html > On Wed, Aug 17, 2016 at 7:20 AM, Fritz Reese wrote: > > This patch extends the GNU

Re: [PATCH] Fix location of command line backend reported issues (PR middle-end/77475)

On September 5, 2016 7:20:57 PM GMT+02:00, Jakub Jelinek wrote: >Hi! > >While it would be perhaps nice to pass explicit location_t in the >target >option handling code, there are hundreds of error/warning/sorry calls >in lots of backends, and lots of those routines are used not

[PATCH, i386] Spellcheck hints for the i386 backend option handling (PR middle-end/77475)

Hi! While most of the i386.opt -m= options have enum args and thus cmdline_handle_error handles those, -march=/-mtune=/-m*-strategy= (and also -mrecip=) don't use that, with the CPU strings being maintained inside of a function rather than in some *.def file that could be also sourced into

[PATCH] Fix location of command line backend reported issues (PR middle-end/77475)

Hi! While it would be perhaps nice to pass explicit location_t in the target option handling code, there are hundreds of error/warning/sorry calls in lots of backends, and lots of those routines are used not just for the process_options time (i.e. command line options), but also for pragma GCC

[C++ PATCH] Fix ICE in cp/error.c (PR c++/77482)

Hi! The recent concept changes that were also backported to 6.2 break diagnostics e.g. on the following testcase, sometimes it ICEs during reporting of the first error, so isn't just a normal low prio error recovery. The thing is that on the testcase the VAR_DECL has no DECL_LANG_SPECIFIC,

[PATCH, i386] Fix ICE with a md builtin call (PR target/69255)

Hi! As the testcase shows, if we want to diagnose a md builtin not enabled in the current ISA, we call error and then return const0_rtx. That isn't a good choice if the result is BLKmode, which can happen for vector modes that aren't enabled in the current ISA. In that case, returning target is

[C++ PATCH] Fix constexpr switch handling (PR c++/77467)

Hi! cxx_eval_switch_expr assumes that SWITCH_EXPR's body is always a STATEMENT_LIST, but that doesn't have to be the case. As the testcase shows, if there are any variable declarations in the switch body, it can be also a BIND_EXPR, which cxx_eval_constant_expression handles properly, and as bar

[PATCH, i386]: Fix zero-extension optimizations from mask registers (PR target/77476)

Hi! On Fri, Aug 05, 2016 at 02:22:39PM +0200, Uros Bizjak wrote: > 2016-08-05 Uros Bizjak > > * config/i386/i386.md (*zero_extendsidi2): Add (*r,*k) alternative. > (zero_extenddi2): Ditto. > (*zero_extendsi2): Ditto. > (*zero_extendqihi2): Ditto. As the PR

Make max_align_t respect _Float128 [version 2]

[Patch version 2 adds an update to cxx_fundamental_alignment_p.] The _FloatN, _FloatNx, _DecimalN and _DecimalNx types are specified in such a way that they are basic types, meaning that max_align_t must be at least as aligned as those types. On 32-bit x86, max_align_t is currently 8-byte

Re: [PATCH, docs] invoke.texi: random copy-editing

On 09/02/2016 12:17 AM, Gerald Pfeifer wrote: On Wed, 29 Aug 2012, Sandra Loosemore wrote: * doc/invoke.texi: Fix numerous typos and punctuation/grammatical errors throughout the file. Re-word some awkward sentences and paragraphs. There are three questions (and to

Re: C/C++ PATCH for c/77423 (bogus warning with -Wlogical-not-parentheses)

On 09/05/16 18:45, Joseph Myers wrote: > On Mon, 5 Sep 2016, Marek Polacek wrote: > >> Still not sure about other operations. I guess no one would >> object to warning on bool1 % bool2, but should we warn for >> bool1 + bool2? > > I think boolean addition (with the result interpreted as an

Re: [PATCH, docs] invoke.texi: random copy-editing

On 09/01/2016 01:04 PM, Gerald Pfeifer wrote: On Wed, 29 Aug 2012, Sandra Loosemore wrote: * doc/invoke.texi: Fix numerous typos and punctuation/grammatical errors throughout the file. Re-word some awkward sentences and paragraphs. I noticed you changed return-value

Re: [PATCH, docs] invoke.texi: random copy-editing

On 09/01/2016 06:22 AM, Gerald Pfeifer wrote: Hi Sandra, On Wed, 29 Aug 2012, Sandra Loosemore wrote: I've had this largish pile of random copy-edits to invoke.texi left over from my previous passes through that file earlier this year. that was an amazing amount of changes; I admire your

Re: [PATCHv2] Add a warning for suspicious use of conditional expressions in boolean context

On Mon, 5 Sep 2016, Bernd Edlinger wrote: > But I think the reasoning is still correct, left shifting > in a boolean context is suspicious, even if -fwrapv may make > it defined. Do you agree? Well, you can argue that if you want to test whether low bits are all zero, you should just use

Re: C/C++ PATCH for c/77423 (bogus warning with -Wlogical-not-parentheses)

On Mon, 5 Sep 2016, Marek Polacek wrote: > Still not sure about other operations. I guess no one would > object to warning on bool1 % bool2, but should we warn for > bool1 + bool2? I think boolean addition (with the result interpreted as an integer, not converted back to boolean) is perfectly

Re: [PATCH, ARM] Add a new target hook to compute the frame layout

Hi Richard, what do you think of this patch, is it OK (with the suggested wording)? Thanks Bernd. On 08/05/16 16:06, Richard Earnshaw (lists) wrote: > On 05/08/16 13:49, Bernd Edlinger wrote: >> On 08/05/16 11:29, Richard Earnshaw (lists) wrote: >>> On 04/08/16 22:16, Bernd Edlinger wrote:

Re: C/C++ PATCH for c/77423 (bogus warning with -Wlogical-not-parentheses)

On 09/05/2016 09:55 AM, Bernd Schmidt wrote: On 09/05/2016 12:52 PM, Marek Polacek wrote: On Mon, Sep 05, 2016 at 12:35:13PM +0200, Bernd Schmidt wrote: On 09/02/2016 05:13 PM, Marek Polacek wrote: diff --git gcc/doc/invoke.texi gcc/doc/invoke.texi index 87da1f1..38d55d4 100644 ---

Re: [PATCH] Delete GCJ

On Mon, 5 Sep 2016, Andrew Haley wrote: > As discussed. I think I should ask a Global reviewer to approve this > one. For obvious reasons I haven't included the diffs to the deleted > gcc/java and libjava directories. The whole tree, post GCJ-deletion, > is at

Re: [PATCH] Delete GCJ

On 05/09/16 17:15, Richard Biener wrote: > On September 5, 2016 5:13:06 PM GMT+02:00, Andrew Haley > wrote: >> As discussed. I think I should ask a Global reviewer to approve this >> one. For obvious reasons I haven't included the diffs to the deleted >> gcc/java and libjava

Re: [PATCH, c++, PR77427 ] Set TYPE_STRUCTURAL_EQUALITY for sysv_abi va_list

On 05/09/16 09:49, Richard Biener wrote: On Sun, Sep 4, 2016 at 11:30 PM, Tom de Vries wrote: > On 04/09/16 16:08, Richard Biener wrote: >> >> On September 4, 2016 12:33:02 PM GMT+02:00, Tom de Vries >> wrote: >>> >>> On 04/09/16 08:12,

Re: C/C++ PATCH for c/77423 (bogus warning with -Wlogical-not-parentheses)

On 09/05/2016 12:52 PM, Marek Polacek wrote: On Mon, Sep 05, 2016 at 12:35:13PM +0200, Bernd Schmidt wrote: On 09/02/2016 05:13 PM, Marek Polacek wrote: diff --git gcc/doc/invoke.texi gcc/doc/invoke.texi index 87da1f1..38d55d4 100644 --- gcc/doc/invoke.texi +++ gcc/doc/invoke.texi @@ -5437,8

RE: [PATCH] Delete GCJ

Andrew Haley writes: > As discussed. I think I should ask a Global reviewer to approve this > one. For obvious reasons I haven't included the diffs to the deleted > gcc/java and libjava directories. The whole tree, post GCJ-deletion, is > at

Re: [PATCH] Delete GCJ

On 05/09/16 16:29, Matthias Klose wrote: > Please consider removing boehm-gc as well. The only other user is > --enable-objc-gc, which better should use an external boehm-gc. I can do that, but I do not want to do so with this patch. Andrew.

Re: [PATCH] Delete GCJ

On 05.09.2016 17:13, Andrew Haley wrote: > As discussed. I think I should ask a Global reviewer to approve this > one. For obvious reasons I haven't included the diffs to the deleted > gcc/java and libjava directories. The whole tree, post GCJ-deletion, > is at

[PATCH] Delete GCJ

As discussed. I think I should ask a Global reviewer to approve this one. For obvious reasons I haven't included the diffs to the deleted gcc/java and libjava directories. The whole tree, post GCJ-deletion, is at svn+ssh://gcc.gnu.org/svn/gcc/branches/gcj/gcj-deletion-branch if anyone would

C++ patch ping

Hi! I'd like to ping 3 patches from a week ago: http://gcc.gnu.org/ml/gcc-patches/2016-08/msg01995.html - PR77375 - wrong-code with mutable members in base classes http://gcc.gnu.org/ml/gcc-patches/2016-08/msg01998.html - PR77338 - fix constexpr ICE on PARM_DECL with incomplete type

Re: C/C++ PATCH for c/77423 (bogus warning with -Wlogical-not-parentheses)

On 09/05/16 17:00, Eric Gallager wrote: > On 9/5/16, Bernd Edlinger wrote: >> On 09/05/16 14:03, Marek Polacek wrote: >>> On Fri, Sep 02, 2016 at 03:51:49PM +, Bernd Edlinger wrote: Hi, > + r += !a == ~b; > + r += !a == ~(int) b;

Re: C/C++ PATCH for c/77423 (bogus warning with -Wlogical-not-parentheses)

On 09/05/16 16:28, Marek Polacek wrote: > On Mon, Sep 05, 2016 at 02:08:20PM +, Bernd Edlinger wrote: >> On 09/05/16 14:03, Marek Polacek wrote: >>> On Fri, Sep 02, 2016 at 03:51:49PM +, Bernd Edlinger wrote: Hi, > + r += !a == ~b; > + r += !a == ~(int) b;

Re: C/C++ PATCH for c/77423 (bogus warning with -Wlogical-not-parentheses)

On 9/5/16, Bernd Edlinger wrote: > On 09/05/16 14:03, Marek Polacek wrote: >> On Fri, Sep 02, 2016 at 03:51:49PM +, Bernd Edlinger wrote: >>> Hi, >>> >>> > + r += !a == ~b; >>> > + r += !a == ~(int) b; >>> >>> I don't understand why ~b should not be warned at

[PATCH] Allow FP to be used as a call-saved registe

Hi All, This patch allows the FP register to be used as a call-saved register when -fomit-frame-pointer is used. The change is done in such a way that the defaults do not change. To use the FP register both -fomit-frame-pointer and -fcall-saved- need to be used. Regression ran on

Re: [PATCHv2] Add a warning for suspicious use of conditional expressions in boolean context

On 09/05/16 13:23, Joseph Myers wrote: > On Sun, 4 Sep 2016, Bernd Edlinger wrote: > >> good to have as well. But this code would still be suspicious >> even if (x << y) is put in parentheses, because the shift count does >> not change the result of the condition, as the integer overflow is >>

Re: C/C++ PATCH for c/77423 (bogus warning with -Wlogical-not-parentheses)

On Mon, Sep 05, 2016 at 02:08:20PM +, Bernd Edlinger wrote: > On 09/05/16 14:03, Marek Polacek wrote: > > On Fri, Sep 02, 2016 at 03:51:49PM +, Bernd Edlinger wrote: > >> Hi, > >> > >> > + r += !a == ~b; > >> > + r += !a == ~(int) b; > >> > >> I don't understand why ~b should not be

Re: C/C++ PATCH for c/77423 (bogus warning with -Wlogical-not-parentheses)

On 09/05/16 14:03, Marek Polacek wrote: > On Fri, Sep 02, 2016 at 03:51:49PM +, Bernd Edlinger wrote: >> Hi, >> >> > + r += !a == ~b; >> > + r += !a == ~(int) b; >> >> I don't understand why ~b should not be warned at -Wall. > > Yeah, there was an RFE for this but I'm not finding it. >

Re: C/C++ PATCH for c/77423 (bogus warning with -Wlogical-not-parentheses)

On Fri, Sep 02, 2016 at 03:51:49PM +, Bernd Edlinger wrote: > Hi, > > > + r += !a == ~b; > > + r += !a == ~(int) b; > > I don't understand why ~b should not be warned at -Wall. Yeah, there was an RFE for this but I'm not finding it. > Frankly I don't even understand why the above

Re: PR35503 - warn for restrict pointer

On 1 September 2016 at 21:28, Martin Sebor wrote: >> The attached version passes bootstrap+test on ppc64le-linux-gnu. >> Given that it only looks if parameters are restrict qualified and not >> how they're used inside the callee, >> this can have false positives as in above

[GCC][PATCH] Add __artificial__ attribute to Aarch64 NEON intrinsics

Hi all, This patch adds __artificial__ attribute to the intrinsics in arm_neon.h so that costs are associated to the user function during profiling and during the intrinsics are are hidden in trace. The attribute does not affect code generation. No new tests for this since it would require a

Re: Testing _Complex varargs passing [was: Alpha, ABI change: pass SFmode and SCmode varargs by reference]

On Sun, 4 Sep 2016, Uros Bizjak wrote: > It looks that different handling of _Complex char, _Complex short and > _Complex float is there on purpose. Is (was?) there a limitation in a > c language standard that prevents passing of these arguments as > varargs? Well, ISO C doesn't define complex

Re: Implement C _FloatN, _FloatNx types [version 6]

On Sat, 3 Sep 2016, Andreas Schwab wrote: > On Aug 17 2016, Joseph Myers wrote: > > > Index: gcc/testsuite/gcc.dg/torture/float32-basic.c > > === > > --- gcc/testsuite/gcc.dg/torture/float32-basic.c

Re: [PATCHv2] Add a warning for suspicious use of conditional expressions in boolean context

On Sun, 4 Sep 2016, Bernd Edlinger wrote: > good to have as well. But this code would still be suspicious > even if (x << y) is put in parentheses, because the shift count does > not change the result of the condition, as the integer overflow is > undefined behavior, and if it does not have side

Re: [PATCH, rtl-optimization]: Fix PR77452, ICE: in plus_constant, at explow.c

On September 5, 2016 12:11:47 PM GMT+02:00, Bernd Schmidt wrote: >On 09/04/2016 02:12 PM, Uros Bizjak wrote: >> As shown in the PR [1], combine is able to simplify lowpart >> CONST_VECTOR constant pool reference to its inner-mode reference. >> However, plus_constant was not

Re: C/C++ PATCH for c/77423 (bogus warning with -Wlogical-not-parentheses)

On Mon, Sep 05, 2016 at 12:35:13PM +0200, Bernd Schmidt wrote: > On 09/02/2016 05:13 PM, Marek Polacek wrote: > > diff --git gcc/doc/invoke.texi gcc/doc/invoke.texi > > index 87da1f1..38d55d4 100644 > > --- gcc/doc/invoke.texi > > +++ gcc/doc/invoke.texi > > @@ -5437,8 +5437,8 @@ if (a < 0 && a <

Re: [patch v2] Get rid of stack trampolines for nested functions (3/4)

Hi Eric, On Sun, Sep 04, 2016 at 10:14:22PM +0200, Eric Botcazou wrote: > * config/aarch64/aarch64.h(TARGET_CUSTOM_FUNCTION_DESCRIPTORS):Define Space after ":". Many spaces are missing in the changelogs for this series. > Index: config/rs6000/rs6000.h >

Re: C/C++ PATCH for c/77423 (bogus warning with -Wlogical-not-parentheses)

On 09/02/2016 05:13 PM, Marek Polacek wrote: diff --git gcc/doc/invoke.texi gcc/doc/invoke.texi index 87da1f1..38d55d4 100644 --- gcc/doc/invoke.texi +++ gcc/doc/invoke.texi @@ -5437,8 +5437,8 @@ if (a < 0 && a < 0) @{ @dots{} @} @opindex Wlogical-not-parentheses @opindex

Re: MAINTAINERS update

On Thu, 19 May 2016, Jeff Law wrote: Spurred by the lack of response to Sandra's message WRT a cygwin/mingw issue, I did a quick pass through the MAINTAINERS file for folks that are listed as maintainers, but aren't (to the best of my knowledge) acting in those positions anymore. I removed

Re: [PATCH, rtl-optimization]: Fix PR77452, ICE: in plus_constant, at explow.c

On 09/04/2016 02:12 PM, Uros Bizjak wrote: As shown in the PR [1], combine is able to simplify lowpart CONST_VECTOR constant pool reference to its inner-mode reference. However, plus_constant was not able to extract the constant from narrowed access. Attached patch teaches plus_constant how to

Re: [MPX] Fix for PR77267

Ok, thanks. The full updated patch is below. I also removed the '--whole-archive' thing from -static-libmpxwrappers case. Would that be possible to backport that patch to 6 branch as well? And could you please also address Sergey's comment on adding weak symbol that he's made in the bugzilla?

Re: [PATCH] Fix alter_output_for_subst_insn (PR other/77421)

On Fri, 2 Sep 2016, Jakub Jelinek wrote: > Hi! > > The two ports that use define_subst (ix86 and visium) don't do anything in > this function, other than returning early - return insn_out, so all I could > do is look at the intent. > The *insn_out == '*' || *insn_out != '@' got flagged by some

Re: [PATCH] Remove unnecessary conditional in get_odr_type (PR rtl-optimization/77425)

On Fri, Sep 2, 2016 at 5:07 PM, Jakub Jelinek wrote: > Hi! > > As mentioned in the PR, we have > static GTY(()) vec *odr_types_ptr; > #define odr_types (*odr_types_ptr) > and in the else block do > odr_types[val->id] = 0; > first (which is actually >

Re: [RFC][SSA] Iterator to visit SSA

On Mon, Sep 5, 2016 at 7:26 AM, Kugan Vivekanandarajah wrote: > Hi All, > > While looking at gcc source, I noticed that we are iterating over SSA > variable from 0 to num_ssa_names in some cases and 1 to num_ssa_names > in others. It seems that variable 0 is

Re: [PATCH, c++, PR77427 ] Set TYPE_STRUCTURAL_EQUALITY for sysv_abi va_list

On Sun, Sep 4, 2016 at 11:30 PM, Tom de Vries wrote: > On 04/09/16 16:08, Richard Biener wrote: >> >> On September 4, 2016 12:33:02 PM GMT+02:00, Tom de Vries >> wrote: >>> >>> On 04/09/16 08:12, Richard Biener wrote: On September 3, 2016

Re: [PATCH] Tree-level fix for PR 69526

Ping. diff --git a/gcc/gimple-match-head.c b/gcc/gimple-match-head.c index 2beadbc..d66fcb1 100644 --- a/gcc/gimple-match-head.c +++ b/gcc/gimple-match-head.c @@ -39,6 +39,7 @@ along with GCC; see the file COPYING3. If not see #include "internal-fn.h" #include "case-cfn-macros.h" #include

Re: [PATCH, vec-tails 07/10] Support loop epilogue combining

On Fri, Sep 2, 2016 at 4:46 PM, Yuri Rumyantsev wrote: > Hi Jeff, > > I am trying to reduce cost of repeated call of if-conversion for > epilogue vectorization. I'd like to clarify your recommendation - > should I design additional support for versioning in >

Re: [PATCH 3/4][Ada,DJGPP] Ada support for DJGPP

> Attached output is from last test build (r239639 with DJGPP related patches > applied, last version of patches for Ada). Very strange error, line 28 of gtype-ada.h is supposed to have a guard for nodes containing the 'common' structure. Can you post an excerpt of the file? -- Eric Botcazou