https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66345
Marek Polacek changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56926
--- Comment #15 from asmwarrior ---
I think the bug has already reported more than ten years ago, see:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14940
There are many fixes in various hosts, but not included the windows hosts. As
Kai suggest i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14940
asmwarrior changed:
What|Removed |Added
CC||asmwarrior at gmail dot com
--- Comment #46
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66350
Bug ID: 66350
Summary: typename should be forbidden in inhering constructors
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Comp
Configured with: ../gcc-trunk/configure --prefix=/usr/local/gcc-trunk
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 6.0.0 20150530 (experimental) [trunk revision 223885] (GCC)
$
$ gcc-trunk -O0 -c small.c
$ gcc-trunk -Os -c small.c
$ gcc-5.1 -O1 -c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66345
H.J. Lu changed:
What|Removed |Added
CC||rguenther at suse dot de
Target Milestone|--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66348
--- Comment #3 from Sebastiano Vigna ---
As an additional information: we printed b->num_lines - 1 - n just before the
loop, and everything is fine--we get there with the current value both with -O0
and -O1. But we -O1 we never exit the loop.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66348
--- Comment #2 from Sebastiano Vigna ---
Er... it's perfectly possible. My knowledge of x64 assembly is rudimentary, but
I wanted to try a diagnosis.
What is definitely true is that at -O0 we enter and exit the loop as it should
happen, and at -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66348
--- Comment #1 from Andrew Pinski ---
I suspect there is an alias violation here rather what is described.
In x86_64, almost all of the instructions which act on 32bit half of the
registers will zero extend. That includes xorl.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66348
Bug ID: 66348
Summary: Simple loop with 64-bit index has only lower half
initialized correctly
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66346
Ruslan changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66346
--- Comment #2 from Jonathan Wakely ---
(In reply to Ruslan from comment #0)
> #include
> int main()
> {
> volatile long double two=2.L;
> long double vol=log10(two);
> long double con=log10(2.L);
These do not calculate the result a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66346
Marc Glisse changed:
What|Removed |Added
Component|c++ |libstdc++
--- Comment #1 from Marc Glisse
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66347
Bug ID: 66347
Summary: Seg fault (ICE) on compile
Product: gcc
Version: 5.1.1
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: fortran
Assig
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66346
Bug ID: 66346
Summary: GCC computes log10(2.L) constant wrongly
Product: gcc
Version: 5.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66319
--- Comment #3 from John David Anglin ---
_HPUX_SOURCE is predefined for c++. This results in
_INCLUDE_XOPEN_SOURCE_EXTENDED being defined but _XOPEN_SOURCE_EXTENDED
is not predefined (see hunk in comment #1). This behavior dates back
to this p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66345
Markus Trippelsdorf changed:
What|Removed |Added
Status|WAITING |NEW
Component|c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66345
--- Comment #3 from Brian Graham ---
Created attachment 35655
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35655&action=edit
Preprocessed file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66345
Markus Trippelsdorf changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66345
--- Comment #1 from Brian Graham ---
Created attachment 35654
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35654&action=edit
Truncated build output.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66345
Bug ID: 66345
Summary: internal compiler error: Segmentation fault --
raidctl.c 'do_meter'
Product: gcc
Version: 5.1.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66342
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66341
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52595
Jonathan Wakely changed:
What|Removed |Added
CC||barry.revzin at gmail dot com
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66344
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66344
Bug ID: 66344
Summary: non-static data member initializer in class template
fails to compile
Product: gcc
Version: 5.1.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #38 from Oleg Endo ---
(In reply to Rich Felker from comment #33)
> The commit in comment 16 broke Linux (the kernel) and nobody seems to have
> noticed since 2012...
There aren't that many (publicly known) users of Linux on SH2 or S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #37 from Rich Felker ---
I expect this is going to be problematic from a license perspective unless they
can be licensed under GPLv2...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #36 from Oleg Endo ---
(In reply to Rich Felker from comment #35)
> No, but the cause is simple -- the kernel doesn't use libgcc but defines its
> own versions of these functions, and has the old ones but not the new ones.
Yeah, that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #35 from Rich Felker ---
No, but the cause is simple -- the kernel doesn't use libgcc but defines its
own versions of these functions, and has the old ones but not the new ones. I
tried just removing the kernel's copies and using libg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66319
Eric Botcazou changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66342
--- Comment #3 from Mikhail Maltsev ---
Probably a typo. It should be:
diff --git a/gcc/testsuite/gcc.dg/alias-8.c b/gcc/testsuite/gcc.dg/alias-8.c
index b99873e..4c95c55 100644
--- a/gcc/testsuite/gcc.dg/alias-8.c
+++ b/gcc/testsuite/gcc.dg/ali
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #34 from Oleg Endo ---
Thanks for spotting and pin pointing. Do you have a bit more info, maybe a
reduced test case?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
Rich Felker changed:
What|Removed |Added
CC||bugdal at aerifal dot cx
--- Comment #33 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66342
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66343
Bug ID: 66343
Summary: "Error: .Lubsan_type3 already defined" with UBSan and
precompiled headers
Product: gcc
Version: 5.1.0
Status: UNCONFIRMED
Severity: norma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66342
Mikhail Maltsev changed:
What|Removed |Added
Target|aarch64-*-* |aarch64-*-*,
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66338
--- Comment #4 from Jonathan Wakely ---
(In reply to Pawel Tomulik from comment #2)
> Anyway, adding explicit to S(T&&) solves the problem...
Or constrain your greedy template so it only accepts arguments that can be
assigned to S::i_
struct S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66338
--- Comment #3 from Jonathan Wakely ---
I think this is expected, because your type S has an unconstrained constructor
template that accepts any argument, including objects of type tuple, but in
the signature of that constructor (specifically in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66342
Bug ID: 66342
Summary: [6 regression] FAIL: g++.dg/ipa/ipa-icf-4.C
-std=gnu++11 scan-ipa-dump icf "Equal symbols: [67]"
Product: gcc
Version: 6.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66341
Bug ID: 66341
Summary: Some casts wrongly produce a lvalue
Product: gcc
Version: 5.1.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c
As
41 matches
Mail list logo
