https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82790
Bug ID: 82790
Summary: [GCC 5, 6, 7] -Wuseless-cast doesn't detect
unnecessary removal of const
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82737
--- Comment #14 from Matti Bryce ---
(In reply to Martin Liška from comment #12)
> (In reply to Matti Bryce from comment #7)
> > (In reply to Martin Liška from comment #5)
> > > Confirmed with cross compiler, I reduce a test-case.
> >
> > I've
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79696
Eric Gallager changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|2017-07-31
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82590
--- Comment #1 from bastl ---
Compiling gcc-7.2.0 with gcc-7.2.0
works fine.
What I did on this error and the other errors followed:
comment out the definitions cousing the errors like:
1.)
gcc/system.h:496:14: error: ambiguating new
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82002
--- Comment #9 from dansan at gcc dot gnu.org ---
Author: dansan
Date: Tue Oct 31 21:48:55 2017
New Revision: 254284
URL: https://gcc.gnu.org/viewcvs?rev=254284=gcc=rev
Log:
PR target/82002 Part 1: Correct ICE caused by wrong calculation
gcc:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81702
Martin Jambor changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81702
--- Comment #9 from Martin Jambor ---
Author: jamborm
Date: Tue Oct 31 21:36:51 2017
New Revision: 254283
URL: https://gcc.gnu.org/viewcvs?rev=254283=gcc=rev
Log:
[PR 81702] Remove devirtualization assert
2017-10-31 Martin Jambor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82635
--- Comment #12 from Andreas Tobler ---
Will soon commit a fix, for gcc6/7/8 on FreeBSD > 9.3. Older gcc's and OS
releases will not be supported by this fix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82333
--- Comment #1 from Michael Meissner ---
This occurs because both fld and ff128 return the same constant (0), one using
it as a long double and the other as a _Float128. Having a 0 constant is not
important. If we return 1 in both functions,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82789
--- Comment #1 from Alexander Nazarenko ---
(In reply to Alexander Nazarenko from comment #0)
Minor correction:
In code must be:
template
A l_and_r( A const l, A const r )
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82789
Bug ID: 82789
Summary: Invalid code generated for std::array element-wise
processing with -O3
Product: gcc
Version: lto
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70129
--- Comment #5 from chuck cranor ---
I don't think anyone would manually add "-isystem /usr/include" ...
but build systems that provide variables for third party headers that
may or may not be installed in /usr/include often trigger this.
e.g.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82788
Bug ID: 82788
Summary: wrong code with -fstack-clash-protection
--param=stack-clash-protection-probe-interval=10 on
simple code
Product: gcc
Version: 8.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82658
--- Comment #2 from mike.k at digitalcarbide dot com ---
I wanted to validate if this issue was presenting in the toolchains for other
architectures, so I tested a bit:
GCC 7.2.0 on x86-64 (-O3):
C:
movzx eax, BYTE PTR [rsp-1]
shr al
mov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70129
--- Comment #4 from Jonathan Wakely ---
Why do you need to use either option? /usr/include is already a system include
dir, so -isystem /usr/include serves no useful purpose.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70129
chuck cranor changed:
What|Removed |Added
CC||chuck at ece dot cmu.edu
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81803
--- Comment #19 from Eric Botcazou ---
Author: ebotcazou
Date: Tue Oct 31 18:27:52 2017
New Revision: 254275
URL: https://gcc.gnu.org/viewcvs?rev=254275=gcc=rev
Log:
PR rtl-optimization/81803
* lra-constraints.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68192
--- Comment #7 from Brian Groose ---
It turns out I was using binutils' nm when building gcc. I rebuilt gcc making
sure that only the AIX nm was available, and ld can now find the symbols.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82787
Bug ID: 82787
Summary: gnu gcc (4.8 - 7.1) cannot parse some system headers
in macOS (10.13)
Product: gcc
Version: 7.1.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82785
Eric Botcazou changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82785
--- Comment #3 from Eric Botcazou ---
Author: ebotcazou
Date: Tue Oct 31 17:29:26 2017
New Revision: 254274
URL: https://gcc.gnu.org/viewcvs?rev=254274=gcc=rev
Log:
PR ada/82785
* gcc-interface/Makefile.in (m68k/Linux): Fix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82247
--- Comment #5 from Joël Lamotte ---
I'll have to recheck when I have access to a proper computer, but that indeed
would explain this(weird) behavior.
My understanding was that for basic types, ADL would still work using global
namespace, which
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64234
Yury Gribov changed:
What|Removed |Added
CC||ygribov at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82785
--- Comment #2 from John Paul Adrian Glaubitz ---
Thanks Matthias for reporting the issue and thanks Eric for working on it!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82785
Eric Botcazou changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78829
--- Comment #4 from joseph at codesourcery dot com ---
_Alignof is alignment requirement (in all contexts), __alignof__ is
preferred alignment (so on 32-bit x86, for long long they are 4 and 8
respectively, because a long long in a structure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82777
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82786
Bug ID: 82786
Summary: aarch64 frame patch caused a number of target specific
test failures.
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Component: ada
Assignee: unassigned at gcc dot gnu.org
Reporter: doko at gcc dot gnu.org
Target Milestone: ---
seen with trunk 20171031:
a-dispat.adb:33:06: "System.Linux" is not a predefined library unit
a-dispat.adb:33:06: "Ada.Dispatching (body)" depends on &
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82754
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82784
--- Comment #4 from Tom de Vries ---
Created attachment 42506
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42506=edit
More minimal asan.c patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82784
--- Comment #3 from Tom de Vries ---
Created attachment 42505
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42505=edit
asan.c patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82247
Casey Carter changed:
What|Removed |Added
CC||Casey at Carter dot net
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82702
--- Comment #8 from Martin Liška ---
> We are not using directly lcov, but a replacement we rewrote in Rust.
> We can easily support reading from multiple gcov files instead of one
> (actually, we already support it when llvm is used, since it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82784
--- Comment #2 from Jonathan Wakely ---
So the way it's used is correct ... but why bother with the do {...} while(0)
in that case? It could just use {...} instead.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82614
--- Comment #9 from Martin Liška ---
(In reply to Marco Castelluccio from comment #8)
> Created attachment 42462 [details]
> Archive with GCNO and GCDA file generated with GCC 6
>
> This is an archive containing the GCNO and GCDA files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82784
--- Comment #1 from Andrew Pinski ---
Some of these makes sense.
gcc/asan.c makes sense:
#define DEF_SANITIZER_BUILTIN(ENUM, NAME, TYPE, ATTRS) \
do { \
decl =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82085
--- Comment #13 from Paolo Carlini ---
Thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82784
Bug ID: 82784
Summary: Remove semicolon after "do {} while (0)" macros
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82771
--- Comment #1 from visit0r at gcc dot gnu.org ---
Author: visit0r
Date: Tue Oct 31 13:00:53 2017
New Revision: 254265
URL: https://gcc.gnu.org/viewcvs?rev=254265=gcc=rev
Log:
[BRIGFE] Fix PR 82771.
Modified:
trunk/gcc/brig/ChangeLog
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82769
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81570
H.J. Lu changed:
What|Removed |Added
CC||andrey.y.guskov at intel dot
com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82781
Marc Glisse changed:
What|Removed |Added
Known to work||5.4.0
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81716
--- Comment #2 from sgunderson at bigfoot dot com ---
Still there in:
gcc version 8.0.0 20171017 (experimental) [trunk revision 253812] (Debian
20171017-1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82781
Marc Glisse changed:
What|Removed |Added
Keywords||wrong-code
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82737
--- Comment #13 from Jonathan Wakely ---
(In reply to Matti Bryce from comment #0)
> My .i file is (far) too big to be uploaded directly
Not if you compress it with zip, gzip, bzip2 or something similar.
(In reply to Matti Bryce from comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82776
--- Comment #7 from amker at gcc dot gnu.org ---
Testing a patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82633
Martin Liška changed:
What|Removed |Added
Known to work||8.0
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82633
--- Comment #10 from Martin Liška ---
Author: marxin
Date: Tue Oct 31 11:55:19 2017
New Revision: 254257
URL: https://gcc.gnu.org/viewcvs?rev=254257=gcc=rev
Log:
GCOV: document behavior of -fkeep-{static,inline}-functions (PR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82783
Bug ID: 82783
Summary: gfotran ICEs when compiling polymorphic function call
Product: gcc
Version: 7.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82694
--- Comment #10 from amker at gcc dot gnu.org ---
(In reply to amker from comment #9)
> (In reply to Markus Trippelsdorf from comment #8)
> > I think -fno-strict-overflow/-fwrapv should use the old behavior.
> > The kernel really needs a flag to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82694
--- Comment #9 from amker at gcc dot gnu.org ---
(In reply to Markus Trippelsdorf from comment #8)
> I think -fno-strict-overflow/-fwrapv should use the old behavior.
> The kernel really needs a flag to control pointer wrapping.
Well, GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82694
--- Comment #8 from Markus Trippelsdorf ---
I think -fno-strict-overflow/-fwrapv should use the old behavior.
The kernel really needs a flag to control pointer wrapping.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82776
--- Comment #6 from amker at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #5)
> (In reply to amker from comment #4)
> > Well, one decision needs to be made is whether such bound information should
> > be covered by
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82776
--- Comment #5 from Jakub Jelinek ---
(In reply to amker from comment #4)
> Well, one decision needs to be made is whether such bound information should
> be covered by -faggressive-loop-optimizations. We already did this for
> undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82772
Uroš Bizjak changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82737
--- Comment #12 from Martin Liška ---
(In reply to Matti Bryce from comment #7)
> (In reply to Martin Liška from comment #5)
> > Confirmed with cross compiler, I reduce a test-case.
>
> I've attempted to reduce a test case, but after 2 days of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82776
--- Comment #4 from amker at gcc dot gnu.org ---
Well, one decision needs to be made is whether such bound information should be
covered by -faggressive-loop-optimizations. We already did this for undefined
behavior of sign type and array bound.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82772
--- Comment #8 from uros at gcc dot gnu.org ---
Author: uros
Date: Tue Oct 31 10:36:33 2017
New Revision: 254255
URL: https://gcc.gnu.org/viewcvs?rev=254255=gcc=rev
Log:
PR target/82772
* config/alpha/sync.md (fetchop_constr) :
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82782
Bug ID: 82782
Summary: ICE: nested template alias and specialized template
with auto template parameter
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82737
--- Comment #11 from Martin Liška ---
Created attachment 42503
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42503=edit
Slightly reduced test-case
With following test-case, I see ICE with following cross-compiler:
../configure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82085
--- Comment #12 from Roland B ---
Done, reported as bug 82782. Thanks for your help!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82772
--- Comment #7 from uros at gcc dot gnu.org ---
Author: uros
Date: Tue Oct 31 10:34:55 2017
New Revision: 254254
URL: https://gcc.gnu.org/viewcvs?rev=254254=gcc=rev
Log:
PR target/82772
* config/alpha/sync.md (fetchop_constr) :
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82772
--- Comment #6 from uros at gcc dot gnu.org ---
Author: uros
Date: Tue Oct 31 10:33:12 2017
New Revision: 254253
URL: https://gcc.gnu.org/viewcvs?rev=254253=gcc=rev
Log:
PR target/82772
* config/alpha/sync.md (fetchop_constr) :
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82641
Tamar Christina changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82776
amker at gcc dot gnu.org changed:
What|Removed |Added
CC||amker at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78829
--- Comment #3 from Jonathan Wakely ---
https://gcc.gnu.org/onlinedocs/gcc/Alignment.html should discuss the
relationship between GCC's __alignof__ and C11's _Alignof. Are they identical?
Should _Alignof be preferred when using C11? It could
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82772
--- Comment #5 from Uroš Bizjak ---
(In reply to Joël Krähemann from comment #4)
> Hi,
> Yesterday I was trying to set up an alpha VM. Since I didn't build it I
> don't have access to the preprocessed source.
>
> As doing a qemu image with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82641
Ramana Radhakrishnan changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82674
--- Comment #8 from Segher Boessenkool ---
Author: segher
Date: Tue Oct 31 09:49:40 2017
New Revision: 254252
URL: https://gcc.gnu.org/viewcvs?rev=254252=gcc=rev
Log:
Subject: [PATCH] rs6000: Fix crash with big stack clash interval (PR82674)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82781
Bug ID: 82781
Summary: Vector extension operators return wrong result in
constexpr
Product: gcc
Version: 7.1.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82780
--- Comment #1 from sgunderson at bigfoot dot com ---
Here's a version that's valid C++:
class a {
};
template class c { c(c &) : a(static_cast
(e.d)) {} a d; };
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82360
Markus Trippelsdorf changed:
What|Removed |Added
CC||sgunderson at bigfoot dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82780
Markus Trippelsdorf changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82780
Bug ID: 82780
Summary: [8 Regression] ICE on compiling Boost
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82085
--- Comment #11 from Paolo Carlini ---
Just to clarify why I think a separate bug report is more appropriate: if I
revert the small change I committed for this bug, the new testcase does *not*
trigger the ICE fixed here.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82085
--- Comment #10 from Paolo Carlini ---
Yes, please, open a new bug, it's a different issue.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82567
--- Comment #7 from Chinoune ---
Fixed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82772
--- Comment #4 from Joël Krähemann ---
Hi,
Yesterday I was trying to set up an alpha VM. Since I didn't build it I don't
have access to the preprocessed source.
As doing a qemu image with debian there were some problems with the kernel. The
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82567
Chinoune changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82670
Markus Trippelsdorf changed:
What|Removed |Added
CC||trippels at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82779
Markus Trippelsdorf changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82778
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
CC||collison at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82085
--- Comment #9 from Roland B ---
Here is the new minimal example (please let me know if this should go into a
new bug report):
// -
template
struct make_char_sequence;
template
struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82779
Bug ID: 82779
Summary: [8 regression] On ppc64le bootstrap-ubsan causes "gcc
-dumpspecs" segfault
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82778
--- Comment #2 from Jakub Jelinek ---
Created attachment 42502
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42502=edit
gcc8-pr82778.patch
The following untested patch ought to fix it.
recog_memoized doesn't handle the important part
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82085
--- Comment #8 from Roland B ---
(In reply to Paolo Carlini from comment #7)
> Fixed trunk and 7.3.0 so far.
Awesome!
Sadly, my "real" code still produces an internal compile error. I will try to
create a new minimal example.
Until then, you
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82002
--- Comment #8 from Uroš Bizjak ---
*** Bug 82485 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82485
Uroš Bizjak changed:
What|Removed |Added
Status|NEW |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82002
--- Comment #7 from Uroš Bizjak ---
*** Bug 82712 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82712
Uroš Bizjak changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82778
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82776
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82776
--- Comment #1 from Marc Glisse ---
That could be because gcc sadly refuses to optimize away infinite loops
(happens for other cases, and cddce2 dump (the pass that removes the whole
thing when the macro is defined) says "can not prove
94 matches
Mail list logo
