https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81956
--- Comment #4 from Eric Botcazou ---
Author: ebotcazou
Date: Tue Feb 26 08:12:21 2019
New Revision: 269205
URL: https://gcc.gnu.org/viewcvs?rev=269205&root=gcc&view=rev
Log:
PR ada/81956
Backport from mainline
2017-09-06
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81956
Eric Botcazou changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89496
--- Comment #4 from Martin Liška ---
(In reply to Thomas Koenig from comment #2)
> This looks pretty obvious to me, at least looking at the
> -fdump-fortran-original dump. I will try to come up with
> a test case.
>
> Would it be possible to ch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89448
--- Comment #3 from Richard Biener ---
Yes.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89455
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |9.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89458
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
Status|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89459
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89497
Martin Liška changed:
What|Removed |Added
Keywords||ice-on-valid-code
Status|UNCO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89463
Richard Biener changed:
What|Removed |Added
Keywords||wrong-debug
Status|UNCONFIR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89503
Bug ID: 89503
Summary: Checking ICE in 'gcc.dg/warn-strlen-no-nul.c'
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: ice-checking, ice-on-valid-code
Severity: nor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89472
--- Comment #1 from Richard Biener ---
Bah, another one. A patch to XFAIL hppa is pre-approved.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89504
Bug ID: 89504
Summary: Checking ICE in 'gcc.dg/rtl/x86_64/pro_and_epilogue.c'
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: ice-checking
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89490
--- Comment #9 from Bernd Edlinger ---
> And, what do you find wrong on the alignment?
In the case of the artificially zero terminated strings,
the .zero is now wrong, and they can actually screw up the
necessary alignment.
Maybe the easiest w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89479
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89480
Richard Biener changed:
What|Removed |Added
Keywords||ice-on-valid-code
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89486
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71446
Richard Biener changed:
What|Removed |Added
CC||st at quanttec dot com
--- Comment #7 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89487
--- Comment #5 from Richard Biener ---
Looks like may_be_nonaddressable_p misses a VAR_DECL case checking for hard
registers and the code in loop-distribution should use that helper to fend
off generating invalid addresses.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89487
Richard Biener changed:
What|Removed |Added
Keywords||wrong-code
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89489
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89489
--- Comment #4 from Richard Biener ---
Testing patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89494
Richard Biener changed:
What|Removed |Added
Keywords||build
Target|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89497
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |8.4
--- Comment #3 from Richard Biener
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89498
--- Comment #1 from Richard Biener ---
Can't reproduce on trunk. If #include is necessary can you attach
preprocessed source please?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89499
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |7.5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89501
--- Comment #5 from Richard Biener ---
(In reply to Jeffrey A. Law from comment #3)
> Yup. It's the same as 18501. We meet UNDEFINED and [0,0] resulting in
> [0,0] and nothing ever causes reevaluation of the PHI. Things are working
> as "expec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89497
--- Comment #4 from Martin Liška ---
(In reply to Richard Biener from comment #3)
> Does trunk work?
Thunk is fine.
> Also I wonder whether the graphite flags are necessary to
> trigger the issue (and as recommendation, don't use -fgraphite-id
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89497
--- Comment #5 from Martin Liška ---
Created attachment 45821
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45821&action=edit
Unreduced test-case
Started to fail with r268745 which is definitely a culprit:
$ gcc 11.i 22.i 33.i 44.i -fPIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89497
--- Comment #6 from Martin Liška ---
Created attachment 45822
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45822&action=edit
Reduced test-case
However, this reduced test-case fails with GCC-8 branch for all releases.
Started on trunk wit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89497
Martin Liška changed:
What|Removed |Added
Known to work||7.4.0, 9.0
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89448
--- Comment #4 from Mark RISON ---
[Aside...
I can't see a way to raise a bug on the GCC Bugzilla itself, so:
The status of this bug is currently NEW. However the explanatory hyperlink,
https://gcc.gnu.org/bugzilla/page.cgi?id=fields.html#bug_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89505
Bug ID: 89505
Summary: [9 Regression] LibreOffice miscompilation starting
with r260383
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89505
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P1
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89497
--- Comment #8 from Martin Liška ---
I can also confirm that building the whole project with original flags and
current GCC trunk is fine.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89474
--- Comment #10 from Jakub Jelinek ---
Author: jakub
Date: Tue Feb 26 10:08:29 2019
New Revision: 269206
URL: https://gcc.gnu.org/viewcvs?rev=269206&root=gcc&view=rev
Log:
PR target/89474
* config/i386/i386.c (remove_partial_avx_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89479
--- Comment #5 from Eyal Rozenberg ---
(In reply to Richard Biener from comment #4)
> exposing __restrict to the IL).
Is "IL" an acronym for "Intermediate Language"? Remember many bug
posters/readers are not GCC developers and don't know all th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89502
--- Comment #3 from Uroš Bizjak ---
(In reply to H.J. Lu from comment #0)
> x.s: Assembler messages:
> x.s:11: Error: can't encode segment `%fs' with 32-bit address
> x.s:18: Error: can't encode segment `%fs' with 32-bit address
Is this some new
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89502
--- Comment #4 from Uroš Bizjak ---
(In reply to H.J. Lu from comment #1)
> Ever better, we can use UNSPEC_TP to handle it:
>
> movl%fs:24, %ecx
>
> to save a register.
We do, with -O2, but -O1 CSEs the constant into the register for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89505
--- Comment #1 from Jakub Jelinek ---
I think the problem is mainly:
MEM[(struct ScXMLTableColContext *)this_29(D) clique 1 base 1].nColCount =
_15;
vs.
_15 = MEM[(const int &)_116 clique 1 base 0];
Both have the same clique, but different ba
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89474
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87007
Bug 87007 depends on bug 89474, which changed state.
Bug 89474 Summary: [9 Regression] ice in df_reg_chain_verify_unmarked, at
df-scan.c:3995
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89474
What|Removed |Add
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89505
--- Comment #2 from Richard Biener ---
ScXMLTableColContext::ScXMLTableColContext (struct ScXMLTableColContext * const
this, struct ScXMLImport & rImport, const struct Reference & rAttrList)
{
# PT = null { D.1010617 } (nonlocal, escaped, restr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43210
--- Comment #10 from Jakub Jelinek ---
Author: jakub
Date: Tue Feb 26 10:36:05 2019
New Revision: 269207
URL: https://gcc.gnu.org/viewcvs?rev=269207&root=gcc&view=rev
Log:
PR fortran/43210
* trans-array.c (gfc_conv_array_initiali
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89505
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89479
--- Comment #6 from Eyal Rozenberg ---
Thanks to a friendly StackOverflow user, I should also report that (about) the
same code produces the same compiler behavior disparity for proper C:
https://godbolt.org/z/kVYqp8
with the slight modificatio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88469
--- Comment #13 from Richard Earnshaw ---
(In reply to Stefan Ring from comment #12)
> Unfortunately my armv5 device has died in the meantime, so I cannot verify
> my original use case. The behavior is indeed different on armv7. It does not
> tra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89505
--- Comment #4 from Richard Biener ---
Created attachment 45824
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45824&action=edit
patch I am testing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89489
--- Comment #5 from Richard Biener ---
Author: rguenth
Date: Tue Feb 26 11:03:45 2019
New Revision: 269210
URL: https://gcc.gnu.org/viewcvs?rev=269210&root=gcc&view=rev
Log:
2019-02-26 Richard Biener
PR tree-optimization/89489
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89489
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64132
--- Comment #15 from Jonathan Wakely ---
Probably r265165 or r265286
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89410
Tamar Christina changed:
What|Removed |Added
CC||tnfchris at gcc dot gnu.org
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64132
--- Comment #16 from Jonathan Wakely ---
I suspect Debian had downstream changes to the it_IT.ISO8859-15 locale data, as
was later done in upstream glibc. The original version of the test failed if
it_IT.ISO8859-15 uses thousands separators. The
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88469
--- Comment #14 from Stefan Ring ---
(In reply to Richard Earnshaw from comment #13)
> Note that if you have root access on your board you can modify the kernel's
> behaviour for various unaligned accesses by changing /proc/cpu/alignment
> (see D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89498
--- Comment #2 from G. Steinmetz ---
Hm, on my environment it's not necessary to include ,
can therefore be omitted. But that case was only exemplary.
You can try to catch the other ones, e.g. simply looping over
###
export LANG=C
cd gcc/tes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82501
--- Comment #20 from Martin Liška ---
(In reply to Andrey Drobyshev from comment #18)
> (In reply to Martin Liška from comment #16)
> > Created attachment 45797 [details]
> > Patch candidate
> >
> > Patch candidate where I made some refactoring
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89506
Bug ID: 89506
Summary: [7/8/9 Regression] ICE: in decompose, at rtl.h:2266
with -Og -g
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82501
--- Comment #21 from Martin Liška ---
Thanks for the test-case.
>
> So I guess we still have to detect relocations. I cannot see limitations
> coming particularly from approach #2 from
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82501#c1. We
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89494
--- Comment #6 from Piotr Kubaj ---
(In reply to Richard Biener from comment #5)
> So it looks like stage1 gcc is miscompiled somehow. I wonder if you can
> avoid
> setting CFLAGS et al?
I just added CFLAGS+=-O0 and CXXFLAGS+=-O0. For now, the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67542
--- Comment #8 from Dominique d'Humieres ---
I cannot get any ICE with the options and revisions I have tried.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79864
Dominique d'Humieres changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70644
--- Comment #3 from Jonathan Wakely ---
-Wbase-conversion (C++, Objective-C++ only)
Warn when a pointer/reference to an object is converted to a
pointer/reference to a base class of the object and any intermediate
base classes have
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89507
Bug ID: 89507
Summary: bogus "size of array exceeds maximum object size"
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67650
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed|2018-05-03 00:00:00 |2019-2-26
--- Comment #34 from Jonatha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89508
Bug ID: 89508
Summary: gcc snapshot 9.0.1 20190127 generates invalid
assembler options on aarch64-unknown-linux-gnu with
-march=native
Product: gcc
Version: 9.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67650
--- Comment #35 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #34)
> __attribute__((weak)) void f() { }
This is here so that I() { f(); } doesn't get inlined (because the compiler
can't know what f() does, since it might get
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89171
--- Comment #3 from Andreas Schwab ---
How can I build and run a single libgo test?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89430
--- Comment #8 from Jiangning Liu ---
It is related to https://gcc.gnu.org/ml/gcc-patches/2015-11/msg02998.html
Bernd's patch is an overkill.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89502
--- Comment #5 from H.J. Lu ---
(In reply to Uroš Bizjak from comment #3)
> (In reply to H.J. Lu from comment #0)
> > x.s: Assembler messages:
> > x.s:11: Error: can't encode segment `%fs' with 32-bit address
> > x.s:18: Error: can't encode segme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89506
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89508
Tamar Christina changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88530
Tamar Christina changed:
What|Removed |Added
CC||andrewm.roberts at sky dot com
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89506
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89171
--- Comment #4 from Ian Lance Taylor ---
To run, say, just the go/build test, cd to the libgo build directory and run
"make go/build/check". To keep the test binary around, run "make
GOTESTFLAGS=--keep go/build/check". That will leave the test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89502
--- Comment #6 from Uroš Bizjak ---
(In reply to H.J. Lu from comment #5)
> I think we should avoid %fs:(%edx) address. Is that possible to generate
It is what middle-end expands to, so nothing much that we can do here.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89410
--- Comment #18 from David Malcolm ---
(In reply to Tamar Christina from comment #17)
> Hi,
>
> I'm getting a test failure on master for these new tests
>
> UNRESOLVED: gcc.dg/pr89410-1.c: bad option "-1": must be -exact, -glob,
> -regexp, or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89479
--- Comment #7 from rguenther at suse dot de ---
On Tue, 26 Feb 2019, eyalroz at technion dot ac.il wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89479
>
> --- Comment #5 from Eyal Rozenberg ---
> (In reply to Richard Biener from comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71446
Jonathan Wakely changed:
What|Removed |Added
Keywords||rejects-valid
Status|UNCON
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89505
Richard Biener changed:
What|Removed |Added
Keywords||wrong-code
Priority|P1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89505
--- Comment #5 from Richard Biener ---
Author: rguenth
Date: Tue Feb 26 14:09:19 2019
New Revision: 269212
URL: https://gcc.gnu.org/viewcvs?rev=269212&root=gcc&view=rev
Log:
2019-02-26 Richard Biener
PR tree-optimization/89505
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89509
Bug ID: 89509
Summary: restrict doesnt work with subfield accesses
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-op
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89509
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
Status|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71446
--- Comment #9 from Jakub Jelinek ---
So, shall we never try ck_list conversion for CONSTRUCTORs with any designators
(while for -std=c++2a we'll complain if there is a mix of designated
initializer clauses and non-designated initializ clauses, I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89410
--- Comment #19 from Tamar Christina ---
Hmm we're running it on
Tcl: 8.5
Expect: 5.45
Dejagnu: 1.5.1
So I think those are about the same..
办PP
理 $ +Q+V+信#%
--
& $ -- I 3 4
髮 $--- 2 4 3 4
& $ ---6 1 4 8
漂 $
-2019/2/26
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89481
--- Comment #4 from Jakub Jelinek ---
Author: jakub
Date: Tue Feb 26 14:37:39 2019
New Revision: 269213
URL: https://gcc.gnu.org/viewcvs?rev=269213&root=gcc&view=rev
Log:
PR c++/89481
* constexpr.c (cxx_eval_store_expression): Wh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89481
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86535
--- Comment #14 from ian at gcc dot gnu.org ---
Author: ian
Date: Tue Feb 26 14:46:56 2019
New Revision: 269214
URL: https://gcc.gnu.org/viewcvs?rev=269214&root=gcc&view=rev
Log:
PR go/86535
runtime: always declare nanotime in Go
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86535
--- Comment #15 from Ian Lance Taylor ---
I committed a patch that should fix the nanotime problem.
Some of the other issues you describe will most likely require a fix in the
libgo/mkrsysinfo.sh script, which generates the file runtime_sysinfo.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89482
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89490
--- Comment #10 from Jakub Jelinek ---
I think there is a serious flaw that the section anchor infrastructure is used
at all for the SECTION_MERGE sections, one really must not use any kind of
section anchors for those sections, there is no guara
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89506
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89507
Richard Biener changed:
What|Removed |Added
Keywords||diagnostic
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89509
--- Comment #2 from Richard Biener ---
Created attachment 45827
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45827&action=edit
the patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89490
--- Comment #11 from Bernd Edlinger ---
I agree, that it would be better to not put any
mergeable things in a block object. If section anchors
are ever used on a string constant, it is going to fail.
A constant with size = 0 is possible, for in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89490
--- Comment #12 from Bernd Edlinger ---
> These should not go into mergeable sections.
I mean: These do not go into mergeable sections.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89490
--- Comment #13 from Jakub Jelinek ---
(In reply to Bernd Edlinger from comment #11)
> Instead of:
>
> if (thissize == 0
> || TREE_STRING_POINTER (str) [thissize - 1] != '\0')
> size = MAX (size, thissiz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89501
--- Comment #6 from Linus Torvalds ---
(In reply to Richard Biener from comment #5)
>
> And this meeting helps us avoid bogus warnings for cases where GCC has
> difficulties proving dead code paths are actually dead ...
Ack. I do see the diffi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89501
--- Comment #7 from Jeffrey A. Law ---
It's reliably the case that a false positive uninit warning also represents a
failure to optimize something. So we've got significant incentives to deeply
analyze and look for fixes. So feel free to pass e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89416
Jonathan Wakely changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89507
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
1 - 100 of 168 matches
Mail list logo
