[Bug go/79037] gccgo: Binaries crash with parforsetup: pos is not aligned on m68k

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79037 --- Comment #8 from Michael Karcher --- The patch looks like it should work fine, I guess John Paul Adrian Glaubitz is going to test it soon. But I wonder whether the determination of alignment is in types.cc really needed, as user-specified

Re: How to configure a bi-arch PowerPC GCC?

Hello Segher, On 20/01/17 02:04, Segher Boessenkool wrote: Hi, On Thu, Jan 19, 2017 at 01:41:33PM +0100, Sebastian Huber wrote: conftest.c:16:1: error: unrecognizable insn: } ^ (insn/f 22 21 23 2 (parallel [ (set (reg/f:DI 1 1) (plus:SI (reg/f:DI 1 1)

Re: [RFC] Further LRA subreg handling issues

> I'll run testing for at least x86_64, MIPS and another > WORD_REGISTER_OPERATIONS target and try to get this committed in the next > couple of days so it can get into everyone's testing well before release. I'm going to give it a try on SPARC. -- Eric Botcazou

Re: need offline deb installation

Hi. This is the qmail-send program at sourceware.org. I'm afraid I wasn't able to deliver your message to the following addresses. This is a permanent error; I've given up. Sorry it didn't work out. : Sorry, no mailbox here by that name. (#5.1.1)

Re: need offline deb installation

my question is about downloading gcc for Ubuntu. I'm sorry I used the wrong mailing list, and will ask my next question there. thank you for your time.

C++ PATCH for C++17 class deduction issues US 19/20

wg21.link/p0512r0 proposes resolutions for some issues with class template argument deduction raised in national body comments against the C++17 draft; the paper hasn't been accepted yet, but the proposals seem sensible, so I'm implementing them here. The first makes deduction guides take

[PATCH] rs6000: Small varargs for BE SVR4 (PR61729, PR77850)

The varargs code for SVR4 puts all (integer) arguments in 4-byte slots. When it then reads an item from there as something not a multiple of 4 bytes, it needs to adjust the address if big endian. We didn't yet do that. This fixes the g++.dg/abi/scoped1.C, gcc.dg/compat/scalar-by-value-4, and

[Bug go/79037] gccgo: Binaries crash with parforsetup: pos is not aligned on m68k

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79037 --- Comment #7 from Ian Lance Taylor --- Can someone with m68k hardware please test the patch at https://golang.org/cl/35478? Thanks. (To download just the patch as a zip file:

Re: [1/5][AArch64] Return address protection on AArch64

On Fri, Jan 6, 2017 at 3:47 AM, Jiong Wang wrote: > On 11/11/16 18:22, Jiong Wang wrote: >> >> As described in the cover letter, this patch implements return address >> signing >> for AArch64, it's controlled by the new option: >> >>-msign-return-address=[none |

[Bug tree-optimization/79159] [7 regression] spurious array-bounds warning

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79159 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |NEW Known to work|

[Bug go/79037] gccgo: Binaries crash with parforsetup: pos is not aligned on m68k

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79037 --- Comment #6 from Ian Lance Taylor --- I don't think it's the type descriptors that need to be aligned, I think it's just the GC symbol pointers. Those are the ones whose names end in "$gc" in the list above.

[Bug go/79146] [7 Regression] Bootstrapping go on s390x fails; redefined symbols

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79146 Ian Lance Taylor changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug libstdc++/72793] pointer_traits is too strict about rebinding

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72793 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug libstdc++/72792] allocator_traits is too strict about rebinding

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72792 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[PATCH] PR72792 PR72793 relax requirements on rebind members

I misread the specifications for pointer_traits::rebind and allocator_traits::rebind_alloc and was requiring them to be valid for any specialization of the class templates. In fact they're only needed if instantiated. This fixes the problem. PR libstdc++/72792 PR libstdc++/72793

[Bug libstdc++/72792] allocator_traits is too strict about rebinding

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72792 --- Comment #1 from Jonathan Wakely --- Author: redi Date: Fri Jan 20 02:36:16 2017 New Revision: 244680 URL: https://gcc.gnu.org/viewcvs?rev=244680=gcc=rev Log: PR72792 PR72793 relax requirements on rebind members PR libstdc++/72792

[Bug libstdc++/72793] pointer_traits is too strict about rebinding

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72793 --- Comment #1 from Jonathan Wakely --- Author: redi Date: Fri Jan 20 02:36:16 2017 New Revision: 244680 URL: https://gcc.gnu.org/viewcvs?rev=244680=gcc=rev Log: PR72792 PR72793 relax requirements on rebind members PR libstdc++/72792

[Bug go/79146] [7 Regression] Bootstrapping go on s390x fails; redefined symbols

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79146 --- Comment #1 from ian at gcc dot gnu.org --- Author: ian Date: Fri Jan 20 02:27:46 2017 New Revision: 244679 URL: https://gcc.gnu.org/viewcvs?rev=244679=gcc=rev Log: PR go/79146 crypto/elliptic: explicitly ignore p256_s390x.go

libgo patch committed: Fix build on s390x GNU/Linux

This patch to libgo fixes the build on s390x GNU/Linux by ignoring an s390x-specific file that only works in conjunction with s390x assembly code that has not (yet) been ported to gccgo. Bootstrapped and ran Go tests on x86_64-pc-linux-gnu, which admittedly proves little. Verified that the right

[Bug c++/79091] [7 regression] ICE in write_unnamed_type

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79091 --- Comment #7 from scott snyder --- Confirmed that this fixes the original problem from which the test case was derived. Thanks!

[PATCH] PR69321 fix any_cast(any*) for non-copyable T

any_cast must not trigger the instantiation of the manager function for types which don't meet the requirements for being stored in an any object. PR libstdc++/69321 * include/experimental/any (__any_caster): Avoid instantiating manager function for types that can't be

[Bug libstdc++/69321] Error on use of non-copyable type with any_cast

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69321 Jonathan Wakely changed: What|Removed |Added Keywords||rejects-valid Status|NEW

[Bug target/79140] gcc.target/powerpc/ssp-1.c fails starting with its introduction in r244562

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79140 --- Comment #2 from Segher Boessenkool --- Author: segher Date: Fri Jan 20 01:22:27 2017 New Revision: 244677 URL: https://gcc.gnu.org/viewcvs?rev=244677=gcc=rev Log: rs6000: Fix the new SSP guard configuration code (PR79140) I foolishly

[Bug libstdc++/69321] Error on use of non-copyable type with any_cast

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69321 --- Comment #1 from Jonathan Wakely --- Author: redi Date: Fri Jan 20 01:22:54 2017 New Revision: 244678 URL: https://gcc.gnu.org/viewcvs?rev=244678=gcc=rev Log: PR69321 fix any_cast(any*) for non-copyable T PR libstdc++/69321

[Bug target/78875] -fstack-protector on powerpc64 now always use TLS, won't work for kernel/firmware

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78875 --- Comment #5 from Segher Boessenkool --- Author: segher Date: Fri Jan 20 01:22:27 2017 New Revision: 244677 URL: https://gcc.gnu.org/viewcvs?rev=244677=gcc=rev Log: rs6000: Fix the new SSP guard configuration code (PR79140) I foolishly

RE: [patch mips/gcc] add build-time and runtime options to disable or set madd.fmt type

> -Original Message- > From: Matthew Fortune [mailto:matthew.fort...@imgtec.com] > Sent: Thursday, January 19, 2017 5:30 PM > To: Moore, Catherine > Cc: 'Aurelien Jarno' ; 'Richard Sandiford' > ; Loosemore,

Re: How to configure a bi-arch PowerPC GCC?

Hi, On Thu, Jan 19, 2017 at 01:41:33PM +0100, Sebastian Huber wrote: > conftest.c:16:1: error: unrecognizable insn: > } > ^ > (insn/f 22 21 23 2 (parallel [ > (set (reg/f:DI 1 1) > (plus:SI (reg/f:DI 1 1) > (const_int 16 [0x10]))) >

[Bug c++/59960] accepts ill-formed 'auto a1 = t1, a2 = t2;' where t1 and t2 have different template types

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59960 Martin Dorey changed: What|Removed |Added CC||martindorey at gmail dot com --- Comment

[Bug c++/79009] Missing 'inconsistent deduction for ‘auto’' error when having a dependent initializer and a nondependent one in the same declaration

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79009 Martin Dorey changed: What|Removed |Added CC||martindorey at gmail dot com --- Comment

[Bug libstdc++/64903] is_partitioned should not apply a predicate more than (last - first) times

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64903 --- Comment #6 from Jonathan Wakely --- Author: redi Date: Fri Jan 20 00:33:25 2017 New Revision: 244675 URL: https://gcc.gnu.org/viewcvs?rev=244675=gcc=rev Log: PR64903 simplify last fix to std::is_partitioned PR libstdc++/64903

[PATCH] Fix PR c++/64382

Hi Jason, I've reopened 64382 and unhooked it from 61636 (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64382#c6). This is a rebase of my original patch for 64382 from April 2015 against latest master. My query about caching parsing_default_capturing_generic_lambda_in_template() still applies.

Re: [PATCH] PR64903 fix number of predicate tests in std::is_partitioned

On 20/01/17 00:11 +, Jonathan Wakely wrote: On 19/01/17 19:08 -0500, Tim Song wrote: On Thu, Jan 19, 2017 at 6:33 PM, Jonathan Wakely wrote: std::advance(__first, 1); Why not just ++__first;? Good question. I have no idea why I did it like that! Fixed like so.

[Bug libstdc++/54043] [LWG 2221] cout << nullptr does not work

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54043 --- Comment #15 from Jonathan Wakely --- The result is supposed to be a null-terminated string, so we could do what glibc's printf does for null pointers and print "(nil)" but we'd have to widen the string to the stream's char_type.

Re: [PATCH] rs6000: Fix the new SSP guard configuration code (PR79140)

On Thu, Jan 19, 2017 at 6:00 PM, Segher Boessenkool wrote: > I foolishly tested this with r241087 reverted. After that revision > default_stack_protect_guard is no longer called if the compiler defaults > to using the TLS guard, which of course is the wrong thing to

[Bug target/79127] [7 Regression] Error: invalid register for .seh_savexmm in matmul_i4.c

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79127 Ian Harvey changed: What|Removed |Added CC||ian_harvey at bigpond dot com --- Comment

Re: [PATCH] PR64903 fix number of predicate tests in std::is_partitioned

On 19/01/17 19:08 -0500, Tim Song wrote: On Thu, Jan 19, 2017 at 6:33 PM, Jonathan Wakely wrote: std::advance(__first, 1); Why not just ++__first;? Good question. I have no idea why I did it like that!

[Bug libstdc++/79156] incorrect c++ usage in gcc7 void function returns a value

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79156 Jonathan Wakely changed: What|Removed |Added Keywords||rejects-valid Status|NEW

Re: [PATCH] PR64903 fix number of predicate tests in std::is_partitioned

On Thu, Jan 19, 2017 at 6:33 PM, Jonathan Wakely wrote: > std::advance(__first, 1); Why not just ++__first;?

[PATCH] PR79156 fix std::__enable_shared_from_this extension

A couple of silly bugs in the non-standard __enable_shared_from_this extension. PR libstdc++/79156 * include/bits/shared_ptr_base.h (__enable_shared_from_this_base): Fix return type. (__enable_shared_from_this): Declare __shared_ptr as a friend. *

[Bug libstdc++/79156] incorrect c++ usage in gcc7 void function returns a value

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79156 --- Comment #2 from Jonathan Wakely --- Author: redi Date: Fri Jan 20 00:07:14 2017 New Revision: 244668 URL: https://gcc.gnu.org/viewcvs?rev=244668=gcc=rev Log: PR79156 fix std::__enable_shared_from_this extension PR libstdc++/79156

[Bug target/79144] cmpstrnsi optimization breaks glibc

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79144 Alan Modra changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|---

[Bug libstdc++/64903] is_partitioned should not apply a predicate more than (last - first) times

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64903 Jonathan Wakely changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[Bug c++/64382] ICE due to use of `this` inside a lambda that captures everything by ref inside a member function of a class template

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64382 Adam Butcher changed: What|Removed |Added Status|RESOLVED|ASSIGNED Resolution|DUPLICATE

RE: [RFC] Further LRA subreg handling issues

Vladimir Makarov writes: > On 01/16/2017 10:47 AM, Matthew Fortune wrote: > > Hi Vladimir, > > > > I'm working on PR target/78660 which is looking like a latent LRA bug. > > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78660 > > > > I believe the problem is in the same

[PATCH] PR64903 fix number of predicate tests in std::is_partitioned

PR libstdc++/64903 * include/bits/stl_algo.h (is_partioned): Don't retest the partition point. * testsuite/25_algorithms/is_partitioned/2.cc: New test. Tested powerpc64le-linux, committed to trunk. commit 5e9b690d27ac3cecf138bac904606f5728ca452f Author: Jonathan

[Bug libstdc++/64903] is_partitioned should not apply a predicate more than (last - first) times

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64903 --- Comment #4 from Jonathan Wakely --- Author: redi Date: Thu Jan 19 23:30:18 2017 New Revision: 244661 URL: https://gcc.gnu.org/viewcvs?rev=244661=gcc=rev Log: PR64903 fix number of predicate tests in std::is_partitioned PR

Re: [RFC] Further LRA subreg handling issues

On 01/16/2017 10:47 AM, Matthew Fortune wrote: Hi Vladimir, I'm working on PR target/78660 which is looking like a latent LRA bug. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78660 I believe the problem is in the same area as a bug was fixed in 2015:

[Bug target/77333] Incorrect stack adjust in epilogue when targeting i686-w64-mingw32

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77333 --- Comment #9 from Tony Kelman --- How can we help get this moving towards resolution? This has kept us stuck on GCC 4.9, which is getting increasingly problematic. We can attempt to reduce this to "minimal working piece of opt.exe with gcc

Re: Re: Fortran, committed: Forall-with-temporary problems(pr 50069 and pr 55086).

I was able to reproduce this on my x86 box by doing "make -k check". Apparently, "make check-fortran" wasn't enough to catch all of the consequences of changing gcc/fortran/lang.opt. The problem was the help text associated with the -ftest-forall-temp option; it needed to end with a period,

[Bug target/79144] cmpstrnsi optimization breaks glibc

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79144 --- Comment #3 from Alan Modra --- Author: amodra Date: Thu Jan 19 23:19:19 2017 New Revision: 244659 URL: https://gcc.gnu.org/viewcvs?rev=244659=gcc=rev Log: [RS6000] PR79144, cmpstrnsi optimization breaks glibc glibc compiled with current

Re: [PATCH] PR69699 document why __GLIBCXX__ macro is useless

On 17/01/17 15:36 +, Jonathan Wakely wrote: The closest thing we have to a version macro in libstdc++ is __GLIBCXX__ which holds the valid of gcc/DATESTAMP from the source tree. That's useless for version checking or feature testing because snapshots have arbitrary values and there's no

Re: [PATCH] Introduce --with-gcc-major-version-only configure option (take 2)

On 19.01.2017 13:26, Jakub Jelinek wrote: > On Thu, Jan 19, 2017 at 01:13:14PM +0100, Franz Sirl wrote: >> Am 2017-01-12 um 21:16 schrieb Jakub Jelinek: >>> libmpx/ >>> * configure.ac: Add GCC_BASE_VER. >>> * Makefile.am (gcc_version): Use @get_gcc_base_ver@ instead of cat to >>> get

[Bug libstdc++/51965] Redundant move constructions in heap algorithms

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51965 Jonathan Wakely changed: What|Removed |Added Last reconfirmed|2012-01-24 00:00:00 |2017-1-19 Target Milestone|---

[Bug libstdc++/67085] priority queue should not copy comparators when calling push_heap and pop_heap

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67085 --- Comment #14 from Jonathan Wakely --- Author: redi Date: Thu Jan 19 23:07:52 2017 New Revision: 244656 URL: https://gcc.gnu.org/viewcvs?rev=244656=gcc=rev Log: PR67085 pass comparison functions by reference in heap algorithms PR

[Bug libstdc++/67085] priority queue should not copy comparators when calling push_heap and pop_heap

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67085 Jonathan Wakely changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[PATCH,rs6000] Correct argument and result types for binary floating point built-in functions

This patch corrects several errors in a patch originally committed on 2016-08-10. The following corrections are required to maintain compliance with "Power Architecture 64-Bit ELF V2 ABI Specification", also known as "OpenPOWER ABI for Linux Supplement". vector unsigned long long

Re: [PATCH] PR67085 move comparison functions in heap operations

On 19/01/17 20:24 +, Jonathan Wakely wrote: On 19/01/17 18:50 +, Jonathan Wakely wrote: On 19/01/17 18:28 +, Jonathan Wakely wrote: @@ -397,7 +401,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION while (__last - __first > 1) { --__last; - std::__pop_heap(__first,

[PATCH] rs6000: Fix the new SSP guard configuration code (PR79140)

I foolishly tested this with r241087 reverted. After that revision default_stack_protect_guard is no longer called if the compiler defaults to using the TLS guard, which of course is the wrong thing to do if there is some other way to enable the global guard. This fixes it. Is this okay for

[PATCH, pr63256] update powerpc dg options

SMS does process the loop in sms-8.c on powerpc now so I have updated the options to reflect that. Test now passes on powerpc -m64/-m32/-m32 -mpowerpc64. Ok for trunk? testsuite/ChangeLog 2017-01-19  Aaron Sawdey   * gcc.dg/sms-8.c: Update options for

[Bug target/69992] test case gcc.dg/sms-4.c fails

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69992 --- Comment #1 from acsawdey at gcc dot gnu.org --- At some point the doloop analysis must have changed and as a result declared that the loop might run infinitely if compiled with -m64. This in turn causes SMS to bail out and the test fails. The

Re: [RS6000] Don't expand strcmp and strncmp inline when -Os

On Thu, Jan 19, 2017 at 10:47:12PM +1030, Alan Modra wrote: > --- a/gcc/config/rs6000/rs6000.md > +++ b/gcc/config/rs6000/rs6000.md > @@ -9102,7 +9102,8 @@ (define_expand "cmpstrnsi" > (use (match_operand:SI 4))])] >"TARGET_CMPB && (BYTES_BIG_ENDIAN || TARGET_LDBRX)" > { > - if

gcc-6-20170119 is now available

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

Re: [RS6000] PR79144, cmpstrnsi optimization breaks glibc

On Thu, Jan 19, 2017 at 10:44:27PM +1030, Alan Modra wrote: > glibc compiled with current gcc-7 fails one test due to strcmp and > strncmp appearing in the PLT. This is because the inline expansion of > those functions falls back to a function call, but not using the asm > name for the call.

RE: [patch mips/gcc] add build-time and runtime options to disable or set madd.fmt type

Matthew Fortune writes: > I've rewritten/simplified this patch as it provides far too much control > to end users who will undoubtedly shoot themselves in the foot so to > speak. The option I intend to support is simply --with-madd4 --without-madd4 > and -mmadd4

Re: [PATCH], PowerPC ISA 3.0 defaults + IEEE 128-bit floating point test

On Wed, Jan 18, 2017 at 08:35:05PM -0500, Michael Meissner wrote: > This patch changes the default options enabled for the PowerPC -mcpu=power9 > option to include the undocumented -mpower9-minmax option. This option > enables > MIN/MAX instructions that do not require -ffast-math or

[Bug target/78478] Compile Error for i386-rtems

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78478 --- Comment #25 from Uroš Bizjak --- (In reply to Joel Sherrill from comment #24) > Would you mind applying this to the 6.x branch? That was where the issue was > initially spotted. Sure, but let's wait for a week if everything works OK in the

[Bug testsuite/68972] g++.dg/cpp1y/vla-initlist1.C test case fails on powerpc64le

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68972 --- Comment #9 from Bill Schmidt --- The test has gone back to not failing anymore at some point: https://gcc.gnu.org/ml/gcc-testresults/2017-01/msg01932.html I don't know why.

[Bug target/79160] gcc.target/powerpc/vsx-elemrev-4.c fails on powerpc BE

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79160 seurer at gcc dot gnu.org changed: What|Removed |Added Target||powerpc64-unknown-linux-gnu

[Bug target/79160] New: gcc.target/powerpc/vsx-elemrev-4.c fails on powerpc BE

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79160 Bug ID: 79160 Summary: gcc.target/powerpc/vsx-elemrev-4.c fails on powerpc BE Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3

[Bug c/69558] [6/7 Regression] glib2 warning pragmas stopped working

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69558 --- Comment #17 from David Malcolm --- Remaining XFAILs for this bug: c-c++-common/pr69558.c (C++ only)

[Bug preprocessor/69543] [6/7 Regression] _Pragma does not apply within macro

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69543 --- Comment #11 from David Malcolm --- (In reply to David Malcolm from comment #10) > The lines in comment #9 came from 18f0e0e551a995687e1822aabb9b7d7ee8f11492 > aka r186971 (affecting gcc.dg/cpp/pragma-diagnostic-2.c) This was: "[PATCH

[PATCH, i386]: Remove config/i386/rtems-64.h

Hello! This file is now the same as config/i386/rtemself.h. Remove one copy. 2017-01-19 Uros Bizjak * config.gcc (x86_64-*-rtems*): Use i386/rtemself.h instead of i386/rtems-64.h. * config/i386/rtems-64.h: Remove. Committed as obvious. Uros. Index:

[Bug target/69992] test case gcc.dg/sms-4.c fails

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69992 acsawdey at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last

[Bug target/78478] Compile Error for i386-rtems

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78478 --- Comment #24 from Joel Sherrill --- Would you mind applying this to the 6.x branch? That was where the issue was initially spotted. I don't know what to do about this extra line in rtemself.h though. It was not present in the master

[Bug preprocessor/69543] [6/7 Regression] _Pragma does not apply within macro

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69543 --- Comment #10 from David Malcolm --- The lines in comment #9 came from 18f0e0e551a995687e1822aabb9b7d7ee8f11492 aka r186971 (affecting gcc.dg/cpp/pragma-diagnostic-2.c)

[PATCH, i386] Fix PR78478, Compile Error for i386-rtems

Hello! This patch (partially) reverts my change from 2013-11-05. Apparently, LONG_DOUBLE_TYPE_SIZE interferes with soft-float handling. 2017-01-19 Uros Bizjak PR target/78478 Revert: 2013-11-05 Uros Bizjak * config/i386/rtemself.h

[Bug target/78478] Compile Error for i386-rtems

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78478 --- Comment #23 from uros at gcc dot gnu.org --- Author: uros Date: Thu Jan 19 21:38:44 2017 New Revision: 244653 URL: https://gcc.gnu.org/viewcvs?rev=244653=gcc=rev Log: PR target/78478 Revert: 2013-11-05 Uros Bizjak

[Bug c++/79159] New: [7 regression] spurious array-bounds warning

++ Assignee: unassigned at gcc dot gnu.org Reporter: s...@li-snyder.org Target Milestone: --- hi - gcc version 7.0.0 20170119 gives what appears to be a spurious warning for this example when compiling with -O3 (tested on x86_64-pc-linux-gnu

[Bug target/79158] New: gcc.target/powerpc/pr70669.c fails on powerpc BE

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79158 Bug ID: 79158 Summary: gcc.target/powerpc/pr70669.c fails on powerpc BE Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component:

[Bug preprocessor/69543] [6/7 Regression] _Pragma does not apply within macro

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69543 --- Comment #9 from David Malcolm --- (In reply to David Malcolm from comment #8) > The following testcases still have xfails: > c-c++-common/pr69543-3.c > c-c++-common/pr69543-4.c > so this isn't quite fixed yet. These XFAILs are fixed

[Bug c++/61636] generic lambda: segfault / "cannot call member function without object"

Smith. > Nice. Your [much cleaner] patch sorts out the starred case above too. With GCC master (7.0.0 20170119) with your patch the results are: auto l0 = [&](auto z) { f (z); };// C:8 G:1 G':8 G'':8 auto l1 = [&](auto) { f (2.4); };// C:8 G:1 G':8 G'':1 * fixed :) auto l

[Bug fortran/79154] omp declare simd in pure function?

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79154 kargl at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 CC|

[Bug preprocessor/69543] [6/7 Regression] _Pragma does not apply within macro

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69543 --- Comment #8 from David Malcolm --- The following testcases still have xfails: c-c++-common/pr69543-3.c c-c++-common/pr69543-4.c so this isn't quite fixed yet.

Re: Pretty printers for versioned namespace

On 19/01/17 22:01 +0100, François Dumont wrote: On 10/01/2017 13:39, Jonathan Wakely wrote: I've committed the attached patch, which passes the tests for the default configuration and the versioned namespace configuration. I added another helper function, strip_versioned_namespace, which is

[Bug testsuite/63256] [5/6/7 regression] FAIL: gcc.dg/sms-8.c scan-rtl-dump-times sms "SMS succeeded" 0

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63256 --- Comment #10 from acsawdey at gcc dot gnu.org --- Looking at this again. Present state of play is: sms-4.c fails with -m64 BE and LE sms-8.c fails with -m32 BE

[Bug fortran/79157] New: gfortran crashed on sparc with openmpi build

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79157 Bug ID: 79157 Summary: gfortran crashed on sparc with openmpi build Product: gcc Version: 5.4.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component:

[Bug target/78478] Compile Error for i386-rtems

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78478 --- Comment #22 from uros at gcc dot gnu.org --- Author: uros Date: Thu Jan 19 21:00:53 2017 New Revision: 244651 URL: https://gcc.gnu.org/viewcvs?rev=244651=gcc=rev Log: PR target/78478 * config/ax_check_define.m4: New file.

Re: Pretty printers for versioned namespace

On 10/01/2017 13:39, Jonathan Wakely wrote: I've committed the attached patch, which passes the tests for the default configuration and the versioned namespace configuration. I added another helper function, strip_versioned_namespace, which is more expressive than doing

Re: [PATCH, configure, libgfortran]: PR78478: Use fpu-generic for x86 when _SOFT_FLOAT is defined

On Thu, Jan 19, 2017 at 10:43 PM, Uros Bizjak wrote: > Hello! > > Attached patch avoids bootstrap error when building libgfortran for > soft-float x86 targets. Configure detects when _SOFT_FLOAT is defined > and uses fpu-generic.h instead of fpu-387.h header. > > The patch

Re: [PATCH] C++: fix fix-it hints for misspellings within explicit namespaces (v2)

On Thu, 2017-01-19 at 13:15 -0500, Jason Merrill wrote: > On Wed, Jan 18, 2017 at 5:29 PM, David Malcolm > wrote: > > Here's a version of the patch which simply tweaks > > cp_parser_primary_expression's call to finish_id_expression so that > > it passes the location of the

[Bug libstdc++/79156] incorrect c++ usage in gcc7 void function returns a value

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79156 --- Comment #1 from Jonathan Wakely --- (In reply to mib.bugzilla from comment #0) > Changing "friend void" to "friend auto" would be a simple fix. That wouldn't compile in C++11 mode. I think shouldn't return anything.

[Bug libstdc++/79156] incorrect c++ usage in gcc7 void function returns a value

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79156 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|

[PATCH, configure, libgfortran]: PR78478: Use fpu-generic for x86 when _SOFT_FLOAT is defined

Hello! Attached patch avoids bootstrap error when building libgfortran for soft-float x86 targets. Configure detects when _SOFT_FLOAT is defined and uses fpu-generic.h instead of fpu-387.h header. The patch also imports ax_check_define.m4 from autoconf archive [1] - the macro is really handy,

Re: Multilib seems to fail for mingw-w64 build

Hi, Help from a build maintainer needed :) I am trying to find why mingw-w64 won’t build as a GCC cross-compiler with multilib (see full report below). It fails in building 32-bit libgcc, because we’re passing it the wrong flags. From toplevel configure, we have:

[Bug libstdc++/79156] New: incorrect c++ usage in gcc7 void function returns a value

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79156 Bug ID: 79156 Summary: incorrect c++ usage in gcc7 void function returns a value Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal

[Bug libstdc++/67085] priority queue should not copy comparators when calling push_heap and pop_heap

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67085 --- Comment #12 from Jonathan Wakely --- Author: redi Date: Thu Jan 19 20:29:07 2017 New Revision: 244650 URL: https://gcc.gnu.org/viewcvs?rev=244650=gcc=rev Log: Fix unsafe moves inside loops PR libstdc++/67085 *

[Bug libstdc++/78905] Add a macro to determine that the library is implemented

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78905 --- Comment #9 from Matt Clarkson --- (In reply to Jonathan Wakely from comment #7) > GCC 7 now defines _GLIBCXX_RELEASE (with the same value as __GNUC__ has, > i.e. the GCC major version, as an integer constant, but defined by the > library

Re: [PATCH] PR67085 move comparison functions in heap operations

On 19/01/17 18:50 +, Jonathan Wakely wrote: On 19/01/17 18:28 +, Jonathan Wakely wrote: @@ -397,7 +401,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION while (__last - __first > 1) { --__last; - std::__pop_heap(__first, __last, __last, __comp); +

[Bug target/79155] New: Typo in cpuid.h comment

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79155 Bug ID: 79155 Summary: Typo in cpuid.h comment Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee:

[Bug c/79082] -Wformat-truncation inconsistent behaviour

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79082 --- Comment #5 from Martin Sebor --- I see no warning at -O0 on snprintf (buffer, 4, "%03hx", val & 0xfff); or at -O2 on: snprintf (buffer, 3, "%2d", (val < 0) ? -(val % 100) : val % 100); (It does warn at -O0 as expected.) This is on

  1   2   3   >