https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64244
--- Comment #7 from janus at gcc dot gnu.org ---
Author: janus
Date: Tue Dec 16 08:15:38 2014
New Revision: 218776
URL: https://gcc.gnu.org/viewcvs?rev=218776&root=gcc&view=rev
Log:
2014-12-16 Janus Weil
PR fortran/64244
* resolve.c (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64244
--- Comment #8 from janus at gcc dot gnu.org ---
The bug should be fixed on trunk with r218776.
Ondrej, in case your test code is part of a larger code base, do you have the
possibility to test it with gfortran trunk?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64326
Bug ID: 64326
Summary: ICE at -O3 on x86_64-linux-gnu in check_probability,
at basic-block.h:581
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64326
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64327
Bug ID: 64327
Summary: ../../gcc/gcc/rtlanal.c:4881:48: runtime error: shift
exponent 4294967295 is too large for 64-bit type 'long
unsigned int'
Product: gcc
Ver
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56459
Tobias Burnus changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64309
--- Comment #13 from rguenther at suse dot de ---
On December 15, 2014 10:11:13 PM CET, "glisse at gcc dot gnu.org"
wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64309
>
>--- Comment #12 from Marc Glisse ---
>(In reply to Marc Glisse fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64326
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64325
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64323
Richard Biener changed:
What|Removed |Added
Keywords||ra
Target|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64323
--- Comment #1 from christophe.lyon at st dot com ---
Maybe this was fixed by Vladimir's commit r218760?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64326
--- Comment #2 from Marek Polacek ---
Started with r211725.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64322
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64322
--- Comment #3 from Jakub Jelinek ---
For VRP I'm thinking of (completely untested):
--- gcc/tree-vrp.c.jj2014-12-01 14:57:30.0 +0100
+++ gcc/tree-vrp.c2014-12-16 10:17:27.543111649 +0100
@@ -2434,6 +2434,7 @@ extract_range_from_b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64319
Richard Biener changed:
What|Removed |Added
Keywords||alias, missed-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63568
Marek Polacek changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64043
--- Comment #11 from Andreas Schwab ---
This breaks ada:
$ gcc/gnatmake --GCC=gcc/xgcc --GNATBIND=gcc/gnatbind --GNATLINK=gcc/gnatlink
-cargs -Bgcc/ -largs '--GCC=gcc/xgcc -Bgcc' -margs
--RTS=ia64-suse-linux/./libada -f ../gcc/testsuite/gnat.dg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64328
Bug ID: 64328
Summary: addr_equal-1.c fails execution.
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64323
--- Comment #2 from Hale Wang ---
(In reply to christophe.lyon from comment #1)
> Maybe this was fixed by Vladimir's commit r218760?
Yes, it's fixed by Vladimir's commit r218760. Thank you very much. This issue
could be marked as fixed now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64323
Hale Wang changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64322
--- Comment #4 from Richard Biener ---
(In reply to Jakub Jelinek from comment #3)
> For VRP I'm thinking of (completely untested):
> --- gcc/tree-vrp.c.jj 2014-12-01 14:57:30.0 +0100
> +++ gcc/tree-vrp.c2014-12-16 10:17:27.543111649
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64322
--- Comment #5 from Jakub Jelinek ---
(In reply to Richard Biener from comment #4)
> (In reply to Jakub Jelinek from comment #3)
> > For VRP I'm thinking of (completely untested):
> > --- gcc/tree-vrp.c.jj 2014-12-01 14:57:30.0 +010
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64329
Bug ID: 64329
Summary: Crash when returning reference from lambda with
deduced type
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: normal
P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64265
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64291
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64291
--- Comment #4 from Jakub Jelinek ---
(In reply to Jakub Jelinek from comment #3)
> Started with r217587.
Oops, sorry for typo, r217588.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64330
Bug ID: 64330
Summary: [ASAN] Bogus "AddressSanitizer: odr-violation"
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priori
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64330
Markus Trippelsdorf changed:
What|Removed |Added
CC||trippels at gcc dot gnu.org
--- Co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64331
Bug ID: 64331
Summary: regcprop propagates registers noted as REG_DEAD
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64331
--- Comment #1 from Senthil Kumar Selvaraj ---
Created attachment 34291
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34291&action=edit
Assembly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61296
--- Comment #8 from H.J. Lu ---
(In reply to Jakub Jelinek from comment #7)
> See discussions when I've added DATA_ABI_ALIGNMENT.
DATA_ABI_ALIGNMENT was added for PR 56564:
/* Similar to DATA_ALIGNMENT, but for the cases where the ABI mandates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61296
--- Comment #9 from Jakub Jelinek ---
(In reply to H.J. Lu from comment #8)
> Do you have a testcase to show decreasing DATA_ALIGNMENT would break
> backwards compatibility with older gcc versions?
Older GCC versions used DATA_ALIGNMENT (what is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61296
--- Comment #10 from H.J. Lu ---
(In reply to Jakub Jelinek from comment #9)
> (In reply to H.J. Lu from comment #8)
> > Do you have a testcase to show decreasing DATA_ALIGNMENT would break
> > backwards compatibility with older gcc versions?
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64330
Jakub Jelinek changed:
What|Removed |Added
CC||jason at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63568
--- Comment #3 from Marek Polacek ---
FWIW, I used this to check the whether the transformation is correct:
int
main ()
{
for (int i = -1000; i < 1000; ++i)
for (int a = -1000; a < 1000; ++a)
for (int b = -1000; b < 1000; ++b)
{
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61296
--- Comment #11 from Jakub Jelinek ---
If you hit the assumption beyond what ABI mandates on some public symbol issue
in some older GCC version, then sure, if you have that public symbol defined by
ICC, it will misbehave. But, if it is compiled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63568
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61296
--- Comment #12 from H.J. Lu ---
(In reply to Jakub Jelinek from comment #11)
> If you hit the assumption beyond what ABI mandates on some public symbol
> issue in some older GCC version, then sure, if you have that public symbol
> defined by ICC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61296
--- Comment #13 from Jakub Jelinek ---
Read the sources? It really depends on many factors.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64330
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63568
--- Comment #5 from Marek Polacek ---
True. E.g. on my x86_64 i7 Nehalem I see (using ./cc1 -quiet -O2 qq.c -mbmi)
andn%edi, %edx, %edi
andl%edx, %esi
movl%edi, %eax
orl %esi, %eax
ret
f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63568
--- Comment #6 from rguenther at suse dot de ---
On Tue, 16 Dec 2014, mpolacek at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63568
>
> --- Comment #5 from Marek Polacek ---
> True. E.g. on my x86_64 i7 Nehalem I see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64331
Richard Biener changed:
What|Removed |Added
Target||avr
Component|rtl-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64291
Richard Biener changed:
What|Removed |Added
Target||x86_64-*-*, i?86-*-*
Priority
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64328
Richard Biener changed:
What|Removed |Added
Component|tree-optimization |testsuite
--- Comment #1 from Richard B
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63473
janus at gcc dot gnu.org changed:
What|Removed |Added
Keywords||wrong-code
Status|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64278
--- Comment #2 from Martin Liška ---
Author: marxin
Date: Tue Dec 16 14:55:29 2014
New Revision: 218779
URL: https://gcc.gnu.org/viewcvs?rev=218779&root=gcc&view=rev
Log:
Fix for PR ipa/64278
* sreal.c (sreal::operator*): Replace std::abs w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64278
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64240
--- Comment #6 from fyang at gcc dot gnu.org ---
Author: fyang
Date: Tue Dec 16 14:58:03 2014
New Revision: 218780
URL: https://gcc.gnu.org/viewcvs?rev=218780&root=gcc&view=rev
Log:
+ PR rtl-optimization/64240
+ * ddg.c (mark_mem_use)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63473
--- Comment #3 from janus at gcc dot gnu.org ---
Here is a slightly compactified test case:
program testprogram
implicit none
type :: mytype_type
integer, allocatable :: i(:)
end type
integer :: n
type(mytype_type), allocatable ::
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63473
--- Comment #4 from janus at gcc dot gnu.org ---
(In reply to janus from comment #3)
> The second message (680 bytes) occurs only with 4.9 upwards (and already in
> the first loop execution).
Actually I think this is not a real regression, but ra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64319
--- Comment #2 from Brian Grayson ---
alignd() in m88ksim from SPECint95 is a poster child for this kind of
optimization -- it receives several pointers to portions of FP representations,
and then operates on them via code like this:
...
*amantl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63473
janus at gcc dot gnu.org changed:
What|Removed |Added
Summary|[4.9/5 Regression] Memory |Memory leak with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64321
janus at gcc dot gnu.org changed:
What|Removed |Added
CC||janus at gcc dot gnu.org
--- C
.file"a.c"
.globlx
.data
.align 64
.typex, @object
.sizex, 128
x:
.byte1
.zero127
.ident"GCC: (GNU) 5.0.0 20141216 (experimental)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-6 pr61296]$
Which older
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64332
Bug ID: 64332
Summary: gcc/g++ handles system_header differently
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64286
--- Comment #1 from Igor Zamyatin ---
Perhaps something like below to restrict ree for such cases?
diff --git a/gcc/ree.c b/gcc/ree.c
index 3376901..92370ea 100644
--- a/gcc/ree.c
+++ b/gcc/ree.c
@@ -1004,6 +1004,11 @@ add_removable_extension (c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64321
Tobias Burnus changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64331
Eric Botcazou changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61189
Kai Tietz changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64244
--- Comment #9 from Ondřej Čertík ---
Janus, thanks a lot for fixing this! Yes, it's part of a large code base. I'll
try the trunk soon.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64332
--- Comment #1 from Andrew Pinski ---
I don't think it is system header which is being handled differently, rather I
think it is warning for attribute is being handled differently.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64244
--- Comment #10 from janus at gcc dot gnu.org ---
(In reply to Ondřej Čertík from comment #9)
> Janus, thanks a lot for fixing this!
You're welcome!
> Yes, it's part of a large code base. I'll try the trunk soon.
That would be great. Since thi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61189
--- Comment #3 from lh_mouse ---
Thanks Kai. It seems to be exactly the same reason that causes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62152. Maybe we should merge them?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64332
--- Comment #2 from Azat ---
On Tue, Dec 16, 2014 at 04:46:28PM +, pinskia at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64332
>
> --- Comment #1 from Andrew Pinski ---
> I don't think it is system header which is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61189
--- Comment #4 from Kai Tietz ---
*** Bug 62152 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62152
Kai Tietz changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64332
--- Comment #3 from Azat ---
On Tue, Dec 16, 2014 at 07:50:48PM +0300, Azat Khuzhin wrote:
> > --- Comment #1 from Andrew Pinski ---
> > I don't think it is system header which is being handled differently,
> > rather I
> > think it is warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64332
Manuel López-Ibáñez changed:
What|Removed |Added
Keywords||diagnostic
Status|UNCO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64332
--- Comment #5 from Azat ---
On Tue, Dec 16, 2014 at 05:16:41PM +, manu at gcc dot gnu.org wrote:
> The C FE does not point to __constructor (3:1 vs 3:19), thus it doesn't
> realize
> this comes from a macro expansion, thus (in your testcase
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64244
--- Comment #11 from Ondřej Čertík ---
On Tue, Dec 16, 2014 at 9:47 AM, janus at gcc dot gnu.org
wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64244
>
> --- Comment #10 from janus at gcc dot gnu.org ---
> (In reply to Ondřej Čertík from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63851
--- Comment #5 from Martin Liška ---
Yes, IPA ICF should respect 'restrict' attribute.
May I ask you to rerun test suite with applied:
diff --git a/gcc/ipa-icf-gimple.c b/gcc/ipa-icf-gimple.c
index ec0290a..98f38ee 100644
--- a/gcc/ipa-icf-gimpl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61591
--- Comment #10 from Martin Jambor ---
Honza, given what you wrote in
https://gcc.gnu.org/ml/gcc-patches/2014-12/msg01033.html
do you want to take over this bug?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61280
Manuel López-Ibáñez changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64313
--- Comment #3 from joseph at codesourcery dot com ---
In the case of expf, if it's used or known to be available in a linked
library then it can be assumed to have the required semantics (since it's
reserved by ISO C90). If it's used it can a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64332
--- Comment #6 from Manuel López-Ibáñez ---
(In reply to Azat from comment #5)
> > Whether the correct behavior is that the system_header applies to the
> > definition or to the expansion location, I am not sure. However, the bad
> > location of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63851
--- Comment #6 from Dominique d'Humieres ---
> Yes, IPA ICF should respect 'restrict' attribute.
> May I ask you to rerun test suite with applied:
My machine is busy regtesting 4.8.4, but a quick test shows that your patch
indeed fixes this PR.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61322
Chris Manghane changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61316
Chris Manghane changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64330
--- Comment #4 from Kostya Serebryany ---
So, maybe the ODR checker in the current form is not that useless.
Sorry, couldn't resist :)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64330
--- Comment #5 from Jakub Jelinek ---
(In reply to Kostya Serebryany from comment #4)
> So, maybe the ODR checker in the current form is not that useless.
> Sorry, couldn't resist :)
But it isn't really an ODR checker. Here it complains if two
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64309
--- Comment #14 from Marek Polacek ---
Author: mpolacek
Date: Tue Dec 16 18:29:01 2014
New Revision: 218787
URL: https://gcc.gnu.org/viewcvs?rev=218787&root=gcc&view=rev
Log:
PR middle-end/64309
* match.pd: Add ((1 << A) & 1) != 0 -> A =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61264
Chris Manghane changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64313
Eric Botcazou changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64309
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61273
--- Comment #1 from ian at gcc dot gnu.org ---
Author: ian
Date: Tue Dec 16 18:53:46 2014
New Revision: 218788
URL: https://gcc.gnu.org/viewcvs?rev=218788&root=gcc&view=rev
Log:
PR go/61273
compiler: Send statements should contextually permi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64328
--- Comment #2 from Jan Hubicka ---
Indeed, the testcase is meant to be nopic. I will check how to test for that
in dg.
Honza
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61264
--- Comment #2 from ian at gcc dot gnu.org ---
Author: ian
Date: Tue Dec 16 19:14:54 2014
New Revision: 218789
URL: https://gcc.gnu.org/viewcvs?rev=218789&root=gcc&view=rev
Log:
PR go/61264
compiler: Fix copying behavior for empty composite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61296
--- Comment #15 from H.J. Lu ---
(In reply to Jakub Jelinek from comment #13)
> Read the sources? It really depends on many factors.
There are
int max_align_compat
= optimize_size ? BITS_PER_WORD : MIN (256, MAX_OFILE_ALIGNMENT);
With -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54687
--- Comment #6 from Tobias Burnus ---
Missed the PR number for the commit r218790:
2014-12-16 Tobias Burnus
PR fortran/54687
* lang.opt (fsecond-underscore, frecord-marker=8, frecord-marker=4,
frealloc-lhs, freal-8-re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64328
--- Comment #3 from Tejas Belagod ---
(In reply to Jan Hubicka from comment #2)
> Indeed, the testcase is meant to be nopic. I will check how to test for
> that in dg.
>
> Honza
{ dg-require-effective-target nonpic } ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64320
--- Comment #1 from Rich Townsend ---
OK, it seems that this bug comes from building with srcdir == objdir. If I
build in a separate directory, then the problem goes away.
As an aside, I hadn't realized that using srcdir == objdir is generally
d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63568
--- Comment #7 from Oleg Endo ---
If you decide not to do the transform at the tree level, please change this to
a target PR and assign it to me.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64333
Bug ID: 64333
Summary: C++14 constexpr gives wrong results when a looping
constexpr function is evaluated twice
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Ke
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54687
--- Comment #7 from Tobias Burnus ---
Author: burnus
Date: Tue Dec 16 20:44:45 2014
New Revision: 218792
URL: https://gcc.gnu.org/viewcvs?rev=218792&root=gcc&view=rev
Log:
2014-12-16 Tobias Burnus
PR fortran/54687
* gfortran.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64244
--- Comment #12 from janus at gcc dot gnu.org ---
(In reply to Ondřej Čertík from comment #11)
> So my system (RHEL6) libstdc++ library might be incompatible with the
> trunk, but I don't see why gcc couldn't compile. Any ideas how to fix
> this?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63568
--- Comment #8 from Marek Polacek ---
(In reply to Oleg Endo from comment #7)
> If you decide not to do the transform at the tree level, please change this
> to a target PR and assign it to me.
I have a patch that does the transformation on matc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53513
--- Comment #46 from Oleg Endo ---
Author: olegendo
Date: Tue Dec 16 21:28:59 2014
New Revision: 218793
URL: https://gcc.gnu.org/viewcvs?rev=218793&root=gcc&view=rev
Log:
gcc/testsuite/
PR target/53513
* gcc.target/sh/fpchg.c: Rename to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61246
--- Comment #3 from ian at gcc dot gnu.org ---
Author: ian
Date: Tue Dec 16 21:36:53 2014
New Revision: 218794
URL: https://gcc.gnu.org/viewcvs?rev=218794&root=gcc&view=rev
Log:
PR go/61246
compiler: Switch expression comparisons should be b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #32 from Oleg Endo ---
Author: olegendo
Date: Tue Dec 16 21:37:42 2014
New Revision: 218795
URL: https://gcc.gnu.org/viewcvs?rev=218795&root=gcc&view=rev
Log:
gcc/testsuite/
PR target/54089
* gcc.target/sh/pr54089-1.c: Change
1 - 100 of 123 matches
Mail list logo
