http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57837
--- Comment #2 from Bernd Edlinger ---
(In reply to Ramana Radhakrishnan from comment #1)
> mine.
fixed with revision 201240 ?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57324
Markus Trippelsdorf changed:
What|Removed |Added
CC||glisse at gcc dot gnu.org
--- Comme
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57324
--- Comment #2 from Markus Trippelsdorf ---
Created attachment 30557
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30557&action=edit
output
unwrapped output
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57699
--- Comment #5 from Bernd Edlinger ---
Well, if a portable O/S like eCos would need such special treatment,
the NO_IMPLICIT_EXTERN_C should not be bound to the target architecture,
it would be far more appropriate to define the NO_IMPLICIT_EXTERN_
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57990
Bug ID: 57990
Summary: cross compilation fails to build zlib
(git-1b179ea9d4020d)
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Pr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57699
--- Comment #6 from Jonathan Wakely ---
(In reply to Bernd Edlinger from comment #5)
> Well, if a portable O/S like eCos would need such special treatment,
eCos doesn't need it
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57837
Ramana Radhakrishnan changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57990
--- Comment #1 from dominik.vogt at gmx dot de ---
Version is commit id 1b179ea9d4020d from git (i.e. current HEAD).
Cross compilation from BUILD=i686-pc-linux-gnu, HOST=i686-pc-linux-gnu to
TARGET=s390-ibm-linux-gnu fails to built zlib.
configur
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57731
Ramana Radhakrishnan changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57699
--- Comment #7 from Bernd Edlinger ---
(In reply to Jonathan Wakely from comment #6)
> (In reply to Bernd Edlinger from comment #5)
> > Well, if a portable O/S like eCos would need such special treatment,
>
> eCos doesn't need it
Of course. In t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57991
Bug ID: 57991
Summary: Enhance "Same actual argument associated" warning
(-Waliasing)
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Keywords: diagnostic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57101
--- Comment #3 from Paolo Carlini ---
This is fixed in mainline. I'm adding the testcase and keeping the bug open
with only the [4.8 Regression] marker.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57101
Paolo Carlini changed:
What|Removed |Added
Summary|[4.8/4.9 Regression]|[4.8 Regression]
|-fcom
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57992
Bug ID: 57992
Summary: Pointless packing of contiguous arrays for simply
contiguous functions results as actual arguments
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: antoine.balestrat at gmail dot com
Hello !
I'm using GCC 4.9.0 as of 20130726 :
$ cat dom.c
int a, b, c, d;
char e;
unsigned g;
void f(void)
{
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57974
--- Comment #14 from Henner Sudek ---
First i want to thank you all for the quick response and solving my problem. I
just want to point out that std::pow(std::complex(0,0),1.) still
returns nan. Maybe there is an way to unify the behavior of these
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57974
--- Comment #15 from Paolo Carlini ---
However, there is *nothing* new about that. I still do believe there is a
middle-end issue here, if only because clang and icc are fine.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57987
--- Comment #1 from Martin Jambor ---
Created attachment 30558
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30558&action=edit
An unsuccessful attempt to fix this
I attempted to fix this with the attached patch but it fails some Fortran
tes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57916
--- Comment #4 from Paolo Carlini ---
Alexey I sent you the questionnaire on July, 21st. Did you get it?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57987
--- Comment #2 from Tobias Burnus ---
Comment on attachment 30558
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30558
An unsuccessful attempt to fix this
>+ if (!has_coarray_vars || gfc_option.coarray == GFC_FCOARRAY_LIB)
>+ (void
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57974
--- Comment #16 from Paolo Carlini ---
Also, in practice, I think it's *very* hard to explain to the users why long
double is so special, why the middle-end can't handle it in complete analogy
with float and double. And since clang and icc are *al
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56429
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54812
--- Comment #9 from Jonathan Wakely ---
*** Bug 56429 has been marked as a duplicate of this bug. ***
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54812
--- Comment #10 from Jonathan Wakely ---
(In reply to Paolo Carlini from comment #3)
> Of course it should be fixed, it *must* be fixed, actually! And it's really
> annoying that this bug affecting private defaulted destructors (which, I
> bet, ar
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54812
--- Comment #11 from Paolo Carlini ---
Jason call if we want this to be a P2. Well, maybe some wrong code bugs I
recently bumped to P2 should be P1 ;)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57993
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57974
--- Comment #17 from Marc Glisse ---
(In reply to Henner Sudek from comment #14)
> First i want to thank you all for the quick response and solving my problem.
> I just want to point out that std::pow(std::complex(0,0),1.)
> still returns nan. May
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57993
Marek Polacek changed:
What|Removed |Added
CC||wschmidt at gcc dot gnu.org
--- Comment #
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57974
--- Comment #18 from Paolo Carlini ---
Couple of clarifications: this doesn't go through cpow at all, the second
argument isn't complex; this isn't -ffast-math, and in general in my experience
whatever you throw at clang and icc (in fact, clang++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57974
Marc Glisse changed:
What|Removed |Added
CC||glisse at gcc dot gnu.org
--- Comment #19 f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57974
Marc Glisse changed:
What|Removed |Added
CC|glisse at gcc dot gnu.org |
--- Comment #20 from Marc Glisse -
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57994
Bug ID: 57994
Summary: Constant folding of infinity
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57306
janus at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|una
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57994
--- Comment #1 from Paolo Carlini ---
Thanks Marc.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57995
Bug ID: 57995
Summary: [4.72, C++11] Lambda [&] wrongly states catch(...)
must be the last handler when variable by-reference
capture occurs within catch(...) scope
Product:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57995
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56388
Paolo Carlini changed:
What|Removed |Added
CC||devcontrib4590 at gmail dot com
--- Comme
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57993
--- Comment #4 from Marek Polacek ---
Thanks. I'd guess that something in slsr_process_phi causes this, but so far I
don't know much more.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57748
--- Comment #5 from Martin Jambor ---
So I only got to this and I definitely won't be able to finish it
today or even this week but here is what I have figured out so far.
We ICE when expanding statement
MEM[(struct resolved_chain *)_19].ips[j
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51784
Dominique d'Humieres changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57413
Dominique d'Humieres changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57993
Bill Schmidt changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57993
--- Comment #5 from Bill Schmidt ---
Looks like the casting is confusing us into replacing PHIs not dominated by the
prospective basis. Shouldn't be too hard to fix.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57993
--- Comment #6 from Bill Schmidt ---
Here's the patch I'm currently testing, which corrects the problem for this
test case. We'll see how it does on regressions.
Index: gcc/gimple-ssa-strength-reduction.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57306
--- Comment #3 from janus at gcc dot gnu.org ---
(In reply to janus from comment #2)
> The following patch seems to fix it ...
... but unfortunately ICEs on a number of tests, e.g. class_{13,18,33,34} and
others.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57954
H.J. Lu changed:
What|Removed |Added
CC||hjl.tools at gmail dot com
--- Comment #2 from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57996
Bug ID: 57996
Summary: Fold more standard complex functions
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priori
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57306
--- Comment #4 from janus at gcc dot gnu.org ---
Here is an enhanced patch which regtests cleanly:
Index: gcc/fortran/trans-decl.c
===
--- gcc/fortran/trans-decl.c(revision 20125
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57954
--- Comment #3 from Evgeniy Dushistov ---
Great, I tested the patch, at now pi calculation as fast as in "icc", and two
times faster then in clang 3.3.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57954
H.J. Lu changed:
What|Removed |Added
Attachment #30560|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42955
Brooks Moses changed:
What|Removed |Added
Last reconfirmed|2010-04-22 20:17:36 |2013-07-26 20:17:36
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57994
--- Comment #2 from joseph at codesourcery dot com ---
There are no errno issues - this is an exact zero result, not underflow.
But I'm not confident that MPFR follows all the Annex F special cases for
infinities and NaNs (and even less confide
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57997
Bug ID: 57997
Summary: Segmentation fault after returning valarray expression
from an auto function
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: maj
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57997
Paolo Carlini changed:
What|Removed |Added
CC||gdr at gcc dot gnu.org
Severity
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57997
--- Comment #2 from Gabriel Dos Reis ---
(In reply to Paolo Carlini from comment #1)
> Gaby, can you help me with this?
I think this is typical confusion about what valarray expressions are.
f1() has some complicated return type that has essenti
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57997
--- Comment #3 from Gabriel Dos Reis ---
Also, there might be some interactions with move semantics; I don't know.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57994
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57998
Bug ID: 57998
Summary: Unhelpful error message when a class has no move
constructor
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: enhancement
58 matches
Mail list logo
