ble-languages=c,c++,objc,obj-c++,fortran,lto --disable-werror
--with-gmp=/usr/local/gcc-trunk --with-mpfr=/usr/local/gcc-trunk
--with-mpc=/usr/local/gcc-trunk --with-cloog=/usr/local/gcc-trunk
--prefix=/usr/local/gcc-trunk
Thread model: posix
gcc version 6.0.0 20150731 (experimental) [trunk revision 226431] (GCC)
$:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67067
--- Comment #4 from Alex Lai ---
(In reply to Alex Lai from comment #1)
> on Solaris x86, I downloaded MPC, GMP and MPFR and extracted them into GCC
> source directory as mpc,gmp and mpfr directories and configure GCC source
> with:
>
> $ ../gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67087
Bug ID: 67087
Summary: FAIL: gcc.dg/cpp/_Pragma3.c (test for excess errors) -
file timestamp issue
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: norma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67034
--- Comment #3 from Alexandre Oliva ---
In case you haven't yet, don't bother. The fix is faulty; at least on ppc64le,
the copying doesn't work because it sets up the pseudo with the address of the
object only after the copying is done. I've go
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67082
--- Comment #2 from dave.anglin at bell dot net ---
On 2015-07-31, at 8:39 PM, redi at gcc dot gnu.org wrote:
> Is this a new failure? Nothing in this area has changed in libstdc++.
It is present on both 32 and 64-bit hpux, but not linux. r2252
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67085
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67082
--- Comment #1 from Jonathan Wakely ---
Is this a new failure? Nothing in this area has changed in libstdc++.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67080
--- Comment #1 from Jonathan Wakely ---
Almost certainly a duplicate of one of the bugs linked from PR 59002
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67061
--- Comment #4 from Oleg Endo ---
(In reply to Kazumoto Kojima from comment #2)
>
> where reg is r2 and curr_insn is the insn 31. sh_find_set_of_reg is
> stepping backward from the insn 31 but the call_insn 29 is missed.
>
> Does the patch bel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67049
Kazumoto Kojima changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67015
Alex Turbov changed:
What|Removed |Added
CC||i.zaufi at gmail dot com
--- Comment #10 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67049
--- Comment #4 from Kazumoto Kojima ---
Author: kkojima
Date: Fri Jul 31 22:25:57 2015
New Revision: 226458
URL: https://gcc.gnu.org/viewcvs?rev=226458&root=gcc&view=rev
Log:
PR target/67049
* config/sh/sh.md (GOTaddr2picreg): Fix typo added wit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67049
--- Comment #3 from Kazumoto Kojima ---
Author: kkojima
Date: Fri Jul 31 22:19:51 2015
New Revision: 226457
URL: https://gcc.gnu.org/viewcvs?rev=226457&root=gcc&view=rev
Log:
PR target/67049
* config/sh/sh.md (GOTaddr2picreg): Fix typo added wit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66842
--- Comment #6 from Bin Fan ---
(In reply to Richard Henderson from comment #5)
> When libatomic was first written, it wasn't clear what the restrictions
> from the various languages would be, nor even if that was the best of
> ideas -- things th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66752
--- Comment #16 from Jeffrey A. Law ---
Just a status update. This patch causes the stage1 compiler to mis-compile
tree-ssa-live, which in turn causes the stage2 compiler to incorrectly issue an
error when building the stage3 compiler on ppc64.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67064
--- Comment #16 from Jens Maurer ---
(In reply to Jason Merrill from comment #14)
> '-Wpedantic' does not cause warning messages for use of the
> alternate keywords whose names begin and end with '__'. Pedantic
> warnings are also
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67086
Bug ID: 67086
Summary: When building ghdl-0.32 the error "RE_Not_Available
rtsfind.adb:296" is reported.
Product: gcc
Version: 5.2.0
Status: UNCONFIRMED
Severit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67070
--- Comment #5 from Jason Merrill ---
(In reply to Casey Carter from comment #3)
> Although not intuitive, this behavior is sane. It's what we're accustomed to
> when overloading functions constrained with enable_if::value> and
> enable_if::value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67085
Andrew Calcutt changed:
What|Removed |Added
Severity|normal |enhancement
--- Comment #1 from Andrew
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67085
Bug ID: 67085
Summary: priority queue should not copy comparators when
calling push_heap and pop_heap
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67070
--- Comment #4 from W E Brown ---
(In reply to Andrew Sutton from comment #2)
> If we had a rule that allowed the evaluation of a concept in any
> context, then we could avoid doing this. It would also guarantee the
> ability to write;
>
>s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67070
--- Comment #3 from Casey Carter ---
Although not intuitive, this behavior is sane. It's what we're accustomed to
when overloading functions constrained with enable_if::value> and
enable_if::value>; substitution failure of foo disables *both*
ove
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67070
--- Comment #2 from Andrew Sutton ---
> This is a very subtle point. It seems to me that it would be better if
> creating the normal form of a constaint stops substituting into concept bodies
> once it's clear that we're inside an atomic constra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67070
Jason Merrill changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67084
Bug ID: 67084
Summary: [c++-concepts] Matching of variable template
declarations ignores constraints
Product: gcc
Version: c++-concepts
Status: UNCONFIRMED
Seve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65501
Yaakov Selkowitz changed:
What|Removed |Added
CC||yselkowi at redhat dot com
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67083
Bug ID: 67083
Summary: arm-eabi libstdc++ multilibs built in wrong place
Product: gcc
Version: 5.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67082
Bug ID: 67082
Summary: FAIL: tr1/8_c_compatibility/complex/functions.cc (test
for excess errors)
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67081
Bug ID: 67081
Summary: FAIL: g++.dg/cpp0x/nsdmi-template14.C (test for
errors)
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66858
John David Anglin changed:
What|Removed |Added
Target|aarch64-none-elf, |aarch64-none-elf,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67080
Bug ID: 67080
Summary: Access to private using declaration incorrectly
allowed
Product: gcc
Version: 5.2.0
Status: UNCONFIRMED
Severity: normal
Priori
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67061
--- Comment #3 from Yaakov Selkowitz ---
(In reply to Kazumoto Kojima from comment #2)
> Does the patch below work?
Yes, this patch in combination of that from bug 67049 allows me to complete the
sh64-elf toolchain and does not break the sh-elf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66521
--- Comment #9 from Eric Gallager ---
Created attachment 36101
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36101&action=edit
additional patch to fix this issue
As a follow-up to my previous comment, the attached patch fixes the issue
de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67064
--- Comment #15 from Daniel Gutson ---
(In reply to Jason Merrill from comment #14)
> (In reply to Ville Voutilainen from comment #13)
> > It is correct that currently none of the pedantic-flags diagnose the use of
> > this extension; perhaps tha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67069
--- Comment #2 from Alex Lai ---
(In reply to Andrew Pinski from comment #1)
> Don't use:
> "CFLAGS=-m64" "CXXFLAGS=-m64" "LDFLAGS=-m64"
>
> Instead set CC/CXX to include -m64 instead.
> Also you might need to default GCC to 64bit too.
Setting
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67079
Bug ID: 67079
Summary: Webpages and manual still claim that C++11 support is
experimental
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66332
--- Comment #5 from Thomas Schwinge ---
Author: tschwinge
Date: Fri Jul 31 14:13:59 2015
New Revision: 226444
URL: https://gcc.gnu.org/viewcvs?rev=226444&root=gcc&view=rev
Log:
[PR libgomp/65742, PR middle-end/66332] libgomp: Remove plugin for n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66870
--- Comment #16 from Alan Modra ---
Author: amodra
Date: Fri Jul 31 14:05:42 2015
New Revision: 226443
URL: https://gcc.gnu.org/viewcvs?rev=226443&root=gcc&view=rev
Log:
PR target/66870
* config/rs6000/rs6000.c (machine_function)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67078
Bug ID: 67078
Summary: [6 Regression] FAIL: 24_iterators/container_access.cc
(test for excess errors) on aarch64-none-elf
Product: gcc
Version: 6.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66691
--- Comment #10 from Vladimir Makarov ---
Author: vmakarov
Date: Fri Jul 31 13:52:09 2015
New Revision: 226442
URL: https://gcc.gnu.org/viewcvs?rev=226442&root=gcc&view=rev
Log:
2015-07-31 Vladimir Makarov
PR debug/66691
* lr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66917
--- Comment #18 from ktkachov at gcc dot gnu.org ---
(In reply to ktkachov from comment #17)
> (In reply to Richard Biener from comment #16)
> > Created attachment 36099 [details]
> > patch
> >
> > I am testing the attached (on x86_64-linux), it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67077
Bug ID: 67077
Summary: [6 Regression] Incorrect "array subscript is above
array bounds" warning with -O2
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67075
--- Comment #3 from Richard Biener ---
I think nowadays we just have a lot more ggc_collect calls.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67076
Bug ID: 67076
Summary: Critical inside a module procedure
Product: gcc
Version: 5.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66977
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66977
--- Comment #4 from Marek Polacek ---
Author: mpolacek
Date: Fri Jul 31 11:12:57 2015
New Revision: 226440
URL: https://gcc.gnu.org/viewcvs?rev=226440&root=gcc&view=rev
Log:
PR sanitizer/66977
* typeck.c (get_member_function_from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67075
--- Comment #2 from Andrew Pinski ---
Sounds more like ggc_collect is now always doing the gc and there are a lot of
ggc_collect calls.
So what is happening we are close to your 32M limit you set, so any garbage
that is produced in a pass will
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67075
--- Comment #1 from Luke Dashjr ---
Also note: ggc-min-expand=1 seems to successfully workaround this issue (but is
non-ideal for low-memory systems).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67075
Bug ID: 67075
Summary: Infinite GC loop with ggc-min-expand=0
Product: gcc
Version: 4.8.4
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66917
--- Comment #17 from ktkachov at gcc dot gnu.org ---
(In reply to Richard Biener from comment #16)
> Created attachment 36099 [details]
> patch
>
> I am testing the attached (on x86_64-linux), it fixes the testcase with a
> cross to arm. Full te
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66917
--- Comment #16 from Richard Biener ---
Created attachment 36099
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36099&action=edit
patch
I am testing the attached (on x86_64-linux), it fixes the testcase with a cross
to arm. Full testing o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67074
Jonathan Wakely changed:
What|Removed |Added
Keywords||rejects-valid
Status|UNCON
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66790
--- Comment #9 from Pierre-Marie de Rodat ---
Created attachment 36098
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36098&action=edit
Updated candidate patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66790
--- Comment #8 from Pierre-Marie de Rodat ---
(In reply to Richard Biener from comment #7)
> It would be certainly good to see why we have this UNDEF in the first place.
Sure: here is a C translation of what happens in my Ada reproducer (only wr
54 matches
Mail list logo
