http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410
--- Comment #25 from Kostya Serebryany kcc at gcc dot gnu.org ---
https://bugzilla.kernel.org/show_bug.cgi?id=66721
Good! Looking forward for a fix and hoping to have it in the next Ubuntu LTS.
Any chance?
Is there anything else we could do
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52898
--- Comment #7 from Oleg Endo olegendo at gcc dot gnu.org ---
Kaz, I'd like to deprecate the mcbranchdi and mcmpeqdi options in 4.9 and make
the current default values fixed as follows:
mcbranchdi is usually enabled (it gets disabled in some SH5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59409
--- Comment #7 from rguenther at suse dot de rguenther at suse dot de ---
hjl.tools at gmail dot com gcc-bugzi...@gcc.gnu.org wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59409
--- Comment #3 from H.J. Lu hjl.tools at gmail dot com ---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52898
--- Comment #8 from Kazumoto Kojima kkojima at gcc dot gnu.org ---
I'm OK with it.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18649
--- Comment #10 from Kai Tietz ktietz at gcc dot gnu.org ---
For mingw-code this bug is fixed. It was caused by a bug in SjLj catch-reason.
Issue is fixed for 32-bit and 64-bit mingw targets for all open branches.
As report was for different
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59414
janus at gcc dot gnu.org changed:
What|Removed |Added
Keywords||rejects-valid
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59409
--- Comment #8 from H.J. Lu hjl.tools at gmail dot com ---
(In reply to rguent...@suse.de from comment #7)
hjl.tools at gmail dot com gcc-bugzi...@gcc.gnu.org wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59409
--- Comment #3 from H.J.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19970
Kai Tietz ktietz at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410
--- Comment #26 from H.J. Lu hjl.tools at gmail dot com ---
(In reply to Kostya Serebryany from comment #25)
https://bugzilla.kernel.org/show_bug.cgi?id=66721
Good! Looking forward for a fix and hoping to have it in the next Ubuntu LTS.
Any
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56686
Kai Tietz ktietz at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59414
--- Comment #2 from janus at gcc dot gnu.org ---
This draft patch fixes the error (but has not been regtested yet):
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59416
Bug ID: 59416
Summary: A nested template reusing the template arguments of
the enclosing type in a template template argument not
working
Product: gcc
Version:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59414
--- Comment #3 from janus at gcc dot gnu.org ---
(In reply to janus from comment #2)
With the patch the reduced test case in comment 1 compiles cleanly, but the
full code in comment 0 then gives an ICE on a different location:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59414
--- Comment #4 from janus at gcc dot gnu.org ---
Btw, when using the second (commented-out) version of 'AddArray' (which
apparently crashes with ifort), the full code in comment 0 compiles cleanly
with gfortran trunk plus the patch in comment 2.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59414
--- Comment #5 from Antony Lewis antony at cosmologist dot info ---
Thanks for the quick fix!
The sourced allocate errors crop up in various places in the full code, and
already seem to be known in several bug reports, e.g.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59414
--- Comment #6 from janus at gcc dot gnu.org ---
(In reply to Antony Lewis from comment #5)
The sourced allocate errors crop up in various places in the full code, and
already seem to be known in several bug reports, e.g.
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: antoine.balestrat at gmail dot com
Hi !
I'm using GCC 4.9 20131207.
$ cat deter.c
int a, b, d;
short c;
void f(void)
{
if(b)
{
int *e;
if(d
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59417
Markus Trippelsdorf octoploid at yandex dot com changed:
What|Removed |Added
CC||jakub at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59414
--- Comment #7 from Dominique d'Humieres dominiq at lps dot ens.fr ---
The issue of comment 3 appeared between revisions 187190 (2012-05-05) and
187198 (actually 187193 and I'ld bet for 187192).
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44672
janus at gcc dot gnu.org changed:
What|Removed |Added
Keywords||rejects-valid
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59414
--- Comment #8 from janus at gcc dot gnu.org ---
The patch in comment 2 regtests cleanly.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59011
--- Comment #7 from Mikael Pettersson mikpelinux at gmail dot com ---
It appears the test case wasn't added to 4.8 branch.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59414
janus at gcc dot gnu.org changed:
What|Removed |Added
CC||pault at gcc dot gnu.org
---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59011
--- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org ---
Author: jakub
Date: Sat Dec 7 15:43:05 2013
New Revision: 205783
URL: http://gcc.gnu.org/viewcvs?rev=205783root=gccview=rev
Log:
PR middle-end/59011
* gimplify.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58864
--- Comment #10 from Jakub Jelinek jakub at gcc dot gnu.org ---
Author: jakub
Date: Sat Dec 7 15:43:48 2013
New Revision: 205784
URL: http://gcc.gnu.org/viewcvs?rev=205784root=gccview=rev
Log:
PR target/58864
* optabs.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59409
--- Comment #9 from rguenther at suse dot de rguenther at suse dot de ---
hjl.tools at gmail dot com gcc-bugzi...@gcc.gnu.org wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59409
--- Comment #8 from H.J. Lu hjl.tools at gmail dot com ---
(In
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59409
--- Comment #10 from H.J. Lu hjl.tools at gmail dot com ---
(In reply to rguent...@suse.de from comment #9)
Is that ever possible to have latch execution count 0
and FIRST_NITERS == 0? It happens in x32 253.perlbmk.
That should be
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59409
--- Comment #11 from H.J. Lu hjl.tools at gmail dot com ---
latch execution count can be an expression like if (b) in
gcc.dg/torture/pr59058.c. Will such an expression be possible
negative at run-time?
-threads=posix --enable-symvers=gnu --enable-c99
--enable-long-long --enable-target-optspace
target_alias=arm-unknown-linux-gnueabi --enable-languages=c++ --disable-shared
--disable-libmudflap --disable-libssp --enable-checking
Thread model: posix
gcc version 4.9.0 20131207 (experimental) [trunk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59409
--- Comment #12 from H.J. Lu hjl.tools at gmail dot com ---
This function:
SV *
sv_mortalcopy(SV *oldstr)
{
dTHR;
register SV *sv;
new_SV(sv);
SvANY(sv) = 0;
SvREFCNT(sv) = 1;
SvFLAGS(sv) = 0;
sv_setsv(sv,oldstr);
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59411
janus at gcc dot gnu.org changed:
What|Removed |Added
CC||janus at gcc dot gnu.org
---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59411
--- Comment #2 from janus at gcc dot gnu.org ---
(In reply to janus from comment #1)
One should check the
Fortran standard for restrictions in the case of C_PTRs (which, strictly
speaking, are no actual pointers in the Fortran sense).
Since
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59414
kargl at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P4
Severity|blocker
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59411
--- Comment #3 from janus at gcc dot gnu.org ---
In F03, I think the relevant quotes are:
R506 initialization is = initialization-expr
or = null-init
7.1.7 Initialization expression
An initialization expression is an
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59409
--- Comment #13 from H.J. Lu hjl.tools at gmail dot com ---
loop in Perl_pp_aassign is miscompiled:
44098a: e8 91 38 05 00 callq 494220 Perl_sv_mortalcopy
44098f: 67 89 03mov%eax,(%ebx)
440992:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59409
--- Comment #14 from H.J. Lu hjl.tools at gmail dot com ---
(In reply to H.J. Lu from comment #13)
loop in Perl_pp_aassign is miscompiled:
44098a: e8 91 38 05 00 callq 494220 Perl_sv_mortalcopy
44098f: 67 89 03
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59414
--- Comment #10 from janus at gcc dot gnu.org ---
Author: janus
Date: Sat Dec 7 19:27:19 2013
New Revision: 205785
URL: http://gcc.gnu.org/viewcvs?rev=205785root=gccview=rev
Log:
2013-12-07 Janus Weil ja...@gcc.gnu.org
PR fortran/59414
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59414
--- Comment #11 from janus at gcc dot gnu.org ---
r205785 fixes the original error (i.e. comment 1). ToDo: The ICE regression of
comment 3.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59419
Bug ID: 59419
Summary: [4.9 Regression] Failing OPEN with FILE='xxx' and
IOSTAT creates the file 'xxx' after revision 196783
Product: gcc
Version: 4.9.0
Status:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59419
Tobias Burnus burnus at gcc dot gnu.org changed:
What|Removed |Added
CC||burnus at gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59419
Tobias Burnus burnus at gcc dot gnu.org changed:
What|Removed |Added
Keywords||wrong-code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59420
Bug ID: 59420
Summary: arm: broken code generated (memset from newlib 2.0)
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59420
--- Comment #1 from Alexander Holler holler at ahsoftware dot de ---
Created attachment 31397
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31397action=edit
memset.s
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59421
Bug ID: 59421
Summary: stof(), stod() wrong result
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59420
--- Comment #2 from Richard Earnshaw rearnsha at gcc dot gnu.org ---
You'll get more attention paid to this if you can describe why you think the
code generated is incorrect.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59420
Andrew Pinski pinskia at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59421
Andrew Pinski pinskia at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59421
--- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org ---
(In reply to Andrew Pinski from comment #1)
Do you have a full testcase that is able to compile and work?
s/work/run/
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59300
--- Comment #1 from Rafael Avila de Espindola rafael.espindola at gmail dot
com ---
clang had an even stranger behavior
(http://llvm.org/bugs/show_bug.cgi?id=18174). I fixed that in a way that it now
agrees with gcc on the testcase in this bug.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59419
--- Comment #3 from Jerry DeLisle jvdelisle at gcc dot gnu.org ---
I will take this one if you like.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59420
--- Comment #4 from Alexander Holler holler at ahsoftware dot de ---
Thanks a lot for the very fast solution.
I wasn't aware that gcc does such optimizations and maybe posted the bug too
fast without really having examined the assembler.
Using
51 matches
Mail list logo
