Re: [PATCH/AARCH64] Fix 64893: ICE with vget_lane_u32 with C++ front-end at -O0

On Mon, Feb 02, 2015 at 02:51:43PM -0800, Andrew Pinski wrote: > While trying to build the GCC 5 with GCC 5, I ran into an ICE when > building libcpp at -O0. The problem is the C++ front-end was not > folding sizeof(a)/sizeof(a[0]) when passed to a function at -O0. The > C++ front-end keeps around

Re: [PATCH IRA] update_equiv_regs fails to set EQUIV reg-note for pseudo with more than one definition

On 02/02/15 08:59, Alex Velenko wrote: On 11/10/14 13:44, Felix Yang wrote: Hello Jeff, I see that you have improved the RTL typesafety issue for ira.c, so I rebased this patch on the latest trunk and change to use the new list walking interface. Bootstrapped on x86_64-SUSE-Linux

Re: [PATCH] Fix combiner from accessing or writing out of bounds SET_N_REGS (PR other/63504)

On Mon, Feb 02, 2015 at 05:26:23PM -0600, Segher Boessenkool wrote: > On Mon, Feb 02, 2015 at 07:54:46PM +0100, Jakub Jelinek wrote: > > +/* Highest pseudo for which we track REG_N_SETS. */ > > +static unsigned int reg_n_sets_max; > > One more than the highest reg num, actually. Changed in my co

Re: [RFC][PR target/39726 P4 regression] match.pd pattern to do type narrowing

On 02/02/15 11:04, Jeff Law wrote: On 02/02/15 09:59, Joseph Myers wrote: On Sat, 31 Jan 2015, Jeff Law wrote: The nice thing about wrapping the result inside a convert is the types for the inner operations will propagate from the type of the inner operands, which is exactly what we want. We

Re: [PATCH, FT32] initial support

On Mon, Feb 2, 2015 at 9:18 PM, James Bowman wrote: > FT32 is a new high performance 32-bit RISC core developed by FTDI for > embedded applications. > > Support for FT32 has already been added to binutils. This patch adds FT32 > support to gcc. > > Please can someone review it, and if appropriat

[PATCH, FT32] initial support

FT32 is a new high performance 32-bit RISC core developed by FTDI for embedded applications. Support for FT32 has already been added to binutils. This patch adds FT32 support to gcc. Please can someone review it, and if appropriate commit it, as I do not have write access to the tree.

Re: [PATCH] Add new target h8300-*-linux

At Sun, 1 Feb 2015 00:39:08 +, Joseph Myers wrote: > > On Sat, 31 Jan 2015, Yoshinori Sato wrote: > > > + * config/h8300/linux.h: New file. > > + * config/h8300/t-linux: New file. > > These files don't appear to be included in the patch. I'll resend it. > > +h8300-*-linux*) > > + tma

Go patch committed: Fix 32-bit host to 64-bit target cross-compilation

In the backend interface for the Go frontend, I foolishly used size_t for the size of a type. That usually works, but fails when compiling on a 32-bit host for a 64-bit target and compiling code that uses very large types. The maximum type size for any Go target is a signed 64-bit number, so for

Fix crossmodule inline hint

Hi, inliner uses crossmodule hint that during LTO preffers in-module inlining over cross-module. This hint is wrong for comdats that gets merged and thus the module information is more or less random. The patch fixes it by adding merged flag to cgraph_node indicating merged comdats and always dis

Re: [PATCH, RFC] fortran [was Re: #pragma GCC unroll support]

On Feb 2, 2015, at 3:22 PM, Bernhard Reutner-Fischer wrote: > Untested draft patch I looked it over, seems to slot in nicely. + gfc_error ("% directive does not commence a loop at %C”); So, don’t like commence here.

Re: [PATCH] Fix combiner from accessing or writing out of bounds SET_N_REGS (PR other/63504)

On Mon, Feb 02, 2015 at 07:54:46PM +0100, Jakub Jelinek wrote: > +/* Highest pseudo for which we track REG_N_SETS. */ > +static unsigned int reg_n_sets_max; One more than the highest reg num, actually. Looks fine otherwise :-) Segher

[PATCH, v0] fortran: !GCC$ unroll for DO

fortran/ChangeLog: 2015-02-02 Bernhard Reutner-Fischer * match.h (gfc_match_gcc_unroll): New prototype. * decl.c (directive_unroll): New global variable. (gfc_match_gcc_unroll): New function. * gfortran.h (directive_unroll): New extern declaration. [gfc_

[PATCH, RFC] fortran [was Re: #pragma GCC unroll support]

Hi, Some compilers IIRC use !DIR$ unroll, if memory serves me right then the DEC compiler had !DEC$ unroll. We could support one or the other three-letter keyword or maybe not. I think a combination of unroll and ivdep directives is allowed (at least in some compilers); TODO. Not sure what other

[PATCH/AARCH64] Fix 64893: ICE with vget_lane_u32 with C++ front-end at -O0

While trying to build the GCC 5 with GCC 5, I ran into an ICE when building libcpp at -O0. The problem is the C++ front-end was not folding sizeof(a)/sizeof(a[0]) when passed to a function at -O0. The C++ front-end keeps around sizeof until the gimplifier and there is no way to fold the expression

Re: C++ PATCH for abi_tag sanity checking

On 02/02/2015 06:43 PM, Jason Merrill wrote: > One of the EDG guys pointed out to me that we weren't doing any sanity > checking > on the arguments to the abi_tag attribute. This patch adds checks to require > that the arguments be strings containing valid identifiers, so they work > appropriatel

Re: [PATCH] PR preprocessor/64803 - __LINE__ inside macro is not constant

On Mon, Feb 02, 2015 at 11:22:58PM +0100, Dodji Seketeli wrote: > Thanks. The patch that finally passed bootstrap is the one below. It's > slightly different in the condition I use to detect that we are popping > the context of the top-most macro expansion stored in > pfile->top_most_macro_node i

Re: [C++ PATCH] PR c++/64901

On 2 February 2015 at 20:50, Ville Voutilainen wrote: > The modified test has been tested, I'm currently running the full testsuite, > so testing is incomplete. I wanted to send this in asap, since this is a > bad regression. > > /cp > 2015-02-02 Ville Voutilainen > > PR c++/64901 > * d

Re: [PATCH] PR preprocessor/64803 - __LINE__ inside macro is not constant

Jakub Jelinek writes: > On Mon, Feb 02, 2015 at 03:41:50PM +0100, Dodji Seketeli wrote: >> libcpp/ChangeLog: >> >> * internal.h (cpp_reader::top_most_macro_node): New data member. >> * macro.c (enter_macro_context): Pass the location of the end of >> the top-most invocation of the

Fix pesimisation due to always_inline

Hi, while looking into Firefox's regressions WRT 4.9 LTO builds, I noticed that some of very small functions are not early inlined. This is because firefox sometimes uses always_inline and we skip early inlining int those. Once the always_inline is inlined we however do not inline recursively becu

PATCH: PR target/64905: unsigned short is loaded with 4-byte load (movl)

This patch fixes a long standing bug where aligned_operand ignores alignment of memory operand less than 32 bits. It drops address decomposition and returns false if alignment of memory operand less is than 32 bits. Tested on Linux/x86-64. OK for trunk, 4.9 and 4.8 branches? H.J. --- gcc/

Re: [PATCH] Added PLUGIN_FINISH_TYPE callback on enum type processing

On Mon, Feb 2, 2015 at 2:39 PM, Bruno Loff wrote: > 2014-10-19 Bruno Loff > > * c-parser.c (c_parser_declspecs): Call invoke_plugin_callbacks after > processing enum declaration. Thanks. Committed at r220358. Diego.

Re: [PATCH] PR preprocessor/64803 - __LINE__ inside macro is not constant

On Mon, Feb 02, 2015 at 03:41:50PM +0100, Dodji Seketeli wrote: > libcpp/ChangeLog: > > * internal.h (cpp_reader::top_most_macro_node): New data member. > * macro.c (enter_macro_context): Pass the location of the end of > the top-most invocation of the function-like macro, or the

Re: [Ping] Port of VTV for Cygwin and MinGW

Hi, after the missed bug at Linux with no VTV I checked everything again on the trunk. I saw that I erroneously wrote in the changelog for libvtv/aclocal.m4 regenerate and deleted the change from the patch. The only change I made there in my working directory was the following. Index: libvtv/aclo

Re: [PATCH] Added PLUGIN_FINISH_TYPE callback on enum type processing

That's On Mon, Feb 2, 2015 at 2:39 PM, Bruno Loff wrote: > Sorry, first contribution ever :) Here is the entry: > > 2014-10-19 Bruno Loff > > * c-parser.c (c_parser_declspecs): Call invoke_plugin_callbacks after > processing enum declaration. This is fine. Thanks. > The dates are off becaus

Re: [PATCH] Added PLUGIN_FINISH_TYPE callback on enum type processing

Sorry, first contribution ever :) Here is the entry: 2014-10-19 Bruno Loff * c-parser.c (c_parser_declspecs): Call invoke_plugin_callbacks after processing enum declaration. The dates are off because I actually made the change a while ago (took me a while because I needed to test it with the

Re: [Patch, libstdc++/64649] Fix regex_traits::lookup_collatename and regex_traits::lookup_classname

On 02/02/15 11:18 -0800, Tim Shen wrote: On Mon, Feb 2, 2015 at 3:22 AM, Jonathan Wakely wrote: I don't think this needs to go on the 4.9 branch, apparently I'm the only person who's noticed the problem. I expect it's quite rare to try using those functions with forward iterators. Sorry, I wa

Re: [Patch, libstdc++/64649] Fix regex_traits::lookup_collatename and regex_traits::lookup_classname

On Mon, Feb 2, 2015 at 3:22 AM, Jonathan Wakely wrote: > I don't think this needs to go on the 4.9 branch, apparently I'm the > only person who's noticed the problem. I expect it's quite rare to try > using those functions with forward iterators. Sorry, I was not talking about the first patch whi

Re: [PATCH] Added PLUGIN_FINISH_TYPE callback on enum type processing

On Mon, Feb 2, 2015 at 2:07 PM, Bruno Loff wrote: > Something like: > > The PLUGIN_FINISH_TYPE callback for gcc plugins is now triggered for > enum declarations. > > ? ChangeLog entries in GCC are pretty pick as to how they want to be formatted. See other entries for reference and https://gcc.gnu

Re: [PATCH] Added PLUGIN_FINISH_TYPE callback on enum type processing

Something like: The PLUGIN_FINISH_TYPE callback for gcc plugins is now triggered for enum declarations. ? On 2 February 2015 at 20:03, Diego Novillo wrote: > On Thu, Jan 29, 2015 at 4:32 PM, Bruno Loff wrote: >> >> The issue was first reported by Joachim Wieland to the list >> g...@gcc.gnu.or

Re: [PATCH] Added PLUGIN_FINISH_TYPE callback on enum type processing

On Thu, Jan 29, 2015 at 4:32 PM, Bruno Loff wrote: > > The issue was first reported by Joachim Wieland to the list > g...@gcc.gnu.org, on Wed, > Jan 19, 2011 (Subject: PLUGIN_FINISH_TYPE not executed for enums). > > > A description of the problem/bug and how my patch addresses it. > --

[PATCH] Fix combiner from accessing or writing out of bounds SET_N_REGS (PR other/63504)

Hi! During combine we sometimes split instructions and on some target that can create new pseudos. combine_split_insns in that case grows the reg_stat vector, but REG_N_SETS lives in an array allocated by regstat.c once and it isn't able right now to grow it. Even adding the ability to grow that

[C++ PATCH] PR c++/64901

The modified test has been tested, I'm currently running the full testsuite, so testing is incomplete. I wanted to send this in asap, since this is a bad regression. /cp 2015-02-02 Ville Voutilainen PR c++/64901 * decl.c (duplicate_decls): Also duplicate DECL_FINAL_P and DECL_OVERRIDE_

[PATCH] Fix CSE volatile MEM handling (PR rtl-optimization/64756)

Hi! We miscompile the following testcase, because first we add a mem/v into the hash table (which should not happen), later on during merge_equiv_classes a new element for that mem/v is added and doesn't even have in_memory set (because HASH failed with do_not_record but nothing checked it) and la

Re: [PATCH] Added PLUGIN_FINISH_TYPE callback on enum type processing

> I am forwarding this reply to Cary Coutant, Diego Novillo and Le-Chun > Wu, as they were listed as the plugin maintainers. > > Cary, Diego, Le-Chun, please let me know if you are on it, or if I > should send it to someone else. Sorry, this isn't my kind of plugin -- I'm a maintainer for the LTO

Re: [RFC][PR target/39726 P4 regression] match.pd pattern to do type narrowing

On 02/02/15 01:57, Richard Biener wrote: The nice thing about wrapping the result inside a convert is the types for the inner operations will propagate from the type of the inner operands, which is exactly what we want. We then remove the hack assigning type and instead the original type will b

Re: [PATCH] Added PLUGIN_FINISH_TYPE callback on enum type processing

I am forwarding this reply to Cary Coutant, Diego Novillo and Le-Chun Wu, as they were listed as the plugin maintainers. Cary, Diego, Le-Chun, please let me know if you are on it, or if I should send it to someone else. On 29 January 2015 at 22:32, Bruno Loff wrote: > The issue was first report

Re: [PATCH][libstdc++][Testsuite] isctype test fails for newlib.

On 2 February 2015 at 18:03, Matthew Wahab wrote: > Updated patch attached and changelog below. Looks good, OK for trunk - thanks for fixing it.

Re: MAINTAINERS: resign as testsuite maintainer, update address

On 02/02/15 09:54, Janis Johnson wrote: I retired from Mentor Graphics 3 weeks ago and have no immediate plans to be active in GCC, so I'm resigning as a testsuite maintainer. I'm leaving myself under Write After Approval with my personal email address so people can find me. Sounds good. Thank

Re: [RFC][PR target/39726 P4 regression] match.pd pattern to do type narrowing

On 02/02/15 09:59, Joseph Myers wrote: On Sat, 31 Jan 2015, Jeff Law wrote: The nice thing about wrapping the result inside a convert is the types for the inner operations will propagate from the type of the inner operands, which is exactly what we want. We then remove the hack assigning type

Re: [PATCH] Added PLUGIN_FINISH_TYPE callback on enum type processing

On Sun, 1 Feb 2015, Bruno Loff wrote: > Do I need to do anything else to get this patch into gcc? I suggest CC:ing the plugin maintainers (as listed in the MAINTAINERS file), and then pinging weekly for as long as needed. -- Joseph S. Myers jos...@codesourcery.com

Re: [PING, www] Re: [PATCH] update_web_docs_svn: support the JIT docs (PR jit/64257)

Hi David, On Monday 2015-02-02 11:39, David Malcolm wrote: * update_web_docs_svn: Don't delete gcc/jit/docs or gcc/jit/jit-common.h, gcc/jit/notes.txt. Special case the building of the jit docs (using sphinx-build). Special case copying them up. >> I've committed t

Re: [Patch, fortran] PR 64757 - [5 Regression] ICE in fold_convert_loc, at fold-const.c:2353

Dear Dominique, On transferring from my laptop to my workstation, I find that it segfaults in runtime - both are x86_64/FC21. If I can, I intend to investigate tonight. Thanks for the report. Paul On 2 February 2015 at 17:53, Dominique Dhumieres wrote: > Dear Paul, > > I have tested your patch

C++ PATCH for abi_tag sanity checking

One of the EDG guys pointed out to me that we weren't doing any sanity checking on the arguments to the abi_tag attribute. This patch adds checks to require that the arguments be strings containing valid identifiers, so they work appropriately in mangled names. Tested x86_64-pc-linux-gnu, app

Re: [RFC][PR target/39726 P4 regression] match.pd pattern to do type narrowing

On Sat, 31 Jan 2015, Jeff Law wrote: > The nice thing about wrapping the result inside a convert is the types for the > inner operations will propagate from the type of the inner operands, which is > exactly what we want. We then remove the hack assigning type and instead the > original type will

MAINTAINERS: resign as testsuite maintainer, update address

vidual FSF copyright assignment; is that still valid? Janis gcc-20150202-1 Description: Binary data

Re: [Patch, fortran] PR 64757 - [5 Regression] ICE in fold_convert_loc, at fold-const.c:2353

Dear Paul, I have tested your patch at https://gcc.gnu.org/ml/fortran/2015-01/txtwnaoa1115V.txt (the latest version) and I found that the test type_to_class_3.f03 is miscompiled (FAIL) with -flto -O0 -m64 (this does not happens with -flto -O0 -m32 or with -Ox and x!=0). In addition, while the

[PING, www] Re: [PATCH] update_web_docs_svn: support the JIT docs (PR jit/64257)

On Mon, 2015-01-26 at 19:14 -0500, David Malcolm wrote: > On Mon, 2015-01-26 at 15:21 -0700, Jeff Law wrote: > > On 01/26/15 09:42, David Malcolm wrote: > > > > > update_web_docs_svn-support-the-JIT-documention-v2.patch > > > > > > > > > From 7f7e15881981228e51b347f23df6e3106ddd68ea Mon Sep 17 00

Re: [PATCH][libstdc++][Testsuite] isctype test fails for newlib.

On 2 February 2015 at 16:17, Paolo Carlini wrote: > Hi, > > On 02/02/2015 04:49 PM, Matthew Wahab wrote: >> >> Hello, >> >> With target arm-none-eabi, the libstdc++ tests >> 28_regex/traits/char/isctype.cc and 28_regex/traits/wchar/isctype.cc fail at >> -- >> VERIFY(!t.isctype('\n', t.lookup_class

Re: [nvptx-tools, committed] Also install [...]/nvptx-none/bin/ar and [...]/nvptx-none/bin/ranlib.

Hi Bernd! On Fri, 9 Jan 2015 16:38:51 +0100, Bernd Schmidt wrote: > On 12/23/2014 07:50 PM, Thomas Schwinge wrote: > > [nvptx-tools patches] > > I've pushed the three patches you sent to my github repository. It probably makes sense for you to switch over to the MentorEmbedded repositories,

RE: [PATCH MIPS RFA] Regression cleanup for nan2008 toolchain

> Please could you add a comment explaining that the mips_nanlegacy is there > because of the #include of system headers that might not compile with > -mnan=legacy? I agree that that's a good reason, but it's not obvious > without a comment. (And without a comment this could start a precendent >

Re: [PATCH][libstdc++][Testsuite] isctype test fails for newlib.

Hi, On 02/02/2015 04:49 PM, Matthew Wahab wrote: Hello, With target arm-none-eabi, the libstdc++ tests 28_regex/traits/char/isctype.cc and 28_regex/traits/wchar/isctype.cc fail at -- VERIFY(!t.isctype('\n', t.lookup_classname(range(blank; -- This is because libstdc++ puts '\n' in the 'sp

Re: Re: [PATCH IRA] update_equiv_regs fails to set EQUIV reg-note for pseudo with more than one definition

On 11/10/14 13:44, Felix Yang wrote: Hello Jeff, I see that you have improved the RTL typesafety issue for ira.c, so I rebased this patch on the latest trunk and change to use the new list walking interface. Bootstrapped on x86_64-SUSE-Linux and make check regression tested.

Re: [Patch, AArch64, Obvious] Fix PR64231.

On 30/01/15 13:25, Jakub Jelinek wrote: On Fri, Jan 23, 2015 at 11:03:13AM +, Tejas Belagod wrote: Hi, This is an almost obvious patch to fix PR64231 as discovered by A. Pinksi and as proposed by Jakub. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64231 Regressions happy. OK to commit?

[PATCH][libstdc++][Testsuite] isctype test fails for newlib.

Hello, With target arm-none-eabi, the libstdc++ tests 28_regex/traits/char/isctype.cc and 28_regex/traits/wchar/isctype.cc fail at -- VERIFY(!t.isctype('\n', t.lookup_classname(range(blank; -- This is because libstdc++ puts '\n' in the 'space' character class, rather than 'blank' when buil

Re: [PATCH] Relax check against commuting XOR and ASHIFTRT in combine.c

Hi Alan, >> I'm still not really comfortable with those target lists; they tend to >> artificially exclude tests on targets where they are perfectly capable >> of running. At least with the comments added, it's better than before >> with no explanation whatsoever. Perhaps Mike can weigh in here?

Re: [PATCH] Change __ARM_NEON__ to __ARM_NEON in libcpp/lex.c

On 02/02/15 15:34, Szabolcs Nagy wrote: > > > On 30/01/15 19:14, Richard Henderson wrote: >> On 01/30/2015 04:52 AM, Szabolcs Nagy wrote: >>> When running natively on AArch64 the preprocessor did not use the >>> AdvSIMD optimized search_line_fast function, because it was ifdefed >>> around by __A

Re: [[ARM/AArch64][testsuite] 03/36] Add vmax, vmin, vhadd, vhsub and vrhadd tests.

2015-01-25 Christophe Lyon * gcc.target/aarch64/advsimd-intrinsics/arm-neon-ref.h (_ARM_FPSRC): Add DN and AHP fields. (clean_results): Force DN=1 on AArch64. * gcc.target/aarch64/advsimd-intrinsics/binary_op_no64.inc: New file. * gcc.target/aarch64/advsimd-int

Re: [PATCH] Change __ARM_NEON__ to __ARM_NEON in libcpp/lex.c

On 30/01/15 19:14, Richard Henderson wrote: On 01/30/2015 04:52 AM, Szabolcs Nagy wrote: When running natively on AArch64 the preprocessor did not use the AdvSIMD optimized search_line_fast function, because it was ifdefed around by __ARM_NEON__ instead of __ARM_NEON. Yes, sorry I didn't fol

Re: nvptx-tools and nvptx-newlib (was: The nvptx port [10/11+] Target files)

Hi! On Tue, 23 Dec 2014 19:49:35 +0100, I wrote: > On Mon, 10 Nov 2014 17:19:57 +0100, Bernd Schmidt > wrote: > > The scripts (11/11) I've put up on github, along with a hacked up > > newlib. These are at [...] > > They are likely to migrate to MentorEmbedded from bernds, but that had > > som

[PATCH] Improve SSA propagator wrt instruction combining

I have queued the following patch for stage1 which improves the ability to utilize the match-and-simplify combiner during SSA propagation (by CCP and VRP). It makes sure to mark stmts as not-simulate-again when possible so that the valueization hooks know when it is safe to combine multiple state

Re: [PATCH] PR preprocessor/64803 - __LINE__ inside macro is not constant

Jakub Jelinek writes: > On Fri, Jan 30, 2015 at 10:19:26AM +0100, Dodji Seketeli wrote: >> [This is a P1 regression for gcc 5] >> libcpp/ChangeLog: >> >> * internal.h (cpp_reader::top_most_macro_node): New data member. >> * macro.c (enter_macro_context): Pass the location of the end of

Re: [PATCH] Relax check against commuting XOR and ASHIFTRT in combine.c

Rainer Orth wrote: I'm still not really comfortable with those target lists; they tend to artificially exclude tests on targets where they are perfectly capable of running. At least with the comments added, it's better than before with no explanation whatsoever. Perhaps Mike can weigh in here?

Re: [PATCH 4/4] OpenMP 4.0 offloading to Intel MIC: non-fallback testing

On 28 Jan 19:20, Ilya Verbin wrote: > On 28 Jan 17:15, Jakub Jelinek wrote: > > On Wed, Jan 28, 2015 at 07:02:59PM +0300, Ilya Verbin wrote: > > > + = XNEWVEC (char, len + sizeof ("-B" "../" DEFAULT_TARGET_MACHINE > > > +"/libgomp/")); > > > + sprintf (optional_

Re: [testsuite] Run guality tests on Solaris

Jeff Law writes: > On 01/30/15 01:19, Jakub Jelinek wrote: >> >> The biggest problem is that what fails and what does not varries between >> targets and between optimization levels. Right now we have no way to xfail >> test XYZ for -Os on x86_64-linux and for -O2 and -O3 on i686-linux ia32, and

Re: [PATCH][RFC][OpenMP] Forbid target* pragmas in target regions

On Mon, Jan 12, 2015 at 12:22:44AM +0300, Ilya Verbin wrote: > Currently if a target* pragma appears within a target region, GCC successfully > compiles such code (with a warning). But the binary fails at run-time, since > it > tries to call GOMP_target* functions on target. > > The spec says: "

Re: [PATCH][OpenMP] Forbid usage of non-target functions in target regions

On Sun, Jan 11, 2015 at 11:06:52PM +0300, Ilya Verbin wrote: > On 09 Jan 16:02, Jakub Jelinek wrote: > > On Fri, Jan 09, 2015 at 05:57:02PM +0300, Ilya Verbin wrote: > > > If one (by mistake) calls a non-target function from the target region, > > > the > > > offload compiler crashes in input_over

Re: [PATCH] Warn about unclosed pragma omp declare target.

On Tue, Jul 29, 2014 at 06:45:01PM +0400, Ilya Tocar wrote: > Hi, > > As discussed here in https://gcc.gnu.org/ml/gcc/2014-01/msg00189.html > Gcc should complain about pragma omp declare target without > corresponding pragma omp end declare target. This patch adds a warning > for those cases. > Bo

Re: [PATCH] PR preprocessor/64803 - __LINE__ inside macro is not constant

On Fri, Jan 30, 2015 at 10:19:26AM +0100, Dodji Seketeli wrote: > [This is a P1 regression for gcc 5] > libcpp/ChangeLog: > > * internal.h (cpp_reader::top_most_macro_node): New data member. > * macro.c (enter_macro_context): Pass the location of the end of > the top-most invocat

Re: [Patch, libstdc++/64649] Fix regex_traits::lookup_collatename and regex_traits::lookup_classname

On 23/01/15 13:20 -0800, Tim Shen wrote: On Wed, Jan 21, 2015 at 9:10 PM, Tim Shen wrote: Submitted version. I think this patch fits 4.9 branch well? I don't think this needs to go on the 4.9 branch, apparently I'm the only person who's noticed the problem. I expect it's quite rare to try u

Re: [Patch, libstdc++/64680] Conform the standard regex interface

On 01/02/15 00:18 -0800, Tim Shen wrote: On Wed, Jan 21, 2015 at 9:08 PM, Tim Shen wrote: Fixed and committed. I believe this one is also suitable for 4.9? I guess we don't have a 'code freeze' for 4.9 branch as we do for 5.0 late stage? Release branches are always in "regression fixes and

Re: [PATCH libstdc++] Fix for std::uncaught_exception (PR 62258)

On 2 February 2015 at 02:37, Michael Hanselmann wrote: > Calls to `std::uncaught_exception` after calling > `std::rethrow_exception' always return `true' when > `std::uncaught_exception' should return `false' unless an exception is > in flight. `std::rethrow_exception' does not update > `__cxa_eh_g

Re: [[ARM/AArch64][testsuite] 03/36] Add vmax, vmin, vhadd, vhsub and vrhadd tests.

On 26 January 2015 at 14:23, Christophe Lyon wrote: > On 26 January 2015 at 13:10, Tejas Belagod wrote: >> On 25/01/15 21:05, Christophe Lyon wrote: >>> >>> On 23 January 2015 at 14:44, Christophe Lyon >>> wrote: On 23 January 2015 at 12:42, Christophe Lyon wrote: > > On

Re: [Patch, fortran] Cosmetics: Dup. code removal, indent fix, typo fix.

Hi Jerry, thanks for the review. Committed as r220345. Regards, Andre On Sat, 31 Jan 2015 07:41:24 -0800 Jerry DeLisle wrote: > On 01/30/2015 04:10 AM, Andre Vehreschild wrote: > > Hi all, > > > > I fear this fix is not so obvious in one location, I therefore ask for a > > review. The

Re: [RFC] PR64703, glibc sysdeps/powerpc/powerpc64/dl-machine.h miscompile

On Fri, Jan 30, 2015 at 10:33:06AM +0100, Jakub Jelinek wrote: > On Fri, Jan 30, 2015 at 10:12:35AM +0100, Richard Biener wrote: > > Ok - without digging into why the above would fail with your patch > > (don't see that - the use in the function call can't be &opdd) - let's > > take a step back and

Re: [RFC][PR target/39726 P4 regression] match.pd pattern to do type narrowing

On Sun, Feb 1, 2015 at 6:46 AM, Jeff Law wrote: > On 01/31/15 17:47, Joseph Myers wrote: >> >> On Fri, 30 Jan 2015, Jeff Law wrote: >> >>> +/* If we are testing a single bit resulting from a binary >>> + operation in precision P1 where the operands were widened >>> + precision P2 and the teste

Re: [PATCH, PR tree-optimization/64277] Improve loop iterations count estimation

On Mon, Feb 2, 2015 at 9:19 AM, Ilya Enkovich wrote: > On 27 Jan 12:29, Richard Biener wrote: >> On Tue, Jan 27, 2015 at 11:47 AM, Ilya Enkovich >> wrote: >> > On 27 Jan 12:40, Ilya Enkovich wrote: >> >> Hi, >> >> >> >> This patch was supposed to fix PR tree-optimization/64277. Tracker is >> >

Re: [PATCHv2][wwwdocs] Mention -freport-bug in release notes

On Monday 2015-01-26 11:03, Yury Gribov wrote: Second version of patch with updates from Gerald Pfeifer. Ok to commit? Yes, this looks good. Thank you, Gerald

Re: [PATCH, PR tree-optimization/64277] Improve loop iterations count estimation

On 27 Jan 12:29, Richard Biener wrote: > On Tue, Jan 27, 2015 at 11:47 AM, Ilya Enkovich > wrote: > > On 27 Jan 12:40, Ilya Enkovich wrote: > >> Hi, > >> > >> This patch was supposed to fix PR tree-optimization/64277. Tracker is now > >> fixed by warnings disabling but I think patch is still us