https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88487
--- Comment #5 from rguenther at suse dot de ---
On Fri, 14 Dec 2018, bugzi...@poradnik-webmastera.com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88487
>
> --- Comment #4 from Daniel Fruzynski ---
> OK, I see. Is there any workaroun
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88490
--- Comment #6 from rguenther at suse dot de ---
On Fri, 14 Dec 2018, joseph at codesourcery dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88490
>
> --- Comment #5 from joseph at codesourcery dot com dot com> ---
> On Fri, 14 D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88497
Richard Biener changed:
What|Removed |Added
Target||powerpc*
Component|middle-end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78394
--- Comment #9 from Allan Jensen ---
I see two other level effort ways to possibly fix the issue. Disable the
warning like for -O0 as it is buggy, or if we believe it still has some value
in -Og even with the false positivies, just removing it fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88529
Bug ID: 88529
Summary: G++ clears the return register on x86_64 when
returning an empty class
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78394
--- Comment #10 from Marc Glisse ---
IMO -Wmaybe-uninitialized should not be enabled by -Wall, whatever the
optimization level (even at -O3), it has too many false positives that are all
but impossible to work around (thus violating the definitio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88517
Richard Biener changed:
What|Removed |Added
Keywords||wrong-code
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88518
Richard Biener changed:
What|Removed |Added
Severity|normal |enhancement
--- Comment #3 from Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88519
Richard Biener changed:
What|Removed |Added
Target||x86_64-*-*, i?86-*-*
Component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88521
--- Comment #2 from Richard Biener ---
Since the patch changes the ABI can it be you have library dependences with the
old ABI around?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88528
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88464
--- Comment #16 from Moritz Kreutzer ---
I can confirm the fix from my side.
Thanks again!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88175
--- Comment #14 from Jonny Grant ---
Wondering, if there is an implicitly created copy-constructor, can the warning
clarify that? Perhaps there is some attribute or flag set so later code can
know it was implicitly created?
eg output could be:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81665
Harald van Dijk changed:
What|Removed |Added
CC||harald at gigawatt dot nl
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88253
--- Comment #5 from Senthil Kumar Selvaraj ---
Author: saaadhu
Date: Mon Dec 17 10:50:54 2018
New Revision: 267198
URL: https://gcc.gnu.org/viewcvs?rev=267198&root=gcc&view=rev
Log:
Fix PR 88253
gcc/ChangeLog:
PR rtl-optimization/88253
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88530
Bug ID: 88530
Summary: [8/9 Regression] AArch64 Unsupported options passed to
assemblers when it doesn't need to.
Product: gcc
Version: 8.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88530
Tamar Christina changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88501
--- Comment #4 from Jonathan Wakely ---
(In reply to Jonny Grant from comment #3)
> I wonder, for typos if a simple byte compare would be enough? Vary each char
> by 1 letter, or length. This starts to get complicated I know..
The matching code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88253
--- Comment #6 from Senthil Kumar Selvaraj ---
Author: saaadhu
Date: Mon Dec 17 12:07:26 2018
New Revision: 267199
URL: https://gcc.gnu.org/viewcvs?rev=267199&root=gcc&view=rev
Log:
2018-12-17 Senthil Kumar Selvaraj
Backport from tru
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88504
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88531
Bug ID: 88531
Summary: Index data types when targeting AVX-512 vectorization
with gather/scatter
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: norma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88531
Richard Biener changed:
What|Removed |Added
Target||x86_64-*-*, i?86-*-*
Status
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88530
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
Keywords||assemble-failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88531
Jakub Jelinek changed:
What|Removed |Added
CC||hjl.tools at gmail dot com
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78986
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59002
Bug 59002 depends on bug 78986, which changed state.
Bug 78986 Summary: [7/8/9 Regression] template inner classes are not affected
by access specifiers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78986
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86823
Jonathan Wakely changed:
What|Removed |Added
CC||michele.caini at gmail dot com
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88507
--- Comment #1 from Jonathan Wakely ---
(In reply to Jonny Grant from comment #0)
> Hello
>
> This is an typo in the word "string", just reporting as perhaps it could
> show £ correctly, as it does on line 10 error.
But then you couldn't have t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88521
Umesh Kalappa changed:
What|Removed |Added
CC||umesh.kalappa0 at gmail dot com
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88521
--- Comment #4 from Umesh Kalappa ---
mateuszb,
Please can you provide us the sample file to investigate more on this .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88512
--- Comment #6 from Jonathan Wakely ---
(In reply to Jonny Grant from comment #3)
> Hi Marc
>
> I agree to useful to have the option to keep on for regular code.
> Perhaps a way just to turn off all expansive output for STL's std namespace?
But
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88521
--- Comment #5 from mateuszb at poczta dot onet.pl ---
W dniu 17.12.2018 o 13:52, umesh.kalappa0 at gmail dot com pisze:
> mateuszb,
> Please can you provide us the sample file to investigate more on this .
OK, after work I will investigate more
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88253
--- Comment #7 from Senthil Kumar Selvaraj ---
Author: saaadhu
Date: Mon Dec 17 13:26:50 2018
New Revision: 267201
URL: https://gcc.gnu.org/viewcvs?rev=267201&root=gcc&view=rev
Log:
2018-12-17 Senthil Kumar Selvaraj
Backport from tru
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88520
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88514
Jakub Jelinek changed:
What|Removed |Added
Attachment #45245|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81239
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed|2017-06-28 00:00:00 |2018-12-17
--- Comment #4 from Jonatha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88512
--- Comment #7 from Jonathan Wakely ---
I don't think this has anything to do with the std::lib anyway (and certainly
not "the STL" which the example doesn't use at all). Most of the differences
between GCC and Clang can be shown by an example li
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88503
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52321
Jonathan Wakely changed:
What|Removed |Added
CC||petschy at gmail dot com
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52321
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79342
--- Comment #14 from hjl at gcc dot gnu.org ---
Author: hjl
Date: Mon Dec 17 13:49:16 2018
New Revision: 267202
URL: https://gcc.gnu.org/viewcvs?rev=267202&root=gcc&view=rev
Log:
DWARF: Don't expand hash table when no insertion is needed
dwarf2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52321
--- Comment #9 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #8)
> Clang outputs an extra line saying the type is incomplete (which should
> probably be a "note:" but nevermind):
Ha, it is a note, but on my terminal the "not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79342
H.J. Lu changed:
What|Removed |Added
Status|NEW |RESOLVED
Known to work|5.4.1, 7.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52321
--- Comment #10 from Jonathan Wakely ---
Untested patch:
--- a/gcc/cp/typeck.c
+++ b/gcc/cp/typeck.c
@@ -7348,8 +7348,19 @@ build_static_cast (tree type, tree oexpr, tsubst_flags_t
complain)
}
if (complain & tf_error)
-error ("inval
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88497
--- Comment #6 from Bill Schmidt ---
Reassociation width should be 4 for this case per the target hook. Kelvin, you
can experiment with rs6000_reassociation_width to see if larger values give you
what you expect.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88507
--- Comment #2 from Jonny Grant ---
(In reply to Jonathan Wakely from comment #1)
> (In reply to Jonny Grant from comment #0)
> > Hello
> >
> > This is an typo in the word "string", just reporting as perhaps it could
> > show £ correctly, as it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88507
--- Comment #3 from Jonny Grant ---
ICC displays the UTF8 ok:
#1 with x86-64 icc 19.0.1
(8): error: unrecognized token
st£ing buf;
^
(8): error: identifier "st" is undefined
st£ing buf;
^
(8): error: expected a ";"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88507
--- Comment #4 from Jonny Grant ---
Clang has an appropriate message and displays the UTF8 okay.
GCC just needs to catch up with clang on this one...
#1 with x86-64 clang (trunk)
:8:7: error: non-ASCII characters are not allowed outside of lit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54589
--- Comment #14 from Jaydeep Chauhan ---
(In reply to Jaydeep Chauhan from comment #10)
I have tried solve this case using define_split or define_insn_and_split
but i am facing is some issue as per below:
1.It is not possible to combine bel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88507
--- Comment #5 from Jonny Grant ---
Created attachment 45247
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45247&action=edit
C example of this UTF8 not displaying
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78394
--- Comment #11 from Eric Gallager ---
(In reply to Marc Glisse from comment #10)
> IMO -Wmaybe-uninitialized should not be enabled by -Wall, whatever the
> optimization level (even at -O3), it has too many false positives that are
> all but impo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52321
Jonathan Wakely changed:
What|Removed |Added
Keywords||patch
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52321
--- Comment #12 from Jonathan Wakely ---
(In reply to Ivan Godard from comment #4)
> Define an enum of reasons with "success" first, flop the sense of the test
> so that false means coercion was OK (grep to find all calls and put a "!" in
> front
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88501
--- Comment #5 from Jonny Grant ---
(In reply to Jonathan Wakely from comment #4)
[..]
> > "st!ing"
>
> ! is a single byte in UTF-8
Fair enough. Just my idea below.
How about converting those two utf8 bytes, to a marker one byte, to help the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88502
--- Comment #3 from uros at gcc dot gnu.org ---
Author: uros
Date: Mon Dec 17 15:46:20 2018
New Revision: 267204
URL: https://gcc.gnu.org/viewcvs?rev=267204&root=gcc&view=rev
Log:
PR target/88502
* internal-fn.def (ACOSH): New.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88531
--- Comment #3 from Florian Schornbaum
---
Thank you for your very quick replies!
I'm aware of 88464 (I think this is the recent work you are referring to?), but
this had no effect on the index data type issue I was describing.
Even if the gat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88480
Tamar Christina changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88469
--- Comment #5 from Richard Earnshaw ---
Tentative patch posted here.
https://gcc.gnu.org/ml/gcc-patches/2018-12/msg01231.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88501
--- Comment #6 from Jonathan Wakely ---
Or just don't offer suggestions for identifiers that might be cut short by
invalid bytes after them.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88521
--- Comment #6 from mateuszb at poczta dot onet.pl ---
W dniu 17.12.2018 o 10:20, rguenth at gcc dot gnu.org pisze:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88521
>
> --- Comment #2 from Richard Biener ---
> Since the patch changes the ABI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81239
--- Comment #5 from Jonny Grant ---
(In reply to Jonathan Wakely from comment #4)
> I fixed the std::__cxx11::string case on trunk, the output is now:
Great!
I wonder how this looks now with -std=c++14or -std=c++17
(not sure why I still
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81239
--- Comment #6 from Jonny Grant ---
> I imagine you may have found out that this goes away if the "const" is
> removed. So it becomes
> void test_params(string & mystr1, string & out_str)
To add, by this I mean the std:: namespace is visible, p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81239
--- Comment #7 from Jonathan Wakely ---
(In reply to Jonny Grant from comment #5)
> (In reply to Jonathan Wakely from comment #4)
> > I fixed the std::__cxx11::string case on trunk, the output is now:
>
> Great!
>
> I wonder how this looks now
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88480
Tamar Christina changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88514
--- Comment #5 from Jakub Jelinek ---
Created attachment 45248
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45248&action=edit
gcc9-pr88513.patch
Full untested patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88522
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88522
--- Comment #2 from H.J. Lu ---
(In reply to Jakub Jelinek from comment #1)
> binutils 2.29 doesn't accept the syntax that 2.32 accepts and vice versa.
> Why has it changed incompatibly?
> Shouldn't new binutils accept both forms?
binutils 2.29
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88522
--- Comment #3 from Jakub Jelinek ---
Yes, it does. So, shall we emit just PTR always, or have a configure check to
detect this and use PTR if assembler with this support isn't detect, otherwise
whatever it requires newly (is that whatever is no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49884
pmatos at gcc dot gnu.org changed:
What|Removed |Added
CC||pmatos at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49884
Segher Boessenkool changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88532
Bug ID: 88532
Summary: variable has initializer but incomplete type
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88532
--- Comment #1 from Andrew Pinski ---
IIRC types defined in sizeof are not exposed to the current scope.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88521
--- Comment #7 from mateuszb at poczta dot onet.pl ---
W dniu 17.12.2018 o 13:52, umesh.kalappa0 at gmail dot com pisze:
> mateuszb,
> Please can you provide us the sample file to investigate more on this .
I'm not assembly expert, but this looks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88532
--- Comment #2 from sasho648 at gmail dot com ---
Related points from the standard:
6.7.9 p3 states:
The type of the entity to be initialized shall be an array of unknown size or a
complete object type that is not a variable length array type.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88528
--- Comment #3 from Pavel Roskin ---
I ran "git bisect" between gcc 7.1.0 (affected) and gcc 8.1.0 (unaffected).
Following commit fixed the issue:
https://github.com/gcc-mirror/gcc/commit/e0ccd4807edc919735b4d86590b5a9def529f91c
2018-04-11 Mar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88522
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88533
Bug ID: 88533
Summary: [9 Regression] Higher performance penalty of
array-bounds checking for sparse-matrix vector
multiply
Product: gcc
Version: 9.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88533
--- Comment #1 from Harald Anlauf ---
Created attachment 45250
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45250&action=edit
Sparse matrix meta-data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88528
--- Comment #4 from Pavel Roskin ---
The trivial backport of PR c++/85032 fixes both my testcase and the original
issue with my code. Please include the fix in gcc 7.5.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88533
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52321
--- Comment #14 from Jonathan Wakely ---
Author: redi
Date: Mon Dec 17 21:49:58 2018
New Revision: 267219
URL: https://gcc.gnu.org/viewcvs?rev=267219&root=gcc&view=rev
Log:
PR c++/52321 print note for static_cast to/from incomplete type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52321
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88410
--- Comment #3 from Jakub Jelinek ---
Author: jakub
Date: Mon Dec 17 21:54:37 2018
New Revision: 267220
URL: https://gcc.gnu.org/viewcvs?rev=267220&root=gcc&view=rev
Log:
PR c++/88410
* cp-gimplify.c (cp_fold) : For offsetof-like
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88533
--- Comment #3 from Harald Anlauf ---
(In reply to Thomas Koenig from comment #2)
> Strange.
>
> I ran the code (with the data) a few times on my Ryzen 7 home
> system.
>
> Here are some timings (run 10 times):
[snipped]
> Is it possible that t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87870
--- Comment #1 from Peter Bergner ---
Author: bergner
Date: Mon Dec 17 22:07:11 2018
New Revision: 267221
URL: https://gcc.gnu.org/viewcvs?rev=267221&root=gcc&view=rev
Log:
gcc/
PR target/87870
* config/rs6000/vsx.md (nW): New mo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87870
Peter Bergner changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88410
Jakub Jelinek changed:
What|Removed |Added
Summary|[8/9 Regression] internal |[8 Regression] internal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88533
--- Comment #4 from Harald Anlauf ---
Without CONTIGUOUS, I see -O3 brings gcc-9 to the level of gcc-7 or gcc-8:
baseline + -O3 -funroll-loops -fcheck=bounds :
7: 1.57
8: 1.40
9: 1.57
baseline + -O3 -funroll-loops -fcheck=bounds -fno-tree-ch :
--enable-languages=c,c++,fortran
Thread model: posix
gcc version 9.0.0 20181217 (experimental) (GCC)
$
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71044
--- Comment #7 from Jonathan Wakely ---
Author: redi
Date: Mon Dec 17 22:43:31 2018
New Revision: 267222
URL: https://gcc.gnu.org/viewcvs?rev=267222&root=gcc&view=rev
Log:
PR libstdc++/71044 fix off-by-one errors introduced recently
The recent
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88525
--- Comment #1 from joseph at codesourcery dot com ---
I'd say the enum member a is declared by a contained struct-declaration,
not by the declaration itself.
The case of reading the text to allow for a declarator inside a
struct-declaration w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87945
--- Comment #7 from Dominique d'Humieres ---
> Not sure this is related, but I tried compiling ./gfortran.dg/pr87945_1.f90
> on an asan build of gcc trunk revision 267200 and got this:
I think it is a duplicate of pr87881.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88526
--- Comment #1 from joseph at codesourcery dot com ---
Types with [*] are definitely complete types; the standard explicitly says
"such arrays are nonetheless complete types". The "'[*]' not in a
declaration" warning is a warning, not an error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88532
Joseph S. Myers changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88477
Joseph S. Myers changed:
What|Removed |Added
CC||sasho648 at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87945
--- Comment #8 from kargl at gcc dot gnu.org ---
(In reply to David Binderman from comment #6)
> Not sure this is related, but I tried compiling ./gfortran.dg/pr87945_1.f90
> on an asan build of gcc trunk revision 267200 and got this:
>
I think
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88253
Senthil Kumar Selvaraj changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86176
Eric Gallager changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88534
Bug ID: 88534
Summary: internal compiler error: in
tree_add_const_value_attribute, at dwarf2out.c:20246
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88534
krux changed:
What|Removed |Added
Keywords||ice-on-valid-code
--- Comment #1 from krux ---
h
1 - 100 of 104 matches
Mail list logo
