https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71709
--- Comment #11 from Bill Schmidt ---
Working on the backports. Stay tuned.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69080
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68703
David Edelsohn changed:
What|Removed |Added
CC||dje at gcc dot gnu.org
--- Comment #8 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77756
--- Comment #2 from Yale Zhang ---
(In reply to Uroš Bizjak from comment #1)
> Created attachment 39711 [details]
> Patch that fixes __get_cpuid
>
> Can you please check if the attached patch fixes your problem?
Great, your patch works. Thanks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77467
--- Comment #4 from Jakub Jelinek ---
Author: jakub
Date: Wed Sep 28 19:21:47 2016
New Revision: 240591
URL: https://gcc.gnu.org/viewcvs?rev=240591&root=gcc&view=rev
Log:
PR c++/77467
* constexpr.c (enum constexpr_switch_state):
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77707
--- Comment #3 from Jerry DeLisle ---
Author: jvdelisle
Date: Wed Sep 28 19:38:03 2016
New Revision: 240592
URL: https://gcc.gnu.org/viewcvs?rev=240592&root=gcc&view=rev
Log:
2016-09-28 Jerry DeLisle
PR libgfortran/77707
io/t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77707
--- Comment #4 from Jerry DeLisle ---
Author: jvdelisle
Date: Wed Sep 28 19:43:03 2016
New Revision: 240593
URL: https://gcc.gnu.org/viewcvs?rev=240593&root=gcc&view=rev
Log:
2016-09-28 Jerry DeLisle
PR libgfortran/77707
* gf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77707
--- Comment #5 from Jerry DeLisle ---
Fixed on trunk. Will backport in a few days.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77786
Bug ID: 77786
Summary: internal compiler error: in tsubst_copy, at
cp/pt.c:13040
Product: gcc
Version: 5.4.1
Status: UNCONFIRMED
Severity: normal
Prio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77786
--- Comment #1 from Matthias Thul ---
Created attachment 39721
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39721&action=edit
preprocessed file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77721
--- Comment #2 from Martin Sebor ---
Author: msebor
Date: Wed Sep 28 19:51:08 2016
New Revision: 240595
URL: https://gcc.gnu.org/viewcvs?rev=240595&root=gcc&view=rev
Log:
PR middle-end/77721 - -Wformat-length not uses arg range for converted var
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77711
--- Comment #5 from Jonathan Wakely ---
For comparison, clang gives a much clearer error:
77711.cc:11:9: error: reference to non-static member function must be called;
did you mean to call it with no arguments?
x.f
~~^
()
I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77711
--- Comment #6 from Jonathan Wakely ---
Yet another variation on missing argument list for a member function call:
call.cc: In function ‘int main()’:
call.cc:20:14: error: cannot convert ‘A::foo’ from type ‘int (A::)()’ to type
‘int (A::*)()’
))
static const char x[] = "bar";
prn(x);
}
int main() {
foo();
bar();
}
Let's pretend that the x[] arrays were put there by ASSERT() macros.
Unfortunately, this won;t compile:
$ g++ -c 20160928-section_type_conflict.cpp
20160928-section_type_conf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77784
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77756
--- Comment #3 from Uroš Bizjak ---
(In reply to Yale Zhang from comment #2)
> But does level 13 really exist? I don't see any documentation for it.
Yes, apparently. It was added to driver-i386.c by Intel people, where:
if (max_level >= 13)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77683
Gerald Pfeifer changed:
What|Removed |Added
Status|RESOLVED|VERIFIED
--- Comment #5 from Gerald Pfe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77756
--- Comment #4 from uros at gcc dot gnu.org ---
Author: uros
Date: Wed Sep 28 21:29:47 2016
New Revision: 240597
URL: https://gcc.gnu.org/viewcvs?rev=240597&root=gcc&view=rev
Log:
PR target/77756
* config/i386/cpuid.h (__get_cpuid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71709
--- Comment #12 from Bill Schmidt ---
Author: wschmidt
Date: Wed Sep 28 21:35:37 2016
New Revision: 240598
URL: https://gcc.gnu.org/viewcvs?rev=240598&root=gcc&view=rev
Log:
2016-09-28 Bill Schmidt
Alan Modra
Backport f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71709
--- Comment #13 from Bill Schmidt ---
Author: wschmidt
Date: Wed Sep 28 21:36:59 2016
New Revision: 240599
URL: https://gcc.gnu.org/viewcvs?rev=240599&root=gcc&view=rev
Log:
2016-09-28 Bill Schmidt
Alan Modra
Backport f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77756
H.J. Lu changed:
What|Removed |Added
CC||hjl.tools at gmail dot com
--- Comment #5 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51242
--- Comment #29 from Jonathan Wakely ---
(In reply to Sasha B from comment #28)
> You can disregard whether the underlying type is fixed or not. So, GCC
> should not give a warning unless a bitfield containing Foo really is too
> small to hold a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61414
--- Comment #6 from Jonathan Wakely ---
(In reply to Xidorn Quan from comment #5)
> It seems G++ always throw that warning for enum class as bitfield, even when
> the enum class is actually empty:
> > enum class K {};
> > struct S {
> > K v : 5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61414
Jonathan Wakely changed:
What|Removed |Added
Keywords||diagnostic
Status|UNCONFIR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70754
--- Comment #5 from Pat Haugen ---
(In reply to Pat Haugen from comment #4)
> This also occurs on powerpc64/powerpc64le.
>
I should note that the failure on powerpc64* doesn't start until GCC 7 rev
236043, where a TARGET_SCHED_REASSOCIATION_WID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77694
--- Comment #7 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Wed Sep 28 23:38:13 2016
New Revision: 240604
URL: https://gcc.gnu.org/viewcvs?rev=240604&root=gcc&view=rev
Log:
2016-09-28 Steven G. Kargl
backport from trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77787
--- Comment #1 from petschy at gmail dot com ---
That last function in json.hpp was gutted:
//template
int foo(int div_)
{
ASSERT(div_ == 0);
return 0;
}
Removed the assertions from all the template functions, as this moved the c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77612
--- Comment #4 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Thu Sep 29 00:18:44 2016
New Revision: 240608
URL: https://gcc.gnu.org/viewcvs?rev=240608&root=gcc&view=rev
Log:
2016-09-28 Steven G. Kargl
backport from trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71730
--- Comment #5 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Thu Sep 29 00:18:44 2016
New Revision: 240608
URL: https://gcc.gnu.org/viewcvs?rev=240608&root=gcc&view=rev
Log:
2016-09-28 Steven G. Kargl
backport from trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77788
Bug ID: 77788
Summary: profiledbootstrap failures on powerpc64le
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77789
Bug ID: 77789
Summary: MinGW option ./configure does not make
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
cc version 7.0.0 20160928 (experimental) [trunk revision 240585] (GCC)
$
$ g++-trunk -c -std=c++14 small.cpp
$
$ g++-trunk -c -std=c++11 small.cpp
small.cpp:3:42: error: ‘f’ function uses ‘auto’ type specifier without trailing
return type
template < typename T > static auto
-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 7.0.0 20160928 (experimental) [trunk revision 240585] (GCC)
$
$ g++-trunk -std=c++11 -c small.cpp
small.cpp:1:29: error: redefinition of ‘int i’
auto a = [] (int i, int i = 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=0
--- Comment #4 from Zoltan Kocsi ---
Tested several gcc versions.
Up to and including 4.8.5 everything seems to be OK, but 4.9.0 or above all
throw the error.
101 - 134 of 134 matches
Mail list logo
