https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65115
Bug ID: 65115
Summary: default init_priority attribute
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: web
Ass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63371
--- Comment #3 from Tobias Burnus ---
See also PR 63363, which causes this code to be reject now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63371
--- Comment #2 from Tobias Burnus ---
See also https://groups.google.com/forum/#!topic/comp.lang.fortran/N3B4ge5XQ40
- and in particular Richard Main's comments therein.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65114
Bug ID: 65114
Summary: char_traits::copy violates memcpy constraints, own
postcondition
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65113
Bug ID: 65113
Summary: string::copy violates traits requirements
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65093
Hans-Peter Nilsson changed:
What|Removed |Added
Component|middle-end |testsuite
Assignee|unassi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64559
--- Comment #7 from ctice at gcc dot gnu.org ---
Author: ctice
Date: Thu Feb 19 00:43:33 2015
New Revision: 220805
URL: https://gcc.gnu.org/viewcvs?rev=220805&root=gcc&view=rev
Log:
Backport patch from Google 4.9 branch (r220431):
r220431 | wmi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64938
--- Comment #5 from ctice at gcc dot gnu.org ---
Author: ctice
Date: Thu Feb 19 00:43:33 2015
New Revision: 220805
URL: https://gcc.gnu.org/viewcvs?rev=220805&root=gcc&view=rev
Log:
Backport patch from Google 4.9 branch (r220431):
r220431 | wmi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64068
--- Comment #13 from ctice at gcc dot gnu.org ---
Author: ctice
Date: Thu Feb 19 00:43:33 2015
New Revision: 220805
URL: https://gcc.gnu.org/viewcvs?rev=220805&root=gcc&view=rev
Log:
Backport patch from Google 4.9 branch (r220431):
r220431 | wmi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46102
Aldy Hernandez changed:
What|Removed |Added
CC||aldyh at gcc dot gnu.org
Assi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62630
--- Comment #14 from Mircea Namolaru ---
It seems to me that scalar evolution succeeds to determine
the number of iterations for the case of signed longs. Looking
in vectorization dump, first a symbolic expression for the number of
iterations of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65028
H.J. Lu changed:
What|Removed |Added
Attachment #34793|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65028
--- Comment #48 from H.J. Lu ---
(In reply to Martin Jambor from comment #46)
> release_ssa is an early optimization pass, wpa dump is not helpful.
> We need release-ssa dump from the compilation stage (as opposed to the
> linking stage) of the s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65028
--- Comment #46 from Martin Jambor ---
(In reply to H.J. Lu from comment #45)
>
> Can you see anything wrong with the new dump?
release_ssa is an early optimization pass, wpa dump is not helpful.
We need release-ssa dump from the compilation st
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65028
--- Comment #45 from H.J. Lu ---
(In reply to Martin Jambor from comment #43)
>
> I really find it very suspicious that even the jump-function printing
> code, which is a an iteration over edges as simple as they get, does
> not see the wrong cal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65028
--- Comment #44 from H.J. Lu ---
Created attachment 34804
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34804&action=edit
Dumps from -fdump-ipa-cp-details -fdump-tree-release_ssa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64634
--- Comment #4 from Jakub Jelinek ---
Author: jakub
Date: Wed Feb 18 22:02:43 2015
New Revision: 220801
URL: https://gcc.gnu.org/viewcvs?rev=220801&root=gcc&view=rev
Log:
PR gcov-profile/64634
* tree-eh.c (frob_into_branch_around): Fix u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65028
--- Comment #43 from Martin Jambor ---
(In reply to H.J. Lu from comment #42)
> Does it skip a jump func when its argument alignment is unknown?
No, I don't think it does. Cur is initialized to unknown alignment
and then only overwrites the who
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64634
Jakub Jelinek changed:
What|Removed |Added
Known to work||5.0
Summary|[4.8/4.9/5 Regres
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65028
--- Comment #42 from H.J. Lu ---
(In reply to Martin Jambor from comment #41)
> (In reply to H.J. Lu from comment #24)
> >
> > IPA-CP missed _ZN18eonImageCalculatorC1Ev which calls
> > _ZmlRK10ggSpectrumS1_ with 8-byte aligned rPrimary.
>
> If
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65028
--- Comment #41 from Martin Jambor ---
(In reply to H.J. Lu from comment #24)
>
> IPA-CP missed _ZN18eonImageCalculatorC1Ev which calls
> _ZmlRK10ggSpectrumS1_ with 8-byte aligned rPrimary.
If I am not mistaken and this call is in between nodes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52231
--- Comment #7 from Nathan Froyd ---
(In reply to Jonathan Wakely from comment #6)
> (In reply to Nathan Froyd from comment #5)
> > This also showed up in the context of trying to hint to the compiler that
> > placement new didn't need null check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65028
--- Comment #40 from Jan Hubicka ---
Do you know why propagate_constants_accross_call skippes the call? Is it
because it is never called on it or is it because it quits on one of the early
exits?
It may be a case that we produce wrong strongly c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58123
--- Comment #8 from Jan Kratochvil ---
(In reply to Aldy Hernandez from comment #7)
> Putting this aside for a second, my question is, do we really want a
> debugging experience where we jump from back from the end of scope, back to
> the declara
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65028
--- Comment #39 from H.J. Lu ---
(In reply to Jan Hubicka from comment #38)
> Created attachment 34803 [details]
> ipp
>
> OK. Though I do not directly see how it can solve this wrong code issue.
It doesn't work. propagate_constants_accross_ca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52231
--- Comment #6 from Jonathan Wakely ---
(In reply to Nathan Froyd from comment #5)
> This also showed up in the context of trying to hint to the compiler that
> placement new didn't need null checks:
That's only become true quite recently:
http:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63491
--- Comment #6 from Peter Bergner ---
(In reply to Vladimir Makarov from comment #5)
> Sorry, I can not reproduce the bug on the today trunk. Probably it was
> fixed by numerous changes in LRA since Oct.
This still fails for me today on my big
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65028
--- Comment #38 from Jan Hubicka ---
OK. Though I do not directly see how it can solve this wrong code issue.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65028
--- Comment #36 from Jan Hubicka ---
Hi,
I do not really see the reason for wrong code, but the merging logic seems
weird for me. There is no merging done when we get two different alignments
and also we seem to immediately drop lattice to botto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65028
--- Comment #37 from H.J. Lu ---
(In reply to Jan Hubicka from comment #36)
> Hi,
> I do not really see the reason for wrong code, but the merging logic seems
> weird for me. There is no merging done when we get two different alignments
> and al
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58123
Aldy Hernandez changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63891
Jeffrey A. Law changed:
What|Removed |Added
Keywords|wrong-code |
Priority|P1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65008
Marek Polacek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64432
--- Comment #24 from Jerry DeLisle ---
(In reply to Harald Anlauf from comment #22)
> count_rate(8),count_max(1) =0 127
>
> OK, but the last line looks strange: lacking documentation,
> I'd expect the rate to be 1, not 0.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64983
--- Comment #5 from Iain Sandoe ---
(In reply to howarth from comment #4)
> FYI, I posted this to
> http://lists.gnu.org/archive/html/bug-dejagnu/2015-02/msg1.html and
> emailed Ben Elliston the g++.log files generated under dejagnu 1.5.1 and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65028
--- Comment #35 from Jan Hubicka ---
> propagate_alignment_accross_jump_function seems wrong:
>
> if (cur.known)
> {
> if (!dest_lat->alignment.known)
> {
> dest_lat->alignment = cur;
> return true;
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65112
Bug ID: 65112
Summary: [5 Regression] -fsanitized=thread Fortran program
crashes at startup
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64983
--- Comment #4 from howarth at bromo dot med.uc.edu ---
FYI, I posted this to
http://lists.gnu.org/archive/html/bug-dejagnu/2015-02/msg1.html and emailed
Ben Elliston the g++.log files generated under dejagnu 1.5.1 and 1.5.2.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65028
--- Comment #34 from H.J. Lu ---
propagate_alignment_accross_jump_function seems wrong:
if (cur.known)
{
if (!dest_lat->alignment.known)
{
dest_lat->alignment = cur;
return true;
}
We can't ch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64432
--- Comment #23 from Harald Anlauf ---
(In reply to Jerry DeLisle from comment #21)
> Created attachment 34798 [details]
> Full Patch
>
> This patch attempts to do it all. I have not tested the mingw/cygwin side of
> it.
>
> Any testing/comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65107
--- Comment #3 from vries at gcc dot gnu.org ---
Author: vries
Date: Wed Feb 18 20:07:48 2015
New Revision: 220794
URL: https://gcc.gnu.org/viewcvs?rev=220794&root=gcc&view=rev
Log:
Add missing cleanup in gfortran.dg/read_eof_8.f90
2015-02-18 T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64432
--- Comment #22 from Harald Anlauf ---
(In reply to Jerry DeLisle from comment #21)
> Created attachment 34798 [details]
> Full Patch
>
> This patch attempts to do it all. I have not tested the mingw/cygwin side of
> it.
>
> Any testing/comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63892
Jeffrey A. Law changed:
What|Removed |Added
Priority|P1 |P2
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52231
--- Comment #5 from Nathan Froyd ---
FWIW, clang (>= 3.5) understands how to optimize the original testcase in
comment 0; it even issues a -Wtautological-undefined-compare warning.
This also showed up in the context of trying to hint to the comp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52231
Andrew Pinski changed:
What|Removed |Added
CC||froydnj at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64983
--- Comment #3 from Iain Sandoe ---
running with dejaGNU 1.6 also produces the wrong output.
I did a small amount of analysis - and it looks like the content of the
xxx.sum.sep files is not what's expected by the combiner script.
*guess* that t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65111
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65028
--- Comment #33 from H.J. Lu ---
There are many calls to _ZmlRK10ggSpectrumS1_ in LTO IR. Some calls have
parameters with unknown alignment. But they are ignored by IPA-CP, which
applies parameter alignment from calls with known parameter alignm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65110
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52595
Jonathan Wakely changed:
What|Removed |Added
CC||stanshebs at earthlink dot net
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65111
Bug ID: 65111
Summary: null checks on pointers created from references not
optimized away
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65110
Bug ID: 65110
Summary: Does not accept multi-argument template in member
initialization
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64999
--- Comment #23 from Ian Lance Taylor ---
Yes, I do mean to change saveg in mprof.goc.
runtime_callers in general returns full file/line information, which is
required for full correctness when using gccgo. When it devolves back to a
plain PC,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65008
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58123
Aldy Hernandez changed:
What|Removed |Added
CC||aldyh at gcc dot gnu.org
Assi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64983
--- Comment #2 from howarth at bromo dot med.uc.edu ---
I am not seeing identical g++.log's being created here from dejagnu 1.5.1 and
1.5.2 on x86_64-apple-darwin14 with separate runs of...
make -k check RUNTESTFLAGS="--target_board=unix'{-m32,-m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58910
Ville Voutilainen changed:
What|Removed |Added
CC||ville.voutilainen at gmail dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65028
--- Comment #32 from H.J. Lu ---
_ZN18eonImageCalculatorC2Ev has an alias, _ZN18eonImageCalculatorC1Ev.
It is only called once in main. _ZN18eonImageCalculatorC1Ev calls
_ZmlRK10ggSpectrumS1_. But _ZN18eonImageCalculatorC1Ev is ignored
by ipa_r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65064
H.J. Lu changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65064
--- Comment #17 from hjl at gcc dot gnu.org ---
Author: hjl
Date: Wed Feb 18 17:24:20 2015
New Revision: 220792
URL: https://gcc.gnu.org/viewcvs?rev=220792&root=gcc&view=rev
Log:
Return false for common symbols in sdata_symbolic_operand
Althoug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65078
Jeffrey A. Law changed:
What|Removed |Added
Target Milestone|--- |5.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65028
H.J. Lu changed:
What|Removed |Added
Status|REOPENED|NEW
--- Comment #31 from H.J. Lu ---
If I dis
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65107
--- Comment #2 from vries at gcc dot gnu.org ---
(In reply to Dominique d'Humieres from comment #1)
> > But cleaning after itself does not guarantee that this failure is fixed.
> > We need to ensure that all tests that use test.dat clean up after
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64491
--- Comment #9 from Jakub Jelinek ---
(In reply to Andrew Stubbs from comment #8)
> Just silencing the warning may not be enough. The compiler may optimize away
> loop exit conditions based on this analysis. The warning mirrors the logic
> rather
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64491
--- Comment #8 from Andrew Stubbs ---
Just silencing the warning may not be enough. The compiler may optimize away
loop exit conditions based on this analysis. The warning mirrors the logic
rather than shares it (due to the way the logic is distr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64634
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65109
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62630
--- Comment #13 from Richard Biener ---
Ah, expand_simple_operations will not expand the MIN/MAX_EXPRs. If we change
that the patch makes data-ref analysis fail differently (we correctly can
then compute bounds for the loops!), as we still may w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62630
--- Comment #12 from Richard Biener ---
Created attachment 34801
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34801&action=edit
use VRP to interpret an expr and compute its range
The attached patch is a prototype that tries to replace ni
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65098
Arnaud Charlet changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65104
Arnaud Charlet changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65104
Arnaud Charlet changed:
What|Removed |Added
CC||charlet at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64935
--- Comment #17 from Markus Trippelsdorf ---
(In reply to Maxim Kuvyrkov from comment #16)
> Created attachment 34799 [details]
> Patch v2
>
> I'm happy with this version of the patch and will post it for review after
> testing.
>
> Markus, I w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65108
--- Comment #1 from Andy Wingo ---
I mentioned this bug to Dodji Seketeli who said that this was probably an
instance of early constant folding causing Foo::one to appear unused.
On Dodji's suggestion I recompiled with -fno-eliminate-unused-debu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65109
Bug ID: 65109
Summary: [5 Regression] r220674 causes FAIL:
gcc.target/powerpc/ppc64-abi-1.c execution test
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65106
Bug ID: 65106
Summary: C99 intialization of struct with const member through
a non-const pointer
Product: gcc
Version: 4.9.3
Status: UNCONFIRMED
Severity: norma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65107
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65106
--- Comment #1 from joseph at codesourcery dot com ---
See the definition of "modifiable lvalue" (6.3.2.1#1): "... if it is a
structure or union, does not have any member (including, recursively, any
member or element of all contained aggregate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64634
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65108
Bug ID: 65108
Summary: Missing DWARF info for static const class members
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64491
Jakub Jelinek changed:
What|Removed |Added
CC||ams at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65107
Bug ID: 65107
Summary: FAIL: gfortran.dg/eof_4.f90, runtime error: File
'test.dat' already exists
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65087
Markus Trippelsdorf changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64864
Markus Trippelsdorf changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56852
--- Comment #6 from Dominique d'Humieres ---
> There is a simple fix, may be too big hammer:
> ...
The patch in comment 3 fixes the ICE, bur breaks many tests (700+) for error:
FAIL: gfortran.dg/abstract_type_3.f03 -O (test for errors, line
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65105
--- Comment #2 from Ilya Enkovich ---
For this test I see 'plus' and 'minus' ops have DI mode until RA and get GPR
pairs:
(insn 12 35 13 2 (parallel [
(set (reg:DI 0 ax [orig:98 D.1945 ] [98])
(plus:DI (reg:DI 0 ax [o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65064
--- Comment #16 from H.J. Lu ---
A new patch is posted at
https://gcc.gnu.org/ml/gcc-patches/2015-02/msg01105.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64999
--- Comment #22 from Dominik Vogt ---
You mean the function saveg() code in mprof.goc?
I'm actually not sure how the above patch to runtime_callers() interacts with
all the other functions that call runtime_callers(). :-/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65063
Richard Biener changed:
What|Removed |Added
Known to work||5.0
Summary|[4.8/4.9/5 Regre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65063
--- Comment #4 from Richard Biener ---
Author: rguenth
Date: Wed Feb 18 13:08:58 2015
New Revision: 220788
URL: https://gcc.gnu.org/viewcvs?rev=220788&root=gcc&view=rev
Log:
2015-02-18 Richard Biener
PR tree-optimization/65063
* tree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62630
--- Comment #11 from Richard Biener ---
Btw, graphite generates expressions like MIN_EXPR <(long)n, (long)mid> < 0
that fold does not simplify. Adding a match.pd pattern to shorten min/max
expressions we end up with
:
_28 = MIN_EXPR ;
_29
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65105
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65098
--- Comment #1 from vries at gcc dot gnu.org ---
This would fix it:
...
diff --git a/gcc/ada/gnat_rm.texi b/gcc/ada/gnat_rm.texi
index 04f3d0b..1fd0534 100644
--- a/gcc/ada/gnat_rm.texi
+++ b/gcc/ada/gnat_rm.texi
@@ -8886,7 +8886,7 @@ attribute.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64999
--- Comment #21 from Ian Lance Taylor ---
Ah, thanks. So we should change that to
r->stk[i] = locstk[i].pc + 1;
too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65105
Bug ID: 65105
Summary: [i386] XMM registers are not used for 64bit
computations on 32bit target
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65104
--- Comment #1 from vries at gcc dot gnu.org ---
Created attachment 34800
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34800&action=edit
tentative patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65092
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65104
vries at gcc dot gnu.org changed:
What|Removed |Added
Severity|normal |trivial
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65104
Bug ID: 65104
Summary: gnat_rm.texi 'next/prev in menu and sectioning
difffer' warnings
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65064
--- Comment #15 from Andreas Schwab ---
The first patch works without regressions.
http://gcc.gnu.org/ml/gcc-testresults/2015-02/msg02066.html
1 - 100 of 132 matches
Mail list logo
