C++ PATCH for C++/71121 (wrong -Waddress warning with PMF and constexpr)

The problem here was that the code that tries to prevent the -Waddress warning used cp_fully_fold, and later code used maybe_constant_value, and the latter simplified the operand more so that it exposed the ADDR_EXPR to the -Waddress warning. Fixed by calling maybe_constant_value from

[Bug c++/71463] [6/7 regression] unexpected warning: ignoring function return attributes on template argument

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71463 --- Comment #9 from Jason Merrill --- (In reply to Milian Wolff from comment #8) > As an interested bystander, may I ask: If the attribute is part of the type, > shouldn't it then be transferred via decltype() and then also used in the >

[gcc-4.4] Re: arch/x86/events/intel/uncore_snbep.o: warning: objtool: snbep_uncore_msr_enable_event()+0x2e: function has unreachable instruction

On Thu, Jul 21, 2016 at 11:06:06AM +0800, Liang, Kan wrote: Hi Fengguang, I located the unreachable instruction which is ud2. This instruction will raise invalid opcode exception. So I think normally it should not be reached. Also ud2 should be generated by compiler, not our codes. It's

Re: [C++ PATCH] Fix up genericization ICE (PR c++/71941)

OK. On Wed, Jul 20, 2016 at 5:05 PM, Jakub Jelinek wrote: > Hi! > > In PR69315, we've recently allowed recursive genericization, unfortunately > the bc_label handling isn't prepared for that, we ICE if we cp_genericize > some function (usually newly instantiated method) while

[libstdc++, C++17] Implement C++17 P0330 size_t UDL.

This patch defines operator""zu(unsigned long long __n) for size_t literals. for (auto k = 0zul; k < v.size(); ++k) ... Testing on x86-64-linux is finishing but I'm past these tests. OK? Ed 2016-07-21 Edward Smith-Rowland <3dw...@verizon.net> Implement C++17 P0330

[Bug c++/71954] New: template partial specialization for constexpr error

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71954 Bug ID: 71954 Summary: template partial specialization for constexpr error Product: gcc Version: 5.3.0 Status: UNCONFIRMED Severity: normal Priority: P3

Re: [PATCH, rs6000] Fix PR target/71733, ICE with -mcpu=power9 -mno-vsx

On 7/12/16 8:48 AM, Alan Modra wrote: On Tue, Jul 12, 2016 at 02:02:43PM +0200, Ulrich Weigand wrote: The second time around, get_secondary_mem should reuse the same stack slot it already allocated, and the elimination offsets should already be set to accommodate that stack slot, which means

Re: [PATCH] Fix source locations of bad enum values (PR c/71610 and PR c/71613)

On Wed, 2016-07-20 at 16:16 -0400, Jason Merrill wrote: > On Thu, Jun 30, 2016 at 1:49 PM, Jason Merrill > wrote: > > This needs a template testcase. > > Did you get this reply before? It bounced from the mailing list, but > I thought you would have gotten it directly. I did;

[Bug c++/71463] [6/7 regression] unexpected warning: ignoring function return attributes on template argument

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71463 --- Comment #8 from Milian Wolff --- As an interested bystander, may I ask: If the attribute is part of the type, shouldn't it then be transferred via decltype() and then also used in the template to trigger the warning there? To me, the example

gcc-4.9-20160720 is now available

Snapshot gcc-4.9-20160720 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.9-20160720/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.9 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches

Re: [PATCH v2] x86: allow to suppress default clobbers added to asm()s

On 07/06/2016 08:32 AM, Jan Beulich wrote: While it always seemed wrong to me that there's no way to avoid the default "flags" and "fpsr" clobbers, the regression the fix for PR/60663 introduced (see PR/63637) makes it even more desirable to have such a mechanism: This way, at least asm()s with

Re: [PATCH] Fix unsafe function attributes for special functions (PR 71876)

On 07/21/16 00:19, Bernd Edlinger wrote: > On 07/21/16 00:00, Jakub Jelinek wrote: >> On Wed, Jul 20, 2016 at 09:50:03PM +, Bernd Edlinger wrote: >>> But the built-in alloca is still recognized because the builtin >>> does have ECF_MAY_BE_ALLOCA and ECF_MALLOC. >> >> But

Re: [PATCH] Fix unsafe function attributes for special functions (PR 71876)

On 07/21/16 00:00, Jakub Jelinek wrote: > On Wed, Jul 20, 2016 at 09:50:03PM +, Bernd Edlinger wrote: >> But the built-in alloca is still recognized because the builtin >> does have ECF_MAY_BE_ALLOCA and ECF_MALLOC. > > But __builtin_alloca_with_align likely doesn't have ECF_MALLOC set (even >

-.Job in Canada

The new canada hotel is looking for over 100 foreign workers. Contact the Canadian Administrator by e-mail: forapplica...@yahoo.ca, if it interests you. Ray

Re: ubsan and Dejagnu not having a big enough buffer in some cases

On Wed, Jul 20, 2016 at 3:07 PM, Andrew Pinski wrote: > On Wed, Jul 20, 2016 at 2:57 PM, H.J. Lu wrote: >> On Wed, Jul 20, 2016 at 2:20 PM, Jeff Law wrote: >>> On 07/20/2016 03:09 PM, Andrew Pinski wrote: On Wed, Jul 20, 2016 at

Re: fold x ^ y to 0 if x == y

On 20 July 2016 at 23:07, Prathamesh Kulkarni wrote: > On 20 July 2016 at 16:35, Richard Biener wrote: >> On Wed, 20 Jul 2016, Prathamesh Kulkarni wrote: >> >>> On 8 July 2016 at 12:29, Richard Biener wrote: >>> > On Fri, 8

Re: fold x ^ y to 0 if x == y

On 20 July 2016 at 16:35, Richard Biener wrote: > On Wed, 20 Jul 2016, Prathamesh Kulkarni wrote: > >> On 8 July 2016 at 12:29, Richard Biener wrote: >> > On Fri, 8 Jul 2016, Richard Biener wrote: >> > >> >> On Fri, 8 Jul 2016, Prathamesh Kulkarni wrote: >>

Re: ubsan and Dejagnu not having a big enough buffer in some cases

On Wed, Jul 20, 2016 at 2:57 PM, H.J. Lu wrote: > On Wed, Jul 20, 2016 at 2:20 PM, Jeff Law wrote: >> On 07/20/2016 03:09 PM, Andrew Pinski wrote: >>> >>> On Wed, Jul 20, 2016 at 2:02 PM, Andrew Pinski wrote: On Wed, Jul 20,

Re: [PATCH] Fix unsafe function attributes for special functions (PR 71876)

On Wed, Jul 20, 2016 at 09:50:03PM +, Bernd Edlinger wrote: > But the built-in alloca is still recognized because the builtin > does have ECF_MAY_BE_ALLOCA and ECF_MALLOC. But __builtin_alloca_with_align likely doesn't have ECF_MALLOC set (even when it should). Jakub

Re: ubsan and Dejagnu not having a big enough buffer in some cases

On Wed, Jul 20, 2016 at 2:20 PM, Jeff Law wrote: > On 07/20/2016 03:09 PM, Andrew Pinski wrote: >> >> On Wed, Jul 20, 2016 at 2:02 PM, Andrew Pinski wrote: >>> >>> On Wed, Jul 20, 2016 at 1:32 PM, Jeff Law wrote: On 07/20/2016 02:21

Re: [PATCH]: Introduce HOST_WIDE_INT_0{,U}

On 07/20/2016 11:16 PM, Uros Bizjak wrote: As suggested by Jakub. 2016-07-20 Uros Bizjak * hwint.h (HOST_WIDE_INT_0): New define. (HOST_WIDE_INT_0U): Ditto. * double-int.c: Use HOST_WIDE_INT_0 instead of (HOST_WIDE_INT) 0. * dse.c: Use HOST_WIDE_INT_0U

Re: [PATCH][C++] C++ bitfield memory model for as-base classes

On 06/29/2016 05:54 AM, Richard Biener wrote: Currently as-base classes lack DECL_BIT_FIELD_REPRESENTATIVEs which means RTL expansion doesn't honor the C++ memory model for bitfields in them thus for the following testcase struct B { B() {} int x; int a : 6; int b : 6; int

Re: [PATCH] Fix unsafe function attributes for special functions (PR 71876)

On 07/20/16 20:08, Richard Biener wrote: > On July 20, 2016 6:54:48 PM GMT+02:00, Bernd Edlinger > wrote: >> >> But I think that alloca just should not be recognized by name any >> more. > > It was introduced to mark calls that should not be duplicated by inlining or

Re: [PATCH GCC]Vectorize possible infinite loops by versioning

On 06/28/2016 12:18 AM, Bin Cheng wrote: Hi, This patch improves vectorizer in order to handle possible infinite loops by versioning. Its changes fall in three categories. A) Changes in vect_get_loop_niters. AT the moment, it computes niter using number_of_executions_latch, in this way the

Re: ubsan and Dejagnu not having a big enough buffer in some cases

On 07/20/2016 03:09 PM, Andrew Pinski wrote: On Wed, Jul 20, 2016 at 2:02 PM, Andrew Pinski wrote: On Wed, Jul 20, 2016 at 1:32 PM, Jeff Law wrote: On 07/20/2016 02:21 PM, Segher Boessenkool wrote: On Wed, Jul 20, 2016 at 12:48:09PM +0530, Senthil Kumar

[Bug sanitizer/71953] New: ICE using sanitizers with PCH

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71953 Bug ID: 71953 Summary: ICE using sanitizers with PCH Product: gcc Version: 7.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3

[PATCH]: Introduce HOST_WIDE_INT_0{,U}

As suggested by Jakub. 2016-07-20 Uros Bizjak * hwint.h (HOST_WIDE_INT_0): New define. (HOST_WIDE_INT_0U): Ditto. * double-int.c: Use HOST_WIDE_INT_0 instead of (HOST_WIDE_INT) 0. * dse.c: Use HOST_WIDE_INT_0U instead of (unsigned HOST_WIDE_INT) 0. *

[Bug c++/71896] [6/7 Regression] Constexpr function with pointer to member parameter doesn't return constexpr value

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71896 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned

Re: ubsan and Dejagnu not having a big enough buffer in some cases

On Wed, Jul 20, 2016 at 2:02 PM, Andrew Pinski wrote: > On Wed, Jul 20, 2016 at 1:32 PM, Jeff Law wrote: >> On 07/20/2016 02:21 PM, Segher Boessenkool wrote: >>> >>> On Wed, Jul 20, 2016 at 12:48:09PM +0530, Senthil Kumar Selvaraj wrote: > > I see this

[C++ PATCH] Fix up genericization ICE (PR c++/71941)

Hi! In PR69315, we've recently allowed recursive genericization, unfortunately the bc_label handling isn't prepared for that, we ICE if we cp_genericize some function (usually newly instantiated method) while inside of some loop in the outer function. Fixed thusly, bootstrapped/regtested on

[Bug c++/70781] [6/7 Regression] ICE on invalid C++ code with lambda expressions on x86_64-linux-gnu in finish_expr_stmt, at cp/semantics.c:677

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70781 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned

Re: ubsan and Dejagnu not having a big enough buffer in some cases

On Wed, Jul 20, 2016 at 1:32 PM, Jeff Law wrote: > On 07/20/2016 02:21 PM, Segher Boessenkool wrote: >> >> On Wed, Jul 20, 2016 at 12:48:09PM +0530, Senthil Kumar Selvaraj wrote: I see this for some of the larger C frontend tests with lots of expected

Re: DejaGnu directive matching multiple messages on the same line

On 07/20/2016 02:28 PM, Jakub Jelinek wrote: On Wed, Jul 20, 2016 at 02:19:15PM -0600, Martin Sebor wrote: Is there a way to express a requirement that a single line cause two or more diagnostic messages (in any order) each matching one of the regex strings? Sure, and it is used many times in

[Bug c++/71117] [6/7 Regression] Overeager application of conversion to function pointer during overload resolution of call to function object

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71117 Jason Merrill changed: What|Removed |Added CC||vittorio.romeo at outlook dot com ---

[Bug c++/70942] [6/7 Regression] [c++14] Incorrect deduction of generic lambda `auto&&` parameter

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70942 Jason Merrill changed: What|Removed |Added Status|NEW |RESOLVED CC|

[Bug c++/70845] [6/7 Regression] inherited piecewise_construct_t constructor from std::pair by "using-declarations" is missing

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70845 Jason Merrill changed: What|Removed |Added Status|NEW |RESOLVED CC|

[Bug c++/70972] [6 Regression] Inheriting constructors taking parameters by value should move them, not copy

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70972 Jason Merrill changed: What|Removed |Added CC||tuwwcn at gmail dot com --- Comment #9

[Bug c++/54367] [meta-bug] lambda expressions

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54367 Bug 54367 depends on bug 70942, which changed state. Bug 70942 Summary: [6/7 Regression] [c++14] Incorrect deduction of generic lambda `auto&&` parameter https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70942 What|Removed

Re: ubsan and Dejagnu not having a big enough buffer in some cases

On 07/20/2016 02:21 PM, Segher Boessenkool wrote: On Wed, Jul 20, 2016 at 12:48:09PM +0530, Senthil Kumar Selvaraj wrote: I see this for some of the larger C frontend tests with lots of expected errors/warnings as well. I also see this for tests with small output, but it happens more often

[Bug c++/71121] [6/7 Regression] Spurious warning: "the address of [...] will never be NULL [-Waddress]"

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71121 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned

Re: DejaGnu directive matching multiple messages on the same line

On Wed, Jul 20, 2016 at 02:19:15PM -0600, Martin Sebor wrote: > Is there a way to express a requirement that a single line cause > two or more diagnostic messages (in any order) each matching one > of the regex strings? Sure, and it is used many times in the testsuite. whatever; /* { dg-error

[Bug fortran/71952] New: [Coarray, F2008] Rejects valid coarray access with array partref

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71952 Bug ID: 71952 Summary: [Coarray, F2008] Rejects valid coarray access with array partref Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal

Re: ubsan and Dejagnu not having a big enough buffer in some cases

On Wed, Jul 20, 2016 at 12:48:09PM +0530, Senthil Kumar Selvaraj wrote: > > I see this for some of the larger C frontend tests with lots of expected > > errors/warnings as well. I also see this for tests with small output, but it happens more often for tests with big output. > Are you guys

DejaGnu directive matching multiple messages on the same line

When multiple diagnostics for a given line in a test are expected, I have been using the vertical bar ('|') in regular expression arguments to DejaGnu directives like dg-error and dg-warning on the assumption that all are matched. This use appears to be sanctioned by the GCC TestCaseWriting Wiki

Re: [PATCH] target lib tests with build sysroot PR testsuite/71931

On 07/20/2016 08:04 AM, Szabolcs Nagy wrote: Fix target library tests when gcc is built using --with-build-sysroot. The dejagnu find_gcc function cannot handle if CC needs extra flags like --sysroot. So for testing target libraries use the same CC that was used for building the target libs.

Re: [PATCH] Fix source locations of bad enum values (PR c/71610 and PR c/71613)

On Thu, Jun 30, 2016 at 1:49 PM, Jason Merrill wrote: > This needs a template testcase. Did you get this reply before? It bounced from the mailing list, but I thought you would have gotten it directly. Jason

Re: [PATCH] Fix source locations of bad enum values (PR c/71610 and PR c/71613)

On 06/22/2016 08:52 PM, David Malcolm wrote: PR c/71613 identifies a problem where we fail to report this enum: enum { e1 = LLONG_MIN }; with -pedantic, due to LLONG_MIN being inside a system header. This patch updates the C and C++ frontends to use the location of the name as the primary

Re: [PING**2] [PATCH] Fix asm X constraint (PR inline-asm/59155)

On 06/22/2016 02:48 PM, Bernd Edlinger wrote: On 06/22/16 21:51, Jeff Law wrote: On 06/19/2016 07:25 AM, Bernd Edlinger wrote: Hi, ping... As this discussion did not make any progress, I just attached the latest version of my patch with the the changes that Vladimir proposed. Boot-strapped

Re: [PATCH] Fix unsafe function attributes for special functions (PR 71876)

> Very few targets continue to use SJLJ eh (perhaps just cygwin/mingw). > *But* I think the Ada front-end explicitly uses SJLJ EH, so if you want > to get some smoke testing, the Ada testsuite is probably the place to go. Right, the Ada front-end uses an EH scheme directly based on

Re: [PATCH build/doc] Replacing libiberty with gnulib

On 20 July 2016 at 19:21, ayush goel wrote: > Hey, > As a first step of my GSOC project > (https://gcc.gnu.org/wiki/replacelibibertywithgnulib) I have imported > the gnulib library inside the gcc tree. I have created gnulib as a top > level directory which contains the

Re: [PATCH] RFC: On-demand locations within string-literals

On Fri, 2016-07-08 at 17:49 -0400, David Malcolm wrote: [...] > Also, this patch currently makes the assumption (in charset.c) > that there's a 1:1 correspondence between bytes in the source > character set and bytes in the execution character set. This can > be the case if both are, say, UTF-8,

[Bug middle-end/71876] longjmp is miscompiled with -ffreestanding

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71876 --- Comment #11 from Bernd Edlinger --- (In reply to Jeffrey A. Law from comment #10) > No opinion on the "x" prefix. I think that was already in place when that > code was updated to support qsetjmp and savectx in the early 90s. I've > never

[Bug libstdc++/37475] [DR 382] codecvt::do_in/do_out functions return "ok" when the output sequence has zero length

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37475 --- Comment #4 from Jonathan Wakely --- Oops, I meant 382 is NAD http://cplusplus.github.io/LWG/lwg-closed.html#382 I'm not sure what (if anything) we need to do here though, someone needs to re-analyze.

Re: [PATCH] Fix unsafe function attributes for special functions (PR 71876)

=== acats Summary === # of expected passes2320 # of unexpected failures0 Native configuration is x86_64-pc-linux-gnu === gnat tests === Running target unix FAIL: gnat.dg/vect3.adb scan-tree-dump-times vect "vectorized 1 loops" 15 FAIL:

Re: [Fortran, Patch] First patch for coarray FAILED IMAGES (TS 18508)

Le 20/07/2016 à 11:39, Andre Vehreschild a écrit : Hi Mikael, + if(st == ST_FAIL_IMAGE) +new_st.op = EXEC_FAIL_IMAGE; + else +gcc_unreachable(); You can use gcc_assert (st == ST_FAIL_IMAGE); foo...; instead of if (st == ST_FAIL_IMAGE) foo...;

[Bug libstdc++/66145] [5/6/7 Regression] std::ios_base::failure objects thrown from libstdc++.so use old ABI

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66145 --- Comment #23 from Jonathan Wakely --- (In reply to Boris Kolpackov from comment #21) > Speaking of possible fixes, I had this crazy idea, not sure if it is > technically possible though: what if libstdc++ throws some custom exception > that

Re: [PATCH] Fix unsafe function attributes for special functions (PR 71876)

On 07/20/2016 10:30 AM, Bernd Edlinger wrote: On 07/20/16 18:15, Jeff Law wrote: On 07/20/2016 05:53 AM, Richard Biener wrote: Is it OK after boot-strap and regression-testing? I think the __builtin_setjmp change is wrong - __builtin_setjmp is _not_ 'setjmp' it is part of the GCC internal

[Bug middle-end/71876] longjmp is miscompiled with -ffreestanding

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71876 --- Comment #10 from Jeffrey A. Law --- No opinion on the "x" prefix. I think that was already in place when that code was updated to support qsetjmp and savectx in the early 90s. I've never seen the "x" versions in practice. ANd yes, you're

[Bug libgcc/71951] libgcc_s built with -fomit-frame-pointer on aarch64 is broken

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71951 --- Comment #7 from Timo Teräs --- (In reply to Andrew Pinski from comment #6) > (In reply to Timo Teräs from comment #5) > > Not easily. It's musl, and using iterate phdr. Same build script works on > > x86, x86_64 and armhf. It's only aarch64

Re: [PATCH] Fix unsafe function attributes for special functions (PR 71876)

On 07/20/2016 10:54 AM, Bernd Edlinger wrote: Yes. That is another interesting observation. I think, originally this flag was introduced by Jan Hubicka, and should mean, "it may be alloca or a weak alias to alloca or maybe even something different". But some of the later optimizations use it

[Bug middle-end/71876] longjmp is miscompiled with -ffreestanding

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71876 --- Comment #9 from Bernd Edlinger --- (In reply to Jeffrey A. Law from comment #8) > Light searching doesn't find anything useful for setjmp_syscall. > > savectx however still shows up in a variety of solaris searches. In fact, > you can find

Re: [PATCH] c++/60760 - arithmetic on null pointers should not be allowed in constant expressions

On Wed, Jul 20, 2016 at 2:15 PM, Martin Sebor wrote: > On 07/20/2016 07:52 AM, Jason Merrill wrote: >> >> On Mon, Jul 18, 2016 at 6:15 PM, Martin Sebor wrote: >>> >>> On 07/18/2016 11:51 AM, Jason Merrill wrote: On 07/06/2016 06:20 PM, Martin

Re: [PATCH] Fix unsafe function attributes for special functions (PR 71876)

On 07/20/2016 12:30 PM, Bernd Edlinger wrote: On 07/20/16 20:08, Richard Biener wrote: On July 20, 2016 6:54:48 PM GMT+02:00, Bernd Edlinger wrote: Yes. That is another interesting observation. I think, originally this flag was introduced by Jan Hubicka, and

[Bug c/70339] Poor message for "singed" vs "signed" typo

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70339 --- Comment #5 from David Malcolm --- Author: dmalcolm Date: Wed Jul 20 18:42:11 2016 New Revision: 238538 URL: https://gcc.gnu.org/viewcvs?rev=238538=gcc=rev Log: C++ FE: handle misspelled identifiers and typenames gcc/cp/ChangeLog:

[Bug c/71858] Surprising suggestions for misspellings

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71858 --- Comment #7 from David Malcolm --- Author: dmalcolm Date: Wed Jul 20 18:42:11 2016 New Revision: 238538 URL: https://gcc.gnu.org/viewcvs?rev=238538=gcc=rev Log: C++ FE: handle misspelled identifiers and typenames gcc/cp/ChangeLog:

Re: [PATCH] Add priority_queue::value_compare (LWG 2684)

On 24/05/16 17:02 +0100, Jonathan Wakely wrote: * include/bits/stl_queue.h (priority_queue::value_compare): Define. This is only Tentatively Ready but I don't think there's any harm in making the change now. Libc++ have been shipping this for years, without realising it wasn't actually

[PATCH] LWG 2441 Provide exact-width atomic typedefs

* include/std/atomic (atomic_int8_t, atomic_uint8_t, atomic_int16_t) (atomic_uint16_t, atomic_int32_t, atomic_uint32_t, atomic_int64_t) (atomic_uint64_t): Define (LWG 2441). * testsuite/29_atomics/headers/atomic/std_c++0x_neg.cc: Remove empty lines.

[Committed] S/390: Remove mode size check in encode_section_info.

With the last change the not-aligned symbol ref markers are always set for modes with size zero. This is wrong since for larl the size of the access does not matter. This patch removes that check entirely from s390_encode_section_info. Modes with a size of 0 get rejected in

[Bug libgcc/71951] libgcc_s built with -fomit-frame-pointer on aarch64 is broken

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71951 --- Comment #6 from Andrew Pinski --- (In reply to Timo Teräs from comment #5) > Not easily. It's musl, and using iterate phdr. Same build script works on > x86, x86_64 and armhf. It's only aarch64 misbehaving like this with omit > frame

Re: [PATCH] Fix unsafe function attributes for special functions (PR 71876)

On 07/20/16 20:08, Richard Biener wrote: > On July 20, 2016 6:54:48 PM GMT+02:00, Bernd Edlinger > wrote: >> >> Yes. That is another interesting observation. I think, originally this >> flag was introduced by Jan Hubicka, and should mean, "it may be alloca >> or a

[Bug c++/62096] unexpected warning overflow in implicit constant conversion

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62096 Jason Merrill changed: What|Removed |Added CC||jason at gcc dot gnu.org

[Bug middle-end/71876] longjmp is miscompiled with -ffreestanding

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71876 Jeffrey A. Law changed: What|Removed |Added CC||law at redhat dot com --- Comment #8

[PATCH] LWG 2328 Rvalue stream extraction should use perfect forwarding

* include/std/istream (operator>>(basic_istream&&, _Tp&)): Adjust to use perfect forwarding (LWG 2328). * testsuite/27_io/rvalue_streams.cc: Test perfect forwarding. * doc/xml/manual/intro.xml: Document DR 2328 status. Teted x86_64-linux, committed to trunk.

[PATCH build/doc] Replacing libiberty with gnulib

Hey, As a first step of my GSOC project (https://gcc.gnu.org/wiki/replacelibibertywithgnulib) I have imported the gnulib library inside the gcc tree. I have created gnulib as a top level directory which contains the necessary scripts to import the modules. It also contains the necessary

[Bug libgcc/71951] libgcc_s built with -fomit-frame-pointer on aarch64 is broken

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71951 --- Comment #5 from Timo Teräs --- Not easily. It's musl, and using iterate phdr. Same build script works on x86, x86_64 and armhf. It's only aarch64 misbehaving like this with omit frame pointer. Any other suggestions what to try/how to debug

Re: [PATCH] c++/60760 - arithmetic on null pointers should not be allowed in constant expressions

On 07/20/2016 07:52 AM, Jason Merrill wrote: On Mon, Jul 18, 2016 at 6:15 PM, Martin Sebor wrote: On 07/18/2016 11:51 AM, Jason Merrill wrote: On 07/06/2016 06:20 PM, Martin Sebor wrote: @@ -2911,6 +2923,14 @@ cxx_eval_indirect_ref (const constexpr_ctx *ctx, tree t,

[Bug libgcc/71951] libgcc_s built with -fomit-frame-pointer on aarch64 is broken

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71951 --- Comment #4 from Andrew Pinski --- Can you try this on a glibc instead musl?

Re: [PATCH] Fix unsafe function attributes for special functions (PR 71876)

On July 20, 2016 6:54:48 PM GMT+02:00, Bernd Edlinger wrote: >On 07/20/16 18:20, Jeff Law wrote: >> On 07/20/2016 09:41 AM, Bernd Edlinger wrote: >>> On 07/20/16 12:44, Richard Biener wrote: On Tue, 19 Jul 2016, Bernd Edlinger wrote: > Hi! > > As

[Bug libgcc/71951] libgcc_s built with -fomit-frame-pointer on aarch64 is broken

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71951 --- Comment #3 from Timo Teräs --- $ cat a.cpp < int foo() { throw "Foo!"; } int main () { try { foo(); }catch (const char* msg) { std::cerr << msg << std::endl; } return 0; } EOF $ gdb a GNU gdb (GDB) 7.11.1

[Bug libgcc/71951] libgcc_s built with -fomit-frame-pointer on aarch64 is broken

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71951 --- Comment #2 from Andrew Pinski --- Do you have an example? Because I ran with omit frame pointer all the time.

[Bug libgcc/71951] libgcc_s built with -fomit-frame-pointer on aarch64 is broken

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71951 --- Comment #1 from Andrew Pinski --- Unwind code in lib gcc does uses the dwarf2 unwinding tables. So omit frame pointer should not change anything.

[Bug libgcc/71951] New: libgcc_s built with -fomit-frame-pointer on aarch64 is broken

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71951 Bug ID: 71951 Summary: libgcc_s built with -fomit-frame-pointer on aarch64 is broken Product: gcc Version: 6.1.0 Status: UNCONFIRMED Severity: normal

[Bug libstdc++/66145] [5/6/7 Regression] std::ios_base::failure objects thrown from libstdc++.so use old ABI

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66145 Shital Shah changed: What|Removed |Added CC||sytelus at gmail dot com --- Comment #22

[Bug libstdc++/71950] New: std::ios_base::failure.what() returns irrelevant error message

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71950 Bug ID: 71950 Summary: std::ios_base::failure.what() returns irrelevant error message Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal

Re: [PATCH test]XFAIL gcc.dg/vect/vect-mask-store-move-1.c

On 07/20/2016 10:58 AM, Bin Cheng wrote: Hi, After patch @238301, issue reported in PR65206 is also exposed by case gcc.dg/vect/vect-mask-store-move-1.c. This patch xfail the case for the moment. Test result checked, is it OK? Thanks, bin gcc/testsuite/ChangeLog 2016-07-14 Bin Cheng

Re: [Patch, testsuite, tentative] Explicitly disable pointer <-> int cast warnings for avr?

On Jul 19, 2016, at 10:37 PM, Senthil Kumar Selvaraj wrote: > The patch fixes a couple of testsuite failures that show up for the > avr target because it has different sizes for longs and pointers (4 > bytes versus 2), by explicitly disabling the warning for

Re: [PATCH] S/390: Fix pr67443.c.

On 07/20/2016 01:55 PM, Dominik Vogt wrote: > The attached patch rewrites the pr67443.c testcase in a different > way so that the test still works with the changed allocation of > globals pinned to registers. The test ist hopefully more robust > now. The test ist hopefully more robust now.

Re: [PATCH] S/390: Xfail some tests in insv-[12].c.

On 07/19/2016 11:40 AM, Dominik Vogt wrote: > The attached patch XFAILs some of the "insv" testcases as > discussed internally. Tested on s390x biarch and s390. Applied. Thanks! -Andreas-

[PATCH #2], PowerPC support to enable -mlra and/or -mfloat128

This patch renames the configure switches to be explicit that they are for the PowerPC, and that they are temporary. I would hope by the time GCC 7 exits stage1 that these switches will be removed, but having them now will allow us to move to LRA and __float128 in an orderly fashion. I built a

Re: [AArch64][8/14] ARMv8.2-A FP16 two operands scalar intrinsics

On 07/07/16 17:17, Jiong Wang wrote: This patch add ARMv8.2-A FP16 two operands scalar intrinsics. The updated patch resolve the conflict with https://gcc.gnu.org/ml/gcc-patches/2016-06/msg00309.html The change is to let aarch64_emit_approx_div return false for HFmode. gcc/ 2016-07-20

Re: [AArch64][7/14] ARMv8.2-A FP16 one operand scalar intrinsics

On 07/07/16 17:17, Jiong Wang wrote: This patch add ARMv8.2-A FP16 one operand scalar intrinsics Scalar intrinsics are kept in arm_fp16.h instead of arm_neon.h. The updated patch resolve the conflict with https://gcc.gnu.org/ml/gcc-patches/2016-06/msg00308.html The change is to let

Re: [AArch64][3/14] ARMv8.2-A FP16 two operands vector intrinsics

On 07/07/16 17:15, Jiong Wang wrote: This patch add ARMv8.2-A FP16 two operands vector intrinsics. The updated patch resolve the conflict with https://gcc.gnu.org/ml/gcc-patches/2016-06/msg00309.html The change is to let aarch64_emit_approx_div return false for V4HFmode and V8HFmode.

Re: [AArch64][2/14] ARMv8.2-A FP16 one operand vector intrinsics

On 07/07/16 17:14, Jiong Wang wrote: This patch add ARMv8.2-A FP16 one operand vector intrinsics. We introduced new mode iterators to cover HF modes, qualified patterns which was using old mode iterators are switched to new ones. We can't simply extend old iterator like VDQF to conver HF

[PATCH test]XFAIL gcc.dg/vect/vect-mask-store-move-1.c

Hi, After patch @238301, issue reported in PR65206 is also exposed by case gcc.dg/vect/vect-mask-store-move-1.c. This patch xfail the case for the moment. Test result checked, is it OK? Thanks, bin gcc/testsuite/ChangeLog 2016-07-14 Bin Cheng *

Re: [PATCH] Fix unsafe function attributes for special functions (PR 71876)

On 07/20/16 18:20, Jeff Law wrote: > On 07/20/2016 09:41 AM, Bernd Edlinger wrote: >> On 07/20/16 12:44, Richard Biener wrote: >>> On Tue, 19 Jul 2016, Bernd Edlinger wrote: >>> Hi! As discussed at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71876, we have a _very_ old hack in

[PATCH GCC]Cleanup lt_to_ne handling in niter analyzer

Hi, This patch cleans up function number_of_iterations_lt_to_ne mainly by removing computation of may_be_zero. The computation is unnecessary and may_be_zero in this case must be true. Specifically, DELTA is integer constant and iv0.base < iv1.base bounds to be true because the false case is

Re: [Re: RFC: Patch 1/2 v3] New target hook: max_noce_ifcvt_seq_cost

On Wed, Jul 20, 2016 at 01:41:39PM +0200, Bernd Schmidt wrote: > On 07/20/2016 11:51 AM, James Greenhalgh wrote: > > > > >2016-07-20 James Greenhalgh > > > > * target.def (max_noce_ifcvt_seq_cost): New. > > * doc/tm.texi.in (TARGET_MAX_NOCE_IFCVT_SEQ_COST):

Re: [PATCH] Fix assembler arguments for -m16

On Wed, Jul 06, 2016 at 04:18:49PM +0200, Roger Pau Monne wrote: > At the moment the -m16 option only passes the "--32" parameter to the > assembler on glibc OSes, while on other OSes the assembler is called without > any specific flag. This is wrong and causes the assembler to fail. Fix it > by

Re: [PATCH] Fix unsafe function attributes for special functions (PR 71876)

On 07/20/16 18:15, Jeff Law wrote: > On 07/20/2016 05:53 AM, Richard Biener wrote: >>> Is it OK after boot-strap and regression-testing? >> >> I think the __builtin_setjmp change is wrong - __builtin_setjmp is >> _not_ 'setjmp' it is part of the GCC internal machinery (using setjmp >> and longjmp

[Bug gcov-profile/69004] Building t-engine on ARM fails during -fprofile-use stage

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69004 --- Comment #16 from PeteVine --- I've just read 4.9.4 is to be released soon - any chance of landing a fix for this issue?

  1   2   3   >